Dia­grammes 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 Mo­dé­li­sa­tion Unifié) (UML). L’UML est à son tour un langage de mo­dé­li­sa­tion orienté objet. Un tel langage est constitué d’éléments gra­phiques. L’UML modélise les systèmes et processus de pro­gram­ma­tion 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 stan­dar­di­sée à cet effet. Un for­mu­laire re­pré­sente toujours un composant ou un com­por­te­ment spé­ci­fique. Ce que l’on appelle la mé­ta­mo­dé­li­sa­tion définit les unités de langage et leur sig­ni­fi­ca­tion au sein de l’UML. Il s’agit également de dé­ter­mi­ner comment certains éléments peuvent interagir les uns avec les autres et quelles hié­rar­chies existent entre les unités lin­guis­tiques res­pec­tives.

Les éléments et les relations sont re­pré­sen­tés par l’UML sous forme de dia­grammes. L’UML distingue 14 types de dia­grammes dif­fé­rents. Il les classe dans l’une des trois ca­té­go­ries suivantes : les dia­grammes de structure, les dia­grammes de com­por­te­ment et les dia­grammes d’in­te­rac­tion.

Les dia­grammes de structure re­pré­sen­tent un système et ses com­po­sants dans un état statique. Ils cla­ri­fient les relations qui existent entre les éléments in­di­vi­duels ou entre les éléments et les concepts su­pé­rieurs. Un exemple de ceci est le diagramme de classes.

• Les dia­grammes de com­por­te­ment re­pré­sen­tent dy­na­mi­que­ment les processus et le com­por­te­ment d’un système. Con­trai­re­ment aux dia­grammes 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 dia­grammes d’in­te­rac­tion ap­par­tien­nent à la catégorie des dia­grammes de com­por­te­ment. Ils sont listés sé­pa­ré­ment parce qu’ils mo­dé­li­sent un com­por­te­ment spé­ci­fique, à savoir les in­te­rac­tions entre les éléments du système. Les éléments de base des in­te­rac­tions sont ce qu’on appelle les lignes de vie. Ce sont des objets (c’est-à-dire les plus petits blocs de cons­truc­tion in­dé­pen­dants de la pro­gram­ma­tion orientée objet) qui re­pré­sen­tent des par­ti­ci­pants in­di­vi­duels dans une in­te­rac­tion. Le diagramme d’in­te­rac­tion le plus cou­ram­ment utilisé est le diagramme de séquence.

Le diagramme de séquence UML affiche les évé­ne­ments par ordre chro­no­lo­gique. 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 res­tric­tions à votre modèle. Par exemple, une limite de temps pour un processus par­ti­cu­lier (comme l’entrée du code PIN à un guichet au­to­ma­tique) 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 par­ti­cu­lier. Les objets sont les éléments de base des dia­grammes UML. Selon le type de diagramme, ils re­pré­sen­tent certaines ca­rac­té­ris­tiques d’un élément du système. Dans les in­te­rac­tions, les objets sont des lignes de vie.

Dans un système, des demandes sont cons­tam­ment faites et des réponses sont envoyées. Le des­ti­na­taire prend ensuite une décision en fonction de la demande spé­ci­fique et de ses propres règles pré­dé­fi­nies. Un tel réseau de décisions et d’in­te­rac­tions possibles est gé­né­ra­le­ment re­pré­senté par un diagramme d’activités. Si vous imaginez toutes les décisions possibles (oui/non) sous forme d’ar­bo­res­cence, vous obtenez pro­ba­ble­ment l’image d’un réseau fortement ramifié. Le diagramme de séquence ne montre qu’un seul chemin spé­ci­fique dans ce réseau.

Le diagramme de séquence diffère du diagramme de cas d’ap­pli­ca­tion UML en par­ti­cu­lier par son ordre détaillé. Si un nouveau processus de gestion doit être introduit, le cas d’uti­li­sa­tion 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 in­di­vi­duels plus pré­ci­sé­ment. Avec ce soi-disant scénario d’ap­pli­ca­tion, vous mettez les con­nexions logiques de votre cas d’ap­pli­ca­tion à l’épreuve.

Les dia­grammes de séquence UML sont également utiles lorsque vous devez re­pré­sen­ter gra­phi­que­ment des opé­ra­tions complexes pour une meilleure com­pré­hen­sion. La mo­dé­li­sa­tion claire vous permet d’iden­ti­fier ra­pi­de­ment les stations par les­quelles 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é quo­ti­dienne ou dans un système in­for­ma­tique.

Pour re­pré­sen­ter les struc­tures de commande d’un langage de pro­gram­ma­tion supérieur, vous combinez plusieurs dia­grammes de séquence dans un fragment combiné.

La ligne de vie re­pré­sente le dé­rou­le­ment temporel d'un processus. Votre tête est cons­ti­tuée d’un rectangle. Celui-ci contient gé­né­ra­le­ment le nom de l’objet et le nom de la classe. Si le nom de l’objet est manquant, la ligne de vie re­pré­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 re­pré­sente toujours un seul opérande. Si l’opérande a plusieurs valeurs, l’une d’entre elles doit être sé­lec­tion­née. Al­ter­na­ti­ve­ment, on peut aussi dire que la mul­ti­pli­cité n’est jamais >1.

Une ligne poin­til­lée descend de la tête rec­tan­gu­laire. Cette ligne re­pré­sente le cours du temps. Vers le bas, le temps évolue li­néai­re­ment. 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 pa­ral­lèles.

Les lignes de vie indiquent combien de temps un objet est ac­ti­ve­ment 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é­ces­saires sont marqués d’un X sur leur ligne de vie à l’endroit où ils doivent être détruits.

Pour tester la ro­bus­tesse de votre système, le diagramme de séquence avec ses vues dé­tail­lées est très bien adapté. Trois sté­réo­types de classe de la ligne de vie peuvent être utilisés :

• Organisme
• Fron­ta­lier
• Do­mi­na­tion

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 ho­ri­zon­tale. 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éo­types de classe, la ligne poin­til­lé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'uti­li­sa­tion, le diagramme de séquence peut vous aider, par exemple, à définir les étapes in­di­vi­duelles en tenant compte des acteurs et objets con­ce­vables.

Les fron­tières sont des in­ter­faces qui in­te­ra­gis­sent avec des acteurs externes. Ces objets peuvent, par exemple, être des in­ter­faces uti­li­sa­teur où l’acteur serait alors une personne. Les entités, d’autre part, re­pré­sen­tent des con­te­neurs de données ou des objets qui con­tien­nent des données système. Pour que les fron­tières et les entités com­mu­ni­quent, vous avez besoin d’un élément de contrôle. Le contrôle ne doit pas né­ces­sai­re­ment être un objet. Une méthode affectée à l’un des deux autres éléments fonc­tionne é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éo­types com­mu­ni­quent selon quatre règles :

• Les objets fron­ta­liers sont res­pon­sables en tant qu’in­ter­faces pour la com­mu­ni­ca­tion avec les acteurs. Ainsi, les acteurs com­mu­ni­quent ex­clu­si­ve­ment avec les fron­tières.
• En revanche, les objets de contrôle com­mu­ni­quent avec d'autres objets de contrôle ainsi qu’avec des entités et des limites. Mais ils n’in­te­ra­gis­sent pas avec les acteurs.
• Les fron­tières com­mu­ni­quent donc avec les objets de contrôle et avec les acteurs.
• Les entités sont les supports de données les plus pro­fon­dé­ment enracinés dans le système. Vous échangez uni­que­ment des données avec des objets de contrôle.

Les messages de réponse peuvent n’avoir qu’une seule ex­pres­sion avec au maximum un opérande par paramètre. Si l’ex­pé­di­teur d’une réponse n'édite pas de valeurs, le message n’a pas non plus de valeurs spé­ci­fiques à envoyer. Nor­ma­le­ment, le message modélise les pa­ra­mètres de sortie d’un émetteur (c'est-à-dire les valeurs résultant d’une opération) comme opérandes. Sans pa­ra­mètres de sortie, l’opérande doit rester vide. Dans ce cas, modélisez sim­ple­ment le caractère de rem­pla­ce­ment au lieu de la valeur de retour. S’il existe un opérande, le système l’analyse à nouveau par rapport à la spé­ci­fi­ca­tion d’apparence. Le résultat de l’éva­lua­tion spécifie les valeurs des pa­ra­mètres « out », « inout » et « return ».

L’UML retient trois symboles qui spé­ci­fient le des­ti­na­taire du message comme ex­pres­sion de paramètre. Le des­ti­na­taire est la cible d’as­sig­na­tion 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 nor­ma­li­sés :

• Inconnu
• Pa­ra­mètres d'in­te­rac­tion
• Par­ti­cu­la­ri­tés

Inconnu est un paramètre vide et re­pré­sente le caractère de rem­pla­ce­ment. Le paramètre d’in­te­rac­tion est un paramètre propre de l’in­te­rac­tion à laquelle il ap­par­tient. Cela signifie que l’in­te­rac­tion a le paramètre. Celui-ci a un nom. Les pa­ra­mètres d’opération et les pa­ra­mètres d’in­te­rac­tion sont du même type. Les attributs peuvent être nommés sans res­tric­tion. Ils re­pré­sen­tent le nom d’un com­por­te­ment de contexte. Ce com­por­te­ment détermine soit la ligne de vie vers laquelle le message retourne, soit l’in­te­rac­tion en­vi­ron­nante. Si l’in­te­rac­tion ne définit aucun com­por­te­ment, elle agit comme un contexte.

Les portes sont sim­ple­ment des points à la fin d’un message. Ils ap­par­tien­nent au type Mes­sa­geEnd. Il marque l’ex­pé­di­teur et le des­ti­na­taire d’un message. Les portes il­lustrent le flux d’in­for­ma­tions et montrent comment les messages se déplacent entre deux fragments d’in­te­rac­tion. Pour être plus précis, ils re­pré­sen­tent des points de connexion pour les messages entre les avantages de l’in­te­rac­tion et les in­te­rac­tions, ainsi qu’entre les opérandes d’in­te­rac­tion à 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’in­te­rac­tion auxquels elles sont associés :

• Le point de départ factuel : les avantages de l’in­te­rac­tion se réfèrent d’un diagramme à l’autre. La porte factuelle ouvre la connexion au bord extérieur de l’uti­li­taire d’in­te­rac­tion pour les messages de l’in­te­rac­tion à laquelle l’uti­li­taire d’in­te­rac­tion se réfère. La porte a donc une as­so­cia­tion avec l’uti­li­sa­tion de l’in­te­rac­tion et accepte les messages entrants et sortants. (Anglais : Actual Gate)
• La porte formelle : pour qu’une in­te­rac­tion puisse échanger des messages avec un avantage d’in­te­rac­tion, elle a besoin d’une porte formelle. Le portail est situé à l'in­té­rieur du cadre. (Anglais : Formal Gate)
• La porte in­té­rieure pour les fragments combinés : dans un fragment combiné, une porte (Gate) repose sur le cadre. Les messages avec des ter­mi­nai­sons de message à partir du fragment combiné qu’il échange avec les messages dont les ter­mi­nai­sons de message sont en dehors du fragment combiné. (Anglais : Inner Com­bi­ned­Frag­ment Gate)
• La porte ex­té­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 in­té­rieure. (Anglais : Outer Com­bi­ned­Frag­ment Gate)

Les portes ont des noms ex­pli­cites ou im­pli­cites qui doivent cor­res­pondre par paires. Les portes fac­tuelles et formelles doivent cor­res­pondre, tout comme les portes in­té­rieures et ex­té­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 Mes­sa­ge­Sort in­du­bi­tables.

Les messages jouent un rôle par­ti­cu­lier dans les dia­grammes de com­mu­ni­ca­tion. Ce type de diagramme est une forme simple du diagramme de séquence. Les dia­grammes de com­mu­ni­ca­tion mo­dé­li­sent comment les lignes de vie in­te­ra­gis­sent. Con­trai­re­ment aux dia­grammes de séquence, ils se con­centrent sur l’ar­chi­tec­ture du système et la façon dont elle détermine le flux des messages. Bien que vous puissiez montrer une ar­chi­tec­ture détaillée, les fragments d’in­te­rac­tion tels que les fragments combinés ne l’utilisent pas. Par con­sé­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é­con­seille de tels messages non sé­quen­tiels dans le diagramme de com­mu­ni­ca­tion.

La notation UML pour les dia­grammes de com­mu­ni­ca­tion prescrit un cadre de diagramme de séquence simple : un rectangle avec une étiquette pen­ta­go­nale dans la tête. Dans l’étiquette, la dé­sig­na­tion « sd » indique ce type de diagramme. Notez le nom de l’in­te­rac­tion à côté. Les messages ont ici une forme dif­fé­rente : ils relient les lignes de vie rec­tan­gu­laires (UML : nœuds objets) en lignes droites simples (UML : bords).

Au-dessus, notez l’ex­pres­sion de séquence ainsi qu’une flèche pointant dans la direction du récepteur. La dé­sig­na­tion de séquence a la forme suivante : [Nom entier][Répéter]. L’entier spécifie la hié­rar­chie 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, re­pré­sente des émissions si­mul­ta­nées. Deux messages avec la dé­sig­na­tion de séquence 1.2.3a et 1.2.3b sont envoyés si­mul­ta­né­ment par le système en raison du nombre entier identique. La ré­pé­ti­tion comprend soit une res­tric­tion 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 com­por­te­ment 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
• cor­ro­bo­rer une af­fir­ma­tion.

Une garde est donc une res­tric­tion. Ce n'est que si la res­tric­tion est respectée que l'élément influencé peut exercer un certain com­por­te­ment. Il y a beaucoup d'élé­ments dif­fé­rents qui peuvent avoir une telle garde : actions, attributs, com­por­te­ments et autres. UML ne prescrit pas un langage strict, mais offre OCL, le langage de con­trainte objet, comme option native. Les variables boo­léennes sont aussi souvent utilisées.

Une res­tric­tion d’in­te­rac­tion est cons­ti­tuée d’une telle ex­pres­sion booléenne. La res­tric­tion sert de garde pour l’opérande dans un fragment combiné. Ce n’est que si la valeur de la con­trainte est vraie que le fragment d’in­te­rac­tion qui l’entoure commence son com­por­te­ment. Notez la res­tric­tion entre crochets sur la ligne de vie au-dessus d’une spé­ci­fi­ca­tion d’exécution. La stan­dar­di­sa­tion permet de combiner des fragments sans res­tric­tion d’in­te­rac­tion. Dans ce cas, le système suppose que les messages entrants sont vrais.

Comme les avantages de l’in­te­rac­tion se réfèrent à d’autres dia­grammes, ces facteurs externes dé­ter­mi­nent leur com­por­te­ment. Alors que l’in­te­rac­tion est liée à des portes formelles, l’in­te­rac­tion de référence l’est à la porte réelle.

La dé­com­po­si­tion partielle est la dé­com­po­si­tion partielle et sé­quen­tielle d’une ligne de vie dans une in­te­rac­tion par une autre in­te­rac­tion. Avec une telle dé­com­po­si­tion, vous pouvez séparer les détails les uns des autres et ainsi examiner de plus près les dif­fé­rentes sous-fonctions. Si une nouvelle arrive ou émane de la ligne de vie dé­com­po­sée, elle est con­si­dé­rée comme une porte réelle. Celles-ci sont liées aux portes formelles de l’action de dé­com­po­si­tion. Les portes et les pa­ra­mètres des deux éléments doivent cor­res­pondre. La dé­com­po­si­tion partielle reçoit également le label « ref » comme un bénéfice d’in­te­rac­tion et est définie par l’in­te­rac­tion associée.

Le début et la fin marquent le début et la fin de la spé­ci­fi­ca­tion de l’événement. Au début d’une ac­ti­va­tion il y a l’événement de début, à la fin, il y a l’événement de fermeture. Ces fragments re­pré­sen­tent chacun un moment unique et existent sur une seule ligne de vie. La spé­ci­fi­ca­tion de l’événement re­pré­sente le début ou la fin d’une action. La spé­ci­fi­ca­tion 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’ac­ti­va­tion n’a pas de notation séparée. Elle existe im­pli­ci­te­ment sur les bords ex­té­rieurs du rectangle de la spé­ci­fi­ca­tion d’exécution. Si la spé­ci­fi­ca­tion d’exécution passe par une action atomique, les as­so­cia­tions initiales et finales se réfèrent à la même spé­ci­fi­ca­tion d'ap­pa­rence. Vous pouvez le mettre en évidence avec une ligne de connexion entre l'action et la spé­ci­fi­ca­tion d'ap­pa­rence entrante.

Alors que les autres spé­ci­fi­ca­tions d’apparence n’exigent pas de notation, marquez la spé­ci­fi­ca­tion d’apparence du message Des­truc­tion avec un grand X. Il marque la ré­so­lu­tion d’une instance d’objet à un certain point de la ligne de vie. La ligne de vie s’arrête là. Les instances su­bor­don­nées ou les spé­ci­fi­ca­tions d’apparence à des moments ul­té­rieurs de la ligne de temps sont alors invalides. Car après la des­truc­tion de l’objet, elles n'’xistent plus non plus.

Parfois, les spé­ci­fi­ca­tions d’exécution se che­vauchent. Par exemple, lorsqu'un objet s'envoie un message à lui-même, une spé­ci­fi­ca­tion d'exé­cu­tion envoie un message à une autre instance de cette classe. Les deux spé­ci­fi­ca­tions sont en partie sur la même ligne de vie en même temps. Dans le diagramme de séquence UML, vous re­pré­sen­tez cette situation avec des rec­tangles qui se che­vauchent.

L’invariant d’état spécifie une valeur res­tric­tive. Si cette valeur est égale à l’état de l’objet, la piste est con­si­dé­rée comme valide. Si l'objet ne répond pas à la res­tric­tion, sa piste est invalide.

Selon la notation du diagramme de séquence UML, l'in­va­riant d'état est soit entre accolades bouclées sur la spé­ci­fi­ca­tion d'exé­cu­tion, soit vous utilisez le rectangle arrondi de la classe Etat.

Les fragments combinés ap­par­tien­nent aux fragments d’in­te­rac­tion. Ces fragments sont des éléments abstraits du système. Ils re­pré­sen­tent les unités d'in­te­rac­tion. Cela signifie que, d'une part, ils font partie d'une in­te­rac­tion. D’autre part, il s’agit également de petites in­te­rac­tions. Les fragments combinés dans un diagramme de séquence dé­ter­mi­nent le com­por­te­ment de plusieurs fragments d'in­te­rac­tion. Mais ils ne forment eux-mêmes que le cadre. Ils sont définis par des opé­ra­teurs d'in­te­rac­tion et des opérandes d'in­te­rac­tion. Les opérandes con­tien­nent un ou plusieurs messages. Sur la ligne de vie devant un fragment combiné, une res­tric­tion, également appelée garde, veille sur les opérandes contenues.

Comme déjà décrit, les opérandes sont des quantités cons­tantes ou variables qui passent par un processus. Les opé­ra­teurs in­fluen­cent le com­por­te­ment 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é­ci­fique est envoyé sous certaines con­di­tions. 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é­ra­teurs d’in­te­rac­tion.

Al­ter­na­tive :

Dans le fragment combiné avec l'opé­ra­teur d'in­te­rac­tion « Al­ter­na­tive », un fragment enfant ne peut envoyer un message que si une certaine condition est remplie. Sinon, un fragment con­cur­rent à l'in­té­rieur de la trame enverra son message. L'image ci-dessus montre un exemple d’un fragment combiné avec l'opé­ra­teur « Al­ter­na­tive ». Utilisez l'abré­via­tion « alt » pour l'éti­quette. Divisez le cadre rec­tan­gu­laire par une ligne poin­til­lée ho­ri­zon­tale. La partie su­pé­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 con­di­tions. Sinon, il envoie un message dans la zone de l'al­ter­na­tive. Un opérande à l'in­té­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 re­pré­sente toujours une décision entre les deux.

Option :

Ce fragment combiné est modélisé dans le diagramme de séquence comme l'al­ter­na­tive. 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 al­ter­na­tive, par contre, est vide. Un fragment avec l’opérateur d'in­te­rac­tion « Option » est marqué avec l’étiquette « opt ».

In­ter­rup­tion :

Un fragment combiné avec l’opérateur d’in­te­rac­tion « break » in­ter­rompt 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 cor­rec­te­ment détruite. Si le fragment de rupture manque de garde, la décision n'est pas dé­ter­mi­niste. Nous vous re­com­man­dons donc d’utiliser un pro­tec­teur.

Au guichet au­to­ma­tique, 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 cor­res­pon­dantes. L'éti­quette 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é­ti­tions est dépassé, la boucle est également relâchée, mais le processus est in­ter­rompu 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'in­te­rac­tion, utilisez-le pour modéliser le com­por­te­ment de la suite. Si la suite se trouve à la fin de votre fragment d’in­te­rac­tion, 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 cor­res­pond à une suite à la fin du fragment.