Université Cadi Ayyad Marrakech

EST Essaouira
DUT GI & IDSD Semestre 3
Module
Génie logiciel
Chapitre II
Modélisation par langage UML
 Diagramme des cas d’utilisation
 Diagramme des séquences

Pr: A. Guezzaz
Département Génie Informatique et Mathématiques (GIM)
Année scolaire: 2020-2021
1. Introduction
 Un diagramme représente l’ensemble des vues sur une expression
de besoins ou sur une solution technique.
 Dans les activités de spécification, il convient de considérer le
système comme une boîte noire à part entière afin d’étudier sa
place dans le système métier plus global.
 Un objet peut représenter l’abstraction d’une entité métier
utilisée en analyse, puis d’un composant de solution logicielle en
conception.
 Aujourd’hui, le standard industriel de modélisation objet est
UML.
 Il est sous la responsabilité de l’OMG. 2
1. Introduction

 Les diagrammes de séquences servent d’abord à développer en

analyse les scénarios d’utilisation du système.
 Le diagramme d’états représente le cycle de vie commun aux
objets d’une même classe.
 Ce diagramme complète la connaissance des classes en analyse et en
conception en montrant les différents états et transitions possibles
des objets d’une classe à l’exécution.
 Le diagramme d’activités représente les règles d’enchaînement des
actions et décisions au sein d’une activité.

4
2. Diagramme des cas d’utilisation
 C’est le premier diagramme de la modélisation UML où s’assure
la relation entre l’utilisateur et les objets que le système met en
œuvre.

 Il montre les interactions fonctionnelles entre les acteurs et le

système à l’étude.

 Visualiser l'interaction du système avec le monde extérieur.

 Modéliser les processus métiers et l'organisation de l'entreprise.

 Il est basée sur des acteurs qui interagissent avec le système de

l’extérieur ou de l’intérieur.

5
2. Diagramme des cas d’utilisation

 Diagramme de cas d’utilisation

 Acteurs.
 Cas d'utilisation (use case).
 Système.

 Relations dans les diagrammes de cas d’utilisation

 Relations entre acteurs.
 Relations entre cas d’utilisation.
 Relation entre acteurs et cas d’utilisations.

6
2. Diagramme des cas d’utilisation
 Acteurs
 Un acteur représente un rôle joué par une entité externe qui
interagit directement avec le système étudié.

 Un acteur peut consulter et/ou modifier directement l’état du

système, en émettant et/ou en recevant des messages susceptibles
d’être porteurs de données.

 Les acteurs candidats sont systématiquement :

Utilisateurs humains directs: identifier tous les profils
possibles sans oublier l’administrateur, l’opérateur de
maintenance, etc.
Dispositif matériel
 Autres systèmes connexes qui interagissent aussi
directement avec le système étudié. 7
2. Diagramme des cas d’utilisation
 Acteurs
 La représentation graphique standard de l’acteur en
UML est l’icône appelée stick man, avec le nom de
l’acteur sous le dessin.
 On peut également figurer un acteur sous la forme
rectangulaire d’une classe, avec le mot-clé <<actor>>.

 Une bonne recommandation consiste à utiliser la

forme graphique du stick man pour les acteurs
humains et la représentation rectangulaire pour
les systèmes connectés.
8
2. Diagramme des cas d’utilisation
 Types d’acteurs

 Acteurs principaux: personnes qui utilisent les fonctions du

système.

 Acteurs secondaires: personnes qui effectuent des tâches

administratives ou de maintenance.

 Matériels extérieurs sauf la machine où se trouve l'application.

 Autres systèmes.

9
2. Diagramme des cas d’utilisation
 Relation entre acteurs
 La seule relation possible entre deux acteurs est la généralisation:
un acteur X est une généralisation d’un acteur Y si l’acteur X peut
être substitué par l’acteur Y.

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

 Dans ce cas, tous les cas d’utilisation accessibles à X le sont aussi

à Y, mais l’inverse n’est pas vrai.
10
2. Diagramme des cas d’utilisation
 Cas d’utilisation
 Un cas d'utilisations (use case) est un ensemble des séquences
d'actions menées par le système qui doit donner un résultat
observable pour un acteur.

 Le cas d’utilisation est nommé par un verbe à l’infinitif suivi d’un

complément, du point de vue de l’acteur et non pas du point de
vue du système.

 Un cas d’utilisation se représente par une ellipse

contenant l’intitulé du cas d’utilisation

11
2. Diagramme des cas d’utilisation
 Cas d’utilisation

 Si on désire présenter les attributs ou les

opérations du cas d’utilisation, il est préférable de
le représenter sous la forme d’un classeur
stéréotypé << use case >>.

 Un cas d’utilisation doit être relié à au moins un acteur.

 Une association est une relation entre éléments UML (classes, cas
d’utilisation, etc.) qui décrit un ensemble de liens.
 Elle est utilisée pour relier les acteurs et les cas d’utilisation par
une relation qui signifie simplement: «participe à».
12
2. Diagramme des cas d’utilisation
 Système
 Un système représente une application dans UML.

 Il est identifié par un nom et regroupe un ensemble de cas

d’utilisation qui correspondent aux fonctionnalités offertes par
l’application à son environnement.

 L’environnement est spécifié sous forme d’acteurs liés aux cas

d’utilisation.

 Un système se représente par un rectangle contenant le nom du

système et les cas d’utilisation de l’application.

13
2. Diagramme des cas d’utilisation
 Système
 Pratiquement, c’est est préférable de figurer les acteurs
principaux à gauche des cas d’utilisation et les acteurs
secondaires à droite.

14
2. Diagramme des cas d’utilisation
 Multiplicité

 Lorsqu’un acteur peut interagir plusieur 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,

Le symbole 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.

15
2. Diagramme des cas d’utilisation
 Multiplicité
 La notion de multiplicité n’est pas propre au diagramme de cas
d’utilisation.

 Il est utilisé aussi dans le diagramme de classes.

16
2. Diagramme des cas d’utilisation
 Relations entre cas d’utilisation
 Il existe principalement deux types de relations:

Généralisation /Spécialisation.

Dépendances stéréotypées, qui sont explicitées par un

stéréotype (l’inclusion et l’extension).

 La dépendance se représente par une flèche avec un trait pointillé.

Si le cas X inclut ou étend le cas Y, la flèche est dirigée

de X vers Y.

 La généralisation est représentée par une flèche avec un trait pleins

dont la pointe est un triangle fermé désignant le cas le plus général.
17
2. Diagramme des cas d’utilisation
 Relation de la généralisation
 Un cas A est une généralisation d’un cas B si B est un cas particulier
de A.

 Exemple: 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.

 une bonne pratique consiste à identifier un seul acteur principal par

cas d’utilisation.
18
2. Diagramme des cas d’utilisation
 Relation de l’inclusion
 Les inclusions permettent de factoriser une partie de la description
d’un cas d’utilisation qui serait commune à d’autres cas
d’utilisation.

 Les inclusions permettent également de décomposer un cas

complexe en sous cas plus simples.

 Il faut éviter de réaliser du découpage fonctionnel d’un cas

d’utilisation en plusieurs sous cas d’utilisation pour ne pas retomber
dans le fonctionnel.

19
2. Diagramme des cas d’utilisation
 Relations entre cas d’utilisation
 Un cas A inclut un cas B si le comportement décrit par le cas A
inclut le comportement du cas B : le cas A dépend de B.

 Lorsque A est sollicité, B l’est obligatoirement, comme partie de A.

 Cette dépendance est symbolisée par le stéréotype <<include>>.

20
2. Diagramme des cas d’utilisation
 Relation de l’extension

 On dit qu’un cas d’utilisation A étend un cas d’utilisation B lorsque

le cas d’utilisation A peut être appelé au cours de l’exécution du
cas d’utilisation B.

 Exécuter B peut éventuellement entraîner l’exécution de A:

contrairement à l’inclusion, l’extension est optionnelle.

 Cette dépendance est symbolisée par le stéréotype << extend >>

21
2. Diagramme des cas d’utilisation
 Relation de l’extension

 L’extension peut intervenir à un point précis du cas étendu. Ce

point s’appelle le point d’extension.

 Une extension est souvent soumise à une condition.

 Graphiquement, la condition est exprimée sous la forme d’une

note.

 Exemple: Dans une banque, la vérification du solde du compte

n’intervient que si la demande de retrait dépasse 20 euros.

22
2. Diagramme des cas d’utilisation

23
3. Description textuelle d’un cas d’utilisation
 À chaque cas d’utilisation doit être associée une description
textuelle des interactions entre l’acteur et le système et les actions
que le système doit réaliser en vue de produire les résultats attendus
par les acteurs.

 La description textuelle est articulée en six points:

1. Objectif: Décrire le contexte et les résultats attendus du cas

d’utilisation.

2. Acteurs concernés: les acteurs concernés par le cas doivent

être identifiés en précisant globalement leur rôle.

3. Pré-conditions: Si certaines conditions sont requises avant

24
l’exécution du cas, elles sont à exprimer à ce niveau
3. Description textuelle d’un cas d’utilisation
5. Scénario nominal: Il s’agit là du scénario principal qui doit se
dérouler sans incident et qui permet d’aboutir au résultat
souhaité.

6. Scénarios alternatifs: Les autres scénarios, secondaires ou

correspondant à la résolution d’anomalies, sont à décrire à ce
niveau. Le lien avec le scénario principal se fait à l’aide d’une
numérotation rappelant le numéro de l’action concernée.

7. Post-conditions: si certaines conditions particulières doivent

être réunies après l’exécution du cas, elles sont à exprimer à ce
niveau.
25
4. Diagramme de séquences
1. Le diagramme de séquence (SD) représente les interactions entre
objets en indiquant la chronologie des échanges.
2. Cette représentation peut se réaliser par cas d’utilisation en
considérant les différents scénarios associés.
3. Un SD se représente globalement dans un grand rectangle avec
indication du nom du diagramme en haut à gauche.

26
4. Diagramme de séquences
 Une ligne de vie représente l’ensemble des opérations exécutées par
un objet.
 Un message reçu par un objet déclenche l’exécution d’une
opération. Le retour d’information peut être implicite ou explicite à
l’aide d’un message de retour.
 Un message synchrone:
 L’émetteur attend la réponse de son message avant de poursuivre
ses actions. Il est symbolisé par flèche avec extrémité pleine.
 Le message de retour peut ne pas être représenté car il est inclus
dans la fin d’exécution de l’opération de l’objet destinataire du
message. 27
4. Diagramme de séquences
 Un message asynchrone:
 L’émetteur n’attend pas la réponse à son message.
 Il poursuit l’exécution de ses opérations. Il est symbolisé par
une flèche avec une extrémité non pleine.

28
4. Diagramme de séquences
 Contrainte temporelle
 Des contraintes de chronologie entre les
messages peuvent être spécifiées.
 De plus lorsque l’émission d’un message
requiert une certaine durée, il se
représente sous la forme d’un trait
oblique.

 Lorsque le SD est utilisé pour représenter un sous ensemble du

logiciel à réaliser, il est possible d’indiquer le pseudo code exécuté
par un objet pendant le déroulement d’une opération
29
4. Diagramme de séquences
 Fragment d’interaction
 Dans un SD, il est possible de distinguer des sous ensembles
d’interactions qui constituent des fragments.
 Un fragment d’interaction se représente globalement comme un
SD dans un rectangle avec indication dans le coin à gauche du
nom du fragment.
 Un port d’entrée et un port de sortie peuvent être indiqués pour
connaître la manière dont ce fragment peut être relié au reste du
diagramme.
 Dans le cas où aucun port n’est indiqué, c’est l’ensemble du
fragment qui est appelé pour exécution.
30
4. Diagramme de séquences
 Fragment d’interaction combiné

 Il correspond à un ensemble d’interaction auquel on applique un

opérateur. Il se représente globalement comme un SD avec
indication dans le coin à gauche du nom de l’opérateur.

 Opérateurs UML:

ref , alt, opt, loop, par, assert,…

31
4. Diagramme de séquences
 Opérateur ref (reference)

 Il permet d’appeler une séquence d’interactions décrite par ailleurs

constituant ainsi une sorte de sous diagramme de séquence.

32
4. Diagramme de séquences
 Opérateur alt (alternative)

 Il correspond à une instruction de test avec une ou plusieurs

alternatives possibles. Il est aussi permis d’utiliser les clauses de
type sinon.

33
4. Diagramme de séquences
 Opérateur opt (optional)

 Il correspond à une instruction de test sans alternative (sinon).

34
4. Diagramme de séquences
 Opérateur loop

 Il correspond à une instruction de boucle qui permet d’exécuter

une séquence d’interactions tant qu’une condition est satisfaite.

35
4. Diagramme de séquences
 Opérateur par (parallel)

 Il permet de représenter deux séries d’interactions qui se déroulent

en parallèle.

36
4. Diagramme de séquences
 Opérateur assert (assertion)

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

37
4. Diagramme de séquences
 Le diagramme de séquence peut être aussi utilisé pour documenter
un cas d’utilisation.
 Les interactions entre objets représentent, dans ce cas, des flux
d’informations échangés et non pas de véritables messages entre
les opérations des objets.

38
4. Diagramme de séquences
 Exercice
 Le guichetier ouvre une session.
 Le guichetier saisit le numéro de
compte du client.
 Le système guichet valide le compte
auprès du système central.

 Le système guichet demande le type d’opération au guichetier

 Le guichetier sélectionne le montant du retrait
 Le système guichet interroge le système central pour s’assurer que le
compte est suffisamment approvisionné
 Le système guichet demande au système central de débiter le compte.
 Le système notifie au guichetier qu’il peut délivrer le montant demandé.
fin
40