PreReq

Je connais les conventions d’écriture du Diagramme des UC

ObjTD

Découvrir le diagramme des UC

Durée

1 séance de 1,5h

1. Rappel du cours

Le Diagramme des Cas d’Utilisation est un modèle UML permettant de représenter :

  • les UC (Use Case ou Cas d’Utilisation)

  • les acteurs (principaux et secondaires)

  • les relations entre acteurs et UC

On notera simplement UC pour signifier "diagramme des UC"

1.1. Définition et concepts

1.1.1. Cas d’Utilisation (Use Case ou UC en abrégé).

Un cas d’utilisation représente un ensemble de scénarios que le système doit exécuter pour produire un résultat observable par un acteur.

Exemple d’UC: cas du retrait par carte bancaire
Scénario principal

L’UC démarre lorsque le Guichet Automatique Bancaire (GAB) demande au client son numéro confidentiel après l’introduction de sa CB. Le client entre son code et valide son entrée. Le GAB contrôle la validité du code. Si le code est valide, le GAB autorise le retrait et l’UC se termine.

Scénario alternatif n°1

Le client peut à tout instant annuler l’opération. La carte est éjectée et l’UC se termine.

Exemple de codification de l’UC

UC01 ou RetraitCB (pour Retrait par carte bleue)

Précisions

Un cas d’utilisation peut être précisé par :

  • une description textuelle

  • un ou des diagrammes UML (séquence, activité)

Dans les outils, cette "précision" se manifeste par le fait que l’on "attache" généralement un diagramme de séquence à un cas d’utilisation (clic droit sur un UC → nouveau diagramme de séquence).

1.1.2. Acteur

Un acteur peut être une personne, un ensemble de personnes, un logiciel, ou un processus qui interagit avec un ou plusieurs UC.

On peut trouver plusieurs types d’acteurs :

  • extérieurs au système (cf. actor Diagramme d’UC ci-après)

    • les acteurs principaux (= acteurs internes du MOT de Merise)

    • les acteurs secondaires (= acteurs externes du MOT de Merise)

    • les administrateurs (ils gèrent le système : données, sécurité, droits d’accès, utilisateurs…​)

  • types d’acteurs prédéfinis dans UML :

    • <<metaclass>>

    • <<utility>>

    • <<process>>

    • <<thread>>

    • <<powertype>>

1.1.3. Relations entre UC

Extension (<<extend>>)

Indique que l’UC source est éventuellement exécutée en complément de l’UC destination (cas particulier, erreur…​)

Inclusion (<<include>>)

Indique qu’un UC est inclus obligatoirement dans un autre UC (notion de sous-programme par exemple)

Généralisation

Relation entre un UC général et un autre plus spécialisé qui hérite de ses caractéristiques et en rajoute

Diagramme d’UC
Figure 1. Notation dans le diagramme d’UC

On n’utilise généralement <<include>> que dans le cas où le sous-cas d’utilisation est inclut dans plusieurs UC. Si ce n’est pas le cas, il est généralement englobé dans l’UC.

1.2. Pour construire un UC (de manière générale)

  1. identifier les acteurs

  2. identifier les cas d’utilisation

  3. structurer en packages

  4. ajouter les relations

  5. finaliser les diagrammes de cas d’utilisation

2. Exercices

2.1. Établissement scolaire

2.1.1. Énoncé

Dans un établissement scolaire, on désire gérer la réservation des salles de cours et du matériel pédagogique (ordinateur portable et/ou vidéo-projecteur). Seuls les enseignants sont habilités à effectuer des réservations (sous réserve de disponibilité de la salle ou du matériel). Le planning des salles peut quant à lui être consulté par tout le monde (enseignants et étudiants). Par contre, le récapitulatif horaire par enseignant (calculé à partir du planning des salles) ne peut être consulté que par les enseignants. Enfin, il existe pour chaque formation un enseignant responsable qui seul peut éditer le récapitulatif horaire pour l’ensemble de la formation.

2.1.2. Question

Modéliser cette situation par un diagramme de cas d’utilisation.

2.2. Magasin

2.2.1. Énoncé

Dans un magasin, le processus de vente est le suivant : le client entre, passe dans les rayons, demande éventuellement des renseignements ou procède à des essais, prend des articles (si le stock est suffisant), passe à la caisse où il règle ses achats (avec tout moyen de paiement accepté). Il peut éventuellement bénéficier d’une réduction.

2.2.2. Question

Modéliser cette situation par un diagramme de cas d’utilisation.