Transcript UML - Diagramme de séquences

UML - Diagramme de séquences
1
Diagrammes de séquence : Définition
• Les diagrammes de séquences représentent
les interactions comme une sorte de clôture
où chaque nouvel objet est ajouté à droite.
2
Diagrammes de séquence : Exemple
Objets
Nom de classe
Nom de l’objet
Message reçu par un objet
de la classe A
(appel de méthode)
Messages envoyés par une méthode de
la classe A à la classe B
(appel de méthode)
3
Diagrammes de séquence : Exemple
Si en terme d’analyse et
conception orientées
objet, on parle de
message, en
programmation, on parle
plutôt d’appel de
méthodes.
4
Diagrammes de séquence : Message
• Chaque message échangé entre des objets est
symbolisé par une flèche pleine et continue.
• La chronologie des envois de messages est organisée
du haut vers le bas (et de gauche à droite).
5
Diagrammes de séquence : Message,
Opération et Méthode
• Un message n’est pas forcément une
opération d’une classe.
• Mais dans la plupart des cas, un message est
‘implémenté’ par une opération d’une classe
qui, elle-même, est ‘implementée’ par une
méthode.
• Voyons un exemple concret.
6
Diagrammes de séquence : Message,
Opération et Méthode
Message
Message envoyé d’un objet quelconque de la classe CTask à l’objet EndPoint de la classe
IPEndPoint. En l’occurrence, le message se traduit par une opération qui est le constructeur
de la classe.
7
Diagrammes de séquence : Message,
Opération et Méthode
Opération
Dans la classe CTask, il existe une opération pour le constructeur.
8
Diagrammes de séquence : Message,
Opération et Méthode
Méthode
In fine, le message est devenu une opération d’une classe et cette opération est devenue
une méthode de la classe.
9
Diagrammes de séquence : Message,
Opération et Méthode
Message
Opération
Méthode
10
Diagrammes de séquence : Message
trouvé
• Dans la figure ci-dessus, le message
‘messageUn()’ est le message de départ et se
nomme message trouvé (found message).
11
Diagrammes de séquence : Message
trouvé
• Un message trouvé est un message pour lequel soit
l’émetteur est inconnu, soit le message provient
d’une source aléatoire.
12
Diagrammes de séquence : Message
trouvé
13
Diagrammes de séquence : Syntaxe
des Messages
• UML dispose d’une syntaxe standard pour
formuler les messages :
Retour = message (paramètre : typeParamètre) : typeRetour
–
–
–
–
–
Initialiser(code)
Initialiser
d = getDescriptionProduit(code)
d = getDescriptionProduit(code : CodeArticle)
d = getDescriptionProduit(code : CodeArticle) : DesciptionProduit
• Les informations relatives au type peuvent être
omises lorsqu’elles sont évidentes ou sans
importance.
14
Diagrammes de séquence : Ligne de
vie
• Les boîtes de lignes de vies des diagrammes
de séquences sont prolongées par une ligne
verticale : ce sont les lignes de vie réelles.
• La spécification UML 2.0 précise que les lignes
de vies peuvent être en continues ou
pointillées.
15
Diagrammes de séquence : Ligne de
vie
Lignes de vie
16
Diagrammes de séquence : Ligne de vie et
création d’objet
• La création d’un nouvel objet (création d’une nouvelle
instance) se fait :
– par l’appel du constructeur
– Par l’utilisation d’un message create ou new
• Un stéréotype sur l’opération (« constructor ») peut renforcer
la notion de constructeur.
• En UML 1.0, la création se fait avec un message normal (flèche
pleine).
• En UML 2.0, la création se fait avec une flèche pointillée.
17
Diagrammes de séquence : Ligne de vie et
création d’objet
18
Diagrammes de séquence : Ligne de vie et
destruction d’objets
• En UML, la croix permet de montrer
explicitement la destruction d’un objet.
• Cela équivaut généralement à l’utilisation
dans le code de l’opérateur delete.
19
Diagrammes de séquence : Ligne de vie et
destruction d’objets
create()
delete()
Durée de
vie de
l’objet
Marque de destruction20
Diagrammes de séquence : barre
d’activation
• Les diagrammes de séquence peuvent représenter
les points de contrôle à l’aide de barres de
spécification d’exécution, auparavant nommées
barres d’activation, ou simplement activation (en
UML 1.0).
• Cette barre est facultative
– Souvent ignorée en mode esquisse
– Souvent automatique avec les outils UML
21
Diagrammes de séquence : barre
d’activation
22
Diagrammes de séquence :
représentations des retours
• Il existe deux façons de représenter le retour
résultant d’un message :
– appliquer la syntaxe valeurDeRetour =
message(paramètre);
– employer une ligne pointillée de réponse (ou
retour) à la fin de la barre d’activation.
• Parfois, ni l’un ni l’autre ne sont utilisés car le
schéma est suffisamment clair pour désigner
le retour d’un message.
23
Diagrammes de séquence :
représentations des retours
Retour implicite
Le bons sens est
d’application pour
ne pas surcharger
le diagramme
Non ambigu
Destruction
24
Diagrammes de séquence :
représentations des retours
Utilisation de la syntaxe du
message
25
Diagrammes de séquence :
représentations des retours
Utilisation du retour explicite
26
Diagrammes de séquence : Messages d’un
objet à lui-même
• On peut montrer qu’un objet s’envoie un
message à lui-même à l’aide d’une flèche
« circulaire ».
27
Diagrammes de séquence :
Concurrences des messages
• Par défaut, un message est séquentiel, c’est-àdire que l’appel est bloquant.
messageUn est
bloqué tant que
messageDeux est
activé
28
Diagrammes de séquence :
Concurrences des messages
• Il est possible néanmoins de représenter une
opération asynchrone, autrement dit un message
non bloquant (retour immédiat).
• Une opération asynchrone (non bloquante) est
représentée par une flèche ouverte :
29
Diagrammes de séquence :
Concurrences des messages
• Se pose alors le problème de la réponse;
comment recevoir le résultat/la réponse du
message ?
– Soit, il n’y a pas de réponse,
– Soit par un appel bloquant synchronisant le
traitement,
– Soit par polling sur l’état de l’opération,
– Soit via une ‘interruption’, autrement dit un
message de retour
30
Diagrammes de séquence :
Concurrences des messages
Le traitement continue en parallèle
Pas évident avec Rational Rose. Ne
tient pas compte du côté asynchrone
du message pour la ligne d’activation
Pas de réponse attendue
31
Diagrammes de séquence :
Concurrences des messages
Synchronisation par
un appel bloquant
32
Diagrammes de séquence :
Concurrences des messages
Synchronisation par
‘interruption’
33
Diagrammes de séquence :
Concurrences des messages
• N’oublions pas que l’interruption peut
survenir à n’importe quel moment.
• On peut donc mettre le message de retour
directement après le traitement asynchrone.
34
Diagrammes de séquence :
Concurrences des messages
Traitement
asynchrone
Traitement
de la réponse
Traitement
parallèle
35
Diagrammes de séquence :
Concurrences des messages
• Un exemple concret : le premier processus lancé par
Windows est SMS.EXE (Session Manager).
• SMS.EXE lance à son tour Csrss.exe et Winlogon.exe
• Ensuite il attend qu’un des deux processus se
termine pour ‘crasher’ le système (sauf si un
shutdown est un cours).
• Voyons comment représenter cela avec un
diagramme de séquence.
36
Diagrammes de séquence :
Concurrences des messages
Le Kernel est vu comme un ‘acteur’
Appel
bloquant
Messages asynchrones
37
Diagrammes de séquence :
Concurrences des messages
• Il existe d’autres valeurs pour la concurrence
des messages :
– Simple (défaut) : Appel bloquant via un seul
thread.
– Synchronous : Appel bloquant (plusieurs threads
possibles).
38
Diagrammes de séquence :
Concurrences des messages
– Balking : Le client passe un message au fournisseur à
condition que le fournisseur accepte directement le
message. Sinon, le message est abandonné.
– Timeout : Le client passe un message au fournisseur et
abandonne le message si le fournisseur ne l’accepte
endéans un délai déterminé.
39
Diagrammes de séquence :
Concurrences des messages
• Asynchrone : le client envoie un message au
fournisseur et continue son exécution en
parallèle.
40
Diagrammes de séquence : conditions,
boucles, …
• UML 1.0 ne définit aucune notation pour :
–
–
–
–
les conditions : if (…) then {} else {}
les boucles : for(…) {} while (…) {}
le parallélisme
…
• L’emploi judicieux de notes permet de remédier à ce
manque.
• UML 2.0, par contre, définit une notation pour ces
différents contrôles d’exécution. Nous ne les
aborderons pas maintenant.
41
Diagrammes de séquence : Exemple
de condition
42
Diagrammes de séquence : Exemple
de condition
43
Diagrammes de séquence : Exemple
de boucles
44
Diagrammes de séquence : Exemple
de boucles
• L’utilisation de note est le meilleur moyen de
noter quelque chose d’important et qui n’est
pas défini par UML.
• Attention néanmoins à ne pas surcharger
inutilement le diagramme de notes inutiles au
risque de le rendre illisible.
45
Diagrammes de séquence : conditions,
boucles, …
• UML 1.0 définit néanmoins une notation pour
les messages conditionnels.
• Malheureusement, cette notation n’est pas
implémentée par tous les outils de
modélisation.
Condition entre crochets []
46
Diagrammes de séquence :
Polymorphisme
• Le polymorphisme est un concept fondamental de la
conception orientée objet. Comment le représenter
dans un diagramme de séquence ?
• Une solution consiste à utiliser plusieurs diagrammes
de séquence
– l’un montrant le message polymorphe vers la super-classe
abstraite (ou l’objet interface)
– Puis plusieurs diagrammes séparés détaillant chaque cas
polymorphe, chacun commençant par un message
polymorphe trouvé (sans source).
47
Diagrammes de séquence :
Polymorphisme
Classe abstraite
48
Diagrammes de séquence :
Polymorphisme
Classe abstraite
49
Diagrammes de séquence :
« Boundary »
• Dans un diagramme de séquence, on a généralement
un acteur qui interagit avec le système.
• Ces interactions se font à travers une classe avec le
stéréotype « boundary ».
• Une « boundary » est une interface graphique ou
une autre interface Hommme/Machine (écran
tactile, PocketPC, …)
50
Diagrammes de séquence :
« Boundary »
: Administratif
: FicheInscriptionSession
51
Exemple
52
Exemple
53