UML - Diagramme de séquences

1. UML - Diagramme de séquences

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

3. 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) Diagrammes de séquence : Exemple

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

5. 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).

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

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

8. Diagrammes de séquence : Message, Opération et Méthode Opération Dans la classe CTask, il existe une opération pour le constructeur.

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

10. Diagrammes de séquence : Message, Opération et Méthode Message Opération Méthode

11. 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).

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

13. Diagrammes de séquence : Message trouvé

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

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

16. Diagrammes de séquence : Ligne de vie Lignes de vie

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

18. Diagrammes de séquence : Ligne de vie et création d’objet

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

20. Marque de destruction Diagrammes de séquence : Ligne de vie et destruction d’objets create() delete() Durée de vie de l’objet

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

22. Diagrammes de séquence : barre d’activation

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

24. Retour implicite Non ambigu Destruction Diagrammes de séquence : représentations des retours Le bons sens est d’application pour ne pas surcharger le diagramme

25. Utilisation de la syntaxe du message Diagrammes de séquence : représentations des retours

26. Utilisation du retour explicite Diagrammes de séquence : représentations des retours

27. 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 ».

28. messageUnestbloquétantquemessageDeuxestactivé Diagrammes de séquence : Concurrences des messages • Par défaut, un message est séquentiel, c’est-à-dire que l’appel est bloquant.

29. 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 :

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

31. Le traitement continue en parallèle Diagrammes de séquence : Concurrences des messages 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

32. Diagrammes de séquence : Concurrences des messages Synchronisation par un appel bloquant

33. Diagrammes de séquence : Concurrences des messages Synchronisation par ‘interruption’

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

35. Traitement asynchrone Traitement de la réponse Diagrammes de séquence : Concurrences des messages Traitement parallèle

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

37. Le Kernel est vu comme un ‘acteur’ Appel bloquant Messages asynchrones Diagrammes de séquence : Concurrences des messages

38. 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).

39. 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é.

40. Diagrammes de séquence : Concurrences des messages • Asynchrone : le client envoie un message au fournisseur et continue son exécution en parallèle.

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

42. Diagrammes de séquence : Exemple de condition

43. Diagrammes de séquence : Exemple de condition

44. Diagrammes de séquence : Exemple de boucles

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

46. Condition entre crochets [] 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.

47. 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).

48. Classe abstraite Diagrammes de séquence : Polymorphisme

49. Classe abstraite Diagrammes de séquence : Polymorphisme

50. 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, …)