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.
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é.
Les diagrammes de séquence supportent les analyses logiques pour certaines parties des systèmes. Si la séquence temporelle des processus joue un rôle important, ce type de diagramme est alors parfaitement adapté pour cela. Mais il n'est pas logique de représenter un système entier avec lui. Au lieu de cela, il est préférable de se référer à un diagramme de comportement approprié tel que le diagramme de cas d’utilisation, le diagramme d’état ou le diagramme d’activité à un emplacement favorable. Elles illustrent également des contextes plus larges d’une manière claire et facilement compréhensible
Un diagramme UML devrait aider toutes les parties impliquées à mieux comprendre les systèmes complexes. Le langage de modélisation utilise à cet effet des symboles visuels. UML peut être adapté pour des cas exceptionnels et certains groupes d’applications. Cependant, il est utile d’utiliser la plupart du langage fourni par le OMG (Object Management Group). Sinon, cela peut facilement entraîner des problèmes de compréhension. Les spécifications suivantes correspondent au standard UML de la version UML 2.5.
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 lamultiplicité n’est jamais >1.
Un opérande en informatique est un objet influencé par un opérateur. Les opérandes peuvent être constantes ou variables. Un opérande simple, par exemple, est la variable X. Les opérateurs peuvent être de simples opérateurs arithmétiques comme « + » et « -» . Dans la programmation, ces composants sont utilisés pour des fonctions simples comme « x = t * 4 » jusqu'à des algorithmes sophistiqués.
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 :
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 :
Le message est un élément de base du diagramme de séquence. Dans la programmation orientée objet, un système est constitué d’objets. UML présente ces objets comme des nœuds reliés par des bords. En UML, ces bords exécutent diverses tâches. Dans le diagramme de séquence UML, ils modélisent les messages des métaclasses. La notation prescrit une ligne comme forme de base du bord. Les flèches sont une forme spéciale de bords qui représentent une relation directionnelle ou un flux d'informations. Dans le diagramme de séquence, ils symbolisent les messages. Différents types de messages sont affichés différemment, comme le montre la figure ci-dessous.
Ajoutez une étiquette au message qui indique son contenu. Pour les messages simples, utilisez le formulaire suivant :
[nom du message] : [attribut « = »] nom du signal ou nom de l'opération [arguments] [« : » valeur retournée]
Les arguments valables pour les nouvelles sont :
Les messages ont une signature. Ceci spécifie le contenu du message. La signature fait référence à un signal ou à une opération et doit être nommée d’après lui. Cela signifie que le contenu du message déclenche une opération (c’est-à-dire une activité) chez le destinataire ou envoie un signal, c'est-à-dire n’échange que des informations. De plus, les messages diffèrent selon qu'ils sont synchrones ou asynchrones. Avec les messages asynchrones, l´’expéditeur n’attend pas de réponse, mais reprend son comportement immédiatement. Les messages synchrones attendent une réponse et bloquent le canal sur lequel ils sont envoyés aussi longtemps.
Il s’agit des types de message standardisés dans le diagramme de séquence UML :
Les messages de n’importe quel type peuvent manquer à l’expéditeur ou au destinataire ou être inconnus. Le standard UML suppose alors que l’instance respective se trouve en dehors du diagramme décrit. Si vous connaissez le destinataire mais pas l’expéditeur, le message est trouvé. Là où vous modéliseriez autrement l’expéditeur, un petit cercle rempli signale son absence. C'est exactement le contraire qui se produit avec le message perdu. Si vous ne connaissez pas le récepteur, modélisez un cercle rempli sur la pointe de la flèche.
Ces messages, qui sont envoyés sur leur propre ligne de vie, constituent une forme spéciale. La ligne de vie envoie ensuite la récursivité à partir d'une barre d'activité. Pendant que l'activation est toujours en cours, une nouvelle activation démarre sur la même ligne de vie. Son point de départ est le message envoyé. Vous utilisez ce type de message, par exemple, si une opération est exécutée plusieurs fois et que l'objet doit donc se référer à lui-même. Les messages entre deux lignes de vie peuvent également provoquer des activations qui se chevauchent. Ci-dessous, nous entrerons plus en détail dans les spécifications des activations.
Une autre partie importante du message est son paramètre. Les paramètres sont des spécifications de valeur. Le système évalue cette taille lorsqu’il envoie un message avec une signature. Cela se produit au moment de la spécification d’apparence, c'est-à-dire au moment où le message est envoyé. Le résultat spécifie les valeurs pour les attributs de signal ou les paramètres d’entrée de l’opération, en fonction de l’identité du récepteur. L’opération traite ensuite la valeur et produit un paramètre de sortie.
Une caractéristique spéciale est le paramètre wildcard. Si tous les paramètres sont manquants, la syntaxe nécessite une chaîne vide. Ce symbole indique que la valeur du paramètre n’est pas fixe. Néanmoins, elle est valable au sens des paramètres ou attributs du récepteur. Donc il agit comme un joker. Les caractères génériques sont des caractères de remplacement pour des lettres simples ou des chaînes entières. Beaucoup connaissent l’astérisque (*) comme un caractère de remplissage. En UML, le tiret (« - » ) représente le paramètre wildcard.
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 ».
Les paramètres IN, OUT et INOUT indiquent si une instance accepte ou retourne des valeurs. Le paramètre IN indique qu'une instance reçoit et traite des valeurs, mais ne les envoie pas. Le paramètre OUT spécifie qu’il n’assume pas de valeurs, mais seulement qu’il les édite. Le paramètre INOUT permet les valeurs entrantes et sortantes. Si vous ne définissez aucune de ces valeurs, le système prend IN comme valeur par défaut.
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 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 :
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 :
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.
Lorsque vous créez un diagramme de séquence, les lignes de vie et les messages sont les composants les plus importants. UML2 recommande un cadre pour ce type de diagramme. Mais il n’est pas obligatoire. Le cadre limite un sous-processus, ce qu’on appelle le fragment d’interaction. Toutes les lignes de vie et tous les messages nécessaires sont dans le cadre. Il se compose d’un rectangle avec une étiquette dans le coin supérieur gauche. La caractéristique d’un diagramme de séquence est l’abréviation sd, qui est généralement en gras. Entrez à côté le nom de l’interaction, comme vous pouvez le voir dans l’image ci-dessous.
En plus de la limitation optique, le cadre sert également à des aspects fonctionnels. Si vous créez plusieurs diagrammes de séquence (ou d'autres interactions), le cadre délimite ces représentations les unes des autres. Si vous voulez montrer que les différents fragments d'interaction communiquent entre eux, modélisez un message (flèche remplie) sur la ligne du cadre. En haut de l’écran, le système envoie le message 5 vers l'extérieur. Le point où la flèche rencontre le cadre est appelé la porte. Cet élément a une fonction dans le diagramme, mais n’a pas sa propre notation.
Les fragments d’interaction appartiennent aux nœuds en UML. Ce terme générique est très général. Les propriétés et les tâches des nœuds sont spécifiées par UML en fonction du type de diagramme dans lequel un nœud particulier apparaît. En général, les nœuds sont des éléments de modèle au sein d’un système ou d’un processus sur lesquels un artefact peut être installé. Le nœud connecte UML avec les bords. Les bords représentent graphiquement l’échange d’informations par des flèches ou des lignes simples.
En UML, vous pouvez créer des diagrammes de séquence qui contiennent des sous-segments imbriqués. Les cadres permettent d’afficher les fragments individuels de manière ordonnée
Les diagrammes de séquence peuvent contenir l’utilitaire d’interaction des fragments d’interaction, les invariants d’état, la spécification des occurrences d’événements, la spécification d’exécution et les fragments combinés.
Les avantages de l’interaction forment une sous-classe qui définit la notation, la structure et le comportement de deux métaclasses. Ces métaclasses sont des avantages d’interaction et de décomposition partielle.
L’utilitaire d’interaction en tant que métaclasse est un fragment d’interaction qui appelle ou utilise une autre interaction. Si votre diagramme de séquence devient trop complexe, utilisez cette référence pour le rendre plus clair. Vous pouvez voir l’interaction à laquelle l’avantage de l'interaction se réfère dans le diagramme actuel dans une vue boîte noire. Pour identifier de façon univoque l’interaction appelée, spécifiez la syntaxe suivante dans le corps (zone dans laquelle les instances effectuent les opérations) :
Modélisez l’utilitaire d’interaction comme un rectangle avec une étiquette pentagonale dans le coin supérieur gauche. Entrez l’abréviation « ref » (de l’anglais : « referral »).
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.
La barre d’activité, en anglais Execution Specification, représente le temps sur une ligne de vie dans laquelle un objet exécute un comportement ou passe par une action. En outre, vous modélisez le temps pendant lequel un objet impliqué envoie un message ou attend une réponse. La barre d’activité représente une période de temps abstraite pendant l’exécution. Comme c’est vrai pour l’ensemble du diagramme de toute façon, le temps n’est pas une quantité absolue, mais relative. Les comportements passifs tels que l’attente d’une réponse doivent également être saisis en tant qu’activation dans le diagramme de séquence.
La sémantique de trace d’une spécification d’exécution représente UML par sa structure simple. La notation de la spécification d’exécution permet deux formes. Modeler un carré long et étroit avec remplissage gris sur la ligne de vie. Normalement, l’activation sous cette forme n’inclut pas d’étiquette dans le corps. Vous pouvez aussi dessiner un rectangle légèrementplus large, rempli de blanc, sur la ligne de vie. Là, vous avez de l’espace pour étiqueter la barre d’activités. Si un objet exécute une action au moment de l’exécution, spécifiez le nom de l'action.
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.
Une action atomique apparaît comme une boîte noire (Blackbox). Il s’agit d’une séquence indivisible de plusieurs opérations simples qui ne peuvent être observées parce qu’elles sont exécutées extrêmement rapidement. Une action atomique apparaît donc immédiatement terminée.
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 est une restriction d'exécution. La ligne de vie représente un objet. Pendant la durée d'exécution, cet objet modifie son état à la suite de la spécification d'exécution. L’invariant d’état examine l'objet par rapport à son changement d'état dans la spécification d'exécution, directement avant d'exécuter la spécification d'apparence suivante. Toutes les actions implicites précédentes dans la spécification d'exécution sont alors considérées comme exécutées.
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.
Non-déterminisme est un concept en informatique théorique qui est censé simplifier la modélisation. Si la valeur initiale est la même, un système a plus d’une façon d’obtenir un résultat. Dans la pratique, on utilise principalement des algorithmes déterministes avec un seul chemin de calcul. Un algorithme non déterministe, par contre, suit un chemin imprévisible dans le calcul, même si vous lancez le système avec les mêmes spécifications. Puisque l'algorithme produit habituellement beaucoup plus de résultats différents qu'un algorithme déterministe, la tâche devrait être moins complexe. Les modèles abstraits simplifient les systèmes complexes. Par conséquent, ils sont appropriés pour jouer à travers différents calculs avec l'algorithme non déterministe.
La proue :
Un fragment combiné avec l'opérateur d’interaction « loop » répète son opérande. La Garde détermine le nombre exact de descentes. Cette garde peut inclure des limites de répétition et des variables booléennes. Notez les barrières de répétition sur l'étiquette du cadre comme suit : boucle (X,Y). Les variables X et Y représentent chacune un nombre naturel. X est le nombre minimum de répétitions (« min-int »). Y est le nombre maximum de répétitions (« max-int »). X doit être un nombre non négatif, Y un nombre non négatifégal ou supérieur au minimum (c’est-à-dire > 0).
Vous pouvez éventuellement noter la variable booléenne dans le corps du cadre à côté de l'étiquette. Cela restreint encore plus la répétition. Si la condition de la variable booléenne n'est plus remplie et que le nombre minimum de répétitions est atteint, la boucle s’arrête. Notez la restriction entre crochets. Cette restriction se réfère à des facteurs externes tels que l’apport d’un acteur.
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.
Si vous ne spécifiez pas de barrières de répétition, le minimum est 0 et le maximum est infini. Si vous spécifiez une seule barrière, le minimum et le maximum ont la même valeur.
Parallèle :
Normalement, la position d'une flèche sur la ligne de vie dans le diagramme de séquence prescrit toujours un ordre chronologique. Dans un fragment combiné avec l'opérateur d'interaction Parallèle, ses opérandes peuvent exécuter leurs processus simultanément. Potentiellement, les opérandes entremêlent leurs règles de procédure. Toutefois, l'ordre donné dans les opérandes est toujours maintenu. Dans le diagramme de séquence UML, vous modélisez ce fragment combiné avec une trame continue. Séparez optiquement les différents opérandes par des lignes pointillées, comme dans l'alternative. Inscrivez l'abréviation « par » sur l’étiquette. Si les opérandes doivent travailler en parallèle sur une seule ligne de vie, UML permet une abréviation : la co-région remplit exactement cette tâche. Pour ce faire, il suffit de combiner les occurrences d’événements affectées avec un crochet.
Section critique :
À l’aide d'une section critique, le système évite les erreurs qui peuvent survenir lorsque plusieurs processus partagent des ressources. Dans ce domaine système, un seul processus à la fois utilise la ressource. En outre, le système hiérarchise le processus correspondant. Avec l’étiquette « critical », vous définissez une section critique (anglais : Critical Region). Ceci empêche les autres opérateurs d'interaction d'influencer un fragment parent. Par exemple, il bloque les traces imbriquées d'un fragment parallèle et combiné dans le diagramme de séquence.
Une hotline d’un fournisseur de gaz accepte plusieurs appels en parallèle dans le graphique du haut et les transmet simultanément aux employés de la hotline. Cependant, s'il s’agit d’une situation d’urgence avec odeur de gaz suspectée, le système priorise le message et transmet l’appel au service d’urgence via la section critique. La section critique empêche les flux d'informations provenant du fragment parent d'être traités en parallèle avec le message de la section critique. Seules les lignes de vie de la section critique se comportent de cette façon.
Affirmation :
L’opérateur d’interaction « assertion » définit l’état des suites. Les séquences à l’intérieur d’un opérande avec l’assertion d'étiquette sont considérées comme des suites valides. L'assurance prétend que toutes les séquences en dehors du fragment se terminent par des traces non valides.
Ignorer/Considérer :
Un diagramme de séquence UML décrit en détail une partie du système. Vous n’avez pas besoin de certains messages pour les voir. Avec l'opérateur d'interaction « ignore », vous excluez certains messages. Cette information apparaît dans le système sur une piste, mais pas dans le fragment ignorer. La notation prescrit une étiquette sous cette forme : ignore {message1,message2}.
Les fragments combinés avec l'opérateur d'interaction « consider », d'autre part, considèrent certains messages dans un fragment. Tous les autres messages passant par le fragment sont ignorés par le système. Placez également les messages entre parenthèses : considérez {message3,message4}.
Ces deux opérateurs ont des tâches contradictoires. Cependant, les deux se rencontrent fréquemment dans des fragments imbriqués. Par exemple, les modélisateurs combinent souvent assert avec ignore (sous cette forme : assert ignore {Msg1, Msg2}) ou assert and consider (sous cette forme : assert consider {Msg3, Msg4}).
Négatif :
Pour indiquer une erreur système, utilisez l’opérateur d’interaction « négatif ». Le fragment combiné contient donc des traces non valides. L’opérateur est utilisé, par exemple, lorsque vous affichez une procédure de connexion à l'aide d'un diagramme de séquence. Modéliser la ligne de vie d'un acteur sur le chemin du time-out, encadrer ce message d'erreur avec le fragment négatif. En raison de la modélisation explicite des traces invalides dans le fragment combiné négatif, tous les autres fragments sont considérés comme positifs. Vos traces sont valides.
Séquençage strict :
Dans un fragment combiné, il peut être important de maintenir un ordre strict. Le label impose un séquençage strict de ses opérandes. Ceci s'applique au premier niveau du fragment. Les opérandes dans d’autres fragments imbriqués sont soumises à leur propre ordre.
Séquençage faible :
Les fragments combinés avec l'opérateur d'interaction « séquence » représentent un ordre faible. Le comportement entre les opérandes du fragment influence les propriétés de la trace au lieu des opérateurs d'interaction. Ainsi, un séquençage faible peut agir comme un fragment parallèle. Cela se produit lorsque les opérandes participent sur des lignes de vie différentes. En retour, le faible séquençage se transforme en un ordre strict lorsque ses opérandes apparaissent sur la même ligne de vie. L'étiquette est seq.
Les pistes avec les propriétés suivantes définissent le faible séquencement :
Suite :
La suite n’est guère un fragment indépendant. Ce n’est que dans la séquence alternative et faible des fragments combinés qu’elle reçoit sa propre sémantique. Cette disposition prescrit la même forme pour la continuation que pour les États : un rectangle aux coins arrondis. À la différence de l’état, une continuation couvre facultativement plusieurs lignes de vie.
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.
Si vous souhaitez afficher des exemples d’application en détail ou vérifier la logique d'un système, créez un diagramme de séquence. La notation vous permet de modéliser le flux de messages sur toute la durée de vie d'un objet. Même les opérations complexes peuvent être affichées clairement à l’aide de fragments d’interaction imbriqués. Le diagramme de séquence n’est pas sans raison l’un des diagrammes de comportement UML les plus utilisés.
Si vous avez besoin d’effectuer une programmation orientée objet, de représenter clairement un système et de le rendre accessible à des spécialistes externes, le langage Universal Modeling Language peut vous sembler idéal. UML est un langage de modélisation, mais a beaucoup d’autres utilisations possibles. Depuis l’introduction d’UML 2.0, les diagrammes UML sont également adaptés à la...
Les diagrammes d’activité UML vous permettent d’afficher sous forme de graphique la séquence chronologique des processus système dans la programmation orientée objet. Les diagrammes d’activité montrent quelles actions ont lieu dans quel ordre pour exécuter une activité. Avec un diagramme terminé, vous pouvez créer des blocs de codes à l’aide du transfert XML. Souhaitez-vous cartographier les...
Comparer les outils UML : vous cherchez le meilleur outil de modélisation UML ? Ou avez-vous besoin d’un simple outil pour dessiner des schémas et les partager rapidement avec votre équipe ? Les programmes UML sont très variés. Que vous souhaitiez utiliser un outil UML gratuitement ou que vous soyez à la recherche d’une solution complète pour entreprise : voici les points importants et la...
Les diagrammes de classes appartiennent aux diagrammes de structure du langage de modélisation UML. Le diagramme de classes UML est donc adapté à la visualisation des éléments du système et de leurs dépendances pour les langages de programmation orientés objet. Il est avantageux de respecter la notation et la sémantique officielle, nous l’expliquons à l’aide d’exemples et présentons les différents...
Offrez un service performant et fiable à vos clients avec l'hébergement web de IONOS.
Voir les packs
