Dia­grammes d’activité : une pré­sen­ta­tion claire des séquences chro­no­lo­giques d’activités avec UML

UML 2 spécifie une activité comme un com­por­te­ment qui place des unités su­bor­don­né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 con­jonc­tion 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 (rec­tangles). Ceux-ci sym­bo­li­sent les actions dé­tail­lé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 con­di­tions spé­ci­fié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é­ci­fiques que les mo­dé­li­sa­teurs peuvent utiliser pour des des­crip­tions plus dé­tail­lées. Certains d’entre eux expriment UML avec leur propre notation. Ce sont les sous-ca­té­go­ries d’actions :

1. Les actions opaques (opaque actions) agissent comme des ca­rac­tères gé­né­riques ou sont spécifiés par une syntaxe texte concrète (non définie par UML).
2. Les in­vo­ca­tion actions sont des actions qui pro­vo­quent un certain com­por­te­ment, di­rec­te­ment ou in­di­rec­te­ment. Ceci inclut :

• les Call-Actions : celles-ci suscitent di­rec­te­ment un com­por­te­ment, ou envoie une requête à un objet qui appelle un com­por­te­ment associé. L’action peut aussi amener di­rec­te­ment un objet à exécuter son com­por­te­ment d’instance. Si aucun n’est défini, il peut dé­clen­cher le com­por­te­ment de classe supérieur (com­por­te­ment clas­si­fier).

La notation d’une action qui provoque un com­por­te­ment consiste en un rectangle. Entrez le nom du com­por­te­ment à susciter. Les actions de com­por­te­ment d’appel sont également marquées d’un symbole de trident, comme le montre l’image ci-dessous. Il s’agit de re­pré­sen­ter le bran­che­ment hié­rar­chique sup­plé­men­taire créé par l’action.

• les Send-Action : dans le diagramme d’activités, ces actions envoient toujours des données de manière asyn­chrone (les dia­grammes de séquence con­nais­sent aussi les messages syn­chrones, 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 pa­ra­mètres, mais ne produit pas de sortie de résultat. De plus, les messages peuvent être envoyés à plusieurs des­ti­na­taires en même temps. L’action d’envoi de signal, l’action de diffusion de signal et l’action d’envoi d’objet ap­par­tien­nent à ce type.

Les actions du signal d’envoi s’écartent dans leur notation de la forme ha­bi­tuelle (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 clas­si­fi­ca­tion. 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é­trui­sent l’objet sur votre épingle d’entrée.
• Les Test Identity Actions examinent si deux valeurs sur votre épingle d’entrée re­pré­sen­tent le même objet.
• Les Read-Self-Actions dé­ter­mi­nent leur propre objet con­tex­tuel.
• Les Value-Spe­ci­fi­ca­tion-Actions examinent les spé­ci­fi­ca­tions de valeur. La notation porte la spé­ci­fi­ca­tion de la valeur de l’étiquette.
• Les Read-Extent-Actions trouvent tous les objets d’une classe ainsi que les objets de ses spé­ci­fi­ca­tions. Pour des raisons pratiques, les mo­dé­li­sa­teurs limitent gé­né­ra­le­ment la portée.
• Les Re­clas­sify-Object-Actions changent la classe de l’objet sur votre broche d’entrée.
• Les Lecture-Is-Clas­si­fied-Object-Actions dé­ter­mi­nent si un objet sur votre broche d’entrée ap­par­tient à une classe.
• Les Start-Clas­si­fier-Behavior-Actions dé­clenchent un com­por­te­ment pour un objet qui est déterminé par sa classe. Le com­por­te­ment est alors asyn­chrone.

4. Les Link-Actions modifient le com­por­te­ment des as­so­cia­tions (relations entre les clas­si­fi­ca­teurs, gé­né­ra­le­ment deux classes) et leurs instances, les liens. Ceci inclut :

• Les Read-Link-Actions qui ré­cu­pè­rent des valeurs (données de fin de lien) sur une page d’une as­so­cia­tion.
• 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 cor­res­pon­dent à une valeur de données de fin de lien spécifiée.

5. Les Link-Object-Actions in­fluen­cent le com­por­te­ment des objets liés de la même manière que les link actions, mais en con­si­dé­rant les objets de dif­fé­rents points de vue. Ce sont des instances d’actions d’objets de lien :

• Les actions Read-Link-Object-End ré­cu­pè­rent les objets finaux des objets de lien.
• les actions Read-Link-Object-Object-End-Qualifier ré­cu­pè­rent les valeurs finales du clas­si­fi­ca­teur des objets liés.
• Les actions Create-Link-Object sont des actions spéciales Create-Link avec les­quelles vous pouvez créer des objets de lien.

6. Les actions Struc­tu­ral-Feature dé­ter­mi­nent le com­por­te­ment des ca­rac­té­ris­tiques struc­tu­relles dans les dia­grammes d’activité. Pour cela, ils ont besoin d’une épingle d’entrée, car on leur affecte gé­né­ra­le­ment à la fois un objet et une ca­rac­té­ris­tique struc­tu­relle spécifiée sta­ti­que­ment d’un clas­si­fi­ca­teur. L’action des ca­rac­té­ris­tiques struc­tu­relles affecte les deux éléments. Les types suivants existent :

• les actions Read-Struc­tu­ral-Feature lisent les valeurs des ca­rac­té­ris­tiques struc­tu­relles et les transmet en sortie.
• les actions Add-Struc­tu­ral-Feature-Value né­ces­si­tent une épingle d’entrée de valeur. Elles spé­ci­fient la valeur que l’action affecte à une ca­rac­té­ris­tique struc­tu­relle.
• Les actions Remove-Struc­tu­ral-Feature-Value sous­traient une valeur d’une ca­rac­té­ris­tique struc­tu­relle. Une broche d’entrée de valeur avec mul­ti­pli­cité 1...1 spécifie cette valeur.
• les actions Clear-Struc­tu­ral-Feature sup­pri­ment toutes les valeurs d’un élément struc­tu­rel.

7. Les actions Variable in­fluen­cent des variables spé­ci­fiées sta­ti­que­ment 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é­ces­si­tent également une épingle d’entrée de valeur. Elle doit être du même type que la variable et ajouter exac­te­ment une valeur à celle-ci.
• Les actions Remove-Variable-Value sup­pri­ment une valeur spécifiée par une épingle.
• Les actions Clear-Variable sup­pri­ment toutes les valeurs d’une variable.

8. Les Actions Accept-Event ap­par­tien­nent à ce qu’on appelle les wait points. Cela signifie que l’action attend un événement (event) du pool d’évé­ne­ments de l’objet de contexte. L’action nécessite des triggers, c’est-à-dire des dé­clen­cheurs qui pro­vo­quent l’action lorsqu’un ou plusieurs états prescrits se pro­dui­sent. UML distingue trois spé­cia­li­sa­tions :

• Les actions Accept-Call ont un dé­clen­cheur qui accepte les évé­ne­ments d’appel. Deux épingles de sortie des résultats et une épingle de sortie des in­for­ma­tions de retour com­plè­tent l’ensemble. Si une action de réponse doit être exécutée, les in­for­ma­tions né­ces­saires à cette action sont stockées dans l’épingle de sortie des in­for­ma­tions de retour.

9. Les Struc­tu­red 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 com­por­te­ment est déterminé par les nœuds d’activité et les bords, d’autre part que certains sous-types de ces actions pres­cri­vent un certain com­por­te­ment pour les nœuds exé­cu­tables en raison de leur sé­man­tique, notamment en ce qui concerne leur séquence.

Voici les sous-types des actions struc­tu­rées :

• Les Con­di­tio­nal Nodes (nœuds con­di­tion­nels) con­sis­tent en une ou plusieurs clauses qui re­pré­sen­tent les dif­fé­rentes branches des actions exé­cu­tables possibles. Une clause contient un segment de test et un segment de corps, qui con­tien­nent à leur tour des nœuds exé­cu­tables 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) cor­res­pon­dent à un groupe d’actions qui se répètent dans une boucle. Les actions sont divisées en trois sections : setup (con­fi­gu­ra­tion), test et body (corps). La boucle exécute toujours la con­fi­gu­ra­tion en premier. Ensuite suivent Test ou Body, qui se répètent ensuite en al­ter­nance.
• Les Sequence Nodes (nœuds séquence) imposent une séquence aux nœuds exé­cu­tables à l’intérieur de leurs limites. Vous les re­pré­sen­tez 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 cons­ti­tuent une autre forme de nœuds d’activité struc­tu­ré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 col­lec­tion. Tous les nœuds internes par­cou­rent chaque valeur de la col­lec­tion. Une passe est con­si­dé­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 col­lec­tion ; en interne, les éléments in­di­vi­duels de la col­lec­tion sont con­si­dé­rés comme des valeurs. Pour la notation, dessinez un rectangle arrondi avec une ligne poin­til­lée. Les nœuds d’expansion ap­pa­rais­sent sous forme de rec­tangles avec des segments et, comme indiqué ci-dessous, sont dessinés di­rec­te­ment sur la ligne. La seg­men­ta­tion est destinée à re­pré­sen­ter la liste des col­lec­tions 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 re­pré­sen­tent les données dans le diagramme d’activités. Pendant l’exécution d’une action, les nœuds d’objet con­tien­nent ces données. Seuls les jetons de contrôle peuvent passer di­rec­te­ment 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é in­tro­duits pour la première fois dans le diagramme d’activité UML-2. Ce sont des éléments dac­ty­lo­gra­phiés. Si un nœud d’objet cor­res­pond à un certain type, les jetons d’objet qui se déplacent sur lui doivent avoir des valeurs cor­res­pon­dantes. Les jetons nuls, qui n’ont pas besoin d’une valeur, cons­ti­tuent une exception : ils sont conformes à chaque nœud d’objet.

Les nœuds d’objets pres­cri­vent 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é (com­por­te­ment 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 exac­te­ment 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 mo­dé­li­sa­tion :

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 con­cep­teurs les dessinent gé­né­ra­le­ment sous forme de petits rec­tangles di­rec­te­ment 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 rac­cour­cir 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 pa­ra­mètres d’activité : l’activité ap­par­tient à la méta-classe de la des­crip­tion du com­por­te­ment. Selon UML, chaque com­por­te­ment a des pa­ra­mètres. Avant qu’un com­por­te­ment ne soit exécuté, on peut lui affecter des valeurs à traiter. Après le trai­te­ment, vous récupérez de nouvelles valeurs. Dans cette structure, les pa­ra­mètres sont les ca­rac­tères gé­né­riques qui per­met­tent 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 pa­ra­mètres d’activité se trouvent donc au début et à la fin d’une activité.

Par con­sé­quent, ce type de nœud dispose uni­que­ment 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 par­cou­rent 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é­ces­saire. Utiliser des nœuds de contrôle pour assurer un dé­rou­le­ment 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, con­trai­re­ment aux nœuds objets comme le nœud tampon.

Une dif­fé­rence sig­ni­fi­ca­tive 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. Con­trai­re­ment aux jetons objets, ces jetons ne con­tien­nent pas de données. Ce ne sont que des marqueurs. Par con­sé­quent, les actions n’ont pas besoin de nœuds d’objets (en par­ti­cu­lier de broches) pour récupérer les jetons de contrôle et les trans­mettre. Un jeton de contrôle lance une action, passe à l’action suivante et la met en mouvement. Il contrôle donc l’exécution chro­no­lo­gique de l’activité.

Parmi les symboles du diagramme d’activité UML, les nœuds de contrôle sont pro­ba­ble­ment les plus divers. Ils ap­par­tien­nent 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 im­mé­dia­te­ment le flux de contrôle en mouvement. S’il existe plusieurs nœuds de départ, les flux de commande cor­res­pon­dants démarrent si­mul­ta­né­ment. Les nœuds d’activité struc­tu­rés peuvent également avoir des nœuds de départ. Ils com­men­cent également dès l’ini­tia­li­sa­tion de l’activité struc­tu­ré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 par­ti­cu­la­rité 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é­trui­sant 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 pa­ra­mètres d’activité sont conservés.

Par ailleurs, toutes les actions syn­chrones s’arrêtent avec elle. Les actions asyn­chrones s’exécutent jusqu’à ce qu’elles soient terminées. Les nœuds finaux acceptent tous les jetons entrants. Con­trai­re­ment 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 al­ter­na­tive pratique si vous modélisez plusieurs points finaux dans le diagramme d’activité.

3. Les nœuds de pa­ral­lé­li­sa­tion et les nœuds de syn­chro­ni­sa­tion (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 pa­ral­lé­li­sa­tion divise un bord d’activité entrant en plusieurs flux sortants si­mul­ta­nés. Un seul bord d’activité peut entrer dans le nœud de pa­ral­lé­li­sa­tion. 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 des­ti­na­tion du flux sortant, le jeton est supprimé du nœud source. Si une autre cible n’accepte pas son jeton, le nœud de pa­ral­lé­li­sa­tion peut tenir le jeton en exception jusqu’à ce qu’il soit accepté.

Les nœuds de syn­chro­ni­sa­tion fonc­tion­nent exac­te­ment 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 cons­ti­tué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 ex­pi­re­ront et seuls les jetons objet ex­pi­re­ront. 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é­ci­fi­ca­tion de valeur au nœud de syn­chro­ni­sa­tion à l’aide de joinSpec, le nœud attend les jetons qui rem­plis­sent ex­pli­ci­te­ment ces con­di­tions avant d’émettre des jetons.

4. Les Decision Nodes et Mer­ge­Nodes (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 ca­rac­té­ris­tique dis­tinc­tive de ces notations de nœuds.

Un nœud de bran­che­ment 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 re­pré­sen­tent 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.