Modélisation UML/Le diagramme de cas d'utilisation
1. Les Cas d'Utilisation
[modifier | modifier le wikicode]Présentation
[modifier | modifier le wikicode]Notre système (ou logiciel) est une boîte qui contient d’autres boîtes, les packages . Chaque package est donc une boîte qu’il faudra ouvrir pour en découvrir le contenu. Le contenu d’un package est illustré par différents diagrammes. Un de ces diagrammes représente les cas d’utilisation, c’est-à-dire les fonctionnalités ou lots d’actions que devront réaliser nos acteurs. Le diagramme de cas d'utilisation représente les fonctionnalités nécessaires aux utilisateurs. On peut faire un diagramme de cas d'utilisation pour le logiciel entier ou pour chaque package.
Ci-dessous un exemple de diagramme de cas d'utilisation pour un package (gestion des stocks).
Le diagramme des cas d'utilisation illustre ce que le logiciel doit permettre de faire.
Exemple: Comment réaliser le diagramme de cas d'utilisation?
[modifier | modifier le wikicode]Nous allons prendre l'exemple du package "gestion des achats". Il faut donc identifier toutes les fonctionnalités dont les différents acteurs concernés par le package auront besoin. Dans notre projet de réalisation d'une boutique en ligne, nous indiquons qu'un client devra pouvoir utiliser le site pour consulter le catalogue des produits. Nous pouvons en déduire que le catalogue des produits est un cas d'utilisation.
Le cas d’utilisation « Consulter le catalogue » de l’acteur principal « Client » est représenté sous forme d’ellipse.
On le schématise ainsi:
Un cas d’utilisation n’est pas forcément lié à un seul acteur. Nous pouvons indiquer qu’un commercial devra également pouvoir consulter le catalogue des produits (par exemple, pour montrer des caractéristiques d’un produit lors d’une visite chez son client) en reliant cet acteur au même cas d’utilisation.
En observant la demande de notre client nous pouvons noter les besoins suivants:
Le diagramme ci-dessous nous donne une version de diagramme de cas d’utilisation un peu plus complète.
Il nous manque encore un élément, le cas d’utilisation « Enregistrer un achat ».
Résumé Nous avons :
[modifier | modifier le wikicode]- - défini le contexte du futur logiciel, en identifiant les différents acteurs;
- - décomposé le système en packages, c’est-à-dire les familles de fonctionnalités;
- - illustré les fonctionnalités principales pour un des packages, grâce aux cas d’utilisation.
Conclusion
[modifier | modifier le wikicode]- Un logiciel à développer est considéré comme un système, vu au départ comme une boîte noire.
- Le système est utilisé par des acteurs principaux, et parfois, il peut être lié à des acteurs secondaires. Les acteurs secondaires échangent des informations avec le système, mais ne déclenchent aucune des fonctionnalités.
- Un système peut être composé de plusieurs packages. Chacun des packages contient une famille de fonctionnalités nécessaires aux acteurs.
- Les fonctionnalités utiles aux acteurs sont appelées des cas d’utilisation. Un diagramme de cas d’utilisation permet d’illustrer QUI devrait pouvoir faire QUOI, grâce au système. Il en existe un par package.
2.Cas d'Utilisation Interne
[modifier | modifier le wikicode]Il existe des cas plus complexes que ce que nous venons de voir. Il s’agit dans ce cas souvent de cas d’utilisation dont le scénario renvoie vers d’autre cas d’utilisation: les cas d’utilisation internes.
Définition
[modifier | modifier le wikicode]Les cas d’utilisation que nous avons découvert dans la partie 1 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 des 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.
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.
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.
Exemple
[modifier | modifier le wikicode]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 (dernier schéma de la partie 1).
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.
Le diagramme reste lisible puisqu’il n’y a pas trop de liens qui se croisent mais il faut éviter, car cela devient vite affreux lorsqu’il y a beaucoup de cas d’utilisation.
Pour cela, nous introduirons la notion de spécialisation au niveau de certains acteurs.
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 vers l’acteur principal.
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 »
La spécialisation est également possible au niveau des cas d’utilisation, voyons cela dans l'exemple ci-dessous:
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é.
Reprenons l'exemple du diagramme de le "Gestion d'achats", on réalise qu’un acheteur qui enregistre un achat en ligne peut constituer un panier. Celle-ci nécessitera plusieurs étapes :
- - une recherche de produits selon une catégorie;
- - la consultation de la fiche produit ;
- - la validation d’un produit à ajouter au panier ;
- etc.
- Le schéma ci-dessous illustre notre exemple:
- Nous avons
- introduit un nouveau cas d’utilisation interne , appelé « Constituer panier ». Ce cas d’utilisation sera nécessaire et lié au cas d'utilisation principal « Enregistrer un achat » par une flèche représentant la relation dite « Include ».
- La relation « include » est utilisée pour indiquer que le cas d’utilisation source (départ de la flèche) contient TOUJOURS le cas d’utilisation inclus.Dans le schéma précédent, le cas d’utilisation source « Enregistrer un achat » contiendra TOUJOURS le cas d’utilisation « Constituer un panier ».
Dans la version précédente de notre diagramme, l’acteur « Système bancaire » était lié au cas d’utilisation « Enregistrer un achat ». Maintenant que ce cas d’utilisation a été complété par des cas d’utilisation internes, nous pouvons être plus précis. Nous avons donc déplacé ce lien vers le cas d’utilisation : « Enregistrement règlement ».
Nous remarquons ci-dessus une relation "extend" entre "Sélectionner un client" et "Enregistrer un achat".
En effet, une relation « extend » est utilisée pour indiquer que le cas d’utilisation source (à l’origine de la flèche) n’est pas toujours nécessaire au cas d’utilisation principal, mais qu’il peut l’être dans certaines situations. On doit alors préciser la condition qui fera que le cas d’utilisation en « extend » est nécessaire.
Dans exemple le cas d’utilisation interne « Sélectionner le client » n’étant pas une action obligatoire au cas d’utilisation principal « Enregistrer un achat », on peut dès lors parler de relation « extend ».
Dès lors qu’il y a une relation « extend », il faudra toujours définir la condition, c’est-à-dire : à quelle condition cette relation peut avoir lieu ? Pour indiquer cela, il faut ajouter une ligne « extension points » et définir la condition « EXT ».
Le cas d’utilisation « Sélectionner un client » est une relation « extend » du cas d’utilisation principal « Enregistrer un achat ». Cette action n’est possible qu’à condition que l’acteur soit le « Commercial », et non pas le « Client ».
Résumé
[modifier | modifier le wikicode]- Les cas d’utilisation principaux sont complétés par des cas d’utilisation internes, qui sont des précisions d’autres cas d’utilisation.
- Les cas d’utilisation internes sont reliés au cas initial par des relations de type « include » ou « extend ».
- Une relation « include » permet d’indiquer qu’un cas d’utilisation a toujours besoin du cas d’utilisation lié.
- Une relation « extend » c’est une relation qui est soumise à une condition.On doit toujours expliciter la condition qui doit être rencontrée pour que le cas d’utilisation lié soit utile.
