Diagrammes de cas d'utilisation

Une partie importante du langage de modélisation unifié (UML) est la possibilité de dessiner des diagrammes de cas d'utilisation. Les cas d'utilisation sont utilisés pendant la phase d'analyse d'un projet pour identifier et partitionner les fonctionnalités du système. Ils séparent le système en acteurs et en cas d'utilisation. Les acteurs représentent des rôles que peuvent jouer les utilisateurs du système.

Ces utilisateurs peuvent être des humains, d'autres ordinateurs, des éléments matériels ou même d'autres systèmes logiciels. Le seul critère est qu'ils doivent être externes à la partie du système partitionnée en cas d'utilisation. Ils doivent fournir des stimuli à cette partie du système et doivent en recevoir des extrants.

Les cas d'utilisation représentent les activités que les acteurs exécutent avec l'aide de votre système dans la poursuite d'un objectif. Nous devons définir ce que ces utilisateurs (acteurs) ont besoin du système. Le cas d'utilisation doit refléter les besoins et les objectifs de l'utilisateur et doit être initié par un acteur. Les entreprises, les acteurs, les clients participant au cas d'utilisation métier doivent être connectés au cas d'utilisation par association.

Dessin de diagrammes de cas d'utilisation

La figure ci-dessous montre à quoi un cas d'utilisation pourrait ressembler à une forme schématique UML. Le cas d'utilisation lui-même ressemble à un ovale. Les acteurs sont dessinés comme de petites figures de bâton. Les acteurs sont connectés au cas d'utilisation avec des lignes.

Use-case 1 - Le vendeur vérifie un article

• Le client place l'article sur le comptoir.
• «Utilise» Swipe UPC Reader.
• Le système recherche le code UPC dans la base de données fournissant la description et le prix de l'article
• Le système émet un bip sonore.
• Le système annonce la description de l'article et le prix via la sortie vocale.
• Le système ajoute le prix et le type d'article à la facture actuelle.
• Le système ajoute le prix pour corriger le sous-total des taxes

Ainsi, la relation «utilise» ressemble beaucoup à un appel de fonction ou à un sous-programme.

Le cas d'utilisation utilisé de cette manière est appelé un cas d'utilisation abstrait car il ne peut pas exister seul mais doit être utilisé par d'autres cas d'utilisation.

Exemple ─ Cas d'utilisation de retrait

L'objectif d'un client par rapport à notre distributeur automatique d'argent (GAB) est de retirer de l'argent. Donc, nous ajoutonsWithdrawalcas d'utilisation. Retirer de l'argent du distributeur automatique peut impliquer une banque pour les transactions à effectuer. Donc, nous ajoutons également un autre acteur -Bank. Les deux acteurs participant au cas d'utilisation doivent être connectés au cas d'utilisation par association.

Le distributeur automatique d'argent fournit un cas d'utilisation de retrait pour le client et les acteurs de la banque.

Relations entre acteurs et cas d'utilisation

Les cas d'utilisation peuvent être organisés en utilisant les relations suivantes -

• Generalization
• Association
• Extend
• Include

Généralisation entre les cas d'utilisation

Il peut y avoir des cas où les acteurs sont associés à des cas d'utilisation similaires. Dans ce cas, un cas d'utilisation enfant hérite des propriétés et du comportement de l'utilisation parent. Il faut donc généraliser l'acteur pour montrer l'héritage des fonctions. Ils sont représentés par une ligne continue avec une grande pointe de flèche triangulaire creuse.

Association entre cas d'utilisation

Les associations entre acteurs et cas d'utilisation sont indiquées dans les diagrammes de cas d'utilisation par des lignes pleines. Une association existe chaque fois qu'un acteur est impliqué dans une interaction décrite par un cas d'utilisation.

Étendre

Certaines fonctions sont déclenchées en option. Dans de tels cas, la relation d'extension est utilisée et la règle d'extension lui est attachée. Il ne faut pas oublier que le cas d'utilisation de base doit être capable d'exécuter une fonction seul même si le cas d'utilisation d'extension n'est pas appelé.

La relation d'extension est représentée par une ligne en pointillés avec une pointe de flèche ouverte dirigée du cas d'utilisation d'extension vers le cas d'utilisation étendu (de base). La flèche est étiquetée avec le mot-clé «étendre».

Comprendre

Il est utilisé pour extraire des fragments de cas d'utilisation qui sont dupliqués dans plusieurs cas d'utilisation. Il est également utilisé pour simplifier un grand cas d'utilisation en le divisant en plusieurs cas d'utilisation et pour extraire des parties communes des comportements de deux ou plusieurs cas d'utilisation.

Incluez la relation entre les cas d'utilisation qui est indiquée par une flèche en pointillé avec une pointe de flèche ouverte entre le cas d'utilisation de base et le cas d'utilisation inclus. La flèche est étiquetée avec le mot-clé «inclure».

Les cas d'utilisation ne concernent que les exigences fonctionnelles d'un système. D'autres exigences telles que les règles métier, les exigences de qualité de service et les contraintes d'implémentation doivent être représentées séparément.

Le diagramme ci-dessous est un exemple de diagramme de cas d'utilisation simple avec tous les éléments marqués.

Principes de base pour une application réussie des cas d'utilisation

• Restez simple en racontant des histoires
• Soyez productif sans perfection
• Comprenez la vue d'ensemble
• Identifier les opportunités de réutilisation pour les cas d'utilisation
• Focus sur la valeur
• Construisez le système en tranches
• Livrer le système par incréments
• S'adapter pour répondre aux besoins de l'équipe

Modèle de cas d'utilisation

Ici, nous avons montré un exemple de modèle de cas d'utilisation qu'un analyste commercial peut remplir afin que les informations puissent être utiles à l'équipe technique pour obtenir des informations sur le projet.

ID de cas d'utilisation:
Nom du cas d'utilisation:
Créé par:		Dernière mise à jour par
Date créée:		Date de la dernière mise à jour
Acteur:
La description:
Conditions préalables:
Conditions postales:
Priorité:
Fréquence d'utilisation:
Cours normal des événements:
Cours alternatifs:
Des exceptions:
Comprend:
Besoins spéciaux:
Hypothèses:
Notes et problèmes: