Cours gratuits » Cours informatique » Cours programmation » Cours UML » Support de cours UML : Diagramme d’activités

Support de cours UML : Diagramme d’activités


Télécharger



★★★★★★★★★★3.5 étoiles sur 5 basé sur 1 votes.
Votez ce document:

Support de cours UML : Diagramme d’activités

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&egr

ave;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.3). 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é à 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.1.

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 groupe d’activités 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)

Figure 6.1: Représentation graphique des nœuds d’activité. De la gauche vers la droite, on trouve : le nœud représentant une action, qui est une variété de nœud exécutable, un nœud objet, un nœud de décision ou de fusion, un nœud de bifurcation ou d’union, un nœud initial, un nœud final et un nœud final de flot.

Figure 6.2: Exemple de diagramme d’activités modélisant le fonctionnement d’une borne bancaire.

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

Figure 6.3: Représentation graphique d’une 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’exception 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

 Figure 6.4: Représentation graphique d’un 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 pseudo-code.

Figure 6.5: Représentation particulière des nœuds d’action de communication.

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)

Figure 6.6: Exemple de diagramme d’activité illustrant l’utilisation de nœuds de contrôle. Ce diagramme décrit la prise en compte d’une commande.

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.

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

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

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

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

Remarque

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

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

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 de union, comme un nœud de bifurcation, par un trait plein (cf. figure 6.2).

Remarque

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 (object node)

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’objet (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

Figure 6.7: Représentation des pins d’entrée et de sortie sur une activité.

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 (value pin)

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’objet

Figure 6.8: Deux notations possibles pour modéliser un flot de données.

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 (central buffer node)

Figure 6.9: Exemple d’utilisation d’un nœud tampon central pour centraliser toutes les commandes prises par différents procédés, avant qu’elles soient traitées.

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 (data store node)

Figure 6.10: Dans cette modélisation, le personnel, après avoir été recruté par l’activité Recruter personnel, est stocké de manière persistante dans le nœud de stockage Base de donnée du Personnel. Bien qu’ils restent dans ce nœud, chaque employé qui n’a pas encore reçu d’affectation (étiquette stéréotypée «selection» : personnel.affectation=null) est disponible pour être utilisé par l’activité Affecter personnel.

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é «datastore» (cf. figure 6.10).


115