Blog ENI : Toute la veille numérique !
🐠 -25€ dès 75€ 
+ 7 jours d'accès à la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. UML 2.5
  3. La modélisation des exigences
Extrait - UML 2.5 Initiation, exemples et exercices corrigés (5e édition)
Extraits du livre
UML 2.5 Initiation, exemples et exercices corrigés (5e édition)
2 avis
Revenir à la page d'achat du livre

La modélisation des exigences

Introduction

Ce chapitre a pour objectif de vous faire découvrir les cas d’utilisation employés pour décrire les exigences fonctionnelles attendues, lors de la rédaction du cahier des charges d’un système, ou les fonctionnalités d’un système existant.

L’ensemble des cas d’utilisation d’un système contient les exigences fonctionnelles attendues ou existantes, les acteurs (les acteurs décrivent le rôle que prennent les utilisateurs du système) ainsi que les associations qui unissent acteurs et fonctionnalités. Cet ensemble détermine également les frontières du système, à savoir les fonctionnalités remplies par le système et celles qui lui sont externes.

Les cas d’utilisation servent de support pour les étapes de modélisation, de développement et de validation. Ils constituent un référentiel du dialogue entre les informaticiens et leurs clients et, par conséquent, une base pour l’élaboration au niveau fonctionnel du cahier des charges.

Les cas d’utilisation

Les cas d’utilisation décrivent sous la forme d’une liste d’actions et d’interactions le comportement du système étudié du point de vue des acteurs. Ils définissent les limites du système et ses relations avec son environnement.

Cette définition doit être complétée. En effet, elle ne précise pas si un cas d’utilisation doit décrire l’intégralité ou une partie du dialogue entre un acteur et le système. Elle peut être formulée ainsi :

"Entre un acteur et le système, un cas d’utilisation décrit les actions et interactions liées à un objectif fonctionnel de l’acteur."

Un cas d’utilisation détaille la partie des exigences fonctionnelles du système concernant l’un des objectifs d’un acteur.

Exemple

Considérons comme système un élevage de chevaux. L’achat d’un cheval par un client constitue un cas d’utilisation.

Les acteurs

Un même utilisateur externe du système peut prendre différents rôles vis-à-vis du système. Seule la notion de rôle est retenue en UML.

Un acteur décrit le rôle qu’un utilisateur externe du système prend lors d’une interaction avec le système.

Cette définition est étendue aux autres systèmes qui interagissent avec le système. Ils forment autant d’acteurs qu’ils prennent de rôles.

Deux catégories d’acteurs doivent être distinguées :

  • Les acteurs primaires, pour lesquels l’objectif du cas d’utilisation est essentiel et constitue un objectif de l’acteur.

  • Les acteurs secondaires, pour lesquels l’objectif du cas d’utilisation n’est pas essentiel bien qu’ils interagissent avec lui.

Exemple

Reprenons l’exemple précédent du cas d’utilisation de l’achat d’un cheval par un client. L’acheteur d’un cheval est un acteur primaire. Les haras nationaux qui enregistrent le certificat de vente constituent un acteur secondaire.

Les scénarios

Un scénario est une instance d’un cas d’utilisation dans laquelle toutes les conditions relatives aux différents événements ont été fixées. Il n’y a donc pas d’alternatives lors du déroulement.

À un cas d’utilisation donné correspondent plusieurs scénarios.

Comme une classe qui détient les aspects communs de ses instances, un cas d’utilisation décrit de façon commune l’ensemble de ses scénarios en utilisant des branchements conditionnels pour représenter les différentes alternatives.

Exemple

L’achat de Jorphée par Fien constitue un exemple de scénario du cas d’utilisation d’achat d’un cheval. Toutes les alternatives du déroulement sont connues, car Fien a acquis Jorphée.

L’association entre un acteur et un cas d’utilisation

L’association entre un acteur et un cas d’utilisation indique que cet acteur a la capacité d’interagir avec le système de la manière décrite par le cas d’utilisation.

Cette association est représentée graphiquement par un simple trait. Il est possible de l’orienter pour indiquer l’extrémité qui initie l’interaction avec l’autre partie. Cette orientation est réalisée à l’aide d’une flèche qui part de l’extrémité qui envoie les demandes vers celle qui les reçoit.

Exemple

L’association qui lie l’acteur Acheteur au cas d’utilisation Achat Cheval indique que cet acteur détient la capacité d’acheter un cheval en interagissant avec ce cas d’utilisation.

Le diagramme des cas d’utilisation

Le diagramme des cas d’utilisation montre les cas d’utilisation représentés sous la forme d’ovales et les acteurs sous la forme de personnages. Il indique également les associations qui les lient.

Exemple

Le cas d’utilisation de l’achat d’un cheval est représenté par la figure 4.1 :

images/04RI01V4.png

Figure 4.1 - Le cas d’utilisation d’achat d’un cheval

Il est possible de représenter le système qui répond au cas d’utilisation sous la forme d’un rectangle englobant le cas.

Exemple

Dans l’exemple précédent, le système est l’élevage de chevaux. Il est illustré à la figure 4.2.

images/04RI02V4.png

Figure 4.2 - Système d’un cas d’utilisation

Un acteur secondaire est représenté comme un acteur primaire. À la différence de l’association entre un acteur primaire et un cas d’utilisation, l’association entre un acteur secondaire et un cas d’utilisation possède obligatoirement un sens qui va du cas d’utilisation vers l’acteur.

Exemple

Le changement de propriétaire du cheval est enregistré par les haras nationaux. Ces derniers constituent un acteur secondaire (voir figure 4.3).

images/04RI03V4.png

Figure 4.3 - Acteurs primaire et secondaire d’un cas d’utilisation

Les cardinalités de l’association acteur/cas d’utilisation

UML offre la possibilité d’introduire des cardinalités au niveau de l’association entre un acteur et un cas d’utilisation. Ces cardinalités figurent au niveau de chaque extrémité de l’association.

La cardinalité située à l’extrémité du cas d’utilisation indique avec combien d’instances du cas d’utilisation (scénarios), chaque instance de l’acteur situé à l’autre extrémité est liée. La cardinalité située à l’extrémité de l’acteur indique avec combien d’instances de l’acteur, chaque instance du cas d’utilisation situé à l’autre extrémité est liée.

Il est possible de spécifier la cardinalité minimale et la cardinalité maximale pour indiquer un intervalle de valeurs auquel doit toujours appartenir la cardinalité. Ces valeurs minimale et maximale sont indiquées dans le tableau ci-après.

Spécification

Cardinalités

0..1

zéro ou une fois

1

une et une seule fois

*

de zéro à plusieurs fois

1..*

de une à plusieurs fois

M..N

entre M et N fois

N

N fois

Exemple

Le cas d’utilisation de l’achat d’un cheval incluant les cardinalités est représenté par la figure 4.4. Un même acheteur peut acheter plusieurs chevaux et peut les acheter en indivision avec d’autres acheteurs. Chaque achat de cheval est enregistré par les haras nationaux qui sont représentés par une seule instance. Ceux-ci enregistrent tous les certificats de vente des chevaux, d’où la présence de la cardinalité * à l’extrémité du cas d’utilisation Achat...

Les relations entre les cas d’utilisation

1. La relation d’inclusion

La relation d’inclusion sert à enrichir un cas d’utilisation par un autre cas d’utilisation. Cet enrichissement est réalisé par une inclusion impérative, il est donc systématique.

Le cas d’utilisation inclus existe uniquement dans ce but. En effet, il ne répond pas à un objectif d’un acteur primaire. Un tel cas d’utilisation est une sous-fonction.

L’inclusion sert à partager une fonctionnalité commune entre plusieurs cas d’utilisation. Elle peut également être employée pour structurer un cas d’utilisation en décrivant ses sous-fonctions.

Dans le diagramme des cas d’utilisation, cette relation est représentée par une flèche pointillée munie du stéréotype «include».

Exemple

Lors de l’achat d’un étalon, un acheteur vérifie ses vaccinations. Par conséquent, le cas d’utilisation d’achat d’un étalon inclut cette vérification (voir figure 4.5).

images/04RI05V4.png

Figure 4.5 - Inclusion d’un cas d’utilisation

La mise en commun du cas d’utilisation d’examen des vaccinations est illustrée à la figure 4.6 car ce cas de sous-fonction est également pertinent pour l’achat d’une jument.

images/04RI06V4.png

Figure 4.6 - Mise en commun d’un cas d’utilisation inclus

L’inclusion peut également être employée pour décomposer l’intérieur d’un cas d’utilisation sans que le cas inclus soit partagé. À la figure 4.7, l’examen des maternités d’une jument n’est pas partagé, mais sa présence illustre bien que cet examen fait partie des points étudiés lors de l’achat d’une jument.

images/04RI07V4.png

Figure...

La représentation textuelle des cas d’utilisation

La représentation textuelle des cas d’utilisation n’est pas spécifiée dans UML. Elle est cependant couramment utilisée, c’est pourquoi nous l’avons introduite dans cet ouvrage.

Cette représentation sous forme textuelle des cas d’utilisation donne une description de leurs comportements, de leurs actions et réactions. Le contenu de cette représentation textuelle est le suivant :

  • Le nom du cas d’utilisation.

  • L’acteur primaire.

  • Le système concerné par le cas d’utilisation.

  • Les intervenants (ensemble des acteurs).

  • Le niveau du cas d’utilisation pouvant être :

  • soit un objectif de l’acteur primaire.

  • soit une sous-fonction.

  • Les préconditions qui sont les conditions à remplir pour que le cas d’utilisation puisse être exécuté.

  • Les opérations du scénario principal.

  • Les extensions.

Cas d’utilisation

Nom du cas d’utilisation

Acteur primaire

Nom de l’acteur primaire

Système

Nom du système

Intervenants

Nom des intervenants

Niveau

Objectif de l’acteur primaire ou sous-fonction

Préconditions

Conditions devant être remplies pour exécuter le cas d’utilisation

Opérations

1

Opération 1

2

Opération 2

3

Opération 3

4

Opération 4

5

Opération 5

Extensions

1.A

Condition d’application de l’extension A sur l’opération 1

1.A.1

Opération 1 de l’extension A sur l’opération 1

1.A.2

Opération 2 de l’extension A sur l’opération 1

1.B

Condition d’application de l’extension B sur l’opération 1

1.B.1

Opération 1 de l’extension B sur l’opération 1

4.A

Condition d’application de l’extension A sur l’opération...

Conclusion

Les cas d’utilisation servent à :

  • Exprimer les exigences fonctionnelles conférées au système par les utilisateurs lors de la rédaction du cahier des charges.

  • Vérifier que le système répond à ces exigences lors de la livraison.

  • Déterminer les frontières du système.

  • Écrire la documentation du système.

  • Construire les jeux de test.

Les cas d’utilisation offrent une technique de représentation qui convient au dialogue avec l’utilisateur car leur formalisme reste proche du langage naturel. Il est conseillé d’y adjoindre un lexique pour éviter les risques de confusion.

Nous étudierons par la suite comment découvrir les objets en utilisant les diagrammes de séquence associés aux cas d’utilisation.

Exercices

1. L’hippodrome

Un hippodrome offre à ses clients la possibilité de suivre les courses et de parier. 

Quels sont les acteurs qui interagissent avec ces services ?

Construisez le diagramme des cas d’utilisation.

2. Le club équestre

Un club équestre offre les prestations d’hébergement des chevaux, de cours d’équitation, de balades. Seuls les adhérents ont accès aux cours et aux hébergements. Les autres clients ont la possibilité de faire des balades et d’adhérer.

Quels sont les acteurs qui interagissent avec ces services ?

Construisez le diagramme des cas d’utilisation.

3. Le manège de chevaux de bois

Un manège de chevaux de bois offre à ses clients la possibilité de faire un tour moyennant paiement.

Quels sont les acteurs liés à ce service ?

Construisez le diagramme des cas d’utilisation.

Donnez la représentation textuelle correspondant au diagramme.