Diagramme de cas d'utilisation
Ne pas confondre avec les cas d'utilisation.
Pour les articles homonymes, voir DCU.
Cet article est une ébauche concernant l’informatique.
Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.
Les diagrammes de cas d'utilisation (DCU) sont des diagrammes UML utilisés pour une représentation du comportement fonctionnel d'un système logiciel. Ils sont utiles pour des présentations auprès de la direction ou des acteurs d'un projet, mais pour le développement, les cas d'utilisation sont plus appropriés. En effet, un cas d'utilisation (use cases) représente une unité discrète d'interaction entre un utilisateur (humain ou machine) et un système. Ainsi, dans un diagramme de cas d'utilisation, les utilisateurs sont appelés acteurs (actors), et ils apparaissent dans les cas d'utilisation.
Cas d'utilisation modifier
Ils permettent de décrire l'interaction entre l'acteur et le système. L'idée forte est de dire que l'utilisateur d'un système logiciel a un objectif quand il utilise le système ! Le cas d'utilisation est une description des interactions qui vont permettre à l'acteur d'atteindre son objectif en utilisant le système. Les use case (cas d'utilisation) sont représentés par une ellipse sous-titrée par le nom du cas d'utilisation (éventuellement le nom est placé dans l'ellipse). Un acteur et un cas d'utilisation sont mis en relation par une association représentée par une ligne.
Le plus souvent, le diagramme de cas d'utilisation est établi par la maîtrise d'ouvrage (MOA) d'un projet lors de la rédaction du cahier des charges afin de transmettre les besoins des utilisateurs et les fonctionnalités attendues associées à la maîtrise d'œuvre (MOE).
Acteurs modifier
Ils sont des entités externes qui interagissent avec le système, comme une personne humaine ou un robot. Une même personne (ou robot) peut être plusieurs acteurs pour un système, c'est pourquoi les acteurs doivent surtout être décrits par leur rôle, ce rôle décrit les besoins et les capacités de l'acteur. Un acteur agit sur le système. L'activité du système a pour objectif de satisfaire les besoins de l'acteur. Les acteurs sont représentés par un pictogramme humanoïde (stick man) sous-titré par le nom de l'acteur.
Catégories d'acteurs modifier
Un acteur peut avoir différents rôles et est amené à intervenir dans une ou plusieurs situations. Miller (2001) en identifie quatre.
- Initiateur : acteur qui active le système et déclenche le cas.
- Serveur : acteur aidant le système à assumer ses responsabilités.
- Receveur : acteur recevant les informations du système (système de backup)
- Facilitateur : acteur dont les actions sont effectuées au bénéfice d'un autre acteur
Relations modifier
Trois types de relations sont prises en charge par la norme UML et sont graphiquement représentées par des types particuliers de ces relations. Les relations indiquent que le cas d'utilisation source présente les mêmes conditions d'exécution que le cas issu. Une relation simple entre un acteur et une utilisation est un trait simple.
Inclusions modifier
Dans ce type d'interaction, le premier cas d'utilisation inclut le second et son issue dépend souvent de la résolution du second. Ce type de description est utile pour extraire un ensemble de sous-comportements communs à plusieurs tâches, comme une macro en programmation. Elle est représentée par une flèche en pointillé et le terme include.
Extensions modifier
Les extensions (extend) représentent des prolongements logiques de certaines tâches sous certaines conditions. Autrement dit un cas d'utilisation A étend un cas d'utilisation B lorsque le cas d'utilisation A peut être appelé au cours de l'exécution du cas d'utilisation B. Elle est représentée par une flèche en pointillée avec le terme extend. Ce type de relation peut être utile pour traiter des cas particuliers ou fonctions optionnelles, préciser les objectifs, ou encore pour tenir compte de nouvelles exigences au cours de la maintenance du système et de son évolution.
Généralisations modifier
La troisième relation est la relation de généralisation ou spécialisation. Le cas d'utilisation A est une généralisation de B, si B est un cas particulier de A c'est-à-dire lorsque A peut être substitué par B pour un cas précis. Ces relations sont des traits pleins terminés par une flèche en triangle.
Relations entre acteurs modifier
Il est également possible d'appliquer à un acteur la relation de généralisation. Cela se fait notamment lorsqu'un acteur est un sous-type d'une autre catégorie d'acteurs. Un acteur lié à un autre par ce type de relation peut interagir avec le système de plus de manières que son parent.
Autres éléments modifier
- Les réalisations décrivent un cas d'utilisation par une suite de collaborations d'autres éléments du modèle de données. Ce type de schématisation n'est pas propre à l'UML mais constitue un des éléments du Processus Unifié.
Voir aussi modifier
Articles connexes modifier
Liens externes modifier
- (fr) Laurent Audibert, « Chapitre 2 Diagramme de cas d'utilisation », sur developpez.com
- (fr) Olivier Capuozzo, "Cas d'utilisation, une introduction",
- (en) Miller, G. (2001)." Introduction to diagramme sequence",
- UML Les quatre types de relations
