Uml Cours EMS DAOUDI Imane

Introduction à la modélisation
- Génie logiciel
Conception Orientée Objet

L'objectif du génie logiciel est d'optimiser le coût de
développement du logiciel. L'importance d'une approche
Plan : méthodologique s'est imposée à la suite de la crise de l'industrie du
logiciel à la fin des années 1970. Cette crise de l'industrie du logiciel
1. Approche orientée objet était principalement due à :
2. UML
UML - Unified Modeling Language 3. Diagramme de cas d’utilisation
4. Diagramme de classes • l'augmentation des coûts ;
5. Diagramme de collaboration • les difficultés de maintenance et d'évolution ;
6. Diagramme de séquence
7. Diagramme d’objets • la non-fiabilité ;
8. Diagramme d’états-transitions • le non-respect des spécifications ;
9. Diagramme d’activités • le non-respect des délais.
10. Diagramme de composants
11. Diagramme de déploiement
12. Paquetage & Mécanismes d’extension d’UML
13. Les patrons de conception 2
Professeur I.DAOUDI
Introduction à la modélisation Introduction à la modélisation

- Génie logiciel - Qualité du logiciel
En génie logiciel, divers travaux ont mené à la définition de la qualité

du logiciel en termes de facteurs, qui dépendent, entre autres, du
Pour apporter une réponse à tous ces problèmes, le génie logiciel domaine de l'application et des outils utilisés. Parmi ces derniers,
s'intéresse particulièrement à la manière dont le code source d'un nous pouvons citer :
logiciel est spécifié puis produit. Ainsi, le génie logiciel touche au
cycle de vie des logiciels :
• Validité :
aptitude d'un produit logiciel à remplir exactement ses fonctions,
• l'analyse du besoin,
définies par le cahier des charges et les spécifications.
• l'élaboration des spécifications,
• Fiabilité ou robustesse :
• la conceptualisation,
aptitude d'un produit logiciel à fonctionner dans des conditions
• le développement, anormales.
• la phase de test, • Extensibilité :
• Mise en production, facilité avec laquelle un logiciel se prête à sa maintenance, c'est-à-
• la maintenance. dire à une modification ou à une extension des fonctions qui lui sont
demandées.
3 4
Introduction à la modélisation Introduction à la modélisation
- Qualité du logiciel - Qualité du logiciel
• Réutilisabilité : • Intégrité :
aptitude d'un logiciel à être réutilisé, en tout ou en partie, dans de aptitude d'un logiciel à protéger son code et ses données contre des
nouvelles applications. accès non autorisés.
• Compatibilité :
facilité avec laquelle un logiciel peut être combiné avec d'autres • Facilité d'emploi :
logiciels. facilité d'apprentissage, d'utilisation, de préparation des données,
• Efficacité : d'interprétation des erreurs et de rattrapage en cas d'erreur
Utilisation optimale des ressources matérielles. d'utilisation.
• Portabilité :
facilité avec laquelle un logiciel peut être transféré sous différents Remarques :
environnements matériels et logiciels. Ces facteurs sont parfois contradictoires, le choix des compromis
• Vérifiabilité : doit s'effectuer en fonction du contexte.
facilité de préparation des procédures de test.
5 6
Modélisation, cycles de vie et méthodes Modélisation, cycles de vie et méthodes

- Modèle - Pourquoi modéliser ?
• Un modèle est une représentation abstraite et simplifiée, d'une • Modéliser un système avant sa réalisation permet de mieux
entité (phénomène, processus, système, etc.) du monde réel en comprendre le fonctionnement du système. C'est également un
vue de le décrire, de l'expliquer ou de le prévoir. bon moyen de maîtriser sa complexité et d'assurer sa cohérence.
• Un modèle permet de réduire la complexité d'un phénomène en
éliminant les détails qui n'influencent pas son comportement de • Un modèle est un langage commun, précis, qui est connu par
manière significative. Il reflète ce que le concepteur croit tous les membres de l'équipe et il est donc, à ce titre, un vecteur
important pour la compréhension et la prédiction du phénomène privilégié pour communiquer. Cette communication est essentielle
modélisé. pour aboutir à une compréhension commune aux différentes
parties prenantes et précise d'un problème donné.
Exemples de modèles :
• Modèle météorologique, modèle économique, modèle • Dans le domaine de l'ingénierie du logiciel, le modèle permet de
démographique… mieux répartir les tâches et d'automatiser certaines d'entre elles.
• Plans (exemple : la construction d'un immeuble) C'est également un facteur de réduction des coûts et des délais.
Remarque : Les trois premiers exemples sont des modèles que l'on
• Par exemple, les plateformes de modélisation savent maintenant
qualifie de prédictifs (Qui permet de prévoir des faits à partir
exploiter les modèles pour faire de la génération de code (au
d'éléments donnés).
moins au niveau du squelette) voire des allers-retours entre le
Le dernier, plus conceptuel, possède différents niveaux de vues 7 code et le modèle sans perte d'information. 8
comme la plupart des modèles en génie logiciel.
- Pourquoi modéliser ? - cycle de vie d'un logiciel
• Le cycle de vie d'un logiciel, désigne toutes les étapes du

• Le modèle est indispensable pour assurer un bon niveau de qualité développement d'un logiciel, de sa conception à sa mise en
et une maintenance efficace. En effet, une fois mise en production, production. L'objectif d'un tel découpage est de permettre de
définir des jalons intermédiaires permettant la validation du
l'application va devoir être maintenue, probablement par une autre
développement logiciel, c'est-à-dire la conformité du logiciel avec
équipe et, qui plus est, pas nécessairement de la même société
les besoins exprimés, et la vérification du processus de
que celle ayant créé l'application.
développement, c'est-à-dire l'adéquation des méthodes mises en
œuvre. Le jalon est un livrable lié à une date.
• Le choix du modèle a donc une influence capitale sur les
solutions obtenues. Les systèmes non triviaux (ne sont pas
simples) sont mieux modélisés par un ensemble de modèles
indépendants. Selon les modèles employés, la démarche de
modélisation n'est pas la même. • L'origine de ce découpage provient du constat que les erreurs ont
un coût d'autant plus élevé qu'elles sont détectées tardivement
dans le processus de réalisation. Le cycle de vie permet de
détecter les erreurs au plus tôt et ainsi de maîtriser la qualité du
9 logiciel, les délais de sa réalisation et les coûts associés. 10

- cycle de vie d'un logiciel - cycle de vie d'un logiciel
Le cycle de vie du logiciel comprend généralement au minimum les • Tests unitaires
étapes suivantes : ils permettent de vérifier individuellement que chaque sous-
ensemble du logiciel est implémenté conformément aux
• Analyse des besoins et faisabilité spécifications ;
C'est-à-dire l'expression, le recueil et la formalisation des besoins du • Intégration
demandeur (le client) et de l'ensemble des contraintes, puis
l'objectif est de s'assurer de l'interfaçage des différents éléments
l'estimation de la faisabilité de ces besoins ;
(modules) du logiciel. Elle fait l'objet de tests d'intégration consignés
• Spécifications ou conception générale dans un document ;
Il s'agit de l'élaboration des spécifications de l'architecture générale
du logiciel ; • Qualification (ou recette)
• Conception détaillée c'est-à-dire la vérification de la conformité du logiciel aux
spécifications initiales ;
Cette étape consiste à définir précisément chaque sous-ensemble
du logiciel ; • Documentation
• Codage (Implémentation ou programmation) elle vise à produire les informations nécessaires pour l'utilisation du
C'est la traduction dans un langage de programmation des logiciel et pour des développements ultérieurs ;
fonctionnalités définies lors de phases de conception ; 11 12
Modélisation, cycles de vie et méthodes Modèles de cycles de vie d'un logiciel
- cycle de vie d'un logiciel - Modèle en cascade
• Mise en production • Dans ce modèle, le principe est très
c'est le déploiement sur site (emplacement géographique) du simple : chaque phase se termine à une
logiciel ; date précise par la production de
certains documents ou logiciels. Les
résultats sont définis sur la base des
• Maintenance
interactions entre étapes, ils sont
elle comprend toutes les actions correctives (maintenance soumis à une revue approfondie et on
corrective) et évolutives (maintenance évolutive) sur le logiciel. ne passe à la phase suivante que s'ils
sont jugés satisfaisants.
La séquence et la présence de chacune de ces activités dans le cycle • L'inconvénient majeur du modèle de
de vie dépendent du choix d'un modèle de cycle de vie entre le client cycle de vie en cascade est que la
et l'équipe de développement. Le cycle de vie permet de prendre en vérification du bon fonctionnement du
compte, en plus des aspects techniques, l'organisation et les aspects système est réalisée trop tardivement :
lors de la phase d'intégration, ou pire,
humains.
lors de la mise en production.
13 14
Modèles de cycles de vie d'un logiciel Modèles de cycles de vie d'un logiciel
- Modèle en V - Modèle en spirale
• Ce modèle est beaucoup plus général que le précédent. Il met

l'accent sur l'activité d'analyse des risques : chaque cycle de la
spirale se déroule en quatre phases :
1. Détermination, à partir des résultats des cycles précédents, ou

de l'analyse préliminaire des besoins, des objectifs du cycle,
des alternatives pour les atteindre et des contraintes ;
2. Analyse des risques, évaluation des alternatives et,
éventuellement maquettage ;
3. Développement et vérification de la solution retenue, un modèle
• Le cycle de vie le plus connu et le plus utilisé. « classique » (cascade ou en V) peut être utilisé ici ;
• Il s'agit d'un modèle en cascade dans lequel le développement du logiciel
4. Revue des résultats et vérification du cycle suivant.
et des tests sont effectués de manière synchrone.
• Le principe de ce modèle est que toute description d'un composant est
accompagnée de tests qui permettront de s'assurer qu'il correspond à sa • L'analyse préliminaire est affinée au cours des premiers cycles. Le
description. modèle utilise des maquettes exploratoires pour guider la phase de
• Ce modèle souffre toujours du problème de la vérification trop tardive du conception du cycle suivant. Le dernier cycle se termine par un
15 16
bon fonctionnement du système. processus de développement classique.
Modèles de cycles de vie d'un logiciel Méthodes et langages d'analyse
- Modèle par incrément et de conception
o Dans les modèles précédents, un logiciel est décomposé en composants
développés séparément et intégrés à la fin du processus.
o Dans les modèles par incrément, un seul ensemble de composants est Les méthodes et les langages d'analyse et de conception
développé à la fois : des incréments viennent s'intégrer à un noyau de fournissent une méthodologie et des notations standards qui
logiciel développé au préalable. Chaque incrément est développé selon l'un
aident à concevoir des logiciels de qualité. Il existe différentes
des modèles précédents.
manières pour classer ces méthodes, dont :
o Les avantages de ce type de modèle sont les suivants :
• chaque développement est moins complexe ;
• les intégrations sont progressives ; o La distinction entre composition et décomposition.
• il est ainsi possible de livrer et de mettre en service chaque incrément ;
• il permet un meilleur lissage du temps et de l'effort de développement grâce o La distinction entre fonctionnelle (dirigée par le
à la possibilité de parallélisation des différentes phases. traitement) et orientée objet.
o Les risques de ce type de modèle sont les suivants :
• remettre en cause les incréments précédents ou pire le noyau ;
• ne pas pouvoir intégrer de nouveaux incréments.
o Les noyaux, les incréments ainsi que leurs interactions doivent donc être
spécifiés globalement, au début du projet. Les incréments doivent être aussi
indépendants que possible, fonctionnellement, mais aussi sur le plan du 17 18
calendrier du développement.
Méthodes d'analyse et de conception :

Méthodes d'analyse et de conception : La distinction entre fonctionnelle (dirigée par le traitement)
La distinction entre composition et décomposition et orientée objet
Dans la stratégie fonctionnelle (structurée) un système est vu

Elle met en opposition d'une part les méthodes ascendantes qui comme un ensemble hiérarchique d'unités en interaction,
consistent à construire un logiciel par composition à partir de ayant chacune une fonction clairement définie. Les fonctions
modules existants et, d'autre part, les méthodes descendantes disposent d'un état local, mais le système a un état partagé, qui
qui décomposent récursivement le système jusqu'à arriver à est centralisé et accessible par l'ensemble des fonctions.
des modules simplement programmables;
Les stratégies orientées objet considèrent qu'un système est un
ensemble d'objets interagissant entre eux. Chaque objet
dispose d'un ensemble d'attributs décrivant son état et l'état du
système est décrit (de façon décentralisée) par l'état de
l'ensemble.
19 20
Approche fonctionnelle vs. approche objet Approche fonctionnelle vs. approche objet
- Méthodes fonctionnelles - Approche fonctionnelle
Les méthodes fonctionnelles (également qualifiées de méthodes

structurées) trouvent leur origine dans les langages procéduraux.
Elles mettent en évidence les fonctions à assurer et proposent une L'approche fonctionnelle dissocie le problème de la représentation
approche hiérarchique descendante et modulaire. des données, du problème du traitement de ces données. Sur la
figure, les données du problème sont représentées sur la gauche. Des
flèches transversales matérialisent la manipulation de ces données par
des sous-fonctions. Cet accès peut-être direct (c'est parfois le cas quand
les données sont regroupées dans une base de données), ou peut être
réalisé par le passage de paramètre depuis le programme principal.
21 22
- Approche orientée objet - Approche orientée objet
Un objet est caractérisé par plusieurs notions :

• L'identité
L'approche OO considère le logiciel comme une collection d'objets L'objet possède une identité, qui permet de le distinguer des autres objets,
dissociés, identifiés et possédant des caractéristiques. Une indépendamment de son état. On construit généralement cette identité grâce à
caractéristique est soit un attribut (i.e. une donnée caractérisant l'état un identifiant découlant naturellement du problème (par exemple un produit
de l'objet), soit une entité comportementale de l'objet (i.e. une pourra être repéré par un code, une voiture par un matricule, etc.) ;
méthode). La fonctionnalité du logiciel émerge alors de l'interaction • Les attributs
entre les différents objets qui le constituent. L'une des particularités Il s'agit des données caractérisant l'objet. Ce sont des variables stockant des
de cette approche est qu'elle rapproche les données et leurs informations sur l'état de l'objet ;
traitements associés au sein d'un unique objet.
• Les méthodes
Les méthodes d'un objet caractérisent son comportement, c'est-à-dire
L'approche structurée privilégie la fonction comme moyen l'ensemble des actions (appelées opérations) que l'objet doit réaliser. Ces
d'organisation du logiciel. Ce n'est pas pour cette raison que opérations permettent de faire réagir l'objet aux sollicitations extérieures (ou
l'approche objet est une approche non fonctionnelle. En effet, les d'agir sur les autres objets). De plus, les opérations sont étroitement liées
méthodes d'un objet sont des fonctions. aux attributs, car leurs actions peuvent dépendre des valeurs des attributs,
ou bien les modifier.
23 24
- Exemple : gestion d'une bibliothèque - Exemple : gestion d'une bibliothèque
• Exemple de découpe fonctionnelle d'un logiciel dédié à la Inconvénients :
gestion d'une bibliothèque. • Maintenance complexe en cas d'évolution.
• Le logiciel est composé d'une hiérarchie de fonctions, qui ensemble, Les fonctions sont interdépendantes : une simple mise à jour du logiciel à
fournissent les services désirés, ainsi que des données qui représentent les
un point donné, peut impacter en cascade une multitude d'autres
éléments manipulés (livres …).
fonctions.
• Une découpe fonctionnelle consiste à factoriser certains comportements
communs du logiciel. Exemple : passage de la gestion d'une bibliothèque à celle d'une médiathèque.
25 26
- Exemple : gestion d'une bibliothèque - Exemple : gestion d'une médiathèque
Inconvénients :
• Séparation des données et des traitements. Améliorations :
Faire évoluer une application de gestion de bibliothèque (livre) pour gérer une
• 1ère amélioration : rassembler les valeurs
médiathèque, afin de prendre en compte de nouveaux types d'ouvrages
(cassettes vidéo, CD-ROM, Livre, etc.), nécessite : qui caractérisent un type, dans le type.
• de faire évoluer les structures de données qui sont manipulées par les
fonctions, Une solution relativement élégante à la
• d'adapter les traitements, qui ne manipulaient à l'origine qu'un seul type de multiplication des branches conditionnelles et
document (des livres). des redondances dans le code
(conséquence logique d'une trop grande
Modification : Il faudra par exemple modifier la fonction qui réalise l'édition des ouverture des données), consiste tout
"lettres de rappel" (une lettre de rappel est une mise en demeure, qu'on envoie simplement à centraliser dans les
automatiquement aux personnes qui tardent à rendre un ouvrage emprunté). Si structures de données, les valeurs qui
l'on désire que le délai avant rappel varie selon le type de document emprunté, leurs sont propres.
il faut prévoir une règle de calcul pour
chaque type de document.
27 28
- Exemple : gestion d'une médiathèque - Exemple : gestion d'une médiathèque
Améliorations : Avantages AOO :
• Si notre médiathèque devait gérer un
• 2ème amélioration : centraliser les nouveau type d'ouvrage, il suffirait de
traitements associés à un type, auprès du type. modifier une seule fonction, pour assurer la
prise en compte de ce nouveau type de
Rassembler dans une même unité physique les document dans le calcul du délai avant rappel.
types de données et tous les traitements Plus besoin de fouiller partout dans le code...
associés.
• Ecrit en ces termes, notre logiciel sera plus

facile à maintenir et bien plus lisible. Le
stockage et le calcul du délai avant rappel des
documents, est désormais assuré par une
seule et unique unité physique (quelques
lignes de code, rapidement identifiables).
29 30
- Exemple : gestion d'une médiathèque - Exemple : gestion d'une médiathèque
Avantages AOO : Récapitulons :
• Pour accéder à la caractéristique "délai avant rappel" d'un document, il suffit de Une même unité physique, permet de limiter les points de maintenance dans le
récupérer la valeur correspondante parmi les champs qui décrivent le document. code et facilite l'accès à l'information en cas d'évolution du logiciel.
Pour assurer la prise en compte d'un nouveau type de document dans le calcul du
délai avant rappel, il suffit de modifier une seule fonction, située au même
endroit que la structure de données qui décrit les documents :
• Les modifications que nous avons apporté à notre logiciel de gestion de

médiathèque, nous ont amené à transformer ce qui était à l'origine une structure de
données, manipulée par des fonctions, en une entité autonome, qui regroupe un
ensemble de propriétés cohérentes et de traitements associés. Une telle entité
s'appelle objet.
• Un objet constitue le concept fondateur de l'approche orientée objet.
31 32
Approche orientée objet Approche orientée objet
Objet Objet
Objet : Exemple :
• Un objet est une entité aux frontières précises qui possède une identité
(un nom).
• Un ensemble d'attributs caractérise l'état de l'objet.
• Un ensemble d'opérations (méthodes) en définissent le comportement.
• Un objet est une instance de classe (une occurrence d'un type abstrait).
• Une classe est un type de données abstrait, caractérisé par des
propriétés (attributs et méthodes) communes à des objets et permettant
de créer des objets possédant ces propriétés.
33 34

Objet - Concepts Objet - Concepts
Encapsulation : Héritage :
• Consiste à masquer les détails d'implémentation d'un objet, en • L'héritage est un mécanisme de transmission des propriétés d'une
définissant une interface. classe (ses attributs et méthodes) vers une sous-classe.
• L'interface est la vue externe d'un objet, elle définit les services • Une classe peut être spécialisée en d'autres classes, afin d'y ajouter
accessibles (offerts) aux utilisateurs de l'objet. des caractéristiques spécifiques ou d'en adapter certaines.
• L'encapsulation facilite l'évolution d'une application car elle stabilise • Plusieurs classes peuvent être généralisées en une classe qui les
l'utilisation des objets : on peut modifier l'implémentation des attributs factorise, afin de regrouper les caractéristiques communes d'un
d'un objet sans modifier son interface. ensemble de classes.
• L'encapsulation garantit l'intégrité des données, car elle permet • La spécialisation et la généralisation permettent de construire des
d'interdire, ou de restreindre, l'accès direct aux attributs des objets hiérarchies de classes. L'héritage peut être simple ou multiple.
(utilisation d'accesseurs). Les accesseurs (getter) sont des méthodes • L'héritage évite la duplication et encourage la réutilisation.
publics permettent d'accéder aux champs d'ordre privé.
35 36
Polymorphisme : Polymorphisme – exemple :

• Le polymorphisme représente la faculté (possibilité) d'une méthode
à pouvoir s'appliquer à des objets de classes différentes.
• Le polymorphisme augmente la généricité du code.
Exemple d'une hiérarchie de classes
37 38

Agrégation : Résumé sur les concepts fondateurs de l'approche

• Il s'agit d'une relation entre classes, spécifiant que les objets d'une objet :
classe sont des composants d'autres classes.
• Une relation d'agrégation permet donc de définir des objets • La notion d'objet et de classe d'objets.
composés d'autres objets. • L'encapsulation (les interfaces des objets).
• L'agrégation permet d'assembler des objets de base, afin de • L'héritage (les hiérarchies d'objets).
construire des objets plus complexes.
• Polymorphisme.
Exemple d'une agrégation : • L'agrégation (la construction d'objets à l'aide d'objets).
Remarque :
Les langages orientés objet fournissent de nombreux autres
mécanismes qui affinent ces concepts de base, favorisent la
généricité du code ou améliorent sa robustesse.
39 40
Présentation – UML
Sommaire
• Genèse d’UML
• UML est une notation
Conception Orientée Objet • UML n’est pas une méthode
• Les niveaux de modélisation
• Les axes de modélisation
• Les diagrammes UML
UML - Unified Modeling Language
42
Genèse d’UML UML est une notation
• UML propose un cadre pour l’Analyse et la Conception orientée

• UML est le fruit de l’unification (regroupement) de 3 méthodes de objet.
modélisation orientées objet
– OMT (Object Modeling Technique) : Conçue par James Rumbaugh en 1991 • UML est un langage de modélisation objet
– Booch : Grady Booch – 9 diagrammes standardisés (facettes complémentaires d’un
– OOSE (Object Oriented Software Engineering) : Ivar Jacobson système).
– Support des phases d’Analyse et de Conception orientée objet.
• UML est le fruit d’un consensus (accord) général
– élaboré avec le concours de la communauté des utilisateurs • UML est un langage de communication
– utilisation d’un même formalisme par tous les intervenants.
– permet de lever les ambiguïtés du langage naturel.
• UML est une notation (relativement) simple et non propriétaire
– standardisé par l’OMG (Object Management Group) en 1997
• UML est un langage simple de haut niveau
– facile à comprendre car visuel.
– indépendant de tout langage de programmation.
43 44
UML est une notation UML est un langage pseudo-formel
• UML est fondé sur un métamodèle, qui définit :

– les éléments de modélisation (les concepts manipulés par le
langage),
• UML est un langage semi-formel – la sémantique de ces éléments (leur définition et le sens de leur
utilisation).
– basé sur un méta-modèle décrit en UML.
– les concepts manipulés et leur sémantique sont clairement établis • Un métamodèle est une description très formelle de tous les
par le méta-modèle. concepts d'un langage. Il limite les ambiguïtés et encourage la
– les différents diagrammes sont cohérents entre eux. construction d'outils.
– UML est largement outillé. • Un métamodèle définit la structure que doit avoir tout modèle
conforme à ce métamodèle.
• UML est un langage ouvert • Le métamodèle d'UML permet de classer les concepts du
– possibilité d’ajouter des notes (texte). langage (selon leur niveau d'abstraction ou domaine
– utilisation de stéréotypes permettant d’étendre la notation.
d'application) et expose sa structure.
améliorant ainsi la sémantique des éléments modélisés. • Le métamodèle UML est lui-même décrit par un métamodèle
(OMG-MOF).
• UML propose aussi une notation, qui permet de représenter
45
graphiquement les éléments de modélisation du métamodèle. 46
• Cette notation graphique est le support du langage UML.
UML n’est pas une méthode Plusieurs niveaux de modélisation
• Niveau « Système »
• UML n’est pas une méthode, ce n’est qu’une notation – recadrage contextuel du système dans son environnement et
– attente de la part des utilisateurs d’une normalisation du formalisme. détermination des interactions avec les utilisateurs.
– définir un processus de développement logiciel universel est illusoire. – modélisation de l’architecture des processus.
– modélisation de l’architecture d’implémentation.
• UML est indépendant de toute démarche – modélisation de l’architecture de déploiement.
– ce qui en fait un langage universel.
– mais favorise la mise en œuvre d’un processus itératif et • Niveau « Sous Système »
incrémental, fondé sur les cas d’utilisation et centré sur l’architecture. – décomposition structurelle hiérarchique du système.
• Niveau « Entité »
– modélisation détaillée au niveau de l’objet.
47 48
Les diagrammes proposés par
Plusieurs axes de modélisation
UML
• Axe structurel / statique

– modélisation statique du système • Système (contextuel)
– quels objets manipule le système ? – Diagramme de cas d’utilisation
– détermination du QUOI • Système (architecture)
– Diagrammes de composants
• Axe comportemental / dynamique – Diagrammes de déploiement
– modélisation dynamique du système • Structurels
– sous quelles conditions agit le système ? – Diagramme de packages
– détermination du QUAND – Diagramme de classes
– Diagramme d’objets
• Axe fonctionnel • Dynamiques
– modélisation des traitements offerts par le système – Diagramme de collaboration
– que fait le système ? – Diagramme de séquence
– détermination du COMMENT – Diagramme d’états-transitions
• Fonctionnels
49 – Diagramme d’activités 50
Sommaire
• Introduction
• Objectifs
UML • Cas d’utilisation
(Cas d’utilisation) • Acteur
• Diagramme de cas d’utilisation
• Dépendances entre cas d’utilisation
Unified Modeling Language
• Scénario
52
Cas d’utilisation (Use Cases) Cas d’utilisation (Use Cases)
Objectifs
• Début des années 90, Ivar Jacobson invente la méthode OOSE • Définir les besoins fonctionnels du système :
(Object-Oriented Software Engineering) chez Ericsson. Les cas d’utilisation ont pour principal objectif la capture des
fonctionnalités couvertes par le système
• Adaptation de la méthode au BPR (Business Process
Reengineering). • Définir le périmètre fonctionnel du système :
Les cas d’utilisation permettent de définir les frontières du
• 1996, Jacobson rejoint Rumbaugh et Booch donnant ainsi système avec son environnement
naissance à UML 0.9.
• Définir le dialogue entre l’utilisateur et le système :
Les cas d’utilisation recensent comment l’utilisateur interagit
• Cas d’utilisation est la traduction française de Use case.
avec le système
53 54
Cas d’utilisation (Use Cases) Cas d’utilisation
• Une interaction en provenance de l’extérieur déclenche un flot

Objectifs (suite) de contrôle (séquence d’activités) au sein du système.
• Pendant l’exécution de ce flot de contrôle, plusieurs interactions avec
son initiateur peuvent avoir lieu.
• Etablir les scénarios fonctionnels qui seront utilisés pour la
recette du système : • Chaque flot de contrôle correspond à une fonctionnalité ou un
processus fonctionnel attendu du système.
Les cas d’utilisation recensent et décrivent les principales
fonctionnalités attendues du système
• Servir de support de référence tout au long des phases de Déposer argent

développement du système :
Les cas d’utilisation seront consultés et référencés tout au long
du processus de développement du système
Retirer argent
55 56
Cas d’utilisation Cas d’utilisation
(Définition) (Notation)
• Un cas d’utilisation est Notation

Un cas d’utilisation est une séquence d’activités ou d’actions représenté par un ovale.
organisées en étapes distinctes, et qu’un système effectue • Le nom du cas
en réponse à une sollicitation extérieure d’utilisation apparaît à
l’intérieur de l’ovale. Il
• Le cas d’utilisation est déclenché par un événement extérieur au est composé :
système appelé événement initiateur.
- d’un nom optionnel de DAB::Retirer argent
paquetage.
• Le cas d’utilisation possède un nom : celui de la fonctionnalité
- du nom de la
du système qu’il prend en charge.
fonctionnalité qu’il prend
en charge.
• Le cas d’utilisation met en œuvre un dialogue entre le système
et l’entité à l’origine de l’événement initiateur.
57 58
Comment déterminer les cas

Description d’un cas d’utilisation
d’utilisation
Se poser les questions suivantes :

• Titre (commence par un verbe)
• Objectif (descriptif court : une phrase si possible) • Quelles sont les grandes fonctionnalités attendues du système ?
• Acteurs
• Le système doit-il informer une personne ou un dispositif extérieur
• Pré-conditions lorsque son état interne est modifié ?
– conditions nécessaires pour que le cas d’utilisation s’exécute
• Le système doit-il être informé d’événements extérieurs se
• Scénario nominal
produisant dans son entourage ?
– description pas à pas textuelle
– chaque étape du cas d’utilisation est numérotée 1. Introduire la carte • Le système stocke-t-il des informations ? Comment sont-elles
• Exceptions
2. Taper le code stockées, mises à jour et détruites ?
3. …
• Post-conditions • …
– état d’une partie du système après l’exécution du cas d’utilisation
• Fréquence & performance requises
59 60
Acteur
Acteur
(Définition)
• « Pierre utilise le système pour gérer son agenda »

Un acteur définit un rôle qu’une entité extérieure • « Philippe utilise aussi le système pour gérer son agenda. Mais
assume lors de son interaction avec le système Philippe est aussi autorisé à administrer le système »
• Pierre n’est pas un acteur du système, Philippe n’est pas un
acteur du système
• L’acteur est à l’origine des événements initiateurs reçus par le
système • Le rôle « Utilisateur » est un acteur du système
• L’acteur dialogue par la suite avec le cas d’utilisation dont il est • Le rôle « Administrateur » est un acteur du système
l’initiateur
• L’acteur possède un nom : celui du rôle qu’il joue lors de son
interaction avec le système Ne pas confondre personne physique et rôle
• L’acteur n’est pas forcément humain. Il peut s’agir : Une personne peut très bien assumer plusieurs rôles
– d’un autre système
et réciproquement
– d’un équipement
61 62
Acteur
Comment déterminer les acteurs
(Notation)
• Un acteur est représenté Notation Se poser les questions suivantes :

par un petit personnage
• Le nom de l’acteur • Qui installe le système ?
apparaît sous le petit • Qui utilise le système ?
personnage • Qui démarre le système ?
• On peut définir des Utilisateur • Qui maintient le système?
catégories d’acteurs • Quels sont les autres systèmes qui utilisent le système ?
plus générales • Qui fournit de l’information au système ?
ou • Qui récupère de l’information à partir du système ?
• …
au contraire spécialiser un
type d’acteur Utilisateur Utilisateur
externe interne
63 64
Diagramme de cas d’utilisation Diagramme de cas d’utilisation
Le diagramme des cas Notation

Le diagramme de cas d’utilisation est une représentation
contextuelle de haut niveau du système modélisé d’utilisation met en scène :
- les acteurs
Cas d’utilisation 1
• Permet de définir de manière précise les frontières du système

- les cas d’utilisation
à modéliser - les interactions entre
acteurs et cas
• Montre les interactions entre le système et son environnement d’utilisation Acteur 1
extérieur - les dépendances entre

cas d’utilisation
• Montre les dépendances existantes entre les cas d’utilisation Acteur 2
65 66
Interaction entre acteur et cas Dépendances entre cas

d’utilisation d’utilisation
Il existe 3 types de dépendances entre use cases :

• Elle est représentée par une Retirer
argent
association sous la forme
• Les dépendances d’utilisation
d’un lien éventuellement
Mise en facteur de séquences d’événement communes
orienté dans le sens de
l’interaction
• Les dépendances d’extension
• Une seule association est Client
Externalisation de séquences d’événement exceptionnelles
utilisée pour représenter Déposer
argent
l’ensemble des événements • Les dépendances de généralisation
échangés Généralisation / spécialisation de cas d’utilisation
• L’association peut comporter
des cardinalités Consulter compte
Banquier
67 68
Dépendance d’utilisation Dépendance d’utilisation
• Indique qu’un cas Notation Notation

d’utilisation utilise « include »
• Le cas d’utilisation source 1. Etape 1
systématiquement et Cas d’utilisation 1

Authentifier de la dépendance 2. Etape2
carte 3. Etape3 (include)
intégralement une « include » d’utilisation contient une 4. …
séquence d’activités Cas d’utilisation 2
référence vers le cas
décrite dans un autre cas d’utilisation inclus
d’utilisation Authentifier
Acteur 1 Cas d’utilisation 1 carte
• L’inclusion est signalée par « include »
• Est représentée par une le texte « (include) » à
flèche pointillée étiquetée l’étape correspondante Cas d’utilisation 2
« include », pointant vers Acteur 1

Le cas d’utilisation 1 utilise
le cas d’utilisation utilisé systématiquement le cas d’utilisation 2
69 70
Dépendance d’utilisation Dépendance d’extension
• Indique qu’un cas Notation

Retirer
argent
« include » d’utilisation utilise Cas d’utilisation 1
• Permet de décomposer « include » Authentifier

facultativement ou
un cas d’utilisation carte sous certaines
Acteur 1
complexe en cas Client Déposer
Déposer
Cas d’utilisation 2 conditions une Cas d’utilisation 2
argent
d’utilisation plus simples argent séquence d’activités « extend »
décrite dans un autre cas
d’utilisation
• Permet de factoriser des Retirer
argent
Utilisateur
comportements utiles à « include »
• Est représentée par une
plusieurs cas d’utilisation « include » Authentifier flèche pointillée étiquetée
carte
Client
Déposer
« extend », pointant Le cas d’utilisation 2 est une extension
argent vers le cas d’utilisation du cas d’utilisation 1
71
étendu 72
Dépendance d’extension Dépendance de généralisation
• Le cas d’utilisation étendu Notation

contient une liste de Cas d’utilisation 1 • Indique qu’un cas Notation
« include »
points d’extension Points d’extension :
. point extension1 : emplacement1
d’utilisation est une
Authentifier
• Un point d’extension est . point extension2 : emplacement2 spécialisation d’un autre Cas d’utilisation 1 carte
composé d’un nom suivi Cas d’utilisation 2

cas d’utilisation Cas d’utilisation 2
d’un numéro d’étape « extend »
(emplacement) • Est représentée par une

• Le cas d’utilisation qui Cas d’utilisation 2
flèche « d’héritage » Acteur 1
étend indique dans sa Utilisateur pointant du cas
description sous quelles d’utilisation spécialisé vers
Condition de déclenchement
conditions il se Au point « point extension1 » :
le cas d’utilisation le plus
déclenche • Etape1 général Le cas d’utilisation 2 est une spécialisation
• Etape2 du cas d’utilisation 1
• … 73 74
Dépendance de généralisation Scénario
• Permet de factoriser un Notation « include »

comportement commun Retirer argent • Un cas d’utilisation propose un comportement nominal
à un ensemble de cas Authentifier (scénario nominal)
carte
d’utilisation proches • Un cas d’utilisation propose aussi un ou plusieurs

comportements alternatifs (scénario alternatif) chacun
représentant un cheminement particulier dans le cas d’utilisation
• Le cas d’utilisation le plus Retirer argent • Un cas d’utilisation décrit aussi des situations exceptionnelles
avec ticket
général est dit abstrait si Utilisateur <<Abstract>> • L’idéal est de créer suffisamment de scénarios couvrant
Ouvrir compte l’essentiel d’un cas d’utilisation
seuls les cas d’utilisation
spécialisés sont – Il est inutile d’identifier tous les scénarios possibles
exécutables
Ouvrir compte
chèque Ouvrir compte
épargne
75 76
Recommandations Recommandations (suite)
• Ne pas confondre cas d’utilisation et scénario • Lorsque le système est complexe, il n’est pas anormal d’avoir
– Chaque cas d’utilisation correspond à un objectif d’un acteur vis à de nombreux cas d’utilisation. Il faut alors les classer et les
vis du système rassembler dans des bibliothèques de cas d’utilisation
– Un scénario décrit le déroulement d’un cas d’utilisation – on définit pour cela des paquetages (notion abordée dans ce
cours)
– Ne pas oublier les scénarios correspondant aux principaux cas
d’échec du cas d’utilisation (mot de passe invalide, carte de crédit
invalide, article du catalogue indisponible ou en nombre • Lorsque le système est complexe, les cas d’utilisation peuvent
insuffisant…) s’emboîter les uns dans les autres. Veiller à ne pas mélanger un
cas d’utilisation « générale » (exemple : prendre une
• Ne décrire que les principaux cas d’utilisation du système commande) avec des cas d’utilisation plus fins (exemple :
choisir son mode de paiement)
Un cas d’utilisation doit contenir une quantité « appréciable et
tangible » de travail – Utiliser les relations de dépendance entre cas (notamment les
include)
• Ne pas décomposer trop finement les cas d’utilisation.

Les dépendances d’utilisation et d’extension ne doivent être
utilisées que pour des comportements significatifs du système
77 78
Recommandations (suite)
• Compléter le diagramme de cas d’utilisation par un diagramme

de séquence ou un diagramme de collaboration
• Faire figurer uniquement les acteurs en interaction avec les cas

UML
d’utilisation (Diagramme de classes)
• Un diagramme de cas d’utilisation n’est pas un diagramme de
flots de données.
• Les dépendances entre cas d’utilisation ne traduisent pas un

échange de données ou un flot de contrôle (diagramme
d’activité)
79
Sommaire Diagramme de classes
• Introduction
• Apport en grande partie de la méthode OMT (Rumbaugh).
• Objectifs
• Diagramme de classes
• Classe (Nom, attribut, opération) • S’apparente à un diagramme entité-association (MERISE). Il
• Visibilité et portée des constituants d’une classe présente les différents objets (classes) du système ainsi que les
• Association (Nom, rôles) liens entre ces objets (associations).
• Association réflexive
• Navigabilité d’une association • Diagramme le plus important dans une modélisation objet.
• Contraintes sur association
• Qualificateur d’une association
• Classe associative
• Types d’association (Agrégation, composition, généralisation /
spécialisation)
• Classe et opération abstraites
81 82
Diagramme de classes Diagramme de classes
Objectifs Objectifs (suite)
• Déterminer les données qui seront manipulées par le système. • Poser les fondements stables régissant la totalité de
Ces données sont organisées en classes. l’architecture du système.
Ce modèle est le garant du respect du paradigme objet.
• Donner la structure statique de ces données.
Ce diagramme permet de décrire la structure interne de
chacune des classes. • Faire abstraction (exclure) des aspects temporels et
dynamiques de la modélisation.
• Représenter les relations statiques existant entre les Seul l’aspect statique compte, la dynamique est prise en
différentes données du système. charge par d’autres modèles.
La navigation parmi les classes est rendue possible par
l’existence d’associations qui les unissent.
83 84
(Définition) Exemple
Le diagramme de classes est un diagramme

Client CompteCourant
entités-associations décrivant les différentes classes, 1 possède 0..1
leur structure et les associations statiques les unissant.
*
• Le diagramme de classes est un diagramme structurel ne 1
présentant que les classes et pas les instances de classe souscrit achète
(objets).
0..1 *
• Il permet de décrire la structure interne des classes en terme Plan Epargne Actions Actions
d’attributs et d’opérations.
• Il permet de représenter les associations statiques entre les

classes, mais ne décrit pas comment les liens effectifs entre les
instances sont effectués.
85 86
Classe
Classe
(Définition)
Une classe est une abstraction de choses

du monde réel possédant des caractéristiques et
des comportements communs.
• La classe est la fabrique, le moule, à partir duquel on fabrique

les instances (les objets).
Abstraction
Abstraction
• Seules les caractéristiques pertinentes pour le problème

étudié entrent dans la composition de la classe.
Chien Personne
age age
pedigree nationalité
courir() se promener()
87 aboyer() crier() 88
Classe
Nom de la classe
(Notation)
• Une classe est Notation • Le nom de la classe

représentée par un
peut être précédé << Sécurité >> << Métier >>
rectangle découpé en login :: Code secret Compte
d’un stéréotype
3 parties.
qualifiant le type de N°
<< Stéréotype >> la classe. Code
• Sont présents : Nom paquetage :: Nom classe Créditer()
Débiter()
– le nom de la classe.
Attributs • Le nom de la classe
– la liste de ses est préfixé par un
attributs.
Opérations nom de paquetage
– la liste de ses si la classe est
opérations. << Métier >>
externe au Compte chèque
paquetage courant.
89 90
Attribut de la classe Attribut de la classe

(Définition et notation) Recommandations pour trouver les attributs
Un attribut est une caractéristique intrinsèque Les 3 règles d’or de l’attribut :

partagée par tous les objets d’une classe
• Eliminer les attributs caractérisant une autre classe
• L’attribut possède un nom ex : l’attribut « nom client » dans la classe « compteBancaire »
unique dans la classe Notation
• Se méfier des attributs multi-valués, ils cachent souvent eux-
• On peut associer à l’attribut mêmes une classe
<< Stéréotype >>
le type des valeurs qu’il peut Nom paquetage :: Nom classe ex : l’attribut « enfants » dans la classe « Personne »
prendre
nomAttribut1 : typeAttribut1 = valeurInitiale1
… • Se méfier des attributs structurés, ils cachent souvent eux-
nomAttributN : typeAttributN = valeurInitialeN
• On peut donner une valeur mêmes une classe
initiale à l’attribut ex : l’attribut « Adresse » dans une classe « Personne »
91 92
Attribut de la classe Opération de la classe
Recommandations pour trouver les attributs (Définition et notation)
Une opération est un service que propose

• Ne donner les types et les valeurs initiales des attributs qu’en une classe sur son interface
phase de Conception
• L’opération possède un nom
• Lorsqu’une classe possède de très nombreux attributs se poser pas forcément unique dans Notation
la question du découpage de la classe la classe
<< Stéréotype >>
• On peut associer à l’opération Nom paquetage :: Nom classe
ses arguments
• On peut associer à l’opération nomOpération1 (nomArg1 :TypeArg1 = valeurParDéfaut1, ...)

: typeRetour1
son type de retour …
nomOpérationN (nomArgN :TypeArgN = valeurParDéfautN, ...)
: typeRetourN
93 94
Opération de la classe
Exemple de classe
Recommandations pour trouver les opérations
Compte
numero
solde
• Ne donner les informations sur les arguments et le type de effectuerVirement()

retour qu’en phase de Conception getSolde()
setSolde()
getNumero()
• Lorsqu’une classe possède de très nombreuses opérations se setNumero()
poser la question du découpage de la classe
accesseur = getter mutateur = setter
o Les getters sont des fonctions qui permettent la récupération de la
valeur d'une variable déclarée "private" dans la classe.
o Le setter permet d'affecter une valeur à l'un des attributs de la
classe. Par exemple, pour modifier l'âge d'une personne, on passera
par son setter en lui passant en paramètre la nouvelle valeur.
95 96
Visibilité et Portée Visibilité des constituants
des constituants de la classe de la classe
• La visibilité précise la
manière dont un nom peut • L'encapsulation permet de définir des niveaux de visibilité des éléments
être vu et utilisé par les Notation d'un conteneur. La visibilité déclare la possibilité pour un élément de
autres (public, protégé, modélisation de référencer un élément qui se trouve dans un espace de
privé). Nom Classe noms différent de celui de l'élément qui établit la référence. Elle fait partie
de la relation entre un élément et le conteneur qui l'héberge. Ce dernier
• / : signal un attribut dérivé. +Attribut public pouvant être un paquetage, une classe ou un autre espace de noms. Il
C'est à dire calculé à partir #Attribut protégé existe quatre visibilités prédéfinies.
d'autres attributs. -Attribut privé
Attribut de classe • Public ou + : tout élément qui peut voir le conteneur peut également voir
• La portée précise dans /Attribut dérivé l'élément indiqué.
quel contexte un nom • Protected ou # : seul un élément situé dans le conteneur ou un de ses
prend sa signification +Opération publique() descendants peut voir l'élément indiqué.
(instance ou classe). #Opération protégée() • Private ou - : seul un élément situé dans le conteneur peut voir l'élément.
-Opération privée()
• Package ou ∼ ou rien : seul un élément déclaré dans le même
• Par défaut, la visibilité est publique et la portée est d’instance. Opération de classe()
• Page 10 paquetage peut voir l'élément. (Visibilité par défaut)
• Page10 ‘
97 98
Association
Association
(Définition)
Une association est une abstraction de liens

qui peuvent exister entre les instances de plusieurs classes
• Dans le monde réel, les objets sont liés physiquement ou

fonctionnellement les uns avec les autres
Abstraction Abstraction
• Ces liens entre objets se traduisent au niveau des classes par
des associations
• Une association traduit donc une relation structurelle statique

Chien Abstraction
Personne
entre deux ou plusieurs classes âge âge
pedigree nationalité
courir() se promener()
99 aboyer() crier() 100
Association
Nom de l’association
(Notation)
• Une association est représentée au moyen d’un trait orienté reliant

chacune des classes concernées
• Le nom de l’association est
• Il est possible de nommer l’association et de préciser les rôles tenus en général une forme Notation
par chaque classe verbale active ou passive
qui décrit globalement le lien
Notation
• Le nom de l’association est
facultatif
Client achète Voiture
• Le nom doit apparaître sur

l’association, mais ne doit
Personne salarié Société pas être rattaché à l’une des
extrémité
employeur
101 102
Nom et rôles de la classe

Rôles de l’association
(Recommandations)
• Le rôle permet de décrire, à

l’aide d’un nom, comment Notation
une classe perçoit une autre • L’utilisation du nom et des rôles d’une association n’est pas
classe au travers de exclusif
l’association
• Cependant, les deux notations sont rarement utilisées
conjointement
• Un rôle doit figurer à Personne Société
salarié
l’extrémité de l’association
qu’il qualifie employeur • L’usage du nom et des rôles n’est pas obligatoire, mais il
s’avère indispensable si deux objets sont reliés par plusieurs
associations ou si une association est réflexive
• Les rôles sont facultatifs
L’association peut faire
figurer les deux, un seul ou
aucun des rôles 103 104
Association réflexive Navigabilité de l’association
• Une association peut mettre • La navigabilité d’une

en jeux deux classes Client achète Voiture association permet de Notation
définir dans quel sens
distinctes.
l’association peut être Personne Film
parcourue a vu
Exemple d’association classique
• Mais, elle peut aussi • La navigabilité d’une
apparaître sur une seule et association est modélisée
même classe. Se marier avec par une flèche sur Chaque personne a accès aux films qu'elle a déjà vus,
mais à partir d'un film, on interdit de retrouver la liste des
l’extrémité pouvant être personnes l'ayant vu
Dans ce cas précis,
atteinte par navigation
l’association est dite Personne
réflexive. • La navigabilité peut être bi- Client Voiture
achète
directionnelle. L’absence de
flèche sur les deux
Exemple d’association réflexive extrémités signifie que
l’association est L’association peut être parcourue dans les deux sens
105 bidirectionnelle 106
Multiplicités de l’association Multiplicités de l’association
La multiplicité est une spécification respectant les conventions

• La cardinalité d’un suivantes :
ensemble est le nombre Notation
1 : un et un seul (notation facultative)
d’éléments de cet ensemble
Personne emploie Société
• La multiplicité est la 0..1 : zéro ou un
spécification des valeurs de 1 ..* 1
cardinalité admissibles pour N : exactement N (N: entier naturel)
un ensemble Une société emploie de une à plusieurs personnes
Une personne est employée par une seule société M..N : de M à N (deux entiers naturels)
• La multiplicité est associée
à une extrémité de * : de zéro à plusieurs
l’association et indique
combien d’instances de la 0..1 *
0..* : de zéro à plusieurs
classe considérée peuvent
1..* : de un à plusieurs
être liées à une instance de Un client achète zéro à plusieurs voitures
Une voiture peut être achetée par un client au plus
l’autre classe N..* : N ou plus (N: entier naturel)
107 108
Contraintes ensemblistes sur
Contraintes sur association
association
• Ce type de contrainte permet de modéliser le cas où un ensemble

d’associations est inclus dans un autre ensemble d’association
D’autres types de contraintes existent sur une association :
• Des contraintes prédéfinies :

Notation
– Les contraintes ensemblistes : {Sous-ensemble}
– Les contraintes d’ordonnancement : {Ordonné}
– Les contraintes d’exclusion : {Ou - exclusif}
* est nominé *
Prix Personne
{Sous-ensemble}
• Des contraintes spécifiques au moyen du langage OCL (Object
Constraint Language) *
est lauréat 1
Les personnes lauréates d’un prix sont obligatoirement choisies parmi celles qui
sont nominées pour ce prix
109 110
Contraintes d’ordonnancement sur Contraintes d’exclusion sur

association association
• Ce type de contrainte permet de modéliser le cas où pour une • Ce type de contrainte permet de modéliser le cas où pour une
instance donnée, l’ensemble des instances avec lesquelles elle est instance donnée d’une classe, une seule association prise parmi
en relation doit être ordonné plusieurs possibles, peut être valide à un instant donné
• Exemple: course et athlète.
Notation Notation
{Ordonné}
0..* 0..6 employé 0..*
Grand prix est dans Pilote Société Personne
les points {Ou - exclusif}
employeur
Lors d’un grand prix au maximum 6 pilotes peuvent être dans les points Une personne peut être soit employée par une société, soit employeur
d’une société
Ces 6 pilotes sont classés à l’arrivée
111 Mais une personne ne peut pas être à la fois employeur et employé 112
Qualificateur d’une association Qualificateur d’association
Exemples
• Le qualificateur est un attribut ou un ensemble d’attributs

permettant de partitionner l’ensemble des instances d’une
1..*
classe qui sont en relation avec une instance donnée Université Salle
possède
• Le qualificateur permet de restreindre la multiplicité de
l’association
Une université possède de une à plusieurs salle(s)
Une salle appartient à une et une seule université
Notation 0..1
Université numéro Salle
possède
Classe A Qualificateur Classe B

Une université possède au plus une salle ayant ce numéro
Une salle appartient à une et une seule université
Qualificateur = attribut1, …, attributN

113 114
Qualificateur d’association Classe associative

Exemples
Notation
• Une association peut être
matérialisée par une classe
dans une des circonstances Classe A Classe B
0..* Compte
Personne suivantes :
possède bancaire – si l’association est
porteuse d’attributs
Une personne possède de zéro à plusieurs compte(s) bancaire(s)
– si l’association se
Un compte bancaire appartient à une et une seule personne
matérialise par un objet Classe associative
concret dans le monde
réel
0..1
– si l’association est de
possède Compte multiplicité M .. N Exemple :
Personne agence
bancaire • Une classe associative est
une classe à part entière
Une personne possède de zéro à plusieurs compte(s) bancaire(s) par agence • Elle est modélisée par un lien
Un compte bancaire appartient à une et une seule personne en pointillé allant de la classe
vers l’association concernée
115 116
Classe associative Les différents types d’association
Exemples
Il existe plusieurs types d’association
• L’agrégation
Forme spéciale d’association entre un tout et une partie
• La composition
Forme spéciale d’agrégation où le cycle de vie de la partie est régi par
celui du tout
• L’héritage
Forme spéciale d’association permettant de factoriser les
caractéristiques et comportement communs à un ensemble de classes
• L’association simple
Ce sont les associations qui ne se réclament d’aucune des catégories
précédemment citées
117 118
Agrégation Agrégation
• Une relation particulière qui attribut à l'une des classes le rôle

• Une agrégation est une association non symétrique dans laquelle d'agrégat et à l'autre classe le rôle d'agrégé.
l’une des deux classes joue un rôle prépondérant • L'agrégation peut être assimilée à une appartenance - faible -.
• Une agrégation est une relation tout-partie entre un agrégat (le tout)
et un composant (la partie) Soit une configuration constituée d'un certain nombre d'éléments:
• L’agrégation est représentée par un losange blanc du côté de l’agrégat
• Le composant peut appartenir simultanément à plusieurs agrégats
• Le cycle de vie des composants n’est pas tributaire de celui de
l’agrégat
étudie
Personne Université - L'agrégation se modélise par un losange côté agrégat.
1..* 0..* - Une configuration comporte un clavier - ou aucun -, un écran - ou aucun - , et
éventuellement plusieurs disques
- L'agrégation traduit une relation d'appartenance de l'agrégé dans l'agrégat; elle
Une personne peut étudier dans aucune à plusieurs universités
n'induit aucune valeur de multiplicité particulière.
Une université peut accueillir de une à plusieurs personnes 119 - La disparition d'une configuration n'entraîne pas la disparition des périphériques. 120
Agrégation Composition
• Une composition est une agrégation à part entière (agrégation forte)

• La composition est représentée par un losange noir du côté de l’agrégat
• Le composant ne peut pas appartenir simultanément à plusieurs
agrégats (multiplicité 1 ou 0..1 côté agrégat)
- Une page peut contenir des images mais celles-ci peuvent appartenir à d'autres • Le cycle de vie des composants est tributaire de celui de l’agrégat
pages. • Si la multiplicité est 0..1 côté agrégat, le composant peut ne pas être
associé à l’agrégat immédiatement, mais une fois l’association effectué le
- La destruction d'une page n'entraîne pas celle de l'image mais seulement la composant vit et meurt avec l’agrégat
suppression du lien.
- Bien sûr nous aurons très souvent une cardinalité 1..1 ou 0..1 côté agrégat.
possède 1..*
- L'appartenance est dite faible car l'agrégé pourra participer à d'autres agrégats et Université Salle
son cycle de vie n'est pas subordonné à celui de son agrégat.
Une université est composée de une à plusieurs salles
121 Une salle n’appartient qu’à une et une seule université 122
Composition Composition
Remarque :
Commentaires : Exemple récapitulatif :

- La composition se modélise par un losange noir côté composé.
- Une application contient de 0 à n fenêtres qui contiennent de 0 à n boutons.
- La destruction (fermeture) de l'application entraîne la destruction des fenêtres
qui entraîne la destruction des boutons.
- La non-présence des valeurs de multiplicités est synonyme de 1..1
Commentaires :
Règles : - Le châssis est un élément indissociable d'une voiture, d'où la composition.
- Un composant ne peut appartenir à un moment donné qu'à un seul composé. - Le moteur et les roues peuvent être utilisés dans d'autres voitures.
- La cardinalité ne peut être que de 1 maximum coté composant. - Notez les valeurs 4..4 qui caractérisent plus précisément les valeurs de
- La suppression du composé entraîne celle du composant. multiplicité
- Les absences de cardinalité sont assimilable à 1..1
- L'association entre Voiture et Personne n'est pas nommée, cela est conseillé
123
lorsque son nom est trivial: "appartient", "concerne"... afin de ne pas alourdir le124
modèle, sans rien apporter à la sémantique.
Composition : abus de langage ! Généralisation / Spécialisation
• La généralisation /
spécialisation est une relation Notation
• Attention : on parle très souvent de composition pour désigner de classification entre une
une simple association entre deux classes. Cela se traduit par classe plus générale et une
l’existence d’un attribut qui référence une (des) instance(s) classe plus spécialisée Super-classe
d’une autre classe.
• On l’appelle aussi relation Spécialisation
d’héritage ou relation « est-
une-sorte-de » Généralisation
*
Personne Compte • La généralisation est
représentée au moyen d’une Sous-classe
flèche pointant de la classe la
Une personne possède des comptes mais n’est pas composée de comptes
plus spécialisée vers la
classe la plus générale
125 126
Généralisation / Spécialisation Classe et opération abstraites

Exemple
• Une classe abstraite est une

Compte classe pour laquelle il n’est pas
possible de créer d’instances
numéro
directement. Forme géométrique
solde
Son nom est écrit en italique.
getSolde() Dessiner()
• Une opération abstraite d’une
classe A est une opération ne
possédant pas d’implémentation
dans A mais qui doit
obligatoirement être implémentée
CompteCourant CompteEpargne dans les sous-classes de A.
Rectangle Rond
montantDécouvertAutorise tauxEpargne Sa signature est écrite en
italique.
Dessiner() Dessiner()
getDecouvert() calculerIntérêts()
• Toute classe contenant au moins
une opération abstraite est
127 abstraite. 128
Contraintes sur généralisation /
Discriminant sur relation d’héritage
spécialisation
• La spécialisation d’une
super-classe peut avoir lieu Il est possible d’exprimer deux types de contraintes prédéfinies
selon différents critères sur les sous-classes d’une généralisation :
simultanés.
Personne
• La contrainte de complétude
• Chacun de ces critères est
représenté par une chaîne sexe travail Précise l’état d’avancement de la classification proposée par la
de caractères et s’appelle généralisation / spécialisation.
un discriminant.
homme femme Etudiant Employé
• La contrainte de chevauchement
• Le discriminant est Contrainte ensembliste sur les instances de la sous-classe vis-
positionné à côté de la à-vis des instances de la super-classe.
sous-arborescence qu’il
qualifie.
129 130
Contrainte de complétude sur Contrainte de chevauchement sur

relation d’héritage relation d’héritage
• La contrainte de
chevauchement apporte des
• La contrainte de complétude Personne Personne
précisions sur la nature des
permet d’indiquer si la
instances de la super-classe
généralisation peut être
{complète} {disjoint}
étendue ou non
• {disjoint} indique que
Homme Femme l’ensemble des instances des Homme Femme
• {complète} indique que l’on
sous-classes forment une
ne peut plus ajouter de classe
partition de la super-classe
à l’arborescence
Mammifère Véhicule
• {chevauchement} indique
• {incomplète} indique que
qu’il peut exister des
l’arborescence peut être {incomplète} {chevauchement}
instances qui soient à la fois
complétée ultérieurement
instance de deux sous-
Chien Chat Loup classes Terrestre Marin
131 132
(Recommandations) (Recommandations)
• Toujours garder à l’esprit qu’un diagramme de classe propose • Dans la mesure du possible, éviter les discriminants dans les
une vision statique des données du problème. associations de type généralisation / spécialisation
• Les associations d’un diagramme de classes sont statiques, • Eviter l’utilisation des contraintes de chevauchement dans les
mais la création des liens entre objets est dynamique. associations de type généralisation / spécialisation
• Ne jamais hésiter à donner les multiplicités. • Privilégier la délégation à l’héritage
133 134
Sommaire
• Introduction
UML • Diagrammes d’interaction
• Interaction
(Diagramme d’objets, • Types de message
• Objectifs du diagramme de collaboration
Diagrammes d’interaction) • Diagramme de collaboration
• Objectifs du diagramme de séquence
Unified Modeling Language • Diagramme de séquence (branchement conditionnel, contraintes
temporelles)
• Objectifs du diagramme d’objets
• Diagramme d’objets
• Objet
• Objet composite
136
Diagrammes d’objets et
d’interaction
• Issus en grande partie de la méthode OMT (Rumbaugh) et de la

méthode Booch.
• S’appuient sur un diagramme de classe. Ils présentent les 1 – Les diagrammes d’interaction
relations et les interactions intervenant entre certains objets du
système.
• Le diagramme d’objets est très peu utilisé car redondant avec le

diagramme de classes.
• Le diagramme de séquence est très important car (a) il est très

descriptif et (b) il peut être facilement couplé à un cas d’utilisation.
137
Interaction
Diagrammes d’interaction
(Définition)
Une interaction est un ensemble d’objets

• Il existe deux types de diagrammes d’interaction : qui interagissent en s’échangeant des messages
– Le diagramme de collaboration
Il met l’accent sur la représentation spatiale d’une interaction
• Les objets d’un diagramme d’objets peuvent participer à une
interaction.
– Le diagramme de séquence
Il met l’accent sur la représentation temporelle d’une interaction
• Un diagramme d’interaction propose la même information qu’un
diagramme d’objets, en y ajoutant les envois de messages inter-
• Diagramme de collaboration et diagramme de séquence sont objets.
équivalents
139 140
Les types de message
• Deux objets qui communiquent peuvent le faire au moyen d’un

message
1.1 – Le diagramme de collaboration
• L’envoi d’un message peut provoquer :
– soit le déclenchement d’une opération sur l’objet récepteur
– soit l’émission d’un signal vers l’objet destination
(voir diagramme états-transitions)
– soit la création d’une instance
– soit la destruction d’une instance
141
Diagramme de collaboration Diagramme de collaboration

Exemple
• Un diagramme de collaboration est identique à un diagramme

d’objets auquel on ajoute des envois de message
Objectifs • Les messages sont représentés par des flèches numérotés pour
indiquer l’ordre des envois
• Montrer explicitement les interactions pouvant intervenir entre • Un élément extérieur au système, comme un acteur, peut figurer
des objets. dans un diagramme de collaboration
• Représenter les interactions en favorisant une vision spatiale

de celles-ci. MaBanque:Banque
1 : effectuerVirement
2 : débiter
• Préciser l’ordre dans lequel les interactions interviennent
sans avoir recours au temps. 3 : Créditer
MonCompteCourant:CompteCourant
MonCompteEpargne:CompteEpargne
143 144
Diagramme de séquence
Objectifs
1.2 – Le diagramme de séquence • Montrer explicitement les interactions pouvant intervenir entre
des objets
• Représenter les interactions en favorisant une vision

temporelle de celles-ci
• Préciser la chronologie des interactions en précisant les

contraintes temporelles
146
Objet du diagramme de séquence

Envoi de message
(Notation)
• Les envois de message sont

• Dans un diagramme de
Notation matérialisés par des flèches étiquetés Notation
séquence, on ajoute à l’objet un
par le nom du message envoyé
axe temporel représentant sa
ligne de vie
• 3 types de message : : Classe1 : Classe2
nomObjet: nomClasse – Message synchrone
• Cet axe temporel est matérialisé Message synchrone
l’objet émetteur envoie le message et
par une ligne pointillée sous
reste bloqué tant que le destinataire n’a
l’objet pas fini de traiter le message reçu Retour d’appel synchrone
– Message asynchrone
• Sur cet axe temporel Axe l’émetteur envoie le message et ne
apparaissent des bandes reste pas bloqué pendant le traitement Message réflexif
temporel du message par le destinataire
rectangulaires représentant les
périodes d’activité de l’objet – Message réflexif
Message asynchrone
l’objet s’envoie un message à lui-même
Retour asynchrone
• On considère que le temps
s’écoule du haut vers le bas
147 148
Diagramme de séquence Création, animation et destruction
Exemple d’un objet
• Représentation chronologique des envois de messages entre objets. • Certains messages ont une
• Possibilité d’exprimer de façon précise les contraintes temporelles signification bien précise : Notation
grâce à un axe gradué.
• Un élément extérieur au système, comme un acteur, peut figurer dans – Message « Créer »
un diagramme de séquence. message ayant pour nom : Classe1
« Créer », demandant la création
d’une instance. Créer
– Message d’activation : Classe2
: Client : ServeurWeb : Cuisinier message de nom quelconque qui
déclenche une bande d’activité
Afficher carte Message activation
chez une instance.
Passer cde – Message « Détruire »
Décrire cde message ayant pour nom
Réaliser plat « Détruire » demandant la Détruire
destruction d’une instance.
Donner • Une instance détruite voit sa
Envoyer message disponibilité bande d’activité s’achever par un
croix
149 150
Condition sur message Contraintes temporelles
• Il est possible de faire apparaître des branchements

• Tracer une flèche oblique
conditionnels sur un diagramme de séquence
pour représenter un délai de Notation
• Les conditions sont présentes sous formes de gardes entre [ propagation important
crochets ] entre deux objets. : Classe1 : Classe2
• Des contraintes X Message1

: Client : Serveur : Cuisinier : Barman temporelles sur l’axe
vertical peuvent être
ajoutées sous forme {Y-X >10s}
Message2
Passage cde textuelle entre {accolades}.
[Repas] Description cde Y
[Apéritif] Description cde
151 152
Les fragments combinés Les fragments combinés
• Un fragment combiné représente des articulations d'interactions. Il est

défini par un opérateur et des opérandes. L'opérateur conditionne la
signification du fragment combiné. Il existe 10 opérateurs définis dans
la notation UML2.0. Les fragments combinés permettent de décrire
des diagrammes de séquence de manière compacte.
• Alt : L'opérateur "alt" désigne un choix, une alternative. Il représente
deux (ou plusieurs) comportements possibles : c'est en quelque sorte
• Opérateurs : l'équivalent du SI...ALORS...SINON. Une seule des deux branches
» alt sera réalisée dans un scénario donné. La condition d'exécution d'une
» loop des deux branches (l'équivalent du SI) peut être explicite ou implicite.
» ref L'utilisation de l'opérateur else permet d'indiquer que la branche est
» opt exécutée si la condition du alt est fausse.
» break
153 154
Les fragments combinés
Le diagramme de séquences
Fragment Alt, Loop et ref
à ajouter • Loop : L'opérateur "Loop" (boucle) est utilisé pour décrire un
ensemble d'interaction qui s'exécutent 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.
else
156
à ajouter
• Ref : Une référence (appel de fonction) peut être vue comme un

pointeur ou un raccourci vers un autre diagramme de séquence
existant. Cela permet de factoriser des parties de comportement
utilisées dans plusieurs scénario.
159
à ajouter • Opt : L'opérateur "opt" désigne un fragment combiné optionnel
comme son nom l'indique. Il représente un comportement qui peut se
produire ou pas. Un fragment optionnel est équivalent à un fragment
"alt" qui ne posséderait pas d'opérande else (qui n'aurait qu'une seule
branche). Un fragment optionnel est donc une sorte de SI...ALORS.
162
• Break : L'opérateur "break" est utilisé dans les fragments combinés

qui représentent des scenarii d'exception en quelque sorte. Les
intéractions de ce fragment seront exécutées à la place des
intéractions décrites en dessous. Il y a donc une notion d'interruption
du flot "normal" des intéractions.
• L'exemple ci-après montre un opérateur "break" : L'utilisateur, lorsque
le distributeur lui demande son code, peut choisir de rentrer son code
ou de consulter l'aide. Si il choisit de consulter l'aide, le flot
d'intéraction relatif à la saisie du code est interrompu. Les intéractions
de l'opérateur break sont "exécutées".
163 164
2 – Le diagramme d’objet
165
Diagramme d’objets
Diagramme d’objets
(Définition)
Un diagramme d’objets est une instance

Objectifs
d’un diagramme de classes
représentant des objets et les liens qui les unissent
• Illustrer par un exemple concret un diagramme de classes
• Faciliter la validation d’un diagramme de classes complexe en • Un diagramme d’objets est un graphe représentant des
présentant une ou plusieurs instanciation de celui-ci instances de classe liées entre elles statiquement
• Visualiser un instantané de l’état d’un système • Un diagramme d’objet est conforme au diagramme de classes
qu’il illustre (vérifie les contraintes)
• Un diagramme d’objets ne montre pas les interactions entre

les objets
167 168
Objet Nom de l’objet
(Notation) (Notation)
• Le nom de l’objet peut être

Notation présenté selon trois formats Notation
• Un objet est représenté plus ou moins précis
par un rectangle découpé
nomObjet
en deux compartiments • Il peut contenir :
nomObjet : nomClasse
– Un nom optionnel identifiant
• Sont présents : nomAttribut1 = valeur1 l’objet de manière unique
Ou nomObjet : nomClasse
– le nom de l’objet … – Le nom optionnel de la
– la liste des attributs nomAttributN = valeurN classe à laquelle appartient
valorisés l’objet
Ou : nomClasse
• Le nom de l’objet est
souligné
169 170
Diagramme d’objets Objet composite

Exemple (Notation)
Diagramme de classes • Un objet composé de sous-

objets est appelé Notation
Personne Société composite
salarié
nom nomComposite : classeComposite
nom
* employeur
activité • Les objets composites sont
prénom
issus de classes liées par
: classePartie1 : classePartie2
une composition
Diagramme d’objets • Les attributs d’un objet

Philippe:Personne composite sont eux-mêmes
Nagora:Société
Ou
des objets
nom = Dupont
prénom = Philippe
nom = Nagora nomComposite : classeComposite
activité = SSII • Les sous-objets peuvent
Eric:Personne être représentés de
: classePartie1
manière graphique ou : classePartie2
nom = Durand textuelle
prénom = Eric
171 172
Objet composite Diagramme d’objets
Exemple (Recommandations)
Diagramme de classes
• Le diagramme d’objets ne doit être utilisé que pour clarifier
possède 1..* certaines structures complexes apparaissant sur un
Université Salle diagramme de classes
• Tous les objets du diagramme de classes ne doivent pas

Diagramme d’objets obligatoirement figurer sur le diagramme d’objets
Orsay : Université • Le diagramme d’objets peut servir de base à un diagramme

d’interaction
salle H123 : Salle
salle G246 : Salle
173 174
Diagrammes d’objets et d’interaction

(Recommandations)
• Utiliser le diagramme d’objets uniquement pour illustrer des

situations complexes d’un diagramme de classes
UML
• Ne pas mélanger diagramme de classes et diagramme d’objets
sur un même modèle (certains outils le permettent) (Diagramme états-transitions)
• Privilégier l’utilisation du diagramme de séquence à celle du
diagramme de collaboration, dès la phase d’analyse
• Ne pas mélanger des niveaux de détails différent sur le même

diagramme de séquence
175
Sommaire Diagramme états-transitions
• Apport en grande partie de la méthode OMT (Rumbaugh)

• Le diagramme états-transitions utilisé dans UML s’inspire
• Introduction largement des Statecharts de Harel
• Objectifs
• Diagramme états-transitions • Le diagramme états-transitions est utilisé pour modéliser un
• Etat d’un objet automate à états finis
• Evénement
• Transition entre états (Garde, action)
• Transition réflexive • Un automate à états finis (AF) est un modèle d'un système et
• Actions d’un état de son évolution, c'est-à-dire une description formelle du
• Activité d’un état système et de la manière dont il se comporte.
• Transition automatique • Un langage formel utilise un ensemble de termes et de règles
• Sous-états séquentiels syntaxiques pour permettre de communiquer sans aucune
• Sous-états concurrents ambiguïté
• Etat à historique
• Diagramme indispensable pour modéliser les systèmes
177 communiquant de manière asynchrone 178
Diagramme états-transitions
(Définition)
Objectifs
Le diagramme états-transitions est un automate à
• Définir les circonstances permettant le déclenchement des
traitements.
états finis décrivant les différents états par lesquels
Certains traitements sont tributaires de la survenue d’événements
passe une instance quelconque d’une classe
dans le système. en réponse à des événements
• Le diagramme états-transitions ne présente que les états significatifs
• Représenter les interactions asynchrones au sein du système. pour le problème posé
L’appel synchrone de fonctionnalité n’est pas toujours un moyen de
communication satisfaisant, en particulier pour les applications • Il ne montre que les transitions autorisées entre les différents états
de l’objet
industrielles ou temps-réel.
• Il donne des précisions sur les événements déclencheurs des
• Déterminer les états stables par lesquels passe le système. transitions
Parmi l’infinité d’états caractérisant un système, seuls quelques uns
• Il indique les traitements effectués par l’objet lorsqu’une transition est
sont significatifs pour le problème donné.
effectuée
179 180
Diagramme états-transitions Diagramme d’états-transitions
Exemple
• Un diagramme états-transitions est utilisé pour décrire le en activité âge légal de la

atteint la majorité
comportement type d’une instance quelconque d’une classe retraite
[ job trouvé ]
• Seules les classes ayant un cycle de vie significatif

nécessitent le recours au diagramme états-transitions embauche
à la retraite décès
perte
• Un diagramme états-transitions est utilisé pour modéliser le emploi
comportement d’objets actifs interagissant entre eux de
manière asynchrone atteint la majorité
[pas de job trouvé] âge légal de la
au chômage retraite
181 182
Etat d ’un objet

Etat d’un objet
(Définition)
• Un objet est caractérisé par un ensemble

Voiture
couleur : chaîne
L’état d’un objet est une configuration particulière
d’attributs année : entier des valeurs de ses attributs,
marque : chaîne
• Les attributs d’un objet changent de valeur significative pour le problème posé
au cours du temps
• Un objet possède autant d’états que de configurations possibles
Les valeurs des attributs d’un objet forment l’état de l’objet pour ses valeurs d’attributs
• Ce nombre peut être infini si le domaine de certains attributs

n’est pas discret
Voiture
couleur = «bleue» Voiture
année = 1980 couleur = «jaune»
peindre en jaune année = 1980
• Parmi la multitude d’états que peut posséder un objet, seuls
marque = «Renault»
marque = «Renault» certains d’entre-eux sont dignes d’intérêt
normale repeinte
183 184
Comment trouver les états Etat d ’un objet
significatifs d’un objet (Notation)
• En général, les états Pierre Pierre

âge = 12 âge = 34 • Un état est représenté
significatifs d’un objet au moyen d’un rectangle
peuvent être décelés en à coins arrondis
examinant :
Oui
« Mineur » Notation
– les valeurs de ses [ âge < 18 ] Non
« Majeur » • Le nom de l’état est
attributs qui satisfont positionné à l’intérieur
certaines conditions du rectangle
Ampoule
intéressantes pour le NomEtat
système Eclairer() • Le nom de l’état est en
– les activités qu’il exerce général un adjectif ou
« Allumée » « Eteinte »
dans le système une petite phrase le
– les événements sur décrivant
lesquels il est en attente
« Au départ » « En course » 185 186
Etat initial et état final d ’un objet Evénement

(Notation) (Définition)
• L’état initial indique le point Un événement est l’occurrence d’un stimulus

de départ par défaut du susceptible d’entraîner le déclenchement d’une réaction
diagramme états-transitions Notation au sein du système
• L’état initial est représenté Etat initial
par un point noir plein • La provenance de l’événement peut être aussi bien interne,
qu’externe au système
• L’état final indique que le
cycle de vie de l’instance • Un événement est par nature instantané et doit donc être
s’achève Etat final traité immédiatement
• L’état final est représenté

par un point noir encerclé • Un événement ne provoque pas systématiquement une
réaction de la part du système
187 188
Les différents types d’événement Signal émis par un objet
Il existe divers types d’événement :

• Un objet peut émettre un signal
• L’événement sur condition vers un autre objet Notation
Condition booléenne particulière dont la valeur passe à VRAI
ex : « le feu est vert » • A la différence de l’invocation
d’une méthode, un signal est « Signal »
asynchrone
• L’événement temporel User input
Ecoulement d’une certaine période de temps ou occurrence d’une
certaine heure / date définie • Les signaux peuvent être
ex : « Après (15 s) »
modélisés sur un diagramme de
classes à l’aide d’une classe « Signal » « Signal »
« Quand (date = ‘1er Janvier 2002’) » stéréotypée « Signal »
Bouton Souris Touche clavier
• Le signal • Un signal peut transporter des position caractère

Signal explicitement émis par un objet données
Ex : « Bouton Souris = down » Elles apparaissent comme attributs
189 de la classe 190
Transition entre états Transition entre états

• Une transition est modélisée sous la forme d’une flèche reliant

Une transition est une connexion orientée entre deux états, les deux états, étiquetée par une description textuelle de la
se déclenchant lorsque l’événement auquel elle est associée transition
est reçu par l’objet et
provoquant ainsi le passage d’un état vers l’autre • La description textuelle est constituée de trois éléments :
– Un événement déclencheur
• Une absence de transition entre deux états indique qu’il n’est – Une condition de garde
pas possible pour un objet de passer de l’un de ces états vers – Une action
l’autre
Notation
• L’état source est l’état dans lequel se trouve l’objet avant
l’apparition de l’événement Événement [ Garde ] / Action
NomEtatSource NomEtatCible
• L’état cible est l’état dans lequel se retrouve l’objet après la
survenue de l’événement
191 192
Garde sur transition Action d’une transition
(Définition et notation) (Définition et notation)
Une garde sur une transition est une condition booléenne Une action sur une transition est un traitement atomique
optionnelle qui doit être vérifiée pour que la transition exécuté lorsque la transition est déclenchée
puisse être déclenchée lors de la survenue de l’événement
• Une action peut comporter
• A la différence de l’événement sur condition, la garde est évaluée une - Des appels à des opérations de l’objet
seule fois (à la survenue de l’événement) - Des créations et destructions d’autres instances
- Des envois de signaux vers des objets (y compris lui-même)
• La garde est exprimée sous la forme d’un texte entre [ crochets ]
• Une action ne peut pas être interrompue par un événement et
s’accomplit totalement contrairement à une activité
Notation
60ème anniversaire [ a cotisé ] / Faire un pot()
60ème anniversaire [ a cotisé ] Salarié Retraité
Salarié Retraité
Mouvement détecté / Send(Problème) à Central
vigilance En alerte
193 194
Actions d’un état

Transition réflexive sur un état
(Définition)
• Une transition peut avoir pour état source et état cible un seul et Une action d’état est un traitement interne atomique
même état
associé à un état et dont les conditions de déclenchement
On parle alors de transition réflexive ou auto-transition
sont liées soit à la survenue d’un événement,
soit à l’entrée ou à la sortie de l’état
• Ce type de transition est utile lorsque l’on souhaite exécuter une
action tout en revenant dans le même état Un état peut comporter :
• Une action en entrée
A chaque fois que l’objet entre dans l’état, l’action est exécutée
Bouton « off » pressé Tic horloge / Emettre bip()
Notation • Un action en sortie
A chaque fois que l’objet sort de l’état, l’action est exécutée
Arrêt En marche
• Plusieurs actions internes sur événement
A chaque fois qu’un événement défini survient, une transition interne
est déclenchée et l’action associée est exécutée
Bouton « on » pressé 195 196
Actions d’un état Activité d’un état
Une activité d’état est une séquence interruptible

• Les actions associées à un état d’actions associée à un état et s’exécutant tant que
sont identiques à celles associées l’objet se trouve dans cet état
aux transitions Notation
• Les actions en entrée et en sortie • Chaque action composant l’activité est atomique (non interruptible
permettent de factoriser des et s’exécutant totalement)
NomEtat
traitements à effectuer
Elles sont précédées des mot-clés Entry / Action entrée • Par contre, la séquence est interruptible par un événement
« Entry » ou « Exit » Exit / Action sortie quelconque intervenant entre deux actions
Evénement1 / Action1
• Une transition interne n’a pas les • Une activité peut s’exécuter indéfiniment dans un état ou bien
EvénementN / ActionN
mêmes effets qu’une transition s’achever d’elle-même ou bout d’un certain temps
réflexive
• Après interruption consécutive à un événement, l’activité
redémarre si l’objet est resté dans le même état
197 198
Activité d’un état Activité et actions

(Notation) Exemple
• L’activité d’un état est

précédée du mot-clé « Do » Notation Activités de la journée
préparerCafé()
9h / préparerCafé()
• L’activité se déclenche une débrancherRépondeur()
fois que l’objet se retrouve travailler()
NomEtat
dans l’état associé à celle-ci Au bureau répondreTéléphone()
Entry / Action entrée travailler ()
Entry / débrancherRépondeur() ouvrirPorte()
• Si l’état possède une action en Exit / Action sortie
Exit / brancherRépondeur() travailler ()
entrée, celle-ci sera déclenchée Evénement1 / Action1 12h / manger()
brancherRépondeur()
avant que ne démarre l’activité téléphoneSonne / répondreTéléphone()
EvénementN / ActionN manger()
sonneriePorte / ouvrirPorte()
Do / Activité débrancherRépondeur()
• La survenue d’un événement Do / travailler() travailler ()
sur action interne interrompt répondreTéléphone()
l’activité le temps du 18h / prendrePain() travailler ()
traitement de l’action interne brancherRépondeur()
prendrePain()
199 200
Transition automatique Exemple de diagramme états-transitions
• Une transition peut ne pas avoir d’événement associé

On parle alors de transition automatique
• Une transition automatique se déclenche lorsque l’activité de son [resteArticleàVérifier]
[tousArticlesVérifiés&& EnLivraison
état source est terminée Vérification tousArticlesDisponibles]
• Une transition automatique peut être conditionnée par une garde do/démarrer
do/ vérifier livraison
article
[tousArticlesVérifiés&& ArticleReçu()
ArticlesManquants] livraison()
[tousArticlesDisponibles]
incident EnAttente
annulation()
Livré
Alerte ArticleReçu()
Repos [ResteArticlePasdeStock] annulation()
do / émettre_alarme()
Annulé
Exercice Contrat Page. 8/15
[ incident non résolu ] [ incident résolu ]
201 Tourniquet badge et ticket
Exercice état transition corréction .docx
Sous-états d’un état

Sous-états séquentiels
(Définition)
• L’état composé possède un nom et embarque en son sein les

Un état composé est un état dans lequel viennent sous-états
s’emboîter d’autres états que l’on appellent sous-états • Les sous-états participent à un diagramme états-transitions
classique
• A un instant donné, un objet ne peut se trouver que dans un
• Par opposition, on parle d’état simple lorsque l’état n’a pas de seul des sous-états séquentiels
structure interne
Notation
• Il existe deux catégories de sous-états :
– Les sous-états séquentiels NomEtatComposé
L’objet ne peut se trouver que dans un seul de ces sous-états à un
Événement [ Garde ] / Action
instant donné
– Les sous-états concurrents NomSousEtat1 NomSousEtatN
L’objet se trouve dans les deux sous-états à un instant donné
203 204
Sous-états séquentiels Sous-états séquentiels
• L’utilisation d’états composés Marche avant Marche arrière

permet de factoriser les
transitions entre états • Il est possible d’avoir des
collision Point mort collision Calée
sous-états qui
• Cette facilité est
collision
démarrer communiquent coup de frein coup de frein
particulièrement intéressante Accidentée directement avec des
pour représenter les états extérieurs En service
traitements de cas d’erreur
Marche avant Marche arrière
En service • Le cas se présente
• Il est aussi possible de désigner lorsqu’une transition ne
le sous-état initial d’un état Marche avant Marche arrière Point mort
peut pas être généralisée à
composé
Point mort
l’ensemble des sous-états
collision Accidentée démarrer
• Toute transition arrivant sur
l’état composé fait passer l’objet collision Accidentée démarrer
dans le sous-état initial 205 206
Sous-états séquentiels Sous-états séquentiels
• Un sous-état peut lui même

Calée
• L’état final de l’objet peut explosion explosion
être re-décomposé en sous- se trouver dans un sous-état Calée
états séquentiels si l’événement entraînant la
coup de frein
destruction se produit explosion coup de frein
• Le cas se présente par En service uniquement lorsque l’objet En service

exemple lorsque l’on souhaite En marche est dans ce sous-état
factoriser des transitions En marche
associées à ce sous-état Marche avant Marche arrière
• Il est cependant Marche avant Marche arrière
recommandé de faire
• A un instant donné et pour un Point mort apparaître l’état final au Point mort
niveau donné, un objet se
trouve dans un seul des sous-
plus haut niveau de la
états séquentiels collision Accidentée démarrer hiérarchie d’états de l’objet Accidentée
collision démarrer
207 208
Sous-états séquentiels
Sous-états concurrents
Exemple
• Ce type de sous-état permet de décrire deux ou plusieurs automates à

états finis qui fonctionnent en parallèle au sein d’un même objet
Démarré
• A un instant donné, un objet se trouve dans un sous-état séquentiel de
Marche avant chacun de ses sous-états concurrents
• Une autre dénomination de sous-état séquentiel est région
2nde
Calé monter descendre monter descendre
Notation
3ème 5ème
1ère NomEtatComposé
freiner Région 1
descendre monter descendre monter NomSousEtatConcurrent1
4ème
Événement [ Garde ] / Action
NomSousEtat1_1 NomSousEtat1_N
freiner enclencher débrayer Région N
NomSousEtatConcurrentN
enclencher
Point mort Marche arrière Événement [ Garde ] / Action
NomSousEtatN_1 NomSousEtatN_N
209 210
Sous-états concurrents Sous-états concurrents
• Il est possible de synchroniser un ou plusieurs sous-états

• Une transition vers l’état séquentiels
Suivi
composé déclenche toutes • On utilise pour cela des fourches et des jonctions
les transition des états effectué
effectué
TP1 TP2
initiaux
effectué effectuée
Installation Inspection
• Un état final dans une région Projet études Soutenance fondations travaux
traduit la fin de l’activité de

la région Examen final
succès En construction
• Une transition automatique échec

Installation Installation
murs Installation
ayant pour origine l’état inscription
porteurs toiture
murs
intérieurs
composé peut se déclencher
Raté Réussi
lorsque les activités de toutes
les régions sont terminées Installation Installation Installation
électricité électricité électricité
fondations murs porteurs extérieure
211 212
Etat à historique
(Recommandations)
• Un état à historique est un état

composé capable de se • Ne faire les
Allumée Créée
souvenir de son dernier sous-état diagrammes états-
actif en cas de transition vers transitions que pour les
l’extérieur Lecture CD Lecture cassette classes ayant un
Mise à jour
comportement
• L’état initial est remplacé par un Tuner significatif dans le
cercle entourant la lettre ‘H’ système
Détruite
H
• Si le H est accompagné d’une • Un diagramme à états-
« * » tous les sous-états sont Bouton « off » transitions est un
sauvegardés quelque soit la automate à états finis
profondeur Eteinte A
Bouton « on »
déterministe evt evt
• Une transition pointant sur ce
cercle fait passer l’objet dans La première fois la chaîne stéréo B C
l’état sauvegardé s’allume en mode Tuner
213 214
Diagramme d’activités
• Apport en grande partie de la méthode OMT (Rumbaugh).

UML
(Diagramme d’activités) • Alors que les diagrammes d’interaction modélisent le flot de
contrôle entre objets, le diagramme d’activités est utilisé pour
modéliser le flot de contrôle entre activités.
• Possibilité de l’utiliser pour décrire des processus métier de haut
niveau (= équivalent du MOT MERISE).
216
Le but du diagramme d’activité Diagrammes d’activités
• Diagramme d’activité est utilisé pour : • Un diagramme d’activités peut être utilisé pour décrire une
– Modéliser un workflow dans un use case ou entre fonctionnalité induisant un flot de contrôle traversant le système.
plusieurs use cases. En particulier, il est une alternative aux diagrammes d’interaction
pour la description d’un cas d’utilisation.
– Spécifier une opération (décrire la logique d’une
opération).
• Un diagramme d’activités peut être utilisé pour décrire avec
• Le diagramme d’activité est le plus approprié pour précision le contenu d’une opération d’une classe.
modéliser la dynamique d’une tâche, d’un use case
lorsque le diagramme de classe n’est pas encore
stabilisé. • Un diagramme d’activités peut être utilisé pour décrire avec
précision une activité incluse dans un diagramme états-
transitions.
217 218
Diagrammes d’activités
Diagramme d’activité
(Définition)
Le diagramme d’activité est un diagramme états-transitions Diagramme d’activité =

simplifié pour lequel les états se réduisent à de simples • ensemble d’activités liés par :
actions ou activités et dont les transitions se déclenchent – Transition (séquentielle),
automatiquement avec éventuellement des gardes
– Transitions alternatives (conditionnelle),
• Le diagramme d’activité est composé de deux sortes d’états : – Synchronisation (disjonction et conjonctions
d’activités),
– Les états d’action ne contenant qu’une action en entrée.
– Les états d’activité ne contenant qu’une activité en leur sein.
– Itération.
• + 2 états : état de départ et état de terminaison.
• Les notions d’action et d’activité dont il est question ici sont • Swimlanes (Couloirs) : représente le lieu, le
identiques à celles utilisés par les diagrammes états-transitions. responsable des activités.
219 220
Diagramme d’activité Diagramme d’activité
•Etat de départ
•Etat de terminaison
•Transition
•Transition Alternative
Synchronisation
[ ]
disjonctive et
[ ]
conjonctive
221 222
Exemple
• Une transition sur un diagramme

Choisir terrain d’activités est représentée par une Choisir terrain
flèche éventuellement étiquetée par
une garde
• Un branchement conditionnel est
représenté par un losange d’où Choisir maison Voir notaire
partent toutes les alternatives
Choisir maison Voir notaire
obligatoirement exclusives
[trop cher] [abordable]
• On utilise des fourches et des
[trop cher] [abordable] jonctions pour synchroniser les
activités entre-elles Voir banquier
• Etat initial et final peuvent être
représentés sur le diagramme
Chercher location Voir banquier
223 224
Diagramme d’activité Diagramme d’activité
Swimlanes
Itération
225 226
Couloirs d’un diagramme

Sous-diagramme d’activités
d’activités
• Chaque Client Commercial Magasinier Sous-diagramme
couloir • Un état activité figurant sur un Choisir terrain
possède un Passer commande diagramme d’activité peut être

nom re-décomposé dans un sous- Choisir maison Voir notaire
diagramme d’activité [trop cher] [abordable]

• Il n’est pas
obligatoire Enregistrer commande Voir banquier
que ce nom • La terminaison du sous-

ait une diagramme entraîne le
sémantique Payer Exécuter commande déclenchement de la transition
particulière en sortie de l’activité
décomposée
Etudier
• En général, projet
Livrer commande
un couloir
correspond à
une classe du Prendre
système Récupérer commande décision
227 228
Construction d’un diagramme Diagrammes d’activités
d’activité (Recommandations)
1. Identifiez la portée (« scope ») du diagramme d'activité :
Commencez en identifiant ce que vous allez modéliser. Un seul
use case? Une partie d'un use case ? Un « workflow » qui inclut
plusieurs use cases ? Une méthode de classe ?
• Utiliser le diagramme d’activité pour décrire un processus métier
2. Ajouter l’état de départ et de terminaison. de haut niveau (= équivalent du MOT MERISE).
3. Ajouter les activités : Si vous modélisez un use case, • Ne pas utiliser le diagramme d’activités si l’on souhaite
introduisez une activité pour chaque use case principal. Si vous modéliser des interactions asynchrones entre objets.
modélisez un « workflow », introduisez une activité pour chaque
processus principal, souvent un use case. Enfin, si vous
modélisez une méthode, il est souvent nécessaire d’avoir une • Préférer le diagramme d’activités à un diagramme d’interaction
activité pour chaque grand étape de la méthode. pour décrire un cas d’utilisation purement algorithmique (cas
des batchs).
4. Ajouter des transitions (séquentielles), des transitions
alternatives (conditionelles), des synchronisations entre des
activités, des itérations. • Privilégier l’utilisation d’un pseudo-code pour décrire les
algorithmes trop imposants.
5. Identifier des swimlanes et répartir des activités identifiées dans
ces swimlanes. 229 230
Sommaire
• Introduction
UML • Objectifs du diagramme de composants
(Diagramme de composants, • Diagramme de composants
• Composant
Diagramme de déploiement) • Interface
• Objectifs du diagramme de déploiement
• Diagramme de déploiement
• Nœud
• Connexion
• Instance de nœud
232
Diagrammes de composants et de
Diagramme de composants
déploiement
• Issu en grande partie de la méthode OMT (Rumbaugh) et de la

méthode Booch Objectifs
• L’utilisation d’un diagramme de composants n’est envisageable • Visualiser l’organisation physique générale d’un système
que pour de petites applications ce qui en fait un modèle très décrite en terme de composants logiciels
peu utilisé
• Présenter les dépendances unissant les différents constituants
• Le diagramme de déploiement est en général utilisé en phase logiciels du système
de Conception générale où il permet de décrire l’architecture
technique générale • Etablir les différentes configurations liant les éléments
physiques logiciels du système
233 234
Diagramme de composants Diagramme de composants

(Définition) Exemple
Un diagramme de composants est un diagramme Banque.h
représentant l’organisation et les dépendances liant {version=3.1}
les éléments physiques logiciels d’un système
Compte.h
• Un diagramme de composants propose une vision statique de
{version=2.2}
l’organisation des éléments physiques logiciels du système
Banque.cpp
{version=3.1}
• Un diagramme de composants montre les dépendances
existant entre les composants physiques logiciels du système
Client.h Entreprise.h
{version=1.0} {version=1.2}
• Un diagramme de composants ne montre pas les interactions
entre les composants physiques logiciels
235 236
Composant Composant
Un composant est un élément physique logiciel Notation

interchangeable d’un système qui fournit • Un composant est
l’implémentation d’un ensemble d’interfaces représenté par un rectangle
avec des onglets << Stéréotype >>
• Un composant est l’implémentation physique logicielle d’un Nom paquetage :: Nom composant
ensemble d’éléments logiques (classe ou collaboration) • Le nom du composant peut
être précédé du nom du
• Un composant propose un ensemble d’interfaces qu’il se doit de paquetage qui le contient Réalise
respecter Nom Elément logique 1
• Il est possible de développer Nom Elément logique N

• Un composant peut être remplacé par un autre composant
le composant de façon à
respectant les mêmes interfaces
faire apparaître le nom des
éléments logiques qu’il
• Un composant peut être un exécutable, une librairie, une table, un implémente
fichier source, un document, …
237 238
Interface d’un composant Interface d’un composant

• Une interface peut être représentée sous la forme d’une icône

Une interface est un ensemble d’opérations servant (rond) ou sous une forme développée présentant les opérations
à spécifier un service proposé par un composant ou par une classe
• Il est possible de représenter l’exportation et l’importation d’une
interface par un composant
• Une interface peut être associée aussi bien au niveau logique
(rare) qu’au niveau physique
Client.java Compte.java
• L’interface contient les opérations mises à la disposition des
autres composants
GestionCompt
e
• Un composant peut implémenter plusieurs interfaces
Client.java << Interface >> Compte.java
GestionCompt
e
• Un composant se doit de proposer une implémentation pour
Ouvrir(int)
chacune de ses interfaces Déposer(int)
239 Retirer(int) 240
Diagramme de déploiement
Diagramme de déploiement
(Définition)
Un diagramme de déploiement est un diagramme de classes

Objectifs
ou un diagramme d’objets représentant les nœuds
ou les instances de nœuds sur lesquels le système s’exécute
• Etablir la cartographie complète de déploiement du logiciel sur
le matériel
• Un diagramme de déploiement propose une vision statique de
• Visualiser la topologie matérielle d’un système la topologie du matériel sur lequel s’exécute le système
• Etablir la nature des connexions reliant les éléments matériels • Un diagramme de déploiement montre les associations
du système (connexions) existant entre les nœuds du système
• Un diagramme de déploiement ne montre pas les interactions

entre les nœuds
241 242
Diagramme de déploiement Noeud

Exemple (Définition)
Un nœud est un élément physique matériel sur lequel

le système s’exécute
<<processor>> <<processor>> <<processor>>
Serveur Web Serveur Applicatif Serveur de

données
Mémoire=128 meg Mémoire=256 meg

• Un nœud est un élément matériel sur lequel sont déployés un
Mémoire=256 meg certain nombre de composants logiciels du système
<<network>> • Un nœud est un élément matériel sur lequel sont exécutés un

Réseau local certain nombre de composants logiciels du système
• Un nœud peut être un processeur, un périphérique, un réseau

<<processor>>
Proxy
• Un nœud est assimilable à une classe et possède donc des
Mémoire=128 meg
attributs
243 244
Noeud Connexion entre nœuds
• Un nœud est représenté par Une connexion est une connexion physique
un cube Notation
reliant deux nœuds entre-eux
• Le nom du nœud peut être
précédé du nom du • Une connexion entre deux nœuds est l’équivalent d’une
paquetage qui le contient << Stéréotype >> association entre deux classes sur un diagramme de classes
Nom paquetage :: Nom nœud
• Il est possible de développer • Exemples de connexion :
le nœud de façon à faire Nom attribut 1: type1
– une connexion Ethernet,
apparaître le nom de ses Nom attribut N : typeN – une ligne série,
attributs
– un bus partagé,
Déploie – …
• Il est possible de développer
le nœud de façon à faire Nom Composant 1
apparaître le nom des Nom Composant N
composants qu’il déploie
245 246
Diagrammes de composants et de
Instance de nœud
déploiement
(Notation)
(Recommandations)
• On peut représenter des Notation • Le diagramme de composants peut s’avérer très difficile
instances de nœuds dans un d’utilisation pour un logiciel complexe. Lui préférer alors une
diagramme de déploiement description textuelle de l’architecture des composants
« objet »
<< Stéréotype >>
• Le diagramme de déploiement est indispensable en phase de
• Une instance de nœud est Nom instance :: Nom nœud
représenté par un cube Conception générale. Il n’est pas assez utilisé…
Nom attribut 1 = valeur1
• Le nom de l’instance d’un • A la différence des diagrammes de classe et d’objets, il peut
Nom Composant N = valeurN
nœud est composé d’un être intéressant de mélanger nœuds et instances de nœud
identifiant de l’instance suivi sur une diagramme de déploiement
du nom du nœud Déploie
Nom Composant 1
• Les attributs de l’instance Nom Composant N
apparaissent valorisés
247 248
Sommaire
• Introduction
• Objectifs
UML • Paquetage
(Paquetage) • Espace de nommage d’un paquetage
• Dépendances entre paquetages
250
Paquetage Paquetage
Objectifs
• Notion introduite véritablement par UML car superficiellement • Décomposer un système complexe selon une organisation
décrite par OMT (module, sheet) et par Booch (subsystem ) hiérarchique
La meilleure façon d’aborder les gros systèmes consiste à les
• Le paquetage est uniquement un élément d’organisation et n’a décomposer en sous-systèmes élémentaires
pas de réalité concrète dans le système physique final
• Structurer un système complexe selon une organisation
• Notion fondamentale pour la gestion de gros systèmes modulaire
nécessitant la mise en place d’une organisation hiérarchique Le paquetage permet de mettre en œuvre un découpage en
et répartie couches, soit à base d’interfaces client/serveur, soit selon les
différentes vues architecturales du système
251 252
Paquetage
Paquetage
(Définition)
Objectifs (suite)
Un paquetage est un regroupement d’éléments
• Répartir l’effort de modélisation sur l’ensemble des acteurs de modélisation
impliqués dans la construction du système
Un gros système nécessite la participation de nombreux
intervenants sur lesquels il faut répartir la charge de travail • Un paquetage permet de regrouper sous une même appellation
un ensemble d’éléments de modélisation UML tels que :
• Répartir les tâches de modélisation selon les compétences – des classes, des composants, des nœuds, des collaborations, des
de chacun cas d’utilisation, …
Le paquetage favorise la mise en place d’une organisation où – des diagrammes de classes, de collaboration, de séquence, de cas
l’on attribue à chaque intervenant une unité de travail répondant d’utilisation, …
à ses compétences – d’autres paquetages
253 254
Paquetage
Paquetage
Exemple
• Un paquetage est susceptible de contenir n’importe quel

élément de modélisation UML
• Dans la pratique on utilise les paquetages :

Gestion « import » Gestion
– Pour regrouper au sein d’une même entité, un diagramme de cas commerciale utilisateurs
d’utilisation, les diagrammes de collaboration ou de séquence
associés, le diagramme de classes et les diagrammes états-
transitions correspondant
« import »
Il apparaît alors comme un dossier dans une arborescence de « import »
fichiers
– Pour décomposer des hiérarchies de classes dans les diagrammes
de classe « import »
Gestion Gestion
Il possède donc une représentation graphique associée produits fournisseurs
• Le type de la relation qui unit les éléments à leur paquetage est

de type composition 255 256
Paquetage Espace de nommage d’un
(Notation) paquetage
• Un paquetage est représenté par un Notation

dossier contenant un nom
• Un paquetage forme un espace de nommage
• Le nom du paquetage peut être

• Le nom des éléments d’un paquetage doit être unique au sein
préfixé par le nom du paquetage qui NomPaquetagePère::NomPaquetage
du paquetage
le contient
• Le nom d’un élément au sein de paquetages imbriqués est

• Le contenu du paquetage peut être
préfixé par tous les paquetages englobant
exposé
Nom Paquetage ex : GestionProduits::Catalogue::Boulon
• Les éléments constituant le +élément1

paquetage donne la visibilité +élément2
(privée, publique, protégée) qu’ils #élément4
affichent vis-à-vis de l’extérieur -élément3
257 258
Dépendances entre paquetages

Dépendances entre paquetages
(Notation)
• Une dépendance amie est

Il existe 4 types de dépendances entre paquetages :
étiquetée par « friend »
Notation
• Une dépendance
• Les dépendances amies
d’importation est étiquetée
Accès à tous les éléments d’un paquetage quelque soit leur visibilité
par « import »
« friend »
• Une dépendance d’accès A B
• Les dépendances d’importation
est étiquetée par
Importation d’éléments dans l’espace de nommage en tenant compte « access »
des visibilités
• Une dépendance de « access »
généralisation utilise la
• Les dépendances d’accès
flèche de généralisation
Accès à des éléments en tenant compte de leur visibilité
« import »
C D
• Les dépendances de généralisation
Généralisation / spécialisation de paquetage
259 260
Paquetage
(Recommandations)
• Penser à utiliser les paquetages pour structurer votre projet

UML
• Penser que le paquetage permet de hiérarchiser des
diagrammes (classes, cas d’utilisation, …), mais aussi de
(Mécanismes d’extension d’UML)
regrouper un ensemble de diagrammes entre eux
• L’utilisation du paquetage est fondamentale pour la mise en
place d’une démarche système
261
Sommaire Mécanismes d’extension d’UML
• Introduction
• Objectifs
• Les mécanismes d’extension sont essentiels car ce sont eux
• Note
qui garantissent l’ouverture du langage et son adaptabilité à
• Stéréotype de nouvelles problématiques
• Etiquette
• Contrainte • Mécanismes à utiliser avec précaution et parcimonie à ne
• Extensions standard mettre entre les mains que des responsables méthodes
• Invariant, pré-condition, post-condition
• OCL
263 264
Mécanismes d’extension d’UML Mécanismes d’extension d’UML
UML fournit 4 mécanismes d’extension du langage :

Objectifs
• Les notes
Apport d’un commentaire n’ayant aucune conséquence sur la
• Augmenter la portée du langage dans des directions bien sémantique du modèle
maîtrisées
Les concepts standard proposés par UML peuvent être • Les stéréotypes
insuffisants pour modéliser certains problèmes complexes
Création de nouveaux concepts UML à partir des concepts standard
• Adapter le langage à des habitudes et méthodes de • Les étiquettes (tagged values)

développement particulières Extension des propriétés associées à un concept UML
Certains corps de métier ou certaines entreprises possèdent
une culture de développement qui leur est propre • Les contraintes
Extension de la sémantique d’un concept UML en ajoutant de nouvelles
règles ou en modifiant les anciennes
265 266
Mécanismes d’extension standard Note

d’UML (Définition)
Une note est un commentaire textuel ou graphique

• UML fournit des stéréotypes, des étiquettes et des contraintes que l’on attache à un élément ou à un ensemble d’éléments
standard :
– stéréotype : extend, use, import, executable, process, thread, … • Une note ne modifie pas la sémantique du modèle
– étiquette : persistance, sémantique, … • Elle est représentée par un rectangle écorné lié par un ou
– contrainte : sous-ensemble, ordonné, ou, disjoint, chevauchement, plusieurs traits pointillés aux éléments qu’elle commente
complète,…
• UML permet de définir ses propres stéréotypes, étiquettes et

contraintes Les attributs et les
méthodes de ces classes
seront définies en phase
de Conception
Cf. Guide méthode
Client http://wwww.nagora.com/
projetY/conception.html
Compte
267 268
Stéréotype Etiquette
(Définition) (Définition)
Un stéréotype est une chaîne de caractères Une étiquette est une chaîne de caractères
qui associée à un élément UML existant qui associée à un élément UML permet
permet de désigner un nouveau type d’élément UML de lui ajouter une propriété et sa valeur associée
• Un stéréotype apparaît entre « guillemets » près du nom de l’élément • L’étiquette apparaît entre {accolades} et précise le nom de la propriété et
stéréotypé sa valeur
• On peut représenter un stéréotype au moyen d’une nouvelle icône • Utiles pour la génération de code ou la gestion de configuration
<<Métier>> <<Technique>>
Client Connexion BD Utilisateur
Une représentation
textuelle et une
représentation graphique nom { persist = Oui } Serveur
d’une classe stéréotypée
{ processeurs = 4 }
Client prénom { persist = Oui }
durée connexion { persist = Non } Gestion utilisateurs
{ version = 2.1 }
<<Sous-système>>
Gestion utilisateurs
269 270
Contrainte Invariant, pré-condition, post-

(Définition) condition
Une contrainte est une chaîne de caractères • Il existe 3 contraintes standard stéréotypées méritant d’être
qui associée à un élément UML permet d’ajouter citées ci :
de nouvelles règles ou de modifier des règles existantes
– La contrainte stéréotypée « invariant »
• La contrainte apparaît entre {accolades} et définit la règle à appliquer Il s’agit d’une contrainte attachée à un ensemble de classes ou de
• On peut utiliser du texte informel ou recourir à l’utilisation d’un langage plus relations et dont la condition associée doit toujours être vérifiée
précis comme OCL (Object Constraint Language) dans le temps par les instances ou les liens des éléments attachés
– La contrainte stéréotypée « pré-condition »
{ dont un compte
chèque } Il s’agit d’une contrainte attachée à une opération d’une classe et
Utilisateur * Compte Employé dont la condition doit être vérifiée pour que l’opération puisse être
parrainé
invoquée
type ancienneté
*
– La contrainte stéréotypée « post-condition »
* Il s’agit d’une contrainte attachée à une opération d’une classe et
parrain
dont la condition doit être vérifiée après l’invocation de l’opération
{ sécurisé }
Client Serveur
{ self.parrain.ancienneté > 1an }
271 272
Object Constraint Language Object Constraint Language
• OCL est un langage formel pour exprimer des contraintes OCL est utilisé pour
• OCL est un langage facile à lire et à écrire
• OCL n’est pas un langage de programmation • Spécifier des contraintes générales sur les classes, les
– Pas de logique de programme associations et les opérations
– Ne sert pas à décrire des flots de contrôle • Spécifier des invariants sur les classes et les associations
• OCL est un langage d’évaluation d’expression • Spécifier des pré / post conditions sur les opérations
– Une expression retourne une valeur qui n’est pas nécessairement • Décrire des gardes
booléenne
• Naviguer dans les diagrammes
• OCL est un langage typé
– Integer, Real, Boolean, String, Enumeration, Collection, Set, Bag
273 274
Object Constraint Language

Object Constraint Language
Exemples
• Context Personne
• On associe à une expression OCL Personne inv : self.ancienneté > 0
un contexte d’application, soit
avec un lien de dépendance, soit • Context Personne::setPrimeAncienneté()
en utilisant le mot-clé « Context » post : self.ancienneté > 1 AND result = self.ancienneté * 1500
• On peut préciser la nature de la • Context Société

contrainte : invariant, pré/post {self.âge > 18}
inv : self.employeur.auChômage=False
condition … inv : self.employé->notEmpty (redondant avec multiplicité)
1..*
{ Context Personne inv : employé
self.âge > 18 } Société Personne
ancienneté {Ou - exclusif} auChômage
setPrimeAncienneté()
275 employeur 276
UML
(Les patrons de conception)

Uml Cours EMS DAOUDI Imane

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

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 :

Formats disponibles

Uml Cours EMS DAOUDI Imane

Transféré par

Droits d'auteur :

Formats disponibles

Introduction à la modélisation

Conception Orientée Objet

Introduction à la modélisation Introduction à la modélisation

En génie logiciel, divers travaux ont mené à la définition de la qualité

Modélisation, cycles de vie et méthodes Modélisation, cycles de vie et méthodes

• Le cycle de vie d'un logiciel, désigne toutes les étapes du

Modélisation, cycles de vie et méthodes Modélisation, cycles de vie et méthodes

• Ce modèle est beaucoup plus général que le précédent. Il met

1. Détermination, à partir des résultats des cycles précédents, ou

Méthodes d'analyse et de conception :

Dans la stratégie fonctionnelle (structurée) un système est vu

Les méthodes fonctionnelles (également qualifiées de méthodes

Un objet est caractérisé par plusieurs notions :

• Ecrit en ces termes, notre logiciel sera plus

• Les modifications que nous avons apporté à notre logiciel de gestion de

Approche orientée objet Approche orientée objet

Polymorphisme : Polymorphisme – exemple :

Approche orientée objet Approche orientée objet

Agrégation : Résumé sur les concepts fondateurs de l'approche

UML - Unified Modeling Language

Genèse d’UML UML est une notation

• UML propose un cadre pour l’Analyse et la Conception orientée

• UML est fondé sur un métamodèle, qui définit :

UML n’est pas une méthode Plusieurs niveaux de modélisation

• Axe structurel / statique

Cas d’utilisation (Use Cases) Cas d’utilisation

• Une interaction en provenance de l’extérieur déclenche un flot

• Servir de support de référence tout au long des phases de Déposer argent

• Un cas d’utilisation est Notation

Comment déterminer les cas

Se poser les questions suivantes :

• « Pierre utilise le système pour gérer son agenda »

• Un acteur est représenté Notation Se poser les questions suivantes :

Le diagramme des cas Notation

• Permet de définir de manière précise les frontières du système

extérieur - les dépendances entre

Interaction entre acteur et cas Dépendances entre cas

Il existe 3 types de dépendances entre use cases :

• Indique qu’un cas Notation Notation

systématiquement et Cas d’utilisation 1

« include », pointant vers Acteur 1

Dépendance d’utilisation Dépendance d’extension

• Indique qu’un cas Notation

• Permet de décomposer « include » Authentifier

• Le cas d’utilisation étendu Notation

composé d’un nom suivi Cas d’utilisation 2

d’un numéro d’étape « extend »

(emplacement) • Est représentée par une

Dépendance de généralisation Scénario

• Permet de factoriser un Notation « include »

d’utilisation proches • Un cas d’utilisation propose aussi un ou plusieurs

• Ne pas décomposer trop finement les cas d’utilisation.

• Compléter le diagramme de cas d’utilisation par un diagramme

• Faire figurer uniquement les acteurs en interaction avec les cas

• Les dépendances entre cas d’utilisation ne traduisent pas un

Diagramme de classes Diagramme de classes

Objectifs Objectifs (suite)

Le diagramme de classes est un diagramme

• Il permet de représenter les associations statiques entre les

Une classe est une abstraction de choses

• La classe est la fabrique, le moule, à partir duquel on fabrique

• Seules les caractéristiques pertinentes pour le problème

• Une classe est Notation • Le nom de la classe