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..............................................................................................5
1.1 Notions de modèle.................................................................................................................5
1.2 Modélisation orientée objets.................................................................................................5
1.2.1 Fondamentaux de l’orienté objets..................................................................................5
1.2.2 Concepts importants de l’approche objet......................................................................6
1.3 UML........................................................................................................................................7
1.3.1 Brève introduction..........................................................................................................7
1.3.2 Conception orientée objet et diagrammes.....................................................................7
2 Processus Unifié (PU).....................................................................................................................9
2.1 Description du processus unifié..............................................................................................9
2.1.1 Définition du processus unifié........................................................................................9
2.1.2 Caractéristiques du processus unifié..............................................................................9
2.1.3 Cycle de vie du processus unifié...................................................................................10
2.1.4 Activités........................................................................................................................11
2.1.5 Phases...........................................................................................................................12
2.2 Résumé de la démarche PU & UML......................................................................................13
3 Diagramme de cas d’utilisation....................................................................................................14
3.1 Introduction..........................................................................................................................14
3.2 Formalisme du diagramme de cas d’utilisation....................................................................14
3.2.1 Acteurs..........................................................................................................................14
3.2.2 Cas d’utilisation.............................................................................................................14
3.2.3 Relations d’associations................................................................................................14
3.2.4 Relations entre cas d’utilisation....................................................................................16
3.2.5 Relations entre acteurs.................................................................................................17
3.3 Description textuelle des cas d’utilisation............................................................................17
3.4 Exemple de diagrammes de cas d’utilisation........................................................................18
4 Diagramme de classes..................................................................................................................20
4.1 Introduction..........................................................................................................................20
4.2 Classes..................................................................................................................................20
4.3 Méthodes.............................................................................................................................20
4.4 Représentation graphique d’une classe................................................................................20
4.5 Relations entre classes.........................................................................................................21
4.5.1 Généralisation et héritage............................................................................................21

1
 4.5.2 Associations..................................................................................................................22
4.5.3 Plusieurs associations entre deux classes.....................................................................22
4.5.4 Association réflexive.....................................................................................................22
4.5.5 Dépendance entre classe..............................................................................................23
4.5.6 Multiplicité ou cardinalité.............................................................................................23
4.5.7 Navigabilité...................................................................................................................24
4.5.8 Classe-association.........................................................................................................24
4.5.9 Agrégation et composition...........................................................................................24
4.5.10 Dépendances................................................................................................................25
4.5.11 Type énuméré...............................................................................................................25
4.6 Diagrammes d’objets............................................................................................................26
4.7 Exemples de diagrammes de classes....................................................................................27
4.8 Exemple de diagrammes objets............................................................................................28
5 Diagramme d’états-transitions.....................................................................................................29
5.1 Introduction..........................................................................................................................29
5.2 Formalisme du diagramme d’état-transition........................................................................29
5.2.1 Etat simple....................................................................................................................29
5.2.2 État composite..............................................................................................................29
5.2.3 Etat initial......................................................................................................................30
5.2.4 Etat final........................................................................................................................30
5.2.5 Transition externe.........................................................................................................30
5.2.6 Transition interne.........................................................................................................30
5.2.7 Points de jonction.........................................................................................................31
5.2.8 Point de décision..........................................................................................................31
5.2.9 État historique..............................................................................................................31
5.2.10 Point de connexion.......................................................................................................32
5.2.11 Nœud de débranchement ou de contrôle....................................................................33
5.3 Exemples d’état-transition...................................................................................................34
6 Diagramme d’activités..................................................................................................................36
6.1 Introduction..........................................................................................................................36
6.2 Formalisme du digramme d’activités....................................................................................37
6.2.1 Activités :......................................................................................................................37
6.2.2 Quelques formalismes..................................................................................................38
6.3 Exemple de diagramme d’activité........................................................................................39
7 Diagrammes de séquence............................................................................................................40
7.1 Rôle du diagramme de séquence.........................................................................................40

2
 7.2 Représentation du diagramme de séquence........................................................................40
7.2.1 Délimitation du diagramme de séquence.....................................................................40
7.2.2 L’objet...........................................................................................................................40
7.2.3 Ligne de vie...................................................................................................................40
7.2.4 Messages......................................................................................................................41
7.3 Quelques séquences expliquées...........................................................................................44
7.3.1 Messages retours implicites et explicites.....................................................................44
7.3.2 Recouvrement des bandes d’activations......................................................................44
7.3.3 Messages récursifs........................................................................................................44
7.3.4 Contraintes temporelles...............................................................................................45
7.3.5 Messages perdus et trouvés.........................................................................................45
7.4 Fragments d’interactions combinés.....................................................................................46
7.4.1 Fragment d’interaction avec opérateur « opt »............................................................46
7.4.2 Fragment d’interaction avec opérateur « alt ».............................................................46
7.4.3 Fragment d’interaction avec opérateur « loop »..........................................................47
7.4.4 Fragment d’interaction avec opérateur « par »............................................................47
7.4.5 Autres fragments d’interactions...................................................................................48
7.5 Exemple de diagramme de séquence...................................................................................48
8 Diagrammes de composants et de déploiement..........................................................................51
8.1 Diagramme de composants..................................................................................................51
8.1.1 Notion de composant (component) et d’interface.......................................................51
8.1.2 Interfaces......................................................................................................................51
8.1.3 Les ports.......................................................................................................................53
8.1.4 Boite noire-boites blanche............................................................................................53
8.1.5 Rôle du diagramme de composants.............................................................................54
8.2 Diagramme de déploiement.................................................................................................54
8.2.1 Rôle du diagramme de déploiement............................................................................54
8.3 Eléments du diagramme de déploiement.............................................................................54
8.3.1 Nœuds..........................................................................................................................54
8.3.2 Chemins de communications........................................................................................55
8.3.3 Artefacts :.....................................................................................................................56
8.3.4 Exemples de projet.......................................................................................................56
9 Bibliographie :..............................................................................................................................60

3
4
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
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.

5
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
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.

6
L’agrégation permet donc d’assembler des objets de base, afin de construire des objets plus
complexes.

Figure 1 Concepts Orienté objet

1.3 UML
1.3.1 Brève introduction
UML : Unified Modeling Language
Normalisé par l'OMG (Object Management Group)
http://www.omg.org/spec/UML/
Dernière version : 2.4.1 (Août 2011)
Notation standard pour la modélisation d'applications à base d'objets (et de composants depuis la
version 2)
Mais utilisable dans de nombreux autres contextes de conception ou spécification  Exemple :
schéma de BDD
Langage utilisant une notation graphique

Comme tout type de projet, un projet informatique nécessite une phase d’analyse, suivi
d’une étape de conception.
1.3.2 Conception orientée objet et diagrammes
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.

7
 Figure 2: 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 :
- une norme ;
- un langage de modélisation objet ;
- un support de communication ;
- un cadre méthodologique.

8
2 Processus Unifié (PU)
Il existe plusieurs méthodes de développement logiciel construites sur UML comme la
méthode : UP, RUP, TTUP, UP agile, XP, 2TUP ….. Parmi ses méthodes notre choix est basé
sur la méthode UP (Unified Process)

2.1 Description du processus unifié

2.1.1 Définition du processus unifié
Le processus unifié est un processus de développement logiciel itératif, centré sur l'architecture,
Piloté par des cas d'utilisation et orienté vers la diminution des risques. C'est un patron de processus
pouvant être adaptée à une large classe de systèmes logiciels, à différents domaines d'application, à
différents types d'entreprises, à différents niveaux de compétences et à différentes tailles de
l'entreprise.

Le Processus Unifié utilise les notations UML

Figure 3 Processus unifié & UML

- Un processus de développement logiciel définit qui fait quoi, quand et comment pour
atteindre un objectif donné
- U.P. (Unified Process - Processus Unifié) = processus de développement logiciel
prenant en charge le cycle de vie d’un logiciel et de son développement
- Contrairement aux démarches antérieures :
 UP prend en compte l’ensemble des intervenants : client, utilisateur,
gestionnaire, qualiticien, … d’où l’adjectif “unified”,
 UP est générique pour les logiciels orientés objets utilisant UML comme
langage de modélisation,
 UP est itérative et incrémentale.
2.1.2 Caractéristiques du processus unifié
UP est itératif et incrémental Le projet est découpé en itérations ou étapes de courte durée qui
permettent de mieux suivre l’avancement globale. A la fin de chaque itération une partie exécutable
du système finale est produite, de façon incrémentale (par ajout).

9
 Figure 4 Déroulement du Processus Unifié

UP est centré sur l'architecture. Tout système complexe doit être décomposé en partie modulaire
afin d’en faciliter la maintenance et l’évolution. Cette architecture (fonctionnelle, logique, matérielle,
etc.) doit être modéliser en UML, et pas seulement documentée en texte.
UP est guidé par les cas d'utilisation d'UML Le but principal d’un système d’informatique est de
satisfaire les besoins de client. Le processus de développement sera donc accès sur l’utilisateur. Le
cas d’utilisation permet d’illustrer ces besoins. Ils détectent puis décrivent les besoins fonctionnels et
leur ensemble constitue le modèle de cas d’utilisation qui dicte les fonctionnalités complètes du
système. UP est piloté par les risques Les risques majeurs du projet doivent être identifiés au plus tôt
mais surtout levés le plus rapidement. Les mesures à prendre dans ce cadre déterminent l’ordre des
itérations.

2.1.3 Cycle de vie du processus unifié

L'objectif d'un processus unifié est de maîtriser la complexité des projets informatiques en diminuant
les risques. UP est un ensemble de principes génériques adapté en fonctions des spécificités des
projets. L’architecture bidirectionnelle : UP gère le processus de développement par deux axes. L'axe
vertical : représente les principaux enchaînements d'activités, qui regroupent les activités selon leur
nature. Cette dimension rend compte l'aspect statique du processus qui s'exprime en termes de
composants, de processus, d'activités, d'enchaînements, d'artefacts et de travailleurs. L'axe
horizontal : représente le temps et montre le déroulement du cycle de vie du processus ; cette
dimension rend compte de l'aspect dynamique du processus qui s'exprime en termes de cycles, de
phases, d'itérations et de jalons.

10
 Figure 5 Architecture bidirectionnelle

Pour mener efficacement un tel cycle, les développeurs ont besoins de toutes les représentations du
produit logiciel.

- un modèle de cas d'utilisation.

- un modèle d'analyse : détailler les cas d'utilisation.
- un modèle de conception : finissant la structure statique du système sous forme de sous-
systèmes, de classes et interfaces.
- un modèle d'implémentation : intégrant les composants
- un modèle de déploiement : définissant les nœuds physiques des ordinateurs
- un modèle de test : décrivant les cas de test vérifiant les cas d'utilisation
- une représentation de l'architecture.

2.1.4 Activités
Expression des besoins

L'expression des besoins comme son nom l'indique, permet de définir les différents besoins :

- inventorier les besoins principaux et fournir une liste de leurs fonctions ;

- recenser les besoins fonctionnels (du point de vue de l'utilisateur) qui conduisent à
l'élaboration des modèles de cas d'utilisation ;
- appréhender les besoins non fonctionnels (techniques) et livrer une liste des exigences. :
L’architecture bidirectionnelle :( le langage UML et le processus unifié )

Le modèle de cas d'utilisation présente le système du point de vue de l'utilisateur et représente sous
forme de cas d'utilisation et d'acteur, les besoins du client

Analyse

L'objectif de l'analyse est d'accéder à une compréhension des besoins et des exigences du client. Il
s'agit de livrer des spécifications pour permettre de choisir la conception de la solution. Un modèle

11
d'analyse livre une spécification complète des besoins issus des cas d'utilisation et les structure sous
une forme qui facilite la compréhension (scénarios), la préparation (définition de l'architecture), la
modification et la maintenance du futur système. Il s'écrit dans le langage des développeurs et peut
être considéré comme une première ébauche du modèle de conception.

Conception

La conception permet d'acquérir une compréhension approfondie des contraintes liées au langage de
programmation, à l'utilisation des composants et au système d'exploitation. Elle détermine les
principales interfaces et les transcrit à l'aide d'une notation commune. Elle constitue un point de
départ à l'implémentation :

- elle décompose le travail d'implémentation en sous-système

- elle créée une abstraction transparente de l'implémentation Implémentation
L'implémentation est le résultat de la conception pour implémenter le système sous formes
de composants, c'est-à-dire, de code source, de scripts, de binaires, d'exécutable et d'autres
éléments du même type. Les objectifs principaux de l'implémentation sont de planifier les
intégrations des composants pour chaque itération, et de produire les classes et les sous-
systèmes sous formes de codes sources.

Test

Les tests permettent de vérifier des résultats de l'implémentation en testant la construction. Pour
mener à bien ces tests, il faut les planifier pour chaque itération, les implémenter en créant des cas
de tests, effectuer ces tests et prendre en compte le résultat de chacun. Chapitre I : le langage UML
et le processus unifié

2.1.5 Phases
Analyse des besoins

L'analyse des besoins donne une vue du projet sous forme de produit fini. Cette phase porte
essentiellement sur les besoins principaux (du point de vue de l'utilisateur), l'architecture générale
du système, les risques majeurs, les délais et les coûts.

Elaboration

L'élaboration reprend les éléments de la phase d'analyse des besoins et les précise pour arriver à une
spécification détaillée de la solution à mettre en œuvre. L'élaboration permet de préciser la plupart
des cas d’utilisation, de concevoir l’architecture du système et surtout de déterminer l'architecture
de référence.

Construction

La construction est le moment où l’on construit le produit. L’architecture de référence se

métamorphose en produit complet. Le produit contient tous les cas d’utilisation que les chefs de
projet, en accord avec les utilisateurs ont décidé de mettre au point pour cette version.

Transition

Le produit est en version bêta. Un groupe d’utilisateurs essaye le produit et détecte les
anomalies et défauts. Cette phase suppose des activités comme la formation des utilisateurs

12
clients, la mise en œuvre d’un service d’assistance et la correction des anomalies constatées.
Tout simplement la phase de transition permet de faire passer le système informatique des
mains des développeurs à celles des utilisateurs finaux.

2.2 Résumé de la démarche PU & UML

Le langage UML nous apporte une aide à toutes les étapes d’un projet, comme il nous offre ainsi de
nombreux avantages pour l’analyse et la conception d’un système, Le couple UML et le processus
unifié propose une approche pour conduire la réalisation de systèmes orienté objet.

13
3 Diagramme de cas d’utilisation
3.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.

3.2 Formalisme du diagramme de cas d’utilisation

3.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 6 : Exemple de représentation d’un acteur

3.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 7 : Exemple de représentation d’un cas d’utilisation

14
3.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 8 : Exemple simplifié de diagramme de cas d’utilisation modélisant une borne d’accès à une banque

Figure 9 : 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
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 »

15
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.
3.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 10 : 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.

16
 Figure 11: Relations entre cas pour décomposer un cas complexe

3.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 12 : Relations entre acteurs

3.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).

17
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 embranchements dans la séquence
nominale) et des séquences d’exceptions (qui interviennent quand une erreur se produit).
Les préconditions : elles décrivent dans quel état doit être le système (l’application) avant
que ce cas d’utilisation puisse être déclenché.
Des scé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.

3.4 Exemple de diagrammes de cas d’utilisation

Exemple 1 : Gestion de stock

18
 Figure 13 Diagramme de cas d'utilisation gestion de stock d'articles

Exemple 2 : Gestion de salle de cours

Figure 14 DCU de la gestion de salle de cours

19
4 Diagramme de classes
4.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 .

4.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.

4.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. 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).

4.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.

20
 Figure 15 : 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 16: 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.

4.5 Relations entre classes

4.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 .

Figure 17: Exemple d’héritage

21
4.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 18: 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 19: Exemple d’association n-aire

Une association n-aire lie plus de deux classes. 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.
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.
4.5.3 Plusieurs associations entre deux classes
On peut définir une ou plusieurs associations entre deux classes

Figure 20 Exemple d’auto-association

4.5.4 Association réflexive

Une classe peut être en association avec elle-même.

22
 Figure 21 Exemple d'auto-association

Comment lire ça ?
Une personne est l’enfant d’une autre personne
Une personne est le parent d’une autre personne

4.5.5 Dépendance entre classe

Lors d’une dépendance, une première classe utilise une deuxième sans que cette dernière ` soit un
membre de la première

Figure 22 Exemple de dépendance entre classe

4.5.6 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.
4.5.7 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

23
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 23 : 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 24 : Deux modélisations équivalentes

4.5.8 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 25 : Exemple de classe-association

4.5.9 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.

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

4.5.10 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 27 : Exemple de relation de dépendance

4.5.11 Type énuméré

Figure 28 Diagramme de classes modélisant une entreprise et des personnes

Le diagramme de la figure ci-dessus modélise des personnes, leurs liens de parenté

(enfant/parent et mari/femme) et le poste éventuel de ces personnes dans une société.

Figure 29 Définition d'une énumération en utilisant un classeur

25
Ce diagramme introduit un nouveau type de classeur, stéréotypé « enumeration »,
permettant de définir une énumération. Une énumération est un type de donnée UML,
possédant un nom, et utilisé pour énumérer un ensemble de littéraux correspondant à
toutes les valeurs possibles que peut prendre une expression de ce type. Un type énuméré
est défini par un classeur possédant le stéréotype « enumeration ».

Figure 30 association d'une classe à une énumération.

4.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 31 : Exemple de diagramme de classes et de diagramme d’objets associé

4.7 Exemples de diagrammes de classes

Exemple 1

26
Exemple 2

27
4.8 Exemple de diagrammes objets

28
5 Diagramme d’états-transitions
5.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.2 Formalisme du diagramme d’état-transition

5.2.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 32 : Exemple d’état

5.2.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.

Figure 33 : Etat composite

29
5.2.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 34 : État initial

5.2.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 35 : État final

5.2.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 36 : Transition externe

5.2.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 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 37 : Transition interne

30
5.2.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 38 : Exemples de deux points de jonction

5.2.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
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 39 : Point de décision

5.2.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.

31
 Figure 40 : État historique

5.2.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).

32
 Figure 41 : Point de connexion

5.2.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.

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

5.3 Exemples d’état-transition

Exemple 1 : diagramme d'état transition du processus d'enregistrement dans un aéroport

34
 Figure 43 processus d'enregistrement dans un aéroport

Exemple 2 : Processus d’inscription dans une université jusqu’à l’examen final

Figure 44 Processus d’inscription dans une université

35
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.

36
 Figure 45 : exemple de diagramme d’activités

6.2 Formalisme du digramme d’activités

6.2.1 Activité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.
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 ».

37
 Figure 46 : diagrammes d’activités opérations DAB

6.2.2 Quelques formalismes

Tableau 1: Formalisme des diagrammes d'activités

Nœuds
activités

Transitions

Nœud d’actions
(action node)

38
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

6.3 Exemple de diagramme d’activité

Figure 47 Diagramme d'activités Processus gestion commande

39
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 diagram) suivi du nom du diagramme.
7.2.2 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 48: objets

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 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. • A chaque objet est associé une ligne de vie (en trait pointillés à la verticale de

40
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 49 : Ligne de vie

7.2.4 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 :

- 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 à

41
 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 50: 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é.

Figure 51: 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

42
 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 52: 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 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 53: 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.

43
 Figure 54: 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 55: 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
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.

44
 Figure 56

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 57: 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.

Figure 58: 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.

45
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 59: 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 »

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 60: interaction operateur opt

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.

46
 Figure 61: interaction operateur alt

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,
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 62: interaction operateur loop

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).

47
 Figure 63 : inteaction opeateur par

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 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 :

48
 Figure 64: exemple de diagramme de séquence

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).

49
Figure 65: diagramme de séquence et description de scénario nominal

50
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 fournit 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 toutefois 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 où 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 66: Formalisme des composants

8.1.2 Interfaces
Là 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>>).

51
 Figure 67: Représentation des composants

 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 68 : Liaison de composants

- 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 69 : Représentation des interfaces

Exemple de transfert de données par Internet

52
 Figure 70 : exemple de diagramme de composants

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 71 : Les ports

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.
Exemple : Transfert de données par Internet vu précédemment.

Figure 72 : Exemple de diagrammes avec des ports

53
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.
Exemple : Compilation de fichiers en C++.

Figure 73: exemple de codage en C

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 Eléments du diagramme de déploiement

8.3.1 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
54
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

Figure 74: Formalisme des noeuds

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 75 : Noeud et composant

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 .

8.3.2 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…

55
 Figure 76 : Communication entre noeud

8.3.3 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 77 : Artefact

L’artefact est placé soit :

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

Figure 78 : Artefact placé à l'interieur

56
 - À 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 79: Artefact placé à l'extérieur

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...

57
 Figure 80 : Projet de transfert de photos par Internet

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

58
59
Figure 82 : Exemple de diagramme de déploiement

60
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.
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.

61
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.

62