Julie Vachon, Hiver 2006
IFT2251 : Génie logiciel
Chapitre 4. Analyse orientée objets Section 6. Diagramme de séquence
Chap.4, Sect.6, p.2 Copyrights Julie Vachon, 2006
Diagramme de séquence
1.
Introduction
2.
Caractéristiques
3.
Modes d’interaction
1.
Mode procédural
2.Mode asynchrone
4.Types de messages
5.
Notation utilisée
1.
Création et destruction d’objet
2.Contraintes temporelles
3.Messages avec garde
4.Ligne de vie à branches multiples
5.Itérations
6.
Interactions concurrentes
Chap.4, Sect.6, p.3 Copyrights Julie Vachon, 2006
4.6.1. Introduction
On souhaite décrire les cas d’utilisation de façon à mettre en évidence les interactions entre les instances des classes (objets) du logiciel
Un cas d’utilisation est réalisé par une collaboration
Collaboration = Ensemble d’objets qui s’échangent des messages et travaillent ensemble et pour accomplir une tâche.
Interaction = Échange d’un message entre deux objets du logiciel.
Chap.4, Sect.6, p.4 Copyrights Julie Vachon, 2006
Introduction
UML propose deux type de diagrammes d’interaction
Diagramme de séquence (interactions projetées sur une ligne de temps)
Diagramme de collaboration (interactions projetées sur un diagramme d’objets)
Pour décrire les scénarios des cas d’utilisation on privilégiera
Analyse : diagrammes de séquence ou d’activités.
Conception : diagrammes de collaboration ou de séquence
(parfois des diagrammes d’activité)
Chap.4, Sect.6, p.5 Copyrights Julie Vachon, 2006
4.6.2. Caractéristiques
Diagramme de séquence
Montre la séquence dans le temps des interactions entre les objets participant à un scénario.
Un diagramme de séquence a deux dimensions
Dimension verticale : le temps
L'ordre d'envoi d'un message est déterminé par sa position sur l'axe vertical du diagramme ; le temps s'écoule « de haut en bas »
Dimension horizontale : les objets (et les acteurs)
L’ordre de disposition des objets sur l'axe horizontal est sans importance
:c1 :c5 :c3 objets
temps
Chap.4, Sect.6, p.6 Copyrights Julie Vachon, 2006
Caractéristiques
Éléments (graphiques) de base
Les objets qui interagissent dans le scénario
Représentation graphique de la ligne de vie de chaque objet et de ses activations
Les différents types de messages envoyés (simple, synchrone, asynchrone)
Les indications de contrôle (branchement conditionnel et itération, création et destruction d’objets, délais de transmission, contraintes temporelles)
:c1 :c5 :c3 objets
temps
4.6.3. Modes d’interaction
Mode d’interaction procédural
unMembre :EmprunteurDeLivre
mb
:MembreBiblio exemplaire
:Exemplaire leLivre:Livre
1. emprunter (exemplaire)
1.1. okPourEmprunter()
1.2. emprunter(mb)
1.2.1. estEmprunté(self)
activation
message ligne
de vie message
récursif
Modes d’interaction
Mode d’interaction procédural
Au plus un objet détient le contrôle à la fois
Un objet obtient le contrôle quand il reçoit un message (une de ses méthodes est invoquées), ce moment détermine le début de son activation
Un objet rend le contrôle à son destinateur lorsqu’il lui renvoie sa réponse, ce moment détermine la fin de son activation
Lorsqu’un objet en activation a le contrôle, il peut
Faire des calculs
Envoyer des messages : dans ce cas, l’objet demeure en activation mais cède à son tour le contrôle à son destinataire, il ne peut rien faire jusqu’à ce qu’il reçoive la réponse de son destinataire (message d’invocation synchrone, aussi dit « bloquant »)
Chap.4, Sect.6, p.9 Copyrights Julie Vachon, 2006
Modes d’interaction
Mode d’interaction procédural
Sur un diagramme de séquence, la période d’activationd’un objet est représentée par une bande rectangulaire superposée à sa ligne de vie
Dans le cas des messages récursifs, on dédouble la bande d’activation de l’objet concerné
L’identité des objets en activation est gérée dans une pile Dessus de la pile = Objet en activation qui possède le contrôle On empile l’identité d’un objet qui débute une activation On dépile l’identité d’un objet qui termine une activation
Les messages sont numérotés de façon à refléter l’imbrication des envois de messages.
Le message 2.2. est envoyé après que la réponse au message 2.1 ait été reçue Il faut attendre la réponse au message 2.2.3. avant de pouvoir répondre au
message 2.2.
O_contrôle O_contrôle
Chap.4, Sect.6, p.10 Copyrights Julie Vachon, 2006
Modes d’interaction
Mode d’interaction procédural
Les objets sont dits « passifs », car on doit leur envoyer un message pour déclencher leur activation
Un seul fil d’exécution
Dans ce mode, seul un acteur peut envoyer un message ou faire des calculs sans l’intervention de qui que ce soit
Son activation est constante…
Chap.4, Sect.6, p.11 Copyrights Julie Vachon, 2006
Mode d’interaction
Mode d’interaction concurrent (asynchrone)
appelant centrale
téléphonique appelé
1. décrocher()
2: envoyerSignal()
3: composerNuméro()
4: chercherDestinataire()
5B: activerSonnerie() 5A: entendreSonnerie()
6. décrocher() 7B: arrêterSonnerie() 7A: arrêterSignalSonnerie()
Chap.4, Sect.6, p.12 Copyrights Julie Vachon, 2006
Diagramme de séquence
Mode d’interaction concurrent
Certains objets disposent d’un propre fil d’exécution
Il ont leur propre contrôle et leur activation est constante
Ces objets sont dits « actifs », car il peuvent faire des calculs et
envoyer des messages sans l’intervention de qui que ce soit
Les objets actifs envoient deux types de messages
Synchrones : ils attendent la réponse de leur destinataire avant de poursuivre
Asynchrones : ils poursuivent leurs activités sans attendre la réponse à leur message, celle-ci leur sera signalée
En mode procédural, tous les messages sont synchrones.
Chap.4, Sect.6, p.13 Copyrights Julie Vachon, 2006
4.6.4. Types de messages
Message synchrone
Suite à l’envoi de son message, l’expéditeur (objet passif ou actif) perd le contrôle mais demeure en activation
Il demeure bloqué jusqu’à ce que le destinataire ait fini de traiter le message Il retrouve ensuite le contrôle avec la réponse à son message (pouvant être
représenté par une flèche pointillée)
Message simpleou asynchrone
Dans tous les cas, l’expéditeur envoie un message au destinataire sans attendre de réponse
Si l’expéditeur est un objet passif (rare): l’envoi du message équivaut à l’envoi d’un message simple (non synchrone), i.e., l’expéditeur perd le contrôle et termine son activation après l’envoi du message
Si l’expéditeur est un objet actif : cet envoi de message équivaut à l’envoi d’un message asynchrone, suite à l’envoi de son message, l’expéditeur demeure en activation et conserve son flot de contrôle, son exécution n’est pas interrompue, le message envoyé peut être pris en compte par le récepteur à tout moment ou ignoré (jamais traité), une réponse n’est pas nécessairement attendue
Chap.4, Sect.6, p.14 Copyrights Julie Vachon, 2006
Types de messages
Note
UML1.4 deprecates the half-arrow because the old distinction between flat and asynchronous messages was "subtle and confusing".
4.6.5. Notation utilisée
Création et destruction d’instance
Création : lorsqu’une instance est créée, on place la boîte qui la représente légèrement en bas, à l’endroit où elle est créée
Destruction : la destruction d’une instance est représentée par
un X à la fin de sa ligne de vie, là où elle se termine
Si l’instance est détruite par une autre instance (non par elle- même), un message issu de l’instance destructrice pointe sur le X
c1:ClasseA
c2:ClasseB 1. new ClasseB(n)
2. détruire()
×
Notation utilisée
Contraintes temporelles
On peut spécifier le temps et des contraintes temporelles
Les intervalles sur la ligne de vie des objets indiquent des intervalles de temps
On peut attribuer une étiquette au moment d’émission et de réception d’un messages et spécifier des contraintes sur ces étiquettes
L’envoi d’un message est généralement considéré
comme instantané, pour marquer une durée significative,
on incline la flèche du message vers le bas (au lieu de la
laisser horizontale)
Chap.4, Sect.6, p.17 Copyrights Julie Vachon, 2006
Notation utilisée
Contraintes temporelles
mb :MembreBiblio
exemplaire
:Exemplaire leLivre:Livre unMembre
:EmprunteurDeLivre
1. emprunter(exemplaire) 1.1. okPourEmprunter()
1.2. emprunter(mb)
1.2.1. estEmprunté(self)
C A
B
{B’ – B < 3ms} B’
{C – A< 8ms}
Chap.4, Sect.6, p.18 Copyrights Julie Vachon, 2006
Notation utilisée
Contraintes temporelles
{b-a < 1 sec.}
{c-b < 10 sec.}
{e-d < 5 sec.}
appelant centrale
téléphonique appelé
1. décrocher()
2. envoyer_signal()
3. composer_numéro()
4. chercher_destinataire()
5B. activer_sonnerie() 5A. entendre_sonnerie()
6. décrocher() 7B. arrêter_sonnerie() 7A. arrêter_signal_sonnerie()
a b c d e
Chap.4, Sect.6, p.19 Copyrights Julie Vachon, 2006
Notation utilisée
Notation utilisée pour exprimer les interactions de plusieurs scénarios
Si cela convient, on peut vouloir décrire les différents scénarios d’un cas d’utilisation sur un même diagramme de séquence
Conditions (gardes) sur les messages
Ligne de vie à branches multiples
Itérations
Interactions concurrentes
Chap.4, Sect.6, p.20 Copyrights Julie Vachon, 2006
Notation utilisée
Messages avec garde
Permet d’exprimer les alternatives de comportement
Message envoyé seulement si la garde est vraie
Les gardes doivent être mutuellement exclusives pour signifier que l’envoi est conditionnel (et non concurrent)
o:Obj
[i=0] 1: foo() [i=1] 1: bar()
o:Obj
[i=0] 1.1: foo() [i=1] 1.2: bar()
Différence ?
Chap.4, Sect.6, p.21 Copyrights Julie Vachon, 2006
Notation utilisée
Ligne de vie à branches multiples
Si deux messages, dont l’envoi est conditionnel à l’évaluation d’une garde, sont destinés à un même objet, on doit pouvoir exprimer le comportement de l’objet dans chaque cas
o1:Obj1
[i=0] 3.1: foo() [i=1] 3.1: bar()
o2:Obj2
Chap.4, Sect.6, p.22 Copyrights Julie Vachon, 2006
Notation utilisée
Itération
On ajoute une clause d’itération (introduite par un ∗) à côté du message pour spécifier le nombre d’itérations ou l’invariant de l’itération
∗[i:=1..10] m()
Le message est envoyé 10 fois ∗[x<10] m()
Le message est envoyé de façon répétée jusqu’à ce que xsoit plus grand ou égal à 10
∗[item not found] m()
Le message est envoyée de façon répétée jusqu’à ce que l’item soit trouvé
Ne pas répéter la clause d’itération chez le destinataire (elle est implicite) à moins de vouloir une boucle imbriquée
Notation utilisée
Itération
a:ObjA
3.1. ∗[i:=1..2] a()
3.1.1. b()
b:ObjB c:ObjC
Notation utilisée
Interactions concurrentes
Il existe différente façon de créer de nouveaux fils de contrôle (threads)
1.
À la réception d’un message, un objet peut découpler le fil d’exécution en envoyant plusieurs messages simultanément (fork)
o:Obj
1.a. foo() 1.b. bar()
Branchement : lorsque les messages n’ont pas de
garde mutuellement exclusive, ils sont
concurrents
Chap.4, Sect.6, p.25 Copyrights Julie Vachon, 2006
Notation utilisée
Interactions concurrentes
2.
Un acteur peut spontanément décider d’envoyer un message et crée ainsi un nouveau fil d’exécution.
3.
Un objet actif peut également découpler le fil d’exécution en envoyant un message asynchrone.
L’instance continue sans attendre le message de retour
Elle octroie ainsi un fil d’exécution indépendant à l’objet
destinataire
o1:Obj
1: foo() 2:bar()o2:Obj
Chap.4, Sect.6, p.26 Copyrights Julie Vachon, 2006
Parmi les objectifs d’apprentissage
Expliquer le rôle des diagrammes de séquence dans une modélisation orientée objet
Lire et interpréter un diagramme de séquence
Identifier, comprendre et savoir distinguer les notions de flot de contrôle et d’activation
Expliquer l’exécution d’un programme en mode procédural, décrire les caractéristiques du mode procédural
Expliquer l’exécution d’un programme en mode concurrent, décrire les caractéristiques du mode concurrent
Comprendre la numérotation des messages dans un diagramme, numérotez convenablement les message d’un diagramme de séquence en tenant compte du mode d’exécution considéré
Comparer les différents types de message (synchrone, asynchrone, simple et retour), justifier l’utilisation de chacun dans un diagramme de séquence
Savoir écrire et interpréter des contraintes temporelles
Savoir interpréter et utiliser des messages avec gardes, des clauses itératives, des ligne de vie doublées, les interactions concurrentes
Savoir exprimer la création et la destruction d’un objet
Construire un diagramme de séquence décrivant le déroulement (scénario) principal (ou secondaire) d’un cas d’utilisation
