Vous êtes sur la page 1sur 78

Université Ibn Zohr Agadir

Ecole Nationale des Sciences Appliquées


ENSA -4 G-INFO 2018-2019
Module: UML2
Prof. Abderrahmane Elyousfi
elyousfiabdo@yahoo.fr
Département: Génie Informatique

Unified Modeling Language (UML 2.0)


Langage unifié pour la modélisation objet
Abderrahmane ELYOUSFI

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Introduction générale

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

1
 UML est un langage graphique de modélisation.
 UML est devenu un standard de fait puisqu’il s’appuie sur une norme très structurante.
 Les fondateurs d’UML sont James Rumbaugh, Ivar Jacobson et Grady Booch qui ont
été dès le début des années 90 des références dans le monde des méthodes de
développement objets.
 Les ouvrages qu’ils ont écrits à l’époque sont: [Rumbaugh1991], [Booch1994] et
[Jacobson1992].
 C’est grâce à un premier niveau de travail de fond mené en commun par ces trois
compères qu’est née en 1995 la méthode dite unifiée qui a été ensuite consacrée par
l’OMG (Object Management Group) en 1997 avec la diffusion de la première version de la
norme : UMLV1.1.
 L’OMG est l’organisme international de normalisation a en charge non seulement la
norme UML mais aussi d’autres réflexions méthodologiques comme l’approche MDA
(Model Driven Architecture) qui pousse encore plus loin les limites de l’automatisation de
la production du logiciel.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

 UML est un langage graphique de modélisation.


 UML est devenu un standard de fait puisqu’il s’appuie sur une norme très structurante.
 Les fondateurs d’UML sont James Rumbaugh, Ivar Jacobson et Grady Booch qui ont
été dès le début des années 90 des références dans le monde des méthodes de
développement objets.
 Les ouvrages qu’ils ont écrits à l’époque sont: [Rumbaugh1991], [Booch1994] et
[Jacobson1992].
 C’est grâce à un premier niveau de travail de fond mené en commun par ces trois
compères qu’est née en 1995 la méthode dite unifiée qui a été ensuite consacrée par
l’OMG (Object Management Group) en 1997 avec la diffusion de la première version de la
norme : UMLV1.1.
 L’OMG est l’organisme international de normalisation a en charge non seulement la
norme UML mais aussi d’autres réflexions méthodologiques comme l’approche MDA
(Model Driven Architecture) qui pousse encore plus loin les limites de l’automatisation de
la production du logiciel.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

2
 UML 2 contient treize diagrammes

 Les diagrammes comportementaux :


 diagramme des cas d’utilisation,
 diagramme d’activité,
 diagramme d’état-transition,
 diagramme de séquence,
 diagramme de communication,
 diagramme global d’interaction
 et diagramme de temps.
ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

 UML 2 contient treize diagrammes

 Les diagrammes structurels :


 diagramme de classe,
 diagramme d’objet,
 diagramme de composant,
 diagramme de déploiement,
 diagramme de paquetage
 diagramme de structure composite.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

3
ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Diagramme de cas
d’utilisation

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

4
Objectif des diagrammes d’interaction

Les cas d’utilisation.


Relations entre acteurs et cas d’utilisation.
Relations entre cas d’utilisation.
Relations entre acteurs

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Modélisation des besoins

 Avant de développer un système, il faut savoir précisément à QUOI il


devra servir, c.à.d à quels besoins il devra répondre.

 Modéliser les besoins permet de :


 Faire l'inventaire des fonctionnalités attendues ;
 Organiser les besoins entre eux, de manière à faire apparaître des
relations (réutilisations possibles, ...).

 Avec UML, on modélise les besoins au moyen de diagrammes de cas


d'utilisation.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

5
Exemple de diagramme de cas d'utilisation

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Définition du cas d'utilisation et du cas d’utilisation

 Un cas d’utilisation est une manière spécifique d’utiliser


un système.

 Un cas d’utilisation réalise un service de bout en bout,


avec un déclenchement, un déroulement et une fin, pour
l’acteur qui l’initie.

 Les acteurs modélisent tout ce qui interagit avec le


système. Ils sont à l’extérieur du système.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

6
Notation du cas d'utilisation et du cas d’utilisation

 Un cas d’utilisation se représente par une ellipse. Le nom


du cas est inclus dans l’ellipse.

 Un acteur se représente par un petit bonhomme ayant son nom inscrit


dessous.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Relations entre acteurs et cas d’ utilisation

 Les acteurs impliqués dans un cas d'utilisation lui sont liés


par une association.

 Un acteur peut utiliser plusieurs fois le même cas


d'utilisation.

 Le symbole * qui signifie « plusieurs » est ajouté à l’extrémité du cas


et s’appelle une multiplicité.

 Plusieurs valeurs sont possibles pour la multiplicité : exactement n


s’écrit tout simplement n, m..n signifie entre m et n, etc.
ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

7
Relations entre cas d’utilisation

Il y’a trois relations possible entre cas d’utilisation.

 La relation d’inclusion.

 La relation d’extension.

 La relation de généralisation.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Relations entre cas d’utilisation


La relation d’inclusion
 Un cas A est inclus dans un cas B si le comportement décrit par le cas A est inclus
dans le comportement du cas B : on dit alors que le cas B dépend de A.
 Cette dépendance est symbolisée par le stéréotype inclut. Le sens des flèches indique la
dépendance, pas le sens de la relation d'inclusion(la même chose aussi pour l’extension).

 l’accès aux informations d’un compte bancaire inclut nécessairement une phase
d’authentification avec un mot de passe.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

8
Relations entre cas d’utilisation
La relation d’extension
 Si le comportement de B peut être étendu par le comportement de A, on dit
alors que A étend B. Une extension est souvent soumise à condition.
Graphiquement, la condition est exprimée sous la forme d’une note.

 la vérification du solde du compte n’intervient que si la demande de retrait


d’argent dépasse 20 euros.
ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Relations entre cas d’utilisation


La 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.
 Cette relation représente le concept d’héritage dans les langages orientés
objet.

 la consultation d’un compte bancaire via Internet est un cas particulier de la


consultation.
ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

9
Décomposition grâce aux inclusions et aux extensions
 Quand un cas est trop complexe (faisant intervenir un trop grand nombre
d'actions), on peut procéder à sa décomposition en cas plus simples.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Décomposition grâce aux inclusions et aux extensions


 Les relations entre cas ne sont pas obligatoires.

 Elles permettent de clarifier et d’enrichir les cas d’utilisation.

 Par exemple, à la précédente, rien n’empêche de regrouper les cas « Consulter


comptes » et « Consulter sur Internet » en un seul cas.

 Cependant, indiquer dès la phase de recueil des besoins qu’il y a des cas
particuliers apporte une information supplémentaire pertinente.

 La question à se poser est : faut-il la faire figurer dans le diagramme de cas


d’utilisation ou la prendre en compte plus tard ? La réponse à cette question
ne sera pas toujours la même selon le contexte du projet.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

10
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 (tous les cas d’utilisation accessibles à A le sont aussi à
B, mais l’inverse n’est pas vrai).

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Relations entre acteurs

 La figure suivante montre que le directeur des ventes est un préposé aux
commandes avec un pouvoir supplémentaire.

 En plus de pouvoir passer et suivre une commande, il peut gérer le stock. Le


préposé aux commandes ne peut pas gérer le stock.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

11
Acteurs principaux et secondaires

Notation:
 Le symbole utilisé pour la généralisation entre acteurs est une flèche en
traits pleins dont la pointe est un triangle fermé.
 La flèche pointe vers l’acteur le plus général.

 L’acteur est dit « principal » pour un cas d’utilisation lorsque le cas


d’utilisation rend service à cet acteur.
 Les autres acteurs sont dits « secondaires ».
 Un cas d’utilisation a au plus un acteur principal, et un ensemble –
éventuellement vide – d’acteurs secondaires.
 Un acteur principal obtient un résultat observable du système tandis qu’un
acteur secondaire est sollicité pour des informations complémentaires.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Identification des acteurs

 Les principaux acteurs sont les utilisateurs du système.

 En plus des utilisateurs, les acteurs peuvent être :

 Des périphériques manipulés par le système (imprimantes...) ;

 des logiciels déjà disponibles à intégrer dans le projet ;

 des systèmes informatiques externes au système mais qui


interagissent avec lui, etc.

 Pour faciliter la recherche des acteurs, on se fonde sur les frontières du


système.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

12
Description des cas d'utilisation

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Diagramme d’interaction

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

13
Objectif des diagrammes d’interaction

 Le diagramme de cas d’utilisation montre des acteurs qui interagissent avec les
grandes fonctions d’un système. C’est une vision fonctionnelle et externe d’un
système.

 Le diagramme de classes, quant à lui, décrit le cœur d’un système et montre


des classes et la façon dont elles sont associées. C’est une vision statique et
structurelle.

 Les diagrammes d’interaction permettent d’établir un pont entre ces deux


approches : ils montrent comment des instances au coeur du système
communiquent pour réaliser une certaine fonctionnalité. Les interactions sont
nombreuses et variées.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Objectif des diagrammes de séquence

 UML propose trois diagrammes pour exprimer ces interactions : diagramme de


séquence, diagramme de communication et le diagramme de timing. Ils
apportent un aspect dynamique à la modélisation du système.

 Le diagramme de séquence montre des interactions sous un angle


temporel, et plus particulièrement le séquencement temporel de messages
échangés entre des lignes de vie,

 Le diagramme de communication montre une représentation spatiale


des lignes de vie.

 le diagramme de timing. Son usage est limité à la modélisation des


systèmes qui s’exécutent sous de fortes contraintes de temps, comme les
systèmes temps réel.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

14
définition

 Une interaction décrit le comportement d’un classeur en se focalisant sur


l’échange d’informations entre les éléments du classeur. Les participants à une
interaction sont appelés « lignes de vie ».

 Une ligne de vie représente un participant unique à une interaction.

 Le terme « ligne de vie » est utilisé car, souvent, les interactions montrent des
objets (instances de classes). Au cours d’une interaction, des objets peuvent
être créés, utilisés, et parfois détruits.

 Ce cycle de vie des objets est matérialisé par une ligne (la ligne de vie) qui
court dans les diagrammes d’interaction

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Notation

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


le coin supérieur gauche, un pentagone accompagné du mot-clé sd lorsqu’il
s’agit d’un diagramme de séquence, et de com lorsqu’il s’agit d’un
diagramme de communication.

 Le mot-clé est suivi du nom de l’interaction.

 La liste des lignes de vie qui figurent dans le diagramme peut suivre le nom de
l’interaction.

 Des attributs peuvent être indiqués près du sommet du rectangle contenant le


diagramme.

 Une ligne de vie se représente par un rectangle auquel est accrochée une ligne
verticale pointillée. Le rectangle contient un identifiant dont la syntaxe est la
suivante :

[<nomDeLaLigneDeVie> [’[’sélecteur’]’]] : <NomDeClasseur> [décomposition]

où le sélecteur permet de choisir un objet parmi n


ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

15
Notation
Exemple: Un diagramme de séquence d’un distributeur de billets.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

UTILISATION DES INTERACTIONS

 L’approche objet du développement d’un système recommande une


conception modulaire (de sorte que les parties du système soient
réutilisables).

 Le langage de modélisation doit permettre la représentation de cette


modularité. Il n’est pas souhaitable de faire figurer toutes les interactions sur
un seul diagramme.

 Le modélisateur doit pouvoir focaliser son attention sur un sous-ensemble


d’éléments du système et étudier leur façon d’interagir pour donner un
comportement particulier au système.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

16
ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Diagramme de séquence

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

17
plan

 MESSAGE ET ÉVÉNEMENTS

 SYNTAXE DES MESSAGES

 CONTRAINTES SUR LES LIGNES DE VIE

 FRAGMENTS D’INTERACTION COMBINÉS

 DÉCOMPOSITION D’UNE LIGNE DE VIE

 LES ÉTATS INVARIANTS

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Introduction

 Les principales informations contenues dans un diagramme de séquence sont


les messages échangés entre les lignes de vie.

 Un message définit une communication particulière entre des lignes de vie.

 Plusieurs types de messages existent. Les plus communs sont :

 l’envoi d’un signal ;

 l’invocation d’une opération ;

 la création ou la destruction d’une instance.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

18
Principaux types de messages

Objet anonyme Objet anonyme Objet identifié Objet identifié


non typé typé non typé typé

Cette figure représente quatre objets, dont un objet anonyme non typé, un
objet anonyme typé, un objet identifié non typé et un objet identifié typé.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Principaux types de messages

Objet anonyme Objet anonyme Objet identifié Objet identifié


non typé typé non typé typé
 Dans une application, tout objet est au moins instance d’une classe
concrète. Cette classe est celle qui a permis de construire l’objet.
 En UML, les objets qui participent à une interaction peuvent ne pas avoir
de classe dont ils sont instances.
 Nous appellerons ces objets des objets non typés.
 Les objets non typés sont utilisés dans les interactions pour spécifier des
objets qui ne font que demander la réalisation d’opérations et dont on ne
se intéresse pas de connaître le type.
ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

19
Principaux types de messages

Objet anonyme Objet anonyme Objet identifié Objet identifié


non typé typé non typé typé
 Dans une application, tout objet a un identifiant.
 En UML, les objets qui participent à une interaction peuvent ne pas avoir
d’identifiant. Nous appellerons ces objets des objets anonymes.
 Les objets anonymes sont utilisés dans les interactions pour spécifier des
objets qui ne sont utilisés qu’une seule fois. Il ne sert alors à rien de bien
les identifier.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Principaux types de messages

 Un message synchrone bloque l'expéditeur jusqu'à la réponse du


destinataire. Le flot de contrôle passe de l'émetteur au récepteur.

 Typiquement : appel de méthode

 Si un objet A invoque une méthode d'un objet B, A reste bloqué tant que
B n'a pas terminé.

 On peut associer aux messages d'appel de méthode un message de retour


(en pointillés) marquant la reprise du contrôle par l'objet émetteur du
message synchrone.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

20
Principaux types de messages

 Un message asynchrone n'est pas bloquant pour l'expéditeur. Le


message envoyé peut être pris en compte par le récepteur à tout
moment ou ignoré.

 L’émetteur d’un message asynchrone n’étant pas bloqué le temps que


le message parvienne au récepteur, une série de messages peut être
envoyée avant qu’un seul ne soit reçu.

 De plus, les messages peuvent être reçus dans un ordre différent de


l’ordre d’envoi.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Notation

Un message synchrone se représente par une flèche à l’extrémité


pleine qui pointe sur le destinataire du message. Ce message peut
être suivi d’une réponse qui se représente par une flèche en
pointillé.

Un message asynchrone se représente par une flèche à l’extrémité


ouverte.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

21
Notation

La création d’un objet est matérialisée par une flèche qui pointe
sur le sommet d’une ligne de vie.

La destruction d’un objet est matérialisée par une croix qui marque
la fin de la ligne de vie de l’objet.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

2-MESSAGE ET ÉVÉNEMENTS

 L’invocation d’une opération ou l’envoi d’un signal peut déclencher


une réaction chez le récepteur.

 La réaction la plus courante est l’exécution d’une méthode (rappel :


une méthode est l’implémentation d’une opération).

 Ce n’est cependant pas la seule réaction possible. Par exemple, un


signal d’erreur (souvent appelé « exception ») peut être interprété
comme une simple alerte qui ne déclenchera pas nécessairement
l’exécution d’une méthode.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

22
2-MESSAGE ET ÉVÉNEMENTS

 UML permet de séparer clairement l’envoi du message de sa


réception, ainsi que le début de l’exécution de la réaction de sa fin.

 Des événements sont utilisés pour marquer chaque étape.

 Ainsi, la transmission d’un message est contrôlée par l’occurrence de


deux événements : un pour l’envoi et un pour la réception.

Notation

 La spécification de l’exécution d’une réaction se fait par:


 un rectangle blanc ou gris placé sur la ligne de vie.
 un rectangle portant un label.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

2-MESSAGE ET ÉVÉNEMENTS
Diagramme de séquence où un message envoyé provoque l’exécution d’une
méthode chez le récepteur.

l’exécution d’une réaction

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

23
2-MESSAGE ET ÉVÉNEMENTS
Diagramme de séquence où un message envoyé provoque l’exécution d’une
méthode chez le récepteur.

l’exécution d’une réaction

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

2-MESSAGE ET ÉVÉNEMENTS

 Grâce aux événements d’envoi et de réception, UML définit trois


types de messages :

 Un message complet est tel que les événements d’envoi et de


réception sont connus.

 Un message perdu est tel que l’événement d’envoi est connu,


mais pas l’événement de réception.

 Un message trouvé est tel que l’événement de réception est


connu, mais pas l’événement d’émission.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

24
2-MESSAGE ET ÉVÉNEMENTS

 Un message complet se représente par une simple flèche dirigée de


l’émetteur vers le récepteur.

 Un message perdu se représente par une flèche qui pointe sur une
boule noire.

 Une flèche qui part d’une boule noire symbolise un message trouvé.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

2 Syntaxe des messages

 UML permet de modéliser tout type de système. Mais bien souvent,


les implémentations se font via des langages de programmation.

 Dans la plupart des cas, la réception d’un message est suivie de


l’exécution d’une méthode d’une classe.

 Cette méthode peut recevoir des arguments et la syntaxe des


messages permet de transmettre ces arguments.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

25
2.2 SYNTAXE DES MESSAGES

Notation
 La syntaxe des messages est :
nomSignalOuOperation ( parametres )

 La syntaxe des arguments est la suivante :


nomParametre = valeurParametre

 Pour un argument modifiable :


nomParametre : valeurParametre

 Exemples :
 appeler("Capitaine Hadock", 54214110)
 afficher(x,y)
 initialiser(x=100)
 f(x:12)
ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

2.2 SYNTAXE DES MESSAGES de retour

Notation
 La syntaxe des messages de retour est :
attributCible = nomOperation ( params ): valeurRetour

 La syntaxe des paramètres est :


nomParam = valeurParam
Ou
nomParam : valeurParam

 Les messages de retour sont représentés en pointillés.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

26
2.2 SYNTAXE DES MESSAGES

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

3- Contraintes sur les lignes de vie

 Les lignes de vie d’une interaction peuvent porter toutes sortes de


contraintes.
 Si la ligne de vie est un objet par exemple, une contrainte sur la
valeur d’un attribut peut être posée.

Notation
 Une contrainte est indiquée sur une ligne de vie par un texte entre
accolades.
 Une contrainte peut aussi être contenue dans une note attachée à
l’occurrence de l’événement sur lequel elle agit.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

27
2.3 CONTRAINTES SUR LES LIGNES DE VIE

 Une contrainte est évaluée au cours de l’exécution de l’interaction.

 Si la condition de la contrainte n’est pas vérifiée, les occurrences


d’événement qui suivent cette contrainte sont considérées comme
invalides,

 alors qu’une contrainte qui se vérifie rend valides les événements à


suivre.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

2.3 CONTRAINTES SUR LES LIGNES DE VIE


 La figure suivante montre que, pour démarrer le moteur d’un avion, il est
impératif de vérifier le niveau d’essence ;

 après vérification l’attribut essence doit avoir une valeur supérieure à 0.

 si la quantité d’essence est nulle, décoller devient un message invalide.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

28
4-Fragments d’interaction combinés

 Les langages de programmation par leur syntaxe permettent


d’écrire des tests et des boucles très simplement.

 UML, sans être un langage de programmation, propose une syntaxe


qui se veut complète.

 UML permet de décomposer une interaction en fragments


suffisamment simples pour les faire tenir sur un schéma.

 La combinaison des fragments permet de reconstituer la complexité


du système. Le terme générique en vigueur pour UML est « fragments
combinés ».

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

4-Fragments d’interaction combinés


 La figure suivante montre comment représenter, à l’aide d’UML,
l’équivalent du test des langages de programmation.
 À cette figure, l’opérateur d’interaction alt indique que le fragment est
un choix. Les deux options de choix sont appelées « opérandes de
l’opérateur alt ».

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

29
4-Fragments d’interaction combinés

Notation
 Un fragment combiné se représente de la même façon qu’une
interaction : par un rectangle dont le coin supérieur gauche contient
un pentagone.

 Dans le pentagone figure le type de la combinaison (appelé «


opérateur d’interaction »).

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Type d'opérateurs d'interaction

Notation
 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 sont données par des expressions
booléennes entre crochets.
 La liste suivante regroupe les opérateurs d’interaction par fonctions :
 les opérateurs de choix et de boucle : alternative, option, break et loop ;
 les opérateurs contrôlant l’envoi en parallèle de messages: parallel et critical region ;
 les opérateurs contrôlant l’envoi de messages: ignore, consider, assertion et negative ;
 les opérateurs fixant l’ordre d’envoi des messages: weak sequencing, strict sequencing.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

30
Opérateur de alternative (Alt)

 L’opérateur alt correspond à une instruction de test avec une ou plusieurs alternatives
possibles. Il est aussi permis d’utiliser les clauses de type sinon.
 L’opérateur alt se représente dans un fragment possédant au moins deux parties
séparées par des pointillés.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Opérateur optional (opt)

 L’opérateur opt (optional) correspond à une instruction de test sans alternative


(sinon).
 L’opérateur opt se représente dans un fragment possédant une seule partie

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

31
Opérateur de boucle (loop)

Syntaxe d'une boucle :


loop (minNbIterations , maxNbIterations )
 La boucle est répétée au moins minNbItérations fois avant qu'une éventuelle
condition booléenne ne soit testée (la condition est placée entre crochets dans le
fragment)
 Tant que la condition est vraie, la boucle continue, au plus maxNbItérations fois.
 L’opérateur loop se représente dans un fragment possédant une seule partie et
englobant toutes les interactions faisant partie de la boucle.

Notation
 loop(valeur) est équivalent à loop(valeur,valeur).
 loop est équivalent à loop(0,*), où * signifie illimité .

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Opérateur de boucle (loop)

La figure suivante montre comment une boucle peut être représentée.


L’exemple illustre la fermeture en boucle de toutes les portes d’un train.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

32
Opérateur parallèle (par)
 L’opérateur par permet d’envoyer des messages en parallèle.
 Ses opérandes se déroulent en parallèle.
 Plus précisément, les événements qui jalonnent un opérande (l’envoi du
message, la réception du message…) forment une trace.
 Soumise à l’opérateur par, la trace d’un opérande est conservée (l’ordre des
événements est le même), mais les différentes traces des différents
opérandes s’entrelacent n’importe comment.
 En conséquence, la trace finale, obtenue par la fusion des traces des
opérandes, peut varier d’un déroulement à l’autre.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Opérateur parallèle (par)


 L’opérateur par permet d’envoyer des messages en parallèle.
 Ses opérandes se déroulent en parallèle.
 Ce qui se passe de part et d'autre de la ligne pointillée est indépendant.
 L’opérateur par se représente dans un fragment possédant au moins deux
parties séparées par une ligne en pointillé.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

33
Opérateur parallèle (par)

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Opérateur break (break)

 L’opérateur break permet de représenter une situation exceptionnelle


correspondant à un scénario de rupture par rapport au scénario général.

 Le scénario de rupture s’exécute si la condition de garde est satisfaite.

 L’opérateur break se représente dans un fragment possédant une seule


partie.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

34
Opérateur break (break)

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Opérateurs ignore et consider


 Les opérateurs ignore et consider sont utilisés pour des fragments
d’interactions dans lesquels on veut montrer que certains messages peuvent
être :
 Soit absents sans avoir d’incidence sur le déroulement des interactions
(ignore),
 soit obligatoirement présents (consider).

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

35
Opérateurs ignore et consider
 dans le fragment consider, les messages Op1, Op2 et Op5 doivent être obligatoirement présents
lors de l’exécution du fragment sinon le fragment n’est pas exécuté,
 dans le fragment ignore, les messages Op2 et Op3 peuvent être absents lors de l’exécution du
fragment.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Opérateur critical
 L’opérateur critical permet d’indiquer qu’une séquence d’interactions ne
peut être interrompue compte tenu du caractère critique des opérations
traitées.
 On considère que le traitement des interactions comprises dans la séquence
critique est atomique.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

36
Opérateur critical
 L’exemple de la figure ci-dessous montre que les opérations Op1( ), Op2( ) et
Op3( ) du fragment critical doivent s’exécuter sans interruption.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Opérateur critical
 La demande d’arrêt doit être impérativement suivie de l’arrêt du moteur du
robot. L’opérateur critical est utilisé pour définir une section critique.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

37
Opérateur negative (neg)
 L’opérateur neg (negative) permet d’indiquer qu’une séquence d’interactions
est invalide.
 L’exemple présenté figure ci-dessous montre que les opérations Op1( ) et
Op2( ) du fragment neg sont invalides.
 Une erreur sera déclenchée dans ce cas à l’exécution du fragment.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Opérateur assertion (assert)


 L’opérateur assert (assertion) permet d’indiquer qu’une séquence d’interactions est
l’unique séquence possible en considérant les messages échangés dans le fragment.
Toute autre configuration de message est invalide.

 L’exemple de cette figure montre que le fragment assert ne s’exécutera que si


l’unique séquence de traitement Op1( ), Op2( ) et Op3( ) se réalise en respectant
l’ensemble des caractéristiques de ces opérations (paramètre d’entrée, type de
résultat…). Toute autre situation sera considérée invalide.

38
Opérateur assertion (assert)
 L'opérateur d'assertion rend indispensable l'envoi d'un message. Si la condition de la
contrainte n'est pas vérifiée, les occurrences des évènements qui suivent sont
considérés comme invalides.

 si la quantité d'essence est nulle, décoller() devient un message invalide

Opérateur assertion (assert)


 Quand un étudiant s'inscrit pour un examen dans le système d'administration des
étudiants, l'étudiant reçoit un e-mail après l'enregistrement.
 Si cette séquence n'est pas implémentée avec précision comme spécifié, une erreur se
produit.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

39
Opérateur strict sequencing

 Les opérateurs srict et weak permettent de représenter une série


d’interactions dont certaines s’opèrent sur des objets indépendants :

 L’opérateur strict est utilisé quand l’ordre d’exécution des opérations


doit être strictement respecté.

 L’opérateur weak est utilisé quand l’ordre d’exécution des opérations n’a
pas d’importance.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Opérateur strict sequencing


 L’opérateur strict sequencing impose que ses opérandes se déroulent dans
l’ordre strict de leur présentation, c’est-à-dire de haut en bas.
 L’ordre imposé ne s’applique qu’à ses opérandes, et d’éventuels fragments
imbriqués peuvent avoir, en interne, un séquencement quelconque.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

40
Opérateur strict sequencing
 Avant de faire décoller un avion, il faut contrôler sa ckeck-list.
 Le détail des interactions pour contrôler la check-list et pour faire décoller
l’avion n’est pas donné.
 D’autres diagrammes référencés sous le label ref s’en chargent.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Opérateur strict sequencing


 In this example, a lecturer only prints an exam when a student has registered
for it.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

41
Opérateur strict sequencing
 L’exemple de la figure suivante montre que les opérations A1, A2, B1, B2 et
A3 doivent être exécutées dans cet ordre puisqu’elles font partie du fragment
d’interaction comportant l’opérateur strict.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

5- DÉCOMPOSITION D’UNE LIGNE DE VIE

 Parfois, une interaction est trop complexe pour être décrite sur un
seul diagramme.

 UML permet de décomposer à volonté une ligne de vie sur plusieurs


diagrammes.

Notation

 Une décomposition est référencée dans le rectangle en tête de ligne


de vie, sous le label ref

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

42
Réutilisation d'une interaction
 Réutiliser une interaction consiste à placer un fragment portant
la référence ref là où l'interaction est utile.
 On spécifie le nom de l'interaction dans le fragment.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Utilisation d'un DS pour modéliser un cas d'utilisation


 Chaque cas d'utilisation donne lieu à un diagramme de
séquences.

 Les inclusions et les extensions sont des cas typiques


d'utilisation de la réutilisation par référencement.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

43
Utilisation d'un DS pour spécier une méthode
 Une interaction peut être identifiée par un fragment sd

 Un message peut partir du bord de l'interaction, spécifiant le


comportement du système après réception du message, quel
que soit l'expéditeur

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Diagramme de communication

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

44
Introduction

 Les diagrammes de communication et les diagrammes de séquences


sont deux types de diagramme d'interaction. Ils servent le plus
souvent à illustrer un cas d’utilisation ou à décrire une opération.

 Ils représentent la même chose, mais sous des formes différentes.

 Un diagramme de séquence montre des interactions sous un angle


temporel, en mettant l'emphase sur le séquencement temporel de
messages échangés entre des lignes de vie.

 Un diagramme de communication représente des interactions du


point de vue spatial. Il montre une représentation spatiale des lignes
de vie.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Diagrammes de séquence et de communication

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

45
Diagrammes de communication

 Un diagramme de communication pour illustrer la


fermeture des portes d’un train.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Ligne de vie

 Un diagramme de communication contient des lignes de vie, à


l’instar des diagrammes de séquence : elles représentent toujours des
participants uniques à une interaction, mais les pointillés qui
matérialisaient leur durée de vie ont disparu.

Notation
 Les lignes de vie sont représentées par des rectangles contenant
une étiquette dont la syntaxe est :
<nomDuRôle> : <NomDuType>
 Au moins un des deux noms doit être mentionné dans l’étiquette (si
le nom du rôle est omis, le caractère : est obligatoire).

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

46
Rôles et connecteurs

 Le rôle permet de définir le contexte d’utilisation de l’interaction.

 Si la ligne de vie est un objet, celui-ci peut avoir au cours de sa vie


plusieurs rôles : une instance d’une classe Personne peut jouer le
rôle d’un étudiant dans un contexte donné, et devenir le conducteur
d’une voiture à un autre moment.

 Les relations entre les lignes de vie sont appelées « connecteurs »


dans les diagrammes de communication.

 Un connecteur se représente de la même façon qu’une association


mais la sémantique est plus large.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Types de messages

 Comme dans les diagrammes de séquence, on distingue deux types de


messages :

 Un message synchrone bloque l'expéditeur jusqu'à la réponse du


destinataire. Le flot de contrôle passe de l'émetteur au
récepteur.

 Un message asynchrone n'est pas bloquant pour l'expéditeur. Le


message envoyé peut être pris en compte par le récepteur à tout
moment ou ignoré.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

47
Types de messages

 Les flèches représentant les messages sont tracées à côté des


connecteurs qui les supportent.

Note
 Bien faire la distinction entre les messages et les connecteurs : on
pourrait avoir un connecteur sans message, mais jamais l'inverse.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Numéros de séquence des messages

 Dans un diagramme de communication, les messages peuvent être


ordonnés selon un numéro de séquence croissant.

 Des messages successifs sont ordonnés selon un numéro de séquence


croissant (1, 2, 3, ... ou encore 3.1, 3.2, 3.3, ...).

 Des messages envoyés en cascade (ex : appel de méthode à l'intérieur


d'une méthode) portent un numéro d'emboîtement avec une notation
pointée
 1.1, 1.2, ... pour des messages appelés par une méthode dont
l'appel portait le numéro 1
 2.a.1, 2.a.2, ... pour des messages appelés par une méthode
dont l'appel portait le numéro 2.a

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

48
Equivalence avec un diagramme de séquence

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Messages et flots d’exécution parallèles

 Il est possible d’envoyer des messages simultanément dans des flots


d’exécution qui se déroulent en parallèle.

 Les flots parallèles sont désignés par des lettres (a, b…).

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

49
Opérateurs de choix et de boucles

 Il n’est pas permis d’utiliser les fragments combinés dans un


diagramme de communication.
 Malgré tout, des choix et des boucles peuvent y figurer selon une
syntaxe particulière.
Notation
 * [ <clause d’itération> ] représente une itération.
 La clause d'itération peut être exprimée dans le format i:=1..n
 Si c'est une condition booléenne, celle-ci représente la condition d'arrêt.
 [ <clause de condition> ] représente un choix. La clause de condition
est une condition booléenne.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Syntaxe des messages


Notation
 La syntaxe complète des messages:

[ <numéro_séquence> ] [ <expression> ] : <message>

• le message a la même forme que dans les diagrammes de séquence,


• le numéro_séquence représente le numéro de séquencement des messages
tel qu’il a été défini précédemment,
• l’expression précise une itération ou un embranchement.

Exemple
 2 : affiche( x, y ) est un message simple.
 1.3.1 : trouve("Hadock" ) est un appel emboîté.
 4 [x < 0] : inverse( x, couleur ) est un message conditionnel.
 3.1 *[i :=1..10] : recommencer() représente une itération.
ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

50
Diagramme de Temps

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Présentation générale et concepts de base

 le diagramme de timing est utilisé pour la modélisation des systèmes


qui s’exécutent sous de fortes contraintes de temps, comme les
systèmes temps réel.

 Le diagramme de temps permet de représenter les états et les


interactions d’objets dans un contexte où le temps a une forte
influence sur le comportement du système à gérer.

 Autrement dit, le diagramme de temps permet de mieux représenter


des changements d’états et des interactions entre objets liés à des
contraintes de temps.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

51
Concepts manipulés

 Ligne de vie – Elle représente l’objet que l’on veut décrire. Elle se
dessine de manière horizontale. Plusieurs lignes de vie peuvent figurer
dans un diagramme de temps.

 État ou ligne de temps conditionnée – Les différents états que


peut prendre l’objet d’étude sont listés en colonne permettant ainsi de
suivre le comportement de l’objet ligne par ligne (une ligne pour un
état).

 États linéaires – Il s’agit du même concept que le précédent, mais la


représentation de la succession des états est faite de manière linéaire
à l’aide d’un graphisme particulier.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Diagramme de Temps

 la pompe à eau qui remplit la chambre de chauffe s’active


dès que le témoin d’eau interne le demande ;
 la pompe à eau se désactive dès que le niveau d’eau
nécessaire est atteint ;
 le chauffage de l’eau, permettant de produire la vapeur, se
met en action à la première mise en service du fer à repasser
dès que le niveau d’eau de la chambre de chauffe est
suffisant ;
 le chauffage initial de l’eau dure 3 mm permettant ainsi
de produire la vapeur.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

52
Exemple de diagramme de temps
avec représentation « en escalier »

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Exemple de diagramme de temps avec


représentation linéaire

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

53
Diagramme de Temps

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Diagramme de Temps

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

54
Diagramme de Temps

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Diagramme de Temps

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

55
Diagramme de Temps

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Diagramme de Temps

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

56
Diagramme de Temps

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Diagramme de Temps

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

57
Diagramme de Temps

Notation compact

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Diagramme de Temps

Plusieurs ligne de vie

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

58
Diagramme de Temps

Plusieurs ligne de vie

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Diagramme de Temps

Plusieurs ligne de vie

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

59
Diagramme de Temps

Plusieurs ligne de vie

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Diagramme de Temps

Plusieurs ligne de vie

TD && TP

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

60
Diagramme de structure
composite

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Introduction

 Le diagramme de structure composite a pour premier objectif de


décrire précisément un objet composé.

 Un tel diagramme n’a pas vocation à remplacer le diagramme des


classes mais à le compléter.

 Dans le diagramme de structure composite, l’objet composé est


décrit par un classificateur tandis que ses composants sont décrits
par des parties.

 Un classificateur et une partie associés à une classe, dont la


description complète est réalisée dans un diagramme de classes.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

61
Introduction

 Nous considérons maintenant l’objet composé décrit par le


diagramme des classes de la figure suivante.

Composé ComposantFort
n..m

1
composant

 Il possède un composant issu d’une composition forte et un autre issu


d’une agrégation.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Introduction
 La figure suivante montre le diagramme de structure composite.

Composé

:ComposantFort[n..m]

:Composant

 Les composants sont intégrés au sein du classificateur qui décrit l’objet


composé.
 Les parties possèdent un type qui est la classe du composant.
 La cardinalité est indiquée entre crochets. Par défaut, elle vaut un.
 Un composant issu d’une agrégation est représenté par une ligne en
pointillé,
 un composant issu d’une composition forte est représenté par une ligne
continue.
ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

62
Introduction

 La figure suivante montre le diagramme de structure composite.

Composé ComposantFort
Objet n..m

composé
1
composant

Composé
Diagramme
:ComposantFort[n..m]
de structure
composite :Composant
ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Exemple 1
 La figure suivante illustre un exemple de diagramme de diagramme de
structure composite décrivant une automobile en tant qu’objet composé.

Moteur Automobile Carrosserie


1 1

Diagramme
de classe
4
Roue

Automobile

Diagramme :Roue[4]
:Moteur
de structure
composite :Carrossrie

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

63
Exemple 1
 Dans le diagramme de structure composite, Moteur, Carrosserie et Roue ne
sont pas des classes mais des parties. Une partie est toujours prise en compte
au sein d’un classificateur.
Moteur Automobile Carrosserie
1 1

Diagramme
de classe
4
Roue

Automobile

Diagramme
:Moteur :Roue[4]
de structure
composite :Carrossrie

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Exemple 2
 Le diagramme de classes de la figure suivante illustre à nouveau une
automobile en tant qu’objet composé.
 Il introduit l’association liée entre les roues et les demi arbres qui assurent la
transmission entre le moteur et les roues avant, qui sont les roues motrices.

Carrosserie
1

Moteur Automobile 2 DemiArbre


1

0..1
4
Diagramme
liée
Roue
1
de classe
ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

64
Exemple 2
 La cardinalité de l’association liée est 0..1 à l’extrémité du demi
arbre.

 En effet, la cardinalité vaut un pour les roues avant et vaut zéro pour
les roues arrière.

 Cette dernière information ne peut pas être décrite dans le


diagramme de classes, à moins d’introduire deux sous-classes de
Roue : RoueAvant et RoueArrière.

 Cependant, introduire deux sous-classes pour préciser une cardinalité


présente l’inconvénient d’alourdir le diagramme des classes.

 Cette possibilité n’est pas souhaitable.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Exemple 2
 Dans le diagramme de structure composite, Moteur, Carrosserie et Roue ne
sont pas des classes mais des parties. Une partie est toujours prise en compte
au sein d’un classificateur.
Automobile

Diagramme :Moteur
de structure
composite :Carrosserie
avec rôles
et rouesArrière :Roue[2]
connecteurs
1 :liée 1 DemiArbreGauche: ArbreGauche
roueAvantGauche :Roue

1 :liée 1
roueAvantDroite :Roue DemiArbreDroite: ArbreDroite

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

65
Diagramme de paquetage

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Introduction

 La classe représente une entité de structuration trop petite dès lors


qu’on s’attaque à un projet réel.

 Au-delà d’une douzaine de classes, il est utile de regrouper les


classes fortement couplées en unités plus grandes.

 Le couplage s’exprime à la fois structurellement par des associations,


des agrégations, des compositions ou des généralisations, mais aussi
dynamiquement par les interactions qui se produisent entre les
instances des classes.

 Un package consiste en un regroupement logique de classes à forte


cohérence interne et faible couplage externe.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

66
Contenu d’un package

 Les packages organisent des éléments UML, tels que des classes, et le
contenu d'un package peut être dessiné dans le package ou à l'extérieur du
package attaché par une ligne, comme le montre la figure suivante.

Figure . Two ways to show that the Credentials and IdentityVerifier classes
are contained in the security package
 Si vous dessinez les éléments dans le package, écrivez le nom du
package dans l'onglet du dossier.
ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Contenu d’un package

 Les packages peuvent également contenir d'autres paquets, comme le


montre la figure suivante.

Figure . A package that contains another package

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

67
Contenu d’un package

 Il est fréquent de voir des packages profondément imbriqués dans les


applications.

Figure . Deeply nested packages are common in enterprise


applications: the search and indexing packages are shown in
a typical package structure for the ACME company
ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Contenu d’un package

 Il existe une notation alternative qui peut être plus facile à utiliser.

 En écrivant par exemple packageA :: packageB :: packageC, etc.


Ceci convertit la figure précédente en la Figure suivante de moins
encombrée.

Figure . Flattening nested packages

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

68
Visibilité des éléments

 Les éléments d'un package peuvent avoir une visibilité publique ou


privée.

 Les éléments avec visibilité publique sont accessibles en dehors du


package.

 Les éléments avec visibilité privée ne sont disponibles que pour les
éléments intérieur du package .

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Visibilité des éléments

 Vous pouvez modéliser la visibilité publique ou privée dans UML en


écrivant un symbole plus ou moins en face du nom de l'élément,
comme le montre la Figure suivante.

Figure . Since MD5Crypt has private visibility, it isn't


accessible outside the security package
ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

69
Dépendance de packages

 Lorsque une classe d’un package utilise une classe d’un autre
package, cela provoque une dépendance entre les packages.

 Si un élément du package A utilise un élément d’un package B, le


package A dépend du package B, comme le montre la figure suivante.

Figure . Package A dépend du package B


ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Importation et accès aux packages

 Dans une relation d'importation, le package importé est appelé


package cible.

 Pour afficher la relation d'importation, tracez une flèche de


dépendance à partir du package d'importation vers le package cible
avec le stéréotype import.

Figure . The package users imports security, so classes in users may use public
classes in security without having to specify the package name

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

70
Importation et accès aux packages

 Un package peut également importer un élément spécifique dans un


autre package au lieu du package entier, comme le montre la figure
suivante.

Figure . The users package imports only the Credentials element from the
security package

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Importation et accès aux packages

 Non seulement les éléments ont une visibilité, mais la relation


d'importation elle-même a une visibilité.

 Une importation peut être une importation publique ou privée avec le


public par défaut:

 Une importation publique signifie que les éléments importés ont


une visibilité publique dans l'espace de noms important;

 Une importation privée signifie que les éléments importés ont


une visibilité privée dans l'espace de noms important.

 Vous affichez une importation privée avec la stéréotypé access au


lieu de import.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

71
Importation et accès aux packages

 La différence entre l'importation et l'accès survient lorsqu'un package


importe un package qui importe ou accède aux autres.

 Les éléments importés ont une visibilité publique dans le package


d'importation, de sorte qu'ils se répercutent sur d'autres
importations, alors que les éléments accessibles ne le font pas.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Importation et accès aux packages

 Dans la figure suivante, le package B importe C et accède à D, donc B peut


voir des éléments publics en C et D.

 A importe B, donc A peut voir des éléments publics dans B.

 A peut également voir des éléments publics dans C car C est publiquement
Importé en B, mais A ne peut rien voir en D car D est importé en privé.

Figure . Package A can see public elements in C but not D


ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

72
Découpage en packages

 Le découpage doit se fonder sur deux principes


fondamentaux:

cohérence

indépendance.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Découpage en packages

 Le premier principe consiste à regrouper les classes sémantiquement


proches. Pour cela, il faut chercher la cohérence avec les critères
suivants :

 finalité : les classes doivent rendre des services de même nature


aux utilisateurs ;

 évolution : on isole ainsi les classes réellement stables de celles


qui vont vraisemblablement évoluer au cours du projet, ou même
par la suite. On distingue notamment les classes métier des
classes applicatives ;

 cycle de vie des objets : permet de distinguer, et donc de gérer


différemment, les classes dont les objets ont des durées de vie
très différentes.
ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

73
Découpage en packages

 Le deuxième principe consiste à renforcer ce découpage initial


en s’efforçant de minimiser les dépendances entre catégories.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

Packages et importation

 Notons que l’importation est une relation unidirectionnelle, qui offre


un accès aux éléments du package fournisseur pour les éléments du
package client.

 Donc, même si le package Missions importe le package Ressources, les


classes Chauffeur et Véhicule n’ont toujours pas accès à la classe
Mission.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

74
INFLUENCE DES RELATIONS ENTRE CLASSES SUR LES
DÉPENDANCES ENTRE PACKAGE

 Lors du découpage en packages, nous allons essayer de limiter au


minimum le nombre de relations qui traversent les catégories.

 En effet, dès qu’une généralisation entre classes sort d’un package,


une dépendance de même sens entre les packages parentes s’impose.

 Mais c’est encore pire pour les associations, puisque par défaut, elles
vont dans les deux sens, et imposent donc une importation mutuelle
des deux packages parentes.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

INFLUENCE DES RELATIONS ENTRE CLASSES SUR LES


DÉPENDANCES ENTRE PACKAGES

 Dans l’exemple ci-dessous, C1 dépend de C2, mais C2 ne dépend pas


de C1. En effet, si A spécialise B, et donc en dépend, la réciproque
n’est pas vraie.

 En revanche, C3 dépend de C4, et C4 dépend également de C3, car


l’association entre les classes C et D est bidirectionnelle.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

75
LES DÉPENDANCES ENTRE PACKAGES PEUVENT GUIDER LE
CHOIX DE NAVIGABILITÉ DES ASSOCIATIONS !

 Une association entre deux classes A et B permet par défaut de


naviguer dans les deux sens entre des objets de la classe A et des
objets de la classe B.

 Cependant, il peut être utile de limiter cette navigation à une seule


des deux directions.

 C’est le cas pour les associations qui sortent des catégories, sans
quoi, nous récupérons systématiquement une paire de dépendances.

 UML nous permet de représenter explicitement cette navigabilité en


ajoutant sur l’association une flèche indiquant le seul sens possible.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

LES DÉPENDANCES ENTRE PACKAGES PEUVENT GUIDER LE


CHOIX DE NAVIGABILITÉ DES ASSOCIATIONS !

 Plus généralement, les


dépendances souhaitées entre
catégories déterminent les
décisions relatives au sens des
relations entre classes.

 L’exemple suivant va illustrer


notre propos :

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

76
LES DÉPENDANCES ENTRE PACKAGES PEUVENT GUIDER LE
CHOIX DE NAVIGABILITÉ DES ASSOCIATIONS !

 le package Réseau a été isolée


précisément parce qu’elle
contient des classes hautement
réutilisables.

 Si l’on veut qu’elle ne dépende


pas des autres packages, les
classes Parcours et Commune ne
doivent en aucun cas avoir une
quelconque connaissance des
classes Connexion et
ZoneTerminale.

 En UML, cela se traduit par la


flèche de navigabilité sur les deux
associations qui vont du package
Plan de Transport au package
catégorie Réseau.

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

LES DÉPENDANCES ENTRE PACKAGES PEUVENT GUIDER LE


CHOIX DE NAVIGABILITÉ DES ASSOCIATIONS !

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

77
LES DÉPENDANCES ENTRE PACKAGES PEUVENT GUIDER LE
CHOIX DE NAVIGABILITÉ DES ASSOCIATIONS !

ENSA -4 G-INFO Module: UML2 Prof. A. Elyousfi (elyousfiabdo@yahoo.fr)

fin

78

Vous aimerez peut-être aussi