Vers un nouveau format de présentation du modèle de cas d’utilisation

Habituellement, l’UCM est modélisé à l’aide du diagramme de cas d’utilisation UML. Ce diagramme permet de donner une vision globale du comportement d’un système logiciel et est largement accepté par la communauté logicielle. En revanche, selon notre démarche, nous proposons la génération de l’UCM à partir du BPM : celui-ci contient des objets, des acteurs et des activités. Il est donc normal pour nous de prendre en compte les objets dans l’UCM. De ce fait, nous proposons une nouvelle technique qui exploite la force du diagramme d’activité UML2 pour concevoir l’UCM.

De ce fait, nous avons introduit des nouveaux éléments dans le diagramme d’activité UML2 afin qu’il puisse supporter la modélisation de l’UCM. Ils sont expliqués dans le Tableau 7.1.

Tableau 7.1 Les nouveaux éléments de l’UCM modélisé par le diagramme d’activités

Éléments Explications Légendes

Acteur secondaire

Le rôle joué par un acteur humain ou un acteur de type système. C’est un élément de type objet stéréotypé Secondary Actor. Relation

d’inclusion

L’instance du cas d’utilisation source comprend également le comportement décrit par le cas d’utilisation destination. Relation

d’extension

Le cas d’utilisation source étend le comportement du cas d’utilisation destination.

Relation d’héritage

Un cas d’utilisation hérite du même rôle joué par un autre cas d’utilisation. La relation d’héritage est aussi applicable quand un acteur hérite du comportement d’un autre acteur.

Cependant, la relation d’héritage entre les acteurs principaux de l’UCM devient difficilement applicable dans ce cas-ci. Cela est dû au choix fait pour représenter les acteurs principaux à l’aide des Swimlanes. Un Swimlane en UML n’a pas de sémantique significative (OMG, 2009-02-02), il indique seulement un certain regroupement quant à l’organisation des actions et des activités. Toutefois, il est tout à fait possible d’utiliser l’héritage entre les acteurs principaux si nous changeons le Swimlane qui représente l’acteur principal par un objet qui porte le stéréotype Principal Actor. Dans ce cas-ci, les Swimlanes ne seront pas utilisés et nous aurons deux possibilités de concevoir un UCM.

7.2.1 Deux catégories de cas d’utilisation

L’utilité des cas d’utilisation varie selon leur pertinence. Pour atteindre l’objectif d’affaires, certains sont d’une importance plus élevée que d’autres. Les plus importants, méritent d’être détaillés davantage. Les autres, qui sont d’une importance relativement faible, ne nécessitent pas d’être détaillés par un cas d’utilisation.

Les auteurs dans (Kurt Bittner et Ian Spence, 2002) recommande de s’intéresser uniquement aux cas d’utilisation dont la finalité est de concrétiser le but de l’acteur comme une réservation de voiture, un retrait d’argent, une commande de produit, etc. Par contre, les cas d’utilisation de type CRUD (Create, Read, Update, Delete) qui manipule directement un objet ne représentent pas une grande importance quant à l’activité du développement de système logiciel. Généralement, ils sont basiques avec des actions redondantes. Ils se réduisent à entrer, valider et modifier une donnée. Ils sont rarement reliés aux buts de l’acteur car ils représentent souvent un ensemble de différents buts à partir d’une variété de processus et de contextes d’affaires. Ils sont généralement longs à rédiger et souvent associés à de nombreux acteurs.

En effet, selon notre BPM nous constatons que les objets de type Resources et Results appartiennent à cette catégorie de cas d’utilisation CRUD. Ceci nous amène à les catégoriser et les distinguer des cas d’utilisation issus de l’activité du BPM. Il est donc important pour nous de mentionner cette différence :

• Les cas d’utilisation transactionnels sont les cas d’utilisation qui nous intéressent dans notre recherche. Ils sont les résultats directs de la transformation de l’élément Activity du BPM à l’UCM.

• Les cas d’utilisation CRUD sont les objets de type Resources et Results de l’UCM.

Il est à noter que dans cette recherche, nous nous intéressons uniquement aux cas d’utilisation transactionnels.

7.2.2 Vers un métamodèle du profil de l’UCM

Dans le même ordre d’idée que le profil BPM, nous profitons de la flexibilité d’UML pour proposer un profil adapté à la modélisation de l’UCM à l’aide du diagramme d’activités UML2. L’utilisation de ce diagramme, à la fois pour concevoir le BPM et l’UCM contribue à préserver une traçabilité entre les éléments des deux modèles. L’utilisation d’un seul diagramme réduit à la fois la courbe d’apprentissage et contribue à focaliser sur l’activité de

l’analyse à l’égard de l’apprentissage d’une nouvelle technologie de modélisation. La Figure 7.2 illustre le métamodèle du profil UCM.

Figure 7.2 Métamodèle du profil du modèle des cas d’utilisation (UCM)

Comme l’illustre la Figure 7.2, les nouveaux éléments qui ont été ajoutés au profil UCM sont en couleur grise. En voici une courte description :

• Extend, Include et Generalize sont des éléments qui héritent le l’élément Transition, ils sont orientés (leur direction a un sens) et stéréotypés;

• Les objets de type Resources et Results sont du même type que ceux du profil BPM; • Secondary Actor est l’acteur secondaire du cas d’utilisation de type objet. Il hérite de

l’élément Object Node et prend le stéréotype Secondary Actor pour se différencier des autres objets;

• Use Case est le cas d’utilisation. Il hérite de l’élément Activity Node et prend le stéréotype Use Case;

• Actor est l’acteur principal d’un cas d’utilisation. Il hérite de l’élément Partition et prend le stéréotype Actor.

Il est à préciser que si nous optons pour construire l’UCM sans l’utilisation des partitions (Swimalne) l’élément Actor dans le profil UCM n’héritera plus de l’élément Partition mais plutôt de l’élément Object Node.

7.3 Synthèse

Ce chapitre propose un nouveau format de modèle de cas d’utilisation (UCM). Celui-ci, à la différence du diagramme de cas d’utilisation UML, est basé sur le métamodèle du diagramme d’activité UML2. Il introduit de nouveaux éléments, notamment, la notion de l’objet.

Il est aussi proposé qu’il est possible de générer l’UCM à partir du BPM. L’identification des activités supportées et automatiques du BPM ainsi que l’application des cinq règles de transformation réalisent cette opération. De plus, un métamodèle du profil de l’UCM a été proposé.