GL - 1-Introduction Au Génie Logiciel

Génie Logiciel
Objectifs du cours
 Avoir les notions de base du génie logiciel

 Maitriser les différents modèles de processus de
développement logiciel
 Avoir un aperçu sur les méthodes d’analyse des besoins
et spécification du logiciel
 Acquérir les techniques de conception, de
programmation et de tests de logiciels.
Logiciel – définitions
 Logiciel:
un ensemble d’entités nécessaires au fonctionnement
d’un processus de traitement automatique de l’information:
 des programmes (en format code source ou exécutables)
 des données
 des documentations d’utilisation
 des informations de configuration.
Logiciel = programmes + utilisation

Catégories de logiciels
Logiciels génériques vendus comme les produits courants.
 Logiciels sans impact économique significatif (logiciels amateurs)

 Logiciels jetables ou consommables (par exemple les traitements de
texte), leur remplacement n’engendrent pas de risque majeur pour
l’entreprise.
Logiciels spécifiques développés pour une application précise et

destinés à un seul client
 Logiciels essentiels au fonctionnement d’une entreprise. Ce type de

logiciel est le fruit d’un investissement non négligeable et doit avoir un
comportement fiable, sûr et sécurisé.
 Logiciels vitaux, c’est-à-dire ceux dont dépend la vie d’êtres humains
(domaines du transport et de la médecine).
Logiciel de qualité
Critères côté client
Validité
Efficacité
Ergonomie
Facilité d’apprentissage
Fiabilité dans le temps
Sécurité
Intégrité
Critères côté concepteur
Modularité
Réutilisabilité
Lisibilité
Clarté Facilité d’extension et de maintenance
Portabilité
Compatibilité
Testabilité
Crise du logiciel
 Historiquement, il y a eu une prise de conscience dans les

années 70, appelée la crise du logiciel, c’est à cette époque que
le coût de construction du logiciel est devenu plus important
que celui de la construction du matériel.
 Constat du développement logiciel fin années 60 :

 Délais de livraison non respectés,
 Budgets non respectés,
 Logiciel ne répondant pas aux besoins de l'utilisateur,
 Logiciel difficile à utiliser, maintenir, et faire évoluer.
É tude du DoD 1995
Étude du Department of Defense des États-Unis sur les logiciels
produits dans le cadre de 9 gros projets militaires:
Génie logiciel - définitions
 Ensemble des méthodes, des techniques et des outils dédiés à

la conception, au développement et à la maintenance des
systèmes informatiques,
 Un domaine des sciences de l’ingénieur dont l’objet d’étude est

la conception, la fabrication, et la maintenance des systèmes
informatiques complexes.
Génie logiciel - objectifs
 Avoir des procédures systématiques pour des logiciels de

grande taille afin que:
 la spécification corresponde aux besoins réels du client,
 le logiciel respecte sa spécification,
 les coûts alloués à la réalisation soient respectés,
 les délais de réalisation sont respectés.
 Le but du génie logiciel est d’optimiser le coût et la qualité de

mise en œuvre (développement, évolution et maintien) du
logiciel.
Exemples d’échecs
Exemples d’abandons
 Confirm (1992) : projet d’American Airlines de système de réservation commun

(avions, voitures, hôtels, etc.). Investissement : 125 M $ sur 4 ans, plus de 200
ingénieurs. Résultat : les différentes parties n’ont pas pu être assemblées en
raison de la diversité des méthodes de développement.
 Taurus (1993) : projet d’automatisation des transactions pour la bourse de
Londres annulé après 5 années de développement. Pertes estimées à 75 M $
pour la société et 450 M $ pour les clients.
Exemple de bug
 Ariane V (1996) : explosion de la fusée en vol due à une erreur de débordement

lors de la conversion d’un nombre flottant 64 bits vers un entier 16 bits.
Raisons de la faible qualité des logiciels
 Manque de méthodes et d'outils :

 Manque de méthodes de conception,
 Négligence et manque de méthodes et d'outils des phases de
validation/vérification.
 Mauvaise compréhension des besoins :
 Négligence de la phase d'analyse des besoins du client
 Manque d'implication du client dans le processus
Raisons de la faible qualité des logiciels
Solution à cette crise
 Appliquer les méthodes connues de l’ingénierie au

domaine du logiciel, pour établir des méthodes fiables sur
lesquelles construire une industrie du logiciel.
 Il s’agit de se donner un cadre rigoureux pour :

1. Guider le développement du logiciel, de sa conception à sa
livraison.
2. Contrôler les coûts, évaluer les risques et respecter les
délais.
3. Établir des critères d’évaluation de la qualité d’un logiciel.
Génie logiciel
 Idée du Génie Logiciel:

Appliquer les méthodes classiques d'ingénierie au domaine du
logiciel.
 Ingénierie (ou génie) : Ensemble des fonctions allant de la
conception et des études à la responsabilité de la construction
et au contrôle des équipements d'une installation technique ou
industrielle.
 Exemples d’ingénieries: génie civil, génie aéronautique, génie
mécanique, génie chimique...
Spécificités du logiciel
 La construction d’un logiciel diffère de celle d’un pont :

 une modification infime peut avoir des conséquences critiques ;
 les progrès technologiques très rapides peuvent rendre un logiciel
caduque ;
 les domaines des entrées des logiciels sont trop grands pour le test
exhaustif ;
 les défaillances des programmes sont en général dues à des erreurs
humaines ;
 chaque logiciel a son organisation et sa logique propre.
Les grands principes du génie logiciel
 La décomposition des problèmes en sous-problèmes
 La modularité
 L’anticipation des évolutions
 La généricité
 La construction incrémentale
Principe 1 — décomposition en sous-problèmes
 Il s’agit de :
 Décorréler les problèmes pour n’en traiter qu’un seul à la fois;
 Simplifier les problèmes (temporairement) pour aborder leur
complexité progressivement.
 Exemple:
Comment créer dynamiquement une page internet pour visualiser et
modifier le contenu d’une base donnée sans la corrompre ?
Décomposition en trois composants :
 Modèle pour gérer le stockage des données.
 Vue pour formater les données.
 Contrôleur pour n’autoriser que les modifications correctes.
Principe 2 — la modularité
 C’est une instance cruciale du principe de décomposition des

problèmes.
 Production de composants assemblables et utilisables dans plusieurs
réalisations
Principe 3 — l’anticipation des évolutions
 Un logiciel a un cycle de vie plus complexe que l’habituel :

commande → spécification → production → livraison.
 La maintenance est la gestion des évolutions du logiciel.
 Il est primordial de prévoir les évolutions possibles d’un logiciel pour
que la maintenance soit la plus efficace possible.
Principe 4 — la généricité
Figure : template
 Un logiciel réutilisable a beaucoup plus de valeur qu’un composant

dédié.
 Un composant est générique lorsqu’il est adaptable.
Principe 5 — la construction incrémentale
 Un développement logiciel a plus de chances d’aboutir s’il suit

un cheminement incrémental.
 Exemple: Laquelle de ses deux méthodes de programmation
est la plus efficace ?
1) Écrire l’ensemble du code source d’un programme et
compiler.
2) Écrire le code source d’une fonction ou module, le compiler,
et passer à la suivante.
Processus de développement logiciel
 Processus: un ensemble structuré d’activités qui conduisent à

la production d’un logiciel.
 En pratique :
 Il n’existe pas de processus idéal,
 Choix du processus en fonction des contraintes (taille des équipes,
temps, qualité...)
Cycle de vie d’un logiciel
 Activités du développement logiciel :

 Analyse des besoins,
 Spécification,
 Conception,
 Programmation (implémentation),
 Validation et vérification,
 Livraison,
 Maintenance (évolution).
 Pour chaque activité : Utilisation et production de documents.
Analyse des besoins
Objectif : Comprendre les besoins du client :
 Elle a pour but de dégager le problème à étudier.

 Le résultat de l'analyse est le cahier de charges (exprimé dans une
langue naturelle) contenant les besoins du futur système.
 3 phases:(Faisabilité, Spécifications des besoins, Organisation du
projet)
Analyse des
besoins
Besoins du Cahier des charges
client ( + manuel d'utilisation
préliminaire)
Analyse des besoins
Faisabilité
 Première étape du cycle de vie d’un logiciel

 Répondre à deux questions :
 Est-ce que le logiciel est réalisable ?
 Est-ce que le développement proposé vaut la peine
d’être mis en œuvre ?
►► Étudier le marché pour déterminer s’il existe un

marché potentiel pour le produit.
Spécification des besoins
26
Permet de définir ce que doit faire le logiciel et non

comment il le fait
Quatre types de spécifications
 Spécifications générales
 Spécifications fonctionnelles
 Spécifications d’interface
 Spécifications techniques
Spécification des besoins: spécification
27
générale
La spécification générale consiste à identifier :
Objectifs à atteindre.
Contraintes (utilisation du matériel et outils
existants).
Règles de gestion à respecter.
Spécification des besoins: fonctionnelles et
28
interface
Spécification fonctionnelles
description des fonctionnalités du futur logiciel
de manière détaillée que possible
Spécification d’interface
décrit les interfaces du logiciel avec le monde
extérieur : homme (IHM), autres logiciel
(Middleware), machines
Spécification des besoins: Spécification
29
technique
Spécification technique :(Étude de l’existant)
 Moyens d’accès (local, distant, Internet, …)
 Temps de réponse acceptable (gestion des GAB, gestion
des emplois de temps, …)
 Plateforme (Windows, Unix, …)
 Quantité d’informations à stocker (choix du SGBDR, …)
Organisation du projet
30
Appelée aussi Planification et gestion de projet

Permet de déterminer la manière de développer le logiciel
La phase de planification permet de :
 découper le projet en tâches
 décrire leur enchaînement dans le temps,
 affecter à chacune une durée et un effort
Organisation du projet
31
Plusieurs étapes :
Analyse des coûts: estimation du prix du projet
Planification: calendrier pour le développement (jours
ouvrables, jours fériés, nombre d’heures de travail par
jours, …)
Répartition des tâches: distribuer les tâches et les sous
tâches (affectation des ressources aux tâches)
Spécification
Spéciﬁcatio
n
Cahier des Cahier des
charges charges
fonctionnel
Conception
 Objectif : Élaborer une solution concrète réalisant la spécification

 Description architecturale en composants (avec interface et
fonctionnalités)
 Réalisation des fonctionnalités par les composants (algorithmes,
organisation des données)
 Réalisation des exigences non fonctionnelles (performance,
sécurité…)
Conceptio
n
Cahier des Dossier de
charges conception
fonctionnel
Programmation
 Objectif : Implantation de la solution conçue.

 Choix de l'environnement de développement, du/des langage(s) de
programmation, de normes de développement...
Programmatio
n
Dossier de Code documenté
conception + manuel d'utilisation
Validation et vérification
 Objectifs :
 Validation : assurer que les besoins du client sont satisfaits (au niveau
de la spécification, du produit fini...)
Concevoir le bon logiciel.
 Vérification : assurer que le logiciel satisfait sa spécification.
Concevoir le logiciel correctement.
Validation
Cahier des
Besoins charges Logicie
du fonctionne l
client l
Vériﬁcatio
n
Validation et vérification
36
On distingue plusieurs types de tests :

Test unitaire: tester les parties du logiciel par les développeurs
Test d’intégration: tester pendant l’intégration des modules
Test système: tester dans un environnement proche à celui de
production
Test alpha: tests faits par le client sur le site de développement
Test bêta: tests faits par le client sur le site de production
Test de régression: enregistrer les résultats des tests et les comparer
avec ceux des anciens versions pour déterminer si la nouvelle n’a pas
apporté de dégradation de performance.
Livraison
37
Fournir au client une solution logiciel qui

fonctionne correctement.
Plusieurs tâches :
Installation: rendre le logiciel opérationnel sur le site du
client
Formation: enseigner aux utilisateurs à se servir de ce
logiciel
Assistance: répondre aux questions de l’utilisateur
Maintenance
 Types de maintenance :
 Correction : identifier et corriger des erreurs trouvées après la

livraison.
 Adaptation : adapter le logiciel aux changements dans
l'environnement (format des données, environnement
d'exécution...).
 Perfection : améliorer la performance, ajouter des
fonctionnalités, améliorer la maintenabilité du logiciel.
Répartition de l'effort
processus de développement d’un logiciel
Qu’est ce que le processus de développement d’un logiciel?
un ensemble structuré d’activités nécessaires pour développer

un logiciel
Cycle de vie en cascade
Le modèle en cascade est une organisation des activités

d'un projet sous forme de phases linéaires et séquentielles, où
chaque phase correspond à une spécialisation des tâches et
dépend des résultats de la phase précédente. Il comprend les
phases d'exigences, de conception, de mise en œuvre et de
mise en service.
Le cycle en cascade
Avantages:
simple et logique
facilité de planification des étapes et des délais
adapté à des petits systèmes
Spécification Cahier des charge

s fonctionnel
Conception Dossier de
conception détaill
ée
Implémentation Code documenté +
Rapport de tests unitaire
s
Vérification
Validation Rapport de validatio
n
Livraison
et maintenan
ce
Le modèle en cascade se base sur des exigences exprimées en début de projet.

Toutefois les exigences et besoins peuvent se montrer incomplets ou de qualité
insuffisante (ambiguïté, incohérence, etc.). De plus, le client peut ne pas être
pleinement conscient de ses besoins avant d'avoir vu le logiciel fonctionner.
Ceci peut conduire à revoir:
 La conception
 Redévelopper un partie du logiciel
 Retester le produit
et donc augmenter les coûts. C'est pourquoi le modèle en cascade est

particulièrement adapté à des projets dont les exigences sont bien comprises et
robustes réalisés avec une technologie bien maîtrisée
Cycle de vie en cascade — critiques
Critiques:Résumé
 Aucune validation intermédiaire
 Impossibilité de suivre le déroulement du projet, donc de
planifier un travail en équipe;
 Augmentation des risques car la validation est tardive :
erreur d’analyse ou de conception très coûteuse.
 Solution limitée aux petits problèmes
 Risques bien délimités dès le début du projet;
 Projet court avec peu de participants.
 Ce modèle est inadapté au développement de systèmes
dont la spécification est difficile à formuler a priori.
Cycle de vie en V
Le cycle en V est un modèle d'organisation des activités d'un

projet qui se caractérise par un flux d'activité descendant qui
détaille le produit jusqu'à sa réalisation, et un flux ascendant,
qui assemble le produit en vérifiant sa qualité.
Cycle de vie en V
Avantages:
facile à comprendre
segmente clairement le projet
vérifications adaptées à chaque étape

Cycle de vie en V - Niveaux de test
 Test unitaire : test de chaque unité de programme (méthode,

classe, composant), indépendamment du reste du système.
 Test d'intégration : test des interactions entre composants
(interfaces et composants compatibles).
 Test système : test du système complet par rapport à son
cahier des charges.
 Test d'acceptation (recette) : fait par le client, validation par
rapport aux besoins initiaux.
Cycle de vie en V : limitations
 Un modèle toujours séquentiel

 Prédominance de la documentation sur l’intégration :
validation tardive du système global;
 Maintenance non intégrée : logiciel jetable.
 Adapté aux problèmes bien connu
 Idéal quand les besoins sont bien connus, quand l’analyse et
la conception sont claires
Modèle de prototypage
 Principe :
 Développement rapide d'un prototype avec le client pour valider
ses besoins;
 Écriture de la spécification à partir du prototype, puis processus
de développement linéaire.
Cahier
Besoins des charges
Prototype Logiciel
du client fonctionnel
 Avantages : Validation concrète des besoins, moins de

risques d'erreur de spécification.
Modèles incrémentaux
 Principe :
 Hiérarchiser les besoins du client
 Concevoir et livrer au client un produit implantant un sous-
ensemble de fonctionnalités par ordre de priorité
Spécification Spéc. Spéc. Spéc. Spéc.

Conception Conc. Conc. Conc. Conc.
Programmation Prog. Prog. Prog. Prog.
Validation et vérificatio V&V V&V V&V V&V
n
Livraison Livr. Livr. Livr.
Livr.
Développement en cascad Développement
e incrémental
Modèles incrémentaux
 Avantages :
 Capture des besoins continue et évolutive;
 Détection des erreurs;
 Etat d’avancement connecté à la réalité;
 Implication des clients/utilisateurs;
 Inconvénients :
 Explosion des besoins;
 Difficile définition de la dimension d’un incrément ;
Modèle en spirale
Le modèle en spirale (spiral model) est un modèle de Cycle de développement
logiciel qui reprend les différentes étapes du cycle en V. Par l'implémentation de
versions successives, le cycle recommence en proposant un produit de plus en
plus complet et dur.
Modèles de processus- Conclusion
Quel est le meilleur modèle ?
Pas de modèle idéal, tout dépend des caractéristiques de

votre projet !
UML
Unified Modeling Language
Qu’est ce que UML ?
UML (Unified Modeling Language) est un langage (et non pas

une méthode) qui permet de représenter les modèles ne définit
pas le processus d'élaboration des modèles.
UML propose donc un ensemble de notations pour que chacun

ait à sa disposition les éléments nécessaires à la conception d'une
application.
Modèles
Un modèle est une représentation partielle de la réalité:

Abstraction de ce qui est intéressant pour un contexte donné.
Vue subjective et simplifiée d'un système.
Avec UML, on va s'intéresser principalement aux modèles d'applications
informatiques
Un modèle UML = des diagrammes UML
Utilité des modèles:
Faciliter la compréhension d'un système
Permettre la communication avec le client
Définir voire simuler le fonctionnement d'un système
Vision de développement, de production.
Historique
UML est né en octobre 1994 chez Rational Software Corporation à l’initiative de G. Booch et
de J. Rumbaugh. UML 1.1 a été standardisé par l’OMG (Object Management Group) le 17
novembre 1997 suite à la demande émanant de la collaboration de plusieurs entreprises
(Hewlett-Packard, IBM, i-Logix, ICON Computing, IntelliCorp, MCI Systemhouse, Microsoft,
ObjecTime, Oracle, Platinum Technology, Ptech, Rational Software Corporation, Reich
Technologies, Softeam, Sterling Software, Taskon et Unisys).
Les versions se succèdent :

Début 1998:UML 1.2
En 1998:UML 1.3
En 2001:UML1.4
En 2003:UML 1.5
En 2005:UML 2.0
Diagrammes d'UML
UML 2.0 comporte ainsi treize types de diagrammes représentant autant de
vues distinctes pour représenter des concepts particuliers du système
d’information. Ils se répartissent en deux grands groupes :
Diagrammes structurels ou diagrammes statiques

 De classes (class diagram)
 D'objets (object diagram)
 De composants (component diagram)
 De structure composite (composite structure diagram)
 De déploiement (deployment diagram)
 De paquetages (package diagram)
Diagrammes de comportement diagrammes dynamiques

 De cas d'utilisation (use case diagram)
 D'activité (activity diagram)
 D'états-transition (state diagram)
 De séquence (sequence diagram)
 Vue générale d'interaction (interaction overview diagram)
 De communication (communication diagram)
 De temps (timing diagram)
Diagramme d’UML
Les diagramme d’UML peuvent être utilisés pour

représenter différents points de vues :
Vue externe : vue du système par ses utilisateurs finaux
Vue logique statique : structure des objets et leurs relations
Vue logique dynamique : comportement du système
Vue d’implémentation : composants logiciels
Vue de déploiement : répartition des composants
Diagramme d’UML
UML
Diagrammes de cas
d'utilisation
Diagrammes des cas d'utilisation
Décrit, sous forme d’actions et de réactions, le comportement

d’un système du point de vue d’un utilisateur.
Permet de définir les limites du système et ses relations avec
l’environnement.
Sert à modéliser les aspects dynamiques d'un système

Fait ressortir les acteurs et les fonctions offertes par le
système.
Utilisé pour modéliser les exigences (besoins) du client
Comportent plusieurs éléments :

Acteurs
Cas d'utilisation
Relations de dépendances, de généralisations et d'associations
Acteurs
UML n’emploi pas le terme d’utilisateur mais d’acteur.
Le terme acteur ne désigne pas seulement des utilisateurs humains mais également les
autres systèmes (machines, programmes, …)
Un acteur est un rôle joué par une entité externe qui agit sur le système (Comptabilité,
service commercial, …), en échangeant de l’information (en entrée et en sortie)
Les acteurs donc peuvent être de trois types :

Humains : utilisateurs du logiciel à travers son interface graphique.
Logiciels : disponibles qui communiquent avec le système grâce à une interface
logicielle (API, ODBC, …)
Matériels : exploitant les données du système ou qui sont pilotés par le système
(Imprimante, robots, automates, …)
Acteurs
Remarques
La même personne physique peut jouer le rôle de plusieurs
acteurs (Chef d’agence est un client de la banque).
D’autres part, plusieurs personnes peuvent jouer le même rôle,
et donc agir comme un même acteur (plusieurs personnes
peuvent jouer le rôle d’administrateur).
Acteurs
Peut être représenté de deux manières différentes :
Petit personnage (stick man)
Nom Acteur
Classe stéréotypée
<<Acteur>>
Nom Acteur
Acteurs
<<acteur>>
Secrétaire Site Web de l'établissement
Etudiant
Système de Gestion
Scolaire
<<acteur>>
Imprimante
Acteurs
du point de vue système on distingue deux types :
Acteurs principaux : utilisent les fonctions principales du
système. Par exemple, le client pour un distributeur de billets.
Acteurs secondaires : effectuent des tâches administratives ou
de maintenance. Par exemple, la personne qui recharge la
caisse contenue dans le distributeur.
Acteurs
Un acteur peut être une spécialisation

d'un autre acteur déjà défini.
Acteur général
Dans ce cas, on utilise la relation de

généralisation/spécialisation.
Acteur spécialisé
Cas d'utilisation
Introduit par Ivar Jacobson en 1992 dans sa méthode Object-

Oriented Software Engineering (OOSE).
Repris par UML dans la but de :
--Effectuer une bonne délimitation du système
--Améliorer la compréhension de son fonctionnement interne
Cas d'utilisation
Les cas d’utilisations

Permettent de modéliser les attentes (besoins) des utilisateurs
Représentent les fonctionnalités du système
Suite d’événements, initiée par des acteurs, qui correspond à une
utilisation particulière du système
L’image d’une fonctionnalité du système, déclenchée en réponse à la
stimulation d’un acteur externe.
Cas d'utilisation
Un cas d'utilisation est représenté par une ellipse en trait plein,

contenant son nom.
Nom Cas Utilisation

Structuration des cas d'utilisation
Après avoir identifié les acteurs et les cas d'utilisation, il est

utile de restructurer l'ensemble des cas d'utilisation que l'on a
fait apparaître afin de rechercher les :
Comportements partagés
Cas particuliers, exceptions, variantes
Généralisations/spécialisations.
Structuration des cas d'utilisation
UML définit trois types de relations standardisées entre cas

d'utilisation :
Une relation d'inclusion, formalisée par la dépendance
«include»
Une relation d'extension, formalisée par la dépendance
«extend»
Une relation de généralisation/spécialisation
Relation d'inclusion
Lors de la description des cas d'utilisation, il apparaît qu'il existe

des sous-ensembles communs à plusieurs cas d'utilisation, il
convient donc de factoriser ces fonctionnalités en créant de
nouveaux cas d'utilisation qui sont utilisés par les cas
d'utilisation qui les avaient en commun.
A inclut B : le cas A inclut obligatoirement le comportement

définit par le cas B; permet de factoriser des fonctionnalités
partagées.
Le cas d'utilisation pointé par la flèche (dans notre cas B) est
une sous partie de l'autre cas d'utilisation (A, dans notre
exemple).
<<include>>
A
Les cas d'utilisation "Déposer de
l'argent", "Retirer de l'argent",
"Effectuer des virements" et "Consulter
Retirer de l'argent
solde" incorporent de façon explicite le
cas d'utilisation "S'authentifier", à un
endroit spécifié dans leurs
<<include>> enchaînements.
Déposer de l'argent
<<include>>
S'authentifier
<<include>>
Effectuer des virements
<<include>>
Consulter solde
On utilise cette relation pour éviter de décrire plusieurs fois un

même enchaînement d'actions. Ainsi, on est amené à
factoriser un comportement commun à plusieurs cas
d'utilisation dans un cas d'utilisation à part.
Résumé
Une instance du cas source inclut obligatoirement le
comportement décrit par le cas d’utilisation destination
Permet de décomposer des comportements et de définir les
comportements partagées entre plusieurs cas d’utilisation
▬► Factoriser
Relation d'extension
La relation stéréotypée «extend» permet d'étendre les

interactions et donc les fonctions décrites dans les cas
d'utilisation, mais sous certaines contraintes.
Le CU source (B) ajoute, sous certaines conditions, son

comportement au CU destination (A)
En d’autres termes, le CU B peut être appelé au cours de
l’exécution du CU A
A
B Point d'insertion
<<extend>>
Le comportement ajouté s’insère au niveau d’un point

d’extension définit dans le CU destination
Le cas d'utilisation de destination peut fonctionner tout seul,

mais il peut également être complété par un autre cas
d'utilisation, sous certaines conditions.
On utilise principalement cette relation pour séparer le
comportement optionnel (les variantes) du comportement
obligatoire.
Exemple :
Au moment de l'authentification, il se peut que le guichet
retient la carte.
S'authentifier
Retenir la carte
<<extend>>
Relations d’inclusion VS d'extension
La relation « extend" montre une possibilité d'exécution

d'interactions qui augmenteront les fonctionnalités du cas
étendu, mais de façon optionnelle, non obligatoire,
La relation "include" suppose une obligation d'exécution des
interactions dans le cas de base.
Relation d'héritage
Il peut également exister une relation d'héritage entre cas

d'utilisation.
Cette relation exprime une relation de
spécialisation/généralisation au sens classique.
Relation d'héritage : Exemple
Dans un système d'agence de voyage, un acteur

"Touriste" peut participer à un cas d'utilisation de
base qui est "Réserver voyage", qui suppose par
exemple, des interactions basiques au comptoir de
l'agence. Une réservation peut être réalisée par
téléphone ou par Internet.
On voit qu'il ne s'agit pas d'une relation "extend", car la

réservation par Internet n'étend pas les interactions ni les
fonctionnalités du cas d'utilisation "Réserver voyage".
Les deux cas d'utilisation "Réservation voyage" et "Réserver
voyage par Internet" sont liés : la réservation par Internet
est un cas particulier de réservation.
De façon générale en objet, une situation de cas particulier
se traduit par une relation de généralisation/spécialisation.
Reserver voyage
Réserver voyage par téléphone Réserver voyage par Internet

Structuration entre cas d’utilisation
Résumé
Les cas peuvent être structurées par des relations :
A inclut B : le cas A inclut obligatoirement le
comportement définit par le cas B; permet de factoriser
des fonctionnalités partagées
A étend B : le cas A est une extension optionnelle du cas B
à un certain point de son exécution.
A généralise B : le cas B est un cas particulier du cas A.
Relations entre cas d’utilisation : Exemple
Un client peut effectuer un retrait bancaire. Le retrait peut être

effectué sur place ou par Internet. Le client doit être identifié
(en fournissant son code d’accès) pour effectuer un retrait,
mais si le montant dépasse 500DH, la vérification du solde de
son compte est réalisée.
Relations entre cas d’utilisation
Intérêts des cas d’utilisation
Les CU obligent les utilisateurs à :

Définir la manière dont ils voudraient interagir avec le système
Préciser quelles informations ils entendent échanger avec le système
Décrire ce qui doit être fait pour obtenir le résultat escompté
Diagramme des cas d'utilisation
Le diagramme des cas d'utilisation regroupe dans un même

schéma les acteurs et les cas d'utilisation en les reliant par
des relations. Le système étant délimité par un cadre
rectangulaire.
La représentation de base d'un cas d'utilisation est une
ellipse contenant le nom du cas. L'interaction entre un acteur
et un cas d'utilisation se représente comme une association.
Diagramme des cas d'utilisation
Déposer de l 'argent Reteni r l a carte
Cl i ent
<<i nclude>> <<extend>>

Reti rer de l 'argent
<<i nclude>>
Consulter l e sol de <<i ncl ude>>

S'authentifi er
<<i nclude>>
Effectuer des vi rements entre comptes
Agent Fourni r un l ogin et un m ot

de passe
Ravi tai ll er
T echni cien
Réparer
É tapes de construction du diagramme des cas
d'utilisation
Pour modéliser le diagramme des cas d'utilisation, il faut :
Identifier les acteurs qui entourent le système. Certains acteurs utilisent le
système pour accomplir des tâches, d'autres effectuent des tâches de
maintenance ou d'administration.
Organiser les acteurs selon une hiérarchisation de généralisation/spécialisation
Structurer les cas d'utilisation pour faire apparaître les comportement partagés
(relation d'inclusion), les cas particuliers (généralisation/spécialisation) ou
options (relation d'extension)
Etude de cas(1)
Le DAB (Distributeur Automatique de Billet)

Un DAB permet à tout détenteur de carte bancaire de retirer de l’argent.
Si le détenteur de carte est un client de la banque propriétaire du DAB, il peut en plus consulter les
soldes de ses comptes et effectuer des virements entres ces différents comptes.
Les transactions sont sécurisées c’est-à-dire :

Le DAB consulte le Système d’Information de la banque (S.I. Banque) pour les opérations que désire
effectuer un client de la banque (retraits, consultation soldes et virements).
Le DAB consulte le Système d’Autorisation Globale Carte Bancaire (Sys. Auto.) pour les retraits des
porteurs de cartes non clients de la banque.
Le DAB nécessite des opérations de maintenance tel que la recharge en billet, la récupération des
cartes avalée, etc.
Après discussion avec l’expert métier, il apparaît que l’une des sous fonctions importantes est
l’authentification (systématique et commune au 3 cas d’utilisations Retirer de l’argent, Consulter ses
soldes et Effectuer un virement).
Le DAB permet à son utilisateur d’imprimer un reçu s’il le désire.
L’expert métier précise que le DAB sera situé dans une zone internationale et devra donc pouvoir
fournir la somme d’argent en Dollars ou en Euros.
Modélisez avec un diagramme de cas d’utilisation le fonctionnement de DAB

Etude de cas(1)
Etude de cas (2)
On souhaite développer une application informatique qui permet la gestion des emprunts
des Cd-rom contenant des jeux vidéo pour les enfants.
Un employé s’occupe d’enregistrer les emprunts des adhérents qui veulent emprunter les
cd-rom. L’employé doit d’abord s’authentifier pour effectuer cette opération. Chaque cd
emprunté doit être rendu à l’employé de la biblio après une durée de 3 jours. L’adhérent
donc peut réserver des cd-rom contenant des jeux, chaque réservation doit mentionner
l’emprunteur, le jeu et la date de réservation. L’adhérent est averti quand le jeu (cd) revient
en rayon.
L’employé peut aussi organiser des événements, pour se faire il doit donner les
informations suivantes : le nombre minimal et maximal des participants, les jeux à tester, la
date de l’événement et l’heure de début de l’événement.
L’adhérent qui souhaite participer à un événement peut s’inscrire à condition qu’il y ait
encore de la place disponible. Pour se faire il doit saisir un mot de passe et login.
Si l’adhérent trouve une place disponible alors il peut payer sa cotisation en ligne par un
système de paiement externe.
Etude de cas (2)
Description des cas d’utilisation
Le diagramme de cas d’utilisation décrit les grandes fonctions d’un

système du point de vue des acteurs.
Mais il n’expose pas de façon détaillée le dialogue entre les acteurs et
les cas d’utilisation.
 nécessité de décrire ce dialogue
Scénario d’un cas d’utilisation
Un scénario représente une succession particulière d’enchaînements,

s’exécutant du début à la fin du cas d’utilisation, un enchaînement étant
l’unité de description de séquences d’actions.
Un cas d’utilisation contient en général un scénario nominal et plusieurs
scénarios alternatifs (qui se terminent de façon normale) ou d’erreur (qui se
terminent en échec).
Description des cas d’utilisation
Deux façons sont couramment utilisées pour décrire les cas

d’utilisation :
Description textuelle
Description à l’aide d’un diagramme de séquence
Description des cas d’utilisation (description
textuelle)
Le diagramme de cas d'utilisation décrit les grandes fonctions

d'un système du point de vue des acteurs, mais n'expose pas
de façon détaillée le dialogue entre les acteurs et les cas
d'utilisation. Il est recommandé de rédiger une description
textuelle, car c'est une forme souple qui convient dans bien
des situations.
textuelle)
Une description textuelle couramment utilisée se compose de trois parties:
1. La première partie permet d'identifier le cas, elle doit contenir les informations
qui suivent.
Nom :
 Utiliser un verbe à l'infinitif suivi d'un complément.
Objectif :
 Une description résumée du cas d'utilisation.
 Acteurs principaux : ceux qui vont réaliser le cas d'utilisation
 Acteurs secondaires : ceux qui ne font que recevoir des informations à l'issue de la
réalisation du cas d'utilisation.
Dates :
 Les dates de création et de mise à jour de la description courante.
Responsable :
 Le nom des responsables.
Version :
 Le numéro de version.
textuelle)
La deuxième contient toujours une séquence nominale qui décrit de
déroulement normal du cas. À la séquence nominale s'ajoutent
fréquemment des séquences alternatives (des embranchements dans la
séquence nominale) et des séquences d'exceptions (qui interviennent
quand une erreur se produit).
Les pré conditions :
 elles décrivent dans quel état doit être le système (l'application) avant
que ce cas d'utilisation puisse être déclenché.
Des scénarios :
 ces scénarios sont décrits sous la forme d'échanges d'événements
entre l'acteur et le système. On distingue le scénario nominal, qui se
déroule quand il n'y a pas d'erreur, des scénario alternatifs qui sont
les variantes du scénario nominal et enfin les scénarios d'exception
qui décrivent les cas d'erreurs.
Des post conditions :
 elles décrivent l'état du système à l'issue des différents scénarios.
textuelle)
La troisième partie de la description d'un cas
d'utilisation est une rubrique optionnelle. Elle
contient généralement des spécifications non
fonctionnelles (spécifications techniques…). Elle
peut éventuellement contenir une description
des besoins en termes d'interface graphique.
Description textuelle des cas d'utilisation(exemple)
Exemple de description textuelle : Le cas d‘utilisation ‘Retirer de l’argent’ du DAB.
Partie 1 : Description.
- Titre : Retirer de l’argent.
- Résumé : Ce cas d’utilisation permet aux possesseurs de carte bancaire de retire de l’argent.
- Acteur principale : Un porteur de carte bancaire.
- Acteurs secondaires : Le Système d’Information de la banque et le Système d’Autorisation
Globale Carte Bancaire.
- Date : 11/01/2020
- Responsable : E. Rachid
- Version : 1.0
- Partie 2 : Description des scénarios.
- Pré-conditions :
- Le DAB contient des billets.
- Les connexions avec le Système d’Autorisation et le Système d’information de la banque sont
opérationnelles.
- Scénario nominale :
1) Le Porteur de carte introduit sa carte dans le DAB.
2) Le DAB vérifie que la carte introduite est bien une carte bancaire.
3) Le DAB demande le code de la carte au Porteur de carte.
4) Le Porteur de carte saisit son code.
5) Le DAB compare ce code avec celui qui est codé sur la carte.
6) Le DAB demande une autorisation au Système Globale d’autorisation.
7) Le Système d’Autorisation globale donne son accord et indique le crédit.
8) Le DAB demande le montant désiré au Porteur de carte.
9) Le Porteur de carte saisit le montant.
10) Le DAB vérifie si le montant demandé est inférieur ou égale au crédit.
11) Le DAB rend la carte et demande au Porteur de carte de la retirer.
12) Le Porteur de carte reprend sa carte.
13) Le DAB demande au Porteur de carte s’il désire un ticket.
14) Le Porteur de carte accepte le ticket.
15) Le DAB délivre le ticket et les billets.
16) Le Porteur de carte prend les billets et le ticket.
- Scénarios alternatifs :
Scénario alternatif SA1: Le code est erroné pour la première ou la deuxième fois.
SA1 commence au point 5 du scénario nominale.
Le DAB indique que le code est erroné.
Le DAB enregistre l’échec.
Le scénario reprend au point 3 du scénario nominal.
Scénario alternatif SA2: Le montant demandé est trop élevé.
Le DAB affiche le montant max et demande au Porteur de carte de ressaisir un montant.
Le scénario reprend au point 9 du scénario nominal.
Scénario alternatif SA3: Le ticket est refusé.
14) L’utilisateur refuse le ticket.
15) Le DAB délivre les billets.
16) L’utilisateur prend les billets.
-Scénarios d’exception:
Scénario d’exception SE1: Carte non valide.
SE1 commence au point 2 du scénario nominal.
Le DAB Indique que la carte n’est pas valide restitue la carte et met fin au cas.
Scénario d’exception SE2: Le code est erroné pour la troisième fois.
Le DAB Indique que le code est erroné pour la troisième fois, confisque la carte et met fin
au cas.
Scénario d’exception SE3: Retrait non autorisé.
Le DAB Indique que tout retrait est impossible, restitue la carte et met fin au cas.
Scénario d’exception SE4: Carte non reprise.
Au bout de 30s, le DAB confisque la carte et met fin au cas.
Scénario d’exception SE5: Billets non pris.
Au bout de 30s, le DAB reprend les billets et met fin au cas.
Scénario d’exception SE6: Annulation de la transaction.
SE6 peut démarrer entre les points 4 et 9 du scénario nominal.
Le DAB éjecte la carte et met fin au cas.
- Post-conditions: Les détails de la transaction doivent être enregistrés (montant, numéro
carte, date…) aussi bien en cas de succès que d’échec.
- Partie 3 : Exigences non fonctionnelles: La saisie du code confidentiel ne doit pas faire
apparaître le code à l’écran. Le compte du client ne doit pas être débité tant que le billets
n’ont pas été distribués.
Description textuelle des cas d'utilisation(exercice)
fonctionnement d’un distributeur automatique de cassettes vidéo
Une personne souhaitant utiliser le distributeur doit avoir une carte magnétique spéciale.
Les cartes sont disponibles au magasin qui gère le distributeur. Elles sont créditées d’un
certain montant en euros et rechargeables au magasin. Le prix de la location est fixé par
tranches de 6 heures (1 euro par tranche).
Le fonctionnement du distributeur est le suivant :
le client introduit sa carte ; si le crédit est supérieur ou égal à 1 euro, le client est autorisé à
louer une cassette (il est invité à aller recharger sa carte au magasin sinon) ; le client choisit
une cassette et part avec ; quand il la ramène, il l’introduit dans le distributeur puis insère sa
carte ; celle-ci est alors débitée ; si le montant du débit excède le crédit de la carte, le client
est invité à régulariser sa situation au magasin et le système mémorise le fait qu’il est
débiteur ; la gestion des comptes débiteurs est prise en charge par le personnel du magasin.
On ne s’intéresse ici qu’à la location des cassettes, et non à la gestion du distributeur par le
personnel du magasin (ce qui exclut la gestion du stock des cassettes).
Décrivez sous forme textuelle le cas d’utilisation « Emprunter une vidéo »

Identification
Nom du cas : « Emprunter une vidéo ».
But : décrire les étapes permettant au client du magasin d’emprunter une cassette vidéo via le distributeur
automatique.
Acteur principal : Client.
Acteur secondaire : néant.
Date de création : le 23/10/2021.
Date de mise à jour :
Responsable : X. Y.
Version : 1
Séquencement
Le cas d’utilisation commence lorsqu’un client introduit sa carte.
Pré-conditions
Le client possède une carte qu’il a achetée au magasin
Le distributeur est alimenté en cassettes.
Enchaînement nominal
1. Le système vérifie la validité de la carte.
2. Le système vérifie que le crédit de la carte est supérieur ou égal à 1 euro.
3. Appel du cas « Rechercher une vidéo ».
4. Le client a choisi une vidéo.
5. Le système indique, d’après la valeur de la carte, pendant combien de temps (tranches de 6 heures) le client
peut garder la cassette.
6. Le système délivre la cassette.
7. Le client prend la cassette.
8. Le système rend la carte au client.
9. Le client prend sa carte.
Enchaînements alternatifs
A1 : Le crédit de la carte est inférieur à 1 euro.
L’enchaînement démarre après le point 2 de la séquence nominale :
3. Le système indique que le crédit de la carte ne permet pas au client d’emprunter une vidéo.
4. Le système invite le client à aller recharger sa carte au magasin.
La séquence nominale reprend au point 8.
Enchaînements d’exception
E1 : La carte introduite n’est pas valide.
2. Le système indique que la carte n’est pas reconnue.
3. Le distributeur éjecte la carte.
E2 : La cassette n’est pas prise par le client.
7. Au bout de 15 secondes le distributeur avale la cassette.
8. Le système annule la transaction (toutes les opérations mémorisées par le système sont défaites).
9. Le distributeur éjecte la carte.
E3 : La carte n’est pas reprise par le client.
9. Au bout de 15 secondes le distributeur avale la carte.
10. Le système consigne cette erreur (date et heure de la transaction, identifiant du client, identifiant
du film).
Post-conditions: Le système a enregistré les informations suivantes : • La date et l’heure de la
transaction• L’identifiant du client. • L’identifiant du film emprunté.
Rubriques optionnelles
Contraintes non fonctionnelles

Le distributeur doit fonctionner 24 heures sur 24 et 7 jours sur 7.
Contrainte liée à l’interface homme-machine
Avant de délivrer la cassette, demander confirmation au client.
UML
DIAGRAMME DE CLASSES
Objectifs de diagramme de classes
Le diagramme de classes est considéré comme le plus important de la

modélisation orientée objet, il est le seul obligatoire lors d’une telle
modélisation.
Le diagramme de cas d’utilisation montre un système du point de vue

des acteurs, le diagramme de classes en montre la structure interne. Il
permet de fournir une représentation abstraite des objets du système qui
vont interagir ensemble pour réaliser les cas d’utilisation.
Le diagramme de classes est la représentation de la structure statique

des classes du modèle et de leurs relations.
CLASSE ET OBJET
Une classe représente la description abstraite d’un ensemble d’objets

possédant les mêmes caractéristiques. On peut parler également de type.
Exemples : la classe Voiture, la classe Personne.
Un objet est une entité aux frontières bien définies, possédant une
identité et encapsulant un état et un comportement. Un objet est une
instance (ou occurrence) d’une classe.
Exemple : Ahmed NOURI est un objet instance de la classe Personne.

CLASSE ET OBJET
Contrôle d'accès à un bâtiment (notion de classe candidate)
Suite à la disparition d'objets divers, il a été décidé de restreindre les
accès à certaines salles au moyen de portes à fermeture automatique.
L'ouverture de chacune des portes est commandée par un lecteur de
badges placé à proximité.
Les badges qui permettent l'ouverture des portes ne sont délivrés
qu'aux personnes qui doivent accéder aux locaux protégés.
Le système de contrôle d'accès doit fonctionner de la manière la plus
autonome possible. Un superviseur est responsable de la configuration
initiale et de la mise à jour des différentes informations de définition des
groupes de personnes et de portes. Un gardien dispose d'un écran de
contrôle et est informé des tentatives de passage infructueuses. Les
alarmes sont transmises en temps légèrement différé sur l'écran de
contrôle (mise à jour toutes les minutes).
Déterminer les classes candidates.

CLASSE ET OBJET
classe candidate
Suite à la disparition d'objets divers, il a été décidé de restreindre les
accès à certaines salles au moyen de portes à fermeture automatique.
L'ouverture de chacune des portes est commandée par un lecteur de
badges placé à proximité.
Les badges qui permettent l'ouverture des portes ne sont délivrés
qu'aux personnes qui doivent accéder aux locaux protégés.
Le système de contrôle d'accès doit fonctionner de la manière la plus
autonome possible. Un superviseur est responsable de la configuration
initiale et de la mise à jour des différentes informations de définition des
groupes de personnes et de portes. Un gardien dispose d'un écran de
contrôle et est informé des tentatives de passage infructueuses. Les
alarmes sont transmises en temps légèrement différé sur l'écran de
contrôle (mise à jour toutes les minutes).
CLASSE ET OBJET
classe candidate
Il faut corriger la liste :
• Les salles ne font pas partie du système, seules les portes sont
contrôlées.
• De même pour les locaux.
• Les informations de définition de groupes de personnes et de portes
deviennent les classes Groupe de Personnes et Groupe de portes.
• L’écran ne permet que l’affichage et ne fait pas partie du système.
• Les tentatives infructueuses ne sont utiles que si on veut sauvegarder
les informations sur les accès non autorisés.
ATTRIBUT ET OPÉ RATION
Un attribut représente un type d’information contenu dans une classe.

Exemples :
vitesse courante, cylindrée, numéro d’immatriculation, etc: sont des attributs
de la classe Voiture.
Une opération représente un élément de comportement (un service) contenu

dans une classe.
Représentation graphique des classes avec UML
Une classe est représentée par un rectangle divisé en trois compartiments.
Le premier compartiment contient le nom de la

classe qui :
- Représente le type d’objet instancié.
- Débute par une lettre majuscule.
- Il est centré dans le compartiment supérieur de
la classe.
- il est écrit en caractère gras.
- il est en italique si la classe est abstraite
(IMPOSSIBLE d’instancié un objet).
Le deuxième compartiment contient les attributs. Le
troisième compartiment contient les méthodes.
Si la modélisation ne s’intéresse qu’aux relations entre les différentes classe du système

(et pas au contenu des classes), nous pouvons ne pas représenter les attributs et les
méthodes de chaque classe (nous ne mettons rien dans le deuxième et troisième
compartiment).
Encapsulation, visibilité
L'encapsulation est un mécanisme consistant à rassembler les données et les méthodes au
sein d'une structure en cachant l'implémentation de l'objet, c'est-à-dire en empêchant l'accès
aux données par un autre moyen que les services proposés.
Symbole à placer devant

Type de visibilité
l’attribut ou la méthode
public : élément non encapsulé visible par tous. +
private : élément encapsulé visible seulement dans la classe. -
protected : élément encapsulé visible dans la classe et dans les
sous-classes. #
package : élément encapsulé visible dans les classes du même
paquetage. ~
Les attributs calculés (dérivé)
Une classe peut avoir des attributs calculés, c'est-à-dire que leurs
valeurs sont proposées au travers d’une fonction utilisant les autres
attributs précédemment exprimés. Un tel attribut possède un nom
précédé du signe « / » et suivi d’une contrainte permettant de le
calculer.
Syntaxe des attributs
L’attribut doit être inscrit en minuscule mais s’il s’agit d’un nom composé la première lettre de
chaque mot peut être mise en majuscule, à l’exception de la première lettre du premier mot :
nomDeLAttribut. La Syntaxe pour un attribut est :
Visibilité nomAttribut : modificateurs type multiplicité = valeur_initiale
Visibilité : + (public) / # (protégé) / - (privé) / ~(package);

Modificateurs : const (constant) / static ou nom de l’attribut souligné (statique).
Type : boolean / short / int / char / float / double (types primitifs) / autre classe ( type complexe).
Multiplicité : [ ] (tableau) / * (pointeur) / & ( référence);
Exemples :
- i : int pour un attribut privé
+ pp : PointPlan pour un attribut public
tabI : int[*] pour un tableau d’entiers de taille quelconque et à la visibilité non définie
tabPP : PointPlans[4] pour un tableau de 4 points exactement et à la visibilité non définie
x : float = 0.0 pour un nombre à virgule initialisé à 0 et à la visibilité non définie
Syntaxe des méthodes
Les règles d’écriture du nom, la spécification de la visibilité et du type de retour s’effectue de la
même manière que pour un attribut.
Syntaxe Pour une méthode, la syntaxe est :
Visibilité nomMéthode (paramètres) : modificateurs type multiplicité
Visibilité : + (public) / # (protégé) / - (privé);
Paramètres : type primitifs ou complexe de chaque paramètre, séparés par une virgule,
éventuellement avec leur nom
Modificateurs : const (constant) / static ou nom de la méthode soulignée (statique) / virtual

( virtuelle) / abstract ou nom de la méthode en italique ( abstraite / virtuelle pure);
Type : void / boolean / short / int / char / float / double (types primitifs) / autre classe ( type
complexe).
Multiplicité : [ ] (tableau) / * (pointeur) / & ( référence);

Associations entre classes
Une association désigne le cas où une instance d’une classe utilise un

objet d’une autre classe en tant qu’attribut objet.
Une association représente une relation sémantique durable entre

deux classes.
Exemple : une personne peut posséder des voitures. La relation

possède est une association entre les classes Personne et Voiture.
Attention : même si le verbe qui nomme une association semble

privilégier un sens de lecture, une association entre concepts dans un
modèle du domaine est par défaut bidirectionnelle. Donc
implicitement, l’exemple précédent inclut également le fait qu’une
voiture est possédée par une personne.
Associations entre classes
Comment les représenter ?

Aux deux extrémités d’une association, on doit faire figurer une indication de multiplicité. Elle
spécifie sous la forme d’un intervalle d’entiers positifs ou nuls le nombre d’objets qui peuvent
participer à une relation avec un objet de l’autre classe dans le cadre d’une association.
Exemple : une personne peut posséder plusieurs voitures (entre zéro et un nombre
quelconque) ; une voiture est possédée par une seule personne.
Multiplicité (cardinalité)
La multiplicité précise le nombre possible d’instances reliées à l’autre instance dans
la relation.
Illustration
• Lecture de la multiplicité coté Client : « Un Compte est la propriété d’un seul Client
(rôle ‘propriétaire’ dans la relation) ». On part toujours de la classe opposée,
considérée au singulier (« Un Compte »), pour trouver le nb possible d’objets reliés à
cette unique instance.
• Lecture de la multiplicité coté Compte : « Un Client est propriétaire d’un ou plusieurs
Compte(s) ».
Multiplicités
1 : la classe est en relation avec un et un seul objet de l’autre classe

1..* : la classe est en relation avec au moins un objet de l’autre classe
0..* : la classe est en relation avec 0 ou n objets de l’autre classe
0..1 : la classe est en relation avec au plus un objet de l’autre classe
Une voiture est achetée par une Une personne peut acheter
et une seule personne 0 ou n voitures
Navigabilité
La navigabilité indique qu'un objet de la classe cible peut être atteint

par un objet de la classe source au travers de l'association. En d’autres
termes, elle montre s’il est possible de traverser une association.
la terminaison du côté de la classe Commande n’est pas navigable :

cela signifie que les instances de la classe Produit ne stockent pas de
liste d’objets du type Commande. Inversement, la terminaison du côté
de la classe Produit est navigable : chaque objet commande contient
une liste de produits.
Navigabilité
Il est beaucoup plus fréquent d’avoir besoin d’une navigabilité unidirectionnelle. Dans ce cas,
une seule classe possède un attribut qui fait référence à l’autre classe, ce qui se traduit par le
fait que la première classe peut solliciter une deuxième et que l’inverse est impossible (la
deuxième classe ne connaît pas la première).
Une relation unidirectionnelle peut se représenter de 3 façons différentes :

• Une croix du coté de l’objet qui ne peut pas être sollicité.
• Une flèche du coté de l’objet qui peut être sollicité.
• Les 2 représentations précédentes à la fois.
Navigabilité
 Par défaut une association est navigable dans les deux sens
Chaque instance de voiture a un lien vers le propriétaire

Chaque instance de Personne a un ensemble de lien vers les voitures
 Restriction de la navigabilité
Le service de contravention Navigable
est associé à une ou plusieurs
voiture(s)
La voiture ne connaît pas service
de contravention
Relation de dépendance
Une dépendance peut s’interpréter comme une relation de type «utilise un ». Elle est
habituellement utilisée lorsqu'une classe utilise un objet d'une autre classe comme argument
dans la signature d’une méthode ou alors lorsque l'objet de l'autre classe est créé à l'intérieur
de la méthode. Dans les deux cas la durée de vie de l'objet est très courte, elle correspond à la
durée d'exécution de la méthode.
Notation : Elle est représentée par un trait discontinu orienté, reliant les deux classes. La
dépendance est souvent stéréotypée (« use ») pour mieux expliciter le lien sémantique entre
les éléments du modèle.
Relation d’associations
• L’association signifie qu’une classe contiendra une référence (ou un pointeur) de l'objet de
la classe associée sous la forme d’un attribut.
• L’association est représentée par un simple trait continu, reliant les deux classes. Le fait
que deux instances soient ainsi liées permet la navigation d’une instance vers l’autre, et
vice versa (chaque classe possède un attribut qui fait référence à l’autre classe).
Relation d’associations: détailler l’association
Nous pouvons détailler l’association en indiquant :
• Le nom de l’association : L’association peut être orné d’un texte, avec un éventuel sens de
lecture, qui permet de nous informer de l’intérêt de cette relation. Nous rajoutons une
phrase courte permettant de préciser le contexte de cette association. Le nom d’une
association doit respecter les conventions de nommage des classeurs : commencer par une
lettre majuscule.
Relation d’associations: détailler l’association
Le rôle : Chaque extrémité d’une association peut être nommée. Ce nom est appelé rôle et
indique la manière dont l’objet est vu de l’autre coté de l’association. Lorsqu’un objet A est lié
à un autre objet B par une association, cela se traduit souvent par un attribut supplémentaire
dans A qui portera le nom du rôle B. (et inversement).
Relation d’associations: Association réflexives
Une association qui lie une classe avec elle-même est une association réflexive
Relation d’associations: Contraintes et associations
Exemple1: Contrainte entre 2 associations.

Contrainte entre 2 associations. En informatique, un raccourci peut concerner soit un répertoire
soit un fichier (mais pas les 2 à la fois). Nous pouvons exprimer cela sous la forme d’une contrainte
{xor}
Relation d’associations: Contraintes et associations
Exemple2: Contrainte sur une association.

Un objet de la classe Personne est associé à un objet de la classe Date. La
contrainte {frozen} indique que cette association ne peut plus être
modifiée une fois instanciée.
Association n-aire
Relation n-aire
Une association qui lie plus de 2 classes entre elles, est une association n-aire.
L’association n-aire se représente par un losange d’où part un trait allant à chaque
classe. L’association n-aire est imprécise, difficile à interpréter et souvent source
d’erreur, elle est donc très peu utilisée.
Exemple 1 : Une séance de cinéma peut correspondre à l’association ternaire de 3

classes.
Classe association
Une association peut apporter de nouvelles informations (attributs et méthodes) qui n’appartiennent
à aucune des deux classes qu’elle relie et qui sont spécifiques à l’association. Ces nouvelles
informations peuvent être représentées par une nouvelle classe attachée à l’association via un trait en
pointillés.
Exemple : Lorsqu’une personne utilise un téléphone, il faut pouvoir mesurer la durée de

l’appel et savoir à quel moment il a lieu afin de le tarifier. Nous ajoutons donc deux attributs
durée et période tarifaire qui n’appartiennent ni à la classe Personne ni à la classe Téléphone.
Ces deux attributs sont mis dans une nouvelle classe (la classe Appel) qui est attachée à
l’association.
Classe association
Remarque : Comme pour l’association ternaire, nous pouvons convertir la classe association en un
ensemble d’associations binaires.
Classe-association
Exemple 2
L'association Emploie entre une société et une personne possède comme propriétés le
salaire et la date d'embauche. En effet, ces deux propriétés n'appartiennent ni à la société,
qui peut employer plusieurs personnes, ni aux personnes, qui peuvent avoir plusieurs
emplois.
Il s'agit donc bien de propriétés de l'association Emploie. Les associations ne pouvant

posséder de propriété, il faut introduire un nouveau concept pour modéliser cette
situation : celui de classe-association.
Exercice
Pour chacun des énoncés suivants, donnez un diagramme des classes:
 Tout écrivain a écrit au moins une œuvre

 Les personnes peuvent être associées à des
universités en tant qu'étudiants aussi bien qu'en tant
que professeurs.
 Un rectangle a deux sommets qui sont des points. On
construit un rectangle à partir des coordonnées de
deux points. Il est possible de calculer sa surface et
son périmètre, ou encore de le translater.
Types de relation : Corrigé
Associations particulières : Contenance
Cas particulier d’association exprimant une relation de contenance
Exemples:
• Une voiture a 4 roues
• Un dessin contient un ensemble de figures géométriques
• Une présentation PowerPoint est composé de transparents
• Une équipe de recherche est composée d’un ensemble de personnes
Deux types de relations de contenance en UML

• Agrégation
• Composition (Agrégation forte)
Contenance: Agrégation
A B
Type de relations
A « contient » des instances de B,
Agrégat
Propriétés de l’agrégation
La suppression de A n’implique pas la suppression de B
L'élément agrégé peut être partagé
Exemples :
L’enseignant est un composant
d’une (ou plusieurs) équipe de
recherche d’un seul département
La disparition d’une équipe de

recherche n’entraine pas la
disparition d’un enseignant
Contenance: Composition
La suppression de A entraine la suppression de B
Exemple:
« Une présentation PowerPoint est composé de transparents »
La suppression de la présentation entraine la disparition des transparents

qui la compose
Associations : Héritage
permet de créer une nouvelle classe à partir d'une classe existante
Principe
classe dérivée contient les attributs et les méthodes de sa superclasse
Spécialisation Généralisation
étendre les propriétés factoriser les propriétés
d'une classe, sous groupe de classes sous
forme de sous-classes forme de super-classe
Chaque personne de l’université est identifiée par son nom, prénom

Les étudiants ont plus un noEtudiant
Les enseignants ont un numéro de téléphone interne
Diagramme de classes
Implémentation : Associations
public class Personne {
public String Nom;

public String prenom;
public java.util.Collection voiture =
new java.util.TreeSet();
}
public class Voiture {
public String immatriculation;

public Personne Propriétaire;
public void demarer() { }
}
public class ServiceContraventions {
public java.util.Collection Voiture = new java.util.TreeSet();

}
Implémentation : Composition &Agrégation
Composition
final class Car { Dans le cas de la composition, le Moteur est

private final Engine engine; complètement encapsulé par la Voiture. Il n'y
a aucun moyen pour le monde extérieur
Car(EngineSpecs specs) { d'obtenir une référence au moteur. Le
engine = new Engine(specs);
} Moteur vit et meurt avec la voiture.
void move() {
engine.work();
}
}
Agrégation
final class Car {
Avec l'agrégation, la voiture remplit également
private Engine engine; ses fonctions à travers un moteur, mais le moteur
n'est pas toujours une partie interne de la
void setEngine(Engine engine) {
this.engine = engine; voiture. Les moteurs peuvent être échangés, ou
} même complètement enlevé. Pas seulement ça,
void move() {
mais le monde extérieur peut encore avoir une
if (engine != null) référence au moteur, et bricoler avec lui, qu'il soit
engine.work(); dans la voiture ou pas.
}
}
Exercices
Exercice 1:
Soit un système d'information qui concerne le suivi des

personnels d'un ensemble d'agences locales. Chaque agence
se trouve dans une région, chaque région est pilotée par une
direction régionale. La direction régionale se charge d'un
ensemble d'agences locales.
une direction régionale est caractérisée par un code et un
libellé.
Modélisez cette situation par un diagramme de classe.
Exercices
Exercices
Exercice 2:
Soit un document composé d'un ou plusieurs feuillets.

Le feuillet comporte des objets géo et des texte. Les
objets graphique supportent des opérations de type :
sélectionner, copier, couper, coller et déplacer. On
suppose les deux objets géométriques suivants: cercle
et rectangle.
Modélisez cette situation par un diagramme de classe

(utiliser la notion d'héritage, composition et
agrégation).
Exercices
Exercices
Exercice 3:
Dans une société de transport, on voudrait gérer les bus de ramassage scolaire et les
conducteurs. Un lycéen est un enfant, il est caractérisé par son nom, son âge et son
sexe. Les informations qui caractérisent le conducteur sont les mêmes que pour le
lycéen, avec en plus le numéro de son permis. Quant au bus, on a besoin de
connaître son numéro d’immatriculation, sa date de mise en service, nombre
d’années de service, et le poids total.
Un bus est composé d’une carrosserie (poids, couleur), de 6 roues (pression,
diamètre), de plusieurs sièges (couleur) pour passagers, plusieurs vitres (épaisseur,
poids).
Présentez le diagramme de classes adéquat.

Exercices
Exercices
Exercice 4:
Un hôtel est composé d'au moins deux chambres. Chaque chambre dispose d'une
salle d'eau : douche ou bien baignoire. Un hôtel héberge des personnes. Il peut
employer du personnel et il est impérativement dirigé par un directeur. On ne
connaît que le nom et le prénom des employés, des directeurs et des occupants.
Certaines personnes sont des enfants et d'autres des adultes (faire travailler des
enfants est interdit). Un hôtel a les caractéristiques suivantes : une adresse, un
nombre de pièces et une catégorie. Une chambre est caractérisée par le nombre et
de lits qu'elle contient, son prix et son numéro. On veut pouvoir savoir qui occupe
quelle chambre à quelle date. Pour chaque jour de l'année, on veut pouvoir calculer
le loyer de chaque chambre en fonction de son prix et de son occupation (le loyer est
nul si la chambre est inoccupée). La somme de ces loyers permet de calculer le
chiffre d'affaires de l'hôtel entre deux dates.
Question : Donnez un diagramme de classes pour modéliser le problème de

l'hôtel.
Exercices
UML
DIAGRAMME D’OBJET
Définition
 Représentation d’un ensemble d’objets et de liens, exprimant la

structure statique.
 Un diagramme d’objets est une instance d’un diagramme de classes et
illustre l’état d’un système a un moment donné.
 Les diagrammes d’objets s’utilisent principalement :
pour faciliter la compréhension des structures de données complexes.
Définition(suite)
Un diagramme d’objets est composé :

 d’objets (instances de classes)
 de liens (instances d’associations).
La notation des diagrammes d’objets est dérivée de celle des diagrammes
de classes.
Résumé diagramme d’objet
Un diagramme de structure d’UML (statique).

Permettant de visualiser les relations entre les objets.
Détaillant un peu plus le diagramme de classes.
Donnant une vue figée de l’état de notre application à un instant donné.
Diagramme d’objets vs Diagramme de classes
Un diagramme de classes décrit les règles de notre application.

Un diagramme d’objet modélise les faits.
Comment modéliser des instances de classe en UML ?
Les diagrammes d‘objet décrivent un ensemble particulier d'objets, dans un cas

donné
Ces diagrammes servent à expliquer des cas particuliers, et à raisonner sur la base
d'exemples
Une instance peut être nommée ou anonyme
La classe de l’instance peut être indiquée ou non
Une instance peut être préciser la valeur d’un attribut
Une instance peut être préciser la composition d’un objet composé

Si la visualisation des attributs et leurs valeurs n’est pas importante,

on peut simplifier la représentation
Ou encore plus simple

Pour modéliser une collection d’objets

Remarques:
Le lien entre les objets est dynamique: il existe si un lien entre les
classes existe déjà
Pas de multiplicité
Exemple :
Soit le diagramme de classe suivant :
Avec le diagramme objet ci-dessous on définit une instance

particulière du diagramme de classe (qui est le combat entre
Mohamed Ali et George Foreman qui a eu lieu le 24 septembre
1974 à Kinshasa).
Exemple 2 :
Considérant le diagramme de classes suivant:
Voici un deuxième exemple de diagramme d’objets, plus détaillé,

pour le diagramme de classes précédent.
Exemple 3:
Considérant le diagramme de classes suivant:
Exemple 3:
Voici un exemple de diagramme d’objets pour le diagramme de
classes précédent :
oxygène, hydrogène1 et hydrogène2 : objets composants

eau : objet composite
UML
DIAGRAMME de séquences
Objectifs de diagramme de séquences
 Les diagrammes de cas d’utilisation modélisent à QUOI sert le système, en

organisant les interactions possibles avec les acteurs.
 Les diagrammes de classes permettent de spécifier la structure et les liens entre les
objets dont le système est composé : ils spécifie QUI sera à l‘œuvre dans le
système pour réaliser les fonctionnalités décrites par les diagrammes de cas
d’utilisation.
 Les diagrammes de séquences permettent de décrire COMMENT les éléments
du système interagissent entre eux et avec les acteurs.
 Les objets au cœur d’un système interagissent en s’échangent des messages.
 Les acteurs interagissent avec le système au moyen d’IHM (Interfaces Homme-
Machine).
Diagramme de séquences
 Représenter les interactions entre objets en précisant la chronologie des

échanges de messages.
 Représente une instance d’un cas d’utilisation (les scénarios possible
d’un cas d’utilisation donné).
 Montre sous forme de scénarios, la chronologie des envoies de
messages issus d’un cas d’utilisation.
Exemple d’interaction
Cas d’utilisation :
Diagramme de séquences correspondant :
Opérations nécessaires dans le diagramme de classes :

Diagrammes de séquences : Description
Représentation graphique
Un objet est représenté par un rectangle et une ligne verticale (ligne de vie de l’objet).
Les objets communiquent en échangeant des messages représentés par des flèches orientées
de l’émetteur au récepteur.
Chaque message échangé entre des objets est symbolisé par une flèche pleine et
continue.
La chronologie des envois de messages est organisée du haut vers le bas (et de gauche à
droite).
Ligne de vie des objets
Elle est représentée par une ligne verticale en dessous des objets.Elle
représente la période de temps durant laquelle l’objet “existe”.
Création d’un objet : un message pointe sur le symbole de
l’objet. Destruction d’un objet : sa ligne de vie se termine
par une croix(×).
La spécification UML 2.0 précise que les lignes de vies peuvent être en
continues ou pointillées.
Type de messages
 Un message définit une communication particulière entre des lignes de vie
(objets ou acteurs).
 Plusieurs types de messages existent, dont les plus courants :

 L’envoi d’un signal ;
 L’invocation d’une opération (appel de méthode) ;
 La création ou la destruction d’un objet.
 La réception des messages provoque une période d’activité (rectangle

vertical sur la ligne de vie) marquant le traitement du message
(spécification d’exécution dans le cas d’un appel de méthode).
Messages asynchrones
Ils n’attendent pas de réponse et ne bloquent pas l’émetteur qui ne sait

pas si le message arrivera à destination, quand il arrivera et s’il serra
traité par le destinataire. (Typiquement :envoi de signal).
Graphiquement, un message asynchrone se représente par une
flèche en traits pleins et à l’extrémité ouverte partant de la ligne de vie
d’un objet expéditeur et allant vers celle de l’objet cible.
Messages synchrones
 Dans la pratique, la plupart des invocations sont synchrones, l’émetteur
(l’expéditeur) reste alors bloqué jusqu’à la réponse du destinataire. Le flot de
contrôle passe de l’émetteur au récepteur.
 Graphiquement, un message synchrone se représente par une flèche en traits
pleins et à l’extrémité pleine. Ce message peut être suivi d’une réponse qui se
représente par une flèche en pointillé.
Messages synchrones: Exemple
Exempledediagrammedeséquences
Messages:activationdesobjets
La dimension verticale représente l’écoulement du temps.

Une période d’activité correspond au temps pendant lequel un objet
effectue une action directe ou indirecte.
Représentation
Réprésenter par une bande verticale le long de la ligne de vie de l’objet.
Événementsetmessages
Un message complet est tel que les événements d’envoi et de

réception sont connus.
Un message complet est représenté par une flèche partant d’une ligne de vie
et arrivant à une autre ligne de vie.
Un message perdu est tel que l’événement d’envoi est connu, mais pas
l’événement de réception.
La flèche part d’une ligne de vie mais arrive sur un cercle indépendant
marquant la méconnaissance du destinataire.
Exemple : broadcast.
Un message trouvé est tel que l’événement de réception est connu,
mais pas l’événement d’émission.
Un message trouvé est un message pour lequel soit l’émetteur est
inconnu, soit le message provient d’une source aléatoire.
Événementsetmessages: exemple
Dans la figure ci-dessous :

Le message ‘messageUn()’ est le message de départ et se nomme
message trouvé (found message).
Les messages ‘messageDeux()’ et ‘messageTrois()’ sont des messages
complets.
Correspondance messages / opérations
Les messages synchrones correspondent à des opérations dans le

diagramme de classes.
Envoyer un message et attendre la réponse pour poursuivre son activité

revient à invoquer une méthode et attendre le retour pour poursuivre ses
traitements.
Correspondance messages / signaux
Les messages asynchrones correspondent à des signaux dans le

diagramme de classes.
Les signaux sont des objets dont la classe est stéréotypée signal et dont les
attributs (porteurs d’information) correspondent aux paramètres du
message.
Messages de retour
Le récepteur d’un message synchrone rend la main à l’émetteur du

message en lui envoyant un message de retour.
Les messages de retour sont optionnels : la fin de la période d’activité
marque également la fin de l’exécution d’une méthode.
Ils sont utilisés pour spécifier le résultat de la méthode invoquée.
Message récursif
Appelé aussi message réflexive.

Message envoyé d’un objet vers lui-même.
On peut montrer qu’un objet s’envoie un message à lui-même à l’aide d’une
flèche « circulaire ».
Message récursif : exemple
Lorsque le client introduit sa carte de guichet, ce dernier vérifie la

validité de la carte avant de demander le code d’accès.
Syntaxe des Messages
Syntaxe générale d’un message : [’[’condition’]’[*[||]’[’itération’]’]:]

[résultat:=] message([paramètres]) La syntaxe de message de routeur est
la suivante :
[<attribut>=] message[:<valeur_de_retour>]
condition est une condition optionnelle sous forme d’expression
booléenne.
itération spécifie (en langage naturel, entre crochets) l’envoi séquentiel (ou
en parallèle, avec ||). On peut omettre cette spécification et ne garder que le
caractère " * " (ou "*||") pour désigner un message récurrent envoyé un
certain nombre de fois.
résultat est la valeur de retour du message, qui sera par exemple
transmise en paramètre à un autre message.
message est le nom du message. paramètres désigne les paramètres
(optionnels) du message.
Etiquettes des messages : itération
Itération séquentielle : envoi séquentiel de n instances du même

message.
Syntaxe : *[ clause d’itération ]
Itération parallèle : envoi parallèle de n instances du même
message.
Syntaxe : *||[ clause d’itération ]
Etiquettes des messages : résultat
Le résultat est constitué d’une liste de valeurs retournées par le message

.
Ces valeurs peuvent être utilisées comme paramètres des autres
messages.
Fragment combiné
 Un fragment combiné permet de décomposer une interaction complexe en

fragments suffisamment simples pour être compris.
 Un fragment combiné se représente de la même façon qu’une interaction. Il est

représenté un rectangle dont le coin supérieur gauche contient un pentagone. Dans le
pentagone figure le type de la combinaison (appelé opérateur d’interaction).
Opérateur alt (alternative)
C’est en quelque sorte l’équivalent du SI...ALORS...SINON. L’utilisation de l’opérateur else permet d’indiquer que la branche est exécutée si la condition du alt est fausse.
Opérateur Loop
Cet opérateur est utilisé pour décrire un ensemble d’interaction qui
s’exécute en boucle.
En général, une contrainte appelée garde indique le nombre de répétitions
(minimum et maximum) ou bien une condition booléenne à respecter.
Syntaxe : loop (minNbIterations , maxNbIterations)
La boucle est répétée au moins minNbItérations fois avant qu’une éventuelle
condition booléenne ne soit testée (la condition est placée entre crochets
dans le fragment).
Tant que la condition est vraie, la boucle continue, au plus
maxNbItérations fois.
Notations
loop(valeur) est équivalent à loop(valeur, valeur). loop
est équivalent à loop(0,*), où * signifie illimité.
Opérateur loop : exemple
Le CAPTCHA est une marque commerciale permettant de différencier de

manière automatisée un utilisateur humain d’un ordinateur.
Fragments de séquence « ref »
ref : sous-séquence détaillée dans un autre diagramme de séquence.

Opérateur Par (parallel)
Il est utilisé pour représenter des interactions ayant lieu en parallèle. Les
interactions des différents opérandes (les deux branches de notre opérateur ci-
dessous) peuvent donc se mélanger, s’intercaler, dans la mesure où l’ordre
imposé dans chaque opérande est respecté.
Section critique : Critical
Ce fragment doit être terminé pour qu’une autre unité d’exécution puisse
s’exécuter.
On dit que l’opérateur impose un traitement atomique des interactions qu’il
contient.
Par exemple, si une opération d() est incluse dans la région crique et appelée,
aucune autre opération ne peut être appelée jusqu’à ce que d() soit terminée.
Section critique : Critical
Diagrammes de séquence : polymorphisme
Le polymorphisme est un concept fondamental de la conception

orientée objet. Comment le représenter dans un diagramme de séquence ?
Une solution consiste à utiliser plusieurs diagrammes de séquence.
L’un montrant le message polymorphe vers la super-classe abstraite (ou
l’objet interface).
Puis plusieurs diagrammes séparés détaillant chaque cas polymorphe, chacun
commençant par un message polymorphe trouvé (sans source).
Polymorphisme : exemple
Polymorphisme : exemple
Exercices
Quand un courrier électronique est envoyé par

l'émetteur, celui-ci ne veut pas attendre que destinataire
l'ait reçu. Complétez la figure ci dessous par des flèches
représentant des messages.
Exercices
Exercices
Un serveur de messagerie sert d'intermédiaire entre

l'émetteur et le récepteur d'un email. Le serveur est
toujours en fonction. Complétez la figure ci dessous par
des flèches représentant les messages.
Exercices
Un message synchrone est possible ici et c'est donc préférable : si

on a le choix, il vaut mieux utiliser des messages synchrones, qui
s'implémentent facilement par des opérations.
Exemples des diagrammes de séquences
Diagramme de séquence cas authentification

dans une application Stock
Diagramme de séquence ajouter client dans

une base de données d’une application
Exercices
Le déroulement de réservation de vol est le suivant:

 Le Client sélectionne un vol.
 Une validation de nombre de place automatique du système
se déclenche.
 Si le nombre de places réservés est inferieur au nombre de
places disponibles dans un vol, la création de la réservation se
lance, sinon une erreur s'affichera au client
Exercices
Exercices
Le déroulement de création de vol est le suivant:

 Le gestionnaire affecte un avion à un vol: il doit sélectionner
un avion disponible et l'affecter au vol
 En suite il doit sélectionner un aéroport de départ et un autre
d'arrivée
 Puis il crée un vol après avoir spécifier les autres informations
requis
Elaborez le DS relatifs à « créer un vol »
Exercices
Exercices
Le diagramme de classes présenté ci dessous modélise la structure interne de la bibliothèque.
Un acteur adhérent peut emprunter un exemplaire d'une oeuvre

donnée. L'emprunt se fait de la façon suivante : la méthode emprunter
est appelée avec un objet de classe Adhérent donné en argument ; s'il
reste des exemplaires dans la bibliothèque, l'un des exemplaires
associés à l'oeuvre est extrait via la méthode extraireExemplaire, une
instance de la classe Prêt est créée, puis l'exemplaire extrait de la
bibliothèque est attribué à l'adhérent grâce à l'opération attribuer. S'il
restait un exemplaire, l'oeuvre retourne « OK « et dans le cas contraire,
elle retourne « PasOK «
Exercices
Exercice
On souhaite gérer les différents objets qui concourent à l’activité d’un
magasin de vente de fleurs.
Le client demande au vendeur des renseignements sur les compositions
florales;
Le vendeur lui fournit toutes les informations nécessaires;
Le client commande alors la composition de son choix et le vendeur émet
le bon de fabrication qu’il transmet à son ouvrier fleuriste.
Le vendeur édite ensuite la facture correspondante.
L’ouvrier fleuriste crée la composition puis archive le bon de fabrication; Il
remet alors la composition au vendeur;
La facture est remise au client pour règlement une fois le bouquet
réalisé;
Une fois la facture réglée, le client récupère sa composition et quitte le
magasin.
Modéliser cette situation à l’aide d’un diagramme de séquence.
Exercice
Exercice
Construisez le diagramme de séquence d’une prise de commande
de produits sur le site Internet d’achat des produits
Exercice
UML
d’états-transitions
Diagramme d’états-transitions
Rôle du diagramme états-transitions (State Machine) :
Le diagramme états-transitions (State Machine Diagram) fait parti des diagrammes

comportementaux. Son rôle, est de décrire le fonctionnement d’une machine (ou d’un
objet) ayant un comportement séquentiel.
Il représente les différents états (situations) dans lesquels peut se trouver la machine (ou
l’objet) ainsi que la façon dont cette machine (ou l'objet) passe d’un état à l’autre en
réponse à des événements.
Ex : Le télérupteur
Le télérupteur est un appareil qui permet de commander des points d'éclairage à partir
d’autant d’endroits que nous désirons via des boutons poussoirs (Un appui sur l’un des
boutons poussoirs provoque le changement d’état du contact qui aliment les lampes).
Le télérupteur possède deux états possibles (contact fermé ou contact ouvert). L’appui sur l’un
des boutons poussoirs ne permet pas de déterminer l’état du contact suite à cet événement.
Si le contact était fermé, il s’ouvrira et s’il était ouvert, il se fermera. Un même événement
(l’appui sur un BP) provoque des réactions différentes en fonction de l’état du télérupteur au
moment de l’événement (état antérieur).
Diagramme d’états-transitions
 Un diagramme d’états-transition est toujours associé à une et une seule classe.
 Un objet peut passer par une série d'états pendant sa durée de vie. Un état de l'objet
correspond à un moment de son cycle de vie.
 Pendant que l’objet se trouve dans un état, il peut se contenter d'attendre un signal
provenant d'autres objets. Il est alors inactif. Il peut également être actif et réaliser une
activité. Une activité est l'exécution d'une série de méthodes et d'interactions avec
d'autres objets.
 L'ensemble des états du cycle de vie d'un objet contient un état initial. Celui-ci correspond
à l'état de l'objet juste après sa création (défini par l'un des constructeurs de l'objet). Il
peut également contenir un ou plusieurs états finaux. Ceux-ci correspondent à une phase
de destruction de l'objet. Il arrive également qu'il n'y ait pas d'état final car un objet peut
ne jamais être détruit.
Représentation du diagramme états-transitions
Etat :
Un état est une situation stable qui possède une certaine durée pendant laquelle un objet exécute
une activité ou attend un événement.
- Un état est représenté par un rectangle arrondi contenant son nom.
- L’état initial est représenté par un point noir (état dans lequel il se trouve lors de sa création).
- Un état final correspond à une étape où l'objet n'est plus nécessaire dans le système et où il est
détruit. Tous les objets n'ont pas d'état final. C'est notamment le cas des objets permanents dans
le système. L’état final se représente par un point entouré d’un cercle.
Evénement:
Un événement est un fait qui déclenche le changement d'état, qui fait donc
passer un objet d’un état à un autre état (désactivation d’un état et
activation de l'état suivant). Il est lié à la réception d'un signal (d'un
message) par l'objet, demandé généralement par un autre objet. Un
événement se produit à un instant précis et est dépourvu de durée. Quand
un événement est reçu, une transition peut être déclenchée et faire basculer
l'objet dans un nouvel état.
Type d’événements:
 Événement de type signal (signal event):

Correspond à la réception d’un signal asynchrone émit par un autre objet ou par un acteur. Le
signal est très souvent associé à une structure complexe comme une IHM. Un événement de type
signal peut être porteur de paramètres et s’écrit comme suit :
nom_événemen
t
ou Différents
nom_événement(paramètre1 ;paramêt niveaux
re2…)
ou de
précision
nom_événement(paramètre1 :type-
paramêtre1 ;paramêtre2 :type_paramêtre2…)
Les signaux sont déclarés dans le diagramme de classes de la même manière qu’une classe mais
en ajoutant le stéréotype <> au dessus du nom. Un signal peut aussi être déclaré de façon
textuelle.
 Événement appel d'opération (call event) : Appel d’une méthode de

l’objet courant par un autre objet ou par un acteur. Il possède la même
syntaxe que l’événement de type signal. La méthode est aussi déclarée
dans le diagramme de classe, mais à l’intérieur de la classe (pas dans un
classeur stéréotypé <>).
 Événement de changement (change event) : Un événement de

changement d'état est généré par la satisfaction (vrai ou faux) d'une
expression booléenne sur des valeurs d'attributs. Il s'agit d'une manière
déclarative d'attendre qu'une condition particulière soit satisfaite.
L’expression est testée en permanence.
La syntaxe est la suivante : when (expression booléenne)

 Événement temporel (time event) :

Les événements temporels sont générés par l’écoulement du temps. Ils sont
spécifiés soit de manière absolue (date précise), soit de manière relative
(temps écoulé). Par défaut, le temps commence à s'écouler dès l'entrée dans
l'état courant.
-de manière absolue (déclenchement à une date précise)
Syntaxe :
when(date= « expression précise d’une date »)
exemple : when(date=17/12/2010)
-de manière relative (déclenchement après une certaine durée passée

dans l’état actuel).
Syntaxe :
after(« expression d’une durée »)
exemple : after(10secondes)
Transitions
 transition externe : Une transition définit la réponse d'un objet à l'arrivée
d'un événement. Elle indique qu'un objet qui se trouve dans un état peut
« transiter » vers un autre état en exécutant éventuellement certaines
activités, si un événement déclencheur se produit et qu'une condition de
garde est vérifiée.
 Syntaxe d'une transition externe : Une transition externe est une
transition qui modifie l'état actif. Il s'agit du type de transition le plus
répandu. Une transition entre deux états est représentée par un trait
droit fléché allant de l'état source vers l'état cible. L'événement qui
détermine le franchissement de la transition est indiqué sous forme de
texte. Si la transition est automatique, aucun événement n'est spécifié.
Transitions(externe suite)
 Une transition n’a pas de durée, elle est franchie instantanément (on
dit qu’elle est déclenchée).
La structure de l'événement correspondant aux détails de la transition
sont précisés au moyen de la syntaxe suivante :
déclencheur [garde] / effet (chacun de ces éléments est facultatif)
 déclencheur : nom de l’événement qui provoque le franchissement de la transition.
 garde : condition de garde [entre crochets]. Il est possible d'associer une condition à
une transition, qui est alors appelée condition de garde. Pour que la transition soit
franchie, il faut que la condition soit remplie en plus de la réception de l'événement
associé, si celui-ci existe.
 effet : spécifie une activité à effectuer lors du déclenchement (nom de l’activité
précédés de /). Une activité est une série d'actions. Une action consiste à affecter une
valeur à un attribut, créer ou détruire un objet, effectuer une opération (lancer une
méthode), envoyer un signal à un autre objet ou à soi-même (Si c’est le cas, le nom
du signal est précédé de ^), etc.
Transitions
 Transition interne : Les états que nous avons vus jusqu’à maintenant étaient
relativement simples, ils n’effectuaient qu’une seule activité. Nous pouvons
avoir des états qui effectuent plusieurs activités successivement ou en
parallèle. L’enchaînement de ces activités à l’intérieur d’un même état peut
être spécifié grâce à des transitions internes. La syntaxe d’une transition
interne est la même que celle d’une transition externe :
déclencheur [garde] / effet
UML définit des mots clé correspondant à des événements particuliers :

-entry : définit l’activité à exécuter lors de l’entrée dans l’état.
-exit : définit l’activité à exécuter lors de la sortie de l’état.
-do : définit l’activité à exécuter dès que celle définie par entry est terminée.
-on : (optionnel) définit l’activité à exécuter à chaque fois que nous avons un
événement particulier.
Les transitions internes s’écrivent à l’intérieur de l’état, séparé du nom de l’état

par un trait.
Transitions
Les transitions internes s’écrivent à l’intérieur de l’état, séparé du nom de l’état par un
trait.
Point de choix
Il est possible de représenter des alternatives pour le franchissement d'une
transition en utilisant des pseudo-états particuliers : les points de jonction et
les points de décision.
a) Point de jonction : Les points de jonction sont représentés par un cercle
plein : Ils permettent à plusieurs transitions d’avoir une partie commune en
partageant des segments de transition. L’utilisation de points de jonction a
pour but de rendre la notation des transitions alternatives plus lisible.
Point de choix
a) Point de jonction(suite)
Point de décision :
b) Les points de décision sont représentés par des losanges :
Un point de décision possède une entrée et au moins deux sorties.

Contrairement à un point de jonction, les gardes situées après le point de
décision sont évaluées au moment où il est atteint. Cela permet de baser
le choix sur des résultats obtenus en franchissant le segment avant le
point de choix.
Remarque importante : Lorsque nous arrivons sur un point de décision, il

faut qu’un des segments de transition qui suit, soit franchissable (une
transition n’ayant pas de durée, nous ne pouvons pas rester à attendre
quelque chose au niveau du point de décision). Pour éviter ce problème
nous pouvons ajouter un segment avec la garde [else] qui est
automatiquement franchie si aucune des gardes des autres segments
n’est vraie.
Point de décision :
Un segment de transition derrière un point de décision ne peut pas comporter
d’événement.
Généralisation d’états:
e1 AB
A B e1
A B
e2 e2
C e2
C
ETATS COMPOSITES:
•Si le diagramme d’état transition devient trop complexe, on peut utiliser

des états imbriqués pour le simplifier.
• Un super-état ou état composite est un état qui englobe d’autres états

appelés sous-états.
•Le nombre d’imbrication n’est pas limité.

ETATS COMPOSITES: Exemple
Vivant
mariable
Naissance Mariage [âge légal
Célibataire atteint]
Marié
Décès conjoint
Veuf
Divorce
Divorcé
Décès
Les processus
agiles -
SCRUM
Contraintes d'un projet
Les projets informatiques présentent, comme tous les
projets, trois contraintes caractéristiques :
périmètre
- Le périmètre fonctionnel (Scope)
- Les délais (Schedule)
- Les coûts (Budget)
Chaque projet est géré de manière à prendre en compte

ces différentes contraintes.
coûts délais
Introduction
Qu'est ce que l'agilité
L'agilité c'est une culture avant

tout.
La capacité au changement,
c'est se placer dans un mode :
 Itératif
 Incrémental
 Adaptatif
Introduction
Démarche incrémentale
Elle permet de travailler par ajout de parties (incréments).
L'inconvénient : il faut connaitre le résultat final attendu, assez

précisément dès le début du travail.
La méthode n'est pas bien adaptée au processus de création.

Introduction
Démarche Agile : à la fois itérative & incrémentale
Ceci permet d'avancer en ayant à chaque étape une bonne vision du résultat final.
Aux différentes étapes, on dispose d'une partie utilisable.
Introduction
La méthode Agile est adaptative
Elle permet de pouvoir au cours du projet, à intervalles réguliers :

 réviser le cahier des charges
 revoir les priorités
 se remettre en question
… et de s'adapter ainsi aux circonstances favorables ou défavorables.
Cycle en V
Hypothèses:
Le Client sait ce qu’il veut
Les développeurs savent comment le faire
Rien ne va changer en cours de route
Ces hypothèses ne sont pas réalistes !

Agile = missile à tête chercheuse
Hypothèses:
 Le client découvre ce qu’il veut
 Les développeurs découvrent comment le construire
 Les choses changent en cours de route
Agile : Inversion du triangle
Le périmètre est une variable d'ajustement
Contrairement à l’approche traditionnelle de la gestion de projet qui consiste à

fixer un périmètre fonctionnel et ajuster en conséquence les délais et des coûts
l’approche agile permet de fixer les délais et les coûts.
On accueille alors sereinement les modifications de périmètre fonctionnel, sans
que ce soit vécu comme un problème dans le projet (le client a aussi le droit, et
parfois le besoin, de changer d’avis…).
Le manifeste agile -Valeurs
Les individus et leurs interactions plus que les processus et les
outils
Des logiciels opérationnels plus qu’une documentation
exhaustive
La collaboration avec les clients plus que la négociation
contractuelle
L’adaptation au changement plus que le suivi d’un plan
Le manifeste agile -Principes
Satisfaction des clients
Accepter le changement du besoin
Livraison fréquentes
Implication du client
Motivation des équipes
Le dialogue face à face
Equipes auto-organisées
Amélioration continue
Principes
Ce sont des méthodes incrémentales: on travaille avec des
incréments de petite taille
Le système est développé comme une succession de versions
qui correspondent à l’ajout des incréments
On prototype rapidement les interfaces du système pour avoir
un retour rapide des utilisateurs
« Extreme programming »
Sélection d’un Décomposition
Planification
scénario à mettre du scénario
de la version
en œuvre en tâches
Développement,
Evaluation Livraison
Livraison,
du système de la version
tests
Le "package" Scrum
Scrum est considéré comme un cadre ou « framework » de gestion de projet. Ce cadre est
constitué d'une définition des rôles, de réunions et d'artefacts.
Scrum définit 3 rôles :
 Le « Product Owner » qui porte la vision du produit à réaliser (représentant généralement le

client).
 Le « Scrum Master » garant de l'application de la méthodologie Scrum.
 L'équipe de développement qui réalise le produit.
La vie d'un projet Scrum est rythmée par un ensemble de réunions clairement définies et
strictement limitées dans le temps (timeboxing):
•Planification du Sprint (Sprint = itération) : au cours de cette réunion, l'équipe de

développement sélectionne les éléments prioritaires du « Product Backlog » (liste
ordonnancée des exigences fonctionnelles et non fonctionnelles du projet) qu'elle pense
pouvoir réaliser au cours du sprint (en accord avec le « Product Owner »).
•Revue de Sprint : au cours de cette réunion qui a lieu à la fin du sprint, l'équipe de
développement présente les fonctionnalités terminées au cours du sprint et collecte les
feedbacks du Product Owner et des utilisateurs finaux.
•Rétrospective de Sprint : la rétrospective qui a généralement lieu après la revue de sprint

est l'occasion de s'améliorer (productivité, qualité, efficacité, conditions de travail, etc)
•Mêlée quotidienne : il s'agit d'une réunion de synchronisation de l'équipe de

développement qui se fait debout (elle est aussi appelée "stand up meeting") en 15 minutes
maximum au cours de laquelle chacun répond principalement à 3 questions : « Qu'est ce que
j'ai terminé depuis la dernière mêlée ? Qu'est ce que j'aurai terminé d'ici la prochaine
mêlée ? Quels obstacles me retardent ? »
Références
Références
1 Pascal Roques, UML 2 par la pratique: études de cas et exercices
corrigés, Groupe Eyrolles.
2 Xavier Blanc Isabelle Mounier, UML 2 pour les développeurs: Cours
avec exercices corrigés, Groupe Eyrolles, Code éditeur : G12029 •
ISBN : 2-212-12029-X.
3 Pierre Gérard, Introduction à UML 2: Modélisation Orientée Objet de
Systèmes Logiciels, Cours DUT Informatique S2D, Université de Paris 13
IUT Villetaneuse.
4 G. BOOCH, J. RUMBAUGH et Y. JACOBSON, Le guide de
l’utilisateur UML , (Eyrolles, 2000).
5 P. A. MULLER et N. GAERTNER, Modélisation objet avec UML ,
(Eyrolles, 2000).
6 Pierre-Alain Muller and Nathalie Gaertner. Modélisation objet avec
UML. Eyrolles, 2è edition, 2003.
7 James Rumbaugh et al. Modélisation et conception orientée objet.
Masson, 1994.
/ 43
Prof. Said El Kafhali

Langue

GL - 1-Introduction Au Génie Logiciel

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

GL - 1-Introduction Au Génie Logiciel

Transféré par

Droits d'auteur :

Génie Logiciel

 Avoir les notions de base du génie logiciel

Logiciel = programmes + utilisation

 Logiciels sans impact économique significatif (logiciels amateurs)

Logiciels spécifiques développés pour une application précise et

 Logiciels essentiels au fonctionnement d’une entreprise. Ce type de

Critères côté concepteur

 Historiquement, il y a eu une prise de conscience dans les

 Constat du développement logiciel fin années 60 :

 Ensemble des méthodes, des techniques et des outils dédiés à

 Un domaine des sciences de l’ingénieur dont l’objet d’étude est

 Avoir des procédures systématiques pour des logiciels de

 Le but du génie logiciel est d’optimiser le coût et la qualité de

 Confirm (1992) : projet d’American Airlines de système de réservation commun

 Ariane V (1996) : explosion de la fusée en vol due à une erreur de débordement

 Manque de méthodes et d'outils :

 Appliquer les méthodes connues de l’ingénierie au

 Il s’agit de se donner un cadre rigoureux pour :

 Idée du Génie Logiciel:

 La construction d’un logiciel diffère de celle d’un pont :

 C’est une instance cruciale du principe de décomposition des

 Un logiciel a un cycle de vie plus complexe que l’habituel :

 Un logiciel réutilisable a beaucoup plus de valeur qu’un composant

 Un développement logiciel a plus de chances d’aboutir s’il suit

 Processus: un ensemble structuré d’activités qui conduisent à

 Activités du développement logiciel :

Objectif : Comprendre les besoins du client :

 Elle a pour but de dégager le problème à étudier.

 Première étape du cycle de vie d’un logiciel

►► Étudier le marché pour déterminer s’il existe un

Permet de définir ce que doit faire le logiciel et non

Appelée aussi Planification et gestion de projet

 Objectif : Élaborer une solution concrète réalisant la spécification

 Objectif : Implantation de la solution conçue.

On distingue plusieurs types de tests :

Fournir au client une solution logiciel qui

 Correction : identifier et corriger des erreurs trouvées après la

Qu’est ce que le processus de développement d’un logiciel?

un ensemble structuré d’activités nécessaires pour développer

Le modèle en cascade est une organisation des activités

Spécification Cahier des charge

Le modèle en cascade se base sur des exigences exprimées en début de projet.

et donc augmenter les coûts. C'est pourquoi le modèle en cascade est

Le cycle en V est un modèle d'organisation des activités d'un

vérifications adaptées à chaque étape

 Test unitaire : test de chaque unité de programme (méthode,

 Un modèle toujours séquentiel

 Avantages : Validation concrète des besoins, moins de

Spécification Spéc. Spéc. Spéc. Spéc.

Quel est le meilleur modèle ?

Pas de modèle idéal, tout dépend des caractéristiques de

UML (Unified Modeling Language) est un langage (et non pas

UML propose donc un ensemble de notations pour que chacun

Un modèle est une représentation partielle de la réalité:

novembre 1997 suite à la demande émanant de la collaboration de plusieurs entreprises

(Hewlett-Packard, IBM, i-Logix, ICON Computing, IntelliCorp, MCI Systemhouse, Microsoft,

ObjecTime, Oracle, Platinum Technology, Ptech, Rational Software Corporation, Reich

Technologies, Softeam, Sterling Software, Taskon et Unisys).

Les versions se succèdent :

Diagrammes structurels ou diagrammes statiques

Diagrammes de comportement diagrammes dynamiques

Les diagramme d’UML peuvent être utilisés pour

Décrit, sous forme d’actions et de réactions, le comportement

Sert à modéliser les aspects dynamiques d'un système

Comportent plusieurs éléments :