Diagrammes d’activité : une présentation claire des séquences chronologiques d’activités avec UML

UML 2 spécifie une activité comme un comportement qui place des unités subordonnées (actions et objets) dans un ordre. Il utilise à cette fin des modèles de flux de données et de contrôle. Le diagramme d’activité peut être affiché en tant qu’élément d’un système plus large en conjonction avec d’autres types de diagramme. Un grand rectangle arrondi marque l’activité comme un système fermé (il peut aussi être omis). Dans l’exemple ci-dessous, vous pouvez voir l’activité « Cuisiner des asperges ». Inscrivez le titre dans la tête du grand rectangle. Le corps contient à son tour des bords (flèches) et des nœuds (rectangles). Ceux-ci symbolisent les actions détaillées, les objets et les flux de contrôle ou de données de l’activité.

Les données n’entrent une action (épingle d’entrée) ou un résultat (épingle de sortie) que si les conditions spécifiées sur les épingles sont remplies. Même si une action a plusieurs flux de contrôle entrants, chacun doit offrir un jeton avant qu’une action ne commence.

Pour les actions dans un diagramme d’activités, la syntaxe abstraite contient la forme simple du rectangle arrondi. Cependant, il existe des actions spécifiques que les modélisateurs peuvent utiliser pour des descriptions plus détaillées. Certains d’entre eux expriment UML avec leur propre notation. Ce sont les sous-catégories d’actions :

1. Les actions opaques (opaque actions) agissent comme des caractères génériques ou sont spécifiés par une syntaxe texte concrète (non définie par UML).
2. Les invocation actions sont des actions qui provoquent un certain comportement, directement ou indirectement. Ceci inclut :

• les Call-Actions : celles-ci suscitent directement un comportement, ou envoie une requête à un objet qui appelle un comportement associé. L’action peut aussi amener directement un objet à exécuter son comportement d’instance. Si aucun n’est défini, il peut déclencher le comportement de classe supérieur (comportement classifier).

La notation d’une action qui provoque un comportement consiste en un rectangle. Entrez le nom du comportement à susciter. Les actions de comportement d’appel sont également marquées d’un symbole de trident, comme le montre l’image ci-dessous. Il s’agit de représenter le branchement hiérarchique supplémentaire créé par l’action.

• les Send-Action : dans le diagramme d’activités, ces actions envoient toujours des données de manière asynchrone (les diagrammes de séquence connaissent aussi les messages synchrones, par exemple). Cela signifie qu’ils n’attendent pas de réponse de l’objet cible et ne bloquent donc pas le flux d’objets. L’action se termine dès que le message a été envoyé. Il peut donc avoir une entrée d’argument, par exemple des paramètres, mais ne produit pas de sortie de résultat. De plus, les messages peuvent être envoyés à plusieurs destinataires en même temps. L’action d’envoi de signal, l’action de diffusion de signal et l’action d’envoi d’objet appartiennent à ce type.

Les actions du signal d’envoi s’écartent dans leur notation de la forme habituelle (le rectangle). Au lieu de cela, un pentagone pointe dans la direction du signal transmis comme une grande flèche. Si le contenu d’une action d’objet d’envoi consiste également en un signal, vous pouvez utiliser la même notation.

3. Object-Actions : elles changent l’état des objets (instances d’une classe). Vous pouvez les créer ou les détruire, les comparer à d’autres instances, les lire, puis les affecter à une classe ou modifier la classification. Les instances suivantes d’actions objet existent donc sous UML 2 :

• Les Create-Object-Actions génèrent des instances d’une classe, c’est-à-dire des objets.
• Les Destroy-Object-Actions détruisent l’objet sur votre épingle d’entrée.
• Les Test Identity Actions examinent si deux valeurs sur votre épingle d’entrée représentent le même objet.
• Les Read-Self-Actions déterminent leur propre objet contextuel.
• Les Value-Specification-Actions examinent les spécifications de valeur. La notation porte la spécification de la valeur de l’étiquette.
• Les Read-Extent-Actions trouvent tous les objets d’une classe ainsi que les objets de ses spécifications. Pour des raisons pratiques, les modélisateurs limitent généralement la portée.
• Les Reclassify-Object-Actions changent la classe de l’objet sur votre broche d’entrée.
• Les Lecture-Is-Classified-Object-Actions déterminent si un objet sur votre broche d’entrée appartient à une classe.
• Les Start-Classifier-Behavior-Actions déclenchent un comportement pour un objet qui est déterminé par sa classe. Le comportement est alors asynchrone.

4. Les Link-Actions modifient le comportement des associations (relations entre les classificateurs, généralement deux classes) et leurs instances, les liens. Ceci inclut :

• Les Read-Link-Actions qui récupèrent des valeurs (données de fin de lien) sur une page d’une association.
• Les actions Create-Link qui créent des liens (elles n’ont pas d’épingles de sortie car les liens ne sont pas des données en soi) et lient des objets.
• Les Destroy-Link actions de lien supprime les liens et connecte les objets s’ils correspondent à une valeur de données de fin de lien spécifiée.

5. Les Link-Object-Actions influencent le comportement des objets liés de la même manière que les link actions, mais en considérant les objets de différents points de vue. Ce sont des instances d’actions d’objets de lien :

• Les actions Read-Link-Object-End récupèrent les objets finaux des objets de lien.
• les actions Read-Link-Object-Object-End-Qualifier récupèrent les valeurs finales du classificateur des objets liés.
• Les actions Create-Link-Object sont des actions spéciales Create-Link avec lesquelles vous pouvez créer des objets de lien.

6. Les actions Structural-Feature déterminent le comportement des caractéristiques structurelles dans les diagrammes d’activité. Pour cela, ils ont besoin d’une épingle d’entrée, car on leur affecte généralement à la fois un objet et une caractéristique structurelle spécifiée statiquement d’un classificateur. L’action des caractéristiques structurelles affecte les deux éléments. Les types suivants existent :

• les actions Read-Structural-Feature lisent les valeurs des caractéristiques structurelles et les transmet en sortie.
• les actions Add-Structural-Feature-Value nécessitent une épingle d’entrée de valeur. Elles spécifient la valeur que l’action affecte à une caractéristique structurelle.
• Les actions Remove-Structural-Feature-Value soustraient une valeur d’une caractéristique structurelle. Une broche d’entrée de valeur avec multiplicité 1...1 spécifie cette valeur.
• les actions Clear-Structural-Feature suppriment toutes les valeurs d’un élément structurel.

7. Les actions Variable influencent des variables spécifiées statiquement qui sont définies par une activité ou un nœud d’activité structuré. Il en existe trois types :

• Les actions Add-Variable-Value nécessitent également une épingle d’entrée de valeur. Elle doit être du même type que la variable et ajouter exactement une valeur à celle-ci.
• Les actions Remove-Variable-Value suppriment une valeur spécifiée par une épingle.
• Les actions Clear-Variable suppriment toutes les valeurs d’une variable.

8. Les Actions Accept-Event appartiennent à ce qu’on appelle les wait points. Cela signifie que l’action attend un événement (event) du pool d’événements de l’objet de contexte. L’action nécessite des triggers, c’est-à-dire des déclencheurs qui provoquent l’action lorsqu’un ou plusieurs états prescrits se produisent. UML distingue trois spécialisations :

• Les actions Accept-Call ont un déclencheur qui accepte les événements d’appel. Deux épingles de sortie des résultats et une épingle de sortie des informations de retour complètent l’ensemble. Si une action de réponse doit être exécutée, les informations nécessaires à cette action sont stockées dans l’épingle de sortie des informations de retour.

9. Les Structured Actions déclarent UML 2 dans le diagramme d’activité à la fois comme une action et comme un groupe d’activités (voir ci-dessus). Cela signifie d’une part que leur comportement est déterminé par les nœuds d’activité et les bords, d’autre part que certains sous-types de ces actions prescrivent un certain comportement pour les nœuds exécutables en raison de leur sémantique, notamment en ce qui concerne leur séquence.

Voici les sous-types des actions structurées :

• Les Conditional Nodes (nœuds conditionnels) consistent en une ou plusieurs clauses qui représentent les différentes branches des actions exécutables possibles. Une clause contient un segment de test et un segment de corps, qui contiennent à leur tour des nœuds exécutables sans coupure. Tout d’abord, la clause exécute l’action dans la zone de test. Si sa valeur de sortie est exacte, la clause exécute l’action dans la zone de corps.
• Les Loop nodes (nœuds boucles) correspondent à un groupe d’actions qui se répètent dans une boucle. Les actions sont divisées en trois sections : setup (configuration), test et body (corps). La boucle exécute toujours la configuration en premier. Ensuite suivent Test ou Body, qui se répètent ensuite en alternance.
• Les Sequence Nodes (nœuds séquence) imposent une séquence aux nœuds exécutables à l’intérieur de leurs limites. Vous les représentez avec des flux de données en tant que bords d’activité (flèches simples). Les bords peuvent s’orienter librement à l’intérieur et à l’extérieur de la structure.

10. Les Expansion Regions constituent une autre forme de nœuds d’activité structurés. Elles acceptent un ou plusieurs ensembles de valeurs comme entrées. Sur son chemin vers la zone d’expansion, la broche d’entrée copie chaque jeton entrant dans le nombre d’éléments de collection. Tous les nœuds internes parcourent chaque valeur de la collection. Une passe est considérée comme une exécution d’expansion (expansion execution).

Un nœud d’expansion (un type de nœud objet) indique l’interface de la région d’expansion. En externe, vous affichez vos valeurs en tant que collection ; en interne, les éléments individuels de la collection sont considérés comme des valeurs. Pour la notation, dessinez un rectangle arrondi avec une ligne pointillée. Les nœuds d’expansion apparaissent sous forme de rectangles avec des segments et, comme indiqué ci-dessous, sont dessinés directement sur la ligne. La segmentation est destinée à représenter la liste des collections de valeurs.

Les nœuds d’objet sont des sous-types de nœuds d’activité. En général, un objet en UML est la plus petite instance avec des valeurs. Les objets représentent les données dans le diagramme d’activités. Pendant l’exécution d’une action, les nœuds d’objet contiennent ces données. Seuls les jetons de contrôle peuvent passer directement par une action. Les jetons d’objet, d’autre part, sont reçus en tant que valeur par une broche d’entrée et sont transmis de la broche de sortie au flux de l’objet.

Les nœuds objets ont été introduits pour la première fois dans le diagramme d’activité UML-2. Ce sont des éléments dactylographiés. Si un nœud d’objet correspond à un certain type, les jetons d’objet qui se déplacent sur lui doivent avoir des valeurs correspondantes. Les jetons nuls, qui n’ont pas besoin d’une valeur, constituent une exception : ils sont conformes à chaque nœud d’objet.

Les nœuds d’objets prescrivent l’ordre dans lequel les jetons les quittent. Il y a quatre façons de procéder :

13. Non commandé (non spécifié)
14. Ordonné (comportement défini par la personne qui modélise)
15. FIFO (First In First Out) : l’ordre d’entrée et de sortie reste le même.
16. LIFO (Last In First Out) : l’ordre est exactement le contraire.

Si vous souhaitez créer un diagramme d’activités, vous pouvez choisir parmi quatre types de nœuds d’objet pour la modélisation :

1. L’épingle (pin) : les épingles ont déjà été coupées dans cette version. Dans le premier graphique, on peut voir la notation de base des épingles. En raison de leur fonction de lien entre les actions et les flux d’objets, les concepteurs les dessinent généralement sous forme de petits rectangles directement sur le symbole d’action. Les broches d’entrée sont marquées par une flèche (c’est-à-dire un bord ou un flux d’objets) dans le sens de l’action. Dans le cas des broches de sortie, la flèche s’éloigne de l’action. Le graphique suivant montre comment raccourcir l’affichage des broches du même type (à gauche) ou comment dessiner les broches d’entrée et de sortie si vous omettez les bords (à droite).

2. Les nœuds de paramètres d’activité : l’activité appartient à la méta-classe de la description du comportement. Selon UML, chaque comportement a des paramètres. Avant qu’un comportement ne soit exécuté, on peut lui affecter des valeurs à traiter. Après le traitement, vous récupérez de nouvelles valeurs. Dans cette structure, les paramètres sont les caractères génériques qui permettent de saisir ou d’éditer ces valeurs. Le nœud de paramètre d’activité fait cela pour le diagramme d’activité UML. Les nœuds de paramètres d’activité se trouvent donc au début et à la fin d’une activité.

Par conséquent, ce type de nœud dispose uniquement de bords d’activité entrants ou sortants. Vous dessinez des nœuds de paramètre d’activité d’entrée avec bords sortants, des nœuds de paramètre d’activité de sortie avec bords entrants. Il existe un nœud de paramètre d’activité pour chaque paramètre, les deux étant du même type.

Dans un diagramme d’activité UML, les jetons parcourent diverses actions jusqu’à ce que l’activité se termine lorsque le premier jeton arrive au nœud final. Comme plusieurs jetons peuvent passer par ce processus en même temps, un certain ordre est nécessaire. Utiliser des nœuds de contrôle pour assurer un déroulement clair du processus. Ceux-ci ne gèrent les flux de contrôle que du début du diagramme d’activité jusqu’à la fin de l’activité, en passant par les actions. Les nœuds de contrôle ne peuvent pas mettre en cache les jetons, contrairement aux nœuds objets comme le nœud tampon.

Une différence significative entre les flux objet et de contrôle est que seuls les jetons de contrôle se déplacent sur les flux de contrôle. Contrairement aux jetons objets, ces jetons ne contiennent pas de données. Ce ne sont que des marqueurs. Par conséquent, les actions n’ont pas besoin de nœuds d’objets (en particulier de broches) pour récupérer les jetons de contrôle et les transmettre. Un jeton de contrôle lance une action, passe à l’action suivante et la met en mouvement. Il contrôle donc l’exécution chronologique de l’activité.

Parmi les symboles du diagramme d’activité UML, les nœuds de contrôle sont probablement les plus divers. Ils appartiennent aux nœuds d’activité. UML 2 distingue six types :

1. Les Initial Nodes démarrent une activité. Il peut y avoir plus d’un nœud de départ par activité. Si une activité démarre, le nœud de départ met immédiatement le flux de contrôle en mouvement. S’il existe plusieurs nœuds de départ, les flux de commande correspondants démarrent simultanément. Les nœuds d’activité structurés peuvent également avoir des nœuds de départ. Ils commencent également dès l’initialisation de l’activité structurée, pour autant qu’aucune condition n’ait été fixée pour leur démarrage. Puisque les nœuds initiaux sont au début, tous leurs bords sont des bords d’activité sortants. Il s’agit toujours de flux de contrôle.

Autre particularité des nœuds de départ : les jetons de contrôle placés sur le nœud de départ au début d’une activité peuvent y rester si le flux de contrôle n’accepte pas ou ne bloque pas le jeton proposé.

2. Les nœuds finaux mettent fin au flux d’une activité. Il existe deux types de nœuds finaux : l’Activity Final Node met fin à toute l’activité en détruisant tous les jetons de l’activité lorsqu’il reçoit le premier jeton. Seuls les jetons d’objet dans la sortie des nœuds de paramètres d’activité sont conservés.

Par ailleurs, toutes les actions synchrones s’arrêtent avec elle. Les actions asynchrones s’exécutent jusqu’à ce qu’elles soient terminées. Les nœuds finaux acceptent tous les jetons entrants. Contrairement au nœud de début, un nœud final n’a que des bords d’activité entrants. Plusieurs nœuds finaux sont possibles.

Si vous dessinez un diagramme d’activités avec plus d’un nœud final, les actions peuvent s’arrêter avant d’avoir atteint leur but, car un jeton a déjà atteint le premier point final. Le Flow Final Node (nœud final de flux) arrête un flux de contrôle et détruit tous les jetons entrants. Ceci n’affecte pas les autres flux de contrôle. Ainsi, ce nœud final est une alternative pratique si vous modélisez plusieurs points finaux dans le diagramme d’activité.

3. Les nœuds de parallélisation et les nœuds de synchronisation (Fork Nodes et Join Nodes), sont des nœuds de contrôle avec une notation presque identique qui reflètent leurs tâches.

Un nœud de parallélisation divise un bord d’activité entrant en plusieurs flux sortants simultanés. Un seul bord d’activité peut entrer dans le nœud de parallélisation. S’il s’agit d’un flux de contrôle, tous les bords sortants sont également des flux de contrôle ; le même principe s’applique aux flux d’objets. Le nœud crée des copies du jeton entrant pour tous les flux sortants. Si un jeton est accepté à la destination du flux sortant, le jeton est supprimé du nœud source. Si une autre cible n’accepte pas son jeton, le nœud de parallélisation peut tenir le jeton en exception jusqu’à ce qu’il soit accepté.

Les nœuds de synchronisation fonctionnent exactement dans l’autre sens. Plusieurs arêtes s’y heurtent, mais une seule d’entre elles s’en détache. Si tous les fronts entrants sont constitués de flux de contrôle, un flux de contrôle quitte également le nœud. S’il n’y a qu’un seul flux d’objets en dessous, UML spécifie le bord sortant comme flux d’objets. Si des jetons de contrôle sont également reçus dans ce cas, ils expireront et seuls les jetons objet expireront. Si deux objets ont la même identité, le nœud les fusionne en un jeton. En général, les jetons ne sortent pas avant tous les bords entrants d’une offre (et d’une opération). Cela se fait selon le principe du First In First Out Si vous affectez une spécification de valeur au nœud de synchronisation à l’aide de joinSpec, le nœud attend les jetons qui remplissent explicitement ces conditions avant d’émettre des jetons.

4. Les Decision Nodes et MergeNodes (nœuds de décision et nœuds de fusion) partagent également le même symbole dans le diagramme d’activités. Le guidage des flux est encore une fois la caractéristique distinctive de ces notations de nœuds.

Un nœud de branchement nécessite au moins un, mais au plus deux bords entrants. L’un s’appelle decision input flow, l’autre primary incoming edge. Le fait que les flux sortants représentent des flux objet ou des flux de commande dépend du type du bord primaire. La tâche du nœud est alors de décider entre les bords sortants. Le nœud offre son nœud entrant sans le copier. Le jeton ne peut donc emprunter qu’un seul chemin.