III. Modèle des cas d'utilisation : Use Case Model▲
Un cas d'utilisation représente généralement un objectif complet que remplit le système de manière à répondre au besoin d'un acteur appelé initiateur pour ce cas d'utilisation.
Les cas d'utilisation d'un projet sont modélisés dans la partie Use Case Model. Cette dernière est constituée d'un ensemble d'éléments dit de modélisation et de diagrammes parmi lesquels :
- les acteurs ;
- les cas d'utilisations ;
- les diagrammes de séquence et de cas d'utilisation.
Nous traitons chacun des éléments ci-dessus dans la suite.
III-A. Description des éléments de modélisation du Use case Model▲
III-A-1. Acteur (Actor)▲
Un acteur représente un rôle d'une entité présente dans le contexte du système considéré vis-à-vis de ce système. L'entité doit être distincte du système lui-même. L'entité doit être extérieure au système considéré. En fonction de son rôle l'entité interagit avec le système.
III-A-1-a. Multiplicité▲
1..n : on peut avoir un ou plusieurs acteurs.
III-A-1-b. Convention de Nommage▲
Pour les acteurs représentant des rôles d'utilisateurs humains : <<Actor>> <nom du rôle d'utilisateur>.
Exemple : pour un projet front-end on pourrait avoir un acteur humain (un utilisateur de rôle Agent) et on note <<Actor>>Agent.
Pour les acteurs représentant des rôles de systèmes externes : <<External System>> <nom du rôle de système>.
Exemple : pour un projet serveur, on pourrait avoir un acteur externe (le front-end) et on note <<ExternalSystem>>Front-End.
Le nom du rôle doit être un groupe nominal.
III-A-1-c. Utilisation d'un Actor▲
Un acteur peut apparaître dans tout ou partie des diagrammes de cas d'utilisation du modèle.
Un acteur peut apparaître sous la forme d'une de ses instances dans tout ou partie des diagrammes de séquence du modèle.
III-A-1-d. Documentation à fournir pour chaque Actor▲
La documentation à fournir pour chaque acteur doit contenir la définition complète de l'acteur. Par exemple pour un projet front-end un acteur humain de rôle Caissier pourra avoir comme documentation : <<agent ayant pour rôle d'effectuer les opérations de dépôt et de retrait d'argent demandées par les usagers>>.
III-A-2. Use Case▲
Un cas d'utilisation peut impliquer dans le cadre de son déroulement un ou plusieurs autres acteurs appelés participants pour ce cas d'utilisation.
L'implication d'un acteur dans un cas d'utilisation doit être matérialisée par une association entre l'acteur et le cas d'utilisation. Optionnellement, pour l'acteur initiateur il est possible de faire porter le rôle « Initiateur » à l'extrémité de l'association liée à l'acteur.
III-A-2-a. Multiplicité▲
1…n : on peut avoir un ou plusieurs Use Case.
III-A-2-b. Convention de Nommage▲
La convention de nommage est :
<<Use Case>>UC-<Code du Package>-<Numéro d'ordre du UC>-<Nom du cas d'utilisation>
- le nom du cas d'utilisation doit être un groupe verbal commençant par un verbe à l'infinitif ;
- le code du package est une chaine de caractère qui représente l'ensemble des UC (UC pour Use Case) qui sont liés à une fonctionnalité ;
- numéro d'ordre de l'UC de format 0xy, où x et y sont des chiffres allant de 0 à 9 :
III-A-2-c. Utilisation d'un Use Case▲
Un cas d'utilisation doit apparaître avec tous les acteurs impliqués dans son déroulement dans le diagramme de cas d'utilisation du package de regroupement des cas d'utilisation auquel il appartient.
III-A-2-d. Documentation à fournir pour chaque Use Case▲
La documentation d'un Use Case doit contenir :
- Événement déclencheur :
Description de l'événement matérialisant la présence d'un besoin de l'acteur initiateur, besoin qui va alors nécessiter la réalisation du cas d'utilisation.
Conventions : La description utilise la forme standardisée suivante : 'Le cas d'utilisation s'initie lorsque <l'acteur initiateur> <le groupe verbal décrivant l'action de l'acteur considérée comme l'événement déclencheur> ;
- Préconditions :
Description des conditions pertinentes et significatives (non triviales) devant être vérifiées à l'apparition de l'événement déclencheur pour que le cas d'utilisation puisse être déclenché ;
- Résumé :
Description synthétique du déroulement du cas d'utilisation dans son cas nominal, déroulement présentant les grandes étapes de cette interaction ;
- Postconditions :
Description des conditions globales et significatives devant être vérifiées lorsque le cas d'utilisation se termine quelle que soit la manière dont le cas d'utilisation s'est réalisé (scénario nominal, alternatif ou exceptionnel) ;
- Contraintes non fonctionnelles :
Descriptions des contraintes pesant sur le cas d'utilisation. Ces contraintes peuvent être de nature technique (exemple : contraintes transactionnelles), volumétrique, etc. ;
- Règles de gestion :
Descriptions des règles de gestion et autres exigences applicables au cas d'utilisation ou références vers leurs spécifications dans des documents extérieurs au modèle.
III-A-3. Diagramme de Cas d'Utilisation▲
n diagramme de cas d'utilisation réunit sur un même diagramme un ensemble de cas d'utilisation, un ensemble d'acteurs et les relations qui unissent ces acteurs aux cas d'utilisation lors du déroulement des fonctionnalités prises en charge par les cas d'utilisation.
III-A-3-a. Multiplicité▲
1..n : on peut avoir un ou plusieurs cas d'utilisation.
III-A-3-b. Convention de Nommage▲
Pas de convention de nommage particulière.
III-A-3-c. Utilisation d'un diagramme de Cas d'utilisation▲
Un diagramme de cas d'utilisation doit être fourni pour chaque package de regroupement de cas d'utilisation.
Un diagramme de cas d'utilisation présente :
- l'ensemble des cas d'utilisation contenus dans le package de regroupement considéré avec leurs acteurs ;
- les dépendances (include, extend, généralisation) qui unissent les cas d'utilisation entre eux.
III-A-4. Diagramme de Séquence de niveau système▲
Un diagramme de séquence met en jeu un ensemble d'objets (instances de classes ou acteurs) s'échangeant des messages représentant les demandes de services et les réponses à ces demandes.
Dans le Use Case Model, les diagrammes de séquence spécifiés sont exprimés « au niveau du système ». Seuls sont représentés les acteurs extérieurs et un objet unique symbolisant le système dans sa globalité. Le diagramme de séquence système ne présente donc que les interactions entre le système et l'extérieur, les interactions internes au système n'étant révélées que plus tard dans des réalisations de cas d'utilisation.
III-A-4-a. Multiplicité▲
1..n : on peut avoir un ou plusieurs diagrammes de séquence.
III-A-4-b. Conventions de Nommage▲
SC<numéro d'ordre du scénario>-<type du scénario>-<nom du scénario>
- Les types possibles de scénarios sont : Nominal, Alternatif et Exception.
- Le numéro d'ordre doit être exprimé sur deux positions. Les numéros d'ordre de format x0 doivent être réservés aux scénarios nominaux. Les scénarios alternatifs et exceptionnels doivent être numérotés selon le format xy où x correspond au x du scénario nominal à partir duquel ils sont exprimés et où y est un chiffre séquentiel différent de 0.
- Le nom du scénario doit être un groupe verbal commençant par un verbe à l'infinitif .
- Le nom du scénario est optionnel pour un scénario de type Nominal s'il s'agit de l'unique scénario de ce type pour le cas d'utilisation considéré.
III-A-4-c. Utilisation d'un Diagramme de séquence▲
Chaque diagramme de séquence de niveau système doit représenter un scénario de résolution d'un cas d'utilisation. Chacun de ces diagrammes doit être créé dans le package contenant le cas d'utilisation pour lequel il représente un scénario de résolution.
Pour chaque cas d'utilisation :
- Un (1) de ces diagrammes présente le scénario de type Nominal c'est-à-dire représentant des interactions normales permettant d'atteindre la satisfaction de l'objectif de l'acteur initiateur.
- Plusieurs (0..n) de ces diagrammes présentent les scénarios de type Alternatif c'est-à-dire représentant des interactions inhabituelles suite à des choix, circonstances et conditions particulières au cours de la résolution du cas d'utilisation, mais permettant d'atteindre tout de même l'objectif initial de l'acteur initiateur.
- Plusieurs (0..n) de ces diagrammes présentent les scénarios de type Exception c'est-à-dire représentant des interactions anormales suite à des erreurs ou des conditions particulières au cours de la résolution du cas d'utilisation ne permettant pas d'atteindre l'objectif initial de l'acteur initiateur.
Chacun de ces diagrammes présente :
- les acteurs et le système impliqués dans le déroulement du scénario considéré sous la forme d'instances de ces acteurs et de l'objet représentant artificiellement le système ;
- l'enchaînement des interactions, des actions et réactions entre les acteurs et le système sous la forme de messages ordonnancés temporellement entre les instances des acteurs et du système.
III-A-4-d. Documentation à fournir pour un diagramme de séquence▲
Elle doit contenir :
- Spécification textuelle :
Description de l'interaction entre les acteurs et le système pour le scénario considéré. Cette description doit donner étape par étape l'enchaînement des demandes et des réponses entre acteurs et système en précisant plus finement les éléments d'informations échangés.
Des références aux exigences et règles métier justifiant les étapes de déroulement du scénario doivent être intégrées dans cette spécification sous la forme suivante : [<référence de l'exigence>].
- Postconditions :
Description des conditions spécifiques et significatives devant être vérifiées lorsque le scénario se termine. Ces postconditions sont optionnelles et complémentaires aux postconditions globales spécifiées dans le cas d'utilisation.
III-B. Contenu du Use Case Model▲
Le Use case Model est composé de trois principaux packages :
- le package des acteurs ;
- le package de contexte ;
- et le package des cas d'utilisation.
III-B-1. Package Actor▲
C'est dans ce package qu'on range tous les acteurs du projet.
On y trouve aussi bien les acteurs humains que les systèmes extérieurs. On peut éventuellement faire figurer les interfaces de librairies extérieures utilisées par le système modélisé. Ce regroupement dans un package unique permet une gestion centralisée de l'ensemble des acteurs du système.
III-B-2. Package Context▲
On y signale toutes les entités systèmes du projet. On entend ici par entité un bloc. Par exemple pour un projet donné, les entités pourraient être : le front-end, le serveur, la base de données, l'ERP, etc. (cf figure 6).
III-B-3. Package Uses Cases▲
C'est dans ce package qu'on range tous les uses cases du projet. Pour une meilleure lecture les use cases d'un projet sont organisés par module fonctionnel : chaque bloc fonctionnel constitue alors un package de Uses Cases.
Par exemple pour un logiciel de gestion banque de détail on pourrait avoir les modules fonctionnels suivants :
- Gestion des clients physiques ;
- Gestion des comptes d'épargne.
Ce qui donnerait alors par exemple pour le module de gestion des clients physiques le regroupement <<UC Package>>CLTPHYS- Gestion Clients Physiques comme montre la figure 7 extraite d'un projet UML :
