MODULE No 27

Titre : Diagrammes d’activités (DA)

But : Montrer l’emploi des DA pour la description du comportement.

Antécédents : Module 36

Corps :

Une activité selon le manuel de UML est : « la spécification d’un comportement qui décrit la suite de pas séquentiels et parallèles d’une procédure […]. Flux de travail, algorithmes et code de programmes sont des exemples de procédures qui sont souvent modélisées comme activités. »

Il est important de souligner que les états concernent la condition des objets tandis que les activités concernent la condition du calcul lui-même.

Un DA est un diagramme qui relie les activités entre elles à l’aide de flux d’objets et/ou de flux de contrôle. L’évolution des activités dans le temps (simulation du comportement) peut être suivie à l’aide de jetons (Tokens). Pour qu’une activité puisse s’exécuter elle a besoin d’un ou plusieurs jetons. L’activité « consomme » les jetons et les mets en sortie (et donc à l’entrée d’autres activités).

Note Le jeton n’est pas représenté dans le DA en rational rose. Il est un élément de simulation car il montre la progression du contrôle. Les DA tout en étant des diagrammes qui décrivent le comportement n’ont pas d’éléments visuels qui montrent la progression étant données certaines conditions initiales. Fin de la note.

Voici un exemple d’un DA employé pour décrire le CU que nous avons vu pour les GA. Le diagramme est divisé en trois couloirs (Swimlanes). Dans le premier à gauche on a un objet de la classe client, dans le couloir central on a un objet de la classe GA et dans le couloir de gauche un objet de la classe FE.

Dès le début (cercle noir comme pour les diagrammes d’état) le contrôle se divise en deux (Fork en anglais) : Insérer Carte (activité normale) et Terminer Opération (le client presse la touche de fin). Le jeton (c’est-à-dire l’élément qui identifie le lieu du contrôle actif) est dupliqué par la barre de synchronisation verticale : un jeton est dans l’activité Terminer opération (et il y reste jusqu’à ce que le client presse la touche Fin) et l’autre jeton entre dans Insérer carte et suit la « voie normale ».

Le client exécute l’activité Insérer Carte qui est suivi par l’activité Lire bande du GA (La ligne qui relie les deux activités indique le passage du contrôle de l’une à l’autre). À l’intérieur de l’activité Lire Bande le GA exécute l’activité Analyse Bande (le do indique qu’il s’agit d’une activité faite à l’intérieur de l’activité : disons « l’activité principale »). À la sortie de l’activité Lire Bande le GA affiche la fenêtre pour le NIP (mot clef exit qui précède le « / » qui indique que ce qui suit est une action). La ligne pointillée indique un flux d’objet (contrairement à la ligne continue qui indique le flux du contrôle).

L’objet Fenêtre : Fenêtre NIP (stéréotype IPM) est le « mécanisme » qui fait suive à l’activité Lire Bande du GA l’activité Entrer NIP du Client. Le Client peut entrer le NIP seulement après que le GA a affiché la fenêtre de saisie. Lorsque le GA exécute l’activité Lire Bande, s’il reçoit l’événement Fin opération, il termine la session. On suppose que l’événement Fin opération est généré par le client à l’aide d’une touche de l’IPM.

Une fois l’activité Entrer NIP terminée, l’objet NIP : NIP est passé à l’activité Vérification Synt du GA. La vérification est fait à l’entrée (entry/Vérifier Syntaxe). Le NIP est normalisé (do/normalisation) et est envoyé au FE qui fait une autre vérification.

Note L’activité Entrer NIP, comme toute autre activité par ailleurs, pourrait être détaillée avec un autre diagramme s’activité (approche top down). Les activités peuvent être imbriquées Fin de la note

Le GA, avant d’afficher la fenêtre pour le choix des comptes, attend la réponde du FE. (ligne horizontale de synchronisation). La ligne de synchronisation qu’au début indiquait une bifurcation (après la ligne il y a deux activités actives, deux jetons indépendants), indique ici une jointure : lorsque les deux jetons en provenance des deux flux (celui qui provient du FE et celui interne au GA) sont présents ils « deviennent un seul » et le contrôle et/ou les objets échangés passent du côté du client (dans le couloir de gauche).

Dans le DA on voit aussi que le FE envoie l’objet compte : état compte au GA.

Conséquents : pouvoir construire un DA pour décrire un CU du TP

Notes :

1) Pour ceux qui connaissent les flow-charts (ordinogrammes) : les DA sont des moyens pour montrer la progression du contrôle comme le sont (l’étaient) les ordinogrammes. Mais ils sont expressivement plus riches car ils permettent aussi de montrer le flux des données (lignes pointillées)

2) Comme pour les DE, la décision d’introduire dans une analyse un DA ne dépend que du besoin de clarté. Le DA (ou le DE) nous aide-t-il à mieux comprendre le domaine ? Si oui alors on l’introduit, sinon… Mais qui nous dit s’il nous aide ? Notre expérience et l’expérience de ceux qui participent à l’analyse avec nous (les autres parties-prenantes). Mais quel niveau de détail faut-il mettre ? Encore une fois, c’est la clarté qui nous aide à décider.