1. Quesako ?
Une notation
Le concept de cas d’utilisation, appliqué à la conception de logiciel, est formalisé en 1992 par Ivar Jacobson (Méthode OOSE). À l’origine (Jacobson, 1967), le cas d’utilisation est un concept de modélisation pour le développement de grands systèmes de télécommunication. Les spécifications proposent UML pour offrir les concepts (syntaxe abstraite) permettant de représenter (syntaxe concrète) les besoins des utilisateurs de manière simple et compréhensible par toutes les parties prenantes du projet informatique : client, utilisateurs, analystes, développeurs, testeurs, …
Une approche méthodologie des besoins utilisateur
Une démarche “basée cas d’utilisation” consiste à décrire le système du point de vue de ses utilisateurs sous la forme d’interactions (actions et réactions) entre les utilisateurs et le système. Plus connu sous sa forme schématique, le diagramme de cas d’utilisation, les cas d’utilisation contiennent un discours narratif qui décrit comment le système est utilisé par ses utilisateurs. Ce formalisme étant basé sur le langage naturel (textuel). Ainsi, le diagramme de cas d’utilisation et la description textuelle des interactions garantissent que les besoins des utilisateurs finaux sont correctement exprimés, validés par le client, et que les développements produisent un logiciel répondant réellement à ces besoins, ce qui est testé au moment de la recette du produit.
Une unité de gestion de projet
La décomposition d’un système en cas d’utilisation permet d’appréhender plus facilement ce qu’est le système, les services rendus par celui-ci, en divisant sa complexité globale en fonctionnalités plus simple. Mais, d’un point de vue gestion du projet, le cas d’utilisation est aussi une unité d’organisation du projet. Le chef de projet planifie ses itérations projet en réalisant les cas d’utilisation ordonnés par priorité.
2. Premiers éléments de modèle
2.a Cas d’utilisation, acteurs, associations, …
Le diagramme de cas d’utilisation représente le plus simplement possible, le système et ses interactions avec son environnement immédiat. Le système y est décrit, vu de l’extérieur, comme une boîte noire dont on ne connait pas les détails d’implémentation. La dimension technique est laissée elle aussi de côté dans un premier temps, les documents des cas d’utilisation formant les spécifications fonctionnelles du système.
Les éléments principaux du diagramme de cas d’utilisation sont les suivants :
- Les acteurs décrivent les rôles de personnes ou d’autres systèmes qui interagissent directement le système, sujet de l’étude. Définir l’ensemble des acteurs permet de définir l’environnement immédiat du système, ce qui est dans le système et ce qui est à l’extérieur.
- Les cas d’utilisation représentent les fonctionnalités “à gros grains” du système du point de vue des acteurs. Le système est ainsi décomposer en fonctionnalités sans pour autant tomber dans une décomposition fonctionnelle. Le titre du cas d’utilisation représente un objectif particulier de l’acteur lors de son utilisation du système.
- Les associations entre acteurs et cas d’utilisation sont la représentation des interactions entre les acteurs et le système contextualisées par les cas d’utilisation et donc une utilisation du système par un acteur dans un certain but.
- Un scénario d’utilisation est une séquence d’étapes (actions ou réactions) qui décrit une interaction entre acteur et système. Dans un cas d’utilisation, il y a un scénario nominal dans lequel l’acteur principal du cas d’utilisation atteint son objectif et d’autres scénarios alternatifs partageant le même but.
- La description d’un cas d’utilisation est un document qui contient essentiellement les scénarios correspondant à ce cas. Ce document doit respecter un certain format afin de s’assurer que le contexte du cas d’utilisation est bien défini : les cas d’utilisations sont déclenchés par un seul événement déclencheur lorsque le système est dans un état donné décrit par des pré-conditions ; on distingue des rôles principaux (acteur à l’initiative du cas d’utilisation) et des rôles secondaires (acteurs à qui le système peut demander de participer) ; des points d’extension au scénario d’utilisation nominal, peuvent mener, selon des règles prédéfinies, à des scénarios alternatifs ; des post-conditions définissent l’état dans lequel le système doit se trouver après l’exécution correcte du cas d’utilisation.
Remarque : les relations entre cas d’utilisation seront détaillées un peu plus tard.
2.b Notation standard UML
La syntaxe concrète proposée par les spécifications UML est décrite ici. Le système sera représenté par un rectangle nommé par le nom du système. Les acteurs seront représentés soit par des stickmen, soit par le symbole de classe stéréotypé <<actor>>. Les cas d’utilisation sont représentés par des ovales. Le titre du cas d’utilisation est le but de l’utilisation du système par l’acteur. L’acteur est associé au cas d’utilisation par des flèches dirigées.
Exemple :
En ce qui concerne la description d’un cas d’utilisation, même si aucun format n’est imposé, un modèle de document suivant semble revenir souvent :
2.c Collecte des besoins des utilisateurs
Les cas d’utilisation décrivent le système comme une boîte noire, on ne considère pas ce qu’il se passe à l’intérieur. Ils sont définis sans préoccupations techniques
3. Élaboration du diagramme de cas d’utilisation, pas à pas …
3.a Identifier les acteurs
L’acteur représente l’interface du système avec son environnement. L’ensemble des acteurs symbolisent les interactions du système avec son environnement, son périmètre fonctionnelle.
Il n’y a pas d’utilisateurs en UML. En effet, le terme d’utilisateur est bien trop générique. On lui préférera la notion d’acteur est un rôle par rapport au système, joué par un/des humains ou d’autres systèmes. Il est important de ne pas confondre acteurs et utilisateurs. Un utilisateur peut jouer plusieurs rôles, correspondant à plusieurs acteurs et un acteur peut représenter plusieurs utilisateurs.
Comment identifier les acteurs ?
Répertoriez les utilisateurs finaux et autres systèmes interopérants. Identifiez les rôles des différents utilisateurs (machines ou humains) avec lesquels le système doit interagir. Enfin, ne retenez que les acteurs qui interagissent directement avec le système (sans intermédiaire).
Bien définir les acteurs d’un système, c’est être sûr de ce qui est dans le système (ce qu’on doit concevoir) et ce qui n’est pas dans le système (ce qu’on va utiliser ou ce que va utiliser le système).
3.b Identifier les cas d’utilisation
L’ensemble des cas d’utilisation décrit toutes les exigences fonctionnelles du système et donc fait parti des spécifications fonctionnelles. Chaque cas correspond à une fonction métier du système du point de vue de ses utilisateurs.
Nommage des cas d’utilisation
Le titre d’un cas d’utilisation représente l’objectif de son acteur principal. Il faut utiliser un verbe à l’infinitif, suivi d’un complément, en se plaçant du point de vue de l’acteur et non du système.
Niveau de détail
Il ne faut pas tomber dans le travers de la décomposition fonctionnelle. Un nombre pas trop important de cas d’utilisation nuirait à la compréhension de l’ensemble. Il faut voir les cas d’utilisation comme des chapitres de spécifications fonctionnelles.
Enfin, il n’y a pas de notion de temps dans un diagramme de cas d’utilisation. Un cas d’utilisation est indépendant des autres et ne se réalise pas avant ou après un autre cas d’utilisation.
Comment identifier les cas d’utilisation ?
On peut partir des acteurs, mais les notions même d’acteur et de cas d’utilisation sont relatives et se définissent souvent simultanément. Les cas d’utilisation sont les fonctionnalités de système utilisé par les acteurs. Les acteurs sont définis par rapport à leur utilisation du système.
Dans cet exemple, l’acteur Client utilise le système pour Commander un article et le système a besoin d’un acteur SystemeInterbancaire pour réaliser le cas d’utilisation Payer.
3.c Héritage/généralisation entre acteurs
Un acteur ClientFidele hérite d’un acteur Client si
- l’acteur Client peut être remplacé par l’acteur ClientFidele
- tous les cas accessibles par Client le sont aussi par ClientFidele
- l’acteur ClientFidele utilise le système de la même façon, mais peut faire d’autres choses
Comment identifier une relation d’héritage entre acteurs ?
L’origine de l’héritage d’acteur vient du métier. Par exemple, un client muni d’une carte de fidélité peut faire la même chose qu’un client normal, mais en plus il peut utiliser ses points de fidélité.
3.d Trouver les relations entre les cas d’utilisation
Relation d’inclusion entre cas d’utilisation <<include>>
Un cas A inclut un cas B si le comportement décrit par le cas A inclut le comportement du cas B. On dira que A dépend de B. Lorsque le cas d’utilisation A est sollicité, B l’est aussi obligatoirement
La représentation de l’inclusion de cas d’utilisation est la relation de dépendance (flèche en pointillés) stéréotypée <<include>>.
On utilise la relation <<include>> dans deux cas : pour factoriser une partie de la description d’un cas d’utilisation ou pour faire un découpage fonctionnel qui permet de décomposer un cas complexe en sous-cas plus simples.
Dans cet exemple, un client commande un article et doit nécessairement payer. La description du cas d’utilisation Commander un article doit inclure la description du cas d’utilisation Payer.
Relation d’extension entre cas d’utilisation <<extend>>
Un cas d’utilisation B étend un cas d’utilisation A lorsque le cas B peut être appelé au cours de l’exécution du cas A. On dit que le cas A dépend de B.
La représentation de l’extension de cas d’utilisation est la relation de dépendance (flèche en pointillés) stéréotypée <<extend>>.
Le point d’extension est un point précis dans le cas d’utilisation étendu ou le cas d’utilisation d’extension peut se déclencher. Une extension est souvent soumise à condition. Dans ce cas, le point d’extension peut-être accompagné d’une contrainte indiquant le moment où l’extension intervient.
Dans cet exemple, un client muni d’une carte de fidélité consulte son solde de points de fidélité et peut, selon une règle établie, éditer un chèque de fidélité.
Relation d’héritage entre cas d’utilisation
Un cas d’utilisation A est une généralisation d’un cas B, si B est un cas particulier de A. On utilise la relation d’héritage.
Dans cet exemple, le cas d’utilisation Payer est abstrait. La description des modalités de paiement sera en effet différente si on paye par chèque ou si on paye en ligne.
Création de relations selon deux motivations
La création d’une relation peut être motiver par deux choses :
- le fonctionnel. La relation a alors un sens métier (à privilégier)
- l’optimisation du diagramme au sens informatique. Ces relations sont plutôt à éviter pour la bonne compréhension de ce que fait le système
Q. Identifiez-les relations avec un vrai sens métier et les relations d’ordre optimisation informatique, dans le diagramme suivant.
4. Description textuelle d’un cas d’utilisation
- Titre du cas d’utilisation Le titre du cas d’utilisation correspond à l’objectif de l’acteur principal. Forme verbale à l’infinitif
Identification du cas d’utilisation
- Objectif Résumé permettant de comprendre l’intention principale du cas d’utilisation
- Acteur principal Acteur qui est à l’initiative du cas, celui qui réalise le cas d’utilisations
- Acteurs secondaires Acteurs qui reçoivent de l’information, qui sont utilisés par le cas d’utilisation
- Dates de création et mises à jour
- Responsable
- Version
Scénarios
- Scénario nominal Déroulement classique, représentatif du cas
- Scénarios alternatifs Variantes du cas nominal
- Scénarios d’exceptions Survenues d’erreur, le du cas d’utilisation n’est pas atteint
Autres précisions
- Préconditions Elles décrivent l’état dans lequel le système doit être avant le déclenchement du cas d’utilisation
- Postconditions État du système à la fin des différents scénarios
- Exigences non fonctionnelles (ou techniques) Tout ce qui n’entre pas dans la description des scénarios, ou des exigences plus globales
- Règles de gestion Description des besoins en termes d’interface graphique
- Maquettage
5. Autres diagrammes UML utiles pour modéliser les besoins
Diagramme de séquence de niveau expression des besoins
Le diagramme de séquence est un diagramme d’interactions. Il montre l’interaction entre objets pendant l’exécution d’un scénario. C’est un diagramme dynamique dans lequel les échanges entre objets par envois de messages se font dans un ordre chronologique. (cf. Article)
Dans une modélisation orientée objet d’un système, les messages entre objets sont des appels de méthodes. Le nom d’un message correspond alors à une méthode dans la classe de l’objet récepteur du message.
Ce diagramme peut aider à schématiser les scénarios. Il est alors utilisé dans un mode dégradé, pour représenter les interactions acteurs-système.
Diagramme d’activité
Le diagramme d’activité représente les différentes actions qu’un objet peut faire (par exemple la description de chacune de ses méthodes). Les noeuds de décision, de bifurcation ou de synchronisation permettent de représenter un algorithme.
En représentation des besoins, le diagramme d’activité est utilisé pour schématiser un processus métier.
Diagramme d’état
Le diagramme d’état représente tous les états internes qu’un objet ou d’un concept. Les transitions correspondent à des actions opérées sur cet objet par son environnement, le faisant changer d’état.
En représentation des besoins, le diagramme d’état peut schématiser les états du système, ou d’une composante du système. En spécifiant de manière exhaustive tous les états possibles d’un système, l’analyste est certain de ne pas en oublier. Il permet de bien comprendre le comportement d’un système.
