Le diagramme de cas d'utilisation rend compte des services rendus par le système.

Il permet d'identifier:

- les acteurs à qui les services sont rendus (acteurs principaux que l'on situe généralement à gauche du système)

- les acteurs (ou éléments) qui participent aux cas d'utilisation (acteurs secondaires, généralement situés à droite du système)

Ce diagramme permet de décrire ce que le système doit faire, sans spécifier comment il le fera.

Chaque cas d'utilisation doit être associé à un scénario. (Si un scénario ne peut pas être établi c'est que le cas d'utilisation n'en est pas un.)

 

En pratique:

• Les systèmes étudiés ne doivent pas comporter plus de 2 ou 3 cas d'utilisations (5 si on considère d'éventuelles inclusions / extensions).

(Si tel n'est pas le cas c'est que le système est trop complexe ou qu'il y a des erreurs)

• Attention, les cas d'utilisations ne sont pas des décompositions fonctionnelles. Un cas d'utilisation est un service rendu par le système à l'utilisateur.

• Les acteurs apparaissant dans ce diagramme doivent forcément être repris du diagramme de contexte. (la réciproque n'est pas vraie).


Relations entre les cas d'utilisation:

Il est possible d'établir 3 types de relations entre les cas d'utilisation:

  • Inclusion («include»): le cas d'utilisation de base en incorpore un autre (ou plusieurs) de façon obligatoire.

  • Extension («extend»): le cas d'utilisation de base en incorpore un autre (ou plusieurs) de façon optionnelle.

  • Généralisation / spécialisation: les cas d'utilisations descendants héritent la description d'un parent commun.


Exemple: Lecture d'un cas d'utilisation de la balance Halo (Oups! Les scénarios ne sont pas écrits mais on peut les définir aisément...)

Cas d'utilisation principal:

          • Peser des aliments: le service est rendu à l'utilisateur.

Autres cas d'utilisations:

          • Convertir la pesée en volume: C'est une utilisation optionnelle offerte par le système. Elle est reliée au cas principal par un lien d'extension.
          • Tarer: C'est une généralisation de deux possibilités:
            - Tarer automatiquement: C'est une opération obligatoire faite par le système (avant chaque pesée ou au démarrage). Elle est reliée au cas principal par un lien d'inclusion.
            - Tarer à la demande: C'est une utilisation optionnelle (tarage en cours de pesée). Elle est reliée au cas principal par un lien d'extension.


Autres exemples:

Machine de test:

Cas d'utilisation d'une machine de test (Sté Pandrol)

Le système est une machine de test, le service rendu est de tester des moules en sable.

A qui ce système rend-il service?

L'erreur serait de placer le technicien comme acteur principal. Il est en réalité un acteur secondaire qui participe au cas d'utilisation (en manipulant la machine) dans un laboratoire d'essais (le laboratoire est placé à titre d'information comme acteur secondaire.

L'acteur principal est la chaîne de fabrication (à qui est rendu le service).

Remarque: le système "Machine de test" fait partie d'un process de production plus général identifié comme «Sur-Système» et nommé "Chaîne de fabrication"

On notera le scénario d'utilisation placé sur la droite et rattaché au cas d'utilisation.


Lecteur MP3 aquatique


Cas d'utilisation du lecteur MP3 Nabaiji.

La mission du système est de pouvoir compter les longueurs de bassin alors que le nageur écoute de la musique. La mission se retrouve bien dans le cas d'utilisation principal.

Deux sous-missions peuvent être définies: Diffuser de la musique et compter les longueurs (inclusion dans le cas principal)

Une troisième utilisation optionnelle est définie: échanger des données avec un pc (qui apparaît comme acteur secondaire)


Eléments syntaxiques








Créé avec HelpNDoc Personal Edition: Générateur facile de livres électroniques et documentation