Cas d'utilisation, Cas d'emplois, Services

Les acteurs nous ont permis de définir l'extérieur de notre système. Décrivons maintenant l'intérieur avec des Cas D'Utilisation. Un service est constitué d'une suite complète d'évènements initialisée par un acteur, il spécifie toutes les interactions possibles entre l'acteur et le système. Un cas d'utilisation est donc une séquence spécialle de transactions entre l'acteur et le système. La collection de tous les cas d'utilisation modélisera notre système.

Pour mieux représenter ces scénarios nous les représentons par des graphes d'états. Chaque stimulus envoyé entre l'acteur et le système fait changer d'état dans ce graphe. Ainsi on perçoit le service comme pouvant être dans plusieurs états différents. Les transactions sont les transitions des graphes.

En cherchant maintenant chaque service possible pour chaque acteur nous devrions obtenir une description exhaustive de notre système.

Les services sont des classes et l'exécution d'un service est une instance.

Remarque: plusieurs services peuvent commencer de la même façon et l'on ne saura qu'à la fin (de l'exécution) ce qu'a été le service réalisé. Un acteur ne demande pas l'exécution d'un service! Il initialise une suite d'évènement qui se concrétisera dans un cas d'utilisation complet.

On identifie les Cas d'utilisations par acteurs. Et pour chaque service on identifie un cas d'utilisation. Pour mieux cerner le cas d'utilisation on lira les spécifications avec le point de vue de l'acteur, et l'on discutera avec ceux qui vont prendre le rôle d'acteur. Les questions suivantes peuvent être fructueuses :

• Quels sont les tâches principales de chaque acteur ?
• Quels acteurs peuvent avoir à changer les informations du système ?
• Quels acteurs ont à informer le système de changement externes ?
• L'acteur veut-il être prévenu de changements inattendus ? imprévus ?

Dans notre exemple Nous pouvons identifier un certains nombre de cas d'utilisations.
On commence par les acteurs principaux, dans notre exemple le client : Le client doit être capable de déposer des articles, ce qui nous donne un cas d'utilisation en incluant tout jusqu'à ce qu'il recoive son reçu. Notons le Dépose d'Article.
Y-a-t'il d'autre cas d'utilisation? Ce n'est pas clair passons donc à l'opérateur.
L'opérateur est un acteur secondaire.
Il doit pouvoir obtenir un rapport quotidien. Ce qui nous donne un cas d'utilisation : Raport Quotidien. Il doit être capable de changer le prix d'un article appelons le mise à jour Article. Ce qui nous donne la figure 1.3.
analyse.exemple1Première tentative de modèle de service pour l'exemple.

Nos différents cas d'utilisation peuvent être résumés comme suit :

Dépose d'Article

est lancé par le client quand il/elle dépose des Articles(bouteilles, Canettes, Boites). Pour chaque Article déposé le système incrémente le nombre d'articles déposés par ce client ainsi que le nombre total pour la journée (de ce type d'article). Quand le client a déposé tous ces Articles il/elle presse le bouton facture pour avoir son reçu avec la description et le montant total de ses retours.

Raport Quotidien

est lancé par l'opérateur quand il veut imprimer les informations sur les Articles déposés dans la journée. Le système imprime le nombre d'article de chaque type qui ont été déposés, ainsi que le total des retours de la journée. Les différents totaux seront remis à zéro pour une nouvelle journée.

Mise à jour Article

est utilisé par l'opérateur pour changer des informations dans le système. Les valeurs des articles peuvent être changées, de nouveau types d'articles peuvent être ajoutés.

Il n'est pas toujours évident de savoir quoi mettre dans des services différents. La complexité des services est importante pour choisir que faire .

Nous avons maintenant identifié les services. Cette étape peut être délicate et nécessiter plusieurs tentatives. Une fois que l'identification des différents services se stabilise, l'étape suivante démarre : la description plus exhaustive de chaque cas d'utilisation.

Pour chaque service :
Rechercher le parcours de base qui décrit le mieux le service. Les variantes et les erreurs sont décrites dans des parcours alternatifs. Il est normal d'avoir un parcours de base et plusieurs parcours alternatifs. Ces descriptions ne sont faites que maintenant pour éviter de forts probables réécritures en cas de changement sur l'identification des services.

Nous pouvons maintenant décrie avec plus de détails les différents services par exemple :

Dépose d'Article

• Quand un client dépose un Article il est mesuré par le système. Les mesure permettent d'identifier le type de (bouteille, cannette, boite) déposé. Si ce type est accepté, le total client est incrémenté en fonction de ce type, puis le total quotidien pour le type. Si l'article n'est pas accepté un message "ARTICLE REFUSE" est allumé sur la machine.
• Quand le client presse le bouton reçu, l'imprimante imprime la date, puis le total de ce client est calculé et les informations suivantes imprimées sur le reçu : nom nombre déposés valeur de l'article total Finalement la somme total que doit recevoir le client est imprimée, sur le reçu.

Quand cette analyse en détail est réalisée le système est minutieusement inspecté. C'est ici en général que les imprécisions dans les besoins font jour, soit dans une des premières étapes du développement.

Chaque cas d'utilisation peut être étudier séparément. Ce qui a deux avantages : rendre l'analyse incrémentale, et parraléliser certaines parties de l'analyse et/ou du développement.