FAQ UMLConsultez toutes les FAQ

Un acteur est une entité externe qui intéragit avec le système (opérateur, centre distant, autre système...). En réponse à l'action d'un acteur, le système fournit un service qui correspond à son besoin. Les acteurs peuvent être classés (hiérarchie).

Pour répondre à cette question, il faut tout d'abord avoir correctement identifié le périmètre du système à modéliser. Si la base de données fait partie du périmètre du système à réaliser, alors elle n'apparaîtra pas comme un acteur. Par contre, si la base de données est externe au système à réaliser alors elle figurera comme un acteur.

Identifier les acteurs intervenant sur les cas d'utilisation peut représenter une véritable problématique. Pour vous aider, voici quelques questions qui vous permettrons plus facilement d'identifier les acteurs de votre système :
- Quels sont les utilisateurs qui ont besoins d'un système pour réaliser le travail ?
- Quels sont les utilisateurs qui vont effectuer les fonctions principales du système ?
- Quels sont les utilisateurs qui vont exécuter les fonctions principales du système (maintenance et administration) ?
- Est-ce que le système interagit avec du matériel ou d'autres logiciels ?

En général les noms sur les associations sont optionnels, donc informatifs. Ils n'ont donc pas d'utilité particulière mise à part la documentation du diagramme.

La relation "Include" est une relation entre 2 instances de cas d'utilisation telle que la réalisation de l'un nécessite la réalisation de l'autre.

Exemple : Pour un système de retrait de monnaie. Le use case "retirer_une_somme" va faire appel systématiquement au use case "verifier_solvabilité_client" afin de vérifier que le client dispose effectivement de la somme d'argent demandée.

La relation extend est une relation entre 2 instances de cas d'utilisation telle que A extend B signifie que le comportement de B peut être complété par le comportement de A. La relation extend indique une possibilité, un complément possible.

Exemple : Pour une application de gestion de commande. Lors de la "création de la commande", on peut éventuellementfaire appel à une "vérification_disponibilité_produit". Il y a un relation d'extend entre les deux cas d'utilisation.

Le problème lié à la granularité et le niveau de détails des cas d'utilisation est extrêmement dépendant du projet, du système à modéliser, de l'objectif de la modélisation et des personnes à qui s'adresse ce modèle. Deux lignes directrices peuvent cependant aider à dégager une ligne de conduite :

• Pour qui sont écrits ces cas d'utilisation ? Il faut que les cas d'utilisation soit parfaitement compréhensibles par tous les intervenants du projet et leur fournissent suffisamment d'informations sans les noyer dans les détails.
• Quel est l'objectif du cas d'utilisation ? Pas besoin de rentrer dans le détail quand le nom est suffisamment explicite.