Introduction
Dans ce chapitre vont être abordés les concepts UML fondamentaux pour la spécification des exigences d'un projet informatique:
- les acteurs,
- les cas d'utilisation,
- les relations entre cas d'utilisation,
- la description textuelle d'un cas d'utilisation,
- les scénarios alternatifs et d'erreur
Les exigences d'un projet informatique
Il est essentiel que chaque membre d'une équipe IT ai une connaissance des fonctionnalités exigées (les exigences) par le client. Le diagramme des cas d'utilisation (Use Cases diagram) d'UML permet de présenter synthétiquement les fonctionnalités offertes par le système à chaque acteur (type d'utilisateurs).
Chaque cas d'utilisation doit également être accompagné d'une description des opérations, obligatoires et facultatives, qu'implique la réalisation de la fonctionnalité ainsi que la formalisation des hypothèses préalables (préconditions) et des résultats vérifiables attendus(postconditions).
Compréhension d'un diagramme UC
Voici les différents diagrammes UC du projet web...
En quelques mots, comment décririez-vous l'application décrite ci-dessus ?
Réponse...
C'est un réseau social dédié au partage de liste de lecture de vidéos (chaines).
Cette application est-elle destinée à un usage interne d'une entreprise ou à tout internaute ?
Réponse...
Bien que la possibilité pour un membre de supprimer son compte soit un indice, le diagramme ne permet pas de répondre à cette question avec certitude. Nous avons besoin de connaitre plus précisément ce que recouvre l'UC "S'authentifier". La description de l'UC que nous verrons ultérieurement permet de lever toute ambiguïté.
Le diagramme UC
Les cas d'utilisation (UC)
Un UC est un ensemble cohérent de plusieurs opérations. Sans doute, une des plus fréquentes difficultés rencontrées lors de la modélisation d'un système par un diagramme de UC est de déterminer le niveau de granularité du schéma ("taille du grain" représente la quantité d'opérations regroupées dans un même UC). En effet, si les grains sont trop petits, le schéma devient difficilement compréhensible par la multiplication des UC et des associations.
À l'inverse, si les grains sont trop gros, le schéma peut masquer des fonctionnalités importantes qui sont sous-jacentes d'un UC.
Comme vous pouvez le constater dans les diagrammes UC du projet web, la modélisation peut être organisée en différents diagrammes UC pour détailler certaines UC trop complexes sans multiplier le nombre de UC sur le même diagramme.
Libellé d'un UC
Le libellé d'un UC doit représenter une action. Il est donc préférable que ce libellé commence par un verbe à l'infinitif suivi d'un complément explicatif en quelques mots.
Le libellé des UC est à choisir avec soin pour être "le moins ambigu possible". Par exemple: "Imprimer facture" plutôt que "Générer document".
Dans ce cours, par convention, un libellé qui commence par "Gérer" sous-entend les 4 opérations CRUD (Create, Read, Update, Delete) sur le concept associé. (Exemple: UC "Gérer membres" implique la consultation du listing des membres, ainsi que l'ajout, la modification et la suppression d'un membre.).
Pareillement, nous considérerons par convention qu'un libellé qui commence par "Éditer" sous-entend les opérations C et U; c-à-d l'ajout et la modification. (Exemple: UC "Éditer compte" implique la création ou la modification d'un compte).
Les acteurs
Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel ou autre système) qui interagit directement avec le système étudié. Un acteur peut consulter et/ou modifier directement l'état du système (ses données à un instant t), en émettant et/ou en recevant des messages susceptibles d'être porteurs de données.
Il ne faut pas considérer un acteur comme une entité concrète. Ainsi un utilisateur peut bénéficier de plusieurs rôles (exemple: une personne peut être à la fois éditeur de contenus et administrateur d'une plateforme elearning); de même un rôle peut être attribué à plusieurs personnes (c'est d'ailleurs le cas en général).
Les use cases associés à un acteur constituent ses privilèges:les fonctionnalités (UC) qu'il a le droit d'utiliser; ou ses responsabilités: les fonctionnalités (UC) auxquelles il est susceptible de contribuer.
Un acteur qui possède au moins un privilège est un acteur primaire et est placé du côté gauche du système.
Un acteur qui n'a que des responsabilités est un acteur secondaire et est placé du côté droit du système.
Association acteur et UC
La liaison entre un acteur et un UC est représentée par un trait simple.
Certains auteurs préconisent l'usage d'une flèche directionnelle entre un UC et un acteur secondaire pour indiquer si celui-ci ne fait que réceptionner ou envoyer des données au système.
Cardinalités sur association acteur et UC
Dans une association UML, la cardinalité représente le nombre d'entités par un intervalle de valeurs entières comprises entre un minimum et un maximum inclus. Exemples:
- "2...*": 2 entités minimum,
- "0...1": une seule entité facultative.
Lorsque la cardinalité est exprimée du côté acteur de l'association, cela indique une contrainte sur le nombre d'entités acteur impliquées pour réaliser une UC. Ainsi dans l'exemple ci-dessous, jouer une partie FPS online requiert au moins 2 joueurs.
Lorsque la cardinalité est exprimée du côté UC de l'association, cela indique que une contrainte sur le nombre d'usages en parallèle du UC par une même entité acteur. Dans l'exemple ci-dessous, il faut imaginer une interface qui permet à l'utilisateur de cliquer sur une catégorie pour demander que l'actualisation des news associées. Ensuite durant le temps de rafraichissement de cette catégorie, il a la possibilité de cliquer sur une autre catégorie pour demander son actualisation également. Si, par contre, le système permettait à l'utilisateur d'actualiser toutes ou plusieurs catégories sélectionnées d'un coup, il ne faut pas écrire de cardinalité dans l'association mais simplement la nommer au pluriel: "Rafraichir catégories"
Spécialisation des acteurs
Lorsque qu'un acteur A bénéficie de tous les privilèges d'un acteur B en plus des siens propres, on le représente comme une version spécialisée de B (flèche de A vers B) afin de ne pas alourdir le schéma en dédoublant les associations vers les UC communs.
Usage de la spécialisation des acteurs
Que pensez-vous de la relation de spécialisation ci-dessus ?
Réponse...
C'est erroné. Bien entendu, un personne qui est vendeur dans le magasin a aussi la possibilité d'être client du magasin; mais dans ce cas, elle endosse un autre rôle (elle devient temporairement un autre acteur.). Conceptuellement, un vendeur n'est pas un client !
Comment corrigeriez-vous ce diagramme ?
Réponse...
Relations entre UC
La relation d'inclusion
La relation d'inclusion est une relation dirigée entre deux cas d'utilisation qui est utilisée pour montrer que les opérations du cas d'utilisation inclus (l'ajout) sont insérées dans les opérations du cas d'utilisation d'inclusion (la base).
La relation d'inclusion peut être utilisée:
- pour simplifier les cas d'utilisation volumineux en les divisant en plusieurs cas d'utilisation,
Exemple: <<include>> pour découper un UC complexe - pour extraire les parties communes des comportements de deux ou plusieurs cas d'utilisation.
Exemple: <<include>> pour isoler opérations communes entre plusieurs UC
La réalisation d'un UC inclus dans un autre est systématique et obligatoire à la réalisation de ce dernier.
Le sens de la relation d'inclusion
Que pensez-vous de la relation d'inclusion ci-dessus ?
Réponse...
Le sens des flèches d'inclusion est erronée. En effet, cela voudrait dire que "Déposer billets" contient "Authentifier client" et "Déposer billets" n'est donc associé à aucun acteur. Le raisonnement vaut également pour "Retirer Argent".
Ce diagramme serait-il correctement corrigé si "Déposer billets" et "Retirer Argent" étaient tous les deux associés à l'acteur "Client" ?
Réponse...
Oui et non... Tout dépend de ce qu'on entend par "Authentifier client"; cela peut être correct si "Authentifier client" implique la vérification d'une session ouverte par le client (il est déjà authentifié), et si ce n'est pas le cas, la demande du code PIN associé à la carte. Par contre, si "Authentifier client" ne consiste qu'à la demande du code PIN sans conservation de la session, cela voudrait dire qu'un client ne peut effectuer plusieurs retraits/dépôts sans systématiquement encoder à chaque fois son code PIN pour s'authentifier.
Utilisation judicieuse de la relation d'inclusion
Que pensez-vous des relations d'inclusion ci-dessus ?
Réponse...
Comme dans l'exemple précédent, tout dépend de ce qui est sous-entendu par "Se connecter". Cependant, même si "Se connecter" ne demande les informations de connexion à l'utilisateur que s'il n'est pas déjà authentifié, ces multiples relations d'inclusion rendent le diagramme peu lisible. Il vaut mieux associer "Se connecter" à l'utilisateur "Internaute" et les UC qui nécessitent d'être authentifié à un autre acteur; par exemple: "Membre".
La relation d'extension
La relation d'extension est une relation dirigée qui spécifie comment et quand les opérations définies dans un cas d'utilisation d'extension généralement supplémentaires (facultatives) peuvent être insérées dans les opérations définies dans le cas d'utilisation étendu.
Le cas d'utilisation étendu est significatif en soi, il est indépendant du cas d'utilisation d'extension. L'extension du cas d'utilisation définit généralement des opérations facultatives qui ne sont pas nécessairement significatives en soi. Le même cas d'utilisation d'extension peut étendre plus d'un cas d'utilisation, et le cas d'utilisation d'extension peut lui-même être étendu.
Utilisation judicieuse de la relation d'extension
Que pensez-vous des relations d'extension ci-dessus ?
Réponse...
Ce n'est pas forcément incorrect mais cela alourdit le diagramme inutilement. L'ajout d'un nouvel acteur "connecté" permettrait d'éviter ces multiples relations.
Utilisation judicieuse de la relation d'extension
Que pensez-vous des relations d'extension ci-dessus ?
Réponse...
Ce n'est pas correct. Le UC "Payer" est "inaccessible" puisqu'il n'y a pas d'acteur relié, et que "S'abonner revue" et "Commander un magazine" ne sont que des extensions de "Payer".
Suffirait-il donc de relier "Payer" à "Client" ?
Réponse...
Ce n'est pas correct non plus. Du point de vue fonctionnel pour le client, "Payer" n'est pas une fin en soi; c'est plutôt une séquence d'opérations impliquées soit par la souscription d'un abonnement soit par l'achat d'un magazine. Il faudrait plutôt remplacer les relations d'extension par des relations d'inclusion.
La relation de spécialisation
La relation de spécialisation (ou de généralisation en fonction des ouvrages) spécifie une variante d'opérations (UC "enfant") qui peut être réalisée à la place d'un UC (UC "parent").
Le UC "parent" peut être déclaré abstrait; dans ce cas, le UC ne peut être réalisé en lui-même; seules les variantes spécialisées peuvent être réalisées.
Résumé des différentes relations entre UC
Inclusion <<include>>
Le UC de base ne peut être réalisé seul;
la réalisation de chaque UC "inclus" est obligatoire.
Extension <<extend>>
Le UC de base peut être réalisé seul;
la réalisation d'une UC d'extension est facultative.
Spécialisation
Le UC "parent" peut être abstrait ou non;
si le UC "parent" est abstrait, une UC spécialisée au moins est obligatoire.
Description UC
Importance de la description textuelle
Le diagramme des UC est utile pour avoir une vision d'ensemble des fonctionnalités offertes par le système. Cependant, un libellé d'UC ne peut se suffire à lui-même pour exprimer l'ensemble des opérations nécessaires à sa résolution.
Idéalement, chaque UC du diagramme doit être accompagné d'une spécification explicative, indépendante de toute interface.
Template de spécification d'un UC
Il n'y a pas de formalisme standardisé au sein d'UML pour la description textuelle d'un UC. Cependant, dans le cadre de ce cours, nous adopterons un template qui reprend les informations usuelles liées à un UC:
- Libellé du UC,
- Acteur(s): noms des acteurs liés au UC,
- Objectif(s): description courte des attentes des acteurs concernés,
- Précondition(s): conditions qui doivent être vraies pour que le UC puisse commencer à se réaliser,
- Postconditions(s): conditions qui doivent être vraies lorsque le UC termine de se réaliser,
- Scénario nominal: représentation de la séquence d'étapes qui permet le plus fréquemment de réaliser l'UC,
- Scénario(s) alternatif(s): représentations des variations de séquence d'étapes qui permettent également de réaliser l'UC,
- Scénario(s) d'erreur: représentation des variations de séquence d'étapes qui ne permettent pas à l'UC de se réaliser complètement (les postconditions ne peuvent être toutes vraies).
Scénario nominal
Chaque scénario va être présenté sous forme d'un tableau dont chaque colonne correspond à un acteur primaire, au système proprement dit ou à un acteur secondaire impliqué dans le scénario.
Chaque étape du scénario est numérotée pour indiquer clairement la séquence des étapes.
Le scénario nominal est le premier scénario qui est rédigé et présente soit le scénario le plus court ou le plus fréquent pour parvenir à la réalisation complète du UC (postconditions vraies).
Scénarios alternatifs
Chaque scénario alternatif est précédé d'un libellé commençant par le numéro de la première étape nominale qui varie suivie d'une lettre (a->z) et d'une courte phrase explicative.
Par exemple, un scénario alternatif 3b est le deuxième scénario alternatif qui peut commencer à la 3ième étape du scénario nominal.
Le scénario alternatif est présenté comme le scénario nominal sous forme d'un tableau: une colonne par acteur et les étapes numérotées à partir de 1. La dernière étape du scénario alternatif indique à quelle étape du scénario nominal la réalisation du UC se poursuit.
Imbrication de scénarios alternatifs
Tout comme le scénario nominal, un scénario alternatif peut lui-même avoir variantes... Les scénarios alternatifs d'un scénario alternatif vont être identifiés par une numérotation en plusieurs niveaux.
Dans l'exemple ci-dessus, le scénario nominal du UC "S'authentifier" décrit comment un utilisateur possédant un identifiant et un mot de passe peut s'authentifier dans l'application. Le scénario alternatif 1b permet à l'utilisateur ne possédant pas de compte de s'en créer un afin de pouvoir malgré tout s'authentifier. Ce même scénario possède une alternative 1b.4a qui démarre à la 4ième étape du scénario alternatif 1b si l'utilisateur n'entre pas des données valides.
Scénarios d'erreur
Un scénario d'erreur est un scénario qui va clôturer celui-ci sans pouvoir satisfaire les postconditions. Ces scénarios peuvent soit être présentés sous forme de tableaux (comme les autres scénarios), soit sous forme d'une simple phrase si ces scénarios ne comportent qu'une étape.
Un scénario d'erreur n'est pas un scénario qui provoque une exception du code informatique !
Cohérence entre diagramme UC et les spécifications
Eviter la redondance
Lors de la rédaction de la spécification d'un Use Case, il est inutile de décrire les étapes correspondantes à un des scénarios d'un autre Use Case. Toute redondance entraine une perte de temps, à la rédaction comme à la lecture, et risque d'être porteuse d'incohérence.
Dans l'exemple ci-dessus, le diagramme UC contient l'UC "Gérer dépense" et l'UC "Rechercher dépense". Comme nous l'avons convenu ensemble, le terme "gérer" englobe les opérations de création, modification et suppression. La spécification du UC "Gérer dépense" décrit dans le scénario nominal les étapes correspondantes à la création d'une nouvelle dépense. La modification, tout comme la suppression, nécessite de sélectionner la dépense concernée. Pour éviter de décrire les étapes de recherche d'une dépense, le scénario alternatif 1a renvoie à la spécification du UC "Rechercher dépense".
UC inclus
Dans le diagramme UC, lorsqu'un UC est inclus dans un autre, cela implique que lorsque la fonctionnalité de ce dernier est utilisée, quelque soit le scénario nominal ou alternatif suivi, la fonctionnalité du UC inclus doit systématiquement être utilisée.
Dans l'exemple ci-dessus, lorsqu'un utilisateur souhaite confirmer ou refuser l'invitation de participation à groupe de partage de dépenses, la fonctionnalité d'affichage du groupe est d'office utilisée. Soit l'utilisateur accepte sa participation, l'application lui affiche directement la page de groupe; soit l'utilisateur souhaite refuser, l'application affiche une demande de confirmation en lui affichant également la page du groupe, afin de s'assurer que l'utilisateur puisse prendre une décision éclairée.
Dans la spécification du UC "Rejoindre groupe", l'appel au UC "Consulter groupe" apparait dans le scénario nominal et le scénario alternatif 1a. Quant au scénario alternatif 1b, puisqu'à l'étape 1 le scénario nominal reprend à l'étape 2, l'UC "Consulter Groupe" est donc appelé également. Seuls les scénarios d'erreur ne font pas forcément appel à l'UC inclus.
UC extension
Contrairement à un UC inclus, un UC qui étend est optionnel. Donc dans la spécification d'un UC, l'appel à un UC qui étend doit être présent dans un des scénarios du UC, nominal ou alternatif; mais certains de ces scénarios sont réalisables sans faire appel au UC facultatif. En effet, sinon, le UC serait inclus (tous les scénarios y font appel) et ne serait pas un simple extension.
Dans le diagramme UC de l'exemple ci-dessus, l'UC "Gérer scan facture" est une extension de l'UC "Gérer dépense". En effet, lors de l'encodage d'une dépense dans l'application, l'utilisateur peut y associer une photo du ticket de caisse ou de la facture s'il le souhaite. Dans la spécification du UC "Gérer dépense", l'appel au UC "Gérer scan facture" est présent uniquement dans le scénario alternatif 1a.2a.
User Story (US)
Dans la méthodologie Agile de gestion de projet informatique, les équipes de développement découpent souvent les fonctionnalités du projet en User Stories ou US.
Une User Story est rédigée sous la forme d'une simple phrase, plus ou moins longue, qui exprime qui souhaite faire quoi et dans quel but.
En tant qu'utilisateur, je souhaite solder mon groupe afin de rééquilibrer les dépenses effectuées et de déterminer qui doit rembourser qui et de combien.
L'écriture d'une US est donc plus rapide, souple que celle d'un UC. Par contre, le manque de description détaillée ne permet pas de visualiser les étapes nécessaires à mettre en place ni de voir facilement les dépendances (utilisation, extension ou inclusion) entre US
Dans la pratique, une US correspond généralement à l'un des scénarios d'un UC et on lui associe des tests d'acceptions; c.-à-d. des tests qui devront être réussis pour considérer la US fonctionnelle.
Conclusion
En résumé
Le diagramme UC offre une vision globale des fonctionnalités d'un système. Chaque UC correspond à une fonctionnalité du point de vue d'un utilisateur final du système.
Plusieurs types d'utilisateurs finaux (les acteurs) peuvent bénéficier de privilèges différents (accès à l'utilisation de certaines fonctionnalités) ou avoir des responsabilités différentes (contribution requise dans la réalisation d'un ou plusieurs UC). Un acteur qui n'a que des responsabilités est considéré comme acteur secondaire et placé à droite du système modélisé.
Un UC peut être inclus dans un autre, étendre un autre ou encore être une version spécialisée d'un autre UC.
Chaque UC devrait au minimum être accompagné d'une description. Dans l'idéal, cette description prend le formalisme d'une spécification qui détaille les différents scénarios possibles dans la réalisation de ce UC.