Règles de transformation du cas d’utilisation textuel en cas d’utilisation visuel

le passage d’un cas d’utilisation textuel en un cas d’utilisation visuel. En effet, pour réussir cette activité de transformation, il est primordial que ce cas d’utilisation textuel respecte toutes les règles d’écriture du gabarit (Tableau 8.1) et ne viole aucune règle de restriction du Tableau 8.8.

Les règles de transformation sont résumées dans le Tableau 8.11 et structurées comme suit :

R1 → R4 : Elles concernent le nom, la version, le domaine du problème et l’auteur du cas d’utilisation. Si le cas d’utilisation visuel est supporté par un outil, elles seront incorporées dans la propriété du diagramme et seront générées comme dans la documentation qui l’accompagne. En cas d’absence d’outil de modélisation, elles seront ajoutées manuellement sous forme de texte.

R5 → R6 : Chaque acteur sera modélisé par une partition (Swimlane) qui porte son nom. R7 : Théoriquement dans la situation où un cas d’utilisation UC1 inclut un cas d’utilisation UC2, celle-ci devient son préalable et conditionne son exécution. Pour cette raison, nous avons décidé de transformer l’élément Include en un nœud d’activité portant le stéréotype Include et le placer juste après le nœud du début du cas d’utilisation visuel. De cette façon, il fait référence au cas d’utilisation inclus qui devrait s’exécuter avant de démarrer le cas d’utilisation qui l’inclut.

R8 : Quand le comportement d’un UC1 peut être étendu par le comportement d’un UC2, nous disons alors que l’UC2 étend l’UC1. Cette extension se déclenche à un moment précis, selon une condition prédéterminée lors de l’exécution des séquences d’étapes de l’UC1. Nous avons donc décidé de modéliser ce cas d’utilisation, qui étend le comportement d’un autre, par un nœud d’activité qui porte le stéréotype Extend.

R9 → R10 : la précondition et la postcondition seront transformées en une note attachée respectivement au nœud initial et au nœud final du cas d’utilisation visuel.

R11 → R13 : Les verbes d’action du patron de communication textuel seront transformés en des nœuds d’actions dans le cas d’utilisation visuel. Leur emplacement, dans les partitions (Swimlanes), variera en fonction du type du patron de communication.

R14 : Data ou donnée dans le patron de communication se transforme en une propriété incorporée dans le nœud de contrôle ou dans le nœud d’objet. Il est tout à fait possible d’incorporer Data dans le nœud d’action juste à droite du verbe d’action.

R15 → R16 : Les deux éléments Object et Destination du patron de communication textuel seront transformés en des nœuds d’objets dans le cas d’utilisation visuel.

R17 : Le mot clé And se transforme en un nœud de jointure dans le cas d’utilisation visuel. R18 → R19 : Ces deux règles ont pour vocation de générer un nœud de décision dans le cas d’utilisation visuel. Elles se génèrent à chaque fois qu’un scénario alternatif se déclenche dans le cas d’utilisation textuel (R18) ou dans le cas où il est possible d’appliquer un verbe d’action sur deux objets, un qui appartient au scénario nominal et l’autre appartient au scénario alternatif (R19).

R20 : Cette règle montre que l’instance d’un objet est associée à l’instance d’un autre objet. Cette règle se manifeste au moment de l’utilisation du verbe d’action Associate. Dans le cas d’utilisation visuel, cette règle s’illustre par deux nœuds d’objets successifs dont le premier prend le statut de Associated.

R21 : Cette règle montre que l’instance d’un objet est dissociée de l’instance d’un autre objet. Cette règle se manifeste au moment de l’utilisation du verbe d’action Dissociate. Dans

le cas d’utilisation visuel, cette règle s’illustre par deux nœuds d’objets successifs dont le premier prend le statut de Dissociated.

Tableau 8.11 Règles de transformation du cas d’utilisation textuel en cas d’utilisation visuel

#

R1 Use case name Nom du cas d’utilisation visuel

R2 Version Doivent être mentionnés dans la propriété du cas d’utilisation si le cas d’utilisation est supporté par un outil de modélisation, si non sous forme de texte qui accompagne le diagramme visuel.

R3 Problem domain R4 Author

R5 Primary Actor Swimlane de l’acteur primaire. R6 Secondary Actor Swimlane de l’acteur secondaire

R7 Include Une activité stéréotypée <<Include>> qui référence le cas d’utilisation inclut doit être placée juste après le nœud de début.

R8 Extend Une activité stéréotypée <<Extend>> en référence au cas d’utilisation qui étend le comportement du cas d’utilisation étendu. Elle doit être placée au point d’extension approprié.

R9 Precondition Une note attachée au nœud initial ou une propriété du nœud initial dans l’outil de modélisation.

R10 Postcondition Une note attachée au nœud final ou une propriété du nœud final dans l’outil de modélisation.

R11 Verbe d’action de l’acteur primaire

Action dans le Swimlane de l’acteur primaire R12 Verbe d’action de l’acteur

secondaire

Action dans le Swimlane de l’acteur secondaire R13 Verbe d’action du système Action dans le Swimlane du système

R14 Data Incorporé dans le Object Flow ou le Control Flow. Il est possible de l’incorporer dans le nœud d’action juste après le verbe d’action.

R15 Object Nœud d’objet

R16 Destination Nœud d’objet

R17 And Noeud de bifurcation (Fork node)

R18 Or Noeud de décision (Decision Node)

R20 Verbe d’action Associate Deux nœuds d’objets successifs. Le premier nœud d’objet prend le statut Associated. Ce statut montre que l’instance du premier objet est associée/assignée à l’instance du deuxième objet. R21 Verbe d’action Dissociate Deux nœuds d’objets successifs. Le premier nœud

d’objet prend le statut Dissociated. Ce statut montre que l’instance du premier objet est dissociée de l’instance du deuxième objet.

8.8 Synthèse

Ce chapitre présente deux manières de documenter un cas d’utilisation, une textuelle et l’autre visuelle, ainsi que la méthode permettant de transformer un cas d’utilisation textuel en un cas d’utilisation visuel.

La documentation d’un cas d’utilisation textuel s’appuie sur un nouveau gabarit composé de treize éléments. Ce gabarit est muni de deux patrons de communication, le premier sert à exprimer l’interaction de l’acteur principal et de l’acteur secondaire et l’autre, à exprimer l’interaction du système. Ces deux patrons de communication sont dotés d’une proposition de quelques verbes génériques pouvant exprimer toutes les actions de l’acteur et du système dans un cas d’utilisation. De plus, des règles de restriction permettant de vérifier, lors de la rédaction des cas d’utilisation, les opérations non autorisées et d’en informer l’analyste d’affaires de la raison de restriction ont été proposées.

La documentation d’un cas d’utilisation visuel s’appuie sur un nouveau profil UML2, basé sur le diagramme d’activité UML2 et adapté à cette fin. Ce profil est accompagné des règles de contrôle permettant de respecter sa syntaxe.

Dans le but de garder un lien et une traçabilité entre les deux manières de documenter un cas d’utilisation, 21 règles de transformation ont été proposées afin de transformer un cas d’utilisation textuel en un cas d’utilisation visuel.