6. Chapitre 6 Diagramme d'activités (Activity diagram)▲
6-1. Introduction au formalisme▲
6-1-1. Présentation▲
Les diagrammes d'activités permettent de mettre l'accent sur les traitements. Ils sont donc particulièrement adaptés à la modélisation du cheminement de flots de contrôle et de flots de données. Ils permettent ainsi de représenter graphiquement le comportement d'une méthode ou le déroulement d'un cas d'utilisation.
Les diagrammes d'activités sont relativement proches des diagrammes d'états-transitions dans leur présentation, mais leur interprétation est sensiblement différente. Les diagrammes d'états-transitions sont orientés vers des systèmes réactifs, mais ils ne donnent pas une vision satisfaisante d'un traitement faisant intervenir plusieurs classeurs et doivent être complétés, par exemple, par des diagrammes de séquence. Au contraire, les diagrammes d'activités ne sont pas spécifiquement rattachés à un classeur particulier. On peut attacher un diagramme d'activités à n'importe quel élément de modélisation afin de visualiser, spécifier, construire ou documenter le comportement de cet élément.
La différence principale entre les diagrammes d'interaction et les diagrammes d'activités est que les premiers mettent l'accent sur le flot de contrôle d'un objet à l'autre, tandis que les seconds insistent sur le flot de contrôle d'une activité à l'autre.
6-1-2. Utilisation courante▲
Dans la phase de conception, les diagrammes d'activités sont particulièrement adaptés à la description des cas d'utilisation. Plus précisément, ils viennent illustrer et consolider la description textuelle des cas d'utilisation (cf. section 2.5.3Description textuelle des cas d'utilisation). De plus, leur représentation sous forme d'organigrammes les rend facilement intelligibles et beaucoup plus accessibles que les diagrammes d'états-transitions. On parle généralement dans ce cas de modélisation de workflow. On se concentre ici sur les activités telles que les voient les acteurs qui collaborent avec le système dans le cadre d'un processus métier. La modélisation du flot d'objets est souvent importante dans ce type d'utilisation des diagrammes d'activités.
Les diagrammes d'activités permettent de spécifier des traitements a priori séquentiels et offrent une vision très proche de celle des langages de programmation impératifs comme C++ ou Java. Ainsi, ils peuvent être utiles dans la phase de réalisation, car ils permettent une description si précise des opérations qu'elle autorise la génération automatique du code. La modélisation d'une opération peut toutefois être assimilée à une utilisation d'UML comme langage de programmation visuelle, ce qui n'est pas sa finalité. Il ne faut donc pas y avoir recours de manière systématique, mais la réserver à des opérations dont le comportement est complexe ou sensible.
6-2. Activité et Transition▲
6-2-1. Action (action)▲
Une action est le plus petit traitement qui puisse être exprimé en UML. Une action a une incidence sur l'état du système ou en extrait une information. Les actions sont des étapes discrètes à partir desquelles se construisent les comportements. La notion d'action est à rapprocher de la notion d'instruction élémentaire d'un langage de programmation (comme C++ ou Java). Une action peut être, par exemple :
- une affectation de valeur à des attributs ;
- un accès à la valeur d'une propriété structurelle (attribut ou terminaison d'association) ;
- la création d'un nouvel objet ou lien ;
- un calcul arithmétique simple ;
- l'émission d'un signal ;
- la réception d'un signal ;
- …
- Nous décrivons ci-dessous les types d'actions les plus courants prédéfinis dans la notation UML.
Action appeler ( call operation )
- L'action call operation correspond à l'invocation d'une opération sur un objet de manière synchrone ou asynchrone. Lorsque l'action est exécutée, les paramètres sont transmis à l'objet cible. Si l'appel est asynchrone, l'action est terminée et les éventuelles valeurs de retour seront ignorées. Si l'appel est synchrone, l'appelant est bloqué pendant l'exécution de l'opération et, le cas échéant, les valeurs de retour pourront être réceptionnées.
Action comportement ( call behavior )
- L'action call behavior est une variante de l'action call operation car elle invoque directement une activité plutôt qu'une opération.
Action envoyer ( send )
- Cette action crée un message et le transmet à un objet cible, où elle peut déclencher un comportement. Il s'agit d'un appel asynchrone (i.e. qui ne bloque pas l'objet appelant) bien adapté à l'envoi de signaux (send signal).
Action accepter événement ( accept event )
- L'exécution de cette action bloque l'exécution en cours jusqu'à la réception du type d'événement spécifié, qui généralement est un signal. Cette action est utilisée pour la réception de signaux asynchrones.
Action accepter appel ( accept call )
- Il s'agit d'une variante de l'action accept event pour les appels synchrones.
Action répondre ( reply )
- Cette action permet de transmettre un message en réponse à la réception d'une action de type accept call.
Action créer ( create )
- Cette action permet d'instancier un objet.
Action détruire ( destroy )
- Cette action permet de détruire un objet.
Action lever exception ( raise exception )
- Cette action permet de lever explicitement une exception.
Graphiquement, les actions apparaissent dans des nœuds d'action, décrits section 6.3.1Nœud d'action.
6-2-2. Activité (activity)▲
Une activité définit un comportement décrit par un séquencement organisé d'unités dont les éléments simples sont les actions. Le flot d'exécution est modélisé par des nœuds reliés par des arcs (transitions). Le flot de contrôle reste dans l'activité jusqu'à ce que les traitements soient terminés.
Une activité est un comportement (behavior en anglais) et à ce titre peut être associée à des paramètres.
6-2-3. Groupe d'activités (activity group)▲
Un est une activité regroupant des nœuds et des arcs. Les nœuds et les arcs peuvent appartenir à plus d'un groupe. Un diagramme d'activités est lui-même un groupe d'activités (cf. figure 6.2).
6-2-4. Nœud d'activité (activity node)▲
Un nœud d'activité est un type d'élément abstrait permettant de représenter les étapes le long du flot d'une activité. Il existe trois familles de nœuds d'activités :
- les nœuds d'exécutions (executable node en anglais) ;
- les nœuds objets (object node en anglais) ;
- et les nœuds de contrôle (control nodes en anglais).
La figure 6.1 représente les différents types de nœuds d'activité. La figure 6.2 montre comment certains de ces nœuds sont utilisés pour former un diagramme d'activités.
6-2-5. Transition▲
Le passage d'une activité vers une autre est matérialisé par une transition. Graphiquement les transitions sont représentées par des flèches en traits pleins qui connectent les activités entre elles (figure 6.3). Elles sont déclenchées dès que l'activité source est terminée et provoquent automatiquement et immédiatement le début de la prochaine activité à déclencher (l'activité cible). Contrairement aux activités, les transitions sont franchies de manière atomique, en principe sans durée perceptible.
Les transitions spécifient l'enchaînement des traitements et définissent le flot de contrôle.
6-3. Nœud exécutable (executable node)▲
Un nœud exécutable est un nœud d'activité qu'on peut exécuter (i.e. une activité). Il possède un gestionnaire d'exceptions qui peut capturer les exceptions levées par le nœud, ou un de ses nœuds imbriqués.
6-3-1. Nœud d'action▲
Un nœud d'action est un nœud d'activité exécutable qui constitue l'unité fondamentale de fonctionnalité exécutable dans une activité. L'exécution d'une action représente une transformation ou un calcul quelconque dans le système modélisé. Les actions sont généralement liées à des opérations qui sont directement invoquées. Un nœud d'action doit avoir au moins un arc entrant.
Graphiquement, un nœud d'action est représenté par un rectangle aux coins arrondis (figure 6.4) qui contient sa description textuelle. Cette description textuelle peut aller d'un simple nom à une suite d'actions réalisées par l'activité. UML n'impose aucune syntaxe pour cette description textuelle, on peut donc utiliser une syntaxe proche de celle d'un langage de programmation particulier ou du pseudocode.
Certaines actions de communication ont une notation spéciale (cf. figure 6.5).
6-3-2. Nœud d'activité structurée (structured activity node)▲
Un nœud d'activité structurée est un nœud d'activité exécutable qui représente une portion structurée d'une activité donnée qui n'est partagée avec aucun autre nœud structuré, à l'exception d'une imbrication éventuelle.
Les transitions d'une activité structurée doivent avoir leurs nœuds source et cible dans le même nœud d'activité structurée. Les nœuds et les arcs contenus par nœud d'activité structuré ne peuvent pas être contenus dans un autre nœud d'activité structuré.
Un nœud structuré est dénoté par le stéréotype « structured » et identifié par un nom unique décrivant le comportement modélisé dans l'activité structurée.
Graphiquement, le contour d'un nœud d'activité structurée est en pointillé. Une ligne horizontale en trait continu sépare le compartiment contenant le stéréotype « structured » et le nom de l'activité structurée du corps de l'activité structurée.
6-4. Nœud de contrôle (control node)▲
Un nœud de contrôle est un nœud d'activité abstrait utilisé pour coordonner les flots entre les nœuds d'une activité.
Il existe plusieurs types de nœuds de contrôle :
- nœud initial (initial node en anglais) ;
- nœud de fin d'activité (final node en anglais) ;
- nœud de fin de flot (flow final en anglais) ;
- nœud de décision (decision node en anglais) ;
- nœud de fusion (merge node en anglais) ;
- nœud de bifurcation (fork node en anglais) ;
- nœud d'union (join node en anglais).
La figure 6.6 illustre l'utilisation de ces nœuds de contrôle.
6-4-1. Nœud initial▲
Un nœud initial est un nœud de contrôle à partir duquel le flot débute lorsque l'activité enveloppante est invoquée. Une activité peut avoir plusieurs nœuds initiaux. Un nœud initial possède un arc sortant et pas d'arc entrant.
Graphiquement, un nœud initial est représenté par un petit cercle plein (cf. figure 6.6).
6-4-2. Nœud final▲
Un nœud final est un nœud de contrôle possédant un ou plusieurs arcs entrants et aucun arc sortant.
6-4-2-a. Nœud de fin d'activité▲
Lorsque l'un des arcs d'un nœud de fin d'activité est activé (i.e. lorsqu'un flot d'exécution atteint un nœud de fin d'activité), l'exécution de l'activité enveloppante s'achève et tout nœud ou flot actif au sein de l'activité enveloppante est abandonné. Si l'activité a été invoquée par un appel synchrone, un message (reply) contenant les valeurs sortantes est transmis en retour à l'appelant.
Graphiquement, un nœud de fin d'activité est représenté par un cercle vide contenant un petit cercle plein (cf. figure 6.6).
6-4-2-b. Nœud de fin de flot▲
Lorsqu'un flot d'exécution atteint un nœud de fin de flot, le flot en question est terminé, mais cette fin de flot n'a aucune incidence sur les autres flots actifs de l'activité enveloppante.
Graphiquement, un nœud de fin de flot est représenté par un cercle vide barré d'un X.
Les nœuds de fin de flot sont particuliers et à utiliser avec parcimonie. Dans l'exemple de la figure 6.6, le nœud de fin de flot n'est pas indispensable : on peut le remplacer par un nœud d'union possédant une transition vers un nœud de fin d'activité.
6-4-3. Nœud de décision et de fusion▲
6-4-3-a. Nœud de décision (decision node)▲
Un nœud de décision est un nœud de contrôle qui permet de faire un choix entre plusieurs flots sortants. Il possède un arc entrant et plusieurs arcs sortants. Ces derniers sont généralement accompagnés de conditions de garde pour conditionner le choix. Si, quand le nœud de décision est atteint, aucun arc en aval n'est franchissable (i.e. aucune condition de garde n'est vraie), c'est que le modèle est mal formé. L'utilisation d'une garde [else] est recommandée après un nœud de décision, car elle garantit un modèle bien formé. En effet, la condition de garde [else] est validée si et seulement si toutes les autres gardes des transitions ayant la même source sont fausses. Dans le cas où plusieurs arcs sont franchissables (i.e. plusieurs conditions de garde sont vraies), seul l'un d'entre eux est retenu et ce choix est non déterministe.
Graphiquement, on représente un nœud de décision par un losange (cf. figure 6.6).
6-4-3-b. Nœud de fusion (merge node)▲
Un nœud de fusion est un nœud de contrôle qui rassemble plusieurs flots alternatifs entrants en un seul flot sortant. Il n'est pas utilisé pour synchroniser des flots concurrents (c'est le rôle du nœud d'union), mais pour accepter un flot parmi plusieurs.
Graphiquement, on représente un nœud de fusion, comme un nœud de décision, par un losange (cf. figure 6.6).
Graphiquement, il est possible de fusionner un nœud de fusion et un nœud de décision, et donc d'avoir un losange possédant plusieurs arcs entrants et sortants. Il est également possible de fusionner un nœud de décision ou de fusion avec un autre nœud, comme un nœud de fin de flot sur la figure 6.6, ou avec une activité. Cependant, pour mieux mettre en évidence un branchement conditionnel, il est préférable d'utiliser un nœud de décision (losange).
6-4-4. Nœud de bifurcation et d'union▲
6-4-4-a. Nœud de bifurcation ou de débranchement (fork node)▲
Un nœud de bifurcation, également appelé nœud de débranchement est un nœud de contrôle qui sépare un flot en plusieurs flots concurrents. Un tel nœud possède donc un arc entrant et plusieurs arcs sortants. On apparie généralement un nœud de bifurcation avec un nœud d'union pour équilibrer la concurrence (cf. figure 6.2).
Graphiquement, on représente un nœud de bifurcation par un trait plein (cf. figure 6.6).
6-4-4-b. Nœud d'union ou de jointure (join node)▲
Un nœud d'union, également appelé nœud de jointure est un nœud de contrôle qui synchronise des flots multiples. Un tel nœud possède donc plusieurs arcs entrants et un seul arc sortant. Lorsque tous les arcs entrants sont activés, l'arc sortant l'est également.
Graphiquement, on représente un nœud d'union, comme un nœud de bifurcation, par un trait plein (cf. figure 6.2).
Graphiquement, il est possible de fusionner un nœud de bifurcation et un nœud d'union, et donc d'avoir un trait plein possédant plusieurs arcs entrants et sortants (cf. figure 6.6).
6-5. Nœud d'objet▲
6-5-1. Introduction▲
Jusqu'ici, nous avons montré comment modéliser le comportement du flot de contrôle dans un diagramme d'activités. Or, les flots de données n'apparaissent pas et sont pourtant un élément essentiel des traitements (arguments des opérations, valeurs de retour…).
Justement, un nœud d'objet permet de définir un flot d'objets (i.e. un flot de données) dans un diagramme d'activités. Ce nœud représente l'existence d'un objet généré par une action dans une activité et utilisé par d'autres actions.
6-5-2. Pin d'entrée ou de sortie▲
Pour spécifier les valeurs passées en argument à une activité et les valeurs de retour, on utilise des nœuds d'objets appelés pins (pin en anglais) d'entrée ou de sortie. L'activité ne peut débuter que si l'on affecte une valeur à chacun de ses pins d'entrée. Quand l'activité se termine, une valeur doit être affectée à chacun de ses pins de sortie.
Les valeurs sont passées par copie : une modification des valeurs d'entrée au cours du traitement de l'action n'est visible qu'à l'intérieur de l'activité.
Graphiquement, un pin est représenté par un petit carré attaché à la bordure d'une activité (cf. figure 6.7). Il est typé et éventuellement nommé. Il peut contenir des flèches indiquant sa direction (entrée ou sortie) si l'activité ne permet pas de le déterminer de manière univoque.
6-5-3. Pin de valeur▲
Un pin valeur est un pin d'entrée qui fournit une valeur à une action sans que cette valeur ne provienne d'un arc de flot d'objets. Un pin valeur est toujours associé à une valeur spécifique.
Graphiquement, un pin de valeur se représente comme un pin d'entrée avec la valeur associée écrite à proximité.
6-5-4. Flot d'objets▲
Un flot d'objets permet de passer des données d'une activité à une autre. Un arc reliant un pin de sortie à un pin d'entrée est, par définition même des pins, un flot d'objets (en haut de la figure 6.8). Dans cette configuration, le type du pin récepteur doit être identique ou parent (au sens de la relation de généralisation) du type du pin émetteur.
Il existe une autre représentation possible d'un flot d'objets, plus axée sur les données proprement dites, car elle fait intervenir un nœud d'objet détaché d'une activité particulière (en bas de la figure 6.8). Graphiquement, un tel nœud d'objet est représenté par un rectangle dans lequel est mentionné le type de l'objet (souligné). Des arcs viennent ensuite relier ce nœud d'objet à des activités sources et cibles. Le nom d'un état, ou d'une liste d'états, de l'objet peut être précisé entre crochets après ou sous le type de l'objet. On peut également préciser des contraintes entre accolades, soit à l'intérieur, soit en dessous du rectangle du nœud d'objet.
La figure 6.11 montre l'utilisation de nœuds d'objets dans un diagramme d'activités.
Un flot d'objets peut porter une étiquette stéréotypée mentionnant deux comportements particuliers :
- « transformation » indique une interprétation particulière de la donnée véhiculée par le flot ;
- « selection » indique l'ordre dans lequel les objets sont choisis dans le nœud pour le quitter (cf. figure 6.10).
6-5-5. Nœud tampon central▲
Un nœud tampon central est un nœud d'objet qui accepte les entrées de plusieurs nœuds d'objets ou produit des sorties vers plusieurs nœuds d'objets. Les flots en provenance d'un nœud tampon central ne sont donc pas directement connectés à des actions. Ce nœud modélise donc un tampon traditionnel qui peut contenir des valeurs en provenance de diverses sources et livrer des valeurs vers différentes destinations.
Graphiquement, un nœud tampon central est représenté comme un nœud d'objet détaché (en bas de la figure 6.8) stéréotypé « centralBuffer » (cf. figure 6.9).
6-5-6. Nœud de stockage des données ▲
Un nœud de stockage des données est un nœud tampon central particulier qui assure la persistance des données. Lorsqu'une information est sélectionnée par un flux sortant, l'information est dupliquée et ne disparaît pas du nœud de stockage des données comme ce serait le cas dans un nœud tampon central. Lorsqu'un flux entrant véhicule une donnée déjà stockée par le nœud de stockage des données, cette dernière est écrasée par la nouvelle.
Graphiquement, un nœud tampon central est représenté comme un nœud d'objet détaché (en bas de la figure 6.8) stéréotypé « data store » (cf. figure 6.10).
6-6. Partitions▲
Les partitions, souvent appelées couloirs ou lignes d'eau (swimlane) du fait de leur notation, permettent d'organiser les nœuds d'activités dans un diagramme d'activités en opérant des regroupements (cf. figure 6.11).
Les partitions n'ont pas de signification bien arrêtée, mais correspondent souvent à des unités d'organisation du modèle. On peut, par exemple, les utiliser pour spécifier la classe responsable de la mise en œuvre d'un ensemble de tâches. Dans ce cas, la classe en question est responsable de l'implémentation du comportement des nœuds inclus dans ladite partition.
Graphiquement, les partitions sont délimitées par des lignes continues. Il s'agit généralement de lignes verticales, comme sur la figure 6.11, mais elles peuvent être horizontales ou même courbes. Dans la version 2.0 d'UML, les partitions peuvent être bidimensionnelles, elles prennent alors la forme d'un tableau. Dans le cas d'un diagramme d'activités partitionné, les nœuds d'activités appartiennent forcément à une et une seule partition. Les transitions peuvent, bien entendu, traverser les frontières des partitions.
Les partitions d'activités étant des catégories arbitraires, on peut les représenter par d'autres moyens quand une répartition géométrique s'avère difficile à réaliser. On peut ainsi utiliser des couleurs ou tout simplement étiqueter les nœuds d'activité par le nom de leur partition d'appartenance.
6-7. Exceptions ▲
Une exception est générée quand une situation anormale entrave le déroulement nominal d'une tâche. Elle peut être générée automatiquement pour signaler une erreur d'exécution (débordement d'indice de tableau, division par zéro…), ou être soulevée explicitement par une action (RaiseException) pour signaler une situation problématique qui n'est pas prise en charge par la séquence de traitement normale. Graphiquement, on peut représenter le fait qu'une activité peut soulever une exception comme un pin de sortie orné d'un petit triangle et en précisant le type de l'exception à proximité du pin de sortie (cf. figure 6.12).
Un gestionnaire d'exceptions est une activité possédant un pin d'entrée du type de l'exception qu'il gère et lié à l'activité qu'il protège par un arc en zigzag ou un arc classique orné d'une petite flèche en zigzag. Le gestionnaire d'exceptions doit avoir les mêmes pins de sortie que le bloc qu'il protège (cf. figure 6.13).
Les exceptions sont des classeurs et, à ce titre, peuvent posséder des caractéristiques comme des attributs ou des opérations. Il est également possible d'utiliser la relation d'héritage sur les exceptions. Un gestionnaire d'exceptions spécifie toujours le type des exceptions qu'il peut traiter, toute exception dérivant de ce type est donc également prise en charge.
Lorsqu'une exception survient, l'exécution de l'activité en cours est abandonnée sans générer de valeur de sortie. Le mécanisme d'exécution recherche alors un gestionnaire d'exceptions susceptible de traiter l'exception levée ou une de ses classes parentes. Si l'activité qui a levé l'exception n'est pas protégée de cette exception, l'exception est propagée à l'activité englobante. L'exécution de cette dernière est abandonnée, ses valeurs de sortie ne sont pas générées et un gestionnaire d'exception est recherché à son niveau. Ce mécanisme de propagation se poursuit jusqu'à ce qu'un gestionnaire adapté soit trouvé. Si l'exception se propage jusqu'au sommet d'une activité (i.e. il n'y a plus d'activité englobante), trois cas de figure se présentent. Si l'activité a été invoquée de manière asynchrone, aucun effet ne se produit et la gestion de l'exception est terminée. Si l'activité a été invoquée de manière synchrone, l'exception est propagée au mécanisme d'exécution de l'appelant. Si l'exception s'est propagée à la racine du système, le modèle est considéré comme incomplet ou mal formé. Dans la plupart des langages orientés objet, une exception qui se propage jusqu'à la racine du programme implique son arrêt. Quand un gestionnaire d'exceptions adapté a été trouvé et que son exécution se termine, l'exécution se poursuit comme si l'activité protégée s'était terminée normalement, les valeurs de sortie fournies par le gestionnaire remplaçant celle que l'activité protégée aurait dû produire.