L'ensemble des éléments de ce TP a été rédigé par Lang Alexandre
Le diagramme de cas d'utilisation représente la structure des grandes fonctionnalités nécessaires aux utilisateurs du système. C'est le premier diagramme du modèle UML, celui où s'assure la relation entre l'utilisateur et les objets que le système met en œuvre.
Bien souvent, la maîtrise d'ouvrage et les utilisateurs ne sont pas des informaticiens. Il leur faut donc un moyen simple d'exprimer leurs besoins. C'est précisément le rôle des diagrammes de cas d'utilisation qui permettent de recueillir, d'analyser et d'organiser les besoins, et de recenser les grandes fonctionnalités d'un système. Il s'agit donc de la première étape UML d'analyse d'un système.
Un diagramme de cas d'utilisation capture le comportement d'un système tel qu'un utilisateur extérieur le voit. Il scinde la fonctionnalité du système en unités cohérentes, les cas d'utilisation, ayant un sens pour les acteurs. Les cas d'utilisation permettent d'exprimer le besoin des utilisateurs d'un système. Ils sont donc une vision orientée utilisateur plutôt qu’une vision informatique.
Il ne faut pas négliger cette première étape pour produire un logiciel conforme aux attentes des utilisateurs. Pour élaborer les cas d'utilisation, il faut se fonder sur des entretiens avec les utilisateurs.
- Objectif 1 : Réaliser quelques rappels sur les cas d'utilisation
- Objectif 2 : Trouver les acteurs d'un système
- Objectif 3 : Trouver les cas d'utilisation d'un système
Prenons pour exemple le diagramme de cas d’utilisation simple suivant :
3.1. Les acteurs
3.1.1. Définition
UML n'emploie pas le terme d'utilisateur, mais d'acteur. Les acteurs d'un système sont les entités externes à ce système qui interagissent (retirer de l’argent, consulter le solde du compte,…) avec lui.
Les acteurs sont donc à l'extérieur du système et dialoguent avec lui. Ces acteurs permettent de cerner l'interface que le système va devoir offrir à son environnement. Oublier des acteurs ou en identifier de faux conduit donc nécessairement à se tromper sur l'interface et donc la définition du système à produire.
Il faut faire attention à ne pas confondre acteurs et utilisateurs (utilisateur avec le sens de la personne physique qui va appuyer sur un bouton) d'un système. D'une part parce que les acteurs incluent les utilisateurs humains, mais aussi les autres systèmes informatiques ou hardware qui vont communiquer avec le système. D'autre part parce qu'un acteur englobe tout une classe d'utilisateurs. Ainsi, plusieurs utilisateurs peuvent avoir le même rôle, et donc correspondre à un même acteur, et une même personne physique peut jouer des rôles différents vis-à-vis du système, et donc correspondre à plusieurs acteurs.
Chaque acteur doit être nommé. Ce nom doit refléter son rôle, car un acteur représente un ensemble cohérent de rôles joués vis-à-vis du système. Il doit être également mettre au singulier !
Il se représente par un petit bonhomme avec son nom ou son rôle inscrit dessous.
Il est également possible de représenter un acteur sous la forme d’un « classeur » dans le cas où cet acteur externe n’est pas une personne et que l’on souhaite le différencier des autres acteurs (téléphone, réseau social,…).
Lorsque l’on définit un acteur il est fortement conseillé de lui ajouter une brève description textuelle mais dans les cas où le nom/rôle de l’acteur est explicite ce n’est pas la peine.
3.1.2. Comment trouver les acteurs du système ?
Pour trouver les acteurs d'un système, il faut identifier quels sont les différents rôles que vont devoir jouer ses utilisateurs (ex. : responsable clientèle, responsable d'agence, administrateur,…). Il faut également s'intéresser aux autres systèmes avec lesquels le système va devoir communiquer comme :
- Les périphériques manipulés par le système (imprimantes, hardware d'un distributeur de billets…) ;
- Des logiciels déjà disponibles à intégrer dans le projet ;
- Des systèmes informatiques externes au système, mais qui interagissent avec lui.
Pour faciliter la recherche des acteurs, on peut imaginer les frontières du système. Tout ce qui est à l'extérieur et qui interagit avec le système est un acteur, tout ce qui est à l'intérieur est une/ fonctionnalité à réaliser.
Vérifiez que les acteurs communiquent bien directement avec le système par émission ou réception de messages. Une erreur fréquente consiste à répertorier en tant qu'acteur des entités externes qui n'interagissent pas directement avec le système, mais uniquement par le biais d'un des véritables acteurs.
Par exemple, l'hôtesse de caisse d'un magasin de grande distribution est un acteur pour la caisse enregistreuse, par contre, les clients du magasin ne correspondent pas à un acteur, car ils n'interagissent pas directement avec la caisse.
Pour trouver les acteurs on peut se poser les questions suivantes :
- Qui ou quoi utilise le système ?
- Qui ou quoi obtient de l’information de ce système ?
- Qui ou quoi fournit des informations au système ?
- Où dans la compagnie le système est-il utilisé ?
- Qui ou quoi supporte et maintient le système ?
- Quels autres systèmes utilisent ce système ?
3.2. Le système
Le système est l’entité avec laquelle les acteurs vont interagir. C’est l’entité qu’on cherche à décrire, modéliser avec le diagramme de cas d’utilisation et que l’on chercher à coder à l’issu de la phase UML.
En UML on le représente à l’aide d’un simple cadre. Le nom du système figure à l’intérieur du cadre, en haut.
Ainsi les acteurs de ce système se situeront autour de ce système et non pas à l’intérieur car cela sous-entendrai qu’ils font partie du système !
A noter que par convention les acteurs représentant des personnes, les bonhommes, sont plutôt placés à gauche du système tandis que les autres acteurs qui ne sont pas des personnes (représentés donc par des classeurs) sont plutôt placés à la droite du système.
3.3. Les cas d'utilisation (use-case)
3.3.1 Définition
Un cas d'utilisation est une unité cohérente représentant une fonctionnalité visible de l'extérieur. Il réalise un service de bout en bout, avec un déclenchement, un déroulement et une fin, pour l'acteur qui l'initie. Un cas d'utilisation modélise donc un service rendu par le système, sans imposer le mode de réalisation de ce service.
Dis de manière plus simple il s’agit d’une action que réalise un acteur en utilisant le système.
Un cas d'utilisation se représente par une ellipse contenant l’action réalisée par l’acteur. L’action doit être sous la forme d’un verbe à l’infinitif suivi d’un complément.
Le complément doit être unique, intuitif et auto-explicatif. Le gain des résultats observables doit être défini clairement et sans ambiguïté.
Par extension un cas d’utilisation sera toujours relier à un acteur, à l’acteur qui réalise l’action du cas d’utilisation…
Comme l’ensemble des cas d’utilisation sont réalisées « à travers » le système, tous les cas d’utilisation doivent être regroupés dans le système, dans le cadre.
Pour reprendre le 1er exemple donné on a bien notre système intitulé « Borne de retrait interactive », notre acteur externe au système, le Client et enfin nos deux cas d’utilisation c’est-à-dire les deux actions que peut réaliser le Client « à travers » la Borne :
- Retirer de l’argent ;
- Consulter le solde du compte.
Comme ces deux actions, ces deux cas d’utilisation sont propres à notre système ils sont bien regroupés dans le système.
3.3.2. Comment trouver un cas d’utilisation ?
L'ensemble des cas d'utilisation doit décrire exhaustivement les exigences fonctionnelles du système.
Chaque cas d'utilisation correspond donc à une « fonction métier » du système, selon le point de vue d'un de ses acteurs. Aussi, pour identifier les cas d'utilisation, il faut se placer du point de vue de chaque acteur et déterminer comment et surtout pourquoi il se sert du système c’est-à-dire que cherche à faire l’acteur avec le système ?
Par exemple, un distributeur de billets aura probablement un cas d'utilisation Retirer de l'argent et non pas Distribuer de l'argent.
Il faut éviter les redondances et limiter le nombre de cas en se situant à un bon niveau d'abstraction. Trouver le bon niveau de détail pour les cas d'utilisation est un problème difficile qui nécessite de l'expérience.
De par la nature fonctionnelle, et non objet, des cas d'utilisation, et en raison de la difficulté de trouver le bon niveau de détail, il faut être très vigilant pour ne pas retomber dans une décomposition fonctionnelle descendante hiérarchique. Un nombre trop important de cas d'utilisation est en général le symptôme de ce type d'erreur.
Dans tous les cas, il faut bien garder à l'esprit qu'il n'y a pas de notion temporelle dans un diagramme de cas d'utilisation.
3.3.3. Le glossaire
Comme pour les acteurs il peut arriver que certains cas d’utilisation nécessitent une petite description pour être compréhensible par tous.
Plus précisément il s’agit de certains mots constitutifs du cas d’utilisation qui nécessitent qu’on leur donne une définition.
La réalisation d’un logiciel ne se fait pas en un claquement de doigt, il faut du temps car plusieurs étapes sont nécessaires pour son élaboration. Ainsi plusieurs personnes vont travailler sur ce logiciel et ce à différents niveaux.
Il est donc important qu’à tout moment de la conception du logiciel ses concepteurs puissent comprendre toutes les exigences demandées par l’utilisateur lors de l’élaboration du cahier des charges.
Ainsi si certains termes sont ambigus ou peuvent avoir plusieurs sens cela peut mener à un problème de conception.
Cela peut notamment être le cas lors de la définition des cas d’utilisation : on constitue des phrases ambiguës et celui qui nous lira après ne comprendra pas ce que l’on a voulu dire.
Pour pallier à cela on créé un glossaire !
Un glossaire peut être vu comme un dictionnaire puisqu’on va y définir les termes qui peuvent poser un problème de compréhension.
Ainsi ce glossaire constituera le point d’entrée et le référentiel initial de l’application, du système que l’on cherche à créer et permettra d’éviter les confusions.
Par conséquent si, lors de la définition d’un cas d’utilisation, on pense qu’un mot ou un terme peut porter à confusion il faudra l’ajouter dans le glossaire et lui donner une définition complète.
Le glossaire constitue un outil de dialogue indispensable !
Maintenant que tous ces rappels ont été effectués passons à une première étude de cas. On rappelle néanmoins qu’aucune solution réelle n’existe pas aux problèmes de modélisation c’est-à-dire que d’une personne à l’autre la solution changera car elles n’auront pas les mêmes interprétations du cahier des charges ou de l’énoncé.
Ainsi il faut toujours être cohérent dans ce que l’on réalise, dans les choix de modélisation que l’on prend et ne pas hésiter à les expliquer clairement. C’est ce que nous ferons pour les exercices afin d’expliquer nos choix.
A chaque étape on représentera la modélisation UML associée en utilisant le logiciel Visual Paradigm en version 12.2.
Il est bien évidemment conseillé de le faire de votre côté avant de lire la correction. Pour davantage d’exercices nous rappelons également que des exercices sont disponibles à la fin de ce premier TD.
Prenons donc l’énoncé suivant, celui d’un garage « Smart garage » :
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 lui remet la facture et encaisse le paiement. Elle 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.
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, …
4.1. Le système
La première chose à faire est d’identifier notre système, celui qu’on cherche à modéliser à travers l’énoncé ci-dessus. Il s’agit donc du « Smart Garage ».
4.2. Les acteurs du système
La deuxième étape consiste à identifier tous les acteurs du système et à identifier leur rôle, leur nom.
Etudions chaque partie de l’énoncé en cherchant toutes les entités qui interagissent avec notre système.
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.
Dès la première phrase un petit piège apparait. On pourrait croire que le client est un acteur du système car il « prend rendez-vous ».
Or quand il prend rendez-vous il le fait avec la secrétaire et pas avec le Smart garage directement. Il passe par l’intermédiaire de la secrétaire qui elle, en revanche, « enregistre le rendez-vous dans le SI du garage » soit le Smart garage.
Ainsi la secrétaire est notre premier acteur du système.
Son nom/rôle est assez évident (Secrétaire) ce qui fait qu’il n’y pas besoin de description pour cet acteur.
2. Le chef d’atelier consulte chaque matin la liste des rendez-vous de la journée.
Ici le chef d’atelier « consulte » les rendez-vous.
Comme la secrétaire enregistre les rendez-vous dans le Smart garage on peut imaginer que le chef d’atelier consulte ces rendez-vous dans le Smart garage directement. Par conséquent cela fait de lui un acteur du système.
Son rôle étant peut-être un peu ambigu on lui ajoute une petite description textuelle.
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.
Une fois de plus on pourrait penser que le client est un acteur du système mais une fois encore il n’interagit pas directement avec le système mais il passe par l’intermédiaire du chef d’atelier qu’on a déjà désigné comme acteur.
Dans la seconde partie de cet énoncé on nous introduit la puce dédiée. Cette puce dédiée, propre à chaque voiture, permet d’identifier les voitures enregistrées dans le système du garage soit le Smart garage.
Par conséquent cette puce se sert du système, interagit avec lui. Cela fait d’elle un acteur du système. Comme la puce n’est pas un personnage, une personne physique, sa représentation sera un classeur et elle sera placée à droite du système.
S’agissant d’un acteur une fois de plus un peu ambigu on lui associe une petite description textuelle.
4. Les mécaniciens peuvent consulter toutes les fiches suiveuses.
Les mécaniciens consultent directement les fiches suiveuses enregistrées dans le système Smart garage. Ils interagissent directement avec le système, ce sont des acteurs.
Leur nom est assez significatif de leur fonction et par conséquent aucune description n’est nécessaire.
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.
Les mécaniciens interagissent une nouvelle fois avec le système mais de façon différente. Ils restent acteur du système.
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).
Dans la première partie les mécaniciens interagissent une nouvelle fois avec le système mais de façon différente. Ils restent acteur du système.
Dans la seconde partie on introduit le « boitier spécialisé ». Ce boitier, si l’on interprète l’énoncé, permet d’enregistrer la date de début de fin de réparation d’une voiture directement dans le service informatique du Smart garage.
Par conséquent cela fait de ce boitier un acteur du système. Ne s’agissant pas d’une personne physique, il sera sous la forme d’un classeur et sera placé à droite du système.
Remarque :
Dans la deuxième partie de l’énoncé, lorsque l’on parle du boiter, on précise bien que le mécanicien passe par le boitier pour entrer la date de début et de fin. Ainsi, si l’on ne considérait que cette partie de l’énoncé, le mécanicien n’aurait pas été un acteur du système.
7. La secrétaire utilise le SI pour préparer les factures.
La secrétaire interagit directement avec le système informatique (SI) du Smart garage mais elle était déjà acteur du système.
8. Quand le client se présente pour retirer le véhicule, la secrétaire lui remet la facture et encaisse le paiement. Elle 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.
La secrétaire interagit directement avec le système informatique (SI) du Smart garage mais elle était déjà acteur du système.
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, …
Ici, le client peut consulter l’état de la réparation de sa voiture. Cet état est stocké directement dans le système informatique du Smart garage. Ainsi le client interagit directement avec le système et par conséquent devient lui aussi un acteur du système.
Son nom étant suffisamment explicite, sans ambigüités, aucune description n’est nécessaire.
Nous obtenons donc le diagramme suivant.
4.3. Les cas d’utilisation
Il nous faut maintenant parcourir une seconde fois l’énoncé pour rechercher tous les cas d’utilisation possible pour chaque acteur identifié ! Autrement rechercher ce que chaque acteur réalise comme action avec le système.
En caractères gras seront les acteurs identifiés précédemment.
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.
Pour cette première phrase on note que la secrétaire « enregistre le rendez-vous dans le SI du garage ». Il s’agit donc d’un premier cas d’utilisation !
Ce cas sera associé à la secrétaire (puisque c’est elle qui réalise l’action).
On rappelle que les cas d’utilisation doivent commencer par un verbe à l’infinitif suivi d’un complément clair et qu’il faut se placer du point de vue de l’acteur.
On pourra donc prendre ici : « Enregistrer les rendez-vous »
Pour ce cas d’utilisation nul besoin de définir ses termes dans le glossaire car nous n’avons, dans l’énoncé, pas d’informations supplémentaires.
En revanche s’il l’on avait eu l’énoncé suivant :
-> 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. Un rendez-vous est défini par une heure d’arrivée et un intitulé.
Remarque :
Avec l’énoncé précèdent et avec davantage de précisions sur l’entité « rendez-vous » il aurait été nécessaire d’ajouter une petite définition :
-> Un rendez-vous est défini par une heure d’arrivée du client au garage et un intitulé expliquant les raisons de ce rendez-vous.
2. Le chef d’atelier consulte chaque matin la liste des rendez-vous de la journée.
Le chef d’atelier réalise une action avec le système : il consulte la liste des rendez-vous. C’est donc un cas d’utilisation.
On pourra donc prendre : « Consulter les rendez-vous ».
Une fois de plus cela ne sert à rien ici de définir des termes dans le glossaire. Il n’y a aucune ambigüité.
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.
Tout d’abord le chef d’atelier saisit les informations de la réparation sur une fiche suiveuse automatisée. Autrement dit il saisit les informations dans le système.
Cela nous fait encore un autre cas d’utilisation pour le chef d’atelier : « Saisir les informations dans la fiche suiveuse ».
Juste après on nous dit « qu’il imprime » la fiche suiveuse. Même si ce n’est pas clairement explicité on comprend qu’il imprime la fiche suiveuse en utilisant le système puisque cette dernière se trouve dans le système du Smart garage.
C’est un autre cas d’utilisation : « Imprimer les fiches suiveuses ».
Quelques remarques :
Tout d’abord, dans nos cas d’utilisation nous employons le terme « fiche suiveuse ». Or nous avons quelques éléments, dans l’énoncé, qui nous décrivent un peu la fonction de ces fiches.
Pour ne pas encombrer les cas d’utilisation nous allons mettre ces informations complémentaires dans le glossaire !
Fiche suiveuse : fiche de suivi d’un véhicule qui permet de connaitre les révisions ou les réparations à effectuer.
D’autre part, nos deux cas d’utilisation ont en commun le même terme : « fiche suiveuse ».
Même si à ce stade notre diagramme est juste, on peut regrouper ces deux cas d’utilisation en un cela dépend des personnes et des interprétations de chacun.
Nous obtenons donc, en choisissant de regrouper nos cas d’utilisation, le diagramme suivant :
Le glossaire :
Dans la seconde partie on nous parle de la puce qui permet d’identifier une voiture. La puce étant un acteur il s’agit d’un cas d’utilisation. Comme nous n’avons plus d’information sur la manière dont la puce identifie une voiture nous n’avons pas besoin d’ajouter de nouveaux termes dans le glossaire.
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.
Dans les deux dernières phrases on apprend que les mécaniciens peuvent réaliser deux actions et ce à l’aide du système :
- Consulter les fiches suiveuses
- Consulter les travaux précédents
On peut encore une fois regrouper ces deux cas d’utilisation ce qui donnerait : « consulter la fiche suiveuse et les travaux précédents ».
Ainsi ici pas de nouveaux termes à ajouter dans le glossaire.
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).
On nous dit tout d’abord que le mécanicien peut compléter la fiche suiveuse. Cela nous fait encore un autre cas d’utilisation pour le mécanicien : « Compléter la fiche suiveuse ».
On nous introduit ensuite le boitier spécialisé qui permet d’une part de définir pour une voiture s’il s’agit du début ou de la fin de la réparation et d’autre part qui permet de sélectionner le numéro et le type de réparation.
On a donc deux nouveaux cas d’utilisation : « Saisir la date de début et de fin d’une réparation » et « Sélectionner le numéro et le type de réparation ».
Dans l’énoncé on nous dit que le mécanicien peut utiliser le boitier. Par conséquent il n’est pas obligé de passer par l’intermédiaire du boitier et peut très bien réaliser toutes ces actions par lui-même. Ainsi ces deux cas d’utilisation sont affectés au boiter spécialisé mais aussi au mécanicien !
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 lui remet la facture et encaisse le paiement. Elle 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.
Dans les dernières phrases on apprend que le secrétaire, à l’aide du système informatique, du système, réalise plusieurs actions qui seront des cas d’utilisation.
On obtient alors les cas d’utilisation suivant :
- « Préparer les factures »
- « Enregistrer le règlement »
- « Enregistrer le rendu d’une voiture »
On peut néanmoins regrouper les deux derniers en un seul cas d’utilisation : « Enregistrer le règlement et le rendu d’une voiture ».
Remarque :
Dans cette partie de l’énoncé on nous parle du processus de règlement et de rendu d’une voiture. On pourrait penser qu’il faille ajouter ces informations dans le glossaire pour mieux décrire, donner une définition, au terme « règlement » ou encore « rendu ».
Or attention ce n’est pas le cas !
Le glossaire doit donner une définition explicite du terme (à quoi il sert) et non pas donner son processus d’utilisation.
En revanche nous verrons plus loin, dans un autre TP, que l’on peut décrire de manière plus précise un cas d’utilisation pour voir toutes les possibilités de ce cas.
Une autre remarque peut être faite sur cette partie de l’énoncé avec le système de paiement. Ici on ne nous donne pas d’informations sur la manière dont le paiement est réalisé. On ne sait pas si le système informatisé se connecte directement à un système de paiement auquel cas on aurait pu mettre le système de paiement comme acteur externe de notre système ; ou si notre système passe par des éléments intermédiaires pour réaliser le paiement.
Quoi qu’il en soit on peut considérer que le paiement se passe complètement en dehors du système et qu’il ne semble pas y avoir de connexion directe à un service de paiement externe qui interagirait avec notre système.
Ainsi ce n’est pas nécessaire de mettre le système de paiement comme un acteur externe de notre système. On dira simplement que lors d’un règlement le système informatisé du Smart Garage se connecte à un système de paiement sans préciser davantage la nature de ce système qui sera totalement externe à notre système informatisé.
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, …
Enfin, le client interagit lui aussi avec le système car il peut « Consulter l’état de la réparation ».
Ici on nous donne quelques informations supplémentaires sur le terme « état de la réparation » que nous allons donc ajouter au glossaire.
On obtient donc le diagramme de cas d’utilisation suivant :
Lors de la modélisation d’un énoncé en diagramme de cas d’utilisation il faut :
- Bien identifier le système sur lequel on travail
- Bien identifier les acteurs du système en se posant les bonnes questions :
o Qui ou quoi utilise le système ?
o Qui ou quoi obtient de l’information de ce système ?
o Qui ou quoi fournit des informations au système ?
o Où dans la compagnie le système est-il utilisé ?
o Qui ou quoi supporte et maintient le système ?
o Quels autres systèmes utilisent ce système ?
- Associer une description textuelle aux acteurs dont le rôle/nom peut être ambigu.
- Bien trouver tous les cas d’utilisation de tous les acteurs du système en se posant la bonne question :
o Que fait cet acteur avec notre système ?
- Ne pas hésiter à regrouper deux cas d’utilisation qui portent sur le même acteur s’ils possèdent des éléments en commun.
- Ne pas oublier d’ajouter les termes ambigus dans le glossaire
Pour faire ce diagramme, il faut s’organiser et avoir une certaine méthodologie. Nous vous conseillons d’avoir une couleur pour chaque acteur. Et en analysant chacune des phrases de l’énoncé, on encadrera le système d’information, on surlignera les acteurs et on soulignera les éléments qui vont nous permettre de faire une description textuelle de l’acteur.
Bien identifier les acteurs du système c’est-à-dire ne pas se laisse piéger par l’énoncé. Il faut que l’acteur (que ce soit une personne physique ou non) sélectionné interagisse bel et bien avec le système directement sans passer par l’intermédiaire d’un autre acteur.
Il faut faire attention à bien formuler un cas d’utilisation c’est-à-dire qu’un cas d’utilisation commence toujours par un verbe à l’infinitif suivi d’un complément.
Il ne faut également pas oublier de relier chaque cas d’utilisation à son/ses acteur(s) !
Bien que nous ayons construit notre diagramme de cas d’utilisation il reste tout de même des notions importantes à voir qui découlent de ce diagramme.
Ces nouvelles notions nous occuperons au cours des prochains TDs.