Diagrammes de séquence : l’échange de messages dans un système UML

Le diagramme de séquence est un type de diagramme du Unified Modeling Language (Langage de Modélisation Unifié) (UML). L’UML est à son tour un langage de modélisation orienté objet. Un tel langage est constitué d’éléments graphiques. L’UML modélise les systèmes et processus de programmation orientée objet et les processus métier. L’objectif est de présenter des faits complexes d'une manière claire. L’UML définit une notation standardisée à cet effet. Un formulaire représente toujours un composant ou un comportement spécifique. Ce que l’on appelle la métamodélisation définit les unités de langage et leur signification au sein de l’UML. Il s’agit également de déterminer comment certains éléments peuvent interagir les uns avec les autres et quelles hiérarchies existent entre les unités linguistiques respectives.

Les éléments et les relations sont représentés par l’UML sous forme de diagrammes. L’UML distingue 14 types de diagrammes différents. Il les classe dans l’une des trois catégories suivantes : les diagrammes de structure, les diagrammes de comportement et les diagrammes d’interaction.

Les diagrammes de structure représentent un système et ses composants dans un état statique. Ils clarifient les relations qui existent entre les éléments individuels ou entre les éléments et les concepts supérieurs. Un exemple de ceci est le diagramme de classes.

• Les diagrammes de comportement représentent dynamiquement les processus et le comportement d’un système. Contrairement aux diagrammes de structure, la séquence des processus et donc le temps jouent un rôle dans l’affichage. Un exemple de ceci est le diagramme d’activités.
• Les diagrammes d’interaction appartiennent à la catégorie des diagrammes de comportement. Ils sont listés séparément parce qu’ils modélisent un comportement spécifique, à savoir les interactions entre les éléments du système. Les éléments de base des interactions sont ce qu’on appelle les lignes de vie. Ce sont des objets (c’est-à-dire les plus petits blocs de construction indépendants de la programmation orientée objet) qui représentent des participants individuels dans une interaction. Le diagramme d’interaction le plus couramment utilisé est le diagramme de séquence.

Le diagramme de séquence UML affiche les événements par ordre chronologique. C’est pourquoi on l’appelle parfois diagramme d’événement ou scénario d’événement. L’ordre (c’est-à-dire l’ordre exact) est plus important que des dates précises. Toutefois, vous pouvez ajouter des restrictions à votre modèle. Par exemple, une limite de temps pour un processus particulier (comme l’entrée du code PIN à un guichet automatique) peut provoquer un événement (retour de la carte si aucune entrée n’est effectuée après un certain temps).

Le diagramme de séquence décrit comment les objets (et les instances) échangent des messages dans un ordre particulier. Les objets sont les éléments de base des diagrammes UML. Selon le type de diagramme, ils représentent certaines caractéristiques d’un élément du système. Dans les interactions, les objets sont des lignes de vie.

Dans un système, des demandes sont constamment faites et des réponses sont envoyées. Le destinataire prend ensuite une décision en fonction de la demande spécifique et de ses propres règles prédéfinies. Un tel réseau de décisions et d’interactions possibles est généralement représenté par un diagramme d’activités. Si vous imaginez toutes les décisions possibles (oui/non) sous forme d’arborescence, vous obtenez probablement l’image d’un réseau fortement ramifié. Le diagramme de séquence ne montre qu’un seul chemin spécifique dans ce réseau.

Le diagramme de séquence diffère du diagramme de cas d’application UML en particulier par son ordre détaillé. Si un nouveau processus de gestion doit être introduit, le cas d’utilisation fournit une bonne synthèse des besoins. Si, par contre, vous devez définir des cas concrets avec un planning, créez un diagramme de séquence. Ceci vous permet d’afficher des sous-domaines individuels plus précisément. Avec ce soi-disant scénario d’application, vous mettez les connexions logiques de votre cas d’application à l’épreuve.

Les diagrammes de séquence UML sont également utiles lorsque vous devez représenter graphiquement des opérations complexes pour une meilleure compréhension. La modélisation claire vous permet d’identifier rapidement les stations par lesquelles une tâche unique doit passer pour être accomplie avec succès. Vous pouvez ainsi planifier et tester vos méthodes avant de les mettre en œuvre dans votre activité quotidienne ou dans un système informatique.

Pour représenter les structures de commande d’un langage de programmation supérieur, vous combinez plusieurs diagrammes de séquence dans un fragment combiné.

La ligne de vie représente le déroulement temporel d'un processus. Votre tête est constituée d’un rectangle. Celui-ci contient généralement le nom de l’objet et le nom de la classe. Si le nom de l’objet est manquant, la ligne de vie représente une instance sans nom de l’objet. Dans ce cas, on peut supposer que tous les objets de la même classe agissent de la même manière dans cette séquence. La ligne de vie représente toujours un seul opérande. Si l’opérande a plusieurs valeurs, l’une d’entre elles doit être sélectionnée. Alternativement, on peut aussi dire que la multiplicité n’est jamais >1.

Une ligne pointillée descend de la tête rectangulaire. Cette ligne représente le cours du temps. Vers le bas, le temps évolue linéairement. Les messages sont envoyés et les réponses données le long de la ligne de temps. Un message qui doit être envoyé après un autre message se trouve plus bas sur la ligne de temps. La notation ne porte jamais sur des points précis dans le temps, mais toujours sur la séquence. Les messages sont toujours disposés les uns en dessous des autres, à moins qu’ils n’existent en fragments combinés parallèles.

Les lignes de vie indiquent combien de temps un objet est activement impliqué dans un processus. On peut le voir en comparant la durée de vie d'une ligne de vie à celle des autres. Certains objets sont détruits avant la fin du processus. Les objets qui ne sont plus nécessaires sont marqués d’un X sur leur ligne de vie à l’endroit où ils doivent être détruits.

Pour tester la robustesse de votre système, le diagramme de séquence avec ses vues détaillées est très bien adapté. Trois stéréotypes de classe de la ligne de vie peuvent être utilisés :

• Organisme
• Frontalier
• Domination

En haut de l’image, vous pouvez voir les trois lignes de vie, y compris la notation : l’entité a une tête ronde qui se trouve sur une ligne horizontale. Au bord, une ligne part au milieu du cercle et se raccorde à une ligne verticale, comme un T incliné qui part sur le côté de la tête. La tête de la commande se compose d’une flèche qui tourne en cercle. De tous ces stéréotypes de classe, la ligne pointillée de la durée de vie est verticale vers le bas.

Si vous avez déjà élaboré un concept à l’aide d’un diagramme de cas d'utilisation, le diagramme de séquence peut vous aider, par exemple, à définir les étapes individuelles en tenant compte des acteurs et objets concevables.

Les frontières sont des interfaces qui interagissent avec des acteurs externes. Ces objets peuvent, par exemple, être des interfaces utilisateur où l’acteur serait alors une personne. Les entités, d’autre part, représentent des conteneurs de données ou des objets qui contiennent des données système. Pour que les frontières et les entités communiquent, vous avez besoin d’un élément de contrôle. Le contrôle ne doit pas nécessairement être un objet. Une méthode affectée à l’un des deux autres éléments fonctionne également. L’élément de contrôle relie l’entité et la frontière en tant que médiateur. Il surveille les signaux des deux éléments et vérifie leur logique.

Les trois stéréotypes communiquent selon quatre règles :

• Les objets frontaliers sont responsables en tant qu’interfaces pour la communication avec les acteurs. Ainsi, les acteurs communiquent exclusivement avec les frontières.
• En revanche, les objets de contrôle communiquent avec d'autres objets de contrôle ainsi qu’avec des entités et des limites. Mais ils n’interagissent pas avec les acteurs.
• Les frontières communiquent donc avec les objets de contrôle et avec les acteurs.
• Les entités sont les supports de données les plus profondément enracinés dans le système. Vous échangez uniquement des données avec des objets de contrôle.

Les messages de réponse peuvent n’avoir qu’une seule expression avec au maximum un opérande par paramètre. Si l’expéditeur d’une réponse n'édite pas de valeurs, le message n’a pas non plus de valeurs spécifiques à envoyer. Normalement, le message modélise les paramètres de sortie d’un émetteur (c'est-à-dire les valeurs résultant d’une opération) comme opérandes. Sans paramètres de sortie, l’opérande doit rester vide. Dans ce cas, modélisez simplement le caractère de remplacement au lieu de la valeur de retour. S’il existe un opérande, le système l’analyse à nouveau par rapport à la spécification d’apparence. Le résultat de l’évaluation spécifie les valeurs des paramètres « out », « inout » et « return ».

L’UML retient trois symboles qui spécifient le destinataire du message comme expression de paramètre. Le destinataire est la cible d’assignation du message. Le message de réponse lui affecte la valeur de retour du paramètre de sortie de l'émetteur. Ce sont les symboles normalisés :

• Inconnu
• Paramètres d'interaction
• Particularités

Inconnu est un paramètre vide et représente le caractère de remplacement. Le paramètre d’interaction est un paramètre propre de l’interaction à laquelle il appartient. Cela signifie que l’interaction a le paramètre. Celui-ci a un nom. Les paramètres d’opération et les paramètres d’interaction sont du même type. Les attributs peuvent être nommés sans restriction. Ils représentent le nom d’un comportement de contexte. Ce comportement détermine soit la ligne de vie vers laquelle le message retourne, soit l’interaction environnante. Si l’interaction ne définit aucun comportement, elle agit comme un contexte.

Les portes sont simplement des points à la fin d’un message. Ils appartiennent au type MessageEnd. Il marque l’expéditeur et le destinataire d’un message. Les portes illustrent le flux d’informations et montrent comment les messages se déplacent entre deux fragments d’interaction. Pour être plus précis, ils représentent des points de connexion pour les messages entre les avantages de l’interaction et les interactions, ainsi qu’entre les opérandes d’interaction à l’intérieur et à l’extérieur d’un fragment combiné. Ils sont placés sur le cadre du diagramme.

Le diagramme de séquence UML connaît quatre types de portes (ou portail). Elles diffèrent par les fragments d’interaction auxquels elles sont associés :

• Le point de départ factuel : les avantages de l’interaction se réfèrent d’un diagramme à l’autre. La porte factuelle ouvre la connexion au bord extérieur de l’utilitaire d’interaction pour les messages de l’interaction à laquelle l’utilitaire d’interaction se réfère. La porte a donc une association avec l’utilisation de l’interaction et accepte les messages entrants et sortants. (Anglais : Actual Gate)
• La porte formelle : pour qu’une interaction puisse échanger des messages avec un avantage d’interaction, elle a besoin d’une porte formelle. Le portail est situé à l'intérieur du cadre. (Anglais : Formal Gate)
• La porte intérieure pour les fragments combinés : dans un fragment combiné, une porte (Gate) repose sur le cadre. Les messages avec des terminaisons de message à partir du fragment combiné qu’il échange avec les messages dont les terminaisons de message sont en dehors du fragment combiné. (Anglais : Inner CombinedFragment Gate)
• La porte extérieure pour les fragments combinés : cette porte se trouve sur le bord extérieur d’un fragment combiné. Il forme le pôle opposé à la porte intérieure. (Anglais : Outer CombinedFragment Gate)

Les portes ont des noms explicites ou implicites qui doivent correspondre par paires. Les portes factuelles et formelles doivent correspondre, tout comme les portes intérieures et extérieures pour les fragments combinés. De plus, les messages doivent aller dans la même direction et avoir les mêmes valeurs de propriété et MessageSort indubitables.

Les messages jouent un rôle particulier dans les diagrammes de communication. Ce type de diagramme est une forme simple du diagramme de séquence. Les diagrammes de communication modélisent comment les lignes de vie interagissent. Contrairement aux diagrammes de séquence, ils se concentrent sur l’architecture du système et la façon dont elle détermine le flux des messages. Bien que vous puissiez montrer une architecture détaillée, les fragments d’interaction tels que les fragments combinés ne l’utilisent pas. Par conséquent, il manque un élément de force. Au lieu de cela, numérotez les messages. Parfois, les nouvelles peuvent prendre le pas sur les autres. L’ordre des messages sortants diffère alors de l’ordre des messages entrants. Cependant, le standard UML déconseille de tels messages non séquentiels dans le diagramme de communication.

La notation UML pour les diagrammes de communication prescrit un cadre de diagramme de séquence simple : un rectangle avec une étiquette pentagonale dans la tête. Dans l’étiquette, la désignation « sd » indique ce type de diagramme. Notez le nom de l’interaction à côté. Les messages ont ici une forme différente : ils relient les lignes de vie rectangulaires (UML : nœuds objets) en lignes droites simples (UML : bords).

Au-dessus, notez l’expression de séquence ainsi qu’une flèche pointant dans la direction du récepteur. La désignation de séquence a la forme suivante : [Nom entier][Répéter]. L’entier spécifie la hiérarchie des éléments imbriqués. Si l’un des nombres entiers s’écarte de deux messages (par exemple 1.2.2 et 1.2.3), le système les envoie l’un après l’autre. Le nom, d’autre part, représente des émissions simultanées. Deux messages avec la désignation de séquence 1.2.3a et 1.2.3b sont envoyés simultanément par le système en raison du nombre entier identique. La répétition comprend soit une restriction qui détermine quand le message sera envoyé, soit une valeur qui détermine à quelle fréquence le message sera répété.

Gardes

En UML, la Garde surveille le comportement d’un élément. L'élément doit être l'un ou l'autre :

• remplir une certaine condition,
• ne pas dépasser ou descendre en dessous d'une certaine valeur ou
• corroborer une affirmation.

Une garde est donc une restriction. Ce n'est que si la restriction est respectée que l'élément influencé peut exercer un certain comportement. Il y a beaucoup d'éléments différents qui peuvent avoir une telle garde : actions, attributs, comportements et autres. UML ne prescrit pas un langage strict, mais offre OCL, le langage de contrainte objet, comme option native. Les variables booléennes sont aussi souvent utilisées.

Une restriction d’interaction est constituée d’une telle expression booléenne. La restriction sert de garde pour l’opérande dans un fragment combiné. Ce n’est que si la valeur de la contrainte est vraie que le fragment d’interaction qui l’entoure commence son comportement. Notez la restriction entre crochets sur la ligne de vie au-dessus d’une spécification d’exécution. La standardisation permet de combiner des fragments sans restriction d’interaction. Dans ce cas, le système suppose que les messages entrants sont vrais.

Comme les avantages de l’interaction se réfèrent à d’autres diagrammes, ces facteurs externes déterminent leur comportement. Alors que l’interaction est liée à des portes formelles, l’interaction de référence l’est à la porte réelle.

La décomposition partielle est la décomposition partielle et séquentielle d’une ligne de vie dans une interaction par une autre interaction. Avec une telle décomposition, vous pouvez séparer les détails les uns des autres et ainsi examiner de plus près les différentes sous-fonctions. Si une nouvelle arrive ou émane de la ligne de vie décomposée, elle est considérée comme une porte réelle. Celles-ci sont liées aux portes formelles de l’action de décomposition. Les portes et les paramètres des deux éléments doivent correspondre. La décomposition partielle reçoit également le label « ref » comme un bénéfice d’interaction et est définie par l’interaction associée.

Le début et la fin marquent le début et la fin de la spécification de l’événement. Au début d’une activation il y a l’événement de début, à la fin, il y a l’événement de fermeture. Ces fragments représentent chacun un moment unique et existent sur une seule ligne de vie. La spécification de l’événement représente le début ou la fin d’une action. La spécification d’événement de message donne le signal d’envoyer et de recevoir un message. Leur valeur dépend donc toujours du message ou de l’action.

L’activation n’a pas de notation séparée. Elle existe implicitement sur les bords extérieurs du rectangle de la spécification d’exécution. Si la spécification d’exécution passe par une action atomique, les associations initiales et finales se réfèrent à la même spécification d'apparence. Vous pouvez le mettre en évidence avec une ligne de connexion entre l'action et la spécification d'apparence entrante.

Alors que les autres spécifications d’apparence n’exigent pas de notation, marquez la spécification d’apparence du message Destruction avec un grand X. Il marque la résolution d’une instance d’objet à un certain point de la ligne de vie. La ligne de vie s’arrête là. Les instances subordonnées ou les spécifications d’apparence à des moments ultérieurs de la ligne de temps sont alors invalides. Car après la destruction de l’objet, elles n'’xistent plus non plus.

Parfois, les spécifications d’exécution se chevauchent. Par exemple, lorsqu'un objet s'envoie un message à lui-même, une spécification d'exécution envoie un message à une autre instance de cette classe. Les deux spécifications sont en partie sur la même ligne de vie en même temps. Dans le diagramme de séquence UML, vous représentez cette situation avec des rectangles qui se chevauchent.

L’invariant d’état spécifie une valeur restrictive. Si cette valeur est égale à l’état de l’objet, la piste est considérée comme valide. Si l'objet ne répond pas à la restriction, sa piste est invalide.

Selon la notation du diagramme de séquence UML, l'invariant d'état est soit entre accolades bouclées sur la spécification d'exécution, soit vous utilisez le rectangle arrondi de la classe Etat.

Les fragments combinés appartiennent aux fragments d’interaction. Ces fragments sont des éléments abstraits du système. Ils représentent les unités d'interaction. Cela signifie que, d'une part, ils font partie d'une interaction. D’autre part, il s’agit également de petites interactions. Les fragments combinés dans un diagramme de séquence déterminent le comportement de plusieurs fragments d'interaction. Mais ils ne forment eux-mêmes que le cadre. Ils sont définis par des opérateurs d'interaction et des opérandes d'interaction. Les opérandes contiennent un ou plusieurs messages. Sur la ligne de vie devant un fragment combiné, une restriction, également appelée garde, veille sur les opérandes contenues.

Comme déjà décrit, les opérandes sont des quantités constantes ou variables qui passent par un processus. Les opérateurs influencent le comportement des opérandes. Par exemple, l’opérateur booléen « OR » peut spécifier que l’opérande A ou l’opérande B soit exécutée (ou les deux). Dans un fragment combiné, un opérande spécifie qu'un message spécifique est envoyé sous certaines conditions. L’opérateur détermine quelles relations les opérandes d'un fragment ont entre eux et quelle relation ils ont avec le fragment supérieur.

UML définit 12 opérateurs d’interaction.

Alternative :

Dans le fragment combiné avec l'opérateur d'interaction « Alternative », un fragment enfant ne peut envoyer un message que si une certaine condition est remplie. Sinon, un fragment concurrent à l'intérieur de la trame enverra son message. L'image ci-dessus montre un exemple d’un fragment combiné avec l'opérateur « Alternative ». Utilisez l'abréviation « alt » pour l'étiquette. Divisez le cadre rectangulaire par une ligne pointillée horizontale. La partie supérieure est une condition.

Garde :

La Garde vérifie si la condition de l'opérande est remplie. Si oui, le système envoie un message dans le domaine des conditions. Sinon, il envoie un message dans la zone de l'alternative. Un opérande à l'intérieur de ce fragment combiné a toujours besoin d'une garde qui est jugée vraie pour être exécutée. Si l'opérande de condition n'a pas de garde explicite, une garde implicite est présumée. Donc ce fragment représente toujours une décision entre les deux.

Option :

Ce fragment combiné est modélisé dans le diagramme de séquence comme l'alternative. Parce que l'option signifie aussi une décision. Cependant, il n'y a qu'un seul opérande. La décision est donc de savoir si l'opérande est exécuté ou non. L'opérande avec une condition ne doit pas être vide. Son alternative, par contre, est vide. Un fragment avec l’opérateur d'interaction « Option » est marqué avec l’étiquette « opt ».

Interruption :

Un fragment combiné avec l’opérateur d’interaction « break » interrompt le fragment parent. Si une ligne de vie remplit la condition de l'opérande, le système exécute le fragment combiné. Au lieu de cela, il ignore le reste du fragment parent. Pour que toutes les lignes de vie puissent épuiser leur durée de vie, vous devez inclure chaque ligne de vie dans le fragment combiné. Sinon, une ligne de vie peut s'arrêter au milieu du processus sans être correctement détruite. Si le fragment de rupture manque de garde, la décision n'est pas déterministe. Nous vous recommandons donc d’utiliser un protecteur.

Au guichet automatique, par exemple, il est possible d'entrer trois fois le bon PIN. Si le code PIN est erroné, il vous sera demandé de répéter la saisie. Dans le diagramme de séquence UML, notez le message « entrer PIN » et sa réponse « PIN incorrect. Réessayer » avec les flèches correspondantes. L'étiquette a la forme Loop (0,2). La variable booléenne est [PIN incorrect]. Tant que le code PIN est erroné, la boucle se répète deux fois. Si le code PIN est correct, le système résout la boucle. Si le nombre maximum de répétitions est dépassé, la boucle est également relâchée, mais le processus est interrompu comme non valide.

Selon la façon dont vous organisez la suite dans le diagramme de séquence, sa tâche change également. Si la suite se trouve au début de votre diagramme d'interaction, utilisez-le pour modéliser le comportement de la suite. Si la suite se trouve à la fin de votre fragment d’interaction, elle fait suivre le processus. Si vous nommez votre suite (comme dans l'exemple : notOK), le fragment suivant sur la ligne de vie doit avoir une suite du même nom (notOK) ou il ne doit pas modéliser une suite. Si la suite est seule dans le fragment, cela correspond à une suite à la fin du fragment.