Ministère de l’Enseignement Supérieur et de

la Recherche Scientifique

Cours

Ingénierie des Systèmes d’Information

Unified Modeling Language (UML)

Dr MAMADOU Diarra
29/01/2020
Table des matières

Table des matières

1 Introduction à la modélisation objet ............................................................................................... 4
1.1 Notions de modèle .................................................................................................................. 4
1.2 Modélisation orientée objets .................................................................................................. 4
1.2.1 Fondamentaux de l’orienté objets .................................................................................. 4
1.2.2 Concepts importants de l’approche objet ....................................................................... 5
1.3 UML ......................................................................................................................................... 6
2 Diagramme de cas d’utilisation ....................................................................................................... 8
2.1 Introduction ............................................................................................................................. 8
2.2 Formalisme du diagramme de cas d’utilisation ...................................................................... 8
2.2.1 Acteurs............................................................................................................................. 8
2.2.2 Cas d’utilisation ............................................................................................................... 8
2.2.3 Relations d’associations .................................................................................................. 9
2.2.4 Relations entre cas d’utilisation .................................................................................... 10
2.2.5 Relations entre acteurs ................................................................................................. 11
2.3 Description textuelle des cas d’utilisation............................................................................. 12
3 Diagramme de classes ................................................................................................................... 13
3.1 Introduction ........................................................................................................................... 13
3.2 Classes ................................................................................................................................... 13
3.3 Méthodes .............................................................................................................................. 13
3.4 Représentation graphique d’une classe ................................................................................ 13
3.5 Relations entre classes .......................................................................................................... 14
3.5.1 Généralisation et héritage ............................................................................................. 14
3.5.2 Associations ................................................................................................................... 15
3.5.3 Multiplicité ou cardinalité ............................................................................................. 16
3.5.4 Navigabilité .................................................................................................................... 16
3.5.5 Classe-association.......................................................................................................... 17
3.5.6 Agrégation et composition ............................................................................................ 17
3.5.7 Dépendances ................................................................................................................. 17
3.6 Diagrammes d’objets............................................................................................................. 18
4 Diagramme d’états-transitions...................................................................................................... 19
4.1 Introduction ........................................................................................................................... 19
5 Formalisme du diagramme d’état-transition ................................................................................ 19
5.1.1 Etat simple ..................................................................................................................... 19

1
 5.1.2 État composite............................................................................................................... 19
5.1.3 Etat initial....................................................................................................................... 20
5.1.4 Etat final ........................................................................................................................ 20
5.1.5 Transition externe ......................................................................................................... 20
5.1.6 Transition interne .......................................................................................................... 20
5.1.7 Points de jonction .......................................................................................................... 21
5.1.8 Point de décision ........................................................................................................... 21
5.1.9 État historique ............................................................................................................... 22
5.1.10 Point de connexion ........................................................................................................ 23
5.1.11 Nœud de débranchement ou de contrôle .................................................................... 24
6 Diagramme d’activités ................................................................................................................... 26
6.1 Introduction ........................................................................................................................... 26
6.2 Formalisme du digramme d’activités .................................................................................... 27
7 Diagrammes de séquence ............................................................................................................. 30
7.1 Rôle du diagramme de séquence .......................................................................................... 30
7.2 Représentation du diagramme de séquence ........................................................................ 30
7.2.1 Délimitation du diagramme de séquence ..................................................................... 30
7.2.2 L’objet ............................................................................................................................ 30
7.2.3 La ligne de vie ................................................................................................................ 30
7.2.4 Les messages ................................................................................................................. 31
7.3 Quelques séquences expliquées ........................................................................................... 35
7.3.1 Messages retours implicites et explicites ...................................................................... 35
7.3.2 Recouvrement des bandes d’activations ...................................................................... 35
7.3.3 Messages récursifs ........................................................................................................ 36
7.3.4 Contraintes temporelles ................................................................................................ 36
7.3.5 Messages perdus et trouvés.......................................................................................... 36
7.4 Fragments d’interactions combinés ...................................................................................... 37
7.4.1 Fragment d’interaction avec opérateur « opt » ............................................................ 37
7.4.2 Fragment d’interaction avec opérateur « alt » ............................................................. 38
7.4.3 Fragment d’interaction avec opérateur « loop » .......................................................... 38
7.4.4 Fragment d’interaction avec opérateur « par » ............................................................ 39
7.4.5 Autres fragments d’interactions.................................................................................... 39
7.5 Exemple de diagramme de séquence ................................................................................... 40
8 Diagrammes de composants et de déploiement .......................................................................... 42
8.1 Diagramme de composants................................................................................................... 42
8.1.1 Notion de composant (component) et d’interface ....................................................... 42

2
 8.1.2 Les interfaces ................................................................................................................. 42
8.1.3 Les ports ........................................................................................................................ 44
8.1.4 Boite noire-boites blanche ............................................................................................ 44
8.1.5 Rôle du diagramme de composants .............................................................................. 45
8.2 Diagramme de déploiement.................................................................................................. 46
8.2.1 Rôle du diagramme de déploiement ............................................................................. 46
8.3 Les éléments du diagramme de déploiement ....................................................................... 46
8.3.1 Les nœuds...................................................................................................................... 46
8.3.2 Les chemins de communications................................................................................... 48
8.3.3 Les artefacts :................................................................................................................. 48
8.3.4 Exemples de projet ........................................................................................................ 49
9 Bibliographie :................................................................................................................................ 53

3
1 Introduction à la modélisation objet
1.1 Notions de modèle
Un modèle est une représentation d’une réalité matérielle ou immatérielle, un modèle n’est
pas cette réalité.
On pourra affiner les modèles en créant de nouveaux modèles de plus en plus
détaillés jusqu'à peut-être atteindre de manière asymptotique le monde réel sans jamais
l'atteindre.
Modéliser est donc l’acte de représenter nos concepts et les objets de notre réalité.

Cette réalité pouvant être immatériel et exister uniquement comme activité conceptuelle.
Un modèle est forcément une description limitée et orientée de la réalité.

Il est impossible de décrire de manière absolue la réalité à des fins descriptives ou prédictives,
sans même parler de l’intérêt d’une telle démarche.

Un modèle va décrire la réalité avec un certain filtre, en utilisant certains concepts

permettant de classifier la réalité observée.
De manière très simplifié, un modèle décrit toujours une réalité observable ou, encore mieux,
mesurable et donc numérique.
La réalité observable peut être décrite en répondant aux questions : « Quoi ? Qui ? Quand ?
Où ? Comment ? » ainsi qu’en décrivant les contraintes qui définissent les limites du modèle.

1.2 Modélisation orientée objets

1.2.1 Fondamentaux de l’orienté objets
L’approche orientée objet considère le logiciel comme une collection d’objets dissociés, et
identifiés, définis par des propriétés. Une propriété est soit un attribut (i.e. une donnée
caractérisant l’état de l’objet), entité élémentaire comportementale de l’objet). La
fonctionnalité du logiciel émerge alors de l’interaction entre les différents objets qui le
constituent. L’une des particularités de cette approche est qu’elle rapproche les données et
leurs traitements associés au sein d’un unique objet.
Comme nous venons de le dire, un objet est caractérisé par plusieurs notions :
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 de série, etc.)
Les attributs – Il s’agit des données caractérisant l’objet. Ce sont des variables stockant des
informations sur l’état de l’objet.
Les méthodes – 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

4
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.
La difficulté de cette modélisation consiste à créer une représentation abstraite, sous forme
d’objets, d’entités ayant une existence matérielle (chien, voiture, ampoule, personne, . . .) ou
bien virtuelle (client, temps, . . .).
La Conception Orientée Objet (COO) est la méthode qui conduit à des architectures logicielles
fondées sur les objets du système, plutôt que sur la fonction qu’il est censé réaliser.
1.2.2 Concepts importants de l’approche objet
L’approche objet rapproche les données et leurs traitements.
Mais cette approche ne fait pas que ça, d’autres concepts importants sont spécifiques à cette
approche et participent à la qualité du logiciel.
Notion de classe
Tout d’abord, introduisons la notion de classe. Une classe est un type de données abstrait,
caractérisé par des propriétés (attributs et méthodes) communes à toute une famille d’objets
et permettant de créer (instancier) des objets possédant ces propriétés. Les autres concepts
importants qu’il nous faut maintenant introduire sont l’encapsulation, l’héritage et
l’agrégation.
Encapsulation
L’encapsulation consiste à masquer les détails d’implémentation d’un objet, en définissant
une interface.
L’interface est la vue externe d’un objet, elle définit les services accessibles (offerts) aux
utilisateurs de l’objet.
L’encapsulation facilite l’évolution d’une application car elle stabilise l’utilisation des objets :
on peut modifier l’implémentation des attributs d’un objet sans modifier son interface, et
donc la façon dont l’objet est utilisé.
L’encapsulation garantit l’intégrité des données, car elle permet d’interdire, ou de restreindre,
l’accès direct aux attributs des objets.
Héritage, Spécialisation, Généralisation et polymorphisme
L’héritage est un mécanisme de transmission des propriétés d’une classe (ses attributs et
méthodes) vers une sous-classe. Une classe peut être spécialisée en d’autres classes, afin d’y
ajouter des caractéristiques spécifiques ou d’en adapter certaines. Plusieurs classes peuvent
être généralisées en une classe qui les factorise, afin de regrouper les caractéristiques
communes d’un ensemble de classes.
Ainsi, la spécialisation et la généralisation permettent de construire des hiérarchies de classes.
L’héritage peut être simple ou multiple. L’héritage évite la duplication et encourage la
réutilisation.
Le polymorphisme représente la faculté d’une méthode à pouvoir s’appliquer à des objets de
classes différentes. Le polymorphisme augmente la généricité, et donc la qualité, du code.
Agrégation

5
Il s’agit d’une relation entre deux classes, spécifiant que les objets d’une classe sont des
composants de l’autre classe. Une relation d’agrégation permet donc de définir des objets
composés d’autres objets.
L’agrégation permet donc d’assembler des objets de base, afin de construire des objets plus
complexes.

1.3 UML
Comme tout type de projet, un projet informatique nécessite une phase d’analyse, suivi d’une
étape de conception.

Dans la phase d’analyse, on cherche d’abord à bien comprendre et à décrire de façon précise
les besoins des utilisateurs ou des clients. Que souhaitent-ils faire avec le logiciel ? Quelles
fonctionnalités veulent-ils ? Pour quel usage ? Comment l’action devrait-elle fonctionner ?
C’est ce qu’on appelle « l’analyse des besoins ». Après validation de notre compréhension du
besoin, nous imaginons la solution. C’est la partie analyse de la solution.

Dans la phase de conception, on apporte plus de détails à la solution et on cherche à clarifier

des aspects techniques, tels que l’installation des différentes parties logicielles à installer sur
du matériel.

Figure 1: Projet informatique

Figure xxx : Projet informatique

UML permet donc de modéliser une application selon une vision objet. L’appréhension
d’UML est complexe car UML est à la fois :

6
- une norme,
- un langage de modélisation objet,
- un support de communication,
- un cadre méthodologique.

7
2 Diagramme de cas d’utilisation
2.1 Introduction
Bien souvent, la maîtrise d’ouvrage et les utilisateurs ne sont pas des informaticiens. Il leur
faut donc un moyen simple d’exprimer leurs besoins. C’est précisément le rôle des
diagrammes de cas d’utilisation qui permettent de recueillir, d’analyser et d’organiser les
besoins, et de recenser les grandes fonctionnalités d’un système. Il s’agit donc de la première
étape UML d’analyse d’un système.
Un diagramme de cas d’utilisation capture le comportement d’un système, d’un sous-
système, d’une classe ou d’un composant tel qu’un utilisateur extérieur le voit. Il scinde la
fonctionnalité du système en unités cohérentes, les cas d’utilisation, ayant un sens pour les
acteurs. Les cas d’utilisation permettent d’exprimer le besoin des utilisateurs d’un système, ils
sont donc une vision orientée utilisateur de ce besoin au contraire d’une vision informatique.
Il ne faut pas négliger cette première étape pour produire un logiciel conforme aux attentes
des utilisateurs. Pour élaborer les cas d’utilisation, il faut se fonder sur des entretiens avec les
utilisateurs.

2.2 Formalisme du diagramme de cas d’utilisation

2.2.1 Acteurs
Un acteur est l’idéalisation d’un rôle joué par une personne externe, un processus ou une chose qui interagit
avec un système.
Il se représente par un petit bonhomme avec son nom (i.e. son rôle) inscrit dessous.

Figure 2 : Exemple de représentation d’un acteur

Figure xxx : Exemple de représentation d’un acteur

2.2.2 Cas d’utilisation

Un cas d’utilisation est une unité cohérente d’une fonctionnalité visible de l’extérieur. Il réalise un service de
bout en bout, avec un déclenchement, un déroulement et une fin, pour l’acteur qui l’initie. Un cas d’utilisation
modélise donc un service rendu par le système, sans imposer le mode de réalisation de ce service.
Un cas d’utilisation se représente par une ellipse (figure 2.3) contenant le nom du cas (un verbe à l’infinitif), et
optionnellement, au-dessus du nom, un stéréotype (cf. section 2.4.2).

Figure 3 : Exemple de représentation d’un cas d’utilisation

Figure xxx : – Exemple de représentation d’un cas d’utilisation

8
2.2.3 Relations d’associations
Une relation d’association est chemin de communication entre un acteur et un cas d’utilisation et est
représenté un trait continu.

Figure 4 : Exemple simplifié de diagramme de cas d’utilisation modélisant une borne d’accès à une banque

Figure xxxx : Exemple simplifié de diagramme de cas d’utilisation modélisant une borne d’accès à une
banque.

Figure 5 : Diagramme de cas d’utilisation représentant un logiciel de partage de fichiers

Figure xxxxx : Diagramme de cas d’utilisation représentant un logiciel de partage de fichiers

Multiplicité
Lorsqu’un acteur peut interagir plusieurs fois avec un cas d’utilisation, il est possible d’ajouter
une multiplicité sur l’association du côté du cas d’utilisation. Le symbole * signifie plusieurs,
exactement n s’écrit tout simplement n, n..m signifie entre n et m, etc. Préciser une
multiplicité sur une relation n’implique pas nécessairement que les cas sont utilisés en même
temps.
La notion de multiplicité n’est pas propre au diagramme de cas d’utilisation. Nous en
reparlerons dans le chapitre consacré au diagramme de classes

9
Acteurs principaux et secondaires
Un acteur est qualifié de principal pour un cas d’utilisation lorsque ce cas rend service à cet
acteur. Les autres acteurs sont alors qualifiés de secondaires. Un cas d’utilisation a au plus un
acteur principal. Un acteur principal obtient un résultat observable du système tandis qu’un
acteur secondaire est sollicité pour des informations complémentaires. En général, l’acteur
principal initie le cas d’utilisation par ses sollicitations. Le stéréotype « primary » vient orner
l’association reliant un cas d’utilisation à son acteur principal, le stéréotype « secondary » est
utilisé pour les acteurs secondaires.
Cas d’utilisation interne
Quand un cas n’est pas directement relié à un acteur, il est qualifié de cas d’utilisation interne.
2.2.4 Relations entre cas d’utilisation
Types et représentations
Il existe principalement deux types de relations :
- les dépendances stéréotypées, qui sont explicitées par un stéréotype (les plus utilisés
sont l’inclusion et l’extension),
- et la généralisation/spécialisation.
Une dépendance se représente par une flèche avec un trait pointillé. Si le cas A inclut ou étend
le cas B, la flèche est dirigée de A vers B.
Le symbole utilisé pour la généralisation est une flèche avec un trait pleins dont la pointe est
un triangle fermé désignant le cas le plus général.

Figure 6 : Exemple de diagramme de cas d’utilisation

10
 Figure xxxx : Exemple de diagramme de cas d’utilisation
Relation de généralisation
Un cas A est une généralisation d’un cas B si B est un cas particulier de A. Dans la figure ci-
dessus, la consultation d’un compte via Internet est un cas particulier de la consultation. Cette
relation de généralisation/spécialisation est présente dans la plupart des diagrammes UML et
se traduit par le concept d’héritage dans les langages orientés objet.

Figure 7: Relations entre cas pour décomposer un cas complexe

Figure xxxx : Relations entre cas pour décomposer un cas complexe

2.2.5 Relations entre acteurs

La seule relation possible entre deux acteurs est la généralisation : un acteur A est une
généralisation d’un acteur B si l’acteur A peut être substitué par l’acteur B. Dans ce cas, tous
les cas d’utilisation accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai.
Le symbole utilisé pour la généralisation entre acteurs est une flèche avec un trait plein dont
la pointe est un triangle fermé désignant l’acteur le plus général (comme nous l’avons déjà vu
pour la relation de généralisation entre cas d’utilisation).

Figure 8 : Relations entre acteurs

Figure xxxx : Relations entre acteurs

11
2.3 Description textuelle des cas d’utilisation
Le diagramme de cas d’utilisation décrit les grandes fonctions d’un système du point de vue
des acteurs, mais n’expose pas de façon détaillée le dialogue entre les acteurs et les cas
d’utilisation. Bien que de nombreux diagrammes d’UML permettent de décrire un cas, il est
recommandé de rédiger une description textuelle car c’est une forme souple qui convient
dans bien des situations.
Une description textuelle couramment utilisée se compose de trois parties.
1. La première partie permet d’identifier le cas, elle doit contenir les informations qui
suivent.
Nom : Utiliser une tournure à l’infinitif (ex : Réceptionner un colis).
Objectif : Une description résumée permettant de comprendre l’intention principale du cas
d’utilisation.
Cette partie est souvent renseignée au début du projet dans la phase de découverte
des cas d’utilisation.
Acteurs principaux : Ceux qui vont réaliser le cas d’utilisation (la relation avec le cas
d’utilisation est illustrée par le trait liant le cas d’utilisation et l’acteur dans un diagramme de
cas d’utilisation)
Acteurs secondaires : Ceux qui ne font que recevoir des informations à l’issue de la réalisation
du cas d’utilisation
Dates : Les dates de créations et de mise à jour de la description courante.

Responsable : Le nom des responsables.

2. La deuxième partie contient la description du fonctionnement du cas sous la forme d’une

séquence de messages échangés entre les acteurs et le système. Elle contient toujours une
séquence nominale qui décrit de déroulement normal du cas. À la séquence nominale
s’ajoutent fréquemment des séquences alternatives (des embranchement dans la séquence
nominale) et des séquences d’exceptions (qui interviennent quand une erreur se produit).
Les préconditions : elles décrivent dans quel état doit être le système (l’application) avant que
ce cas d’utilisation puisse être déclenché.
Des scénarii : Ces scénarii sont décrits sous la forme d’échanges d’évènements entre l’acteur
et le système. On distingue le scénario nominal, qui se déroule quand il n’y a pas d’erreur, des
scénarii alternatifs qui sont les variantes du scénario nominal et enfin les scénarii d’exception
qui décrivent les cas d’erreurs.
Des postconditions : Elles décrivent l’état du système à l’issue des différents scénarii.
3. La troisième partie de la description d’un cas d’utilisation est une rubrique optionnelle. Elle
contient généralement des spécifications non fonctionnelles (spécifications techniques, . . .).
Elle peut éventuellement contenir une description des besoins en termes d’interface
graphique.

12
3 Diagramme de classes
3.1 Introduction
Le diagramme de classes est considéré comme le plus important de la modélisation orientée
objet, il est le seul obligatoire lors d’une telle modélisation. Le diagramme de classes en
montre la structure interne. Il permet de fournir une représentation abstraite des objets du
système qui vont interagir ensemble pour réaliser les cas d’utilisation.
Il s’agit d’une vue statique car on ne tient pas compte du facteur temporel dans le
comportement du système. Le diagramme de classes modélise les concepts du domaine
d’application ainsi que les concepts internes créés de toutes pièces dans le cadre de
l’implémentation d’une application. Chaque langage de Programmation Orienté Objets donne
un moyen spécifique d’implémenter le paradigme objet (pointeurs ou pas, héritage multiple
ou pas, etc.), mais le diagramme de classes permet de modéliser les classes du système et
leurs relations indépendamment d’un langage de programmation particulier.
Les principaux éléments de cette vue statique sont les classes et leurs relations : association,
généralisation et plusieurs types de dépendances, telles que la réalisation et l’utilisation .

3.2 Classes
Tout système orienté objet est organisé autour des classes.
Une classe est la description formelle d’un ensemble d’objets ayant une sémantique et des
propriétés communes.
Un objet est une instance d’une classe. C’est une entité discrète dotée d’une identité, d’un
état et d’un comportement que l’on peut invoquer. Les objets sont des éléments individuels
d’un système en cours d’exécution.
Une classe est un concept abstrait représentant des éléments variés. Une instance est une
concrétisation d’un concept abstrait.

3.3 Méthodes
Une classe définit un jeu d’objets dotés de propriétés. Les propriétés d’un objet permettent
de spécifier son état et son comportement. Dans les sections 1.3.2 et 1.3.4, nous avons dit que
les propriétés d’un objet étaient soit des attributs, soit des opérations. Ce n’est pas exact dans
un diagramme de classe car les terminaisons d’associations font également partie des
propriétés d’un objet au même titre que les attributs et les opérations.
Les attributs, les terminaisons d’association et les méthodes constituent donc les propriétés
d’une classe (et de ses instances).

3.4 Représentation graphique d’une classe

Elle est représentée par un rectangle divisé en trois à cinq compartiments. Le premier indique
le nom de la classe, le deuxième ses attributs et le troisième ses opérations.

13
 Figure 9 : Représentation graphique d’une classe

Figure xxx : Représentation graphique d’une classe

Pour matérialiser l’Encapsulation, la visibilité et l’interface une classe peut être représentée
de la façon suivante.

Figure 10: Bonnes pratiques concernant la manipulation des attributs

Figure xxx : Bonnes pratiques concernant la manipulation des attributs.

Où :

public ou + : tout élément qui peut voir le conteneur peut également voir l’élément indiqué.
protected ou # : seul un élément situé dans le conteneur ou un de ses descendants peut voir
l’élément indiqué.
private ou - : seul un élément situé dans le conteneur peut voir l’élément.
package ou ~ ou rien : seul un élément déclaré dans le même paquetage peut voir l’élément .

3.5 Relations entre classes

3.5.1 Généralisation et héritage
La généralisation décrit une relation entre une classe générale (classe de base ou classe
parent) et une classe spécialisée (sous-classe). La classe spécialisée est intégralement
cohérente avec la classe de base, mais comporte des informations supplémentaires (attributs,
opérations, associations). Un objet de la classe spécialisée peut être utilisé partout où un objet
de la classe de base est autorisé.
Le symbole utilisé pour la relation d’héritage ou de généralisation est une flèche avec un trait
plein dont la pointe est un triangle fermé désignant le cas le plus général .

14
 Figure 11: Exemple d’héritage

Figure xxx : Exemple d’héritage.

3.5.2 Associations
Une association est une relation entre deux classes (association binaire) ou plus (association
n-aire),
qui décrit les connexions structurelle entre leurs instances.

Figure 12: Exemple d’association binaire

FIigure xxx : Exemple d’association binaire.

Une association binaire est matérialisée par un trait plein entre les classes associées.
Elle peut être ornée d’un nom, avec éventuellement une précision du sens de lecture (
)
Quand les deux extrémités de l’association pointent vers la même classe, l’association est dite
réflexive.

Figure 13: Exemple d’association n-aire

Figure xxxx : Exemple d’association n-aire.

Une association n-aire lie plus de deux classes. La section 3.3.3 détaille comment interpréter
les multiplicités d’une association n-aire. La ligne pointillé d’une classe-association peut être
reliée au losange par une ligne discontinue pour représenter une association n-aire dotée
d’attributs, d’opérations ou d’associations.

15
On représente une association n-aire par un grand losange avec un chemin partant vers
chaque classe participante. Le nom de l’association, le cas échéant, apparaît à proximité du
losange.
3.5.3 Multiplicité ou cardinalité
La multiplicité associée à une terminaison d’association, d’agrégation ou de composition
déclare le nombre d’objets susceptibles d’occuper la position définie par la terminaison
d’association. Voici quelques exemples de multiplicité :
- exactement un : 1 ou 1..1
- plusieurs : * ou 0..*
- au moins un : 1..*
- de un à six : 1..6 ( quand le maximum est connu)

Remarque
- Il faut noter que, pour les habitués du modèle entité/relation, les multiplicités sont en
UML « à l’envers » (par référence à Merise) pour les associations binaires et « à
l’endroit » pour les n-aires avec n > 2.
3.5.4 Navigabilité
La navigabilité indique s’il est possible de traverser une association. On représente
graphiquement la navigabilité par une flèche du côté de la terminaison navigable et on
empêche la navigabilité par une croix du côté de la terminaison non navigable (cf. figure 3.6).
Par défaut, une association est navigable dans les deux sens.

Figure 14 :Exemple de navigabilité

Figure xxxx : Exemple de navigabilité.

Lorsque l’on représente la navigabilité uniquement sur l’une des extrémités d’une association,
il faut remarquer que, implicitement, les trois associations représentées sur la figure 3.7 ont
la même signification : l’association ne peut être traversée que dans un sens.

Figure 15 : Deux modélisations équivalentes

Figure xxxx : Deux modélisations équivalentes.

16
3.5.5 Classe-association
Une classe-association possède les propriétés des associations et des classes : elle se connecte
à deux ou plusieurs classes et possède également des attributs et des opérations.
Une classe-association est caractérisée par un trait discontinu entre la classe et l’association
qu’elle représente.

Figure 16 : Exemple de classe-association

Figure xxx : Exemple de classe-association.

3.5.6 Agrégation et composition

Une agrégation est une association qui représente une relation d’inclusion structurelle ou
comportementale d’un élément dans un ensemble. Graphiquement, on ajoute un losange
vide (}) du côté de l’agrégat. Contrairement à une association simple, l’agrégation est
transitive.
La composition, également appelée agrégation composite, décrit une contenance structurelle
entre instances. Ainsi, la destruction de l’objet composite implique la destruction de ses
composants. Une instance de la partie appartient toujours à au plus une instance de l’élément
composite. Graphiquement, on ajoute un losange plein du côté de l’agrégat.

Figure 17 : Exemple de relation d’agrégation et de composition

Figure xxxxx : Exemple de relation d’agrégation et de composition.

3.5.7 Dépendances
Une dépendance est une relation unidirectionnelle exprimant une dépendance sémantique
entre les éléments du modèle. Elle est représentée par un trait discontinu orienté. Elle indique
que la modification de la cible implique une modification de la source. La dépendance est
souvent stéréotypée pour mieux expliciter le lien sémantique entre les éléments du modèle.

Figure 18 : Exemple de relation de dépendance

Figure xxx : Exemple de relation de dépendance.

17
3.6 Diagrammes d’objets
Un diagramme d’objets représente des objets (i.e. instances de classes) et leurs liens (i.e.
instances de relations) pour donner une vue de l’état du système à un instant donné. Un
diagramme d’objets permet, selon les situations, d’illustrer le modèle de classes (en montrant
un exemple qui explique le modèle), de préciser certains aspects du système (en mettant en
évidence des détails imperceptibles dans le diagramme de classes), d’exprimer une exception
(en modélisant des cas particuliers, des connaissances non généralisables . . .), ou de prendre
une image (snapshot) d’un système à un moment donné. Le diagramme de classes modélise
les règles et le diagramme d’objets modélise des faits.

Figure 19 : Exemple de diagramme de classes et de diagramme d’objets associé

Figure xxxx : Exemple de diagramme de classes et de diagramme d’objets associé.

18
4 Diagramme d’états-transitions
4.1 Introduction
Les diagrammes d’états-transitions d’UML décrivent le comportement interne d’un objet à
l’aide d’un automate à états finis. Ils présentent les séquences possibles d’états et d’actions
qu’une instance de classe peut traiter au cours de son cycle de vie en réaction à des
événements discrets (de type signaux, invocations de méthode).
Un diagramme d’états-transitions rassemble et organise les états et les transitions d’un
classeur donné.
Bien entendu, le modèle dynamique du système comprend plusieurs diagrammes d’états-
transitions.
Il est souhaitable de construire un diagramme d’états-transitions pour chaque classeur (qui,
le plus souvent, est une classe) possédant un comportement dynamique important. Un
diagramme d’états-transitions ne peut être associé qu’à un seul classeur. Tous les automates
à états finis des diagrammes d’états-transitions d’un système s’exécutent concurremment et
peuvent donc changer d’état de façon indépendante.

5 Formalisme du diagramme d’état-transition

5.1.1 Etat simple
Comme nous l’avons déjà dit, un état, que l’on peut qualifier informellement d’élémentaire,
se représente graphiquement dans un diagramme d’états-transitions par un rectangles aux
coins arrondis.

Figure 20 : Exemple d’état

Figure xx : Exemple d’état

5.1.2 État composite

L’utilisation d’états composites permet de développer une spécification par raffinements. Il
n’est pas nécessaire de représenter les sous-états à chaque utilisation de l’état englobant. Une
notation abrégée permet d’indiquer qu’un état est composite et que sa définition est donnée
sur un autre diagramme.

19
 Figure 21 : Etat composite

Figure xxx : Etat composite

5.1.3 Etat initial

L’état initial est un pseudo état qui indique l’état de départ, par défaut, lorsque le diagramme
d’états-transitions, ou l’état enveloppant, est invoqué. Lorsqu’un objet est créé, il entre dans
l’état initial.

Figure 22 : État initial

Figure xxx : État initial

5.1.4 Etat final

L’état final est un pseudo état qui indique que le diagramme d’états-transitions, ou l’état
enveloppant, est terminé.

Figure 23 : État final

Figure xxx : Etat final

5.1.5 Transition externe

Une transition externe est une transition qui modifie l’état actif. Il s’agit du type de transition
le plus répandu. Elle est représentée par une flèche allant de l’état source vers l’état cible.

Figure 24 : Transition externe

Figure xxx : Transition externe

5.1.6 Transition interne

Les règles de déclenchement d’une transition interne sont les mêmes que pour une transition
externe excepté qu’une transition interne ne possède pas d’état cible et que l’état actif reste

20
le même à la suite de son déclenchement. La syntaxe d’une transition interne reste la même
que celle d’une transition classique. Par contre, les transitions internes ne sont pas
représentées par des arcs mais sont spécifiées dans un compartiment de leur état associé.
Les transitions internes possèdent des noms d’événement prédéfinis correspondant à des
déclencheurs particuliers : entry, exit, do et include. Ces mots clefs réservés viennent prendre
la place du nom de l’événement dans la syntaxe d’une transition interne.

Figure 25 : Transition interne

Figure xxx : Transition interne

5.1.7 Points de jonction

Les points de jonction sont un artefact graphique (un pseudo-état en l’occurrence) qui permet
de partager des segments de transition, l’objectif étant d’aboutir à une notation plus
compacte ou plus lisible des chemins alternatifs.

Figure 26 : Exemples de deux point de jonction

Figure xxx : Exemples de deux point de jonction

5.1.8 Point de décision

Un point de décision possède une entrée et au moins deux sorties. Contrairement à un point
de jonction, les gardes situées après le point de décision sont évaluées au moment où il est
atteint. Cela permet de baser le choix sur des résultats obtenus en franchissant le segment

21
avant le point de choix. Si, quand le point de décision est atteint, aucun segment en aval n’est
franchissable, c’est que le modèle est mal formé.
Il est possible d’utiliser une garde particulière, notée [else], sur un des segments en aval d’un
point de choix. Ce segment n’est franchissable que si les gardes des autres segments sont
toutes fausses.
L’utilisation d’une clause [else] est recommandée après un point de décision car elle garantit
un modèle Bien formé.

Figure 27 : Point de décision

Figure xxx : Point de décision

5.1.9 État historique

Un état historique, également qualifié d’état historique plat, est un pseudo-état qui mémorise
le dernier sous-état actif d’un état composite. Graphiquement, il est représenté par un cercle
contenant un H.

22
 Figure 28 : État historique

Figure xxx : État historique

5.1.10 Point de connexion

Les points de connexion sont des points d’entrée et de sortie portant un nom, et situés sur la
frontière d’un état composite. Ils sont respectivement représentés par un cercle vide et un
cercle barré d’une croix. Il ne s’agit que de références à un état défini dans l’état composite.
Une unique transition d’achèvement, dépourvue de garde, relie le pseudo-état source (i.e. le
point de connexion) à l’état référencé. Cette transition d’achèvement n’est que le
prolongement de la transition qui vise le point de connexion (il peut d’ailleurs y en avoir
plusieurs).

23
 Figure 29 : Point de connexion

Figure xxx : Point de connexion

5.1.11 Nœud de débranchement ou de contrôle

Un nœud de bifurcation, également appelé nœud de débranchement est un noeud de
contrôle qui sépare un flot en plusieurs flots concurrents. Un tel nœud possède donc un arc
entrant et plusieurs arcs sortants. On apparie généralement un nœud de bifurcation avec un
nœud d’union pour équilibrer la concurrence.
Graphiquement, on représente un nœud de bifurcation par un trait plein.

24
 Figure 30 : Noeud de bifurcation ou de débranchement (fork node)

Figure xxx : Noeud de bifurcation ou de débranchement (fork node)

25
6 Diagramme d’activités
6.1 Introduction
Le diagramme d’activité (Activity Diagram) fait partie des diagrammes comportementaux. Il
est utilisé pour modéliser les aspects dynamiques d'un système. Il s'agit de représenter les
opérations d'un processus et leurs conséquences sur les objets (logiciels ou matériels). La
modélisation peut être utilisée pour décrire le déroulement d'un cas d'utilisation ou d'une
méthode.
Les diagrammes d'activité affichent le flux de travail d'un point de départ à un point d'arrivée
en détaillant les nombreux chemins de décision existant dans la progression des événements
contenus dans l'activité.
Ils peuvent être utilisés pour détailler des situations dans lesquelles un traitement parallèle
peut avoir lieu lors de l'exécution de certaines activités. Les diagrammes d'activités sont utiles
pour la modélisation métier car ils sont utilisés pour détailler les processus impliqués dans les
activités métier.
Les diagrammes d'activités permettent de mettre l'accent sur les traitements.
Dans la phase de conception, les diagrammes d'activités sont particulièrement adaptés pour
une plus grande description des cas d'utilisation. Plus précisément, ils viennent illustrer et
consolider la description textuelle.
De plus, leur représentation sous forme d'organigrammes nous les rend facilement
intelligibles. Nous nous concentrons ici sur les activités telles que les voient les acteurs qui
collaborent avec le système dans le cadre d'un processus métier. La modélisation du flot
d'objets est souvent importante dans ce type d'utilisation des diagrammes d'activités.

26
 Figure 31 : exemple de diagramme d’activités

Figure xxxx : exemple de diagramme d’activités

6.2 Formalisme du digramme d’activités

Aactivités :

Une activité définit un comportement décrit par un séquencement organisé d'unités dont les
éléments simples sont les actions. Le flot d'exécution est modélisé par des nœuds reliés par
des arcs (transitions). Le flot de contrôle reste dans l'activité jusqu'à ce que les traitements
soient terminés.
Ce diagramme ci-après représente le fonctionnement d'une borne bancaire qui illustre les
différentes représentations des actions. Après avoir saisi le code, deux activités sont
déclenchées : nous choisissons l'opération souhaitée si le code est valide ou la carte est
restituée si nous annulons l'opération. Après avoir choisi l'opération, nous trouvons deux
alternatives : choisir une somme à déposer (dépôt) ou retirer de l’argent (retrait). Dans les deux
cas, nous spécifions le compte par la suite. Si nous avons choisi de déposer des billets, nous
devons insérer une enveloppe ce qui nous donne droit à la restitution de notre carte à la fin de
l'opération. Si nous avons choisi d'effectuer un retrait de billets, nous lançons deux actions
simultanées : afficher une publicité et demander en même temps une autorisation de retrait.
Dans tous les cas de figure, la carte bancaire est restituée et nous arrivons à la fin du processus.

27
Une activité possède éventuellement des paramètres en entrée ou en sortie, ainsi que des
variables locales au même titre qu'une méthode d’un objet. Une activité peut regrouper des
nœuds et des arcs, c’est ce que nous appelons « groupe d'activités ».

Figure 32 : diagrammes d’activités opérations DAB

Figure xxx : diagrammes d’activités opérations DAB

Quelques formalismes

Nœuds
activités

Transitions

28
Nœud d’actions
(action node)

Noeud de
bifurcation ou de
débranchement
(fork node) :
Nœuds de
stockage de
données (data
store node)

Pins
d’entrée/sortie

Les noeud d’objet

(object node) et
les flots d’objet

Figure xxx : Formalisme diagrammes d’activités

29
7 Diagrammes de séquence
7.1 Rôle du diagramme de séquence
Le diagramme de séquence fait parties des diagrammes comportementaux (dynamique) et
plus précisément des diagrammes d’interactions.

- Il permet de représenter des échanges entre les différents objets et acteurs du système
en fonction du temps.
- A moins que le système à modéliser soit extrêmement simple, nous ne pouvons pas
modéliser la dynamique globale du système dans un seul diagramme. Nous ferons
donc appel à un ensemble de diagrammes de séquences chacun correspondant à une
sous fonction du système, généralement d’ailleurs pour illustrer un cas d’utilisation.

7.2 Représentation du diagramme de séquence

7.2.1 Délimitation du diagramme de séquence
Le diagramme de séquence est placé dans un rectangle qui dispose d’une étiquette sd en
haut à gauche (qui signifie sequence diagramm) suivi du nom du diagramme.
7.2.2 L’objet
Dans un diagramme de séquence, l’objet à la même représentation que dans le diagramme
des objets. C'est-à-dire un rectangle dans lequel figure le nom de l’objet. Le nom de l’objet
est généralement souligné et peut prendre l’une des quatre formes suivantes :

Figure xxxx : objet

Les diagrammes de séquences représentant les échanges entre les objets mais aussi les
échanges avec les acteurs, nous trouverons aussi la représentation du stickman (qui peut être
considéré comme un objet).
7.2.3 La ligne de vie
Comme il représente la dynamique du système, le diagramme de séquence fait entrer en
action les instances de classes intervenant dans la réalisation d’un cas d’utilisation particulier.

30
• A chaque objet est associé une ligne de vie (en trait pointillés à la verticale de l’objet) qui
peut être considéré comme un axe temporel (le temps s’écoule du haut vers le bas). Dans ce
genre de diagramme, la quantification du temps n’a pas d’importance.

La ligne de vie indique les périodes d’activité de l’objet (généralement, les moments ou l’objet
exécute une de ces méthodes).

Lorsque l’objet est détruit, la ligne de vie s’achève par une croix.

Figure xxx : ligne de vie

7.2.4 Les messages

7.2.4.1 Définition
Un message définit une communication particulière entre des lignes de vie. Ainsi, un message
est une communication d’un objet vers un autre objet. La réception d’un message est
considérée par l’objet récepteur comme un événement qu’il faut traiter (ou pas). Plusieurs
types de messages existent, les plus communs sont :
- L’invocation d’une opération : message synchrone (appel d’une méthode de l’objet
cible).
- L’envoi d’un signal : message asynchrone (typiquement utilisé pour la gestion
événementielle).
- La création ou la destruction d’une instance de classe au cours du cycle principal.

• Les messages synchrones : La réception d’un message synchrone doit provoquer chez le
destinataire le lancement d’une de ses méthodes (qui souvent porte le même nom que le
message). L’expéditeur du message reste bloqué pendant toute l’exécution de la méthode et
attend donc la fin de celle-ci avant de pouvoir lancer un nouveau message. C’est le message
le plus fréquemment utilisé.

• Les messages asynchrones : Dans le cas d’un message asynchrone, l’expéditeur n’attend pas
la fin de l’activation de la méthode invoquée chez le destinataire. Un message asynchrone
peut être :

31
 - Un appel de méthode : Fréquent dans un système multi-threads (multi-tâche). Ainsi,
l’objet expéditeur n’étant pas bloqué pendant l’exécution de la méthode, il peut
continuer ainsi à envoyer d’autres messages.
- Un signal (cas le plus fréquent) : L’objet expéditeur transmet juste une information à
l’objet destinataire. Souvent, ce sont les acteurs ou les périphériques qui envoient
des signaux, typiquement utilisé dans la gestion événementielle d’une IHM
graphique, comme la librairie QT, par exemple.
7.2.4.2 Représentation graphique
Dans le diagramme de séquence, les envois de messages sont représentés par des flèches
horizontales qui vont de la ligne de vie de l’objet émetteur vers la ligne de vie de l’objet
récepteur du message.

- Les messages synchrones : (flèche avec un triangle plein à son extrémité).

- Les messages asynchrones : (simple flèche)
- Les messages de retour (réponses) : (simple flèche en pointillés).

Figure xxx : représentation graphique messages

Si une méthode qui a été activée (par un message) doit retourner des valeurs à la fin de son
activation, cela se fait par un message retour. o Le message de retour n’est donc pas un appel
de méthode (il ne provoque donc pas l’activation d’un objet) o Le message retour porte
souvent le nom de l’élément retourné.

32
 Figure xxx : messages synchrones et asynchrones

7.2.4.3 Création et destruction d’objets

Une séquence peut aussi contenir la création ou la destruction d’un objet :

- La création d’un objet est matérialisée par un message spécifique, appel d’un
constructeur, généralement accompagné du stéréotype « create » qui pointe sur le
début (le sommet) de la ligne de vie de l’objet créé (Le rectangle de l’instance de la
classe est alors surbaissée).
- La destruction d’un objet est représentée par une croix à la fin de sa ligne de vie.
Souvent l’objet est détruit suite à la réception d’un message mais ce n’est pas
obligatoire. Dans ce cas là, il porte le stéréotype « destroy ».

Figure xxx : création et destruction d’objets

7.2.4.4 Syntaxe des messages synchrones et asynchrones

Dans la plupart des cas, la réception d’un message est suivie de l’exécution de la méthode de
la classe cible. Cette méthode peut recevoir des arguments et la syntaxe des messages permet
de transmettre ces arguments. La plupart du temps, dans un diagramme de séquence, nous
pouvons nous contenter de définir un message par : - Son nom (qui est le nom de la méthode

33
appelée ou du signal envoyé). Nous pouvons lui adjoindre facultativement : - Une
numérotation devant le nom message (séparé du nom du message par 2 point " : "). La
numérotation s’effectue séquentiellement à partir de 1. - Les paramètres passés à la méthode
ou au signal (entre parenthèses après le nom du message).

Figure xxx : syntaxe de messages

7.2.4.5 Syntaxe des réponses (messages retour)

Comme pour les messages synchrones ou asynchrones, nous pouvons nous contenter de
donner au message retour un simple nom, mais nous pouvons aussi les caractériser plus
précisément en utilisant la syntaxe suivante : numéro : attribut = nomMessage (paramètres) :
valeurDeRetour.

34
 Figure xxx : réponse de message

7.2.4.6 Remarque sur la syntaxe des messages dans les diagrammes de séquence
La syntaxe que nous venons de voir est simple et très souvent largement suffisante pour
décrire les messages des diagrammes de séquence.

7.3 Quelques séquences expliquées

7.3.1 Messages retours implicites et explicites
Le retour d’un message synchrone peut ne pas être représenté, le retour est alors implicite.
Par contre, dans le cas d’un message asynchrone, il est impératif de faire apparaître le
message de retour. Le retour est explicite. Bien entendu, si l’exécution de la méthode lancée
par le message asynchrone ne doit rien retourner, il est évident que nous ne devons pas
représenter le message de retour (c'est généralement le cas le plus classique, notamment avec
la gestion événementielle). Les 3 diagrammes suivants sont équivalents :

Figure xxx : messages implicites et explicites

7.3.2 Recouvrement des bandes d’activations

Lorsqu’un objet est déjà activé il peut quand même recevoir d’autres messages (appel d’une

35
autre de ses méthodes), cela se représente par un dédoublement de la bande d’activation.

7.3.3 Messages récursifs

Un objet peut s’envoyer un message à lui-même (utilisation d’une autre méthode du même
objet). Cela se représente là aussi par un dédoublement de la bande d’activation.

Figure xxx : Messages récursifs

7.3.4 Contraintes temporelles

Des repères temporels avec des contraintes peuvent être placés le long de la ligne de
vie. Un message avec un temps de propagation non négligeable peut être représenté
par une flèche oblique ou en l'écrivant explicitement.

Figure xxxx : contraintes temporelles

7.3.5 Messages perdus et trouvés

- Le message perdu est un message dont nous connaissons l’émetteur mais pas le récepteur.
Il est représenté par une flèche partant de la ligne de vie d’un élément vers un disque noir. Le
message perdu pouvant être, à l’origine, synchrone ou asynchrone, nous avons donc les types
de pointes de flèches. Cette sorte de message permet de modéliser, par exemple, les scenarii
de pertes de message sur un réseau.

36
 Figure xxxx : messages perdus et trouvés

- Le message trouvé est un message dont nous connaissons le destinataire mais pas
l’émetteur. Il est représenté par une flèche partant d’un disque noir vers la ligne de vie d’un
élément. Ce message peut être utilisé pour modéliser le comportement d’un élément suite à
la réception d’un message d’exception.

7.4 Fragments d’interactions combinés

Un fragment d’interactions est une partie du diagramme de séquence (délimitée par un
rectangle) associée à une étiquette (dans le coin supérieur gauche). L’étiquette contient un
opérateur d’interaction qui permet de décrire des modalités d’exécution des messages à
l’intérieur du cadre.

Figure xxx : fragment d’interactions combinés

Les opérandes d’un opérateur d’interaction sont séparés par une ligne pointillée. Les
conditions de choix des opérandes (éventuels) sont données par des expressions booléennes
entre crochets ([ ]). Les principales modalités sont les boucles, les branchements
conditionnels, les alternatives, les envois simultanés, etc.

7.4.1 Fragment d’interaction avec opérateur « opt »

37
L’opérateur option (opt) comporte un opérande et une condition de garde associée. Le
sousfragment s’exécute si la condition de garde est vraie et ne s’exécute pas dans le cas
contraire.

Figure xxxx :

7.4.2 Fragment d’interaction avec opérateur « alt »

L’opérateur alternatives (alt) est un opérateur conditionnel possédant plusieurs opérandes
séparés par des pointillés. C’est l’équivalent d’une exécution à choix multiples. Chaque
opérande détient une condition de garde. Seul le sous-fragment dont la condition est vraie est
exécuté. La condition else est exécutée que si aucune autre condition n’est valide.

Figure xxxx :

7.4.3 Fragment d’interaction avec opérateur « loop »

L’opérateur de boucle (loop) exécute une itérative dont la séquence qu’elle contient est
exécutée tant que la garde qui lui est associée est vraie.

- La garde s’écrit de la façon suivante : loop [min, max, condition] : Chaque paramètre (min,

38
max et condition) est optionnel.

o Le contenu du cadre est exécuté min fois, puis continue à s’exécuter tant que la condition
et que le nombre d’exécution de la boucle ne dépasse pas max fois.

- Exemple de gardes : loop[3]→La séquence s’exécute 3 fois.

Loop[1, 3, code=faux] La séquence s’exécute 1 fois puis un maximum de 2 autres fois si

code=faux.

Figure xxxx :

7.4.4 Fragment d’interaction avec opérateur « par »

Un fragment d’interaction avec l’opérateur de traitements parallèles (par) contient au moins
deux sous fragments (opérandes) séparés par des pointillés qui s’exécutent simultanément
(traitements concurrents).

Figure xxxx :

7.4.5 Autres fragments d’interactions

Nous venons de voir les 4 fragments d’interactions les plus utilisés (opt, alt, loop et par). Il en

39
existe en réalité 13 au total, ci-dessous la liste des 8 autres :
- ignore et considere : pour les fragments facultatifs ou obligatoires.
- critical : pour les fragments qui doivent se dérouler sans être interrompus.
- break : pour les fragments représentants des scenarii exceptionnels ou de ruptures (ex
appui sur la touche « Esc »). Le scénario de rupture est exécuté si une condition de
garde est satisfaite.
- assert : Pour les fragments dont on connaît à l’avance les paramètres du message
(exemple : après la saisie des 4 chiffres d’un code, la saisie suivante sera
obligatoirement la touche « Entrée »).
- seq : indique que le fragment est composé de plusieurs sous fragments qui peuvent
s’exécuter dans n’importe quel ordre (mais pas en même temps).
- strict : pour les fragments dont les messages doivent se dérouler dans un ordre bien
précis.
- neg : pour indiquer que la séquence à l’intérieur du fragment n’est pas valide.
- ref : permet de faire appel à un autre diagramme de séquence.

7.5 Exemple de diagramme de séquence

Le DAB Un cas d’utilisation est très souvent documenté par une description textuelle. Un
diagramme de séquence permet de compléter et de visualiser simplement et intuitivement la
description textuelle. Dans le cours sur les diagrammes des cas d’utilisations, nous avons fait
une description textuelle du cas d’utilisation « Retirer de l’argent » du DAB. Le diagramme de
séquence du scénario nominale est le suivant :

Figure xxxx :

40
Grâce aux fragments d’interactions, il est possible de documenter un scénario alternatif (ou
d’exception) dans le diagramme de séquence du scénario nominale. Par exemple, le
diagramme de séquence ci-dessous correspond à la description du scénario nominal et du
scénario alternatif SA4 (porteur de carte client banque).

Figure xxxx :

41
8 Diagrammes de composants et de déploiement
8.1 Diagramme de composants
8.1.1 Notion de composant (component) et d’interface
UML, un composant est un élément logiciel remplaçable et réutilisable qui fourni ou reçoit un
service bien précis. Il peut être vu comme une pièce détachée du logiciel. Les plu-gins, les
drivers, les codecs, les bibliothèques sont des composants.
La notion de composant est proche de celle d’objet, dans le sens de la modularité et de
réutilisation avec toute fois une granularité qui peut être différente. Le composant est à
l’architecture du logiciel ce que l’objet est à l’architecture du code. Les composants
fournissent des services via des interfaces. Un composant peut être remplacé par n’importe
quel autre composant compatible c'est-à-dire ayant les mêmes interfaces. Un composant peut
évoluer indépendamment des applications ou des autres composants qui l’utilise à partir du
moment ou les interfaces sont respectées. Il existe deux types d’interface :

✔ Les interfaces requise : Ce sont des interfaces qui fournissent un service au composant et
dont il a besoin pour fonctionner.

✔ Les interfaces fournies : Ce sont des interfaces par lesquels le composant fourni lui-même
un service.
2)Représentation graphique : 2-1) Les composants : Il existe plusieurs possibilités pour
représenter un composant, à vous de choisir :

Figure xxxx :

8.1.2 Les interfaces

La aussi, il existe plusieurs possibilités pour représenter les interfaces :
- Intégrées dans la représentation du composant : Nous reprenons l’une des trois
représentations du composant que nous venons juste de voir et nous ajoutons un
compartiment dans lequel nous listons les interfaces requises et fournies (grâce aux
stéréotypes <<required interface>> et <<provided interface>>).

42
 Figure xxxx :

• Dans un classeur séparé du composant dans lequel sont listés les différents services :

✔ Les interfaces requises sont reliées au composant par une flèche en pointillées sur laquelle
figure le stéréotype <<use>>.

✔ Les interfaces fournies sont reliées au composant par une flèche en pointillées sur laquelle
figure le stéréotype <realize> (le bout de la flèche est un triangle vide).

Figure xxxx :

- Avec des connecteurs d’assemblage :

✔ Les interfaces requises (représentées par un demi-cercle) et les interfaces fournies

(représentées par un cercle) sont raccordées au composant par un trait.

Figure xxxx :

Exemple de transfert de données par Internet

43
 Figure xxxx :

8.1.3 Les ports

Le port est le point de connexion entre le composant et son environnement, il est la
matérialisation de l’interface. Nous le représentons par un petit carré à la périphérie du
composant.

Figure xxxx :

8.1.4 Boite noire-boites blanche

Un composant peut être vu de 2 manières : ✗ Comme une boite noire dont nous ne
connaissons pas le contenu et auquel nous accédons via les interfaces qui sont la seule partie
visible. ✗ Comme une boite blanche en spécifiant les objets qui constituent le composant et
en indiquant leurs relations.

44
Ex : Transfert de données par Internet vu précédemment.

Figure xxxx :

8.1.5 Rôle du diagramme de composants

Le diagramme de composants fait partie des diagrammes structuraux (statiques) d’UML. Il
permet de représenter les différents éléments logiciels (composants) du système et leurs
dépendances (relations qui les lient). Comme nous venons de le voir dans le chapitre
précédent lorsque nous définissons la notion de composant, ces dépendances peuvent être :
- Des relations de compositions (boîte blanche)
- Des relations d’assemblages et de connexion (via des interfaces) Mais elles peuvent
aussi être d’autre type tel que :
✓ Des contraintes de compilation, des éditions de liens (les composant sont alors des
fichiers de code source, des fichiers en binaire, des bibliothèques…). Dans ce cas, un
stéréotype peut préciser la nature de la dépendance.
Ex : Compilation de fichiers en C++.

45
 Figure xxxx :

8.2 Diagramme de déploiement

8.2.1 Rôle du diagramme de déploiement
Le diagramme de déploiement fait partie des diagrammes structuraux (statique), il représente
:

- la disposition physique des ressources matérielles qui constituent le système et

montre la répartition des composants (élément logiciels) sur ces matériels.
- La nature des connexions de communication entre les différentes ressources
matérielles.

8.3 Les éléments du diagramme de déploiement

8.3.1 Les nœuds
Un nœud est une ressource matérielle du système. En général, cette ressource possède au
minimum de la mémoire et parfois aussi des capacités de calcul (des ressources humaines ou
des périphériques sont des ressources modélisées par des nœuds). Les ressources matérielles
sont quelquefois représentées avec le stéréotype <> (généralement plutôt les périphériques
mais également tout système informatique comme par exemple les ordinateurs de bureau).

Un nœud est représenté par un parallélépipède rectangle dans lequel figure son nom

46
 Figure xxxx :

Un nœud possède des attributs (quantité de mémoire, vitesse de processeur, marque, type…)
que nous pouvons spécifier à l’intérieur du parallélépipède.

Figure xxxx :

Pour montrer qu’un composant est affecté sur un nœud, il faut :

- Soit en plaçant le composant dans le nœud.

- Soit en le reliant à l'aide d'une relation de dépendance (flèche en pointillées)
stéréotypée «support» orientée du composant vers le nœud .

Figure xxxx :

47
8.3.2 Les chemins de communications
Les différents nœuds qui apparaissent dans le diagramme de déploiement sont connectés
entre eux par des lignes qui symbolisent un support de communication → Ce sont les chemins
de communications. Le chemin de communication est donc un lien qui permet de modéliser
de façon simpliste la communication entre 2 nœuds (liaison Ethernet, USB, série…).

Il est possible de faire figurer sur ce lien :  les cardinalités ;

- des contraintes entre accolades (pour indiquer par exemple qu’un accès est sécurisé)
;
- le type de réseau et/ou son débit en l’indiquant comme un stéréotype…

Figure xxxx :

8.3.3 Les artefacts :

L'artefact est le terme générique qui désigne n'importe quel élément produit du travail, c’est
un élément concret et existant dans le monde réel (document, exécutable, fichier, base de
données…). L’implémentation des modèles se fait sous forme d’artefacts. On dit que l’artefact
est la manifestation du modèle qu’il implémente.

→ Ce sont les artefacts qui sont déployés sur les nœuds et nom pas les composants. Un
artefact se représente par un rectangle contenant son nom et le stéréotype <artefact> (nous

pouvons aussi y faire figurer le symbole ). Un artefact qui est la manifestation d’un
composant est relié à celui-ci par une relation de dépendance (flèche en pointillées)
stéréotypé <manifast> orienté de l’artefact vers le composant.

Figure xxxx :

L’artefact est placé soit :

- À l’intérieur du nœud dans lequel il est déployé.

48
 Figure xxxx :

- À l’extérieur du nœud dans lequel il est déployé, mais relié à celui-ci par une relation
de dépendance stéréotypé <deploy>.

- Figure xxxx :
-

8.3.4 Exemples de projet

Ci-dessous vous pouvez découvrir deux exemples de projet réels. Remarquez la présence de
plusieurs stéréotypes supplémentaires qu'il est possible de proposer (caractère non
obligatoire), comme :
• <process> : processus représentant une application qui réalise un traitement
spécifique,
• < database > : base de données,
• <service> : application qui rend service à un autre nœud,
• <entitty> : entité représentant la classe persistante dans les bases de données objet,
• <table> : table d'une base de données,
• <config> : fichier de configuration,
<ressource> : ressource quelconque, comme une bibliothèque applicative...

49
Figure xxx : Projet de transfert de photos par Internet

50
Figure xxxx : Projet de mesure et d'analyse de consommation énergétique

51
Figure xxxx : Exemple de diagramme de déploiement

52
9 Bibliographie :
UML 2.0, guide de référence . James Rumbaugh, Ivar Jacobson, Grady Booch. Editions Campus
Press (2005)

UML 2.0 . Benoît Charoux, Aomar Osmani, Yann Thierry-Mieg. Editions Pearson, Education
France (2008)

UML 2.0 Superstructure et UML 2.0 Infrastructure OMG (Object Management Group).
www.uml.org (2004).

J. Gabay, Merise. Vers OMT et UML, InterÉditions, 1998.

N. Kettani, D. Mignet, P. Paré et C. Rosenthal-Sabroux, De MERISE à UML, Eyrolles, 1998 : recommandé

!

M. Lai, Penser objet avec UML et Java, InterÉditions, 1998.

M. Lai, UML : La notation unifiée de modélisation objet – De Java aux EJB, Dunod, 2000

N. Lopez, J. Migueis et E. Pichon, Intégrer UML dans vos projets, Eyrolles, 1997.

C. Morley, B. Leblanc et J. Hugues, UML pour l'analyse d'un système d'information – Le cahier des
charges du maître d'ouvrage, Dunod, 2000.

P.-A. Muller, Modélisation objet avec UML, Eyrolles, 1998 : souvent cité et conseillé !

P. Roques et F. Vallée, UML en action – De l’analyse des besoins à la conception en Java, Eyrolles, 2000.
C. Soutou, Objet-Relationnel sous Oracle8, Modélisation avec UML, Eyrolles, 1999. 1.5.2. Les
références (ouvrages et articles cités dans la documentation d’UML 1.3)

C. Bock et J. Odell, “A Foundation For Composition”, Journal of Object-Oriented Programming, oct.

1994.

G. Booch, J. Rumbaugh et I. Jacobson, The Unified Modeling Language User Guide, Addison-Wesley,
1999.

S. Cook et J. Daniels, Designing Object Systems: Object-oriented Modelling with Syntropy, Prentice Hall
Object-Oriented Series, 1994.

D. D’Souza et A. Wills, Objects, Components and Frameworks with UML: The Catalysis Approach,
Addison-Wesley, 1999.

53
M. Fowler avec K. Scott, UML Distilled: Applying the Standard Object Modeling Language, Addison-
Wesley, 1997.

M. Griss, “Domain Engineering And Variability In The Reuse-Driven Software Engineering Business”,
Object Magazine, déc. 1996.

D. Harel, “Statecharts: A Visual Formalism for Complex Systems”, Science of Computer Programming
8, 1987, pp. 231- 274.

D. Harel et E. Gery, “Executable Object Modeling with Statecharts”, Proc. 18th Int. Conf. Soft. Eng.,
Berlin, IEEE Press, mars 1996, pp. 246-257.

D. Harel et A. Naamad, “The STATEMATE Semantics of Statecharts”, ACM Trans. Soft. Eng. Method 5:4,
oct. 1996.

I. Jacobson, G. Booch et J. Rumbaugh, The Unified Software Development Process, Addison-Wesley,

1999.

R. Malan, D. Coleman, R. Letsinger et al., “The Next Generation of Fusion”, Fusion Newsletter, oct.
1996.

J. Martin et J. Odell, Object-Oriented Methods, A Foundation, Prentice Hall, 1995.

G. Ramackers et D. Clegg, “Object Business Modelling, requirements and approach” in Sutherland, J.

and Patel, D. (eds.), Proceedings of the OOPSLA95 Workshop on Business Object Design and
Implementation, Springer Verlag.

G. Ramackers et D. Clegg, “Extended Use Cases and Business Objects for BPR”, ObjectWorld UK ‘96,
Londres, 18-21 juin 1996.

J. Rumbaugh, I. Jacobson et G. Booch, The Unified Modeling Language Reference Manual, Addison-
Wesley, 1999.

B. Selic, G. Gullekson et P. Ward, Real-Time Object-Oriented Modeling, John Wiley & Sons, 1994.

J. Warmer et A. Kleppe, The Object Constraint Language: Precise Modeling with UML, Addison-Wesley,
1999.

54