L'ensemble des éléments de ce TP a été rédigé par Lang Alexandre
Le diagramme de cas d'utilisation décrit les grandes fonctions d'un système du point de vue des acteurs, mais n'expose pas de façon détaillée le dialogue entre les acteurs et les cas d'utilisation. Bien que de nombreux diagrammes d'UML permettent de décrire un cas, il est recommandé de rédiger une description textuelle, car c'est une forme souple qui convient dans bien des situations.
Comme un cas d’utilisation représente une action que peut réaliser un acteur avec le système ces descriptions textuelles permettront de mieux comprendre comment ces cas d’utilisation sont mis en œuvre. Autrement dit cela permettra de décrire tout ce qui va se passer quand l’acteur réalisera ce cas d’utilisation.
- Objectif 1 : Rappeler comment on réaliser une description complète d'un cas d'utilisation
- Objectif 2 : Réaliser une descriprion complète d'un cas d'utilisation
- Objectif 3 : Tester, à l'aide d'un scénario réel, la description d'un cas d'utilisation
- Objectif 4 : Réaliser une maquette basse fidélité pour un cas d'utilisation
Une description textuelle couramment utilisée se compose de trois parties qui permettent un niveau de détail plus ou moins élevé selon ce qu’on souhaite.
3.1. Identification du cas d’utilisation
La première partie permet d'identifier le cas, elle doit contenir les informations qui suivent.
Nom :
Utiliser une tournure à l'infinitif (ex. : Réceptionner un colis). Cela peut être le nom du cas d’utilisation dont on fait la description.
Résumé :
Un résumé permettant de comprendre l'intention principale du cas d'utilisation. Cela permet de faire quoi pour celui qui le réalise ?
Acteurs principaux :
Ceux qui vont réaliser le cas d'utilisation (la relation avec le cas d'utilisation est illustrée par le trait liant le cas d'utilisation et l'acteur dans un diagramme de cas d'utilisation).
Acteurs secondaires :
Ceux qui ne font que recevoir des informations à l'issue de la réalisation du cas d'utilisation. En général il s’agit du système.
Dates :
Les dates de création et de mise à jour de la description courante.
Responsable :
Le nom des responsables.
Version :
Le numéro de la version.
3.2. Description du fonctionnement
La deuxième partie contient la description du fonctionnement du cas sous la forme d'une séquence de messages échangés entre les acteurs et le système. Elle contient toujours une séquence nominale qui décrit de déroulement normal du cas (tout fonctionne bien).
À la séquence nominale s'ajoutent fréquemment des séquences alternatives (des embranchements dans la séquence nominale) et des séquences d'exceptions (qui interviennent quand une erreur se produit).
Ces séquences peuvent aussi porter le nom de « flot » : flot nominal, flot alternatif, flot d’erreur.
Ces flots, qui forment des scénarii, peuvent être entourés par deux éléments supplémentaires : les préconditions et les post conditions.
Les préconditions :
Elles décrivent dans quel état doit être le système (l'application) avant pour que ce cas d'utilisation puisse être déclenché.
Attention néanmoins à ne jamais faire référence à d’autres cas d’utilisation.
Des scénarii :
Ces scénarii sont décrits sous la forme d'échanges d'événements entre l'acteur et le système. On distingue le scénario nominal, qui se déroule quand il n'y a pas d'erreur, des scénarii alternatifs qui sont les variantes du scénario nominal et enfin les scénarii d'exception qui décrivent les cas d'erreurs.
Les post-conditions :
Elles décrivent l'état du système à l'issue des différents scénarii.
3.3. Spécifications non fonctionnelles
La troisième partie de la description d'un cas d'utilisation est une rubrique optionnelle.
Elle contient généralement des spécifications non fonctionnelles (spécifications techniques…). Cela peut consister à faire la description de certaines contraintes liées à ce cas d’utilisation comme par exemple le temps de réponse, la concurrence, la disponibilité,…
Elle peut éventuellement contenir une description des besoins en termes d'interface graphique (IHM,…).
La rédaction des scénarii constitue l’étape la plus important de la description textuelle. En effet, comme nous l’avons dit plus haut, ces scénarii permettront de comprendre le cas d’utilisation de manière très clair puisqu’on envisage toutes les possibilités ou du moins les possibilités essentielles au bon fonctionnement du cas d’utilisation et par conséquent du système.
Néanmoins quelques règles sont à respecter.
Il faut voir les scénarii comme une succession d’action à réaliser c’est-à-dire que pour chaque ligne on lui associe une seule action et surtout un numéro qui s’incrémente de 1 à chaque fois qu’on créé une nouvelle ligne.
Comme les scénarii décrivent ce qui passe entre les acteurs et le système ce sera soit les acteurs soit le système qui sera au cœur de l’action décrite. Par conséquent pour chaque action on devra utiliser la voix active et employer le nom des acteurs tels qu’ils ont été définis lors de l’élaboration des cas d’utilisation.
Ex :
Au lieu de dire « Le carnet de bord est réalisé par Alexandre et Rémy » on dira « Alexandre et Rémy réalisent le carnet de bord ».
La voix active met en jeu le sujet, c’est le sujet qui fait l’action et par conséquent on utilise principalement le présent de l’indicatif.
Lors de la déclaration de flots alternatifs ou de flots d’erreurs il est important de préciser, en première, de quelle cas alternatifs ou d’erreurs il s’agit. On peut considérer cela comme les préconditions de ces flots puisque cela nous dit dans quelles conditions, dans quel état on doit se trouver pour entrer dans ces flots.
Lors de la déclaration de ces « préconditions » il ne faudra pas indiquer le numéro de la ligne mais le numéro de la ligne du flot nominale qui a engendré ces flots.
Si l’on souhaite créer plusieurs flot alternatifs/erreurs pour une même ligne du flot nominal il suffit, dans les « préconditions » de ces flots de faire suivre le numéro de la ligne, du flot nominal qui a engendré ces flots, par une lettre qui évoluera plus on créera de flots supplémentaires.
Ex :
Identification du cas d’utilisation
Préconditions
Flot nominal :
1- Action 1
2- Action 2
Flot alternatif :
1- Flot alternatif de la 1ère ligne
1) Action 1 du flot alternatif 1
2) Action 2 du flot alternatif 1
2- a) 1er flot alternatif de la 2ème ligne
1) Action 1 du flot alternatif 2a
2) Action 2 du flot alternatif 2a
2- b) 2ème flot alternatif de la 2ème ligne
1) Action 1 du flot alternatif 2b
2) Action 2 du flot alternatif 2b
Post-conditions
Exigences non fonctionnelles
Ensuite, pour tous les flots, il est important qu’à chaque fois qu’un acteur demande de faire quelque chose au système, ce dernier lui renvoie une réponse pour savoir si l’action demandée a bien été réalisée ou non.
A noter également que les flots alternatifs se terminent toujours par un retour vers le flot nominal (terme jump to) tandis que les flots d’erreur, sauf contradictions, se finissent par la sortie prématurée du scénario sans retour au flot nominal (terme exit). Dans ce dernier cas on indique quand même l’état dans lequel le système se trouve. On peut considérer cela comme les post-conditions en cas d’erreur en sachant qu’elles peuvent être différentes d’un flot d’erreur à un autre.
Ex :
Identification du cas d’utilisation
Préconditions
Flot nominal :
1- Action 1
2- Action 2
3- Action 3
Flot alternatif :
1- Flot alternatif de la 1ère ligne
1) Action 1 du flot alternatif 1
2) Action 2 du flot alternatif 1
3) Jump to 3- // A la fin de ce flot alternatif on reviendra à la ligne 3 du flot nominal. On saute la ligne 2 !
Flot d’erreur
2- Flot d’erreur de la 2ème ligne
1) Action 1 du flot d’erreur 2
2) Action 2 du flot d’erreur 2
3) Post-conditions du flot d’erreur 2
4) Exit // On sort du scénario, plus aucune ligne du flot nominal ne sera exécutée
Post-conditions
Exigences non fonctionnelles
On peut voir l’exemple précédent sous la forme schématique suivante :
Pour cette nouvelle application nous allons reprendre l’énoncé et le résultat obtenu au TP n°1 qui portait sur l’élaboration d’un diagramme de cas d’utilisation.
A noter que nous continuerons à utiliser le logiciel Visual Paradigm en version 12.2.
Reprenons donc l’énoncé d’un garage, le « Smart garage » en modifiant un peu le 8ème point :
1. Pour faire réparer son véhicule, un client doit prendre rendez-vous à l’avance avec une secrétaire du garage qui enregistre le rendez-vous dans le SI du garage.
2. Le chef d’atelier consulte chaque matin la liste des rendez-vous de la journée.
3. Le jour convenu, le client présente sa voiture à la réception du garage et précise au chef d’atelier les révisions et réparations à faire. Le chef d’atelier en prend note sur une fiche suiveuse informatisée, qu'il imprime et fait signer au client avant de lui en remettre une copie. Il affecte à la voiture une puce dédiée, qui est posée sur le tableau de bord, qui permet d'identifier la voiture automatiquement.
4. Les mécaniciens peuvent consulter toutes les fiches suiveuses.
5. Les mécaniciens peuvent également consulter les travaux précédents réalisés sur la voiture si elle a déjà été réparée par le garage.
6. Au début et à la fin de chaque réparation, le mécanicien complète la fiche suiveuse en précisant la réparation réalisée sur le véhicule, ce qui permet le calcul du temps maximal passé sur les réparations. Pour saisir le début et la fin d'une réparation, le mécanicien peut utiliser un boitier spécialisé (fourni par la société “TrustMyMechanic”) auquel il présente son badge et la puce associée à la voiture et sélectionne s'il s'agit du début ou de la fin d'une réparation et le numéro du type de réparation (Il est ainsi possible de traiter les cas où un mécanicien a oublié de signaler un début ou une fin de réparation, on ne cherchera pas pour l'instant à faire mieux).
7. La secrétaire utilise le SI pour préparer les factures.
8. Quand le client se présente pour retirer le véhicule, la secrétaire, Mme Martinez, lui remet la facture et encaisse le paiement. Si des factures sont encore en attente de paiement, elle les encaisse également et enregistre le règlement dans le SI. Il est possible dans certains cas, qu'elle lui rende la voiture sans paiement, par exemple dans le cas où des travaux n'ont pas encore été faits. Elle enregistre dans le SI que la voiture a été rendue.
Le temps de réponse du système de paiement est estimé à 5 secondes.
9. Un client peut à tout moment savoir où en est la réparation de sa voiture (Site web) : en cours de réparation, réparations faîtes, factures prêtes, …
A la fin du TP précèdent nous avions obtenu le diagramme de cas d’utilisation suivant après avoir identifié le système, les acteurs et leur cas d’utilisation associés :
Et le glossaire associé :
Nous allons maintenant faire la description textuelle du cas d’utilisation « Enregistrer le règlement et le rendu d’une voiture » effectué par l’acteur Secrétaire dont l’énoncé est le suivant.
8. Quand le client se présente pour retirer le véhicule, la secrétaire, Mme Martinez, lui remet la facture et encaisse le paiement. Si des factures sont encore en attente de paiement, elle les encaisse également et enregistre le règlement dans le SI. Il est possible dans certains cas, qu'elle lui rende la voiture sans paiement, par exemple dans le cas où des travaux n'ont pas encore été faits. Elle enregistre dans le SI que la voiture a été rendue.
Le temps de réponse du système de paiement est estimé à 5 secondes.
Pour cela nous allons faire étape par étape afin d’obtenir à la fin une description aussi complète que possible. Pour chaque étape on détaillera aussi précisément que possible et le résultat sera surligné en gras.
Etape 1 : Identification du cas d’utilisation
Pour commencer nous allons identifier le cas à l’aide des informations qui suivent :
Nom :
On peut reprendre ici le nom de notre cas d’utilisation du moment qu’il commence par un verbe à l’infinitif :
Enregistrer le règlement et le rendu d’une voiture
Résumé :
Ce résumé doit décrire l’intention principale du cas d’utilisation.
Ce cas d’utilisation permet à une Secrétaire du Smart garage d’effectuer et d’enregistrer un règlement d’un client pour une réparation ou une révision effectuée sur sa voiture. Il permet aussi d’enregistrer, dans le système informatisé, que la voiture a été rendue.
Acteurs principaux :
Les acteurs principaux seront ceux qui réaliseront ce cas d’utilisation. Ils se repèrent facilement dans le diagramme de cas d’utilisation car ce sont ceux qui sont directement liés au cas d’utilisation.
La Secrétaire du Smart garage
Acteurs secondaires :
Il s’agit de ceux qui ne font que recevoir des informations à l'issue de la réalisation du cas d'utilisation. En général il s’agit du système.
Le Smart garage ou système informatisé
Dates :
Les dates de création et de mise à jour de la description courante.
On peut ici imaginer mettre comme date de création et de mise à jour la date courante puisque l’on est en train de créé cette fiche puis, à chaque modification, on changera la date de mise à jour.
Date de création : 19/03/16
Date de mise à jour : 19/03/16
Responsable :
Le nom des responsables associés à ce cas d’utilisation.
Mme Martinez, la secrétaire du Smart garage
Version :
Le numéro de la version.
S’agissant de la création de cette fiche on peut mettre le plus petit numéro.
1.0
Nous avons donc créé la fiche qui permettra d’identifier ce cas d’utilisation.
Etape 2 : Description du fonctionnement
Cette étape doit permettre de décrire de manière très précise le mode de fonctionnement du cas d’utilisation. Les questions à se poser tout au long sont : que se passe-t-il quand on met en œuvre ce cas d’utilisation ? Que font les acteurs à chaque moment ?
Commençons par écrire les préconditions
Les préconditions :
Elles décrivent dans quel état doit être le système (l'application) avant pour que ce cas d'utilisation puisse être déclenché.
Attention néanmoins à ne jamais faire référence à d’autres cas d’utilisation.
Le système attend qu’on le sollicite
Passons ensuite aux scénarii :
Des scénarii :
Ces scénarii sont décrits sous la forme d'échanges d'événements entre l'acteur et le système. On distingue le scénario nominal, qui se déroule quand il n'y a pas d'erreur, des scénarii alternatifs qui sont les variantes du scénario nominal et enfin les scénarii d'exception qui décrivent les cas d'erreurs.
Flot nominal :
Que se passe-t-il après que le secrétaire ait remis la facture au client ?
On peut imaginer que la secrétaire va chercher à savoir si le client a encore des factures impayées qu’elle pourrait également lui faire régler.
Que fait alors la secrétaire, acteur principal de ce cas d’utilisation ? Ne pas oublier de numéroter chaque ligne !
1- La secrétaire entre les informations personnelles du client dans le système informatisé du Smart garage et demande l’affichage des informations du client et de son véhicule. (qu’on pourra abréger par « le système »).
Il ne faut pas oublier qu’à chaque fois qu’un acteur interagit avec le système ce dernier doit lui répondre !
2- Le système confirme à la secrétaire que le client a été trouvé et affiche les informations du client et de son véhicule et signale que toutes les réparations ont été effectuées.
Avec cette dernière action on peut imaginer un premier flot d’erreur : le cas où le client n’est pas trouvé dans le système.
Flot d’erreurs :
2- Le système ne trouve pas le client
1- Le système signale à la secrétaire que le client n’a pas été trouvé
2- Exit
Poursuivons quand même l’écriture de notre flot nominale dans le cas où le client est bien trouvé par le système.
Flot nominal :
3- La secrétaire cherche d’autres factures que le client pourrait régler.
4- Le système affiche les factures impayées du client
5- La secrétaire entre le montant total à payer dans le système
6- La secrétaire demande au client de régler le montant à payer
Dans ce que nous avons écrit ci-dessus on voit qu’on peut définir un flot alternatif : le cas où aucune facture en attente n’est trouvée.
Flot alternatif :
Pour ce flot alternatif on peut envisager reprendre à partir du 4 :
4- Le système ne trouve aucune facture supplémentaire impayées
1- Jump to 5
On revient directement à la 5ème ligne du flot nominal car il n’y a rien de plus à dire ou faire quand aucune facture supplémentaire n’est trouvée.
On continue le flot nominal.
Flot nominal :
7- Le client entre ses informations bancaires dans le système
8- Le système affiche qu’il est en train d’établir la connexion avec le système de paiement
9- Le système a réussi à se connecter au système de paiement
10- Le système affiche qu’il a bien établi la connexion avec le système de paiement
11- Le système crédite le compte du client du montant indiqué
On voit ici qu’on peut définir un autre flot d’erreur : le cas où le système n’arrive pas à établir la connexion avec le système de paiement.
Flot d’erreurs :
9- Le système n’a pas réussi à se connecter au système de paiement
1- Le système affiche qu’il n’a pas réussi à établir la connexion avec le système de paiement
2- Exit
On voit également ici qu’on peut définir un autre flot alternatif : le cas où le système n’arrive pas à se connecter car les informations entrées par le client sont erronées.
Flot alternatif :
9- Le système n’a pas réussi à se connecter au système de paiement pour cause de mauvaises informations entrées
1- Le système affiche qu’il n’a pas réussi à se connecter pour cause de mauvaises informations entrées
2- Jump to 7
Dans le précédent flot alternatif on laisse la possibilité au client, dans le cas où il entre des informations personnelles fausses, d’essayer à nouveau de se connecter.
Flot nominal :
12- Le système affiche que le règlement a bien été effectué
13- La secrétaire enregistre dans le système que le véhicule a été rendu
14- Le système enregistre que le véhicule a été rendu
15- Le système affiche qu’il a bien enregistré le rendu du véhicule
Maintenant que notre scénario nominal est terminé il nous faut envisager un dernier flot alternatif : le cas où il reste des réparations à effectuer sur le véhicule et par conséquent que le client repart avec son véhicule sans payer.
Comme de toute façon la secrétaire enregistrera que la voiture a été rendue même s’il reste des réparations à effectuer on peut sauter toute l’étape où le client effectue le paiement.
Flot alternatif :
2- Le système confirme à la secrétaire que le client a été trouvé et affiche les informations du client et de sa voiture et signale qu’il reste des réparations à effectuer
1- Jump to 13
On termine finalement cette étape de la description avec les post-conditions
Les post conditions (du flot nominal) :
Elles décrivent l'état du système à l'issue des différents scénarii.
Le système informatisé a enregistré que la voiture a été rendue au client
En effet on ne peut pas mettre que le règlement a été effectué dans les post-conditions car nous avons le cas où la voiture a été rendue alors que le client n’a pas effectué de paiement car il reste des réparations à effectuer sur son véhicule.
On obtient ainsi, pour l’étape 2, la description suivante (sans les commentaires) :
Préconditions :
Le système attend qu’on le sollicite
Flot nominal :
1- La secrétaire entre les informations personnelles du client dans le système informatisé du Smart garage et demande l’affichage des informations du client et de son véhicule.
2- Le système confirme à la secrétaire que le client a été trouvé et affiche les informations du client et de son véhicule et signale que toutes les réparations ont été effectuées.
3- La secrétaire cherche d’autres factures que le client pourrait régler.
4- Le système affiche les factures impayées du client
5- La secrétaire entre le montant total à payer dans le système
6- La secrétaire demande au client de régler le montant à payer
7- Le client entre ses informations bancaires dans le système
8- Le système affiche qu’il est en train d’établir la connexion avec le système de paiement
9- Le système a réussi à se connecter au système de paiement
10- Le système affiche qu’il a bien établi la connexion avec le système de paiement
11- Le système crédite le compte du client du montant indiqué
12- Le système affiche que le règlement a bien été effectué
13- La secrétaire enregistre dans le système que le véhicule a été rendu
14- Le système enregistre que le véhicule a été rendu
15- Le système affiche qu’il a bien enregistré le rendu du véhicule
Flot alternatif :
2- a) Le système ne trouve aucune facture supplémentaire impayées
1- Jump to 5
2- b) Le système confirme à la secrétaire que le client a été trouvé et affiche les informations du client et de sa voiture et signale qu’il reste des réparations à effectuer
1- Jump to 13
9- Le système n’a pas réussi à se connecter au système de paiement pour cause de mauvaises informations entrées
1- Le système affiche qu’il n’a pas réussi à se connecter pour cause de mauvaises informations entrées
2- Jump to 7
Flot d’erreurs :
2- Le système ne trouve pas le client
1- Le système signale à la secrétaire que le client n’a pas été trouvé
2- Exit
9- Le système n’a pas réussi à se connecter au système de paiement
1- Le système affiche qu’il n’a pas réussi à établir la connexion avec le système de paiement
2- Exit
Post-conditions :
Le système informatisé a enregistré que la voiture a été rendue au client
Etape 3 : Spécifications non fonctionnelles
Dans l’énoncé considéré on apprend que le temps de réponse du système de paiement est estimé à 5 secondes. Il s’agit d’une spécification non fonctionnelle.
Temps de réponse du système de paiement : 5 secondes.
Nous avons donc obtenu pour le cas d’utilisation « Enregistrer le règlement et le rendu d’une voiture » une description aussi complète que possible.
Grâce à cette description nous connaissons mieux les fonctionnements généraux de ce cas d’utilisation ce qui pourrait nous aider dans le cas où l’on réaliserait l’implémentation de ce cas d’utilisation (le code).
Maintenant que nous avons élaboré notre description complète d’un cas d’utilisation en 3 étapes dans la partie précédente nous avons la possibilité de nous arrêter-là en pensant que notre description est parfaite.
Le problème c’est qu’avec nos yeux de développeurs nous n’avons pas forcement la même vue qu’un utilisateur lambda.
En élaborant notre scénario nous l’avons fait selon notre point de vue et il possible que l’on ait oublié certaines étapes clés.
C’est pourquoi il est conseillé, comme à chaque fois que l’on élabore quelque chose, de le tester.
Pour cela il faut prendre un scénario issu d’une situation de la vie réelle et voir s’il peut correspondre à nos flots.
6.1. Procédure des tests
Pour nous aider à réaliser les tests sur les flots on peut s’aider du tableau suivant :
| Etapes du flot | Procédures | Résultat attendu |
|---|---|---|
Dans la première colonne « Etape du flot » on marque pour chaque ligne une étape (un numéro) de nos flots. Ainsi dans la 1ère ligne on aura la ligne 1 du flots nominal puis dans la 2nd ligne on aura la 2ème étape du flot nominal,…
Dans la colonne « Procédures » il faut écrire ce que nos acteurs du scénario réel font à ces étapes. Pour cela on s’aide du scénario réel que l’on a en support.
Par exemple si le flot était « La secrétaire entre son mot de passe » il faudra écrire dans les procédures « Mme Martinez, la secrétaire rentre son mot de passe ».
Dans la dernière colonne, « Résultat attendu » il faut mettre ce qui est idéalement attendu lorsque l’acteur du scénario réalise la procédure.
Par exemple pour notre dernier exemple cela serait : « Mme Martinez arrive à se connecter ».
A noter qu’il n’est pas nécessaire de compléter les colonnes Procédures et Résultat attendu pour toutes les lignes. En effet le scénario de notre situation réelle ne possèdera surement pas un champ pour toutes les étapes de nos flots.
Si l’on observe qu’un élément dans notre scénario réel ne peut pas être placé dans une des colonnes de nos flots c’est soit que cet élément n’est pas pertinent et on peut donc l’ignorer ou bien à l’inverse qu’il est important et il nous permet de nous rendre compte qu’on a oublié une étape importante dans nos flots pour tenir compte de cet élément.
Attention à ne pas oublier les pré et post-conditions !
Le scénario réel constitue donc un test empirique de nos flots !
6.2. Application
Pour illustrer les nouveaux éléments introduits précédemment nous allons reprendre, une fois encore, le cas d’utilisation « Enregistrer le règlement et le rendu d’une voiture » pour lequel nous avions réalisé la description complète précédemment.
Nous avons le scénario réel suivant :
Votre Client se prénomme Juan Manuel Fangio, son mail est fangio@gmail.com, sa voiture est une Maserati 250F de 1953. Elle a un problème d'allumage. Fred a changé le système d'allumage en 1h. La facture s'élève à 150 euros. Mais il reste un problème de carrosserie qui sera réparée plus tard quand les pièces seront reçues.
Voyons si nos flots sont corrects pas à pas.
Dans le scénario énoncé précédemment beaucoup d’élément apparaissent et beaucoup ne trouveront pas leur place dans nos flots. Ce n’est pas pour autant qu’il faudra les modifier !
En effet il ne faut pas perdre de vue qu’il faut rester cohérent avec ce que l’énoncé original nous disait (les besoins réels du client). Si certains éléments ne servent à rien, il ne faut pas les mettre !
Encore une fois cela dépend de l’interprétation de chacun mais il ne faut jamais perdre de vue l’énoncé original !
Commençons par les préconditions :
| Etapes du flot | Procédures | Résultat attendu |
|---|---|---|
| Le système attend qu’on le sollicite |
Dans la colonne procédure il faut, on le rappelle, entrer ce que font nos acteurs du scénario réel en adéquation avec le flot énoncé. Ainsi on a :
| Etapes du flot | Procédures | Résultat attendu |
|---|---|---|
| Le client se présente au garage pour récupérer son véhicule. La secrétaire remet la facture au client | Juan Manuel Fangio se présente au garage pour récupérer sa Maserati 250F de 1953. Mme Martinez, la secrétaire, lui remet la facture des réparations effectuées |
On remplit ensuite la colonne des résultats attendus qui, on le rappelle, doit contenir ce qui se passe lorsque l’acteur a réussi à effectuer la procédure. On a donc :
Dans la colonne procédure il faut, on le rappelle, entrer ce que font nos acteurs du scénario réel en adéquation avec le flot énoncé. Ainsi on a :
| Etapes du flot | Procédures | Résultat attendu |
|---|---|---|
| Le client se présente au garage pour récupérer son véhicule. La secrétaire remet la facture au client | Juan Manuel Fangio se présente au garage pour récupérer sa Maserati 250F de 1953. Mme Martinez, la secrétaire, lui remet la facture des réparations effectuées | Juan Manuel Fangio sait désormais que pour les réparations effectuées jusqu’à lors il devra payer 150 euros |
On commence ensuite notre flot nominal avec la 1ère ligne
| Etapes du flot | Procédures | Résultat attendu |
|---|---|---|
| 1 - La secrétaire entre les informations personnelles du client dans le système informatisé du Smart garage et demande l’affichage des informations du client et de son véhicule. |
On obtient le résultat suivant :
| Etapes du flot | Procédures | Résultat attendu |
|---|---|---|
| 1 - La secrétaire entre les informations personnelles du client dans le système informatisé du Smart garage et demande l’affichage des informations du client et de son véhicule. | Mme Martinez entre les informations personnelles de Juan Manuel Fangio dans le système | Les informations personnelles de Juan Manuel Fangio sont affichées à l’écran ainsi que celles de sa voiture, une Maserati 250F de 1953 |
Passons ensuite à la 2ème ligne :
| Etapes du flot | Procédures | Résultat attendu |
|---|---|---|
| 2 - Le système confirme à la secrétaire que le client a été trouvé et affiche les informations du client et de son véhicule et signale que toutes les réparations ont été effectuées |
Pour cette ligne de notre flot il n’y a rien à mettre dans les colonnes procédure et résultat attendu car, dans le scénario réel, on nous dit que les toutes les réparations n’ont pas été effectuées : « il reste un problème de carrosserie qui sera réparée plus tard ». Par conséquent il serait faux, avec le scénario actuel, de marquer quelque chose dans ces deux colonnes.
En revanche notre flot n’est pas faux pour autant mais cette 2ème ligne servira dans un autre scénario où toutes les réparations de la voiture de Juan Manuel Fangio seront effectuées.
Il nous faut donc poursuivre notre élaboration de tableau avec un des cas alternatif ou d’erreurs qui prend ce cas en compte et nous en avons un !
En revanche, si nous n’avions rien eu pour gérer ce cas de figure il aurait fallu que nous le rajoutions !
Prenons donc la ligne suivante issue d’un flot alternatif.
| Etapes du flot | Procédures | Résultat attendu |
|---|---|---|
| 2 - b) Le système confirme à la secrétaire que le client a été trouvé et affiche les informations du client et de sa voiture et signale qu’il reste des réparations à effectuer |
On obtient le tableau suivant.
| Etapes du flot | Procédures | Résultat attendu |
|---|---|---|
| 2 - b) Le système confirme à la secrétaire que le client a été trouvé et affiche les informations du client et de sa voiture et signale qu’il reste des réparations à effectuer | Au vu des informations affichées par le système, Mme Martinez dit à Juan Manuel Fangio que les réparations sur sa voiture ne sont pas terminées mise à part le problème d’allumage qui a été réglé et qu’il reste un problème de carrosserie | Juan Manuel Fangio sait que toutes les réparations n’ont pas pu être effectuées sur sa voiture |
Passons à la ligne suivante et au tableau suivant :
| Etapes du flot | Procédures | Résultat attendu |
|---|---|---|
| 1 - Jump to 13 |
Pour cette ligne il n’y a pas de tableau à remplir car il s’agit juste d’une étape de transition pour revenir au flot nominal.
Passons donc à ligne 13 du flot nominal !
| Etapes du flot | Procédures | Résultat attendu |
|---|---|---|
| 13 - La secrétaire enregistre dans le système que le véhicule a été rendu |
On obtient donc le tableau suivant :
| Etapes du flot | Procédures | Résultat attendu |
|---|---|---|
| 13 - La secrétaire enregistre dans le système que le véhicule a été rendu | Mme Martinez enregistre dans le système que le véhicule de Juan Manuel Fangio, une Maserati 250F de 1953, a été rendue | Juan Manuel Fangio peut récupérer sa voiture sur laquelle il restera tout de même des réparations à effectuer |
Continuons ensuite avec les deux lignes suivantes qui concluront notre flot :
| Etapes du flot | Procédures | Résultat attendu |
|---|---|---|
| 14 - Le système enregistre que le véhicule a été rendu | Le système enregistre que la Maserati 250F de 1953 a été rendue | La secrétaire et Juan Manuel Fangio attendent la confirmation du système qu’il a bien enregistré que la Maserati 250F de 1953 a été rendue |
| 15 - Le système affiche qu’il a bien enregistré le rendu du véhicule | Le système affiche qu’il a bien enregistré que la Maserati 250F de 1953 a été rendue | La Maserati 250F de 1953 a été rendue à Juan Manuel Fangio |
Et enfin nous terminons avec les post-conditions :
| Etapes du flot | Procédures | Résultat attendu |
|---|---|---|
| Le système informatisé a enregistré que la voiture a été rendue au client | Le système a enregistré que la voiture de Juan Manuel Fangio a été rendue | Juan Manuel Fangio repart avec sa voiture en sachant qu’il devra revenir pour finir les dernières réparations non effectuées |
Nous avons donc parcouru nos flots en leur assoyant un maximum d’informations compte tenu de notre scénario. Voyons les éléments que nous avons utilisé (en gras) et les ceux qu’il nous reste (surligné en jaune) :
Votre Client se prénomme Juan Manuel Fangio, son mail est fangio@gmail.com, sa voiture est une Maserati 250F de 1953. Elle a un problème d'allumage. Fred a changé le système d'allumage en 1h. La facture s'élève à 150 euros. Mais il reste un problème de carrosserie qui sera réparée plus tard quand les pièces seront reçues.
Parmi les informations restantes (surlignées en jaune) certaines, peu importe le scénario qu’on prendra, ne seront pas pertinente comme par exemple le nom du mécanicien, Fred, ce qu’il a réalisé, en combien de temps (1h) et pourquoi toutes les réparations n’ont pas été effectué.
Si cela intéresse le client de le savoir il peut le demander à la secrétaire qui lira ces informations dans le système mais on s’écarterait un peu de l’énoncé initial…
Nous avons donc, pour ce scénario, réussi à placer dans nos flots toutes les informations réellement pertinentes ce qui permet de penser que nos flots sont suffisamment exhaustifs.
La création d’un logiciel passe par plusieurs phases d’analyse, de recherches et bien évidemment de développement.
Nous avons pu voir jusqu’à présent que le diagramme de cas d’utilisation et les descriptions de cas d’utilisation pouvaient constituer une excellente base de départ pour tous les développeurs qui souhaiteraient coder le logiciel.
Néanmoins tous logiciels possèdent certes des fonctionnalités techniques, des outils mais un logiciel doit absolument posséder une interface !
Lors de l’élaboration du diagramme de cas d’utilisation d’un logiciel il est possible d’élaborer en même temps une interface.
En effet, si l’on y réfléchi un peu, comme celui qui réalise le diagramme de cas d’utilisation connait bien les attentes du client il est en mesure de déjà réalisé au moins un prototype pour l’interface.
En réalité il ne s’agit pas vraiment d’une interface puisqu’on ne pourra cliquer sur les boutons pour qu’ils nous emmènent vers d’autres fenêtres, on ne pourra pas interagir avec l’interface mais on pourra simplement avoir un aperçu.
Ainsi c’est comme si l’on prenait des photos, des instantanés de l’interface sur ses différents écrans. Il s’agit en réalité d’une maquette basse résolution des différents écrans c’est-à-dire qu’on ne représente que l’essentiel sur l’écran.
Pour organiser au mieux les écrans et ne pas les créé au hasard il est conseillé de réaliser un instantané par cas d’utilisation.
Autrement dit réaliser un écran pour chaque cas d’utilisation.
Ainsi l’ensemble de tous les écrans réalisés pour chaque cas d’utilisation pourra former, à termes, notre future interface pour notre logiciel.
On peut être encore plus précis et minutieux dans notre travail c’est-à-dire qu’on peut réaliser un instantané pour chaque action majeure (qui peuvent regrouper plusieurs lignes) de notre flot nominal, alternatif et d’erreurs de notre de description de notre cas d’utilisation !
Ainsi pour un cas d’utilisation donné on pourra avoir une description détaillée textuelle et à l’appui des instantanés qui montre le résultat produit sur l’interface du futur logiciel.
Au final, même si ces instantanés de l’interface ne sont pas forcément complets et qu’ils ne représenteront pas l’interface final ils permettront au moins de donner aux développeurs une meilleure idée de ce qui est attendu !
7.1. Création d'un instantané
Une fois de plus, comme pour beaucoup de choses en UML, l’interprétation de chacun joue beaucoup dans le résultat produit.Pour la création d’un instantané de l’interface à un moment précis il n’y a pas de méthode mais il faut bien avoir à l’esprit quelques petites choses :
L’interface d’un logiciel n’est jamais destinée qu’à un seul utilisateur c’est pourquoi il faut qu’une interface soit :
- D’une part utile c’est-à-dire qu’elle possède suffisamment d’options, d’éléments pour répondre à toutes les attentes des utilisateurs ;
- D’autre part il faut qu’elle soit utilisable c’est-à-dire qu’elle soit ergonomique, compréhensible par un utilisateur.
Il faut vraiment se mettre à la place de l’utilisateur pour imaginer ce qu’il souhaiterait réaliser.
7.2. Application
Pour illustrer ce nouvel élément nous allons reprendre la description que nous avons précédemment réalisée sur le cas d’utilisation « Enregistrer le règlement et le rendu d’une voiture », prendre une ligne bien précise du scénario nominal, alternatif ou d’erreurs et réaliser une interface dédiée telle qu’elle pourrait être sur le logiciel final !On rappelle les 3 scénarios écrits précédemment :
Flot nominal :
1- La secrétaire entre les informations personnelles du client dans le système informatisé du Smart garage et demande l’affichage des informations du client et de son véhicule.
2- Le système confirme à la secrétaire que le client a été trouvé et affiche les informations du client et de son véhicule et signale que toutes les réparations ont été effectuées.
3- La secrétaire cherche d’autres factures que le client pourrait régler.
4- Le système affiche les factures impayées du client
5- La secrétaire entre le montant total à payer dans le système
6- La secrétaire demande au client de régler le montant à payer
7- Le client entre ses informations bancaires dans le système
8- Le système affiche qu’il est en train d’établir la connexion avec le système de paiement
9- Le système a réussi à se connecter au système de paiement
10- Le système affiche qu’il a bien établi la connexion avec le système de paiement
11- Le système crédite le compte du client du montant indiqué
12- Le système affiche que le règlement a bien été effectué
13- La secrétaire enregistre dans le système que le véhicule a été rendu
14- Le système enregistre que le véhicule a été rendu
15- Le système affiche qu’il a bien enregistré le rendu du véhicule
Flot alternatif :
2- a) Le système ne trouve aucune facture supplémentaire impayées
1- Jump to 5
2- b) Le système confirme à la secrétaire que le client a été trouvé et affiche les informations du client et de sa voiture et signale qu’il reste des réparations à effectuer
1- Jump to 13
9- Le système n’a pas réussi à se connecter au système de paiement pour cause de mauvaises informations entrées
1- Le système affiche qu’il n’a pas réussi à se connecter pour cause de mauvaises informations entrées
2- Jump to 7
Flot d’erreurs :
2- Le système ne trouve pas le client
1- Le système signale à la secrétaire que le client n’a pas été trouvé
2- Exit
9- Le système n’a pas réussi à se connecter au système de paiement
1- Le système affiche qu’il n’a pas réussi à établir la connexion avec le système de paiement
2- Exit
Pour notre exemple on peut construire les interfaces correspondant aux lignes 1 à 4 inclues.
Rappel des lignes concernées :
1- La secrétaire entre les informations personnelles du client dans le système informatisé du Smart garage et demande l’affichage des informations du client et de son véhicule.
2- Le système confirme à la secrétaire que le client a été trouvé et affiche les informations du client et de son véhicule et signale que toutes les réparations ont été effectuées.
3- La secrétaire cherche d’autres factures que le client pourrait régler.
4- Le système affiche les factures impayées du client
Pour mieux cerner les interfaces que l’on va chercher à réaliser pour chacune des 4 lignes on va essayer de déterminer quels éléments majeurs doivent figurer sur l’interface.
Ligne 1 :
- La secrétaire saisit les informations du client :
Il faut un champ pour saisir le nom et le prénom du client
- La secrétaire demande l’affichage des informations du client
Il faut un bouton où la secrétaire peut cliquer pour valider les informations entrées et que le système puisse rechercher les informations demandées.
On peut donc penser à une interface comme celle ci-dessous :
Ligne 2 :
- Le système affiche les informations du client et du véhicule
Il faut une zone qui rappelle les informations du client avec le nom, le prénom, sa photo et d’autres informations.
Il faut une zone qui rappelle les informations du véhicule du client
- Le système signale que toutes les réparations ont été effectuées
Il faut une zone pour rappeler les réparations qui devaient être effectuées sur le véhicule et pour savoir s’ils elles ont été effectuées ou non
Il faut également donner le prix de chaque réparation
On peut également imaginer donner la possibilité à la secrétaire de générer la facture correspondante à l’aide d’un bouton
On peut donc penser à une interface comme celle ci-dessous :
On pourrait un peu améliorer l’interface précédente pour tenir compte du cas alternatif où toutes les réparations n’ont pas été effectuées et par conséquent qu’on diffère le paiement. Pour cela on peut imaginer rajouter un autre bouton « Différer le paiement de la facture et l’archiver » ce qui aurait pour effet d’ajouter la facture actuelle dans les factures à régler plus tard.
On obtient ainsi le résultat suivant :
Ligne 3 :
- La secrétaire cherche des factures qu’elles pourraient faire régler au client
Il faut un moyen d’accéder au factures archivées comme par exemple un bouton « Consulter les factures archivées » qu’on va bien évidemment placer sur l’écran précèdent.
On obtient ainsi le résultat suivant :
Ligne 4 :
- Le système affiche les factures impayées, archivées du client
Il faut un nouvel écran sur lequel figure les anciennes factures archivées
Il nous faut ensuite un bouton ou une case à cocher pour décider si on l’encaisse ou non
Et enfin un bouton pour effectuer le paiement des factures sélectionnées
On obtient ainsi le résultat suivant :
Avec ces quelques exemples nous avons pu voir qu’il peut être utile de réaliser une maquette basse résolution des différents écrans de notre interface en plus de la description textuelle afin d’encore mieux décrire les interactions possibles lors d’un cas d’utilisation.
La description d’un cas d’utilisation se fait en 3 étapes :
- Etape 1 : l’identification du cas où l’on donne les informations générales du cas d’utilisation (nom, résumé,…)
- Etape 2 : La description du fonctionnement dans laquelle il faut écrire un scénario complet qui retrace le déroulement du cas d’utilisation. Autrement dit écrire un scénario qui indique ce que le ou les acteur(s) font en réalisant ce cas d’utilisation. Ce scénario est généralement composé d’un flot nominal (scénario quand tout se passe bien) auquel on peut ajouter un flot alternatif qui traite de cas alternatif au flot nominal et un flot d’erreurs dans lequel on recense toutes les erreurs qui peuvent survenir lors de la réalisation du flot nominal.
- Etape 3 : Les spécifications non fonctionnelles. Cette rubrique optionnelle contient des contraintes liées au cas d’utilisation (temps de réponse, la disponibilité,…)
Il est ensuite conseillé de réaliser des tests pour chacun des flots écrits à partir d’un scénario réel. Pour cela on peut s’aider du tableau suivant :
| Etapes du flot | Procédures | Résultat attendu |
|---|---|---|
- Dans la colonne « Procédures » ce que nos acteurs du scénario réel font à ces étapes. Pour cela on s’aide du scénario réel que l’on a en support.
- Dans la dernière colonne, « Résultat attendu » ce qui est idéalement attendu lorsque l’acteur du scénario réalise la procédure.
Enfin, on peut associer une interface, un modèle basse résolution à un cas d’utilisation pour représenter l’éventuel aspect final d’un logiciel qui utiliserai ce cas d’utilisation.
Lors de l’écriture d’une description d’un cas d’utilisation il ne faut pas oublier, pour l’étape 2, de bien rédiger les pré et post-conditions.
Il ne faut surtout pas oublier de rédiger les flots à la voix active, c’est l’acteur qui fait l’action.
Il ne faut également pas oublier de numéroter chaque ligne des flots et penser, pour les flots alternatifs ou d’erreurs, de bien indiquer, dans la première ligne, de quelle ligne du flot nominal ils sont issus et de bien terminer par une instruction « jump to » ou « exit ».
Ainsi vous saurez maintenant décrire au mieux un cas d’utilisation et exploiter toutes les possibilités qui y sont liées.
Bien que nous ayons construit notre diagramme de cas d’utilisation dans le TD1 et avons vu comment décrire plus précisément des cas d’utilisation dans ce TD il reste tout de même des notions importantes à voir qui découlent de ce diagramme.
Ces nouvelles notions nous occuperons au cours du prochain TD.