CENTRE D’INFORMATIQUE ET DE GESTION APPLIQUEE

CIGA

Cours UML

Licence Informatique

Année académique 2020/2021

Chapitres 4: Les diagrammes d’UML (Cas d’étude)

[Link]
 Généralité sur les diagrammes d’UML:
Etude de cas
❑Diagrammes d’UML
Les diagrammes d’UML constituent des faisceaux lumineux complémentaires sur les
situations à modéliser.

En effet, chaque diagramme à travers sa sémantique et sa représentation graphique permet

d’éclaircir, d’avoir une meilleur compréhension d’un aspect de la situation à modéliser.
Ainsi, le choix de mettre en œuvre l’un d’eux sera fonction des besoins d’une meilleure
compréhension de certains aspects. Il est rare que dans un processus de MOO tous les
diagrammes soient utilisés. Cependant, certains d’entre eux, comme on les verra plus tard
seront toujours là
 Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagrammes d’UML
Les diagrammes sont subdivisés en deux groupes:
▪ Le groupe des diagrammes statiques
▪ Le groupe des diagrammes dynamiques Diagramme de cas
d’utilisation
Diagramme de séquences

Diagramme d’objets
Diagramme de
collaboration
SYSTEME Diagramme de classes

Diagramme d’activités
Diagramme de
composants
Diagramme d’états
transition Diagramme de
déploiement
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagrammes d’UML
▪ Cas d’utilisation CU(Use Case)
• sémantique

Ce diagramme permet de structurer les besoins c’est-à-dire les attentes

des futurs utilisateurs du SI qu’on cherche à mettre en place. Cela passe
par l’identification de tous les futurs utilisateurs(les acteurs) ainsi que les
attentes de chacun d’entre eux(c’est-à-dire les CU qui leurs sont liés)
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagrammes d’UML
▪ Digramme de Cas d’utilisation: CU(Use Case)
représentation graphique
La représentation graphique d’un diagramme de CU contient des acteurs
nommés liés par des traits pleins à leurs attentes que sont les CU. Ces CU
sont plongés dans un rectangle représentant le système à modéliser. Il peut
contenir des relations entre CU (inclusion, extension, entre autre). La relation
peut être précisée dans sa nature
Exemple : Gestion inscription
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagrammes d’UML
▪ Diagramme de classes
• Sémantique
Le diagramme de classes est considéré comme le plus important de la MOO, il
est le seul obligatoire lors d’une telle modélisation. Alors que le diagramme de
cas d’utilisation montre un système du point de vue des acteurs, 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 est important de noter qu’un même objet peut très bien intervenir
dans la réalisation de plusieurs cas d’utilisation
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagrammes d’UML
▪ Diagramme de classes
• Sémantique
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 POO 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
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagrammes d’UML
Diagramme de classes
• Sémantique
Le diagramme de classes permet de structurer, de modéliser les données du
domaine à modéliser. En effet, les données d’un SI sont gérées à partir d’une BD
qui est l’aboutissement final de tout diagramme de classes. Sa mise en place
nécessite l’identification de toutes les entités encapsulant des données vitales du
domaine de modélisation, c’est-à-dire des classes, de leurs relations sous toutes
les formes (association, agrégation, composition, héritage, dépendance,…) ainsi
que les contraintes d’associations (contrainte de restriction exclusive,
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagrammes d’UML
▪ Diagramme de classes
• Représentation graphique
On représente graphiquement sous les bonnes formes (c’est-à-dire en UML) les
différents éléments de modélisation identifiés
Généralité sur les diagrammes d’UML: Etude de cas
❑Diagrammes d’UML
▪ Diagramme d’objets
Ces diagrammes sont des instances des diagrammes de classes à l’image des
objets qui sont des instances de classes. Ils permettent de confronter les
diagrammes de classes à la réalité qu’ils sont censée modéliser. On utilise donc
les diagrammes d’objet pour valider les diagrammes de classes. Les
diagrammes d’objet peuvent aussi servir dans la réflexion préalable à la mise
en place des classes puisqu’ils permettent de décrire des réalités concrètes
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagrammes d’UML
▪ Diagramme d’objets
Exemple : considérons le diagramme de classe précédant .

Représentons graphiquement le diagramme d’objet représentant au descriptif

suivant : « l’étudiant Babacar de la filiere web des TIC de l’UFR SATIC est en
Master1 en 2015/[Link] état de santé est bon puisqu’il n’a aucune maladie et
apte. Babacar a emprunté l’exemplaire E005 du livre de modélisation UML à la
date du 20/05/[Link] login est Babs et son mot de passe est carL1b
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme de séquences
▪ Diagramme de comportement dynamique
▪ Un diagrammes d’interaction entre les objets, il met en valeur les échanges de
messages dans le temps
▪ Il peut montrer:
• Les interactions entre acteurs métiers
• Les interactions entre acteurs du système et le système
• Les interactions entre objets d’analyse
• Les interactions entre objets logiciels’
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme de séquences
▪ Syntaxes avancée
Les cadres LOOP, ALT, REF, OPT
Auto-messages, messages récursifs
 Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme de séquences
▪ Syntaxes de bases:

• Objets, lignes de vie, focus de contrôle

• Messages de synchrones, asynchrones

• Messages de création de destruction

Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme de séquences
▪ Syntaxes avancée
• LOOP
Généralité sur les diagrammes d’UML: Etude de cas

❑ Diagramme de séquences
▪ Syntaxes avancée
• ALT
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme de séquences
▪ Sémantique
Un tel diagramme permet de représenter graphiquement le dynamisme d’un CU.
Autrement dit, on peut représenter avec un tel diagramme les interactions entre un
acteur et un système ou entre un acteur et les objets du système ou alors la
collaboration entre différents objets d’un système dans le cadre de l’exécution d’un
CU. Plus précisément, un diagramme de séquences permet de représenter un
scénario d’un CU.
Exemple scénario nominal du CU : « Retirer bourse »
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme d’activité
▪ Sémantique
• Les diagrammes d’activités permettent de mettre l’accent sur les
traitements.
• Ils sont donc particulièrement adaptés à la modélisation du cheminement
de flots de contrôle et de flots de données.
• Ils permettent ainsi de représenter graphiquement le comportement d’une
méthode ou le déroulement d’un cas d’utilisation.
• Les diagrammes d’activités sont relativement proches des diagrammes
d’états-transitions dans leur présentation, mais leur interprétation est
sensiblement différente.
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme d’activité
▪ Sémantique
• Les diagrammes d’états-transitions sont orientés vers des systèmes réactifs,
mais ils ne donnent pas une vision satisfaisante d’un traitement
faisant intervenir plusieurs classeurs et doivent être complétés, par exemple,
par des diagrammes de séquence.
• Au contraire, les diagrammes d’activités ne sont pas spécifiquement rattachés
à un classeur particulier. Ils permettent de spécifier des traitements a priori
séquentiels et offrent une vision très proche de celle des langages de
programmation impératifs comme C++ ou Java
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme d’activités
▪ Sémantique
• Dans la phase de conception, les diagrammes d’activités sont particulièrement
adaptés à la description des cas d’utilisation. Plus précisément, ils viennent
illustrer et consolider la description textuelle des cas d’utilisation.
• De plus, leur représentation sous forme d’organigrammes les rend facilement
intelligibles et beaucoup plus accessibles que les diagrammes d’états-
transitions.
• Les diagrammes d’activités sont également utiles dans la phase de réalisation
car ils permettent une description si précise des traitements qu’elle autorise la
génération automatique du code.
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme d’activités
▪ Concepts
o Action
• Une action est le plus petit traitement qui puisse être exprimé en UML. Une action a une
incidence sur l’état du système ou en extrait une information.
• Les actions sont des étapes discrètes à partir desquelles se construisent les comportements.
• La notion d’action est à rapprocher de la notion d’instruction élémentaire d’un langage de
programmation (comme C++ ou Java). Une action peut être, par exemple :
- une affectation de valeur à des attributs ;
- un accès à la valeur d’une propriété structurelle (attribut ou terminaison d’association) ;
- la création d’un nouvel objet ou lien ;
- un calcul arithmétique simple ;
- l’émission d’un signal ;
- la réception d’un signal
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme d’activités
▪ Concepts
o Activité (activity)
• 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.
• Une activité est un comportement (behavior en anglais) et à ce titre peut être
associée à des paramètres
 Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme d’activités
▪ Concepts
o Groupe d’activités (activity group)
Un groupe d’activités est une activité regroupant des nœuds et des arcs. Les
nœuds et les arcs peuvent appartenir à plus d’un groupe. Un diagramme
d’activités est lui-même un groupe d’activités
oTransition
Le passage d’une activité vers une autre est matérialisé par une transition.
Graphiquement les transitions sont représentées par des flèches en traits pleins
qui connectent les activités entre elle.
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme d’activités
▪ Concepts
oTransition (suite)
Elles sont déclenchées dès que l’activité source est terminée et provoquent
automatiquement et immédiatement le début de la prochaine activité à
déclencher (l’activité cible). Contrairement aux activités, les transitions sont
franchies de manière atomique, en principe sans durée perceptible. Les
transitions spécifient l’enchaînement des traitements et définissent le flot de
contrôle.
• Représentation
Etablir Livrer
commande commande
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme d’activités
▪ Concepts
o Nœud exécutable (executable node)
Un nœud exécutable est un nœud d’activité qu’on peut exécuter (une
activité). Il possède un gestionnaire d’exception qui peut capturer les
exceptions levées par le nœud, ou un de ses nœuds imbriqué
 Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme d’activités
▪ Concepts
oNœud d’action
Un nœud d’action est un nœud d’activité exécutable qui constitue l’unité
fondamentale de fonctionnalité exécutable dans une activité. L’exécution d’une
action représente une transformation ou un calcul quelconque dans le système
modélisé. Les actions sont généralement liées à des opérations qui sont
directement invoquées. Un nœud d’action doit avoir au moins un arc entrant.
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme d’activités
▪ Concepts
oNœud d’action
Graphiquement, un nœud d’action est représenté par un rectangle aux coins
arrondis qui contient sa description textuelle. Cette description textuelle peut
aller d’un simple nom à une suite d’actions réalisées par l’activité. UML
n’impose aucune syntaxe pour cette description textuelle, on peut donc
utiliser une syntaxe proche de celle d’un langage de programmation
particulier ou du pseudo-code.
• Représentation graphique
Saisir code
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme de séquences
▪ Concepts
oNœud de contrôle (control node)
Un nœud de contrôle est un nœud d’activité abstrait utilisé pour coordonner les flots
entre les nœuds d’une activité.
Il existe plusieurs types de nœuds de contrôle :
• nœud initial (initial node en anglais) ;
• nœud de fin d’activité (final node en anglais)
• nœud de fin de flot (flow final en anglais) ;
• nœud de décision (decision node en anglais) ;
• nœud de fusion (merge node en anglais) ;
• nœud de bifurcation (fork node en anglais) ;
• nœud d’union (join node en anglais).
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme de séquences
▪ Concepts
o Nœud initial
Un nœud initial est un nœud de contrôle à partir duquel le flot débute lorsque l’activité enveloppante est
invoquée. Une activité peut avoir plusieurs nœuds initiaux. Un nœud initial possède un arc sortant et pas
d’arc entrant.

Graphiquement, un nœud initial est représenté par un petit cercle plein

o Nœud final

Un nœud final est un nœud de contrôle possédant un ou plusieurs arcs entrants et aucun arc sortant.
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme de séquences
▪ Concepts
o Nœud de fin d’activité
Lorsque l’un des arcs d’un nœud de fin d’activité est activé (lorsqu’un flot
d’exécution atteint un nœud de fin d’activité), l’exécution de l’activité
enveloppante s’achève et tout nœud ou flot actif au sein de l’activité
enveloppante est abandonné. Si l’activité a été invoquée par un appel
synchrone, un message (reply) contenant les valeurs sortantes est transmis en
retour à l’appelant.
Graphiquement, un nœud de fin d’activité est représenté par un cercle vide
contenant un petit cercle plein
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme de séquences
▪ Concepts
o Nœud de fin de flot
Lorsqu’un flot d’exécution atteint un nœud de fin de flot, le flot en question
est terminé, mais cette fin de flot n’a aucune incidence sur les autres flots
actifs de l’activité enveloppante.
Graphiquement, un nœud de fin de flot est représenté par un cercle vide barré
d’un X. Les nœuds de fin de flot sont particuliers et à utiliser avec
parcimonie
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme de séquences
▪ Concepts
o Nœud de décision (decision node)
Un nœud de décision est un nœud de contrôle qui permet de faire un choix entre
plusieurs flots sortants.

Il possède un arc entrant et plusieurs arcs sortants. Ces derniers sont généralement
accompagnés de conditions de garde pour conditionner le choix. Si, quand le
nœud de décision est atteint, aucun arc en aval n’est franchissable (aucune
condition de garde n’est vraie), c’est que le modèle est mal formé.
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme de séquences
▪ Concepts
oNœud de décision (decision node)
L’utilisation d’une garde [else] est recommandée après un nœud de décision
car elle garantit un modèle bien formé. En effet, la condition de garde [else] est
validée si et seulement si toutes les autres gardes des transitions ayant la même
source sont fausses. Dans le cas où plusieurs arcs sont franchissables (plusieurs
conditions de garde sont vraies), seul l’un d’entre eux est retenu et ce choix est
non déterministe.
Graphiquement, on représente un nœud de décision par un losange
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme de séquences
▪ Concepts
o Nœud de fusion (merge node)
Un nœud de fusion est un nœud de contrôle qui rassemble plusieurs flots
alternatifs entrants en un seul flot sortant. Il n’est pas utilisé pour synchroniser
des flots concurrents (c’est le rôle du nœud d’union) mais pour accepter un
flot parmi plusieurs.
Graphiquement, on représente un nœud de fusion, comme un nœud de
décision, par un losange
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme d’activités
▪ Concepts
o Nœud de bifurcation ou de débranchement (fork node)
Un nœud de bifurcation, également appelé nœud de débranchement est
un nœud 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
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme d’activités
▪ Concepts
o Nœud d’union ou de jointure (join node)
Un nœud d’union, également appelé nœud de jointure est un nœud de contrôle
qui synchronise des
flots multiples. Un tel nœud possède donc plusieurs arcs entrants et un seul arc
sortant. Lorsque tous
les arcs entrants sont activés, l’arc sortant l’est également.
Graphiquement, on représente un nœud d’union, comme un nœud de
bifurcation, par un trait plein
Généralité sur les diagrammes d’UML: Etude de cas
▪ Exemple Diagramme activités
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme d’activités
▪ Concepts
o Les partitions
Les partitions, souvent appelées couloirs ou lignes d’eau (swimlane) du fait de
leur notation, permettent d’organiser les nœuds d’activités dans un diagramme
d’activités en opérant des regroupements
Les partitions n’ont pas de signification bien arrêtée, mais correspondent
souvent à des unités d’organisation du modèle.
On peut, par exemple, les utiliser pour spécifier la classe responsable de la
mise en œuvre d’un ensemble tâche. Dans ce cas, la classe en question est
responsable de l’implémentation du comportement des nœuds inclus dans
ladite partition
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme d’activités
▪ Concepts
o Les partitions
Graphiquement, les partitions sont délimitées par des lignes continues. Il
s’agit généralement de lignes verticales, mais elles peuvent être horizontales
ou même courbes.
Dans la version 2.0 d’UML, les partitions peuvent être bidimensionnelles,
elles prennent alors la forme d’un tableau. Dans le cas d’un diagramme
d’activités partitionné, les nœuds d’activités appartiennent forcément à une
et une seule partition. Les transitions peuvent, bien entendu, traverser les
frontières des partitions.
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme d’activités
▪ Concepts
o Les partitions
Les partitions d’activités étant des catégories arbitraires, on peut les représenter
par d’autre moyens quand une répartition géométrique s’avère difficile à
réaliser.
On peut ainsi utiliser des couleurs ou tout simplement étiqueter les nœuds
d’activité par le nom de leur partition d’appartenance.
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme d’état-transition
▪ Présentation
• 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).
• Ils spécifient habituellement le comportement d’une instance de classeur
(classe ou composant), mais parfois aussi le comportement interne d’autres
éléments tels que les cas d’utilisation, les sous-systèmes, les méthodes.
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme d’état-transition
▪ Présentation
• Le diagramme d’états-transitions est le seul diagramme, de la norme UML, à
offrir une vision complète et non ambiguë de l’ensemble des comportements de
l’élément auquel il est attaché. En effet, un diagramme d’interaction n’offre
qu’une vue partielle correspondant à un scénario sans spécifier comment les
différents scénarii interagissent entre eux
• La vision globale du système n’apparaît pas sur ce type de diagramme
puisqu’ils ne s’intéressent qu’à un seul élément du système indépendamment de
son environnement.
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme d’état-transition
▪ Sémantique
• Le diagramme d’état-transition permet d’identifier et de représenter
graphiquement les différents états d’un objet au cours de la vie de celui-ci
ou pendant une période de sa vie.
• Diagramme de comportement, dynamique
• Un état représente un temps dans la vie d’un objet
• Le diagramme d’état représente le cycle de vie d’un objet
• Très intéressant pour décrire les états possibles et les transitions autorisées
• Utilisé sur des objets dont le cycle de vie est significatif, ou dont les
réponses aux stimuli extérieur varient selon les états
Généralité sur les diagrammes d’UML: Etude de cas
❑Diagramme d’état-transition
▪ Sémantique
• Un diagramme d’états-transitions rassemble et organise les états et les
transitions d’un classeur donné.
• 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.
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme d’état-transition
▪ Concepts
• État dans un diagrammes d’états-transitions
un état, que l’on peut qualifier informellement d’élémentaire, se représente
graphiquement dans un diagrammes d’états-transitions par un rectangles aux
coins arrondis Certains états, dits composites peuvent contenir des sous états
Etat simple

Le nom de l’état peut être spécifié dans le rectangles et doit être unique dans
le diagrammes d’états transitions, ou dans l’état enveloppant. On peut
l’omettre, ce qui produit un état anonyme. Il peut y avoir un nombre
quelconque d’états anonymes distincts
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme d’état-transition
▪ Concepts
• État dans un diagrammes d’états-transitions
Un état peut être partitionné en plusieurs compartiments séparés par une ligne
horizontale. Le premier compartiment contient le nom de l’état et les autres
peuvent recevoir des transitions interne ou des sous-états
• 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.
Généralité sur les diagrammes d’UML: Etude de cas
❑Diagramme d’état-transition
▪ Concepts
• Etat final
L’état final est un pseudo état qui indique que le diagramme d’états-transitions, ou
l’état enveloppant, est terminé.

• Evénement
-Un événement est quelque chose qui se produit pendant l’exécution d’un système et
qui mérite d’être modélisé. Les diagrammes d’états-transitions permettent justement
de spécifier les réactions d’une partie du système à des événements discrets.
-Un événement se produit à un instant précis et est dépourvu de durée.
-Quand un événement est reçu, une transition peut être déclenchée et faire basculer
l’objet dans un nouvel état.
-On peut diviser les événements en plusieurs types explicites et implicites : signal,
appel, changement
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme d’état-transition
▪ Concepts
• Transition
Une transition définit la réponse d’un objet à l’occurrence d’un événement.
Elle lie, généralement, deux états E1 et E2 et indique qu’un objet dans un état
E1 peut entrer dans l’état E2 et exécuter certaines activités, si un événement
déclencheur se produit et que la condition de garde est vérifiée.

Allumer

pression pression

Eteindre
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme d’état-transition
▪ Concepts
• Condition de garde
Une transition peut avoir une condition de garde (spécifiée par ’[’ <garde> ’]’ dans la
syntaxe). Il s’agit d’une expression logique sur les attributs de l’objet, associé au
diagramme d’états-transitions, ainsi que sur les paramètres de l’événement
déclencheur. La condition de garde est évaluée uniquement lorsque l’événement
déclencheur se produit. Si l’expression est fausse à ce moment là, la transition ne se
déclenche pas, si elle est vraie, la transition se déclenche et ses effets se produisent.
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme de communication
▪ Présentation

• Diagramme de comportement dynamique

• Sert à montrer les interactions entre des objets. Les objets sont disposés dans l’espace, liés
par des liens, et les messages circulent sur ces liens

• Destiné aux interactions logicielles, il peut être utilisé au plus haut niveau

• Parfois utilisé dans l’analyse de besoins sous le nom de diagramme de contexte

dynamique

• il est souvent utilisé pour illustrer un cas d’utilisation ou pour décrire une opération
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme de composants
▪ Présentation

• Diagramme de structure, statique

• Le diagramme permet la représentation de parties de l’application qui sont

connectés les unes aux autres, sans pour autant parler de classes

• Utilisé pour éviter de parler de classes, ou de packages

• Utile lors des efforts de rétro-conception (besoin d’un système pour lequel il n’y
pas beaucoup d’information)
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme de composants
▪ Concepts
➢ Notion de composant
• Un composant doit fournir un service bien précis.

• Les fonctionnalités qu’il encapsule doivent être cohérentes entre elles et génériques (par opposition à spécialisées)
puisque sa vocation est d’être réutilisable.

• Un composant est une unité autonome représentée par un classeur structuré, stéréotypé «component»,
comportant une ou plusieurs interfaces requises ou offertes.

• Son comportement interne, généralement réalisé par un ensemble de classes, est totalement masqué :

• seules ses interfaces sont visibles.

• La seule contrainte pour pouvoir substituer un composant par un autre est de respecter les interfaces requises et
offertes.
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme de déploiement
▪ Présentation
• Diagramme de structure statique

• Il sert à décrire une architecture physique, les nœuds d’un réseau sur lequel sera
déployé l’application

• se rapprochent encore plus de la réalité physique, puisqu’ils identifient les

éléments matériels (PC, Modem, Station de travail, Serveur, etc.), leur disposition
physique (connexions) et la disposition des exécutables (représentés par
des composants) sur ces éléments matériels.
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme de déploiement
▪ Objectif du diagramme de déploiement
• Un diagramme de déploiement décrit la disposition physique des ressources matérielles
qui composent le système et montre la répartition des composants sur ces matériels.

• Chaque ressource étant matérialisée par un nœud, le diagramme de déploiement précise

comment les composants sont répartis sur les nœuds et quelles sont les connexions entre
les composants ou les nœuds.

• Les diagrammes de déploiement existent sous deux formes : spécification et instance.

Généralité sur les diagrammes d’UML: Etude de cas

❑ Diagramme de déploiement
▪ Représentation
• Nœud

Chaque ressource est matérialisée par un nœud représenté par un cube comportant
un nom. Un nœud est un classeur et peut posséder des attributs (quantité de
mémoire, vitesse du processeur,
Généralité sur les diagrammes d’UML: Etude de cas

❑ Diagramme de déploiement
▪ Représentation
• Notion d’artefact (artifact)

Un artefact correspond à un élément concret existant dans le monde réel

(document, exécutable, fichier, tables de bases de données, script, . . .).
Il se représente comme un classeur par un rectangle contenant le mot-clé
«artifact» suivi du nom de l’artefact
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme de déploiement
▪ Représentation
• Notion d’artefact (artifact)
L’implémentation des modèles (classes, . . .) se fait sous la forme de jeu
d’artefacts. On dit qu’un artefact peut manifester, c’est-à-dire résulter et
implémenter, un ensemble d’éléments de modèle. On appelle manifestation la
relation entre un élément de modèle et l’artefact qui l’implémente.
Graphiquement, une manifestation se représente par une relation de
dépendance stéréotypée «manifest»
Généralité sur les diagrammes d’UML: Etude de cas
❑ Diagramme de déploiement
▪ Usage
• Diagramme de structure, statique

• Un package regroupe n’importe quel type d’élément UML

• Très utile pour regrouper des classes

• On étudie préférentiellement les dépendances entre ces classes

• Permet d’avoir une vue de haut niveau sur l’architecture de

l’application