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

Le diagramme d’activité est un type de diagramme au sein du Unified Modeling Language. Ce langage de modélisation graphique définit les formes pour la représentation de la programmation orientée objet. Il distingue 14 types de diagrammes. Des formulaires sont assignés à chacun d’eux. À l’aide de règles de notation, même les systèmes et processus abstraits peuvent être clairement représentés. UML modélise non seulement les systèmes logiciels, mais aussi les processus métier. Les diagrammes d’activité sont particulièrement utiles dans les deux domaines. Mais dans quel but devriez-vous créer un tableau d’activités ?

L’objectif des diagrammes d’activité

Les diagrammes d’activité UML appartiennent au groupe des diagrammes de comportement en UML. Tandis qu’un diagramme de structure enregistre l’état d’un système, c’est-à-dire les objets existants et leurs hiérarchies, ainsi que les connexions entre eux à un moment donné, les diagrammes de comportement décrivent le flux chronologique des flux de données. En plus du diagramme d’activité, le use case diagram et le state machine diagram appartiennent à ce groupe. Les diagrammes d’activité sont similaires dans leur utilisation et leur notation aux organigrammes (en particulier les organigrammes de programme), mais sont adaptés à la programmation orientée objet.

Fondamentalement, on peut dire que le diagramme d’activité modélise le flux des activités. Il peut s’agir de processus au sein d’un système informatique, de processus de cas d’utilisation ou de processus opérationnels. L’activité, par exemple « préparer une omelette au fromage », se décompose en plusieurs petites sous-activités : les actions. Celles-ci peuvent se dérouler de manière chronologique. Une action, par exemple, serait « casser des œufs », suivie de l’action « battre des œufs avec des épices ». La première action nécessite la seconde. Ils sont, pour ainsi dire, dans un état d’évolution.

Des processus parallèles peuvent également être représentés. Lorsque deux personnes préparent une omelette, les actions simultanées de « casser des œufs » et « hacher des herbes » sont possibles. L’activité a donc deux points de départ. C’est à partir de ces points que les personnes commencent leur activité. Elles passent d’une action à l’autre. Dans un cas d’application, ces personnes seraient des acteurs. Bien qu’ils jouent un rôle important dans le diagramme d’activité, ils ne reçoivent pas leur propre notation. Ils se déplacent d’un point de départ à un point d’arrivée, traversant des flux de contrôle ou d’objets pour se déplacer d’une action à l’autre. Entre les deux, il y a parfois des barrières, appelées épingles, qu’ils ne laissent passer que sous certaines conditions, par exemple lorsque les deux personnes sont présentes.

Dans le diagramme d’activité, ces « personnes » sont appelées des jetons. Il existe deux types de jetons dans le diagramme d’activité UML : le premier est le jeton objet, qui transmet les informations au nœud d’action, y lance une action et (si spécifié) stocke le résultat sous forme de valeur. Si le résultat et le jeton correspondent aux spécifications définies dans une épingle, cette épingle de sortie envoie le jeton objet via un flux objet à l’action suivante. Pour que le jeton puisse commencer cette action, il doit être conforme aux spécifications de l’épingle d’entrée. Les jetons de contrôle, en revanche, ne migrent que par des flux de contrôle et servent de marqueurs. Vous lancez une action, mais ne transmettez aucune donnée.

Dans l’exemple « Préparation d’une omelette au fromage », nous utilisons le diagramme d’activité pour montrer la séquence chronologique d’une application. Les diagrammes de cas d’utilisation, d’autre part, représentent les exigences du système qui doivent être respectées en cas d’utilisation.

Les diagrammes d’activité UML-2 ne peuvent bien sûr pas être utilisés uniquement pour des applications quotidiennes. En premier lieu, ils vous aident à présenter de manière structurée les processus dans les systèmes logiciels. Les analystes d’affaires, par exemple, l’utilisent pour établir les spécifications des développeurs de logiciels. En utilisant le langage graphique, les experts échangent des informations à un niveau généralement compréhensible et clair. Une fois que tous les processus ont été clarifiés et que les erreurs ont été corrigées, le diagramme d’activité sert de modèle pour la programmation.

Si vous intégrez un outil UML approprié dans votre environnement de développement intégré, le diagramme peut servir de cadre de code en utilisant la conversion XML en langage de programmation.

L’Object Management Group (OMG), qui spécifie la UML, résume les tâches possibles des diagrammes d’activité UML-2 comme suit :

  • Programmation informatique procédurale qui assigne des hiérarchies aux activités
  • Dans les modèles orientés objet, les activités agissent comme des méthodes qui décrivent les processus plus en détail.
  • Pour afficher les workflows et les processus de gestion.
  • Pour les systèmes d’application assistés par ordinateur, les activités spécifient les processus au niveau du système.

La notation pour les diagrammes d’activité UML

Les formulaires au sein de l’UML peuvent être compris comme des blocs de phrases du langage. Par conséquent, le langage de modélisation attribue un sens à chaque forme. Les modificateurs les décrivent plus en détail et les relient les uns aux autres. De plus, les formes ont parfois besoin de certaines autres formes ou étiquettes pour créer un diagramme significatif. Tout comme la langue parlée n’a de sens que si certaines règles grammaticales de base sont respectées, UML ne fonctionne comme un moyen de communication que si vous respectez les spécifications.

UML 2.5 est la spécification la plus récente du langage de modélisation et constituera donc la base du document. UML détermine la notation des types de diagrammes en fonction de leurs domaines d’application. Puisque le diagramme d’activité UML représente le flux des processus système et des cas d’utilisation, la méta-modélisation lui attribue les formulaires appropriés.

Comment les composants individuels sont-ils affichés visuellement et quelles fonctions les symboles du diagramme d’activités UML remplissent-ils ?

Activités

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 activités sont considérées comme des classes en UML (leur méta-classe est le comportement). Ils peuvent donc être mieux déterminés par les propriétés. Ceci peut influencer les éléments subordonnés. Une activité est considérée comme terminée lorsqu’un jeton est passé de son point de départ au point d’arrivée en passant par les actions. Le terminal détruit le jeton. Ceci s’applique également à tous les autres jetons, de sorte que l’activité arrête toutes les actions synchrones.

Note

UML 1 définit les diagrammes d’activité différemment d’UML 2, la version précédente leur attribuait le rôle d’un diagramme machine d’état spécialisé, ce qui limitait leurs domaines d’application. Si vous utilisez un outil UML, vous devez vous assurer qu’il supporte la formulation souhaitée, idéalement UML 2.5 ou plus.

Actions : les nœuds d’activité qui représentent le comportement

Une action (action, executable node) est un élément de modèle qui est hiérarchiquement subordonné à l’activité : l’action est une instance de l’activité de classe. Les actions représentent un comportement dans un système. Ce sont les blocs de construction de base utilisés pour exprimer le comportement en UML. Ils sont utilisés à la fois dans les diagrammes d’activité et dans les interactions.

Lorsque vous créez un diagramme d’activités, vous utilisez la notation « Action » pour représenter les parties exécutables d’une activité. Dans l’exemple ci-dessus, l’action « Éplucher les asperges et les mettre dans la poêle » (Peel the asparagus and put it in the pan) est une étape dans la réalisation de l’activité « Cuire les asperges » (Cook the asparagus). Les actions reçoivent l’information d’entrée, la traitent et produisent l’information de sortie. Une action ne s’arrête pas tant qu’elle n’est pas terminée.

Dans les diagrammes d’activité UML, les actions appartiennent aux nœuds d’activité. Les bords (flèches) relient les actions les unes aux autres. UML distingue les flux objets (flux de données) et les flux de contrôle (jetons de contrôle de transport). Lorsque les flux de données passent d’une action à l’autre, les épingles (nœuds d’objet) acceptent les jetons d’objet en entrée, les convertissent pour traitement dans l’action, puis génèrent la sortie de l’objet qui passe ensuite en jetons d’objet.

Remarque

La catégorie nœud d’activité a été introduite dans UML 2. Il existe trois sous-types : les nœuds de contrôle, les nœuds d’objet et les nœuds exécutables (les actions). Il n’y a pas de hiérarchie entre ces trois éléments. Tant qu’ils ne sont pas connectés en série ou définis plus étroitement au sein d’un groupe d’activités, ils peuvent être exécutés dans n’importe quel ordre (c’est-à-dire dès que les jetons entrants remplissent les conditions d’un nœud) ou en parallèle.

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.

  1. 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.
  1. Les Link-Actionsmodifient 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.
  1. LesLink-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.
  1. 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.
  1. Les actionsVariable 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.
  1. Les ActionsAccept-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.
  • Les Reply-Actions ont un lien avec les actions d’acceptation d’appel. D’une part, les triggers doivent correspondre afin que l’action de réponse, dans le cas Call-Event, d’un événement d’appel puisse réagir à l’action de réception d’appel exécutée précédemment. D’autre part, le comportement de niveau supérieur place leur valeur de sortie dans l’épingle des informations de retour de la reply action.
  • Les Unmarshall-Actions interrogent les valeurs des caractéristiques de la structure de référence. Pour reconnaître l’objet, vous disposez d’une épingle d’entrée objet. Les valeurs obtenues sont délivrées sur une épingle de sortie.
Remarque

Si des données structurées d’un objet ou des données élémentaires d’un programme doivent être transférées dans d’autres programmes, ou si l’on souhaite les mémoriser, il faut les convertir dans un format qui lui convient. Ce processus s’appelle Marshalling. Le processus inverse, Unmarshalling convertit ces données « gelées » en objets exécutables. C’est le cas par exemple du transfert de diagrammes UML d’un outil à l’autre en utilisant la conversion XML.

  1. 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 :

  • LesConditional 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.
  • LesLoop 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.
  • LesSequence 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.
  1. 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.

  1. LesReduce Actions (actions réduites) provoquent un comportement jusqu’à ce qu’une valeur unique émerge d’un ensemble de valeurs. Pour ce faire, l’action combine les éléments de collection. L’action a donc deux paramètres d’entrée mais un seul paramètre de sortie ou de retour.
  2. LesRaise Exception Actions (actions qui créent une exception) se terminent dès qu’elles causent une exception. Ainsi, elles ne se terminent pas comme des actions normales qui s’arrêtent lorsque l’action est terminée. Ils s’étendent vers l’extérieur à travers le système jusqu’au nœud d’activité structuré supérieur suivant. Si ce nœud a un gestionnaire qui correspond à l’exception, l’action s’arrête. Sinon, elle se propage davantage.

Nœud d’objet : nœuds d’activité qui contrôlent les jetons d’objets

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 :

  1. Non commandé (non spécifié)
  2. Ordonné (comportement défini par la personne qui modélise)
  3. FIFO (First In First Out) : l’ordre d’entrée et de sortie reste le même.
  4. 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).
  1. 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.

  1. Nœud tampon : comme pour les broches, vous utilisez le nœud tampon central (Central Buffer Node) directement dans le diagramme d’activité. Ce nœud d’objet stocke ou tamponne les valeurs n’importe où dans le diagramme. Contrairement à la broche, cependant, elle est autonome sans être liée à un nœud d’activité. Le nœud tampon relie les objets entrants et sortants à d’autres nœuds d’objets via le flux d’objets, par exemple avec une broche.

Le nœud tampon est utilisé pour mettre en mémoire tampon les flux d’objets entrants et sortants. Il accepte donc tous les jetons d’objets entrants et les rend disponibles pour les flux d’objets sortants. Ce n’est que lorsqu’un nœud objet devient libre à l’autre extrémité du flux et accepte les paramètres de l’objet qu’il transfère le jeton. Selon la notation UML, ce nœud est constitué d’un simple rectangle. Vous affichez sa fonction spéciale avec le stéréotype <<centralBuffer>>.

  1. Nœud de stockage de données : comme les nœuds tampons, vous pouvez également commuter les nœuds de stockage de données entre les flux d’objets sans les lier à une action. Ce sous-type du nœud tampon a une particularité : il stocke une copie de chaque jeton envoyé jusqu’à ce que l’activité de niveau supérieur soit terminée. Chaque valeur n’existe qu’une seule fois sur le nœud de stockage de données. Si le nœud stocke déjà un jeton d’objet avec une identité fixe, il n’accepte pas les nouveaux jetons ayant exactement les mêmes propriétés.

Comme pour tous les nœuds d’objet, le nœud de stockage des données est représenté par un rectangle. Pour les différencier, il est recommandé d’écrire la formule <<datastore>>> dans l’en-tête.

Nœud de contrôle : nœuds d’activité qui dirigent les jetons de contrôle

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é.

  1. Les nœuds finaux mettent fin au flux d’une activité. Il existe deux types de nœuds finaux : l’Activity Final Nodemet 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é.

  1. 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.

  1. 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.

Un nœud de connexion regroupe plusieurs flux entrants en un seul flux sortant. Contrairement au nœud de synchronisation, le nœud de connexion ne fusionne pas les jetons en un nouveau ou ne synchronise pas les types de bords entrants. Par conséquent, tous les fronts entrants doivent également être des flux de contrôle pour un flux de contrôle sortant. Il en va de même pour les flux d’objets. Le nœud de connexion offre simplement tous les jetons entrants pour le bord sortant.

Si vous souhaitez créer un diagramme d’activités sous UML et éditer le concept dans une équipe, il est important de respecter la notation. C’est le seul moyen d’assurer la compréhensibilité générale de ce langage de modélisation graphique. Dans cet article, nous vous avons présenté les nœuds d’activité les plus importants et leurs fonctions. De plus, nous avons montré toutes les notations de base et spécifiques pour les diagrammes d’activité selon les spécifications UML-2.5.1- . La spécification exhaustive de tous les symboles des diagrammes d’activité UML peut être trouvée sur le site Web de l’Object Management Group.


Attendez ! Nous avons quelque chose pour vous !
Votre messagerie professionnelle

Créez une adresse personnalisée
Affichez votre sérieux sur Internet
Nom de domaine inclus
À partir d' 1 € HT/mois (1,20 € TTC)
Conseiller personnel inclus !