• 20 heures
  • Facile

Ce cours est visible gratuitement en ligne.

Ce cours est en vidéo.

Vous pouvez obtenir un certificat de réussite à l'issue de ce cours.

Ce cours est diplômant et vous permet d'obtenir des crédits universitaires européens (ECTS).

J'ai tout compris !

Mis à jour le 22/02/2019

Les cas d’utilisation internes

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Dans ce chapitre, nous allons découvrir ce qu’on appelle des cas d’utilisation interne. Il s’agit ici de détailler les cas d’utilisation principaux afin de comprendre tous les lots d’actions qu’ils impliquent.

Définition

Les cas d’utilisation que nous avons découvert dans la partie 2 sont directement liés à un acteur et sont appelés des « cas d’utilisation principales ». On y décrit ce qu’un utilisateur doit pouvoir faire grâce au logiciel à développer. On parle donc les fonctionnalités principales du logiciel à développer.

Chacun de ces cas d’utilisation nécessitera un certain nombre d’actions. Il arrive que l’on doive regrouper certaines actions dans un ou plusieurs cas d’utilisation complémentaires qui ne sont pas directement liés à un acteur. On parle alors d’un cas d’utilisation interne.

Il s’agit essentiellement :

  • de cas d’utilisation interne qui peuvent être nécessaires à plusieurs autres cas d’utilisation (qu’ils soient des cas d’utilisation principaux, ou même d’autres cas d’utilisation interne) ;

  • de cas d’utilisation qui regroupent un certain nombre d’actions qui forment un tout homogène et pouvant être décrit séparément.

Pour trouver les cas d’utilisation internes, nous devrons réfléchir à chaque cas d’utilisation que nous avons déjà indiqué dans notre diagramme.

Diagramme illustrant des cas d’utilisation internes

Les cas d’utilisation internes seront indiqués dans le diagramme de cas d’utilisation. Leur particularité réside dans le fait qu’ils ne seront pas directement liés aux acteurs, mais aux cas d’utilisation qui en ont besoin.

Les liens (ou relations) entre cas d’utilisation peuvent être divisés en deux groupes :

  • La spécialisation 

  • Les relations stéréotypées

Cela vous semble un peu nébuleux ?

Revoyons tout cela à partir de notre étude de cas : créer une boutique en ligne. Dans la partie précédente, nous nous étions arrêté au diagramme de cas d’utilisation du package « Gestion des achats » qui mettait en évidence les acteurs et les cas d’utilisation principaux. Cela vous rappelle quelque chose ? (Voir la figure suivante).

Diagramme de cas d’utilisation du package «Gestion des achats» v4
Diagramme de cas d’utilisation du package « Gestion des achats » v4

La spécialisation des acteurs

Un premier complément à notre diagramme de cas d’utilisation pourra être mis en œuvre à l’aide d’une notion appelée « la spécialisation ».

La spécialisation peut être indiquée à deux niveaux :

  • au niveau des acteurs ;

  • au niveau des cas d’utilisation principaux.

Regardons le diagramme de package « Gestion des achats» dans le détail. On constate très vite qu’au niveau des acteurs « Client » et « Commercial », les cas d’utilisation « Consulter catalogue produits » et « Enregistrer un achat » s’entrecroisent.

Diagramme de cas d’utilisation du package «Gestion des achats» v4 (détail)

Le diagramme reste lisible puisqu’il n’y a pas trop de liens qui se croisent mais prenons tout de même l’habitude d’éviter les liens qui s’entrecoupent, car cela devient vite affreux lorsqu’il y a beaucoup de cas d’utilisation. Et comme pour plein d’autres choses, une fois que nous avons pris de bonnes habitudes, nous ne les oublierons pas.

Alors, comment remédier à ces liens qui s’entrecoupent?

Pour cela, nous introduirons donc la notion de spécialisation au niveau de certains acteurs.

Cela se justifie si plusieurs acteurs ont besoin d’un ou de plusieurs cas d’utilisation communs et qu’ils ont également besoin de cas d’utilisation spécifiques.

On utilise alors :

  • un acteur générique qui est lié aux cas d’utilisations communs ;

  • des acteurs spécialisés qui sont liés à des cas d’utilisation spécifiques.

On indique qu’un acteur est la spécialisation d’un autre en dessinant une flèche à pointe fermée vers l’acteur principal. 

Diagramme illustrant la spécialisation d’un acteur
Diagramme illustrant la spécialisation d’un acteur

Dans notre étude de cas, on constate que deux acteurs ont les mêmes cas d’utilisation. Pour indiquer cela, nous créons un nouvel acteur générique appelé « Acheteur », dont « Client » et « Commercial » sont des spécialisations. Nous pouvons alors relier l’acteur générique aux cas d’utilisation « Consulter catalogue produits » et « Enregistrer un achat » (voir la figure suivante).

Diagramme de cas d’utilisation, package « Gestion des achats » v5

Je vous ai dit que la spécialisation est également possible au niveau des cas d’utilisation, n’est-ce pas ?
Il va falloir patienter un peu, car notre diagramme ne présente pas encore d’éléments nécessitant cela. Je vous promets que vous verrez la notion de spécialisation de cas d’utilisation avant la fin de ce chapitre. Parole de scout !

D’autres précisions

Regardons de nouveau le diagramme de package « Gestion des achats» dans le détail. Intéressons-nous cette fois-ci au cas d’utilisation « Enregistrer un achat ». L’objectif ici est de détailler les actions au sein de cette fonctionnalité.

Quand on y réfléchit plus en détail, on réalise qu’un acheteur qui enregistre un achat doit forcément constituer un panier (comme cela est souvent le cas lors d’un achat en ligne). La constitution du panier nécessitera plusieurs séquences d’actions :

  • probablement une recherche de produits selon une catégorie ou un nom ;

  • la consultation de la fiche produit ;

  • la validation d’un produit à ajouter au panier ;

  • etc.

Essayons de voir tout ce que l’on doit faire pour « Enregistrer un achat», que l’on soit client ou commercial.

 

Actions ou lots d’actions pour le cas d’utilisation « Enregistrer un achat » :

Le client doit...

Le commercial doit...

1. S’authentifier

1. S’authentifier

2. Constituer un panier

2. Sélectionner le client pour lequel on réalise l’achat

3. Saisir les informations de livraison

3. Constituer un panier

4. Enregistrer le règlement de l’achat

4. Saisir les informations de livraison

 

5. Enregistrer le règlement de l’achat

Vous voyez ? L’enregistrement d’un achat est bien plus complexe que ce qu’on aurait pu penser au début. Ces lots d’actions sont donc des précisions du cas d’utilisation « Enregistrer un achat ». Ces précisions nécessiteront, elles-mêmes, plusieurs actions. On peut en faire des cas d’utilisation internes.

D’accord ! Mais comment est-ce qu’on illustre cela dans le diagramme de cas d’utilisation alors ?

C’est très simple. Tout d’abord, nous allons introduire un nouveau cas d’utilisation, appelé « Constituer panier ». Ce cas d’utilisation sera toujours nécessaire pour la fonctionnalité « Enregistrer un achat ». Le nouveau cas d’utilisation interne sera donc lié au cas d’utilisation principal « Enregistrer un achat » par une flèche représentant la relation dite « Include ». Regardez la figure suivante.

 

Diagramme de cas d’utilisation, package « Gestion des achats » V6

Une relation dite « include » ? Qu’est-ce que c’est ?

Voyons cela dans le chapitre suivant !

Exemple de certificat de réussite
Exemple de certificat de réussite