MCDC
Diagrammes de séquence
Ileana Ober
Université Paul Sabatier
IRIT
[Link]
Année Universitaire 2023-2024
©Ileana Ober
Une démarche
(classes métier)
+ diags activité
(processus métier)
Adapté de
"UML : modéliser un site e-commerce",
Pascal ROQUES, Eyrolles, 2002
Description de l’interaction
RetirerDeLArgent
AuDistributeur
Client
A travers des
diagrammes de séquences
système
©Ileana Ober
Les diagrammes séquence
sequence diagram
✤ But :
✤ détailler l’interaction entre plusieurs objets /acteurs
✤ donner des scénarios d’exécution signi catifs
✤ Mettent en évidence
✤ les lignes de vie des objets/acteurs
✤ les échanges de messages et leur ordre
✤ chronologie des messages échanges entre objets (et acteurs)
©Ileana Ober
fi
DS système / DS détaillé
✤ En fonction de l’étape à laquelle le diagramme est élaboré on a
✤ DS système spéci e les interactions entre le système (vu comme
un tout) et un (des) acteur(s) externe(s)
✤ DS détaillé spéci e aussi les interactions entre objets internes au
système
✤ Les deux détaillent un cas d’utilisation, mais à un grain différent
✤ La syntaxe du DS ne dépend pas de son type
©Ileana Ober
fi
fi
Plan
✤ Diagramme de séquence parmi les autres diagrammes UML
✤ Notions de base
✤ Utilisation
©Ileana Ober
Spécification de l’interaction
Diagramme séquence
©Ileana Ober
Spécification de l’interaction
Diagramme
collaboration
©Ileana Ober
Les deux diagrammes
d’interactions sont équivalentes
les
Euro outils de modélisation
Euro €
proposent souvent de
passer automatiquement
d’un à l’autre
€
€
©Ileana Ober
Plan
✤ Diagramme de séquence parmi les autres diagrammes UML
✤ Notions de base
✤ Utilisation
©Ileana Ober
Notions de base
acteur
objet
distributeurBalma: (instance
sg:Banque d’une classe)
Distributeur
jean : Acteur
retirer 20 € véri er
présence objet
argent
véri er solde
solde OK
débiter solde
con rmer débit
donner 20 €
©Ileana Ober
fi
fi
fi
Notions de base
distributeurBalma:
sg:Banque
Distributeur
jean : Acteur
retirer 20 € véri er lignes
présence de vie
argent
véri er solde
solde OK
débiter solde
con rmer débit
donner 20 €
©Ileana Ober
fi
fi
fi
Notions de base
distributeurBalma:
sg:Banque
Distributeur
jean : Acteur appel d’une
opération locale
retirer 20 € véri er
présence
argent
appel d’une
opération
véri er solde
solde OK
retour d’une
débiter solde opération
con rmer débit
donner 20 €
©Ileana Ober
fi
fi
fi
permet de mettre en
Ligne de vie évidence les périodes
d’activation
distributeurBalma:
sg:Banque
Distributeur
jean : Acteur
retirer 20 € véri er
présence
argent exécution
(objet activé)
véri er solde
solde OK
débiter solde
con rmer débit
donner 20 €
©Ileana Ober
fi
fi
fi
les acteurs étant
Ligne de vie externes sont
toujours inactifs
distributeurBalma:
sg:Banque
Distributeur
jean : Acteur objet crée mais
inactif
retirer 20 € véri er
présence
argent exécution
(objet activé)
véri er solde
solde OK
débiter solde
objet crée mais
con rmer débit
donner 20 € inactif
©Ileana Ober
fi
fi
fi
Ligne de vie
distributeurBalma:
sg:Banque
Distributeur
jean : Acteur
retirer 20 € véri er certains outils
présence
argent ne soignent pas
l’af chage des lignes
véri er solde de vie
solde OK
débiter solde
con rmer débit
donner 20 €
©Ileana Ober
fi
fi
fi
fi
après un message
asynchrone les 2 objets
Messages s’exécutent en parallèle
synchrone
distributeurBalma:
✤
sg:Banque
(type appel opération) Distributeur
jean : Acteur
✤ appelant bloqué jusqu’à retirer 20 € véri er
la réception du retour présence
argent
✤ asynchrone
véri er solde
(type envoi de message)
solde OK
✤ l’appelant peut
débiter solde
continuer son exécution
con rmer débit
✤ le retour n’est ni donner 20 €
immédiat, ni obligatoire
©Ileana Ober
fi
fi
fi
Messages - notation
distributeurBalma:
sg:Banque
Distributeur
✤ synchrone jean : Acteur
(type appel opération)
message synchrone retirer 20 €
véri er
èche pleine
✤ appelant bloqué
présence
argent
jusqu’à la réception
du retour véri er solde
retour - èche pointillée solde OK
✤ asynchrone
(type envoi de message) débiter solde
message asynchrone con rmer débit
✤ l’appelant peut
èche creuse
donner 20 €
continuer son
exécution
©Ileana Ober
fl
fl
fi
fi
fi
fl
Message réflexif
distributeurBalma:
sg:Banque
Distributeur
jean : Acteur
retirer 20 € véri er
présence
argent
✤ appel d’une opération
interne
véri er solde
✤ en principe peut être
synchrone ou
asynchrone
©Ileana Ober
fi
fi
Le temps dans le
diagramme de séquence
✤ Dans un diagramme de
séquence le temps
s’écoule de haut en bas
: Distributeur :Banque
✤ pour montrer qu’un jean : Acteur
échange de message véri er
prends du temps, la retirer 20 € présence
argent
èche de message peut
être oblique véri er solde
solde OK
débiter solde
donner 20 € con rmer
©Ileana Ober
fl
fi
fi
fi
Le temps dans le
diagramme de séquence
:A :B :C
Dans un diagramme
de séquence on voit
message1 uniquement l’ordres relatif
des messages
les messages 1 et 2
prennent du temps
message2 (arrivent quelques temps
le message 1 est après leur envoi)
envoyé avant le
message 2
©Ileana Ober
Exercice ?
:A :B :C Lequel des messages 1
et 2 arrive en premier?
message1
message2 On ne sait pas !!!
©Ileana Ober
Exercice ?
Est-ce que le
:A :B :C message 1 est arrivé
lorsque le message 2
part?
message1
message2 On ne sait pas !!!
©Ileana Ober
Contraintes temporelles
✤ Si on a besoin de :A :B :C
préciser qu’un
message arrive avant
un autre il faut le dire
explicitement message1
t1
t2
✤ On rajoute des
étiquettes temporelles
message2
{t2-t1>0} t3
✤ On peut mettre des
contraintes relatives
ou absolues t3 message3
{t2-t1<2s}
©Ileana Ober
Création / destruction objet
distributeurBalma:
sg:Banque creation d’objet
Distributeur
débiter solde
Session(noCompte)
:Session
le constructeur
de la classe peut nouvelle Session
apparaître débiter solde
ok
destruction d’objet
con rmer débit destroy
(peut être spontanée)
©Ileana Ober
fi
Alternative
✤ principe: condition à l’envoi d’un message
✤ deux diagrammes alternatives
on peut avoir plus:Utilisateur :Serveur
de 2 altérnatives ouvrir session
demande mdp
on peut mettre else mdp
comme guarde
véri er mdp
alt
acces refusé
[mdp pas bon]
create :Session
[mdp bon] acces accordé
©Ileana Ober
fi
Boucle
:Utilisateur :Serveur
condition de
boucle ouvrir session
loop demande mdp
mdp
[jusqu’à l’introduction
d’un bon mdp] véri er mdp
alt
acces refusé
[mdp pas bon]
create :Session
[mdp bon] acces accordé
©Ileana Ober
fi
Structuration
✤ En général un diagramme de séquence décrit un scénario
✤ Pour éviter les gros diagrammes qui nuisent la lisibilité ⇒ structurer
✤ Mécanismes de structuration
✤ alt fragment alternatif - condition dans les [gardes]
✤ loop fragment à répéter jusqu’à ce que la condition [garde] est vraie
✤ opt fragment optionnel - à exécuter si [garde] est vraie
✤ ref passage à un autre diagramme de séquence
©Ileana Ober
Plan
✤ Diagramme de séquence parmi les autres diagrammes UML
✤ Notions de base
✤ Utilisation
©Ileana Ober
Utilisation
✤ Description des scénarios signi catifs
(ex. réalisation d’un cas d’utilisation)
scénario typique, scénario d’erreur, scénario réputé complexe
✤ Utilisation en ultérieure en test (automatique ou manuel)
✤ Description de protocoles
✤ IHM - échanges d’informations utilisateur - application
✤ systèmes communicants - échanges de messages
✤ Description des échanges entre objets pour la réalisation d’une
tâche
©Ileana Ober
fi
Réalisation d’un cas d’utilisation
✤ Objets:
✤ Acteurs (extraits du cas d’utilisation)
✤ Dans le cas des DS système
le diagramme comporte uniquement 2 objets (acteur
+ :Système)
✤ Dans le cas des DS détaillé
le DS contient comme objets des instances des classes d’analyse
✤ Messages:
✤ échanges entre les objets identi és en haut, tels que spéci és par
le cas d’utilisation
✤ le niveau de détail dépend de si DS système ou détaillé
©Ileana Ober
fi
fi
Identification des classes d’analyse
à partir d’un cas d’utilisation
✤ Au moins une classe «boundary» par couple (acteur, cas
d’utilisation)
✤ Au moins une classe «control» par cas d’utilisation
✤ Les classes «entity» sont issues, en général, du modèle des classes
du domaine
©Ileana Ober
Modèle-Vue-Contrôleur
✤ Paradigme (patron, Modèle
architecture) permettant la 1
séparation entre les données 1
du programme (modèle) et la *
partie graphique af chant les
donnée Vue
✤ La vue correspond à la
présentation (IHM) *
✤ Le contrôleur assure la partie
logique Contrôleur
*
✤ S’utilise aussi en modélisation
©Ileana Ober
fi
Classes d’analyse
✤ <<entity>> (correspond à une donnée élémentaire)
objets métier manipulés NomEntityClass
en général persistants
✤ <<boundary>> (correspond à la vue ) - moyens
d’interaction avec le système NomBoundaryClass
écrans, formulaires de saisie (mais peut aller au delà
des IHM)
durée de vie du cas d’utilisation
✤ <<control>> (correspond au contrôle ) - logique NomControlClass
applicative
©Ileana Ober
Règles d’interaction
Acteur Boundary Control Entity
Acteur Non Oui non non
Boundary Oui rare oui non
Control Non oui oui oui
Entity Non non non oui
©Ileana Ober
Diagramme de séquence détaillé
:Acteur :NomBoundaryClass :NomControlClass :NomEntityClass
message1
message2
message3
retour3
message4
retour4
©Ileana Ober
DS système / DS détaillé
✤ En fonction de l’étape à laquelle le diagramme est élaboré on a
✤ DS système spéci e les interactions entre le système (vu comme
un tout) et un (des) acteur(s) externe(s)
✤ DS détaillé spéci e aussi les interactions entre objets internes au
système
✤ Les deux détaillent un cas d’utilisation, mais à un grain différent
✤ La syntaxe du DS ne dépend pas de son type
©Ileana Ober
fi
fi
Conclusion
✤ Diagramme utile en spéci cation et conception objet préliminaire
✤ Bonne vision des interactions
✤ Il faut adapter le niveau de détail
©Ileana Ober
fi