Aller au contenu

Modélisation UML/Le diagramme d'activité

Leçons de niveau 17
Une page de Wikiversité, la communauté pédagogique libre.
Début de la boite de navigation du chapitre
Le diagramme d'activité
Icône de la faculté
Chapitre no 7
Leçon : Modélisation UML
Chap. préc. :Le diagramme de collaboration
Chap. suiv. :Sommaire
fin de la boite de navigation du chapitre
En raison de limitations techniques, la typographie souhaitable du titre, « Modélisation UML : Le diagramme d'activité
Modélisation UML/Le diagramme d'activité
 », n'a pu être restituée correctement ci-dessus.


Les diagrammes d'activités privilégient les traitements. Ils sont adaptés à la modélisation du cheminement de flots de contrôle (toutes les instructions, branches, chemins...) et de flots de données (toutes les définitions de variable, les utilisations...). Ils représentent graphiquement le comportement d'une méthode ou le déroulement d'un cas d'utilisation.

Les diagrammes d'activités ont certaines similitudes avec les diagrammes d'états-transitions dans leur présentation mais ils sont différents dans leurs interprétations. En effet, les diagrammes d'état-transitions sont orientés vers des systèmes réactifs, mais ils ne doivent pas présenter une vision unifiée d'un traitement avec plusieurs classeurs et ils peuvent être complétés par des diagrammes de séquence par exemple. A contrario, les diagrammes d'activité ne sont pas rattachés à un classeur particulier. Ils peuvent être attachés à n'importe quel élément de modélisation afin de visualiser, spécifier, construire ou documenter le comportement de cet élément.

Ensuite, la principale différence entre les diagrammes d'interaction et les diagrammes d'activités est que les premiers privilégient le flot de contrôle d'un objet à l'autre, contrairement aux seconds qui mettent en avant le flot de contrôle d'une activité à l'autre.

Dans la phase de conception, les diagrammes d'activités sont particulièrement adaptés à la description des cas d'utilisation car ils viennent illustrer et consolider leur description textuelle. De plus, leur représentation sous la forme d'organigrammes les rend facilement compréhensible et accessible les diagrammes d'états-transitions. Par exemple, un diagramme d'activité se concentre 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'objet est souvent importante dans ce type de modèle qui peut être rapproché de la modélisation bien connue de workflow.

Cette page Modélisation UML : Le diagramme d'activité est largement inspirée du livre UML2 de l'apprentissage à la pratique[1] de Laurent Audibert.

Les modèles UML sont utilisés pour expliquer comment fonctionne un système de manière abstraite. En même temps, UML 2 ne présente pas une simple description informelle en présentant un système à un niveau de détails qui permette son exécution. Le but est de donner une vision se rapprochant des langages de programmation impératifs comme C++ ou Java, UML 2 a pour objectif de se détacher des langages de programmation classiques. UML doit posséder des mécanismes présentant la précision d'un langage de programmation au niveau de la description de l'effet des actions. Étant donné que UML est universel, c’est à la charge des outils de définir la syntaxe d'un langage de programmation existant. Mais UML propose une définition des instructions de base qui représentent le langage orienté objet: c’est la description des actions UML.

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. Ce 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. Par exemple, une action peut être: - la création d'un nouvel objet ou lien - l'émission d'un signal - une affectation de valeur à des attributs - la réception d'un signal - un calcul arithmétique simple etc.

Désormais, nous allons présenter les différents types d'actions les plus courants.

Les différents types d'actions

[modifier | modifier le wikicode]

Action appeler (Call Operation)

[modifier | modifier le wikicode]

L'action Call Operation correspond à l'invocation d'une opération sur un objet sur un classeur de manière synchrone (qui a lieu en même temps) 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. Lorsque l'appel est synchrone, l'appelant est bloqué pendant l'exécution de l'opération et les valeurs de retour, s'il y en a, pourront être réceptionnées.

Action comportement (Call Behaviour)

[modifier | modifier le wikicode]

C'est une variante de l'action Call Operation car elle invoque directement une activité plutôt qu'une opération. Elle correspond à l'invocation d'un comportement spécifié à l'aide d'un diagramme UML, par exemple un diagramme d'activités ou d'interactions. Cela offre la possibilité, dans les diagrammes d'activités, de directement référer à d'autres types de diagrammes. On peut donc utiliser un diagramme de séquence par exemple (imbriqué dans un diagramme d'activités) pour illustrer le comportement d'une activité, et inversement.

Action envoyer (Send)

[modifier | modifier le wikicode]

Cette action crée un message et le transmet à un objet cible, où elle peut déclencher un comportement. Elle correspond à des appels asynchrones correspondant à des envois de messages asynchrones: l'appelant poursuit son exécution sans attendre que l'entité cible ait bien reçu le message. Ce type d'appel est bien adapté à la modélisation de systèmes matériels (communication sur un bus, interruptions d'entrée/sortie avec send signal) ou de protocoles de communication particuliers.

Action accepter événement (Accept Event)

[modifier | modifier le wikicode]

L'exécution de cette action interrompt l'exécution en cours jusqu'à la réception du type d'événement spécifié, qui est généralement un signal. Cette action est utilisée pour la réception de signaux asynchrones.

Action accepter appel (Accept Call) et action répondre (Reply)

[modifier | modifier le wikicode]

L'action Appeler appel est une variante de Accept Event pour les appels synchrones. L'action Répondre permet de transmettre un message en réponse à la réception d'une action de type Accept Call. Les actions accept call et reply peuvent être utilisées du côté récepteur pour décomposer la réception de l'appel. Reply correspond précisément au return des langages de programmation.

Action créer (Create)

[modifier | modifier le wikicode]

Cette action permet d'instancier (dupliquer) un objet.

Action détruire (destroy)

[modifier | modifier le wikicode]

Cette action permet de détruire un objet.

Action lever exception (raise exception)

[modifier | modifier le wikicode]

Cette action permet de lever explicitement une exception. Une exception est un élément important de l'approche orientée objet; elle permet de traiter des cas particuliers.

Pour faciliter la compréhension, nous avons représentés certaines actions évoquées précédemment, sous la forme d'un schéma:

Une représentation spécifique des actions de communication
Une représentation spécifique des actions de communication

Premièrement, on détecte l'arrivée du train; cette action représente l'action "accept event" c'est-à-dire qu'on reçoit le signal de l'arrivée du train. Deuxièmement, "faire clignoter les feux" est une action "send signal", cela veut dire qu'on envoie un signal qui est transmis à un objet cible sans attendre que ce dernier ait bien reçu le signal. Ensuite, l'action "time event" est un événement temporel déclenché après l'écoulement d'une certaine durée. Enfin, "abaisser la barrière" est une action "send signal", un message est envoyé et transmis à la cible.

On distingue graphiquement les actions associés à une communication: send signal, accept event et accept time event. Cela permet de mieux mettre en valeur les échanges entre les diagrammes de la spécification.

Une activité définit un comportement décrit par une série organisée 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 le traitement soit terminé. Une activité est un comportement et peut comporter des paramètres en entrée ou en sortie, ainsi que des variables locales au même titre qu'une opération.

Une activité peut regrouper des nœuds et des arcs, c’est ce qu'on peut appeler "groupe d'activités". Les nœuds et les arcs peuvent appartenir à plusieurs groupes. Le groupe d'activités représente un système qui est générique regroupant des activités pouvant être utilisé de façon variée. Un diagramme d'activité est lui-même un groupe d'activités. Voici ci-dessous un exemple de diagramme d'activités qui représente le fonctionnement d'une borne bancaire:

Schéma d'un groupe d'activités représentant le fonctionnement d'une borne bancaire
Schéma d'un groupe d'activités représentant le fonctionnement d'une borne bancaire

Cet exemple illustre différentes représentations des actions. Après avoir saisi le code, deux activités sont déclenchées: on choisit l'opération souhaitée si le code est valide ou la carte est restituée si on annule l'opération. Après avoir choisi l'opération, on trouve deux alternatives: choisir un montant qu'on dépose (dépôt) ou retire (retrait). Dans les deux cas, nous choisissons le compte par la suite. Si nous avons choisi de déposer des billets, nous devons insérer une enveloppe ce qui nous donne droit à la restitution de notre carte à la fin de l'opération. Si nous avons pris le choix d'effectuer un retrait de billets, nous avons le droit à deux options: afficher une publicité ou demander une autorisation de retrait. Enfin, la note portant le mot-clé "decisionInput" spécifie un critère de décision parmi plusieurs arcs d'activité, dont chacun doit satisfaire la variable "autorisation accordée" à "Non autorisé" ou "Autorisé" avant que la transition associée ne puisse être déclenchée (la garde).

Après avoir expliqué le diagramme d'activités et son fonctionnement, nous abordons majoritairement des nœuds qui sont essentiels dans un diagramme d'activités. Elle permet d'évoquer davantage en détail le contenu d'un diagramme d'activités.

Nœud d'activité

[modifier | modifier le wikicode]

Un nœud d'activité est un type d'élément abstrait qui permet de représenter les étapes le long du flot d'activité. On observe trois types de nœuds d'activité: • les nœuds d'exécution (executable node) • les nœuds d'objet (object node) • les nœuds de contrôle (control nodes)

Nœuds d'exécution

[modifier | modifier le wikicode]

Un nœud exécutable est un nœud d'activité qui donne lieu à une exécution d'actions. On trouve également le nœud d'action qui est un nœud d'activité exécutable qui constitue l'unité fondamentale de fonctionnalité exécutable dans une activité. Lorsqu'une action est exécutée, une transformation ou un calcul quelconque sont mis en place dans le système modélisé. En général, les actions sont liées à des opérations qui sont directement appelées. De plus, un nœud d'action doit avoir au moins un arc entrant. Afin de comprendre au mieux le système des nœuds d'action, revenons sur le graphique précédent: Image:Schéma d'un groupe d'activités représentant le fonctionnement d'une borne bancaire.PNG. Un noeud d'activité est représenté par un rectangle aux coins arrondis qui contient sa description textuelle. Cette dernière peut aller d'un simple nom à une suite d'actions réalisées par l'activité. UML n'a pas de règle spécifique sur cette description textuelle, on peut utiliser un langage de programmation ou du pseudo-code. On peut le constater avec la première représentation graphique de cette leçon: Image:Actions de communication.PNG

Nœuds de contrôle

[modifier | modifier le wikicode]

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)
• nœud de fin d'activité(final node)
• nœud de fin de flot (flow final)
• nœud de décision (decision node)
• nœud de fusion (merge node)
• nœud de bifurcation (fork node)
• nœud d'union (join node)

Nous allons décrire ces différents nœuds de contrôle.

C'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 et un nœud a un arc sortant et pas d'arc entrant. Il est représenté par un petit cercle plein. (cf. au diagramme suivant: Image:Noeud de contrôle.PNG)

Un nœud final est un nœud de contrôle possédant un ou plusieurs arcs entrants et aucun arc sortant. Il y a deux type de nœuds finaux: nœud de fin d'activité et nœud de fin de flot.

Lorsque l'un des arcs d'un nœud de fin d'activité est activé, l'exécution de l'activité enveloppante s'arrête et tous les nœuds ou flots actifs appartenant de cette activité est abandonné. Si l'activité a été appelé par un appel synchrone, un message Reply qui contient les valeurs sortantes est transféré en retour à l'appelant. Un nœud de fin d'activité est représenté par un cercle contenant un petit cercle plein. (cf. au diagramme suivant: Image:Noeud de contrôle.PNG)

Un flot est terminé lorsqu'un flot d'exécution atteint un nœud de fin de flot. Mais cette fin de flot n'a pas d'incidence sur les autres flots actifs de l'activité enveloppante. Un nœud de fin de flot est représenté par un cercle vide barré d'une croix.

Nœud de décision

[modifier | modifier le wikicode]

C'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, accompagnés de conditions de garde pour conditionner le choix. Quand le nœud de décision est atteint et qu'aucun arc en aval n'est franchissable (ce qui veut dire qu'aucune condition est vraie), cela signifie que le modèle est mal formé. C'est pour cela que 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 est validée si et seulement si toutes les autres gardes des transitions ayant la même source sont fausses. Lorsque plusieurs arcs sont franchissables (c'est-à-dire que plusieurs conditions de garde sont vraies), l'un d'entre eux est retenu et ce choix est non déterministe. Un nœud de décision est représenté par un losange. (cf. au diagramme suivant: Image:Noeud de contrôle.PNG)

Nœud de fusion

[modifier | modifier le wikicode]

Un nœud de fusion est un nœud de contrôle rassemblant plusieurs flots alternatifs entrants en un seul flot sortant. On ne l'utilise pas pour synchroniser des flots concurrents mais pour accepter un flot parmi plusieurs. Un nœud de fusion est représenté par un losange comme le nœud de décision. (cf. au diagramme suivant: Image:Noeud de contrôle.PNG)

Graphiquement, il est possible de fusionner un nœud de fusion et un nœud de décision, c'est-à-dire de posséder plusieurs arcs entrants et sortants. Il est aussi possible de fusionner un nœud de décision ou de fusion avec un autre nœud. Mais pour mieux mettre en évidence un branchement conditionnel, il est préférable d’utiliser un nœud de décision.

Nœud de bifurcation

[modifier | modifier le wikicode]

Un nœud de bifurcation est un nœud de contrôle qui sépare un flot ou plusieurs flots concurrents. Il possède donc un arc entrant ou plusieurs arcs sortants. Il est souvent accordé avec un nœud d'union pour équilibrer la concurrence (cf. Image:Schéma d'un groupe d'activités représentant le fonctionnement d'une borne bancaire.PNG). Il est représenté par un trait plein épais. (cf. au diagramme suivant: Image:Noeud de contrôle.PNG)

C'est un nœud de contrôle qui synchronise des flots multiples. Il possède plusieurs arcs entrants et un seul arc sortant. Lorsque tous les arcs entrants sont activés, l'arc sortant l'est aussi également. Un nœud d'union est aussi représenté par un trait plein épais. (cf. au diagramme suivant: Image:Noeud de contrôle.PNG)

Enfin il est possible de fusionner un nœud de bifurcation et un nœud d'union, possédant donc plusieurs arcs entrants et sortants.

Après vous avoir présentés les différents nœuds que peut avoir un diagramme d'activité, voici un exemple de diagramme d'activité qui illustre ces différents nœuds de contrôle. Ce diagramme décrit le fonctionnement d'une prise de commande.

Exemple de diagramme d'activité
Exemple de diagramme d'activité

Précédemment, nous avons expliqué la modélisation des flots de contrôle. Dans cette partie, nous allons aborder les flots de données, essentiels pour les traitements. Un nœud d'objet permet de définir un flot de données dans un diagramme d'activités.

Pins d'entrée et de sortie

[modifier | modifier le wikicode]

Pour exprimer les valeurs passées en argument à une activité ainsi que les valeurs de retour, il faut utiliser des nœuds d'objet appelés pins d'entrée ou de sortie. L'activité ne peut commencer uniquement lorsqu'une valeur est affectée à chacun de ses pins de sortie. Un pin est représenté par un petit carré attaché à la bordure d'une activité.

Pins d'entrée et de sortie
Pins d'entrée et de sortie

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.

Un pin de 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'objet. Il est toujours associé à une valeur spécifique. Graphiquement, il est représenté de la même manière qu'un pin d'entrée avec la valeur associée écrite à proximité.

Flot de données (ou flot d'objet)

[modifier | modifier le wikicode]

Il permet de passer des données d'une activité à une autre. Un arc reliant un pin de sortie à un pin d'entrée est un flot d'objet. Dans cette situation, le type de pin récepteur doit être identique ou parent du type du pin émetteur. Nous pouvons le constater sur le schéma suivant (en haut de la figure):

Pin de valeur
Pin de valeur

Il y a une autre représentation possible d'un flot d'objet, axée sur les données, car elle fait intervenir un nœud d'objet détaché d'une activité spécifique (cf. le bas de la figure du schéma ci-dessus). Ce nœud est représenté par un rectangle dans lequel est mentionné le type de l’objet qui est souligné dans ce cas. Des arcs viennent relier ce nœud d'objet à des activités sources et cibles. On peut également mettre en crochet le nom d'un état ou liste d'états et également en accolades des contraintes.

Le flot d'objet mentionne deux comportements:
- "transformation" qui indique une interprétation particulière de la donnée véhiculée par le flot;
- "selection" présente l’ordre dans lequel les objets sont choisis dans le nœud pour le quitter.

Nœud tampon central

[modifier | modifier le wikicode]

C'est un nœud d'objet qui accepte les entrées de plusieurs nœuds d'objet ou produit des sorties vers plusieurs nœuds d'objet. Les flots en provenance d'un nœud tampon central ne sont donc pas directement connectés à des actions. Ce nœud modélise un tampon traditionnel qui peut contenir des valeurs venant 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 du schéma suivant:Image:Pin de valeur.PNG) stéréotypé "centralBuffer". Voici ci-dessous un exemple de nœud tampon central pour centraliser toutes les commandes par différents procédés, avant qu’elles ne soient traitées:

Nœud tampon central
Nœud tampon central

Il existe également un autre type de nœud tampon central appelé "Nœud de stockage données (data store node). Quand un flux sortant sélectionne une information, l'information est reproduite et elle ne se supprime pas du nœud de stockage des données comme ce qui se passe dans un nœud tampon central. Lorsque un flux entrant sélectionne une donnée déjà stockée , cette donnée est supprimée par une nouvelle. Ce nœud est représenté comme un nœud d'objet détaché avec écrit "datastore". Voici ci-dessous un exemple de nœud de stockage de donnée:

Noeud de stockage des données
Noeud de stockage des données

Après avoir recruté le personnel, il est stocké dans le noeud de stockage des données de façon permanente, appelé dans ce cas "Base de données du Personnel". Ceux qui n'ont pas été affectés sont disponibles pour être affectés par l'activité "Affecter personnel". L'étiquette "selection: personnel.affectation=null" permet de sélectionner ceux qui n'ont pas été affectés.

Nœud d'activité structurée

[modifier | modifier le wikicode]

Un nœud d'activité structurée est un espace de nom et une spécialisation d'un groupe d'activités et d'un nœud d'activité exécutable. C'est une partie structurée d'une activité qui ne présente aucun autre nœud structuré. Dans le même nœud d'activité structurée, les transitions doivent avoir leurs nœuds source et cible. Les arcs et les nœuds doivent être présents dans un seul et unique nœud d'activité structuré. De plus, c’est uniquement lorsque toutes les données d'entrée sont disponibles que l'activité structurée peut s'activer. Enfin le flux a la possibilité de quitter l'activité quand toutes les actions de l'activité structurée se termine.

Afin de faciliter la compréhension, voici un schéma représentant un nœud d'activité structurée:

Noeud d'activité structurée
Noeud d'activité structurée

Un nœud structuré est identifié par la dénomination "strutured" et par un nom qui décrit le comportement modélisé dans l'activité structurée. Comme vous pouvez le constater sur le schéma ci-dessus, un nœud d'activité structurée est représenté de la façon suivante: le contour du noeud est en pointillé et une ligne continu sépare le nœud structuré de l'activité structurée.

Les nœuds d'activité structurée ont été mis en place par l'UML 2.

Structure de contrôle

[modifier | modifier le wikicode]

On note trois types de nœud d'activité structurée: le nœud conditionnel, le nœud de boucle et le nœud séquentiel. Comme évoqué précédemment, ce sont des nœud d'activité mis en place à partir l'UML 2 ce qui signifie que leurs définitions ne sont pas précises au niveau de leur syntaxe.

Avant de présenter une structure de contrôle, il est important de définir les différents types de nœud d'activité:
- Nœud de séquence: c’est un noeud d'activité structurée intitulé "séquence" qui garantit l'exécution d'un certain nombre d'activités réalisé en séquence dans un ordre établi en amont
- Nœud conditionnel: c’est un noeud d'activité appelé "conditional" qui représente le choix exclusif d'une activité parmi un certain nombre d'activités alternatives
- Nœud de boucle: c’est un noeud d'activité appelé "loop" qui représente une structure de contrôle en boucle présentant une partie d'initialisation, une partie de test et une partie correspondant au corps de la boucle

Voici ci-dessous une représentation graphique des différentes structures de contrôle:

Structure de contrôle
Structure de contrôle

Les partitions sont aussi des éléments essentiels dans un diagramme d'activités. En effet, elles sont appelées couloirs ou lignes d'eau. Elles ont pour but d'organiser les noeuds d'activités disposés dans un diagramme d'activités par le biais de regroupements. Ce sont des unités d'organisation du modèle. Ces partitions sont utiles lorsqu'on doit désigner la classe responsable qui rassemble un ensemble de tâches par exemple. La classe en question est donc responsable du comportement des noeuds à l'intérieur de la partition précédemment évoquée. Graphiquement, les partitions sont représentées par des lignes continues. Elles peuvent prendre la forme d'un tableau. De plus, les noeuds d'activités doivent appartenir à une seule et unique partition et les transitions peuvent passer à travers les frontières des partitions.

Afin de faciliter la compréhension, voici ci-dessous un ensemble de noeuds d'objet et de partitions dans un diagramme d'activités:

Partitions
Partitions

Pour savoir si vous avez bien compris ce qu'est un diagramme d'activités, exercez-vous sur l'exercice de la mousse au chocolat en vous amusant !



  1. UML2 de l'apprentissage à la pratique, Laurent Audibert, Ellipses Marketing, ISBN-10: 2340002044, ISBN-13: 978-2340002043