Diagramme de cas d’utilisation - UML

INTRODUCTION

UML offre la possibilité de créer une variété de modèles pour représenter un système. Chacun de ces modèles offre une perspective différente sur le système, qu'il s'agisse de la vue depuis l'utilisateur, de la structure interne, d'une vision globale ou détaillée. Ces modèles ne sont pas isolés les uns des autres, mais se complètent mutuellement et peuvent être intégrés. Ils sont élaborés tout au long du cycle de développement d'un système, depuis la collecte initiale des besoins jusqu'à la phase de conception. Dans ce chapitre, nous allons nous pencher sur l'un de ces modèles, à savoir le diagramme de cas d'utilisation. Ce diagramme joue un rôle essentiel dans la collecte, l'analyse et l'organisation des besoins d'un système. Il marque le début de la phase d'analyse du système en permettant de visualiser les interactions entre les acteurs et le système lui-même, ainsi que les fonctionnalités principales attendues.

L'importance d'une collecte de besoins efficace

Quand il s'agit de développer un nouveau système ou d'améliorer un système existant, il est crucial de s'assurer que les besoins sont correctement identifiés et compris. Par exemple, une banque pourrait avoir le besoin d'un guichet automatique pour permettre à ses clients de retirer de l'argent en dehors des heures d'ouverture de la banque. Dans ce scénario, le maître d'ouvrage est la personne ou l'entité responsable de la commande du logiciel, tandis que le maître d'œuvre est chargé de sa réalisation.

Le maître d'ouvrage joue un rôle essentiel tout au long du projet, en particulier pour :

1. Définir et exprimer clairement les besoins.
2. Valider les solutions proposées par le maître d'œuvre.
3. Valider le produit final livré.

Le maître d'œuvre, souvent représenté par une société de services en informatique (SSII), est choisi principalement pour ses compétences techniques, mais son expertise va au-delà. Dès le début du projet, il doit être capable de recueillir de manière efficace les besoins du maître d'ouvrage. Cela implique une compréhension approfondie du secteur d'activité concerné. Par exemple, la création d'un logiciel pour une banque nécessite une connaissance approfondie du secteur bancaire, y compris toutes les contraintes et les exigences spécifiques.

Chaque cas d'utilisation exprimé par le client présente des particularités liées à son secteur d'activité. La collecte des besoins peut être réalisée de diverses manières, mais il est recommandé de compléter le cahier des charges par des discussions approfondies avec le maître d'ouvrage et les futurs utilisateurs du système. Il est également essentiel d'examiner tous les documents pertinents (rapports techniques, études de marché, etc.) et d'étudier les procédures administratives des fonctions de l'entreprise qui seront prises en charge par le système.

Pendant la collecte des besoins, le maître d'œuvre doit se poser la question suivante : dispose-t-il de toutes les connaissances et informations nécessaires pour définir précisément les fonctionnalités que le système doit offrir ?

Le diagramme de cas d'utilisation : Un outil essentiel

Le diagramme de cas d'utilisation est un élément essentiel lorsqu'il s'agit de travailler avec UML pour le recueil des besoins.

UML, en lui-même, est simplement un langage, et son utilité réside dans sa capacité à formaliser les besoins. En d'autres termes, il permet de représenter ces besoins de manière graphique, de manière suffisamment claire et simple pour que toutes les personnes impliquées dans un projet puissent les comprendre. Il est important de rappeler que très souvent, le maître d'ouvrage et les utilisateurs finaux ne sont pas des informaticiens, ils ont donc besoin d'un moyen simple et accessible pour exprimer leurs besoins. C'est précisément ce que les diagrammes de cas d'utilisation offrent.

Les diagrammes de cas d'utilisation servent à identifier et à répertorier les principales fonctionnalités d'un système. Ils permettent de visualiser de manière synthétique comment les acteurs (utilisateurs ou autres systèmes) interagissent avec le système, quelles actions ils réalisent, et quelles sont les fonctionnalités offertes par le système en réponse à ces actions. En résumé, les diagrammes de cas d'utilisation sont un outil puissant pour comprendre et documenter les exigences du projet de manière compréhensible pour toutes les parties prenantes.

EXEMPLE : La figure ci-dessous modélise une borne interactive qui permet d’accéder à une banque. Le système à modéliser apparaît dans un cadre (cela permet de séparer le système à modéliser du monde extérieur). Les utilisateurs sont représentés par des petits bonshommes, et les grandes fonctionnalités (les cas d’utilisation) par des ellipses.

L’ensemble des cas d’utilisation contenus dans le cadre constitue « un sujet ». Les petits bonshommes sont appelés « acteurs ». Ils sont connectés par de simples traits (appelés « associations ») aux cas d’utilisation et mettent en évidence les interactions possibles entre le système et le monde extérieur. Chaque cas modélise une façon particulière et cohérente d’utiliser un système pour un acteur donné.
 

Définition d'un cas d'utilisation

Un cas d'utilisation est une représentation spécifique de la manière dont un système est utilisé. Dans cette représentation, les acteurs, qui sont des entités extérieures au système, sont utilisés pour modéliser toutes les interactions avec ce dernier. Un cas d'utilisation décrit un scénario complet, de son déclenchement initial à son déroulement et jusqu'à sa conclusion, tout en se concentrant sur le service qu'il offre à l'acteur qui l'initie. En résumé, un cas d'utilisation permet de décrire comment un acteur interagit avec un système pour accomplir une tâche ou atteindre un objectif spécifique.

Notation et spécification
 Un cas d’utilisation se représente par une ellipse (figure ci-dessous). Le nom du cas est inclus dans l’ellipse ou bien il figure dessous. Un stéréotype (voir la définition ci-après), peut être ajouté optionnellement au-dessus du nom, et une liste de propriétés placée au-dessous. Un cas d’utilisation se représente aussi sous la forme d’un rectangle à deux compartiments : celui du haut contient le nom du cas ainsi qu’une ellipse (symbole d’un cas d’utilisation) ; celui du bas est optionnel et peut contenir une liste de propriétés (figure ci-dessous). Un acteur se représente par un petit bonhomme ayant son nom inscrit dessous (figure ci-dessous) ou par un rectangle contenant le stéréotype acteur avec son nom juste en dessous (figure ci-dessous). Il est recommandé d’ajouter un commentaire sur l’acteur pour préciser son rôle.

La figure ci-dessous représente un acteur par un rectangle. UML utilise aussi les rectangles pour représenter des classes, et plus généralement des classeurs. Pour autant, la notation n’est pas ambiguë puisque le stéréotype  acteur indique que le rectangle désigne un acteur. Les stéréotypes permettent d’adapter le langage à des situations particulières.

Définition Un stéréotype représente une variation d’un élément de modèle existant.
 

À un niveau d’abstraction plus élevé, UML permet de représenter tous les cas d’utilisation d’un système par un simple rectangle. La figurec-dessous montre comment un tel rectangle peut remplacer tous les cas d’utilisation de la figure 1

Le rectangle de la figure est appelé « classeur ».
 

Définition d'un classeur

Un classeur est un élément de modélisation utilisé dans le contexte de la conception de systèmes. Il sert à décrire une unité, qu'elle soit de nature comportementale ou structurelle. Les acteurs, qui représentent les entités externes interagissant avec un système, et les cas d'utilisation, qui décrivent les scénarios d'utilisation d'un système, sont des exemples de classeurs couramment utilisés dans la modélisation.

Il convient de noter que le terme "classeur" est un concept générique qui englobe divers types d'unités de modélisation, notamment les classes (dans le contexte de la programmation orientée objet), les parties d'un système, et d'autres éléments similaires. Cette notion de "classeur" est utilisée pour simplifier la discussion et l'organisation des différents éléments lors de la modélisation d'un système, en les regroupant sous une seule catégorie générale.

Notation
 Un classeur se représente par un rectangle contenant éventuellement des compartiments (la figure ci-dessous montre comment il est possible de faire figurer explicitement des cas d’utilisation dans un classeur).

Un acteur peut utiliser plusieurs fois le même cas d’utilisation.
 
EXEMPLE La figure ci-dessous montre un internaute qui télécharge plusieurs morceaux de musique sur Internet.

Le symbole * qui signifie « plusieurs » est ajouté à l’extrémité du cas et s’appelle une multiplicité. Plusieurs valeurs sont possibles pour la multiplicité : exactement n s’écrit tout simplement n, m..n signifie entre m et n, etc. Préciser une multiplicité sur une relation n’implique pas nécessairement que les cas sont utilisés en même temps.
 

relations entre cas d'utilisations :

Les relations entre les cas d'utilisation en UML sont essentielles pour clarifier les interactions et les dépendances entre les différentes fonctionnalités d'un système. Voici une explication des principaux types de relations entre les cas d'utilisation :

Relation d'inclusion (inclusion) :

Cette relation indique qu'un cas d'utilisation A est inclus dans un autre cas d'utilisation B.

Elle signifie que le comportement décrit par A est inclus dans le comportement global de B. En d'autres termes, B dépend de A.

Cette dépendance est symbolisée par le stéréotype "inclus".

Exemple : Dans le contexte d'une banque, l'accès aux informations d'un compte bancaire (cas A) est inclus dans le processus de transaction bancaire (cas B), car il nécessite une phase d'authentification avec un mot de passe.

Relation d'extension (extension) :

Cette relation indique qu'un cas d'utilisation A peut étendre le comportement d'un autre cas d'utilisation B.

L'extension est souvent soumise à une condition, qui est exprimée graphiquement sous la forme d'une note.

Exemple : Dans une banque, la vérification du solde du compte (cas A) peut étendre le processus de retrait d'argent (cas B) uniquement si la demande de retrait dépasse 20 euros.

Relation de généralisation/spécialisation (généralisation) :

Cette relation indique qu'un cas d'utilisation A est une généralisation d'un cas d'utilisation B.

Cela signifie que B est un cas particulier de A. A est plus général, tandis que B est plus spécifique.

Exemple : Dans le contexte bancaire, la consultation d'un compte bancaire via Internet (cas A) est une généralisation de la consultation de compte (cas B).

Ces relations aident à organiser et à hiérarchiser les cas d'utilisation dans un diagramme UML, ce qui facilite la compréhension et la gestion des fonctionnalités du système. Les relations d'inclusion et d'extension sont particulièrement utiles pour décomposer un cas complexe en sous-cas plus simples, améliorant ainsi la lisibilité et la modularité du modèle.

EXEMPLE À la figure ci-dessous le modélisateur a jugé que la vente d’un article par correspondance est un problème complexe et qu’il est important de faire apparaître dans le modèle une décomposition en sous-cas.

Notation et spécification Une dépendance se représente par une flèche pointillée. Un stéréotype est souvent ajouté au-dessus du trait. Le stéréotype inclut indique que la relation de dépendance est une inclusion (figures 1.8 et 1.9). Le stéréotype étend indique une extension (figure 1.8). L’extension peut intervenir à un point précis du cas étendu ; ce point s’appelle le point d’extension ; il porte un nom, qui figure dans un compartiment du cas étendu sous la rubrique « point d’extension », et est éventuellement associé à une contrainte indiquant le moment où l’extension intervient. Une extension est souvent soumise à une condition (indiquée dans une note attachée à la flèche pointillée). Le symbole utilisé pour la généralisation est une flèche en traits pleins dont la pointe est un triangle fermé. La flèche pointe vers le cas le plus général (figure 1.8).

Un cas relié à un autre cas peut ne pas être directement accessible à un acteur (figure 1.9). Un tel cas est appelé « cas interne ».

Définition Un cas d’utilisation est dit « interne » s’il n’est pas relié directement à un acteur.

Les relations entre cas ne sont pas obligatoires. Elles permettent de clarifier et d’enrichir les cas d’utilisation. Par exemple, à la figure 1.8, rien n’empêche de regrouper les cas « Consulter comptes » et « Consulter sur Internet » en un seul cas. Cependant, indiquer dès la phase de recueil des besoins qu’il y a des cas particuliers apporte une information supplémentaire pertinente. La question à se poser est : faut-il la faire figurer dans le diagramme de cas d’utilisation ou la prendre en compte plus tard ? La réponse à cette question ne sera pas toujours la même selon le contexte du projet.

Remarque Attention à l’orientation des flèches : si le cas A inclut B on trace la flèche de A vers B, mais si B étend A, la flèche est dirigée de B vers A.

RELATIONS ENTRES ACTEURS

La seule relation possible entre deux acteurs est la généralisation : un acteur A est une généralisation d’un acteur B si l’acteur A peut être substitué par l’acteur B (tous les cas d’utilisation accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai). La figure ci-dessous montre que le directeur des ventes est un préposé aux commandes avec un pouvoir supplémentaire (en plus de pouvoir passer et suivre une commande, il peut gérer le stock). Le préposé aux commandes ne peut pas gérer le stock.

Notation Le symbole utilisé pour la généralisation entre acteurs est une flèche en traits pleins dont la pointe est un triangle fermé. La flèche pointe vers l’acteur le plus général.

REGROUPEMENT DES CAS D'UTILISATION EN PAQUETAGES

En effet, UML offre la possibilité de regrouper des cas d'utilisation dans des entités appelées "paquetages". Ce regroupement peut être effectué de différentes manières pour organiser efficacement les cas d'utilisation dans un diagramme de cas d'utilisation. Voici quelques points importants à retenir :

Regroupement par Acteur :

Vous pouvez organiser des cas d'utilisation en les associant à des acteurs spécifiques. Cela signifie que les cas d'utilisation sont regroupés en fonction des acteurs qui les initient ou les utilisent. Cette approche permet de montrer clairement quelles fonctionnalités sont liées à chaque acteur dans le système.

Regroupement par Domaine Fonctionnel :

Vous pouvez également organiser des cas d'utilisation en fonction de leur domaine fonctionnel. Cela signifie que les cas d'utilisation sont regroupés en fonction de la catégorie ou de la fonction à laquelle ils appartiennent. Par exemple, vous pourriez regrouper tous les cas d'utilisation liés aux opérations bancaires, tels que la consultation de compte, le retrait d'argent, le virement, etc., dans un paquetage "Opérations Bancaires".

Hiérarchie de Paquetages :

Vous pouvez créer une hiérarchie de paquetages en incorporant un paquetage dans un autre paquetage. Cela permet de structurer davantage le modèle. Par exemple, vous pourriez avoir un paquetage principal appelé "Système Bancaire" qui contient plusieurs sous-paquetages tels que "Opérations Bancaires", "Gestion des Clients", etc. L'utilisation de paquetages permet de rendre le modèle plus modulaire, plus organisé et plus facile à gérer. Il offre également une représentation visuelle claire de la structure fonctionnelle du système, que ce soit en fonction des acteurs ou des domaines fonctionnels.

En résumé, les paquetages sont une fonctionnalité essentielle d'UML qui vous permet de regrouper et d'organiser efficacement les cas d'utilisation dans un diagramme de cas d'utilisation, en fonction de vos besoins de modélisation.

Définition Un paquetage permet d’organiser des éléments de modélisation en groupe. Un paquetage peut contenir des classes, des cas d’utilisations, des interfaces, etc.

EXEMPLE À la figure ci-dessous, trois paquetages ont été créés : Client, Stock et Support. Ces paquetages contiennent les cas d’utilisation du diagramme de la figure 1.10 (Client contient les cas « Passer une commande » et « Suivre une commande », Stock contient le cas « Gérer le stock », tandis que le cas « Rechercher article » est inclus dans le paquetage Support.

En tant que langage, UML est soumis à des règles de nommage qu’il faut strictement respecter : pour accéder au contenu de paquetages imbriqués les uns dans les autres, il faut utiliser des deux-points comme séparateur des noms de paquetage. Par exemple, si un paquetage B inclus dans un paquetage A contient une classe X, il faut écrire A::B::X pour pouvoir utiliser la classe X en dehors du contexte des paquetages.