UML Version PDF Livre-1

Université Hassan II de Casablanca
Ecole supérieure de Technologie

Département Génie Informatique
DUT & LICENCE
Ingénierie des Systèmes

d’Information
-
Unified Modeling Language
(U M L )
Pr. Nadia AFIFI

A
AVVA
ANNTT--P
PRRO
OPPO
OSS
L’information se présente sous trois formes: les données, les connaissances
et les messages. On a l’habitude de désigner par «système d’information»
l’ensemble des moyens techniques et humains qui permet de stocker, de
traiter ou de transmettre l’information. On dira donc qu’un Système
d’Information est «tout moyen dont le fonctionnement fait appel d’une façon
ou d’une autre à l’électricité et qui est destiné à élaborer, traiter, stocker,
acheminer, présenter ou détruire l’information» (AGI n°900/SGDN). Ainsi,
l’objectif du Système d’Information(SI) est de rendre possible la mise en
commun d’informations appartenant à des sources séparées.
L’élaboration des SI fait appel à des méthodes et des langages de

modélisation afin de les concevoir et de pouvoir les réaliser par la suite. La
conception classique qui se base sur la décomposition fonctionnelle des
systèmes (devenus de plus en plus complexes) n’est plus capable de suivre
les évolutions incessantes des technologies et des besoins applicatifs. Donc
l’approche objet est devenue incontournable dans le cadre du
développement des systèmes logiciels complexes. L’approche objet requiert
de modéliser avant de concevoir.
Dans ce support on présente de façon simplifiée les différents concepts du

langage de modélisation UML. Le Langage propose uniquement une
notation dont l’interprétation est définie par un standard, mais pas une
méthodologie complète ; Alors qu’une méthode de développement définit à la
fois un langage de modélisation et la marche à suivre lors de la conception.
C’est un langage de modélisation fondé sur des événements et ou
messages. Ce n’est pas un langage formel ni un langage de programmation.
L’objectif de ce cours est de fournir une référence des concepts de base

d’UML 2.x. Il est composé de sept chapitres qui peuvent être lu séparément,
Chaque chapitre est divisé en deux ou trois sections qui présentent les
différents diagrammes d‘UML.
Le support s'adresse aux étudiants de premier cycle (DUT, BTS). Il pourrait

également servir de référence aux étudiants de second cycle (universités et
écoles d’ingénieurs) désireux d’apprendre les concepts de base du langage
UML.
2
Table des matières
A
AVVA
ANNTT--PPR
ROOPPO
OSS ........................................................................................... 2
Table des matières ........................................................................................ 3
CHAPITRE I .................................................................................................. 12
INTRODUCTION : Les méthodes objet et la genèse d'UML ..................... 12
I.1 Historique des Méthodes ................................................................................. 13
I.1.1 Historique d’UML ................................................................................. 14
I.2 Introduction au Langage de Modélisation UML ........................................... 16
I.2.1 Définition d’UML .................................................................................. 16
I.3 Modélisation avec UML .................................................................................. 17
I.3.1 Pourquoi modéliser ............................................................................ 17
I.3.2 Les principes de la modélisation....................................................... 17
I.3.3 Qu’apporte la modélisation objet ...................................................... 17
I.3.4 Les objectifs d’UML ............................................................................ 18
I.3.5 UML et les domaines d’utilisation ..................................................... 19
I.4 Les Composants d’UML .................................................................................. 19
I.4.1 Les trois éléments de base en UML .................................................. 19
I.4.2 Les Modèles d’UML ............................................................................ 23
I.4.3 Les Diagrammes D’UML ..................................................................... 23
I.4.4 Les Vues d’UML .................................................................................. 26
I.4.1 Point de vue des cas d’utilisation ..................................................... 26
I.4.2 Point de vue logique........................................................................... 27
I.4.3 Point de vue processus ..................................................................... 27
I.4.4 Point de vue implantation .................................................................. 27
I.4.5 Point de vue déploiement .................................................................. 28
3
I.5 Les Phases de la modélisation.......................................................................... 28
I.5.1 Expression des besoins..................................................................... 29
I.5.1 Spécification ....................................................................................... 30
I.5.2 Analyse ................................................................................................ 30
I.5.4 Conception.......................................................................................... 33
I.5.5 Implémentation ................................................................................... 33
I.5.6 Tests de vérification ............................................................................ 33
I.5.7 Validation ............................................................................................ 33
I.5.8 Maintenance et évolution ................................................................... 34
CHAPITRE II ................................................................................................. 35
Diagrammes des Cas d’Utilisations - USE CASES DIAGRAM ................. 35
II.1 Cahier des Charges : Gestion de Bibliothèque .............................................. 36
II.2 But des Use Cases ............................................................................................ 36
II.3 Modèle des Cas d'Utilisations ......................................................................... 37
II.4 Concepts de base du Diagramme des UC ....................................................... 37
II.4.1 Acteurs ................................................................................................ 37
II.4.2 Cas d’utilisation (Use-Case) .............................................................. 38
II.4.3 Système.............................................................................................. 41
II.5 Elaboration du Diagramme Des UC de la Gestion de Bibliothèque ............. 42
II.6 Elaboration du Modèle des Cas d’Utilisation de la Gestion de Bibliothèque 43
II.6.1 Scénarios d'un cas d'utilisation : Définition ..................................... 43
II.6.2 Scénarios du UC : Réservation d’un livre ......................................... 43
II.6.3 Représentation du Scénario par diagramme de séquences ............ 45
CHAPITRE III ................................................................................................ 49
Concepts Objets& Diagramme de Classes - Class Diagram .................... 49
SECTION A : CONCEPTS OBJETS ............................................................. 50
III.A.1 Classe : Définition ............................................................................ 51

4
III.A.1.1 Attributs / Méthodes / Identité ...................................................... 51
III.A.1.2 Attributs / Operations: Syntaxe .................................................... 52
III.A.1.3 Operations (Méthodes) .................................................................. 52
III.A.1.4 La Classe et ses membres ........................................................... 53
III.A.2 Classe & Objet ........................................................................................... 53
III.A.3 Protection des Attributs et des Opérations .............................................. 54
III.A.3.1 Principe de l'encapsulation ........................................................... 54
III.A.3.2 Usage et Notation.......................................................................... 54
III.A.3.3 Attributs et Opérations de Classe ................................................. 56
III.A.3.4 Attribut dérivé ................................................................................ 57
III.A.4 Surcharge & Polymorphisme .................................................................... 57
III.A.5 Principaux Concepts du Diagramme de Classe ........................................ 58
III.A.5.1 Associations entre Classes ........................................................... 58
III.A.5.2 Multiplicité, Nom d’Association, Nom de Rôle ............................. 59
III.A.5.3 Nommage des Rôles ...................................................................... 59
III.A.5.4 Lien entre Objets ............................................................................ 60
III.A.5.5 Classe d’Association ..................................................................... 61
III.A.5.6 Qualificateurs : restriction de la cardinalité ................................. 61
III.A.5.7 Contraintes sur les Associations .................................................. 62
III.A.6 Types d’Associations .................................................................................. 64
III.A.6.1 Agrégation ...................................................................................... 64
III.A.6.2 Composition : Agrégation forte .................................................... 65
III.A.6.3 Exemples ........................................................................................ 65
III.A.7 Navigabilité ................................................................................................ 66
III.A.8 Éléments sur une association : Résumé ..................................................... 68
III.A.9 Héritage ...................................................................................................... 69
III.A.9.1 Héritage : Nouvelles classes dérivées de classes existantes..... 69

5
III.A.9.2 Héritage : Ajout d’une classe de base (analyse) .......................... 70
III.A.9.3 Héritage : Généralisation, Factorisation des propriétés ............. 71
III.A.9.4 Héritage : Polymorphisme ............................................................. 73
III.A.9.5 Héritage multiple et répété ............................................................ 73
III.A.10 Classe Abstraite ....................................................................................... 74
III.A.10.1 Exemple 1 : Classe abstraite Media ............................................ 74
III.A.10.2 Exemple 2 : Classe abstraite Figure .......................................... 75
III.A.11 Interfaces .................................................................................................. 76
III.A.12 Paquetages ................................................................................................ 77
SECTION B : Diagramme de Classes de la Gestion de Bibliothèque ...... 78
III.B.1 Phases de la modélisation Objet ............................................................... 79
III.B.1.1 Identifier les Classes : Classes Candidates ................................. 79
III.B.1.2 Classes retenues............................................................................ 80
III.B.1.3 Dictionnaire des Données ............................................................. 80
III.B.1.4 Chercher les Associations ............................................................ 80
III.B.1.5 Chercher les Attributs.................................................................... 81
III.B.1.6 Généraliser par Héritage................................................................ 82
SECTION C : Diagramme d’Objets - OBJECT DIAGRAM .......................... 83
III.C.1 Diagramme d’Objets : Définition .............................................................. 84
III.C.2 Diagramme d’Objets: Structures complexes ............................................ 85
III.C.3 Résumé ..................................................................................................... 86
CHAPITRE IV................................................................................................ 87
MODELE DYNAMIQUE : Diagramme de Sequence, Diagramme de

Communication & Diagramme d’Etats Transition ..................................... 87
IV.1 Modèle Dynamique : Définition .................................................................... 88
IV.2 Diagrammes d'Interaction ............................................................................. 89
IV.2.1 Diagrammes de Séquence ................................................................ 89
6
IV.2.2 Diagramme de Collaboration/Communication ................................ 89
SECTION A : Diagrammes de Séquence - SEQUENCES DIAGRAM......... 90
IV.A.1 Diagrammes de Séquence : Définition ....................................................... 91
IV.A.2 Concepts principaux ................................................................................. 91
IV.A.2.1 Participant : Représentation des acteurs..................................... 92
IV.A.2.2 Messages ...................................................................................... 92
IV.A.2.3 Cadre d’interaction ....................................................................... 95
IV.A.3 Diagramme de séquence : Réserver un Livre ............................................ 96
IV.A.4 Diagramme de Classe: Ajout des opérations dans les classes ................... 96
SECTION B : Diagramme de Collaboration entre Classes ; Diagramme de

Communication - COMMUNICATION DIAGRAM........................................ 98
IV.B.1 Diagramme de collaborations : Définition ................................................. 99
IV.B.2 Diagramme de Communication : But & Principes ................................. 100
IV.B.3 Principaux Concepts ................................................................................ 101
IV.B.3.1 Objet : Représentation graphique ............................................. 101
IV.B.3.2 Liens d’interactions ..................................................................... 102
IV.B.3.3 Messages : Types ....................................................................... 102
IV.B.4 Diagramme de collaboration : Réserver un livre .................................... 103
SECTION C : Diagrammes Etats –Transitions - STATE MACHINE

DIAGRAM ................................................................................................... 104
IV.C.1 Diagramme d’Etats : Définition............................................................... 105
IV.C.2 Diagramme d’Etats : Objectif.................................................................. 105
IV.C.3 Diagramme d’Etats : Notion d’état ......................................................... 105
IV.C.3.1 Etats spéciaux ............................................................................. 106
IV.C.3.2 Etats imbriqués-composite ......................................................... 106
IV.C.4 Diagramme d’Etats : Notions d’évènement ............................................. 107
IV.C.4.1 Notions de garde ......................................................................... 108
7
IV.C.4.2 Notions de transitions ................................................................. 108
IV.C.5 Diagramme d’Etats : Notions d’opérations et actions........................... 109
IV.C.6 Diagramme d’Etats : Syntaxe .................................................................. 110
IV.C.7 Résumé ..................................................................................................... 111
IV.C.8 Cas de la bibliothèque : Recherche des états .......................................... 111
IV.C.8.1 Diagramme de transitions d’états : Livre ................................... 112
IV.C.8.2 Diagramme de transitions d’états : Adhérent ............................ 113
CHAPITRE V .............................................................................................. 114
Diagramme de Composants, Diagramme de Déploiement & Diagramme

de Structure Composite ............................................................................ 114
SECTION A : Diagrammes de Composants - COMPONENT DIAGRAM . 115
V.A.1 Notion de composant ................................................................................. 116
V.A.2 Diagrammes de Composants : Définition ................................................. 116
V.A.3 Concepts de Base ....................................................................................... 117
V.A.3.1 Composant .................................................................................... 117
V.A.3.2 Interface et Composant ............................................................... 118
V.A.3.3 Module .......................................................................................... 119
V.A.3.4 Dépendance ................................................................................. 119
V.A.3.5 Processus et Thread .................................................................... 121
V.A.3.6 Composant, Port & Connecteurs ................................................ 121
V.A.4 Diagrammes de Composants : Exemple Agenda ..................................... 122
V.A.5 Diagramme de Composants : Exemple Tickets ........................................ 124
SECTION B: Diagrammes de Déploiement-DEPLOYMENT DIAGRAM... 125
V.B.1 Diagrammes de Déploiement : Définition & Objectif ............................... 126
V.B.2 Concept du Nœud ...................................................................................... 126
V.B.2.1 L’appareil (device) ....................................................................... 127
V.B.2.2 L’environnement d’exécution ..................................................... 127
8
V.B.3 Les chemins de communication ................................................................. 128
V.B.4 Artefact : Définition .................................................................................. 128
V.B.5 Déploiement .............................................................................................. 129
V.B.6 Diagramme de Déploiement : Exemples .................................................. 130
V.B.6 Diagrammes de Déploiement de l'application Bibliothèque .................... 131
SECTION C : Diagrammes de Structure Composites - COMPOSITE

STRUCTURE DIAGRAM ............................................................................ 132
V.C.1 Diagramme de Structure Composite : Définition & Objectifs ................ 133
V.C.2 Diagramme de Structure Composite : Concept ....................................... 133
V.C.2.1 Classificateurs Structurés .......................................................... 133
V.C.2.2 Eléments du diagramme : Parties .............................................. 135
V.C.2.3 Eléments du diagramme : Ports ................................................. 135
V.C.2.4 Eléments du diagramme : Connecteurs ..................................... 137
V.C.2.5 Eléments du diagramme : Collaboration.................................... 138
V.C.3 Exemples de Collaboration....................................................................... 139
V.C.4 Diagramme de Structure Composite versus Diagramme de Classe ....... 140
CHAPITRE VI............................................................................................. 142
Diagramme d’Activité, Diagramme de Globale Interaction & Diagramme

de Paquetage ............................................................................................. 142
SECTION A : Diagramme d’Activité - ACTIVITY DIAGRAM .................... 143
VI.A.1 Diagrammes d’Activité : Définition ........................................................ 144
VI.A.2 Diagrammes d’Activité : Intérêt ............................................................. 144
VI.A.3 Concepts du diagramme d’activité ......................................................... 145
VI.A.3.1 Concept: Activité ........................................................................ 145
VI.A.3.2 Concept : Etat ............................................................................ 146
VI.A.3.3 Concept : Transition ................................................................... 146
VI.A.3.4 Swimlanes .................................................................................. 150
9
VI.A.4 Diagrammes d’Activité : Exemples........................................................ 151
VI.A.3.5 Diagrammes d’Activité : Résume ............................................. 153
SECTION B : Diagramme Globale Interaction - Interaction Overview

Diagram ..................................................................................................... 154
VI.B.1 Interaction : Définition ............................................................................ 155
VI.B.2 Diagrammes Globale Interaction : Définition ........................................ 155
VI.B.3 Diagrammes Globale Interaction : Représentation ................................ 156
VI.B.4 Diagrammes Globale Interaction: Exemple ........................................... 157
SECTION C : Diagrammes de Paquetages - Package Diagram .............. 162
VI.C.1 Diagrammes de Paquetages : Définition & Objectif .............................. 163
VI.C.2 Paquetage : Définition & Notation ......................................................... 163
VI.C.3 Espace de Nommage................................................................................ 165
VI.C.4 Dépendances ............................................................................................ 167
CHAPITRE VII............................................................................................ 169
Diagrammes de Temps & Diagrammes de Profile................................... 169
SECTION A : Diagrammes de Temps - TIMING DIAGRAM...................... 170
VII.A.1 Timing Diagrams : Defintion................................................................. 171
VII.A.2 Concepts ................................................................................................. 171
VII.A.2.1 Lifeline ........................................................................................ 171
VII.A.2.2 State / Condition Timeline .......................................................... 172
VII.A.2.3 Destruction occurrence.............................................................. 173
VII.A.2.4 Time Constraint .......................................................................... 174
VII.A.2.5 Duration Constraint .................................................................... 174
VII.A.3 Etude de Cas : Retrait ........................................................................... 175
VII.A.3 Etude de cas – Notation Robuste .......................................................... 179
VII.A.3.2 Diagramme de Temps – Notation Concise................................ 179
VII.A.4 Timing diagram example: Website Latency ......................................... 180
10
SECTION B : Diagrammes de Profile - PROFIL DIAGRAM ..................... 182
VII.B.1 Diagrammes de Profile: Définition & Notation..................................... 183
VII.B.2 Diagrammes de Profile: Composant...................................................... 184
VII.B.2.1 Stéréotypes ................................................................................ 184
VII.B.2.2 Tagged Values ........................................................................... 185
VII.B.2.3 Contraintes................................................................................. 185
VII.B.2.4 Relations .............................................................................................. 186
VII.B.3 Diagrammes de Profile : Exemples........................................................ 187
Conclusions ............................................................................................... 190
B
Biibblliiooggrraapphhiiee -- W
Weebbooggrraapphhiiee.................................................................... 191
N
NAAD
DIIA
AAAFFIIFFII’’ss B
BIIO
OGGR
RAAPPH
HYY...................................................................... 192
11
CHAPITRE I
INTRODUCTION
-
Les méthodes objet et
la genèse d'UML
"L'apprentissage est la seule chose que l'esprit

n'épuise jamais, ne craint jamais et ne regrette
jamais "
Léonard de Vinci
12
I.1 Historique des Méthodes
Les premières méthodes d'analyse (années 70)
Découpe cartésienne (fonctionnelle et hiérarchique) d'un système.
L'approche systémique (années 80)
Modélisation des données + modélisation des traitements (Merise, Axial,

IE, etc.).
L'émergence des méthodes objet (1990-1995)
Prise de conscience de l'importance d'une méthode spécifiquement

objet : comment structurer un système sans centrer l'analyse
uniquement sur les données ou uniquement sur les traitements (mais
sur les deux)?
Plus de 50 méthodes objet sont apparues durant cette période (Booch,

Classe-Relation, Fusion, OOD, OMT, OOA, OOM, OOSE, etc.)
Aucune méthode ne s'est réellement imposée.
Les premiers consensus (1995)
OMT (Object Modeling Technique) par James Rumbaugh : vues

statiques, dynamiques et 3fonctionnelles d'un système.
- Issue du centre de R&D de General Electric.
- Notation graphique riche et lisible.
OOD (Object Oriented Development) par Grady Booch : vues logiques

et physiques du système
- Définie pour le DOD, afin de rationaliser le développement

d'applications ADA, puis C++.
- Ne couvre pas la phase d'analyse dans ses 1ères versions

(préconise SADT).
- Introduit le concept de package (élément d'organisation des

modèles).
OOSE (Object Oriented Software Engineering) par IV.Ar Jacobson :

couvre tout le cycle de développement
13
- Issue d'un centre de développement d'Ericsson, en Suède.
- La méthodologie repose sur l'analyse des besoins des

utilisateurs.
UML est un standard OMG
UML 1.3
06/1999
unifie les concepts et la notation

intègre les « meilleures pratiques »
Booch OOSE
OMT - 2
’93
UML est un langage public et standardisé
L’Object Management Group (OMG) a retenu UML comme le langage

de modélisation objet standard, pour la spécification et la conception
L ’OMG est désormais responsable de ses évolutions
www.omg.org
I.1.1 Historique d’UML
14
Industrialisation
06/1999 : révision 1.3 UML 1.3
11/1997 : adoption par l'OMG

UML 1.1
09/1997 : révision 1.1
01/1997 : soumission à l'OMG UML 1.0

Standardisation
10/1996 UML 0.91
06/1996 UML 0.9
Partenaires
10/1995 Unified Method 0.8 UML
Unification
10/1994 Booch'93 + OMT-2
G. Booch J. Rumbaugh I. Jacobson

Fragmentation
Booch-91 OMT-1 OOSE
December 2017 https://www.omg.org/spec/UML/2.5.1

2.5.1
July 2011 https://www.omg.org/spec/UML/2.4.1

2.4.1
May 2010 https://www.omg.org/spec/UML/2.3

2.3
January 2009 https://www.omg.org/spec/UML/2.2

2.2
October 2007 https://www.omg.org/spec/UML/2.1.2

2.1.2
July 2005 https://www.omg.org/spec/UML/2.0

2.0
March 2003 https://www.omg.org/spec/UML/1.5

1.5
September 2001 https://www.omg.org/spec/UML/1.4

1.4
February 2000 https://www.omg.org/spec/UML/1.3

1.3
July 1999 https://www.omg.org/spec/UML/1.2

1.2
December 1997 https://www.omg.org/spec/UML/1.1

1.1
15
I.2 Introduction au Langage de Modélisation UML
Ce qu’est et n’est pas UML
• UML = Langage de modélisation

graphique & textuel
• UML Méthode !
I.2.1 Définition d’UML
UML est un langage de modélisation pour :
comprendre et décrire des besoins ;
spécifier des systèmes, simples ou complexes ;
concevoir et construire des solutions ;
documenter (textes et graphiques) un système ;
communiquer entre les membres de l'équipe de projet.
UML est un langage à usage général, quel que soit :
le type de système - logiciel, matériel, organisation, etc.
le domaine métier - gestion, ingénierie, finance, etc.
le processus de développement - cascade, itératif, RAD, etc.
16
I.3 Modélisation avec UML
I.3.1 Pourquoi modéliser
Un modèle est une simplification de la réalité qui permet de mieux

comprendre le système à développer.
Il permet :
De visualiser le système comme il est ou comme il devrait l'être ;
De valider le modèle vis à vis des clients ;
De spécifier les structures de données et le comportement du

système ;
De fournir un guide pour la construction du système ;
De documenter le système et les décisions prises.
I.3.2 Les principes de la modélisation
Le modèle doit être connecté au monde réel.
Un modèle peut être exprimé avec différents niveaux de précision.
Un simple modèle n'est pas suffisant, il y a plusieurs façons de voir un

système :
plan de masse
vue de face, de coté, …
plan des niveaux
plan électrique
plan de plomberie
plan des calculs de construction
I.3.3 Qu’apporte la modélisation objet
Plus grande indépendance du modèle par rapport aux fonctionnalités

demandées.
Des fonctionnalités peuvent être rajoutées ou modifiées, le modèle

objet ne change pas.
Plus proche du monde réel.

17
I.3.4 Les objectifs d’UML
Représenter des systèmes entiers.
Prendre en compte les facteurs d’échelle.
Créer un langage de modélisation utilisable à la fois par les humains et

les machines ;
Recherche d’un langage commun :
Utilisable par toutes les méthodes ;
Adapté à toutes les phases du développement ;
Compatible avec toutes les techniques de réalisation.
Un processus de développement logiciel universel est une utopie :
Impossible de prendre en compte toutes les organisations et

cultures d'entreprises.
Un processus est adapté (donc très lié) au domaine d'activité de

l'entreprise.
Même si un processus constitue un cadre général, il faut

l'adapter de manière précise au contexte de l'entreprise.
UML un langage
UML n’est pas une méthode
UML est un langage de modélisation objet
UML a été adopté par toutes les méthodes objet
UML est dans le domaine public, c’est une norme
UML un langage pour
Visualiser : chaque symbole graphique a une sémantique ;
Spécifier de manière précise et complète, sans ambiguïté ;
construire les classes, les relations SQL peuvent être générées

automatiquement ;
18
documenter les différents diagrammes, notes, contraintes,
exigences seront présentées dans un document.
I.3.5 UML et les domaines d’utilisation
Systèmes d'information des entreprises
Les Banques et les services financiers
Télécommunications
Transport
Défense et aérospatiale
Scientifique
Applications distribuées par le WEB
I.4 Les Composants d’UML
UML se décompose en plusieurs sous ensembles :
Les vues : Les vues sont les observables du système. Elles décrivent le
système d’un point de vue donné, qui peut être organisationnel,
dynamique, temporel, architectural, géographique, logique, etc. En
combinant ces vues, il est possible de définir (ou retrouver) le système
complet.
Les diagrammes : ce sont des éléments graphiques. Ceux-ci décrivent

le contenu des vues, qui sont des notions abstraites. Les diagrammes
peuvent faire partie de plusieurs vues
Les modèles d’élément : ce sont les briques des diagrammes UML, ces
modèles sont utilisés dans plusieurs types de diagrammes. Ex: cas
d’utilisation, classe, association, etc.
I.4.1 Les trois éléments de base en UML
1- Les blocs de bases pour construire
Les entités utilisées : Entités structurelles
19
- Entités de comportement
- Entités de regroupement
- Entité d'annotation
La notion de relation
Les diagrammes
2- Les règles à observer pour utiliser ces blocs de base
Règles sémantiques
Règles de présentation
3- Les mécanismes communs
Spécification
Présentation
Extension des modèles
20
Les relations
dépendance
association
héritage
réalisation
En langage UML, une relation est une connexion entre des éléments de
modèle. Une relation UML est un type d'élément de modèle qui ajoute une
sémantique à un modèle en définissant la structure et le comportement
entre les éléments de modèle.
Les relations UML sont regroupées dans les catégories suivantes :
21
Catégorie Fonction & Définition
Bords d'activité Représentent le flux entre des activités
Associations Indiquent que des instances d'un élément de modèle

sont connectées aux instances d'un autre élément de
modèle.
Relation entre 2 classificateurs ou plusieurs qui
implique des connections entre leurs instances.
Dépendances Indiquent qu'un changement apporté à un élément de

modèle peut affecter un autre élément de modèle.
Relations entre 2 éléments; dans laquelle un
changement sur un élément (indépendant) peut affecter
l’autre (dépendant)
Généralisations Indiquent qu'un élément de modèle est une

spécialisation d'un autre élément de modèle
Réalisations Indiquent qu'un élément de modèle fournit une

spécification qu'un autre élément de modèle
implémente
Relation entre spécification et implémentation.
Transitions Représentent des changements dans un état
Stéréotypes et icônes associées
<<contrôle>>
Gestion Commande
gestion Commande
<<entité>>
Stockage Commande
stockage Commande
<<frontière>>
Réception Commande
réception Commande
22
I.4.2 Les Modèles d’UML
Le modèle des classes qui capture la structure statique ;
Le modèle des états qui exprime le comportement dynamique des

objets ;
Le modèle des cas d’utilisation qui décrit les besoins des utilisateurs ;
Le modèle d’interaction qui représente les scénarios et les flots de

messages ;
Le modèle de réalisation qui montre les unités de travail ;
Le modèle de déploiement qui précise la répartition des processus.
I.4.3 Les Diagrammes D’UML
UML 2.5 définit 14 sortes de diagrammes (9 en UML 1.3) pour

représenter les différents points de vue de modélisation.
Les diagrammes peuvent montrer tout ou partie des caractéristiques

des éléments de modélisation, selon le niveau de détail utile dans le
contexte d’un diagramme donné.
Diagrammes structurelles ou statiques
Les diagrammes de classes
Les diagrammes d’objets
Les diagrammes de composants
Les diagrammes de déploiement
Les diagrammes de paquetages
Les diagrammes de structure composite (collaboration)
Les diagrammes de profils
Diagrammes comportementaux
Les diagrammes d’états-transition
Les diagrammes d’activités
Les diagrammes de cas d’utilisation

23
Diagrammes d’interactions ou dynamiques
Les diagrammes de séquence
Les diagrammes de communication
Les diagrammes global d’interaction
Les diagrammes de temps
Diagrammes
Diagrammes Diagrammes de
de Structure Comportement
Diagramme Diagramme de Diagramme Diagramme Diagramme de

de Classes Paquetages d’Objets d’Activités Cas d’Utilisation
Diagramme de Diagramme de Diagramme Diagramme Diagramme de

Composants Déploiement de Structure d’Interactions Transition
Composite d’état
Diagramme Diagramme de Diagramme de

UML 1.x Séquence Communication
Diagramme Diagramme vue Diagramme

UML 2.0 d’ensemble des de Temps
Interactions
Les 14 diagrammes d’UML2

1. Les diagrammes de classes (Class Diagram) : représentent la structure
statique en terme de classes et de relations.
2. Les diagrammes d’objets (Object Diagram) : représentent les objets et

leurs relations et correspondent à des diagrammes de collaboration
simplifiés, sans représentation des envois de messages.
3. Les diagrammes de composants (Component Diagram) : représentent

les composants physiques d’une application.
24
4. Les diagrammes de déploiement (Deployment Diagram) : montrent la
disposition physique des matériels qui composent le système et la
répartition des composants sur ces matériels.
5. Les diagrammes de structures composites (Composite Structure

Diagram) : représentent la structure interne d’un objet complexe lors de
son exécution, dont ses points d’interaction avec le reste du système.
6. Les diagrammes de cas d’utilisation (Use-cases ou Use Case Diagram)
: représentent les fonctions du système du point de vue de l’utilisateur.
7. Les diagrammes d’activité (Activity Diagram) : représentent le

comportement d’une opération, d’un cas d’utilisation ou un processus
métier.
8. Les diagrammes de séquence (Sequence Diagram) : sont une

représentation temporelle des objets et de leurs interactions.
9. Les diagrammes d’états-transition (State Machine Diagram) :

représentent le comportement d’un classificateur ou d’une opération en
terme d’états.
10. Les diagrammes de communication (Communication Diagram) : sont

une représentation simplifiée des diagrammes de séquence se
concentrant sur les échanges de messages entre les objets;
équivalents au diagrammes de collaboration (UML 1) qui sont une
représentation spatiale des objets, des liens et des interactions.
11. Les diagrammes de temps (Timing Diagram) : permettent de décrire les
variations d’une donnée au cours du temps.
12. Les diagrammes global interaction (Interaction Overview Diagram) :
permettent de décrire les enchainements possibles entre les scénarios
préalablement identifiés sous forme de diagrammes de séquences
(variante du diagramme d’activité)
13. Les diagrammes des paquetages (Package Diagram) : servent à
représenter les dépendances entre paquetages, c’est-à-dire les
dépendances entre ensembles de définitions.
14. Les diagrammes de profiles (Profil Diagram): permettent de spécialiser,

de personnaliser pour un domaine particulier un méta-modéle de
référence d’UML
25
I.4.4 Les Vues d’UML
I.4.1 Point de vue des cas d’utilisation
Description du modèle vue par ses utilisateurs finaux : correspond aux

besoins attendus par chaque acteur –QUOI et QUI.
Regroupe le comportement du système selon
Priorité: critique, important, accessoire ;
Risques à circonscrire ;
Options disponibles ;
Couverture de l’architecture ;
Autres objectifs tactiques et contraintes.
26
I.4.2 Point de vue logique
Définition du système vu de l’intérieur : COMMENT peuvent être

satisfaits les besoins des acteurs ;
Décomposition orientée-objet
Décomposition en objets et classes ;
Regroupement en paquetages ;
Connexions par héritage, association, etc.
Accent sur l’abstraction, l’encapsulation, l’uniformité ;
Réalisation des scénarios des cas d'utilisation.
I.4.3 Point de vue processus
Vue temporelle et technique : met en œuvre les notions de taches

concurrentes, contrôle, synchronisation, etc.
Décomposition en tâches et processus ;
Regroupement des groupes de processus ;
Communication ;
Information sur les caractéristiques suivantes :
Disponibilité, fiabilité ;
Intégrité, performance ;
Contrôle.
I.4.4 Point de vue implantation
Définit les dépendances entre les modules ;
Décomposition en modules et niveaux ;
Regroupement de modules en paquetages ;
Organisation des sous-systèmes en niveaux pour :
Réduire le couplage et la visibilité ;
Augmenter la robustesse ;
27
Facilité de développement ;
Potentiel de réutilisation ;
Gestion de configuration ;
I.4.5 Point de vue déploiement
Décrit la position géographique et l’architecture physique de chaque

élément du système : OU ;
Décomposition en nœuds d’exécution ;
Rôle d’un nœud ;
Inter-connectivité, topologie ;
Performance, disponibilité ;
Installation, maintenance.
I.5 Les Phases de la modélisation
28
Les différentes étapes de la modélisation
1. Expression des besoins ;
2. Spécification ;
3. Analyse ;
4. Conception ;
5. Implémentation ;
6. Tests de vérification ;
7. Validation ;
8. Maintenance et évolution.
I.5.1 Expression des besoins
ROLE :
Permettre une meilleure compréhension du système ;
Comprendre et structurer les besoins du client :
29
Clarifier, filtrer et organiser les besoins, ne pas chercher
l’exhaustivité.
Une fois identifiés et structurés, ces besoins :
Définissent le contour du système à modéliser (ils précisent le but

à atteindre) ;
Permettent d'identifier les fonctionnalités principales (critiques) du

système ;
Comprendre le contexte du système en définissant un modèle du

domaine et du métier ;
Recenser les besoins fonctionnels et les définir par des cas

d'utilisations ;
Noter les contraintes, exigences non fonctionnelles.
Le modèle du domaine regroupe les objets qui se situent dans le

contexte du système : entités existantes ou événements qui s'y
produisent.
Exigences non fonctionnelles:
Contraintes de concurrence ;
Contraintes de temps de réponse ;
Contraintes de distribution ;
Contraintes de performance ;
Contraintes de répartition.
I.5.1 Spécification
Ce que le système doit être et comment il peut être utilisé.
I.5.2 Analyse
L’objectif est de déterminer les éléments intervenant dans le système à

construire, ainsi que leur structure et leurs relations.
Elle doit décrire chaque objet selon 3 axes :
- Axe fonctionnel : savoir-faire de l’objet.
30
- Axe statique : structure de l’objet
- Axe dynamique : cycle de vie de l’objet au cours de

l’application (Etats et messages de l’objet).
Ces descriptions ne tiennent pas compte des contraintes

techniques (informatique).
Le but de l’analyse est de traduire dans un langage proche de celui des

informaticiens les modèles exprimés dans l'expression des besoins.
Cependant pour rester compréhensible par les clients ou utilisateurs, il

n'intervient que des entités du domaine (métier) considéré.
Elle sert d'interface, avec l'expression des besoins, aux dialogues et

aux contrats avec les clients et les utilisateurs.
L'analyse doit servir de support pour la conception, l'implémentation et

la maintenance.
31
32
La notation graphique a pour but :
Modéliser les objets, les relations entre objets, les interactions avec le
système.
Servir de support de communication entre l'analyste, le client, et les
utilisateurs.
I.5.4 Conception
Elle consiste à apporter des solutions techniques aux descriptions

définies lors de l’analyse : architecture technique ; performances et
optimisation ; stratégie de programmation.
On y définit les structures et les algorithmes.
Cette phase sera validée lors des tests.
I.5.5 Implémentation
C’est la réalisation de la programmation : codage
I.5.6 Tests de vérification
Ils permettent de réaliser des contrôles pour la qualité technique du

système.
Il s’agit de relever les éventuels défauts de conception et de

programmation (revue de code, tests des composants,...).
Il faut instaurer ces tests tout au long du cycle de développement et

non à la fin pour éviter des reprises conséquentes du travail
(programmes de tests robustes ; Logiciels de tests).
I.5.7 Validation
Le développement d’une application doit être lié à un contrat ayant une

forme de cahier de charges, où doivent se trouver tous les besoins de
l’utilisateur. Ce cahier de charge doit être rédigé avec la collaboration
de l’utilisateur et peut être par ailleurs complété par la suite.
Tout au long des ces étapes, il doit y avoir des validations en
collaboration également avec l’utilisateur.
33
Une autre validation doit aussi être envisagée lors de l’achèvement du
travail de développement, une fois que la qualité technique du système
est démontrée. Elle permettra de garantir la logique et la complétude du
système.
I.5.8 Maintenance et évolution
Deux sortes de maintenances sont à considérer :
- Une maintenance corrective, qui consiste à traiter les

“buggs ”.
- Une maintenance évolutive, qui permet au système
d’intégrer de nouveaux besoins ou des changements
technologiques.
34
CHAPITRE II
Diagrammes
des Cas d’Utilisations
-
USE CASES DIAGRAM
Ce que doit faire le système

sans spécifier comment il le fait
" L'art de la connaissance, c'est de savoir ce qui

doit être ignoré "
Djalâl-ad-Dîn Rûmî
35
II.1 Cahier des Charges : Gestion de Bibliothèque
Un gérant de bibliothèque désire automatiser la gestion des prêts.
Il commande un logiciel permettant aux utilisateurs de connaître les livres

présents, d'en réserver jusqu'à 2. L'adhérent peut connaître la liste des livres
qu'il a empruntés ou réservés.
L'adhérent possède un mot de passe qui lui est donné à son inscription.
L'emprunt est toujours réalisé par les employés qui travaillent à la

bibliothèque. Après avoir identifié l'emprunteur, ils savent si le prêt est
possible (nombre max de prêts = 5), et s'il a la priorité (il est celui qui a
réservé le livre).
Ce sont les employés qui mettent en bibliothèque les livres rendus et les
nouveaux livres. Il leur est possible de connaître l'ensemble des prêts
réalisés dans la bibliothèque.
II.2 But des Use Cases
Les cas d'utilisation représentent les fonctionnalités que le système doit

savoir faire.
Chaque cas d'utilisation peut être complété par un ensemble d'interactions

successives d'une entité en dehors du système (l’utilisateur) avec le système
lui même.
Les Uses Cases permettent :
De connaître le comportement du système sans spécifier comment ce

comportement sera réalisé.
De définir les limites précises du système
Au développeur de bien comprendre l'attente des utilisateurs et les

experts du domaine.
36
De plus les Use Cases sont :
Des instruments de validation et de test du système en cours et en fin

de construction.
II.3 Modèle des Cas d'Utilisations
Un diagramme de cas d’utilisation définit :

1. Les acteurs ;
2. Les cas d'utilisations ;
3. Le système ;
4. Les liens entre acteurs et cas d'utilisations.
Un modèle de cas d'utilisation se définit par :

1. Des diagrammes de cas d’utilisation ;
2. Une description textuelle des scénarios d'utilisation ;
3. Une description de ces scénarios par :
- Les diagrammes de séquences ;
- Les diagrammes de communication (collaboration).
II.4 Concepts de base du Diagramme des UC
II.4.1 Acteurs
Un acteur représente une personne ou un périphérique qui joue un rôle

(interagit) avec le système.
Relation entre acteurs : généralisation (héritage)
37
II.4.2 Cas d’utilisation (Use-Case)
Un cas d’utilisation est un moyen de représenter les différentes

possibilités d'utiliser un système.
Il exprime toujours une suite d'interactions entre un acteur et

l'application.
Il définit une fonctionnalité utilisable par un acteur.
II.4.2.1 Organisation des Use Cases : «include»
La relation «include» précise qu'un cas d’utilisation contient le

comportement défini dans un autre cas d’utilisation.
Cette relation permet de mettre en commun des comportements

communs à plusieurs cas d'utilisation.
38
Un cas A est inclus dans un cas B si le comportement décrit par le cas A est
inclus dans le comportement du cas B: on dit alors que le cas B dépend de A.
II.4.2.2 Organisation des Use Cases: «extend»
La relation «extend» précise qu'un cas d’utilisation peut dans certains

cas augmenter le comportement d'un autre cas d'utilisation.
Une condition devra valider cette augmentation.
Le point d'utilisation de cette augmentation peut être défini dans un

"point d'extension".
Si le comportement de B peut être étendu par le comportement de A on

dit que A étend B.
Un point d'extension doit spécifier le ou les points du cas d'utilisation au

niveau desquels le comportement d'extension entre en jeu.
Dans cet exemple, le cas d'utilisation « Regarder la liste des livres »

augmente le cas d’utilisation d’une réservation, avant le choix du livre, si
l'utilisateur en fait la demande.
39
II.4.2.3 Organisation des Use Cases : Généralisation
Cette relation « est un » introduit la notion d’héritage.
Les cas d'utilisation "Vérification par mot passe" et "Vérification par

carte" sont des spécialisations du cas d'utilisation "Identification
abonné".
Autrement dit : si l'on dit que l'on fait une "Identification abonné", ce
peut être une "Vérification par carte" ou une "Vérification par mot
passe".
II.4.2.4 Modélisation d’un Système : Obtenir les Cas

d'Utilisation
Identifier les acteurs qui utilisent, qui gèrent, qui exécutent des
fonctions spécifiques.
Organiser les acteurs par relation d’héritage.
Pour chaque acteur, rechercher les cas d’utilisation avec le système.

En particulier, ceux qui modifient l’état du système ou qui attendent une
réponse du système.
Ne pas oublier les variantes d’interactions (cas d’erreur, cas interdits).
Organiser ces interactions par héritage, par utilisation et par extension.
40
II.4.3 Système
Le système définit l'application informatique, il ne contient donc pas les

acteurs, mais les cas d'utilisation et leurs associations.
41
II.5 Elaboration du Diagramme Des UC de la Gestion de
Bibliothèque
42
II.6 Elaboration du Modèle des Cas d’Utilisation de la
Gestion de Bibliothèque
II.6.1 Scénarios d'un cas d'utilisation : Définition
La description d’un cas d’utilisation se fait par des scénarios qui définissent la
suite logique des interactions qui constituent ce cas.
On peut définir des scénarios simples ou des scénarios plus détaillés faisant
intervenir les variantes, les cas d'erreurs etc.
Cette description se fait de manière simple, par un texte compréhensible par

les personnes du domaine de l'application.
Elle précise ce que fait l'acteur et ce que fait le système.
La description détaillée pourra préciser les contraintes de l'acteur et celles du

système.
II.6.2 Scénarios du UC : Réservation d’un livre
Le client se présente devant un terminal:
• (1) Le système affiche un message d’accueil.
• (2) Le client choisit l’opération réservation parmi les différentes opérations

proposées.
• (3) Le système lui demande de s'authentifier.
• (4) Le client donne son identification (nom, mot de passe).
• (5) Le système lui demande de choisir un livre.
• (6) Le client précise le livre qu'il désire.
• (7) Le système lui précise si un exemplaire du livre lui est réservé.
43
Pré-conditions:
- Le client doit être inscrit à la bibliothèque ;
- Le client ne doit pas avoir atteint le nombre maximum de

réservation ;
- Un exemplaire du livre doit être enregistré ;
Post-conditions: (Si l'opération s'est bien déroulée) ;
- Le client a une réservation supplémentaire ;
- Le nombre d'exemplaires disponibles du livre est décrémenté de 1.
Scénarios du cas d'utilisation Réservation d’un livre
1. (1) Le système affiche un message d’accueil sur le terminal avec un choix

d'opérations ;
2. (2) Le client choisit l’opération réservation parmi les différentes opérations

proposées ;
3. (3) Le système lui demande de s'authentifier ;
4. (4) Le client donne son identification (nom, mot de passe) ;
5. (5) Le système demande le titre du livre en donnant la possibilité de choisir

dans une liste ;
6. (6) Le client précise le livre qu'il désire ;
7. (7) Le système lui précise qu’un exemplaire du livre lui est réservé.
44
Scénarios du cas d'utilisation réservation d’un livre
(Variantes)
Variante 1 : en (6) le client demande à connaître les livres présents ;
Variante 2 : en (4) le client n'est pas reconnu, dans ce cas, tant qu'il
n'est pas reconnu, on lui redemande de s'authentifier ;
Variante 3 : en (4) le client est reconnu, mais le mot de passe est

incorrect, il peut avoir 5 essais, par la suite le client sera interdit
pendant 1 heure ;
Variante 4 : en (4) le client n'a plus le droit de réserver ;
Variante 5 : en (7) le livre n'est pas libre.
II.6.3 Représentation du Scénario par diagramme de

séquences
Suite aux descriptions textuelles, le scénario peut être représenté en utilisant

un diagramme de séquences.
Le diagramme de séquences permet :
- De visualiser l’aspect temporel des interactions
- De connaître le sens des interactions (acteur vers système ou

contraire)
45
Diagramme de Séquence
Client Système de prêts
Afficher message d ’accueil
Choix de l ’opération réservation temps
Demande d ’identification du client

Réserver un livre
Identification du client
Demande identification du livre
Identification du livre
Message « le livre est réservé »
Variation du scénario
Client Système de prêts
Choix de l ’opération réservation
Demande d ’identification du client

Réserver un livre
Identification du client
Refus trop de livres réservés
46
Déscription à l’aide de diagramme de communication
(5) Refus trop de livre emprunté

Client
(3) Demande (4) Identification client

identification client
(2) Choix opération

réservation
Système de Prêt
(1) Afficher message accueil
Cas d ’utilisation: Distributeur de billets
Distributeur de billets
Cas
d’utilisation
Effectuer un virement
Client Retirer l ’argent
Acteur Consulter un compte

client Banque
Gérer le distributeur Acteurs

gestionnaires
Effectuer la Maintenance
Employé
47
Diagramme de séquences : Use Case Retirer de l'argent

Insère la carte Distributeur de
Demande de mot de passe billets
Client Entre mot de passe
Demande type opération
Entre demande retrait
Demande somme
Entre somme
Distribue l'argent
Retirer l’argent Demande prendre les billets
Prendre les billets
Imprimer le reçu
Éjecter la carte
Demande de prendre la carte
Prendre la carte
48
CHAPITRE III
Concepts Objets
&
Diagramme de Classes
-
CLASS DIAGRAM
"Le Ce n'est pas que je suis si intelligent, c'est

que je reste plus longtemps avec les problèmes"
Albert Einstein
49
SECTION A
CONCEPTS OBJETS
"Le plus important pour un scientifique n'est

pas ses diplômes, ni le nombre de ses années
d'étude, ni même son expérience, mais tout
simplement son intuition"
Albert Einstein
50
III.A.1 CLASSE : DEFINITION
CLASSE
Caractéristiques
attributs
Personne données membres
informations
nom propriétés
age
adresse
mot de passe Famille d'objets ayant
nbre livres empruntés mêmes caractéristiques
et même comportement
changerAdresse() Comportement
donnerAge() opérations
donnerAdresse() méthodes
vérifierMotDePasse() fonctions
procédures CLASSE
messages
services
Personne
III.A.1 Classe : Définition
Une classe est une description d’un ensemble d’objets ayant une
sémantique, des attributs des méthodes et des relations en commun.
La modélisation objet consiste à créer une représentation abstraite, sous

forme d'objets, d'entités ayant une existence matérielle (arbre, personne,
téléphone, etc.) ou bien virtuelle (sécurité sociale, compte bancaire, etc.). Un
objet est caractérisé par plusieurs notions:
III.A.1.1 Attributs / Méthodes / Identité
Les attributs (on parle parfois de propriétés): Il s'agit des données

caractérisant l'objet. Ce sont des variables stockant des
informations d'état de l'objet
Les méthodes (appelées parfois fonctions membres): Les méthodes
d'un objet caractérisent son comportement, c'est-à-dire l'ensemble
des actions (appelées opérations) que l'objet est à même de réaliser.
Ces opérations permettent de faire réagir l'objet aux sollicitations
extérieures (ou d'agir sur les autres objets). De plus, les opérations
sont étroitement liées aux attributs, car leurs actions peuvent
dépendre des valeurs des attributs, ou bien les modifier.
51
L'identité: l'objet possède une identité, qui permet de le distinguer
des autres objets, indépendamment de son état. On construit
généralement cette identité grâce à un identifiant découlant
naturellement du problème (par exemple un produit pourra être repéré
par un code, une voiture par un numéro d’immatriculation, etc.).
III.A.1.2 Attributs / Operations: Syntaxe
Attributs :
nomAttribut : type = valeur initiale
Exemples :
prenom : String
size : int = 100
Operations :
nomOpération (param1 : type1, param2 : type2…) : typeResultat
Exemples :
getName() : String
setName(newName : String)
III.A.1.3 Operations (Méthodes)
Implémentation d’un service offert par l’objet, correspondant à une partie de

ses responsabilités. On distingue :
- Accesseurs : une opération qui renvoie une information sur l’état de
l’objet (fonction) ;
- Modificateur : une opération qui modifie l’état de l’objet (procédure) ;
- Constructeur : une opération de la classe qui permet d’initialiser une
nouvelle instance.
Les propriétés de classe sont soulignées.
- Mots-clé ‘static’ en java
52
III.A.1.4 La Classe et ses membres
Personne
nom : String
âge : Integer
adresse : String
mot de passe : String
nbre livres empruntés : Integer 0<= nbre livres empruntés <=5
<<constructeur>>
Personne(nom:String, âge : Integer
adresse:String, motDePasse:String)
<<caractéristiques>>
changerAdresse (String)
<<authentification>>
vérifierMotDePasse(String) : Boolean
changerMotDePasse(old:String,
new:String)
III.A.2 Classe & Objet
53
III.A.3 Protection des Attributs et des Opérations
III.A.3.1 Principe de l'encapsulation
Peut-on accéder à tous les attributs ou à toutes les méthodes d'un

objet ? NON
La classe définit ce qui est accessible.
C'est le principe de l'encapsulation.
Un objet complexe ne peut être utilisé qu'au travers de ce qui est

accessible.
En effet, la programmation orientée objet permet de cacher

l'implémentation d'un objet en ne lui permettant d'accéder aux
attributs que, uniquement par l'intermédiaire de méthodes crées à cet
effet (on parle d'interface).
Exemple :
On ne peut utiliser une voiture qu'à travers son volant, son frein, son
accélérateur, etc.
L’accès au carburateur est impossible sauf par les méthodes qui le font de
manière cohérente (méthode accélérer de l’accélérateur).
III.A.3.2 Usage et Notation
Les attributs sont en général inaccessibles (secret). Ils sont alors

qualifiés de :
- "protected" (notation UML : # )
- "private" (notation UML: - )
Leur lecture ou modification n'est possible qu'au travers de certaines

opérations (accesseurs : changerAdresse(), obtenirAge(), etc.).
Les opérations sont en général accessibles (publiques) : Elles sont alors

qualifiées de :
- "public" (notation UML: + )
54
Certaines opérations peuvent cependant être privées et certains
attributs peuvent être publics (non souhaitable / principe
d’encapsulation).
Visibilité des Attributs / Opérations

Public (+) : Visible et utilisable par toute autre classe (utilisation très
limitée pour les attributs).
Protected (#) : Visible et utilisable par toute les spécialisations de la
classe.
Private (-) : Visible uniquement par la classe elle-même.
Notation UML
55
III.A.3.3 Attributs et Opérations de Classe
Attributs et Opérations de Classe : Notation UML
56
III.A.3.4 Attribut dérivé
Syntaxe OCL : Object Constraint Langage
{Contexte Personne
Inv : age = dateCourante - dateNai ssance }
III.A.4 Surcharge & Polymorphisme
Définition
Le polymorphisme représente la faculté d'une méthode à pouvoir
s'appliquer à des objets de classes différentes. Ce qui signifie qu'une
même opération peut se traduire différemment selon l'objet sur
laquelle elle s'applique.
La surcharge (prototype de fonctions : plusieurs méthodes portant le

même nom à l’intérieur d’une classe). La surcharge est la possibilité
de donner le même nom à des méthodes ayant des signatures
différentes.
57
Une méthode est identifiée par sa signature (Nom de la méthode;
Nombre et/ou type de chaque paramètre).
Classes Paramétrables
III.A.5 Principaux Concepts du Diagramme de Classe
III.A.5.1 Associations entre Classes
58
III.A.5.2 Multiplicité, Nom d’Association, Nom de
Rôle
III.A.5.3 Nommage des Rôles
Le rôle décrit une extrémité d’une association.
Les noms des rôles sont obligatoires pour les associations réflexives.
59
Visibilité des Rôles :
Les rôles définissent des responsabilités.
Connaissant une personne on doit pouvoir retrouver ses employeurs ; il doit y

avoir une méthode publique dans « person » qui renvoie une collection
d’instances de « company ».
Exemple java :
Public Collection<Company> getEmployers()
III.A.5.4 Lien entre Objets
60
III.A.5.5 Classe d’Association
Associations ternaires
III.A.5.6 Qualificateurs : restriction de la cardinalité
La restriction (dite qualification en UML) d’une association consiste à

sélectionner un sous-ensemble d’objets parmi l’ensemble des objets qui
61
participent à une association. Elle est réalisée au moyen d’une clé. La clé
appartient à l’association et non aux classes associées.
Association Qualifiée
Une association qualifiée met en relation deux classes sur la base d’une clef.
III.A.5.7 Contraintes sur les Associations
Contrainte d’association : porte sur une relation ou sur un groupe de

relations (notée {contrainte}).
La contrainte {Ou-exclusif} précise que, pour un objet donné, une seule

association parmi un groupe d’associations est valide .
La contrainte {sous-ensemble} indique qu’une collection est incluse dans

une autre collection.
62
III.A.5.7.1 Object Constraint Language OCL
OCL (Object Constraint Language) est un langage informatique

d’expression des contraintes utilisé par UML. C'est une contribution
d'IBM à UML 1.1.
Ce langage formel est volontairement simple d'accès et représente un

juste milieu entre langage naturel et langage mathématique. Il permet
ainsi de limiter les ambigüités dans la spécification des contraintes
logicielles. Sa grammaire simple lui permet d'être interprété par des
outils logiciels pour faire de la programmation par contrat et vérifier
qu'un logiciel répond à ses spécifications techniques.
Pour spécifier complètement une application, les diagrammes UML

seuls sont généralement insuffisants. Il y’a toujours une nécessité de
rajouter des contraints.
Comment exprimer ces contraintes ?
- Langue naturelle mais avec manque de précision,

compréhension pouvant être ambiguë ;
- Langage formel avec sémantique précise : par exemple OCL.
OCL : Object Constraint Language
- Langage de contraintes orienté-objet ;
- Langage formel (mais « simple » à utiliser) avec une syntaxe,

une grammaire, une sémantique (manipulable par un outil) ;
- S'applique entre autres sur les diagrammes UML.
OCL peut s'appliquer sur la plupart des diagrammes UML.
Il sert, entre autres, à spécifier des :
- Invariants sur des classes ;
- Pré et post conditions sur des opérations ;
- Gardes sur transitions de diagrammes d'états ou de messages

de diagrammes de séquence/collaboration ;
- Des ensembles d'objets destinataires pour un envoi de

message ;
63
- Des attributs dérivés ;
- Des stéréotypes.
III.A.6 Types d’Associations
III.A.6.1 Agrégation
C'est une association qui exprime un couplage fort lié à une relation de
subordination, elle est asymétrique du type ensemble/élément.
Règles permettant de choisir une agrégation :
- Est ce que c’est une partie de?

- Les opérations appliquées à l'ensemble sont elles appliquées à
l'élément?
- Les changements d'états sont-ils liés ?
Mais
- Un élément agrégé peut être lié à d'autres classes ;

- La suppression de l'ensemble n'entraîne pas celle de l'élément.
Agrégation : Exemple
64
III.A.6.2 Composition : Agrégation forte
La composition est une agrégation forte qui lie les cycles de

vie entre le composé (ensemble) et les composants (éléments).
Le choix entre composition et agrégation peut être laissé à la

phase de conception.
Association, Agrégation ou Composition ?

Règles obligatoires pour la composition :
La suppression du composé entraîne elle la suppression des

composants ?
Les attributs du composé sont-ils utilisés dans les composants ?
Les composants sont des instances du composé ?
Un composant ne peut pas être en relation avec d'autres classes

externes au composé.
III.A.6.3 Exemples
La relation « gère » est-ce que c’est une Association simple ; une Agrégation
ou bien une composition ?
65
Exemple de Composition :
Fenêtre
scrollbar contrôle contenu

Ascenseur Bordure Panel
Fenêtre
scrollbar [2]: Ascenseur
contrôle : Bordure
contenu : Panel
III.A.7 Navigabilité
Par défaut une association est bidirectionnelle: à partir d’un objet d’une
des 2 classes, on peut atteindre les objets de l’autre classe.
Il est possible de réduire la portée en la rendant unidirectionnelle.
En général, ce choix se fait dans la phase de conception.
66
Navigabilité : Exemple
Etant donné un utilisateur; on désire pouvoir accéder a ces mots de passe.
Etant donné un mot de passe on ne souhaite pas accéder à l’utilisateur

correspondant.
67
III.A.8 Éléments sur une association : Résumé
Propriétés de mise à jour de liens :

La contrainte prédéfinie {frozen} interdit l'ajout, la suppression ou la
mise à jour des liens d'un objet vers les objets de la classe associée,
après l'initialisation du premier.
La contrainte prédéfinie {addOnly} autorise l'ajout de nouveaux liens,

mais pas leur suppression ni leur mise à jour.
A défaut, tout est autorisé.
Ordre sur les liens :

Dans le cas d'une multiplicité >1 les liens peuvent être :
unordered (c'est la valeur par défaut)
ordered
sorted : niveau implémentation (ordonnés sur une valeur interne).
68
III.A.9 Héritage
III.A.9.1 Héritage : Nouvelles classes dérivées de

classes existantes
BUT
Permettre une réutilisation optimale des classes déjà écrites, utilisées
et validées.
Réutilisation de la structure des données héritées.
Réutilisation du code des services hérités.
PRINCIPE
Ne pas modifier les classes déjà écrites cela modifierait l'utilisation qui
en est faite.
Ne pas hésiter à créer des classes, extensions d'autres déjà validées.
III.A.9.1.1 Généralisation / Spécialisation
Relation de spécialisation « est-un », « is-a-kind-of » entre classes :
La classe spécialisée (sous-classe) hérite des méthodes des attributs

et des relations de la classe générale (super-classe).
Elle peut ajouter des attributs / méthodes.
Elle peut redéfinir le comportement des méthodes (mais pas les

attributs).
69
III.A.9.1.2 Héritage : Adaptation
III.A.9.2 Héritage : Ajout d’une classe de base

(analyse)
BUT 2
Permettre une factorisation des caractéristiques et des comportements
communs à plusieurs classes.
Mise en commun des structures des données.
Mise en commun du code des services.
PRINCIPE
Lorsque plusieurs classes ont des caractéristiques et des comportements
communs la création d'une classe ancêtre permet de regrouper ce qui est
commun.
Cette classe ancêtre peut correspondre à une classe concrète ou à une

classe abstraite.
70
III.A.9.3 Héritage : Généralisation, Factorisation des
propriétés
Soit les deux classes suivantes : Permanent et Vacataire
On va factoriser les propriétés de ces deux classes en créant une super

classe Enseignant.
On suppose qu’il y a d’autre corps métier ; Ex : classes Avocat, Vendeur etc.
71
On va encore factoriser les propriétés communes aux trois classes Avocat,
Vendeur et Enseignant en créant une super classe Personne.
La contrainte OCL {Complète} indique la généralisation est terminée :

tout ajout de sous-classe est alors impossible.
72
A l’inverse, la contrainte {Incomplète} indique une généralisation
extensible.
La contrainte {Disjoint} (ou {exclusif}) indique la participation exclusive

d’un objet à l’une des collections spécialisées.
III.A.9.4 Héritage : Polymorphisme
BUT 3
Créer des sous-types (sous-classes). Une sous-classe sera du même
type que la classe dont elle hérite (super-classe).
Ceci permet de mettre en œuvre le polymorphisme et la liaison

dynamique.
PRINCIPE
Un objet d'une classe donnée pourra toujours faire référence à des
objets de ses sous classes (polymorphisme).
Une opération exécutée par un objet sera celle que connaît l'objet
dont il fait référence (liaison dynamique).
III.A.9.5 Héritage multiple et répété
73
La contrainte OCL {overlapping} : indique que la super-classe
possède des instances qui peuvent se recouvrir lors de la réunion de
celles de ses sous-classes.
Une instance (indirecte) de véhicule peut être une instance de véhicule

terrestre ou une instance de véhicule aquatique ou encore les deux
(soit une instance de véhicule amphibie). Le contraire, lorsqu'il y a une
partition exacte des instances par les sous-classes, se note :
{disjoint}. C'est la contrainte par défaut et qui correspond à un graphe
en forme d'arbre.
La réunion des instances de la classe Voiture avec celles de véhicule

amphibie donne les instances de véhicule terrestre.
III.A.10 Classe Abstraite
C’est une classe non instanciable définissant au moins un mécanisme

général instanciable par des classes filles.
Elle contient des opérations non définies :
Notation : abstract (java) ; virtual (C++)
Doit être spécialisée en une ou plusieurs classes non abstraites.
Notation : stéréotype «abstract», ou le nom de la classe est noté en

italique.
III.A.10.1 Exemple 1 : Classe abstraite Media
Un média peut être transporté, dupliqué, affiché.
Le transport et la duplication sont indépendants du type du média

(copie de fichiers).
Par contre, tout média peut être affiché et ce n'est pas la même chose
pour l'audio, la vidéo, le graphisme, le texte.
Un média ne peut pas définir comment s'afficher tant qu'il ne sait pas
ce qu'il est.
Il n'y a pas d'instance de la classe média.
Un média n’existe qu’en tant que livre, chanson, graphique ou vidéo.
74
La classe Media est une classe abstraite parce qu’elle définie une méthode
abstraite qui est la méthode afficher().
III.A.10.2 Exemple 2 : Classe abstraite Figure
75
La classe Figure est une classe abstraite parce qu’elle définie une
méthode abstraite qui est la méthode afficher().
Les sous classes 0_dimension, 1_dimension et 2_dimension sont

aussi des classes abstraites parce que la méthode afficher() n’est
toujours pas définie à ce niveau ; il faut connaitre le type de figure
pour pouvoir le faire.
III.A.11 Interfaces
Une interface est une classe sans attribut dont toutes les opérations
sont abstraites / virtuelles (non définie).
Elle ne peut pas être instanciée.
Elle doit être réalisée (implémentée) par des classes non abstraites.
Elle peut hériter d’une autre interface.
Une interface permet de décrire le comportement d'une entité (classe,

paquetage ou composant), c'est à dire un savoir faire sous la forme
d’une liste d’opérations.
Une interface ne peut donner lieu à aucune implémentation.
Une classe peut déclarer qu'elle implémente une interface. Elle doit
alors implémenter toutes les opérations de cette interface. Elle peut
ensuite être utilisée partout où ce comportement est exigé.
76
III.A.12 Paquetages
Une application est constituée de plusieurs lasses, des dizaines ou des

centaines. Il est important de les organiser en groupes (en fonction de
certains critères surtout logiques).
C'est le paquetage (package) qui permet ce regroupement.
Un paquetage regroupe des classes, des interfaces, des paquetages.
Il permet d'encapsuler certains éléments de la modélisation. Un
élément du paquetage peut être inaccessible de l'extérieur du
paquetage, il n'est alors connu que par les éléments du même
paquetage.
Il met en œuvre un espace de nommage.
Véhicule : : Voiture signifie que la classe Voiture appartient au paquetage

Véhicule.
77
SECTION B
de la
Gestion de Bibliothèque
-
Recherche à partir du Cahier
des Charges Recherche par
responsabilité
"Au cœur de toute difficulté se cache une

possibilité "
Albert Einstein
78
III.B.1 Phases de la modélisation Objet
Identifier les classes candidates.
Préparer le dictionnaire de données : classes retenues.
Identifier les associations entre classes (en incluant les agrégations).
Identifier les attributs.
Organiser et simplifier les classes en utilisant l'héritage.
Supprimer les associations inutiles
Vérifier que le diagramme inclut toutes les demandes du cahier des

charges.
Itérer et affiner le modèle.
Grouper les classes en modules (paquetages).
III.B.1.1 Identifier les Classes : Classes Candidates
Il commande un logiciel permettant aux utilisateurs de connaître les

livres présents, d'en réserver jusqu'à 2. L'adhérent peut connaître la
liste des livres qu'il a empruntés ou réservés.
L'adhérent possède un mot de passe qui lui est donné à son inscription.

Ce sont les employés qui mettent en bibliothèque les livres rendus et

les nouveaux livres. Il leur est possible de connaître l'ensemble des
prêts réalisés dans la bibliothèque
Les classes candidates sont :
Gérant bibliothèque gestion prêts logiciel

utilisateur livres adhérent liste mot de passe
inscription emprunt employés emprunteur ensemble.
79
III.B.1.2 Classes retenues
- gérant non pertinente, n'intervient pas.
- bibliothèque oui responsabilité : gérer les livres, adhérents, prêts.
- gestion non vague.
- prêts oui responsabilité : contenir les infos et actions sur les prêts.
- logiciel non vague.
- utilisateurs choix entre utilisateur, adhérent, emprunteur.

- livres oui responsabilité : permettre de connaître son état.
- adhérent oui responsabilité : permettre à la personne d'être identifiée
- liste non implémentation ou conception.
- mot de passe non attribut.
- Inscription non action.
- emprunt non action.
- employés oui responsabilité : reconnaître qui a fait un prêt, etc.
- emprunteur choix entre utilisateur, adhérent, emprunteur.
- ensemble non implémentation ou conception.
III.B.1.3 Dictionnaire des Données
bibliothèque : organisme gérant une collection de livres qui peuvent

être empruntés par ses adhérents. Une bibliothèque est gérée par ses
employés.
prêt : un prêt est caractérisé par le numéro du livre, la date, la durée.

Il ne peut être fait que par un adhérent.
livre : ouvrage pouvant être emprunté.
adhérent : personne inscrite à la bibliothèque.
employé : personne travaillant à la bibliothèque.
III.B.1.4 Chercher les Associations
80
Il commande un logiciel permettant aux utilisateurs de connaître les

livres présents, d'en réserver jusqu’à 2. L'adhérent peut connaître la
liste des livres qu'il a empruntés ou réservés.
L’adhérent possède un mot de passe qui lui est donné à son

inscription.
Ce sont les employés qui mettent en bibliothèque les livres rendus et

les nouveaux livres. Il leur est possible de connaître l'ensemble des
prêts réalisés dans la bibliothèque.
Associations sous entendues :

Un adhérent est inscrit à la bibliothèque.
La bibliothèque contient des livres.
Associations :
III.B.1.5 Chercher les Attributs
81
III.B.1.6 Généraliser par Héritage
82
SECTION C
DIAGRAMME D’OBJETS
-
OBJECT DIAGRAM
"Un problème ne peut être résolu en réfléchissant

de la même manière qu'il a été créé "
Albert Einstein
83
III.C.1 Diagramme d’Objets : Définition
Un diagramme d’objets représente les liens structurels entre instances

des classes.
Il facilite la compréhension de structures complexes.
Trois représentations possibles des instances.
Nom de l’objet
Nom de l’objet : Nom de la classe
: Nom de la classe
Les valeurs des attributs sont optionnelles ainsi que les liens entre
objets.
Diagramme de Classe Diagramme d’Objet
Les liens, instances des associations réflexives peuvent relier un objet

à lui-même.
84
Les objets composés de sous-objets peuvent être visualisés.
III.C.2 Diagramme d’Objets: Structures complexes
Les diagrammes d’objets facilitent la compréhension et l’élaboration d’un

diagramme de classes.
Exemple1 :
Bus Destination
1
+passager * 1
+conducteur
Personne
85
bus_Numero_100: Bus etudiant:Personne
conducteur:Personne
faculte_des_sciences: Destination
Exemple 2 :
III.C.3 Résumé
instance
Classe Objet
* 1 *
* *
relie relie
instance
Association Lien
1
*
*
Agrégation
Composition
instance
Diagramme de classes Diagramme d'objets
1
86
CHAPITRE IV
MODELE DYNAMIQUE
Diagramme de Séquence,
Diagramme de Communication
&
Diagramme d’Etats Transition
"La logique vous mènera d'un point A à un point

B. L'imagination vous mènera partout "
Albert Einstein
87
IV.1 Modèle Dynamique : Définition
Le modèle dynamique montre le comportement du système et

l’évolution des objets dans le temps.
Le modèle dynamique identifie les différents événements venant du

monde externe et montre l'enchaînement dans le système que
provoquent ces événements externes.
Evénement : Quelque chose qui se produit à un moment donné dans le

temps, et qui n'a pas de durée.
Exemples : l’utilisateur décroche son téléphone, le conducteur appuie

sur un bouton.
But du modèle dynamique :
Trouver les relations temporelles et événementielles entre les objets.
Définir les états des objets qui déterminent une réaction différente face à
un événement.
Trouver les actions effectuées par les objets suite à la réception

d’événements.
Place du modèle dynamique dans le processus de modélisation
88
IV.2 Diagrammes d'Interaction
Les diagrammes d’interaction ont pour but de modéliser la façon dont les
groupes d'objets collaborent pour réaliser un comportement donné.
Représentent la collaboration entre objets pour la réalisation d'un cas

d'utilisation ou la réalisation d’une opération.
Mettent en évidence l'expéditeur et le récepteur de l'événement.
Chaque événement reçu par un objet devra se traduire par une

opération pour le gérer dans le diagramme de classes.
IV.2.1 Diagrammes de Séquence
Montrent les interactions entre objets selon un point de vue temporel.
Le contexte des objets n'est pas représenté.
IV.2.2 Diagramme de Collaboration/Communication
Montre les interactions entre objets en insistant sur la structure spatiale

statique.
Exprime à la fois le contexte de groupe d'objets et l'interaction entre ces

objets.
Extension du diagramme d'objets.

89
SECTION A
Diagrammes de Séquence
-
SEQUENCES DIAGRAM
" Celui qui n'a jamais fait une erreur n'a sans
doute jamais essayé quelque chose de nouveau "
Albert Einstein
90
IV.A.1 Diagrammes de Séquence : Définition
Met en évidence l'aspect temporel (haut vers le bas).
Un objet a une ligne de vie représentée par une ligne verticale en

pointillé.
Une flèche reçue par un objet se traduit par l’exécution d’une opération.
La durée de vie de l’opération est symbolisée par un rectangle.
Certains objets vivent pendant tout le diagramme, d'autres sont activés

et/ou meurent pendant la séquence.
Il est possible de définir des choix et des itérations.
IV.A.2 Concepts principaux
1. Les participants (le plus souvent des objets) :
- Une ligne de vie
- Des zones d’actIV.Ation

2. Les messages
- L’opération et éventuellement ses paramètres

- Eventuellement son résultat
3. Des structures de contrôle
- Alt : conditionnelle
- Loop : boucle
- Réf : référence à un autre diagramme de séquence (= appel
de fonction)
- Etc.
91
IV.A.2.1 Participant : Représentation des acteurs
Rectangle + Ligne de vie
Nom_objet : nom_classe
IV.A.2.2 Messages
Communication entre les lignes de vie
appel de méthode
envoi d'un signal
création/destruction d'une instance
Syntaxe : attribut = nom_signal_ou_op (arguments) : valeur_retournée
92
IV.A.2.2.1 Types de messages
Appels de méthodes ou autres méthodes d'appels synchrones ;
Communication asynchrone : l'émetteur déclenche le stimulus et

passe immédiatement à la suite de l'exécution ;
Retours de procédures (ou de méthodes) : optionnel ;
Un objet peut s'envoyer des messages ;
Un message peut entraîner la création ou la destruction

d'objets ;
93
IV.A.2.2.2 Occurrence d'exécution
L’occurrence d’execution est aussi appelé « focus de contrôle » elle

correspond à la durée d'activité de l'objet ; ce qui représente le temps
durant lequel il est actif.
IV.A.2.2.3 Message trouvé; Création & Destruction

d’objets
Message trouvé = émetteur inconnu
Diagrammes de séquence : Exemple Création & Destruction d’objets
94
IV.A.2.3 Cadre d’interaction
Cadre qui englobe une partie du DS (un fragment) pour définir un

fonctionnement non séquentiel.
Alt : représente une alternative (if-then-else) ; fragment alternatif :

conditions dans les gardes.
Loop : c’est une boucle; fragment à répéter tant que la condition de
garde est vrai.
Opt : c’est un fragment optionnel qui sera exécuté si la garde est vraie.
Par : ce sont des fragments qui s’exécutent en parallèle.
Region : région critique dans laquelle un seul thread doit s’exécuter.
Ref : référence : passage à un autre diagramme de séquence.
IV.A.2.3.1 Diagramme de séquence : Exemple cadres
Mot réservé pour déclarer un diagramme de séquence
Nom du diagramme de séquence
95
Contrôle et diagrammes de séquences
IV.A.3 Diagramme de séquence : Réserver un Livre
IV.A.4 Diagramme de Classe: Ajout des opérations dans

96
les classes
97
SECTION B
Diagramme de
Collaboration entre Classes
Diagramme
de Communication
-
COMMUNICATION DIAGRAM
" La connaissance s'acquiert par l'expérience,

tout le reste n'est que de l'information. "
Albert Einstein
98
Diagramme Collaboration / Communication
Diagramme de collaboration (UML 1.X) ;
Diagramme de communication (UML 2.X) ;
Version simplifié du diagramme de séquence ;
2 vues différentes mais logiquement identiques : isomorphe ;
Diagramme de collaboration au niveau instance = diagramme de

communication.
IV.B.1 Diagramme de collaborations : Définition
Le diagramme de collaborations sous une forme distincte du

diagramme de séquences représente les interactions entre classes en
mettant moins en évidence l'aspect temporel.
Ce modèle explique la coopération entre objets pour la réalisation d'une

fonctionnalité, cette coopération implique les différents événements qui
se propagent d'un objet à l'autre. Un objet doit avoir une méthode
appropriée pour traiter chaque événement qu'il reçoit (message).
L'aspect temporel n'est pas complètement caché car chaque message

est numéroté.
Système
1 2
4
5 3
6
Le flot de données intervenant dans ces interactions peut être précisé.
99
IV.B.2 Diagramme de Communication : But & Principes
PRINCIPES :
Libre de placer les participants (objets) ;
On fait des liens entre eux, et on les numérote (interactions) ;
Pas de ligne de vie.
BUTS :
Comportement collectif d’objets ;
En vue de réaliser une opération.
DEFINITIONS :
Une collaboration est une collection d’objets et d’acteurs liés entre eux.
Une collaboration définit un ensemble de participants et de relations qui

sont sensés pour un périmètre donné.
Une collaboration entre deux objets travaillants ensemble produit une

fonctionnalité.
Les objets collaborent entre eux par communications (s’échangeant des

messages).
QUAND L’UTILISER ?
Phase de cadrage.
Début de projet pour clarifier le domaine d’étude.
Représenter collaboration entre le domaine d’étude et les partenaires
Permet de déterminer :
Les flux entrants ;
Les flux sortants ;
Les acteurs externes ;
Les domaines connexes.
100
QUOI UTILISER ?
Diagramme de séquence ou Diagramme de communication ?
Majorité des personnes : Diagramme de séquence ;
Diagramme de communication : Adapté pour montrer les

liens ;
Diagramme de séquence: Importance des messages ;
IV.B.3 Principaux Concepts
1. Les Objets
2. Les liens d’interactions
3. Les Messages
IV.B.3.1 Objet : Représentation graphique
Représenté par un
rectangle
Nommage : Nom de
l’objet instancié
Nom de l’objet et
nom de la classe
Nom de la classe
UML 2.X : Plus de soulignement
101
IV.B.3.2 Liens d’interactions
Les liens indiquent un chemin de communication entre 2 objets, sur lequel

passent les messages.
Lien d’interaction
Exemples :
IV.B.3.3 Messages : Types
Synchrone
L’expéditeur est bloqué pendant le
traitement du message par l'expéditeur
Retour d'appel Un message synchrone peut être un
appel de procédure, le retour peut être
représenté
Asynchrone L'expéditeur continue son exécution
pendant le traitement du message
Minuté Comme le synchrone, mais un chien de
garde est positionné, c'est à dire que
l'expéditeur se réveille au bout d'un certain
temps s'il ne reçoit pas de réponse.
102
Informations portées sur les messages :
[pré "/"] [["["cond"]"] [séq] ["*"["||"]["["iter"]"]]":"] [r ":="]

msg"("[par]")"
pré : numéro des messages prédécesseurs

cond : condition, garde d'envoi du message
séq : numéro de séquence du message
* : itération, || : en parallèle
iter : détaille l'itération
r : stocke la valeur de retour du message
msg : nom de l'opération à appeler
par : paramètres de l'opération
Exemples :
[heure = midi] 1 : manger()

3 / *[i := 1..5] : fermer()
1.3, 2.1 / [t < 10s] 2.5 : age := demanderAge(nom)
IV.B.4 Diagramme de collaboration : Réserver un livre
103
SECTION C
Diagrammes Etats –
Transitions
-
STATE MACHINE DIAGRAM
" "Ne me dites pas que ce problème est difficile.

S'il n'était pas difficile, ce ne serait pas un
problème. "
Maréchal Foch
104
IV.C.1 Diagramme d’Etats : Définition
Le diagramme d’états de transition décrit:
Le comportement des objets d’une classe au moyen d’un automate

d’états associés à la classe qui est modélisé par un graphe.
Une transition :
exécution d’une action.
réaction de l’objet sous l’effet d’une occurrence d’événement.
Un cycle de vie d’un objet d’une classe :
Les états qui peuvent être pris par les objets d’une classe.
Les événements qui provoquent la transition d’un état à un

autre.
Les actions subies/provoquées qui accompagnent un

changement d’état.
Les activités qui surviennent tant que l’objet est dans un état
donné.
IV.C.2 Diagramme d’Etats : Objectif
Etudier les états d’un Système d’Information :
Comprendre le système d’information en s’intéressant aux classes qui

présentent des traitements complexes.
Fournir une représentation dynamique du comportement des objets

d’une classe.
Aider à déterminer les événements qui occasionnent les transitions.
Aider à déterminer les opérations qui vont permettre ces transitions.
IV.C.3 Diagramme d’Etats : Notion d’état
Un état = étape dans le cycle de vie d’un objet.
Chaque objet possède à un instant donné un état particulier.
105
Chaque état est identifié par un nom.
Un état est stable et durable.
Chaque diagramme d’états-transitions comprend un état.
Il est possible de n’avoir aucun état final : un système qui ne s’arrête

jamais.
IV.C.3.1 Etats spéciaux
2 états prédéfinis:
état de démarrage : obligatoire, unique.
état de fin : optionnel, peut-être multiple.
IV.C.3.2 Etats imbriqués-composite
Si le diagramme d’état transition devient trop complexe, on peut

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

états appelés sous-états • Le nombre d’imbrication n’est pas limité
(ne pas abusé sinon problème de lisibilité).
Etats imbriqués-composite : Exemple
106
IV.C.4 Diagramme d’Etats : Notions d’évènement
Un événement :
correspond à l’occurrence d’une situation donnée dans le domaine

étudié.
est une information instantanée qui doit être traitée à l’instant où elle se
produit.
La description complète d’un événement est donnée par :
Nom de l’événement
Liste des paramètres
Objet expéditeur
Objet destinataire
Description textuelle
107
IV.C.4.1 Notions de garde
Une garde est une condition booléenne qui permet ou non le

déclenchement d’une transition lors de l’occurrence d’un événement.
IV.C.4.2 Notions de transitions
Les états sont reliés par des connexions unidirectionnelles appelées

transitions.
Exemple : place de parking
Communications entre les objets par évènements
La communication est de type asynchrone, atomique et

unidirectionnelle.
108
IV.C.5 Diagramme d’Etats : Notions d’opérations et
actions
Action et activités: Le lien entre les opérations définies dans la spécification

d’une classe et les événements apparaissant dans le diagramme d’états-
transitions:
Chaque transition peut avoir une action à exécuter lorsqu’elle est

déclenchée
L’action est considérée comme instantanée et atomique
Une action correspond à l’exécution d’une des opérations déclarées

dans la classe de l’objet destinataire de l’événement.
L’action a accès aux paramètres de l’événement ainsi qu’aux attributs

de l’objet sur lequel elle s’applique.
Notions d’opérations et actions

Contrairement à une action, une activité est une opération qui dure un
certain temps.
Les activités sont associées aux états:
commencent quand on est entré dans l’état.
s’exécutent jusqu’à la fin si elles ne sont pas interrompues par

une transition sortante (donc tant que l’état ne change pas).
peuvent être interrompues car elles ne modifient pas l’état de

l’objet.
Les activités sont notées dans la partie inférieure de l’état.
109
IV.C.6 Diagramme d’Etats : Syntaxe
Syntaxe d'une transition:
événement [garde] / action
Chaque partie est optionnelle.
La transition est suivie si l'événement a été généré et que la garde

est valide.
Exécute alors l'action avant de rentrer dans l'état ciblé par la

transition.
Attention : pas deux transitions possibles partant d'un même état.
Syntaxe des activités que l'on peut associer à un état :
do / action : action exécutée dans l'état ;
entry / action : action exécutée à l'entrée dans ;
exit / action : action exécutée à la sortie de l'état ;
evt / action : transition interne pour l'occurrence de l'événement

evt.
Lien avec l'objet associé au diagramme d'états :
Les actions peuvent être les méthodes de la classe de l'objet.
Peut utiliser les attributs de l'objet, par exemple dans les gardes
des transitions.
110
IV.C.7 Résumé
Diagramme d'états décrit le comportement interne d'un objet ;
Permet la définition de tous les états possibles d'un objet ;
La définition de tous les changements d'états via des transitions ;
Il est associé à un objet ou à une opération.
Etat d’un objet: Situation d’un objet que l’on désire connaître et
gérer.
Transition: Passage d’un objet d’un état à un autre. Elle est
déclenchée par un événement.
Evénement: Stimulus qui provoque une (ou plusieurs)
transition(s). A chaque stimulus peut correspondre une action
responsable des modifications de l’objet (les valeurs des
attributs).
IV.C.8 Cas de la bibliothèque : Recherche des états
111
L’état d'un objet est lié aux valeurs de ses variables d'instances et des
interactions avec les autres objets. Il s'agit de ne conserver que les
états significatifs.
La réponse d'un objet à un événement dépend de l'état dans lequel cet

objet se trouve.
Un objet passe dans un état donné par l'événement qui modifie ses
variables, et quitte cet état par un autre événement qui les modifie à
nouveau. Ce sont des transitions d'états.
IV.C.8.1 Diagramme de transitions d’états : Livre
Chaque transition est provoquée par un événement.
Une transition n'a pas de durée.
La durée d'un état est l'intervalle de temps qui s'écoule entre

l'événement d'entrée et celui de départ .
112
IV.C.8.2 Diagramme de transitions d’états : Adhérent
113
CHAPITRE V
Diagramme de Composants
-
Diagramme de Déploiement
&
Diagramme de Structure
Composite
" Il n'y a pas de question idiote, seulement une

réponse idiote "
Albert Einstein
114
SECTION A
Diagrammes de Composants
-
COMPONENT DIAGRAM
" L'école devrait toujours avoir pour but de

donner à ses élèves une personnalité harmonieuse,
et non de les former en spécialiste "
Albert Einstein
115
V.A.1 Notion de composant
Dans le monde du bâtiment, le modèle de l’architecte (logique) permet

de visualiser, spécifier et documenter sur papier les caractéristiques de
la future construction : place des murs, des fenêtres, etc.
Lors de la construction, on utilise des composants fenêtres, portes,

murs. Ce sont des choses physiques qui existent dans le monde réel.
Ils rendent des services mais définissent leurs exigences (taille, espace,
etc.).
De même, dans un système informatique, le modèle logique dans une

application permet de visualiser, spécifier et documenter la structure et
le comportement des entités qui collaborent.
La construction va s appuyer sur des composants qui existent dans le

monde des ordinateurs : librairies, fichiers, tables, documents
exécutables, etc.
Un composant définit les services qu'il rend et aussi les services dont il
est en attente pour pouvoir fonctionner.
V.A.2 Diagrammes de Composants : Définition
Ce modèle définit l'architecture logicielle du système dans un

environnement de développement donné.
Il est issu de la conception et permet de représente
r le système et les sous systèmes du modèle physique de l'architecture

logicielle à réaliser.
Un système ou un sous système défini un espace de visibilité et

regroupe des classes.
Décrit les composant et leurs dépendance dans l’environnement de

réalisation.
Vue statique de l’implémentation du système illustrant les choix de

réalisation.
Les diagrammes de composant sont composée de :
116
Description des implémentations du système (composants)
Groupes d’implémentation (modules)
Relations entre divers implémentation (dépendances)
V.A.3 Concepts de Base
V.A.3.1 Composant
Un composant est une partie physique et remplaçable d’un système

qui sait faire et fournit la réalisation d’un ensemble d’interfaces.
Elément physique représentant une partie de l’implémentation du

système:
– Code (source, binaire, exécutable);

– Script, fichier de commande;
– Fichier de données, table, etc.
Un composant implante des services utilisables par d’autres
composants
UML propose des stéréotypes de composant :
«document»: un document quelconque;
«exécutable»: un programme qui peut s’exécuter sur un nœud;
«fichier»: un document contenant du code source ou des

données;
« bibliothèque»: une bibliothèque statique ou dynamique;
« table»: une table d’une base de données relationnelle;
En général un composant représente l’implémentation d’une classe;

Ex : le composant java nommé java.lang.String est l’implémentation
d’une classe nommée String;
117
Si un composant implémente plusieurs classes ces dernières sont
notées comme suit (visibilités +;-)
L’instance d’un composant est représentée par un composant dont le

nom est souligné
V.A.3.2 Interface et Composant
Le composant encapsule l’état et le comportement d’un ensemble de

classifiers (classes, composants…)
Elément spécifiant ses interactions avec l’extérieur via la définition de

ses interfaces fournis et requises:
Interfaces fournies: « provided interfaces »
Interfaces requises : « required interfaces »
On connecte une interface requise d’un composant à l’interface

fournie compatible d’un autre composant : assemblage.
118
Un composant offre une interface, mais exige la disposition de
certains services.
V.A.3.3 Module
Représente une unité pour le regroupement et la manipulation des

composants;
Ex: le module java java.lang contient les composants String, Integer, etc.
Représentation non standard :
V.A.3.4 Dépendance
Les rubriques suivantes présentent les relations qu’on utiliser dans les
diagrammes de composants :
Relations d'abstraction
119
Une relation d'abstraction est une dépendance entre des éléments de
modèle qui représente le même concept à différents niveaux d'abstraction
ou de différents points de vue. Vous pouvez ajouter des relations
d'abstraction à un modèle dans différents diagrammes, tels que les
diagrammes de cas d'utilisation, de classes et de composants.
Relations d'association
Dans les modèles UML, une association est une relation entre deux
discriminants, tels que des classes ou des cas d'utilisation, qui décrit les
causes de la relation et les règles qui régissent la relation.
Relations de réalisation d'interface
Dans les diagrammes UML, une relation de réalisation d'interface est un type
spécialisé de relation d'implémentation entre un discriminant et une interface
fournie. La relation de réalisation d'interface spécifie que le discriminant
réalisant doit se conformer au contrat spécifié par l'interface fournie.
Relations de réalisation
En modélisation UML, une relation de réalisation est une relation entre deux
éléments de modèle, dans laquelle un élément de modèle (le client) réalise le
comportement que l'autre élément de modèle (le fournisseur) spécifie.
Plusieurs clients peuvent réaliser le comportement d'un seul fournisseur.
Vous pouvez utiliser des relations de réalisation dans les diagrammes de
classes et les diagrammes de composants.
Relations d'utilisation
En modélisation UML, une relation d'utilisation est un type de relation de

dépendance dans laquelle un élément de modèle (le client) nécessite un
autre élément de modèle (le fournisseur) pour une implémentation ou une
opération complète.
Représente les relations de dépendance entre composants/modules.
Illustre l’utilisation des services d’un composant par un autre

composant.
120
V.A.3.5 Processus et Thread
Les processus et tâches (thread) peuvent être représentés par un

composant;
Un processus ou une tâche est caractérisée par son propre flot de

contrôle;
UML propose les stéréotypes « processus » et « thread »
V.A.3.6 Composant, Port & Connecteurs
Composant composite :
Composant peut être formé de composants internes assemblés par

leurs interfaces ;
Composition hiérarchiques des composants.
Port :
Point d’interaction du composant ;
Associé a une interface d’opérations(en mode requis ou fournis).
121
Connecteurs :
De délégation: lie un port du composite à un port d’un de ces

éléments.
D’assemblage : lie une interface d’un élément interne avec celle d’un
autre élément interne.
V.A.4 Diagrammes de Composants : Exemple Agenda
Un agenda contient un ensemble de personnes.
Un agenda possède un propriétaire.
Chaque personne est identifiée par son nom et par un ensemble

de coordonnées.
Une coordonnée peut être postale, téléphonique ou électronique
(email ou page web).
Une adresse email n’appartient qu’à une seule personne.
122
Diagramme de Composants
123
V.A.5 Diagramme de Composants : Exemple Tickets
124
SECTION B
Diagrammes de Déploiement
-
DEPLOYMENT DIAGRAM
" Ce que nous devons apprendre à faire, nous

l'apprenons en le faisant "
Aristote
125
V.B.1 Diagrammes de Déploiement : Définition &
Objectif
Ce modèle définit le diagramme de l'architecture matérielle du système

ou de l'application.
Il représente les différents processeurs, périphériques et la répartition

du système sur ces différents éléments.
Il montre les liens de communication entre ces différentes entités.
Le diagramme a pour objectif de :
Etablir la cartographie complète de déploiement du logiciel sur le

matériel.
Visualiser la topologie matérielle d’un système.
Etablir la nature des connexions reliant les éléments matériels du

système.
Permet de visualiser les éléments matériels et logiciels d’un système
et la manière dont ils sont mis en œuvre pour faire fonctionner ce
système.
Eléments matériels: ordinateurs, périphériques, et les liens de

communications qui les relient.
Eléments logiciels: existant comme des bibliothèques ou des

SGBD et ceux résultant du processus de développement et la
manière dont ils sont affectés aux différents éléments matériels.
V.B.2 Concept du Nœud
Un nœud est une ressource informatique sur la quelle on peut placer un

élément logiciel (programme,…) en vue d’une exécution.
Ce nœud est alors considéré comme la cible de déploiement

(deployment target) pour l’élément logiciel.
Ce nœud peut être un nœud complexe qui contient des «sous-

nœuds».
Représentation graphique
126
Les nœuds sont représentés sous forme de boîtes.
Les boîtes peuvent être nommées en respectant une syntaxe proche de

celle utilisée pour les diagrammes de classes.
V.B.2.1 L’appareil (device)
Un appareil (device) est un sorte de nœud qui correspond à une

ressource informatique matérielle (comme un ordinateur ) qui est
dotée d’une capacité d’exécution.
Ce device est représenté par un nœud, avec le stéréotype <<device>>

au dessus du nom.
V.B.2.2 L’environnement d’exécution
L’environnement d’exécution « execution environment » est un autre

sorte de nœud qui correspond à une ressource informatique logicielle
qui est dotée d’une capacité d’exécution.
Un système d’exploitation est, par exemple, considéré comme

l’environnement d’exécution qui permet à des logiciels de fonctionner.
Le système d’exploitation est placé sur un ordinateur.
127
V.B.3 Les chemins de communication
Un chemin de communication est une association entre deux nœuds

susceptibles de s’échanger des signaux et des messages.
On peut y préciser des informations complémentaires comme: les

cardinalités; des contraintes et des stéréotypes.
V.B.4 Artefact : Définition
Un artéfact est un terme générique pour désigner des données ou des

programmes placés dans un fichier (au sens large).
Exemple d’artéfacts :
fichiers sources d’un programme ;

scripts ;
exécutables binaires ;
tables dans une base de données ;
livrable dans un processus de développement ;
document issu d’un traitement de texte ;
Mail; etc.
128
Représentation graphique :
Un artéfact est représenté comme une classe munie du stéréotype
<<artifact >>.
Lien avec le composant logiciel :

L’artéfact correspond également à la manifestation d’un composant
logiciel (qui représente un modèle).
Par exemple, un composant logiciel implanté en Java comporte

plusieurs classes. Lorsqu’on le compile, on obtient un ensemble de
fichiers .class qui peuvent être regroupés dans un .jar . Le composant
logiciel se manifeste donc sous la forme d’un fichier .jar.
D’un point de vue modélisation seul les artéfacts peuvent être déployés
au niveau d’un nœud et non les composants qui représentent des
modèles.
Il est possible de représenter cette manifestation sous la forme d’un lien

de dépendance entre l’artéfact et le composant logiciel.
V.B.5 Déploiement
Pour indiquer qu’un artéfact est déployé sur un nœud, on peut représenter
l’artéfact à l’intérieur du nœud.
129
V.B.6 Diagramme de Déploiement : Exemples
130
V.B.6 Diagrammes de Déploiement de l'application
Bibliothèque
Serveur stockage
document
documents
Livre Revues
BandeDessinées
Résumé
131
SECTION C
Diagrammes de Structure
Composites
-
COMPOSITE STRUCTURE
DIAGRAM
" Soyez insatiables, soyez fous. Ce n'est pas

dans le statu quo qu'on prépare un avenir
meilleur "
Steve Jobs
132
V.C.1 Diagramme de Structure Composite : Définition &
Objectifs
Dans le langage UML, le diagramme de structure composite expose la

structure interne d'une classe ainsi que les collaborations que cette
dernière rend possible.
Une structure composite est un ensemble d'éléments interconnectés

collaborant dans un but commun lors de l’exécution d'une tâche.
Chaque élément se voit attribuer un rôle dans la collaboration .
Objectif
Les diagrammes de structure composites peuvent être utilisés pour décrire
les :
structures de parties interconnectées ;

structures d'exécution des instances interconnectées ;
Exemple: Description des parties d'un moteur qui sont reliés entre
eux pour réaliser le fonctionnement du moteur.
V.C.2 Diagramme de Structure Composite : Concept
Les éléments clés du diagramme de structure composite sont les :

1. Classificateurs structurés,
2. Parties,
3. Ports,
4. Connecteurs,
5. Collaborations.
V.C.2.1 Classificateurs Structurés
Un classificateur structuré représente une classe, dans la plupart

des cas une classe abstraite, dont le comportement peut être décrit
complètement ou partiellement par le biais d'interactions entre parties.
Un classificateur encapsulé est une forme de classificateur structuré

contenant des ports.
133
Classifieurs structurés : Propriété
Un ensemble d'instances regroupées dans une instance

structuré
Rôle des instances de

classe des proprietés
pour le conteneur Types ou
de occurrences
(facultatif) (obligatoire) MailSender
ms:MailSender
roleName:rRoleName : TypeName
ms:MailSender
sendMail(…
)
134
V.C.2.2 Eléments du diagramme : Parties
Une partie représente un rôle joué par une instance d'une classe ou un
ensemble d'instances à l'exécution.
La partie peut donner le nom d'un rôle, d'une super-classe abstraite ou

d'une classe concrète spécifique.
La partie peut inclure une cardinalité.
V.C.2.3 Eléments du diagramme : Ports
Un port est crée à l'extérieur d'un classificateur, il spécifie un point

d'interaction distinct :
Entre le classificateur et son environnement : port de service
Entre le classificateur et ses parties internes : port de comportement
V.C.2.3.1 Ports de Service
Un Port de service est utilisé pour désigner le classificateur en tant que

fournisseur de services avec des fonctionnalités publiées, il précise les
services qu’un classificateur fournit (offre) à son environnement ainsi que
les services qu’un classificateur attend (exige) de son environnement.
Les interfaces requises d’un port caractérisent les demandes qui

peuvent être faites du classificateur à son environnement par ce port.
Les interfaces fournies d’un port caractérisent les demandes au

classificateur que les autres classificateurs peuvent faire à ce port.
135
V.C.2.3.2 Ports de Comportement
Un port est de comportement si les demandes arrivant à ce port sont

envoyées au comportement du classificateur possédant le port.
Les ports peuvent déléguer les requêtes reçues à des parties internes
ou au contraire les délivrer directement à la partie qui possède le port
en question. Les ports ayant un statut public sont dessinés à cheval sur
la bordure de la partie. À l'inverse, les ports protégés (non visibles par
l'environnement) sont contenus dans la partie.
V.C.2.3.3 Ports : Exemple
Structure avec de nombreux types de connecteurs et de ports:
136
V.C.2.3.4 Ports & Interfaces : Exemples
V.C.2.4 Eléments du diagramme : Connecteurs
Les connecteurs relient plusieurs entités, leur permettant d'interagir entre

elles lors de l'exécution. Un connecteur est représenté par une ligne reliant
une combinaison de parties, des ports ou des classificateurs structurés.
Connecteurs - Syntaxe
Représente :
la visibilité entre deux propriétés ;
un moyen de communication
137
V.C.2.5 Eléments du diagramme : Collaboration
Une collaboration est en général d'un niveau d'abstraction plus élevé qu'un
classifieur. Elle est représentée par un ovale en pointillé contenant les rôles
joué par chaque instance dans la collaboration lors de l'exécution .
138
V.C.3 Exemples de Collaboration
Exemple1 : Collaboration Vente
Example 2: Collaboration Drive a taxi
139
Exemple3: Structured Class House
V.C.4 Diagramme de Structure Composite versus

Diagramme de Classe
Le diagramme de structure composite n’a pas n’a pas vocation à

remplacer le diagramme de classes mais à le compléter.
Dans le diagramme de structure composite l’objet composé est décrit par

un classificateur tandis que ses composants sont décrits par des parties.
Un classificateur et une partie sont associés à une classe, dont la

description complète est réalisée dans un diagramme de classes.
140
Exemple :
141
CHAPITRE VI
Diagramme d’Activité
-
Diagramme de Globale
Interaction
&
Diagramme de Paquetage
Le peu qu'on peut faire, le très peu qu'on peut

faire, il faut le faire "
Théodore Monod
142
SECTION A
Diagramme d’Activité
-
ACTIVITY DIAGRAM
" L'information n'est pas la connaissance. La

seule source de connaissances est l'expérience.
Vous avez besoin d'expérience pour acquérir la
sagesse "
Albert Einstein
143
VI.A.1 Diagrammes d’Activité : Définition
Variante des diagrammes d’états-transitions;
Le diagramme d’activité permet de représenter le comportement

interne d’un use case ou processus;
Représente le déroulement des traitements en les regroupant dans des

étapes appelées « Activité »;
La question réside dans comment décomposer les traitements,

jusqu’où aller dans la décomposition (quels critères) ;
Représente la dynamique du système;
Montre l’enchaînement des activités d’un système ou d’une opération;
Représente le flot de contrôle qui retrace le fil d’exécution et qui transite

d’une activité à l’autre dans le système;
Représentent des diagrammes d’états transitions particuliers utilisés de

façon duale par rapport aux diagrammes d’états transitions: les
diagrammes d’états transitions sont centrés sur les états, les
diagrammes d’activités sont centrés sur les activités qui modifient l’état
d’un système;
Modélise le comportement interne, d’une classe, d’un cas d’utilisation

ou l’implémentation d’une opération sous forme d’une succession
d’actions.
VI.A.2 Diagrammes d’Activité : Intérêt
Représenter une succession d’états synchrones (alors qu’on préférera

les diagrammes d’états transitions pour représenter une suite d’états
asynchrones).
Ne pas nécessiter l’existence d’événements de transition pour avoir un

changement d’état : les changements d’états s’effectuent à la fin des
actions.
Le diagramme d’activité est le plus approprié pour modéliser la

dynamique d’une tâche, d’un use case lorsque le diagramme de classe
n’est pas encore stabilisé.
144
Les diagrammes d'activité sont utilisés pour :
Décrire un comportement qui est parallèle;
Montrer comment les comportements dans plusieurs use cases

agissent les un sur les autres;
Décrire des opérations composées de suites d'actions élémentaires

continues; • Clarifier des cas compliqués d'utilisation;
Montrer la logique d'un algorithme.
VI.A.3 Concepts du diagramme d’activité
Activité
Etats: état de départ et état de terminaison
Transitions : ensemble d’activités liés par:
Transition simple (séquentielle)
Transitions alternatives (conditionnelle)
Synchronisation (disjonction et conjonctions d’activités)
Itération
Swimlanes: représente le lieu, le responsable des activités.
VI.A.3.1 Concept: Activité
L’activité est un concept d’UML 2.x Elle est modélisée dans un

diagramme d’activité (activity diagram).
Une activité (activity) décrit l’exécution de fonctionnalités ou de

comportements. Elle est modélisée par plusieurs nœuds reliés par des
flèches.
Une activité représente une exécution d'un mécanisme, un

déroulement d'étapes séquentielles.
145
Nœud d’objet
Souvent, différentes activités manipulent un même objet qui change
alors d’état selon le degré d’avancement du mécanisme.
Deux utilisations :
Une information associée à l’activité (lié par une flèche en

pointillés) pour indiquer qu’un message initialise l’objet visé dans
l’état indiqué entre crochet. UML V1.
Un résultat de l’activité (lié par une flèche pleine) et repris

comme événement pour l’activité suivante. UML V2.
Exemple1 Exemple 2
VI.A.3.2 Concept : Etat
Un état est un point où un certain événement doit avoir lieu avant

que l'activité puisse continuer.
Etat départ : Ceci montre le point de départ ou la première activité

de l'écoulement ; dénoté par un cercle plein.
Etat final : L'extrémité du diagramme d'activité est montrée par un

symbole de boudine, également appelé activité finale.
VI.A.3.3 Concept : Transition
VI.A.3.3.1 Transition simple
Une transition est le passage instantané et automatique à l'action

suivante.
Les transitions sont déclenchées par la fin d'une activité et

provoquent le début immédiat d'une autre (elles sont automatiques).
146
VI.A.3.3.2 Transition alternative
Une alternative spécifie des chemins alternatifs, chacun basé sur la

valeur d'une expression booléenne (condition de garde).
Une garde est une condition booléenne qui valide ou non le

déclenchement d’une transition.
Les conditions de garde ne doivent pas se chevaucher.
Les conditions de garde doivent couvrir tous les cas possibles.
Le mot clé sinon peut être utilisé pour couvrir les chemins non déjà
couverts par des conditions de garde.
Représentation graphique d'une alternative
147
VI.A.3.3.3 Synchronisation
Il est possible de synchroniser les transitions à l'aide des "barres de

synchronisation" ;
Une barre de synchronisation permet d'ouvrir et de fermer des branches

parallèles au sein d'un flot d'exécution ;
Les transitions qui partent d'une barre de synchronisation ont lieu en

même temps ;
On ne franchit une barre de synchronisation qu'après réalisation de

toutes les transitions qui s'y rattachent ;
Deux types de synchronisation :
Synchronisation conjonctive : plusieurs transitions entrantes et

une seule sortante;
Synchronisation disjonctive (embranchement) :
- Un embranchement est la décomposition du flux de contrôle

en deux ou plusieurs flux de contrôle.
- Un embranchement permet de spécifier des activités

concurrentes (notion de parallélisme).
On représente une synchronisation et le parallélisme par une barre verticale

ou horizontale :
Parallélisme utilisé pour représenter des déroulements parallèles.
Synchronisation utilisée pour représenter la fin des traitements

parallèles.
148
Synchronisation – Exemple
149
VI.A.3.3.4 Itération
Boucle (ou itération)
Activité : ‘assigner employés à campagne’ est répétée jusqu’à ce qu’il

n’y ait plus de ‘employé’ à assigner à cette campagne particulière .
VI.A.3.4 Swimlanes
Coupage (Couloir d’activité – Swimlane):
Pour montrer les différentes responsabilités au sein d’un

mécanisme ou d’une organisation, on schématise des couloirs
d’activités.
Chaque activité est allouée à un couloir correspondant à la

ressource concernée : partenaire, travailleur.
150
VI.A.4 Diagrammes d’Activité : Exemples
Exemple 1 - Cafetière
Construire un diagramme d’activité représentant l’utilisation d’une cafetière
électrique:
premier état: chercher du café ;
dernier état: Servir du café.
151
Cafetière: Solution possible
Exemple 2 – Commander un produit

Construire un diagramme d’activité pour modéliser le processus de
commander d’un produit. Le processus concerne les acteurs suivants:
Client : qui commande un produit et qui paie la facture ;
Caisse : qui encaisse l’argent du client ;
Vente : qui s’occupe de traiter et de facturer la commande du client ;
Entrepôt : qui est responsable de sortir les articles et d’expédier la

commande.
Commander un Produit: Solution possible

152
VI.A.3.5 Diagrammes d’Activité : Résume
Les éléments-clé des diagrammes d'activité sont :

Activités: actions dont la complétion d'une d'entre elles entraine
automatiquement une transition vers la prochaine étape du processus.
Transitions : un mouvement d'une activité vers une autre.
Conditions de garde : règles décrivant dans quelles circonstances une
transition pourra se produire.
Etat de départ / état initial : Etat initial du système au début du
processus.
Etat de fin / final, ou point de sortie : Un processus peut avoir plusieurs
points de sortie, chacun relié à une post-condition spécifique (c.a.d.
une condition vérifiée quand le processus se termine).
Swimlanes (Couloirs) : Optionnels; Ils montrent comment différents
objets prennent la responsabilité d'effectuer certaines actions.
153
SECTION B
Diagramme
Globale Interaction
-
INTERACTION OVERVIEW
DIAGRAM
" Essaie de devenir ce que tu veux plutôt

que ce qu'ils veulent que tu sois "
Bob Marley
154
VI.B.1 Interaction : Définition
Une interaction montre le comportement d’un classeur structuré ou

d’une collaboration en se focalisant sur l’échange d’informations entre
les éléments du classeur ou de la collaboration.
Une interaction contient un jeu de ligne de vie. Chaque ligne de vie

correspond à une partie interne d’un classeur ou d’une collaboration.
Une interaction décrit donc l’activité interne des éléments du classeur

ou de la collaboration, appelés lignes de vie, par les messages qu’ils
échangent.
UML propose principalement deux diagrammes pour illustrer une

interaction : le diagramme de communication et celui de séquence. Une
même interaction peut être présentée aussi bien par l’un que par l’autre.
Une interaction a pour effet de produire une modification de l'état des

objets en interaction.
VI.B.2 Diagrammes Globale Interaction : Définition
Apparut dans la version 2.0 d’UML pour combler les insuffisances des
diagrammes d’activités et de séquence.
Variante des diagrammes d’activités où les nœuds peuvent être des

diagrammes de séquence.
Met le focus sur le flot général de contrôle dans lequel chaque nœud
représente un diagramme d'interactions. Il s'agit d'un cas spécial de
diagramme d'activités.
Dispose d’un pouvoir d’expression qui lui permet de montrer l’interaction

des composants d’un système à un haut niveau d’abstraction.
Sa force réside dans sa capacité d’exhiber les dépendances entre les

séquences d’un système par le biais d’un diagramme d’activités.
Représentation synthétique de la dynamique.
Permet d’éviter l’utilisation abusive de fragment d’interaction.
Définit les interactions au travers d’une variante du diagramme

d’activités.
155
Cherche à mettre en évidence une vue globale du flux de contrôle.
Les nœuds sont des interactions.
Les lignes de vies et les messages n’apparaissent pas à ce niveau.
Mélange diagramme de séquences et diagramme d’activités
Met le focus sur le flot général de contrôle dans lequel chaque nœud
représente un diagramme d'interactions. Il s'agit d'un cas spécial de
diagramme d'activités.
Dispose d’un pouvoir d’expression qui lui permet de montrer

l’interaction des composants d’un système à un haut niveau
d’abstraction.
Sa force réside dans sa capacité d’exhiber les dépendances entre les

séquences d’un système par le biais d’un diagramme d’activités.
Représentation synthétique de la dynamique.
Permet d’éviter l’utilisation abusive de fragment d’interaction.
Définit les interactions au travers d’une variante du diagramme

d’activités.
Cherche à mettre en évidence une vue globale du flux de contrôle.
Les nœuds sont des interactions.
Les lignes de vies et les messages n’apparaissent pas à ce niveau.
Mélange diagramme de séquences et diagramme d’activités.
VI.B.3 Diagrammes Globale Interaction :

Représentation
Un diagramme d’interaction se représente par un rectangle contenant, dans

le coin supérieur gauche, un pentagone accompagné du mot-clef.
sd lorsqu’il s’agit d’un diagramme de séquence
com lorsqu’il s’agit d’un diagramme de communication.
Le mot clé est suivi du nom de l’interaction.
156
Dans le pentagone, on peut aussi faire suivre le nom par la liste des
lignes de vie impliquées, précédée par le mot clé lifelines.
Des attributs peuvent être indiqués dans la partie supérieure du

rectangle contenant le diagramme.
La syntaxe des attributs est la même que celle des attributs d’une
classe.
VI.B.4 Diagrammes Globale Interaction: Exemple
157
158
159
Diagrammes Globale Interaction: Exemple 1
160
161
SECTION C
Diagrammes de Paquetages
-
PACKAGE DIAGRAM
« Cela n'a aucun sens d'embaucher des gens

intelligents et de leur dire quoi faire; Nous
embauchons des gens intelligents pour qu'ils
puissent nous dire quoi faire »
Steve Jobs
162
VI.C.1 Diagrammes de Paquetages : Définition &
Objectif
Les diagrammes de paquetages sont la représentation graphique des

relations existant entre les paquetages ou espaces de noms composant un
système, dans le langage (UML); c’est-à-dire les dépendances entre un
ensemble de définitions.
Objectif :
Structurer / organiser les éléments et diagrammes;
notamment les classes
Donner une vision globale plus claire ;

Maintenance des diagrammes ;
Maintenance du code ;
Définir un espace de nom.
Un package est un regroupement de concepts .
VI.C.2 Paquetage : Définition & Notation
Un paquetage est un regroupement d’éléments de modélisation :
des classes, des composants, des nœuds, des collaborations, des

cas d’utilisation, etc.
des diagrammes de classes, de collaboration, de séquence, de

cas d’utilisation, etc.
d’autres paquetages.
Le type de la relation qui unit les éléments à leur paquetage est de type
composition.
Notation :
Un paquetage est représenté par un rectangle avec une cartouche
rectangulaire en haut à gauche.
le nom du paquetage est indiqué dans la cartouche.
Les éléments constituant le paquetage donne la visibilité.
163
Visibilité d’un élément E dans un package P :
Public (+) : Elément visible par tous (utilisation du nom complet)
Privé (-) : Elément visible uniquement par
- Les autres éléments de P
- Les éléments englobés par E (si E est un package)
164
VI.C.3 Espace de Nommage
Un paquetage forme un espace de nommage:
Le nom des éléments d’un paquetage doit être unique au sein du

paquetage.
Le nom d’un élément au sein de paquetages imbriqués est préfixé

par tous les paquetages englobant.
GestionProduits::Catalogue::Boulon
Les packages sont utiles au travail de séparation dans des zones

différentes.
Chaque package définit un espace de noms afin que les noms définis
dans les différents packages ne soient pas en conflit les uns avec les
autres.
La propriété de nom qualifié de chaque élément est le nom qualifié du

package auquel il appartient, suivi par le propre nom de l'élément.
Si le package est appelé MyPackage, une classe dans le package aura

un nom qualifié comme MyPackage :: MyClass.
165
Banque :: Compte ≠ Commerce :: Compte
Espace de Nommage: Exemple
166
Classe1 possède dans son nom le nom du paquetage, la
hiérarchie des paquetages étant indiquée par le symbole « :: » ;
Classe2 possède en dessous de son nom le nom du paquetage
entre parenthèse ;
Classe4 et Classe5 sont reliées au paquetage ;
Classe6 est directement visualisée dans le paquetage.
VI.C.4 Dépendances
Dépendances entre éléments de paquetages

Une classe A dépend d’une classe B (noté A - - - - - - - - > B) si :
Il existe une association navigable de A vers B (ou A possède un

attribut de type B)
Une méthode de A a un paramètre ou une variable locale de type B
Dépendances entre paquetages

Amies « freind » : Accès à tous les éléments d’un paquetage quelque
soit leur visibilité.
Importation « import » : Importation d’éléments dans l’espace de

nommage en tenant compte des visibilités. (A - -«importe»- -> B: Tout
élément public de B est accessible par son nom depuis A)
167
Accès « access » : Accès à des éléments en tenant compte de leur
visibilité. (A - - «accède» - - > B : Tout élément public de B est
accessible par son nom complet depuis A)
Généralisation : Généralisation / spécialisation de paquetage.
Dépendances – Notation :
Imbrication de paquetages = imbrication d’espaces de nommage.
Dépendance entre paquetages.
168
CHAPITRE VII
Diagrammes de Temps
&
Diagrammes de Profile
« Les décisions les plus importantes que vous

prenez ne sont pas les choses que vous faites,
mais les choses que vous décidez de ne pas
faire »
Steve Jobs
169
SECTION A
Diagrammes de Temps
-
TIMING DIAGRAM
« L'innovation, c'est une situation qu'on

choisit parce qu'on a une passion
brûlante pour quelque chose »
Steve Jobs
170
VII.A.1 Timing Diagrams : Defintion
Timing diagrams are UML interaction diagrams used to show

interactions when a primary purpose of the diagram is to reason about
time.
Timing diagrams focus on conditions changing within and among

lifelines along a linear time axis.
Timing diagrams describe behavior of both individual classifiers and

interactions of classifiers, focusing attention on time of events causing
changes in the modeled conditions of the lifelines.
The following nodes and edges are typically drawn in a UML timing
diagram:
1. Lifeline,
2. State or condition timeline,
3. Destruction event,
4. Duration constraint,
5. Time constraint
VII.A.2 Concepts
VII.A.2.1 Lifeline
Lifeline is a named element which represents an individual

participant in the interaction. While parts and structural features
may have multiplicity greater than 1, lifelines represent only one
interacting entity. See lifeline from sequence diagrams for details.
Lifeline on the timing diagrams is represented by the name of

classifier or the instance it represents. It could be placed inside
diagram frame or a "swimlane".
Lifelines representing instances of System and Virus.
171
Diagrammes de Temps : Définition
Ce sont des diagrammes d'interaction où l'attention est portée sur les
contraintes temporelles dans le langage UML2.
Ils sont utilisés pour explorer le comportement des objets d'un système
à travers une période de temps.
Ils représentent une forme spéciale de diagramme de séquence où les

axes ont été inversés pour que le temps s'écoule de la gauche vers la
droite et les lignes de vies sont affichées dans des compartiments
séparés disposés horizontalement.
Sur un diagramme de temps, la ligne de vie permet aussi de présenter

les états d'un objet au cours de la période de temps représentée par le
diagramme; un plateau signifiant que l'état de l'objet n'a pas évolué sur
cette période.
Les lignes de vies peuvent être annotées avec des :
intervalles de durées (« entre 1 et 6 minutes »)

intervalles de temps (« entre 5h40 et 6h00 »)
Il y a deux types de diagramme de temps:
« notation concise »
« notation robuste »
VII.A.2.2 State / Condition Timeline
Timing diagram could show states of the participating classifier or

attribute, or some testable conditions, such as a discrete or enumerable
value of an attribute.
Timeline shows Virus changing its state between Dormant, Propagation,

Triggering and Execution state.
UML also allows the state/condition dimension be continuous. It could

be used in scenarios where entities undergo continuous state changes,
such as temperature or density.
172
Concept : Etats - Conditions
Les diagrammes de temps contiennent des états ou des conditions.
Un état invariable dans un diagramme de temps est interprété

comme le temps, ou la durée, que la ligne de vie invariable
particulière d'état est dans un état indiqué
L'exemple suivant montre un diagramme de temps qui contient

deux lignes de vies, état invariants, des messages, des
observations de durée et des contraintes et des observations de
temps et des contraintes.
Diagrammes de Temps : Etats - Conditions
VII.A.2.3 Destruction occurrence
Destruction occurrence is a message occurrence which represents

the destruction of the instance described by the lifeline. It may result in
the subsequent destruction of other objects that this object owns by
173
composition. No other occurrence may appear after the destruction
event on a given lifeline.
Complete UML name of the occurrence is destruction occurrence

specification. Until UML 2.4 it was called destruction event, and
earlier - stop.
The destruction event is depicted by a cross in the form of an X at the

end of a timeline.
Virus lifeline is terminated.
VII.A.2.4 Time Constraint
Time constraint is an interval constraint that refers to a time interval.

The time interval is time expression used to determine whether the
constraint is satisfied.
The semantics of a time constraint is inherited from constraints. All

traces where the constraints are violated are negative traces, i.e., if they
occur, the system is considered as failed.
Time constraint is shown as graphical association between a time

interval and the construct that it constrains. Typically this graphical
association is a small line, e.g., between an occurrence specification
and a time interval.
Person should wake up between 5:40 am and 6 am.
VII.A.2.5 Duration Constraint
Duration constraint is an interval constraint that refers to a duration

interval. The duration interval is duration used to determine whether
the constraint is satisfied.
The semantics of a duration constraint is inherited from constraints. If

constraints are violated, traces become negative which means that
system is considered as failed.
Duration constraint is shown as some graphical association between a

duration interval and the constructs that it constrains.
Ice should melt into water in 1 to 6 minutes.

174
Contraintes - Notation
Une contrainte représente une condition ou une restriction exprimée en
langage naturel ou en langue exploitable par une machine dans le but de
déclarer la sémantique d'un élément.
Le nom de la contrainte est optionnel.
La condition qui doit être vraie pour que la contrainte soit

satisfaite.
Note
Une note (le commentaire) donne la capacité d'attacher des remarques
diverses aux éléments. Un commentaire ne porte aucune force
sémantique, mais peut contenir les informations qui sont utiles pour un
concepteur.
On spécifie dedans le nom de la note qu’on souhaite ajouter au

diagramme.
VII.A.3 Etude de Cas : Retrait
Etapes de modélisation
On va traiter l’exemple de retrait d’argent d’un guichet.
Etapes:
Trouver les états décrivant le cas étudié ;
175
Définir les acteurs participant au processus ;
Relier les états aux acteurs;
Etats trouvées:
Le client insère sa carte guichet.

Carte guichet invalide;
Ejection de carte ;
Carte valide.
Client entre le code.
Code invalide
Code valide.
Compte bancaire sélectionné.
Montant sélectionné.
Fournir les fonds.
Fournir le reçu.
Définition des acteurs :
Le client
Le système bancaire
La carte bancaire
On va déterminer les états correspondant à chaque acteur
Relier les acteurs aux états :
Client :
Carte dans main

Insertion de la carte
Saisie du code
Choix du compte
Choix du montant
Lecteur de carte:
Aucune carte
Carte reçu
Carte valide
Carte invalide
Ejection de carte
Relier les acteurs aux états :
176
Système bancaire :
Aucune carte
Carte reçu
Carte valide
Carte invalide
Montant invalide
Ejection du montant
Ejection de carte
Ejection du reçu
Représentation des différents acteurs
Liaison des acteurs avec leurs états respectifs
177
Après avoir effectuer les deux tâches précédentes, on doit maintenant
dessiner le diagramme de temps, avec sa ligne de vie , et ces contraintes de
temps.
178
VII.A.3 Etude de cas – Notation Robuste
VII.A.3.2 Diagramme de Temps – Notation Concise
179
VII.A.4 Timing diagram example: Website Latency
An example of timing diagram which shows some duration constraints for a

fabricated website to evaluate how long web user should wait to see
something rendered on his/her display.
After web user enters web page URL, the URL should be resolved to some IP
address. DNS resolution can add some tangible waiting time to the response
latency as perceived by user. Latency delays related to DNS resolution could
range from 1 ms (local DNS cache) to several seconds. With simple Model–
View–Control (MVC) implementation, Java servlet gets control and requests
some data from "model". Communication with data sources usually takes
some discernible time. After data is received and processed, servlet forwards
request processing to JSP ("view"). Buffered HTTP response is sent back to
the browser. Web browser takes some time to process HTTP response and
HTML page to start rendering the page view to the web client.
(Note, that after that it could take even more time for the web browser to
request other resources like CSS, JavaScript, images, which is not shown on
the diagram.)
180
Timing diagram example: Website Latency
181
SECTION B
Diagrammes de Profile
-
PROFIL DIAGRAM
« N'essaie pas de tout faire. Fais une chose

bien »
Steve Jobs
182
VII.B.1 Diagrammes de Profile: Définition & Notation
Un profil est un mécanisme d’extension léger au standard UML, il étend un

méta-modèle de référence (Comme UML) pour permettre de l’adapter et le
personnaliser avec des constructions qui sont spécifiques à un domaine
particulier ou une plateforme (contexte métier ou technique).
Exemple :
Profil pour composants EJB.
Profil pour gestion bancaire.
Profil pour architecture logicielle
Un profil est une spécialisation du méta-modèle UML qui permet de :
Ajouter de nouveaux types d'éléments.
Ajouter des contraintes sur les éléments existants d'UML.
Ajouter des contraintes sur les relations existantes entre les

éléments d'UML.
Ne permet Aucune suppression de contraintes ou d'éléments .
Profile – Notation :
Le Profile utilise la même notation que le paquettage avec l'ajout du

mot-clé «profile» avant ou au-dessus du nom du package.
Exemple:
183
VII.B.2 Diagrammes de Profile: Composant
Un profil UML est composé de 3 types d'éléments:
1. Des stéréotypes.
2. Des tagged values (Valeurs marquées).
3. Des contraintes :
- Sur les stéréotypes, tagged values.

- Sur des éléments du méta-modèle existant.
- Sur les relations entre les éléments.
VII.B.2.1 Stéréotypes
Stéréotype : classe de profil qui définit la manière dont une méta-classe

existante peut être prolongée dans le cadre d'un profil.
Méta-classe : classe de profil et un élément packageable qui peut être

prolongé par un ou plusieurs stéréotypes.
Extension, spécialisation d'un élément du méta-modèle
Classe, association, attribut, opération etc.

Le nom d'un stéréotype est indiqué entre <<...>>
Il existe déjà des stéréotypes définis dans UML:
<< interface >> : une interface est un classifier particulier (sans
attribut)
Stéréotypes - Notation
Un stéréotype utilise la même notation en tant que classe, le mot
«stéréotype» présenté avant ou au-dessus du nom du stéréotype.
Une méta-classe peut être représentée avec le stéréotype

«Metaclass» indiqué au dessus ou avant son nom.
Elle est reliée au stéréotype avec la relation ‘Extension’.
184
VII.B.2.2 Tagged Values
Quand un stéréotype est appliqué à un élément de modèle, les valeurs

des propriétés sont appelées valeurs marquées (Tagged Values).
Les tagged value sont principalement utilisées pour ajouter des

informations sur les classes
Une tagged value peut être vue comme un nouvel méta-attribut.
VII.B.2.3 Contraintes
Les contraintes sont utilisées pour exprimer les relations, les

stéréotypes et les tagged values.
Les contraintes servent a exprimer la sémantique du profil.
Ces contraintes permettent de compléter le profil.
185
VII.B.2.4 Relations
Les stéréotypes peuvent être reliés les uns aux autres par des relations
Composition: (Aggregation forte)
Généralisation: (Héritage)
Profile Appliqué :
C’est une relation utilisée pour montrer que les profils ont été appliqués
à un package.
Un profil appliqué est représenté à l'aide d'une flèche en pointillés avec

le mot-clé «apply».
Un profil qui a été appliqué ne peut être retiré que si d'autres profils qui
en dépendent sont d'abord retirés.
186
VII.B.3 Diagrammes de Profile : Exemples
Exemple 1 – Serveur :
Diagramme de profil sous forme
de package
Serveur composé du stéréotype

Server
Ce stéréotype étend une méta-

classe Device.
Ce profil peut alors être appliqué

à un package.
Exemple 2 - Architecture Logicielle :

Des composants client et serveur.
Un client est associé à un serveur via une interface de service par

l'intermédiaire d'un proxy.
Profil défini :
Nommé ClientProxyServer
Définit trois stéréotypes
- Trois classes jouant un rôle particulier : extensions de la
méta-classe Class du méta-modèle UML
- Server, Proxy, Client
187
Exemple 3 – EJB :
Enterprise JavaBeans (EJB) est une architecture de composants
logiciels côté serveur qui permet de :
Créer des composants distribués écrits en langage de programmation

Java ;
188
Hébergés au sein d'un serveur applicatif permettant de représenter des
données (Entités). Le serveur applicatif se charge de la :
Création
Destruction
Passivation
Activation de ses composants en fonction de ses besoins.
189
Conclusions
Langage de modélisation permettant d’appréhender la réalisation d’un
système informatique.
Diagrammes qui permettent d’aider à la réflexion, de permettre la

discussion (clients, développeurs).
Pas de solution unique mais un ensemble de solutions plus ou moins

acceptables suivant les contraintes du client et les logiciels et matériels
disponibles.
Une solution acceptable sera obtenue avec des itérations successives.
UML est le résultat d’un large consensus, continuellement enrichi par

les avancées en matière de modélisation de systèmes et de
développement de logiciels. C’est le résultat d’un travail d’expert
reconnus, issus du terrain. Il couvre toutes les phases du cycle de vie
de développement d’un système et se veut indépendant de langages
d’implémentation et de domaines d’application.
190
Bibliographie - Webographie
Martin Fowler, Kendall Scott; “UML Distilled”, Addison-Wesley 2000
Grady Booch, et al; “The Unified Modeling Language User Guide”, Addison-
Wesley
James Rumbaugh, et al; “The Unified Modeling Language Reference

Manual”, Addison-Wesley
Ivar Jacobson, et al ; “Unified Software Development Process”, Addison-

Wesley
Jos B. Warmer, Anneke G. Kleppe ;The Object Constraint Language :

Precise Modeling With UML, Addison-Wesley
Pierre-Alain Muller, Nathalie Gaertner ; «Modélisation avec UML», Eyrolles
Drady Booch, James Rumbaugh et Ivar Jacobson ; "Guide de l'utilisateur

UML", , ed. Eyrolles - 2000
« Analysis Patterns, Reusable Object Models », de Martin Fowler, ed.

Addison Wesley - 2001
Martin Fowler ; "UML", coll. Le tout en poche, ed. Campus Press – 2001
Benoit Charroux, Aomar Osmani, Yann Thierry-Mieg; «UML 2», collection

Synthex, Pearson Education
omg.org
https://www.omg.org/spec/UML/About-UML/
http://st-www.cs.uiuc.edu/users/patterns/patterns.html, "
Patterns info: http://c2.com/ppr/index.html
Rational doc: http://www.rational.com/uml/documentation.html
Rational CASE tools: http://www.rational.com/products/rose/seed
UML 2.0 Working Group
https://laurent-audibert.developpez.com/Cours-UML/?page=object-constraint-
langage-ocl
OMG UML Resources: www.omg.org/uml/
191
NADIA AFIFI’s Biography
Nadia AFIFI is Currently Professor at Higher School of
Technology (ESTC), Hassan II University of Casablanca -
Morocco (UH2C). She is IEEE Senior Member; part of
“Software Engineering, Business Intelligence an and
Security” (SEBIS) research team of “Networks,
Computer, Telecom & Multimedia” (RITM) Laboratory
(ESTC).
She received a PhD in Computer Engineering from UH2C; and HDR (Habilitation
to Direct Research) in IT. She had received an Electrical Engineering, Computer
Systems degree from the Mohammadia School of Engineers (EMI), Mohammed
V University – Rabat Morocco. Prior to her academic career, she had worked as a
software engineer in the Finance Ministry (Rabat).
Pr Nadia’s teaching and research interests include, Information Systems

Modeling (UML, MDA, etc.), Information Systems Security, Software
Architecture ,Human Machine Interface, Dependability, Business Intelligence;
Cloud Computing Security, Big Data, IoT and Artificial Intelligence.
192

UML Version PDF Livre-1

Transféré par

Informations du document

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 Version PDF Livre-1

Transféré par

Droits d'auteur :

Formats disponibles

Université Hassan II de Casablanca

Ecole supérieure de Technologie

DUT & LICENCE

Ingénierie des Systèmes

Pr. Nadia AFIFI

L’élaboration des SI fait appel à des méthodes et des langages de

Dans ce support on présente de façon simplifiée les différents concepts du

L’objectif de ce cours est de fournir une référence des concepts de base

Le support s'adresse aux étudiants de premier cycle (DUT, BTS). Il pourrait

INTRODUCTION : Les méthodes objet et la genèse d'UML ..................... 12

I.1 Historique des Méthodes ................................................................................. 13

I.1.1 Historique d’UML ................................................................................. 14

I.2 Introduction au Langage de Modélisation UML ........................................... 16

I.2.1 Définition d’UML .................................................................................. 16

I.3 Modélisation avec UML .................................................................................. 17

I.3.1 Pourquoi modéliser ............................................................................ 17

I.3.2 Les principes de la modélisation....................................................... 17

I.3.3 Qu’apporte la modélisation objet ...................................................... 17

I.3.4 Les objectifs d’UML ............................................................................ 18

I.3.5 UML et les domaines d’utilisation ..................................................... 19

I.4 Les Composants d’UML .................................................................................. 19

I.4.1 Les trois éléments de base en UML .................................................. 19

I.4.2 Les Modèles d’UML ............................................................................ 23

I.4.3 Les Diagrammes D’UML ..................................................................... 23

I.4.4 Les Vues d’UML .................................................................................. 26

I.4.1 Point de vue des cas d’utilisation ..................................................... 26

I.4.2 Point de vue logique........................................................................... 27

I.4.3 Point de vue processus ..................................................................... 27

I.4.4 Point de vue implantation .................................................................. 27

I.4.5 Point de vue déploiement .................................................................. 28

I.5.1 Expression des besoins..................................................................... 29

I.5.1 Spécification ....................................................................................... 30

I.5.2 Analyse ................................................................................................ 30

I.5.5 Implémentation ................................................................................... 33

I.5.6 Tests de vérification ............................................................................ 33

I.5.7 Validation ............................................................................................ 33

I.5.8 Maintenance et évolution ................................................................... 34

Diagrammes des Cas d’Utilisations - USE CASES DIAGRAM ................. 35

II.1 Cahier des Charges : Gestion de Bibliothèque .............................................. 36

II.2 But des Use Cases ............................................................................................ 36

II.3 Modèle des Cas d'Utilisations ......................................................................... 37

II.4 Concepts de base du Diagramme des UC ....................................................... 37

II.4.1 Acteurs ................................................................................................ 37

II.4.2 Cas d’utilisation (Use-Case) .............................................................. 38

II.5 Elaboration du Diagramme Des UC de la Gestion de Bibliothèque ............. 42

II.6 Elaboration du Modèle des Cas d’Utilisation de la Gestion de Bibliothèque 43

II.6.1 Scénarios d'un cas d'utilisation : Définition ..................................... 43

II.6.2 Scénarios du UC : Réservation d’un livre ......................................... 43

II.6.3 Représentation du Scénario par diagramme de séquences ............ 45

CHAPITRE III ................................................................................................ 49

Concepts Objets& Diagramme de Classes - Class Diagram .................... 49

SECTION A : CONCEPTS OBJETS ............................................................. 50

III.A.1 Classe : Définition ............................................................................ 51

III.A.1.2 Attributs / Operations: Syntaxe .................................................... 52

III.A.1.3 Operations (Méthodes) .................................................................. 52

III.A.1.4 La Classe et ses membres ........................................................... 53

III.A.2 Classe & Objet ........................................................................................... 53

III.A.3 Protection des Attributs et des Opérations .............................................. 54

III.A.3.1 Principe de l'encapsulation ........................................................... 54

III.A.3.2 Usage et Notation.......................................................................... 54

III.A.3.3 Attributs et Opérations de Classe ................................................. 56

III.A.3.4 Attribut dérivé ................................................................................ 57

III.A.4 Surcharge & Polymorphisme .................................................................... 57

III.A.5 Principaux Concepts du Diagramme de Classe ........................................ 58