7466 Chap01

1 e r t i p a h C c
Diagramme de cas dutilisation

UML permet de construire plusieurs modles dun systme : certains montrent le systme du point de vue des utilisateurs, dautres montrent sa structure interne, dautres encore en donnent une vision globale ou dtaille. Les modles se compltent et peuvent tre assembls. Ils sont labors tout au long du cycle de vie du dveloppement dun systme (depuis le recueil des besoins jusqu la phase de conception). Dans ce chapitre, nous allons tudier un des modles, en loccurrence le premier construire : le diagramme de cas dutilisation. Il permet de recueillir, danalyser et dorganiser les besoins. Avec lui dbute ltape danalyse dun systme.
9
2010 Pearson Education France UML2, 3e dition Benot Charroux, Aomar Osmani, Yann Thierry-Mieg
1. Limportance L de bien recueillir les l besoins

Le dveloppement dun nouveau systme, ou lamlioration dun systme existant, doit rpondre un ou plusieurs besoins. Par exemple, une banque a besoin dun guichet automatique pour que ses clients puissent retirer de largent mme en dehors des heures douverture de la banque. Celui qui commande le logiciel est le matre douvrage. Celui qui ralise le logiciel est le matre duvre. Le matre douvrage intervient constamment au cours du projet, notamment pour : dfinir et exprimer les besoins ; valider les solutions proposes par le matre duvre ; valider le produit livr. Le matre duvre est, par exemple, une socit de services en informatique (SSII). Il a t choisi, avant tout, pour ses comptences techniques. Mais son savoir-faire va bien au-del. Au dbut du projet, il est capable de recueillir les besoins auprs du matre douvrage. Le recueil des besoins implique une bonne comprhension des mtiers concerns. Raliser un logiciel pour une banque, par exemple, implique la connaissance du domaine bancaire et lintgration de toutes les contraintes et exigences de ce mtier. Cette condition est ncessaire pour bien cerner les cas dutilisation exprims par le client afin dapporter les solutions adquates. Chaque cas a ses particularits lies au mtier du client. Le recueil des besoins peut soprer de diffrentes faons. Cela dit, il est recommand de complter le cahier des charges par des discussions approfondies avec le matre douvrage et les futurs utilisateurs du systme. Il convient galement dutiliser tous les documents produits propos du sujet (rapports techniques, tude de march) et dtudier les procdures administratives des fonctions de lentreprise qui seront prises en charge par le systme. La question que doit se poser le matre duvre durant le recueil des besoins est la suivante : ai-je toutes les connaissances et les informations pour dfinir ce que doit faire le systme ? y
UML 2
2. Le L diagramme de cas dutilisation d

2.1. Les cas dutilisation
Parlons prsent dUML et voyons quelle aide il peut apporter lors du recueil des besoins. UML nest quun langage et il ne sert ici qu formaliser les besoins, cest--dire les reprsenter sous une forme graphique suffisamment simple pour tre comprhensible par toutes les personnes impliques dans le projet. Noublions pas que bien souvent, le matre douvrage et les utilisateurs ne sont pas des informaticiens. Il leur faut donc un
10
moyen simple dexprimer leurs besoins. Cest prcisment le rle des diagrammes de cas dutilisation. Ils permettent de recenser les grandes fonctionnalits dun systme.
Exemple
La figure 1.1 modlise une borne interactive qui permet daccder une banque. Le systme modliser apparat dans un cadre (cela permet de sparer le systme modliser du monde extrieur). Les utilisateurs sont reprsents par des petits bonshommes, et les grandes fonctionnalits (les cas dutilisation) par des ellipses.
Figure 1.1 Diagramme de cas dutilisation modlisant une borne daccs une banque. frontire du sujet Borne interactive dune banque nom du sujet cas dutilisation
acteur
Retirer argent
Effectuer un virement
Client association
Consulter comptes
Lensemble des cas dutilisation contenus dans le cadre constitue un sujet . Les petits bonshommes sont appels acteurs . Ils sont connects par de simples traits (appels associations ) aux cas dutilisation et mettent en vidence les interactions possibles entre le systme et le monde extrieur. Chaque cas modlise une faon particulire et cohrente dutiliser un systme pour un acteur donn.
Dfinition
Un cas dutilisation est une manire spcifique dutiliser un systme. Les acteurs sont lextrieur du systme ; ils modlisent tout ce qui interagit avec lui. Un cas dutilisation ralise un service de bout en bout, avec un dclenchement, un droulement et une fin, pour lacteur qui linitie.
Notation et spcification
Un cas dutilisation se reprsente par une ellipse (figure 1.2). Le nom du cas est inclus dans lellipse ou bien il figure dessous. Un strotype (voir la dfinition ci-aprs), peut tre ajout optionnellement au-dessus du nom, et une liste de proprits place au-dessous. Un cas dutilisation se reprsente aussi sous la forme dun rectangle deux compartiments : celui du haut contient le nom du cas ainsi quune ellipse (symbole dun cas dutilisation) ; celui du bas est optionnel et peut contenir une liste de proprits (figure 1.3). Un acteur se reprsente par un petit bonhomme ayant son nom inscrit dessous (figure 1.1) ou par un rectangle contenant le strotype acteur avec son nom juste en dessous (figure 1.4). Il est recommand dajouter un commentaire sur lacteur pour prciser son rle.
Figure 1.2 et 1.3 Reprsentations dun cas dutilisation.
strotype Nom du cas Liste de proprits
Nom du cas Liste de proprits
11
Chapitre 1 Diagramme de cas dutilisation
UML 2
Figure 1.4 Autre reprsentation dun acteur.
Rle de lacteur acteur Nom de lacteur
La figure 1.4 reprsente un acteur par un rectangle. UML utilise aussi les rectangles pour reprsenter des classes, et plus gnralement des classeurs. Pour autant, la notation nest pas ambigu puisque le strotype acteur indique que le rectangle dsigne un acteur. Les strotypes permettent dadapter le langage des situations particulires.
Dfinition
Un strotype reprsente une variation dun lment de modle existant.
un niveau dabstraction plus lev, UML permet de reprsenter tous les cas dutilisation dun systme par un simple rectangle. La figure 1.5 montre comment un tel rectangle peut remplacer tous les cas dutilisation de la figure 1.1.
Figure 1.5 Reprsentation des cas dutilisation un niveau dabstraction lev. Borne interactive dune banque
Le rectangle de la figure 1.5 est appel classeur .
Dfinition
Un classeur est un lment de modlisation qui dcrit une unit comportementale ou structurelle. Les acteurs et les cas dutilisation sont des classeurs. Tout au long de ce livre, on retrouvera le terme classeur car cette notion englobe aussi les classes, des parties dun systme, etc.
Notation
Un classeur se reprsente par un rectangle contenant ventuellement des compartiments (la figure 1.6 montre comment il est possible de faire figurer explicitement des cas dutilisation dans un classeur).
Figure 1.6 Les compartiments dun classeur. Borne interactive dune banque
Retirer argent
Effectuer un virement
Consulter comptes
12
2.2. Relations entre acteurs et cas dutilisation

Un acteur peut utiliser plusieurs fois le mme cas dutilisation.
Exemple
La figure 1.7 montre un internaute qui tlcharge plusieurs morceaux de musique sur Internet.
Figure 1.7 Association avec multiplicit. * Internaute Logiciel de tlchargement Tlcharger une musique
Le symbole * qui signifie plusieurs est ajout lextrmit du cas et sappelle une multiplicit. Plusieurs valeurs sont possibles pour la multiplicit : exactement n scrit tout simplement n, m..n signifie entre m et n, etc. Prciser une multiplicit sur une relation nimplique pas ncessairement que les cas sont utiliss en mme temps.
2.3. Relations entre cas dutilisation

Pour clarifier un diagramme, UML permet dtablir des relations entre les cas dutilisation. Il existe principalement deux types de relations : les dpendances strotypes et la gnralisation/spcialisation. Les dpendances strotypes sont des dpendances dont la porte est explicite par le nom du strotype. Les strotypes les plus utiliss sont linclusion et lextension. La relation dinclusion. Un cas A est inclus dans un cas B si le comportement dcrit par le cas A est inclus dans le comportement du cas B : on dit alors que le cas B dpend de A. Cette dpendance est symbolise par le strotype inclut. Par exemple, laccs aux informations dun compte bancaire inclut ncessairement une phase dauthentification avec un mot de passe (figure 1.8). La relation dextension. Si le comportement de B peut tre tendu par le comportement de A, on dit alors que A tend B. Une extension est souvent soumise condition. Graphiquement, la condition est exprime sous la forme dune note. La figure 1.8 prsente lexemple dune banque o la vrification du solde du compte nintervient que si la demande de retrait dargent dpasse 20 euros. La relation de gnralisation. Un cas A est une gnralisation dun cas B si B est un cas particulier de A. la figure 1.8, la consultation dun compte bancaire via Internet est un cas particulier de la consultation. Cette relation de gnralisation/spcialisation est prsente dans la plupart des diagrammes UML et se traduit par le concept dhritage dans les langages orients objet. Les inclusions permettent aussi de dcomposer un cas complexe en sous-cas plus simples.
Exemple
la figure 1.9, le modlisateur a jug que la vente dun article par correspondance est un problme complexe et quil est important de faire apparatre dans le modle une dcomposition en sous-cas. 13
UML 2
Notation et spcification
Une dpendance se reprsente par une flche pointille. Un strotype est souvent ajout audessus du trait. Le strotype inclut indique que la relation de dpendance est une inclusion (figures 1.8 et 1.9). Le strotype tend indique une extension (figure 1.8). Lextension peut intervenir un point prcis du cas tendu ; ce point sappelle le point dextension ; il porte un nom, qui figure dans un compartiment du cas tendu sous la rubrique point dextension , et est ventuellement associ une contrainte indiquant le moment o lextension intervient. Une extension est souvent soumise une condition (indique dans une note attache la flche pointille). Le symbole utilis pour la gnralisation est une flche en traits pleins dont la pointe est un triangle ferm. La flche pointe vers le cas le plus gnral (figure 1.8).
Figure 1.8 Relations entre cas dans un diagramme de cas dutilisation.
Borne interactive dune banque

Retirer argent
Effectuer un virement Point dextension : vrificationSolde {aprs avoir demand le montant}
inclut inclut
Sauthentifier
tend
Client Vrifier le solde Condition : {si montant > 20 euros} Point dextension : vrificationSolde Consulter comptes
inclut
Consulter sur Internet
Figure 1.9 Relations entre cas pour dcomposer un cas complexe.
Systme de vente par correspondance Vrifier la disponibilit de larticle inclut Passer une commande inclut Prpos aux commandes Vrifier la solvabilit du client
14
Un cas reli un autre cas peut ne pas tre directement accessible un acteur (figure 1.9). Un tel cas est appel cas interne .
Dfinition
Un cas dutilisation est dit interne sil nest pas reli directement un acteur.
Les relations entre cas ne sont pas obligatoires. Elles permettent de clarifier et denrichir les cas dutilisation. Par exemple, la figure 1.8, rien nempche de regrouper les cas Consulter comptes et Consulter sur Internet en un seul cas. Cependant, indiquer ds la phase de recueil des besoins quil y a des cas particuliers apporte une information supplmentaire pertinente. La question se poser est : faut-il la faire figurer dans le diagramme de cas dutilisation ou la prendre en compte plus tard ? La rponse cette question ne sera pas toujours la mme selon le contexte du projet.
Remarque
Attention lorientation des flches : si le cas A inclut B on trace la flche de A vers B, mais si B tend A, la flche est dirige de B vers A.
2.4. Relations entre acteurs

La seule relation possible entre deux acteurs est la gnralisation : un acteur A est une gnralisation dun acteur B si lacteur A peut tre substitu par lacteur B (tous les cas dutilisation accessibles A le sont aussi B, mais linverse nest pas vrai).
Exemple
La figure 1.10 montre que le directeur des ventes est un prpos aux commandes avec un pouvoir supplmentaire (en plus de pouvoir passer et suivre une commande, il peut grer le stock). Le prpos aux commandes ne peut pas grer le stock.
Figure 1.10 Relations entre acteurs. Systme de vente par correspondance
Passer une commande
inclut
Suivre une commande Prpos aux commandes
inclut
Rechercher article
inclut
Grer le stock Directeur des ventes
Notation
Le symbole utilis pour la gnralisation entre acteurs est une flche en traits pleins dont la pointe est un triangle ferm. La flche pointe vers lacteur le plus gnral. 15
UML 2
2.5. Regroupement des cas dutilisation en paquetages

UML permet de regrouper des cas dutilisation dans une entit appele paquetage . Le regroupement peut se faire par acteur ou par domaine fonctionnel. Un diagramme de cas dutilisation peut contenir plusieurs paquetages et des paquetages peuvent tre inclus dans dautres paquetages.
Dfinition
Un paquetage permet dorganiser des lments de modlisation en groupe. Un paquetage peut contenir des classes, des cas dutilisations, des interfaces, etc.
Exemple
la figure 1.11, trois paquetages ont t crs : Client, Stock et Support. Ces paquetages contiennent les cas dutilisation du diagramme de la figure 1.10 (Client contient les cas Passer une commande et Suivre une commande , Stock contient le cas Grer le stock , tandis que le cas Rechercher article est inclus dans le paquetage Support.
Figure 1.11 Regroupement des cas dutilisation en paquetage. Dpendance entre paquetages qui reflte linclusion des cas dutilisation. Support
Client
Stock
En tant que langage, UML est soumis des rgles de nommage quil faut strictement respecter : pour accder au contenu de paquetages imbriqus les uns dans les autres, il faut utiliser des deux-points comme sparateur des noms de paquetage. Par exemple, si un paquetage B inclus dans un paquetage A contient une classe X, il faut crire A::B::X pour pouvoir utiliser la classe X en dehors du contexte des paquetages.
3. M Modlisation des besoins avec a UML

3.1. Qui sont les acteurs ? Comment les identifier ?
Les principaux acteurs sont les utilisateurs du systme. Ils sont en gnral faciles reprer. Cest le matre douvrage qui les dsigne. Chaque acteur doit tre nomm, mais attention, pour trouver son nom, il faut penser son rle : un acteur reprsente un ensemble cohrent de rles jous vis--vis dun systme. Ainsi, pour un logiciel de gestion de paie, le nom correct dun acteur est Comptable plutt que Mme Dupont. Plusieurs personnes
16
peuvent avoir le mme rle. Cest le cas des clients dune banque par exemple. Il ny aura alors quun seul acteur. Rciproquement, une mme personne physique peut jouer des rles diffrents vis--vis du systme et donc correspondre plusieurs acteurs. En gnral, les utilisateurs ne sont pas difficiles trouver, mais il faut veiller ne pas oublier les personnes responsables de lexploitation et de la maintenance du systme. Par exemple, un logiciel de surveillance qui limite les accs un btiment doit avoir un administrateur charg de crer des groupes de personnes et leur donner des droits daccs. Il ne sagit pas ici des personnes qui installent et paramtrent le logiciel avant sa mise en production, mais des utilisateurs du logiciel dans son fonctionnement nominal. En plus des utilisateurs, les acteurs peuvent tre : des priphriques manipuls par le systme (imprimantes, robots) ; des logiciels dj disponibles intgrer dans le projet ; des systmes informatiques externes au systme mais qui interagissent avec lui, etc. Pour faciliter la recherche des acteurs, on peut imaginer les frontires du systme. Tout ce qui est lextrieur et qui interagit avec le systme est un acteur ; tout ce qui est lintrieur est une fonctionnalit du systme que le matre duvre doit raliser. Un cas dutilisation a toujours au moins un acteur principal pour qui le systme produit un rsultat observable, et ventuellement dautres acteurs ayant un rle secondaire. Par exemple, lacteur principal dun cas de retrait dargent dans un distributeur automatique de billets est la personne qui fait le retrait, tandis que la banque qui vrifie le solde du compte est un acteur secondaire. En gnral, lacteur principal initie le cas dutilisation par ses sollicitations.
Dfinition
Lacteur est dit principal pour un cas dutilisation lorsque le cas dutilisation rend service cet acteur. Les autres acteurs sont dits secondaires . Un cas dutilisation a au plus un acteur principal, et un ensemble ventuellement vide dacteurs secondaires. Un acteur principal obtient un rsultat observable du systme tandis quun acteur secondaire est sollicit pour des informations complmentaires.
3.2. Comment recenser les cas dutilisation ?

Il ny a pas une faon unique de reprer les cas dutilisation. Il faut se placer du point de vue de chaque acteur et dterminez comment il se sert du systme, dans quels cas il lutilise, et quelles fonctionnalits il doit avoir accs. Il faut viter les redondances et limiter le nombre de cas en se situant au bon niveau dabstraction (par exemple, ne pas rduire un cas une action).
Exemple
Considrons un systme de rservation et dimpression de billets de train via des bornes interactives situes dans des gares. En prenant pour acteur une personne qui souhaite obtenir un billet, on peut obtenir la liste suivante des cas dutilisation : rechercher un voyage ; rserver une place dans un train ; acheter son billet.
17
Lensemble des cas dutilisation doit couvrir exhaustivement tous les besoins fonctionnels du systme. Ltape de recueil des besoins est souvent longue et fastidieuse car les utilisateurs connaissent lexistant et nont quune vague ide de ce que leur apportera un futur systme ; en outre, le cahier des charges contient des imprcisions, des oublis, voire des informations contradictoires difficiles extraire. Llaboration du diagramme de cas dutilisation permet de pallier ces problmes en recentrant le systme sur les besoins fonctionnels et ce, ds le dbut du projet. On peut se demander pourquoi adopter un point de vue fonctionnel, et non technique ? Trop souvent, par le pass, les logiciels taient techniquement trs labors sans pour autant satisfaire les utilisateurs. Avec les diagrammes de cas dutilisation, on se place clairement du ct des utilisateurs. Le ct technique nest pas oubli mais abord diffremment : les besoins sont affins lors de lcriture des spcifications on parle de spcifications techniques des besoins (voir la section Description textuelle des cas dutilisation ).
UML 2
Remarque
Il ne faut pas faire apparatre les dtails des cas dutilisation, mais il faut rester au niveau des grandes fonctions du systme. La question qui se pose alors est de savoir jusqu quel niveau de dtails descendre ? Si le nombre de cas est trop important, il faut se demander si on a fait preuve de suffisamment dabstraction. Le nombre de cas dutilisation est un bon indicateur de la faisabilit dun logiciel. Il ne doit pas y avoir de notion temporelle dans un diagramme de cas dutilisation. Il ne faut pas se dire que lacteur fait ceci, puis le systme lui rpond cela, ce qui implique une raction de lacteur, et ainsi de suite. Le squencement temporel sera pris en compte plus tard, notamment dans la description dtaille des cas (voir section 3.3). Lintrt des cas dutilisation ne se limite pas au recueil des besoins. La description des cas dutilisation peut servir de base de travail pour tablir les tests de vrification du bon fonctionnement du systme, et orienter les travaux de rdaction de la documentation lusage des utilisateurs.
3.3. Description des cas dutilisation

Le diagramme de cas dutilisation dcrit les grandes fonctions dun systme du point de vue des acteurs, mais nexpose pas de faon dtaille le dialogue entre les acteurs et les cas dutilisation.
Exemple
Lexemple de la figure 1.12 ne permet pas de savoir ce qui entre et ce qui sort du logiciel bancaire : le retrait dargent se fait-il en euros ou en dollars ? Dans quel ordre les oprations sont-elles effectues ? Faut-il choisir le montant du retrait avant de choisir le compte dbiter, ou bien linverse ? Tous ces dtails sont des lments de spcification. Spcifier un produit, cest le dcrire de la faon la plus prcise possible.
Figure 1.12 Diagramme de cas dutilisation pour une banque. Gestion dune banque Retirer argent
Guichetier
Consulter compte
Systme central
18
Les spcifications peuvent tre divises en deux catgories selon quelles sont fonctionnelles ou techniques. Les spcifications fonctionnelles concernent les fonctions du systme, la fonction de retrait dargent par exemple, tandis que les spcifications techniques permettent de prciser le contexte dexcution du systme. Par exemple, le logiciel qui gre la distribution des billets doit tre compatible avec tel ou tel systme dexploitation, ou encore, un retrait dargent doit se faire en moins de 5 secondes. Les spcifications fonctionnelles dcoulent directement du diagramme de cas dutilisation. Il sagit de reprendre chaque cas et de le dcrire trs prcisment. En dautres termes, vous devez dcrire comment les acteurs interagissent avec le systme.
Exemple
partir du diagramme de cas dutilisation de lexemple prcdent, la figure 1.13 montre une faon de dcrire les interactions entre le guichetier et le systme. On y voit clairement apparatre une squence de messages. Le graphisme utilis fait partie du formalisme des diagrammes de squence (voir chapitre 3).
Figure 1.13 Description dun cas dutilisation par une squence de messages. sd Retirer argent
: Systme Guichetier Saisie du numro de compte client Demande de validit du compte Compte valide Demande type dopration Retrait despces de 200 euros Demande de dbit du compte Compte dbit Autorisation de dlivrer les 200 euros Systme central
Les diffrentes faons de dcrire les cas dutilisation

UML nimpose rien quant la faon de dcrire un cas dutilisation. Au lieu dutiliser une squence de messages, il est possible dutiliser les diagrammes dactivits dUML (voir chapitre 5). Cette libert de choix peut tre droutante, mais comme UML est cens pouvoir modliser tout type de systme, une manire unique de dcrire un cas ne suffirait pas.
Remarque
Une des forces de la notation UML est de proposer de nombreux types de diagrammes qui mettent en avant des aspects diffrents dune description. Ainsi, le modlisateur peut utiliser le type de diagramme qui lui parat le plus adapt pour reprsenter son problme (et sa solution), tout en restant dans la norme. 19
UML 2
Description textuelle des cas dutilisation

Bien que de nombreux diagrammes dUML permettent de dcrire un cas, il est recommand de rdiger une description textuelle car cest une forme souple qui convient dans bien des situations. Une description textuelle couramment utilise se compose de trois parties, comme le montre lexemple suivant. La premire partie permet didentifier le cas. Elle doit contenir : le nom du cas ; un rsum de son objectif ; les acteurs impliqus (principaux et secondaires) ; les dates de cration et de mise jour de la description courante ; le nom des responsables ; un numro de version. La deuxime partie contient la description du fonctionnement du cas sous la forme dune squence de messages changs entre les acteurs et le systme. Elle contient toujours une squence nominale qui correspond au fonctionnement nominal du cas (par exemple, un retrait dargent qui se termine par lobtention des billets demands par lutilisateur). Cette squence nominale commence par prciser lvnement qui dclenche le cas (lutilisateur introduit sa carte bancaire par exemple) et se dveloppe en trois points : Les pr-conditions. Elles indiquent dans quel tat est le systme avant que se droule la squence (le distributeur est aliment en billets par exemple). Lenchanement des messages. Les post-conditions. Elles indiquent dans quel tat se trouve le systme aprs le drouement de la squence nominale (une transaction a t enregistre par la banque par exemple). Parfois la squence correspondant un cas a besoin dtre appele dans une autre squence (par exemple quand une relation dinclusion existe entre deux cas dutilisation). Signifier lappel dune autre squence se fait de la faon suivante : appel du cas X , o X est le nom du cas. Les acteurs ntant pas sous le contrle du systme, ils peuvent avoir des comportements imprvisibles. La squence nominale ne suffit donc pas pour dcrire tous les comportements possibles. la squence nominale sajoutent frquemment des squences alternatives et des squences dexceptions. Ces deux types de squences se dcrivent de la mme faon que la squence nominale mais il ne faut pas les confondre. Une squence alternative diverge de la squence nominale (cest un embranchement dans une squence nominale) mais y revient toujours, alors quune squence dexception intervient quand une erreur se produit (le squencement nominal sinterrompt, sans retour la squence nominale).
Exemple
Dans le cas dun retrait dargent, des squences alternatives se produisent par exemple dans les situations suivantes : Le client choisit deffectuer un retrait en euros ou en dollars. Le client a la possibilit dobtenir un reu. Une exception se produit si la connexion avec le systme central de la banque qui doit vrifier la validit du compte est interrompue. 20
La survenue des erreurs dans les squences doit tre signale de la faon suivante : appel de lexception Y o Y est le nom de lexception. La dernire partie de la description dun cas dutilisation est une rubrique optionnelle. Elle contient gnralement des spcifications non fonctionnelles (ce sont le plus souvent des spcifications techniques, par exemple pour prciser que laccs aux informations bancaires doit tre scuris). Cette rubrique contient aussi dventuelles contraintes lies aux interfaces homme-machine (par exemple, pour donner la possibilit daccder tous les comptes dun utilisateur partir de lcran principal).
Description dun retrait dargent

Identification Nom du cas : retrait despces en euros. But : dtaille les tapes permettant un guichetier deffectuer lopration de retrait deuros demand par un client. Acteur principal : Guichetier. Acteur secondaire : Systme central. Date : le 18/02/2005. Responsable : M. Dupont. Version : 1.0. Squencement Le cas dutilisation commence lorsquun client demande le retrait despces en euros. Pr-conditions Le client possde un compte (donne son numro de compte). Enchanement nominal 1. Le guichetier saisit le numro de compte client. 2. Lapplication valide le compte auprs du systme central. 3. Lapplication demande le type dopration au guichetier. 4. Le guichetier slectionne un retrait despces de 200 euros. 5. Lapplication demande au systme central de dbiter le compte. 6. Le systme notifie au guichetier quil peut dlivrer le montant demand. Post-conditions Le guichetier ferme le compte. Le client rcupre largent. Rubriques optionnelles Contraintes non fonctionnelles Fiabilit : les accs doivent tre extrmement srs et scuriss. Confidentialit : les informations concernant le client ne doivent pas tre divulgues. Contraintes lies linterface homme-machine Donner la possibilit daccder aux autres comptes du client. Toujours demander la validation des oprations de retrait.
La squence nominale, les squences alternatives, les exceptions, etc., font quil existe une multitude de chemins depuis le dbut du cas jusqu la fin. Chaque chemin est appel scnario . Un systme donn gnre peu de cas dutilisation, mais, en gnral, beaucoup de scnarios.
21
UML 2
Remarque
Parfois, les utilisateurs ont du mal dcrire un cas sous une forme textuelle. Il est alors judicieux de se servir dune autre forme de description, en utilisant un organigramme ou encore en construisant des maquettes des interfaces homme-machine. Le dessin, mme sommaire, de laspect des crans des interfaces permet de fixer les ides ; il offre une excellente base pour la discussion avec le matre douvrage, qui le considre comme plus parlant .
Conclusion
Les phases de recueil des besoins et dcriture des spcifications sont longues et fastidieuses. Mais quand elles sont bien menes, elles permettent de lever toutes les ambiguts du cahier des charges et de recueillir les besoins dans leurs moindres dtails. Les spcifications permettant dapprofondir les besoins (on parle dailleurs juste titre de spcifications techniques des besoins), la frontire entre ces deux notions est floue. Il nest pas question ce moment de la modlisation de limiter les besoins. Du ct du matre duvre, la tendance est les limiter des fonctionnalits essentielles, tandis que le matre douvrage, et surtout les utilisateurs, ont tendance en exprimer bien plus quil nest possible den raliser. Le matre duvre doit faire preuve ici de patience et mener la phase de spcifications de tous les besoins jusqu son terme. Cest ce moment seulement, que des priorits sont mises sur les spcifications. Le matre duvre tente alors dagencer les besoins de faon cohrente et fait plusieurs propositions de solutions au matre douvrage, qui couvrent plus ou moins de besoins. UML ne propose rien pour mettre des priorits sur les spcifications. Le diagramme de cas dutilisation est un premier modle dun systme. Que savonsnous sur le systme aprs avoir cr ce diagramme ? Sur le systme lui-mme, en interne, pas grand-chose vrai dire. Cest encore une bote noire larchitecture et au mode de fonctionnement interne inconnus. Donc, a fortiori, ce stade, nous ne savons toujours pas comment le raliser. En revanche, son interface avec le monde qui lentoure est partiellement connue : nous nous sommes placs du point de vue des acteurs pour dfinir les spcifications fonctionnelles. Il faut sattarder un instant sur lexpression partiellement connue pour mesurer les limites du modle des cas dutilisation. Les spcifications fonctionnelles disent ce que le systme doit faire pour les acteurs. En dautres termes, nous connaissons prcisment ce qui entre et ce qui sort du systme, mais, en revanche, nous ne savons toujours pas comment raliser cette interface avec lextrieur. Lobjectif de cette phase de la modlisation est donc de clairement identifier les frontires du systme et les interfaces quil doit offrir lutilisateur. Si cette tape commence avant la conception de larchitecture interne du systme, il est en gnral utile, quand la rflexion est suffisamment pousse, de poser les bases de la structure interne du systme, et donc dalterner analyse des besoins et bauche des solutions envisages. Aux spcifications fonctionnelles sajoutent des spcifications techniques qui peuvent tre vues comme des exigences pour la future ralisation. Le prsent chapitre se poursuit par une srie de problmes corrigs. Le chapitre 2, quant lui, prsente le diagramme des classes, qui permet de modliser la structure interne dun systme.
22
Problmes et exercices
La construction dun diagramme de cas dutilisation dbute par la recherche des frontires du systme et des acteurs, pour se poursuivre par la dcouverte des cas dutilisation. Lordre des exercices suit cette progression. Llaboration proprement dite dun diagramme de cas dutilisation est illustre par plusieurs exercices. Ce chapitre se termine par des tudes de cas de complexits croissantes.
Exercice 1 : Identification des acteurs et recensement de cas dutilisation simples

Considrons le systme informatique qui gre une station-service de distribution dessence. On sintresse la modlisation de la prise dessence par un client. 1. Le client se sert de lessence de la faon suivante. Il prend un pistolet accroch une pompe et appuie sur la gchette pour prendre de lessence. Qui est lacteur du systme ? Est-ce le client, le pistolet ou la gchette ? 2. Le pompiste peut se servir de lessence pour sa voiture. Est-ce un nouvel acteur ? 3. La station a un grant qui utilise le systme informatique pour des oprations de gestion. Est-ce un nouvel acteur ? 4. La station-service a un petit atelier dentretien de vhicules dont soccupe un mcanicien. Le grant est remplac par un chef datelier qui, en plus dassurer la gestion, est aussi mcanicien. Comment modliser cela ?
Solution
1 1. Pour le syst systme informatique qui pilote la station-service, le pistolet et la gchette sont des priphriques matriels. De ce point de vue, ce sont des acteurs. Il est nanmoins ncessaire de consigner dans le systme informatique ltat de ces priphriques : ds quun client prend le pistolet par exemple, le systme doit informer le pompiste en indiquant le type dessence choisi. Pistolet et gchette doivent donc faire partie du systme modliser. Ici, nous sommes face deux options contradictoires : soit le pistolet et la gchette sont des acteurs, soit ils ne le sont pas. Pour lever cette ambigut, il faut adopter le point de vue du client. Le client agit sur le systme informatique quand il se sert de lessence. Laction de se servir constitue une transaction bien isole des autres fonctionnalits de la station-service. Nous disons donc que Se servir est un cas dutilisation. Le client, qui est en dehors du systme, devient alors lacteur principal, comme le montre la figure 1.14. Ce cas englobe la prise du pistolet et lappui sur la gchette. Ces priphriques ne sont plus considrs comme des acteurs ; sils ltaient, la modlisation se ferait un niveau de dtails trop important. Le client est donc lacteur principal du systme. Or, bien souvent, le pompiste note le numro dimmatriculation du vhicule du client dans le systme informatique.
23
Le client doit alors tre modlis deux fois : la premire fois en tant quacteur, et la seconde, lintrieur du systme, pour y conserver un numro dimmatriculation.
Figure 1.14 Le client comme acteur du cas Se servir . Client Station-service Se servir
2. Un acteur est caractris par le rle quil joue vis--vis du systme. Le pompiste, bien qutant une personne diffrente du client, joue un rle identique quand il se sert de lessence. Pour le cas Se servir , il nest pas ncessaire de crer un acteur supplmentaire reprsentant le pompiste. 3. La gestion de la station-service dfinit une nouvelle fonctionnalit modliser. Le grant prend le rle principal ; cest donc un nouvel acteur (figure 1.15).
Figure 1.15 Deux acteurs pour deux rles. Client Grer la station Grant Station-service
Se servir
4. La station offre un troisime service : lentretien des vhicules. Le systme informatique doit prendre en charge cette fonctionnalit supplmentaire. Un nouvel acteur apparat alors : le mcanicien. Le grant est prsent un chef datelier qui est un mcanicien ayant la capacit de grer la station. Il y a ainsi une relation de gnralisation entre les acteurs Mcanicien et Chef datelier (figure 1.16) signifiant que le chef datelier peut, en plus dassurer la gestion, entretenir des vhicules.
Figure 1.16 Relation de gnralisation entre acteurs. Client Entretenir des vhicules Mcanicien Station-service Se servir
Grer la station Chef datelier
24
Exercice 2 : Relations entre cas dutilisation

Quel est le dfaut du diagramme prsent la figure 1.17 ?
Figure 1.17 Exemple dun diagramme erron.
Dcrocher le pistolet Client Station-service
Appuyer sur la gchette
Reposer le pistolet
Payer
Solution
Il ne f faut t pas introduire de squencement temporel entre des cas dutilisation (cette notion apparat lors de la description des cas). De plus, il est incorrect dutiliser un trait plein pour relier deux cas. Cette notation est rserve aux associations entre les acteurs et les cas.
Exercice 3 : Relations entre cas dutilisation cas internes

Choisissez et dessinez les relations entre les cas suivants : 1. Une agence de voyages organise des voyages o lhbergement se fait en htel. Le client doit disposer dun taxi quand il arrive la gare pour se rendre lhtel.
Figure 1.18 Diagramme incomplet des cas dutilisation dune agence de voyages.
Agence de voyages Rserver une chambre dhtel Rserver un taxi Rserver un billet de train
Organiser un voyage Agent de voyages
2. Certains clients demandent lagent de voyages dtablir une facture dtaille. Cela donne lieu un nouveau cas dutilisation appel tablir une facture dtaille . Comment mettre ce cas en relation avec les cas existants ? 3. Le voyage se fait soit par avion, soit par train. Comment modliser cela ?
25
Solution
1 1. Le modlisa modlisateur a considr que lorganisation dun voyage est trop complexe pour tre reprsente par un seul cas dutilisation. Il la donc dcompose en trois tches modlises par les trois cas dutilisation Rserver une chambre dhtel , Rserver un taxi et Rserver un billet de train . Ces trois tches forment des transactions suffisamment isoles les unes des autres pour tre des cas dutilisation. De plus, ces cas sont mutuellement indpendants. Ils constituent des cas internes du systme car ils ne sont pas relis directement un acteur.
Figure 1.19 Relations dinclusion entre cas dutilisation. Agence de voyages Rserver une chambre dhtel inclut Rserver un taxi Rserver un billet de train
inclut Organiser un voyage
inclut
Agent de voyages
2. Ltablissement dune facture dtaille se fait uniquement sur demande du client. Ce caractre optionnel est modlis par une relation dextension entre les cas Organiser un voyage et tablir une facture dtaille . Lextension porte la condition la demande du client .
Figure 1.20 Relation dextension entre cas dutilisation. Agence de voyages Rserver une chambre dhtel
Rserver un taxi
Rserver un billet de train
inclut
inclut
inclut
Organiser un voyage Agent de voyages Points dextension : tablirUneFacture
Condition : { la demande du client} Point dextension : tablirUneFacture
tend
tablir une facture dtaille
26
3. Il y a maintenant deux cas particuliers : le voyage se fait en train ou en avion. Ces cas particuliers sont modliss par les cas Rserver un billet de train et Rserver un billet davion . Ceux-ci sont lis un cas plus gnral appel Rserver un titre de transport .
Figure 1.21 Relation de gnralisation entre cas dutilisation.
Agence de voyages Rserver une chambre dhtel Rserver un taxi Rserver un titre de transport
inclut
inclut Organiser un voyage
inclut
Agent de voyages
Points dextension : tablirUneFacture
Condition : { la demande du client} Point dextension : tablirUneFacture
Rserver un billet de train tend
Rserver un billet davion
tablir une facture dtaille
Exercice 4 : Identification des acteurs, recensement des cas dutilisation et relations simples entre cas
Modlisez avec un diagramme de cas dutilisation le fonctionnement dun distributeur automatique de cassettes vido dont la description est donne ci-aprs. Une personne souhaitant utiliser le distributeur doit avoir une carte magntique spciale. Les cartes sont disponibles au magasin qui gre le distributeur. Elles sont crdites dun certain montant en euros et rechargeables au magasin. Le prix de la location est fix par tranches de 6 heures (1 euro par tranche). Le fonctionnement du distributeur est le suivant : le client introduit sa carte ; si le crdit est suprieur ou gal 1 euro, le client est autoris louer une cassette (il est invit aller recharger sa carte au magasin sinon) ; le client choisit une cassette et part avec ; quand il la ramne, il lintroduit dans le distributeur puis insre sa carte ; celle-ci est alors dbite ; si le montant du dbit excde le crdit de la carte, le client est invit rgulariser sa situation au magasin et le systme mmorise le fait quil est dbiteur ; la gestion des comptes dbiteurs est prise en charge par le personnel du magasin. On ne sintresse ici qu la location des cassettes, et non la gestion du distributeur par le personnel du magasin (ce qui exclut la gestion du stock des cassettes).
Solution
L seul Le l acteur t est le client. Lacquisition dune carte et sa recharge ne se font pas via le distributeur : il faut aller au magasin. Ces fonctions ne donnent pas lieu des cas dutilisation.
27
Il ne faut pas faire apparatre un squencement temporel dans un diagramme de cas dutilisation. On ne fait donc pas figurer les tapes successives telles que lintroduction de la carte puis le choix dune cassette, etc. Ce niveau de dtails apparatra quand on dcrira les cas dutilisation (sous forme textuelle par exemple). Dans un diagramme de cas dutilisation, il faut rester au niveau des grandes fonctions et penser en termes de transactions (une transaction est une squence doprations qui fait passer un systme dun tat cohrent initial un tat cohrent final). Il ny a donc que deux cas : Emprunter une vido et Restituer une vido (figure 1.22).
Figure 1.22 Diagramme de cas dutilisation dun distributeur de cassettes vido. Magasin de location de cassettes vido
Emprunter une vido
Client
Restituer une vido
Nom de lacteur
Rle
Client
Reprsente un client du magasin de location de cassettes vido.
Pour dcrire le cas Emprunter une vido , imaginons un scnario possible. Le client introduit sa carte. Il doit ensuite pouvoir choisir une vido. Quels sont les critres de choix ? Lnonc ne prcise pas ces critres. Ce problme arrive frquemment en situation relle. Le matre douvrage dans un projet informatique de cette ampleur est bien souvent le propritaire du magasin de location. Il sait rarement rdiger un cahier des charges. Cest le rle du matre duvre dobliger le matre douvrage bien formuler ses besoins. Choisir une vido peut tre complexe : la recherche se fait-elle par genres, par titres ou par dates de sortie des films en salles ? Si la recherche se fait par genres, quels sont-ils ? Rechercher un film semble plus complexe quon ne limaginait au premier abord. De plus, cette fonctionnalit peut tre isole de la location proprement dite, qui concerne plutt la gestion de la carte. Ces remarques incitent crer le cas supplmentaire Rechercher une vido . Lemprunt dune vido inclut sa recherche. Une relation dinclusion intervient donc entre les cas Emprunter une vido et Rechercher une vido , comme le montre la figure 1.23.
Figure 1.23 Diagramme de cas dutilisation complt par la recherche dune vido. Magasin de location de cassettes vido
Emprunter une vido
inclut Rechercher une vido
Client
Restituer une vido
28
ce point de la modlisation, deux remarques simposent : Le succs dUML en tant que langage de modlisation sexplique, entre autres, par le fait quil oblige le modlisateur poser les bonnes questions au bon moment ; la modlisation vient peine de commencer que dj des questions se posent. Il faut cependant veiller rester au niveau du recueil des besoins et des spcifications et ne faire aucun choix de conception du systme. Il faut se contenter de dcrire les fonctions du systme sans chercher savoir comment les raliser. Le problme des critres de recherche a conduit une rvision du diagramme de cas dutilisation. Cet aller-retour sur les modles est ncessaire. Chacun deux apporte des informations complmentaires qui peuvent remettre en cause les modles existants. Une fois tous les modles tablis, la modlisation sera alors aboutie.
Exercice 5 : Description dun cas dutilisation

Dcrivez sous forme textuelle les cas dutilisation Emprunter une vido et Rechercher une vido du diagramme prsent la figure 1.23. La recherche dune vido peut se faire par genres ou par titres de film. Les diffrents genres sont action, aventure, comdie et drame. Quand une liste de films saffiche, le client peut trier les films par titres ou par dates de sortie en salles.
Solution
Avant de prse prsenter la solution, donnons quelques indications : Tous les cas dutilisation dun systme doivent tre dcrits sous forme textuelle (dans la suite de ce chapitre, nous omettrons ventuellement de le faire pour des raisons de place ou dintrt). Quand une erreur (exception) est dtecte dans un cas, une squence derreurs est active (par exemple, voir la squence E1 dans la description suivante). La squence nominale nest pas reprise et le cas sinterrompt aussitt.
Description du cas Emprunter une vido

Identification Nom du cas : Emprunter une vido . But : dcrire les tapes permettant au client du magasin demprunter une cassette vido via le distributeur automatique. Acteur principal : Client. Acteur secondaire : nant. Date de cration : le 31/12/2004. Date de mise jour : le 1/1/2005. Responsable : M. Dupont. Version : 1.1. Squencement Le cas dutilisation commence lorsquun client introduit sa carte. 29
Description du cas Emprunter une vido (suite)

Pr-conditions Le client possde une carte quil a achete au magasin. Le distributeur est aliment en cassettes.
Enchanement nominal
1. 2. 3. 4. 5. 6. 7. 8. 9. Le systme vrifie la validit de la carte. Le systme vrifie que le crdit de la carte est suprieur ou gal 1 euro. Appel du cas Rechercher une vido . Le client a choisi une vido. Le systme indique, daprs la valeur de la carte, pendant combien de temps (tranches de 6 heures) le client peut garder la cassette. Le systme dlivre la cassette. Le client prend la cassette. Le systme rend la carte au client. Le client prend sa carte.
Enchanements alternatifs
A1 : Le crdit de la carte est infrieur 1 euro. Lenchanement dmarre aprs le point 2 de la squence nominale : 3. Le systme indique que le crdit de la carte ne permet pas au client demprunter une vido. 4. Le systme invite le client aller recharger sa carte au magasin. La squence nominale reprend au point 8.
Enchanements dexception E1 : La carte introduite nest pas valide.

Lenchanement dmarre aprs le point 1 de la squence nominale : 2. Le systme indique que la carte nest pas reconnue. 3. Le distributeur jecte la carte.
E2 : La cassette nest pas prise par le client.

Lenchanement dmarre aprs le point 6 de la squence nominale : 7. Au bout de 15 secondes le distributeur avale la cassette. 8. Le systme annule la transaction (toutes les oprations mmorises par le systme sont dfaites). 9. Le distributeur jecte la carte.
E3 : La carte nest pas reprise par le client.

Lenchanement dmarre aprs le point 8 de la squence nominale : 9. Au bout de 15 secondes le distributeur avale la carte. 10. Le systme consigne cette erreur (date et heure de la transaction, identifiant du client, identifiant du film).
E4 : Le client a annul la recherche (il na pas choisi de vido).

Lenchanement dmarre au point 4 de la squence nominale : 5. Le distributeur jecte la carte.
Post-conditions
Le systme a enregistr les informations suivantes : La date et lheure de la transaction, la minute prs : les tranches de 6 heures sont calcules la minute prs. Lidentifiant du client. Lidentifiant du film emprunt. Rubriques optionnelles
Contraintes non fonctionnelles

Le distributeur doit fonctionner 24 heures sur 24 et 7 jours sur 7. La vrification de la validit de la carte doit permettre la dtection des contrefaons.
Contrainte lie linterface homme-machine

Avant de dlivrer la cassette, demander confirmation au client. 30
Description du cas Rechercher une vido

Identification Nom du cas : Rechercher une vido . But : dcrire les tapes permettant au client de rechercher une vido via le distributeur automatique. Acteur principal : nant (cas interne inclus dans le cas Emprunter une vido ). Acteur secondaire : nant. Date de cration : le 31/12/2004. Responsable : M. Dupont. Version : 1.0. Squencement Le cas dmarre au point 3 de la description du cas Emprunter une vido .
Enchanement nominal (le choix du film se fait par genres)

1. Le systme demande au client quels sont ses critres de recherche pour un film (les choix possibles sont : par titres ou par genres de film). 2. Le client choisit une recherche par genres. 3. Le systme recherche les diffrents genres de film prsents dans le distributeur. 4. Le systme affiche une liste des genres (les choix possibles sont action, aventure, comdie et drame). 5. Le client choisit un genre de film. 6. Le systme affiche la liste de tous les films du genre choisi prsents dans le distributeur. 7. Le client slectionne un film.
Enchanements alternatifs A1 : Le client choisit une recherche par titres.

Lenchanement dmarre aprs le point 1 de la squence nominale : 2. Le client choisit une recherche par titres. 3. Le systme affiche la liste de tous les films classs par ordre alphabtique des titres. La squence nominale reprend au point 7.
Enchanements dexception E1 : Le client annule la recherche.

Lenchanement peut dmarrer aux points 2, 5 et 7 de la squence nominale : Appel de lexception E4 du cas Emprunter une vido .
Post-conditions Le systme a mmoris le film choisi par le client.
Rubriques optionnelles Contraintes non fonctionnelles Contraintes lies linterface homme-machine

Quand une liste de films saffiche, le client peut trier la liste par titres ou par dates de sortie en salles. Le client peut se dplacer dans la liste et la parcourir de haut en bas et de bas en haut. Ne pas afficher plus de 10 films la fois dans la liste.
31
Exercice 6 : Relations dextension entre cas dutilisation, regroupement de cas dutilisation en paquetages
Modlisez laide dun diagramme de cas dutilisation un systme informatique de pilotage dun robot distance. Le fonctionnement du robot est dcrit ci-aprs. Un robot dispose dune camra pour filmer son environnement. Il peut avancer et reculer grce un moteur lectrique capable de tourner dans les deux sens et commandant la rotation des roues. Il peut changer de direction car les roues sont directrices. Il est pilot distance : les images prises par la camra sont envoyes vers un poste de tlpilotage. Ce dernier affiche lenvironnement du robot sur un cran. Le pilote visualise limage et utilise des commandes pour contrler distance les roues et le moteur du robot. La communication entre le poste de pilotage et le robot se fait via des ondes radio.
Solution
Le systme L t informatique i f est compos de deux sous-systmes : le sous-systme du robot ; le sous-systme du poste de tlpilotage. Do lide de faire deux diagrammes de cas dutilisation un par sous-systme et de placer chaque diagramme dans un paquetage. La figure 1.24 montre deux paquetages : un pour le sous-systme du robot et un pour le sous-systme du poste de pilotage. La relation de dpendance entre les paquetages signifie que le systme de pilotage utilise le robot.
Figure 1.24 Reprsentation du systme de tlpilotage dun robot par des paquetages. Robot Systme de pilotage
Commenons par modliser le robot. Ses capteurs (camra, moteur et roues) sont lextrieur du systme informatique et ils interagissent avec lui. Ils correspondent a priori la dfinition dacteurs. Reprenons chaque capteur pour ltudier en dtail : Le systme doit demander la capture dune image la camra et raliser la capture. La camra est donc un acteur associ un cas dutilisation appel Capturer images (figure 1.25). Le sens de rotation du moteur peut tre command. Le moteur est lacteur ; il est associ un cas appel Commander le moteur .
32
La direction des roues peut tre modifie, do la cration du cas dutilisation
Commander la direction reli lacteur Direction. Pour pouvoir envoyer les images au poste de pilotage et recevoir les commandes en retour, il faut un capteur supplmentaire, metteur/rcepteur dondes radio. Le systme informatique ne va pas se charger denvoyer et de recevoir des ondes radio cest le rle des priphriques dmission et de rception mais il doit soccuper du transcodage des images pour les envoyer via des ondes. Le systme informatique doit-il raliser lui-mme ce transcodage ou bien les fonctions de transcodage sont-elles fournies avec les priphriques ? Pour rpondre cette question, il faudrait raliser une tude de march des metteurs/rcepteurs radio. Cela dpasse le cadre de cet ouvrage. Considrons que le systme informatique intervient, ne serait-ce que pour appeler des fonctions de transcodage. Cela constitue un cas dutilisation. Deux flots dinformations distincts doivent tre envoys au poste de pilotage : des images et des commandes. Cette dernire remarque incite crer deux cas dutilisation : un pour mettre des images ( Envoyer les images ) et un pour recevoir les commandes ( Recevoir les commandes ). En outre, selon lutilisation du robot, la transmission des images seffectue plus ou moins vite : si les dplacements du robot sont rapides par exemple, la transmission doit ltre aussi. Ces contraintes de ralisation font partie des spcifications techniques du systme. Elles doivent figurer dans la description textuelle du cas dutilisation. Sur le diagramme de cas dutilisation, il est possible de placer une relation dextension entre les cas Envoyer les images et Capturer images , en indiquant comme point dextension quel moment de la capture et quelle frquence sont envoyes les images.
Nom de lacteur Rle
Camra Direction Moteur metteur Rcepteur
Permet de capturer des images de lenvironnement du robot. Permet de diriger les roues du robot. Permet de faire avancer ou reculer le robot. Permet denvoyer des ondes radio. Permet de recevoir des ondes radio.
33
Figure 1.25 Diagramme de cas dutilisation du robot.
Systme de contrle dun robot Capturer images Points dextension : envoiImage
Camra Condition : {ds quune image complte a t capture} Point dextension : envoiImage tend Envoyer les images metteur Recevoir les commandes Points dextension : - commandeMoteur - commandeDirection
Rcepteur
Condition : {ds quune commande concerne le moteur} Point dextension : commandeMoteur
Condition : {ds quune commande concerne la direction} Point dextension : commandeDirection tend tend Commander la direction
Commander le moteur
Moteur
Direction
Intressons-nous prsent au sous-systme de pilotage. La figure 1.26 prsente le diagramme de cas dutilisation, qui se dduit sans problme du diagramme prcdent.
Nom de lacteur Rle
Pilote metteur Rcepteur
Reprsente un pilote qui agit sur les commandes distance. Permet denvoyer des ondes radio. Permet de recevoir des ondes radio.
34
Figure 1.26 Diagramme de cas dutilisation du systme de pilotage.
Systme de pilotage dun robot Recevoir des images Points dextension : afficheImage
Rcepteur Condition : {ds quune image complte a t reue} Point dextension : afficheImage
tend Afficher les images
Tlpiloter Points dextension : envoiCommande
Pilote
Condition : {ds quune commande a t manipule par le pilote} Point dextension : envoiCommande
tend Envoyer des commandes
metteur
Exercice 7 : Relations entre acteurs, extensions conditionnelles entre cas dutilisation

Modlisez laide dun diagramme de cas dutilisation une mdiathque dont le fonctionnement est dcrit ci-aprs. Une petite mdiathque na quune seule employe qui assume toutes les tches : la gestion des uvres de la mdiathque ; la gestion des adhrents. Le prt dun exemplaire dune uvre donne est limit trois semaines. Si lexemplaire nest pas rapport dans ce dlai, cela gnre un contentieux. Si lexemplaire nest toujours pas rendu au bout dun an, une procdure judiciaire est dclenche. Laccs au systme informatique est protg par un mot de passe.
Solution
L mdiathque La di th nemploie quune employe. Nanmoins, un acteur est dtermin par le rle quil joue vis--vis du systme modliser. Ici, lemploye a deux rles essentiels :
35
le rle de bibliothcaire qui gre les uvres ainsi que les adhrents ; le rle de gestionnaire des contentieux ayant les connaissances juridiques suffisantes
pour dclencher des procdures judiciaires. Ces rles sont modliss par deux acteurs : Bibliothcaire et Gestionnaire des contentieux. Un gestionnaire de contentieux est un bibliothcaire avec pouvoir. Les acteurs correspondants sont relis par une relation de gnralisation (figure 1.27). Ainsi, lacteur Gestionnaire des contentieux peut utiliser les cas associs lacteur Bibliothcaire. A contrario, lacteur Bibliothcaire ne peut pas utiliser les cas relatifs la gestion des contentieux. Jusqu prsent la mdiathque fonctionne avec une seule employe. Si, lavenir, plusieurs employs devenaient ncessaires, le systme informatique pourrait fonctionner avec deux groupes dutilisateurs : un premier groupe dont le rle serait limit celui des bibliothcaires et un deuxime groupe susceptible de grer les contentieux en plus davoir un rle de bibliothcaire. Lauthentification du groupe auquel appartient un utilisateur du systme doit tre contrle par un mot de passe. La gestion des mots de passe requiert la prsence dun administrateur du systme. Pour UML, peu importe si cette personne fait partie ou non du groupe des bibliothcaires ou des gestionnaires de contentieux. Comme un nouveau rle apparat dans le systme, cela justifie la dfinition dun acteur supplmentaire : Administrateur. Tous les cas dutilisation lis aux acteurs incluent la procdure dauthentification matrialise par le cas Sauthentifier . Dans le diagramme, la gestion des adhrents et la gestion des emprunts sont spares : Grer les adhrents consiste ajouter, supprimer ou modifier lenregistrement dun adhrent dans la mdiathque, tandis que Grer les emprunts consiste prter des exemplaires aux adhrents dj inscrits. La gestion des contentieux a deux degrs dalerte : Un exemplaire na pas t rendu au bout de trois semaines. Un exemplaire na toujours pas t rapport au bout dun an. Cela correspond deux fonctionnalits distinctes puisque, dans le deuxime cas seulement, il faut dclencher une procdure judiciaire. Nous reprsentons cela par deux cas dutilisation : Grer les contentieux et Dclencher une procdure judiciaire . Ces deux cas sont lis par une relation dextension soumise la condition si le retard dpasse un an .
Nom de lacteur Rle
Bibliothcaire Gestionnaire des contentieux Administrateur
Reprsente un bibliothcaire. Il gre les uvres, les adhrents et les emprunts. Reprsente un bibliothcaire qui peut grer les contentieux. Reprsente un gestionnaire des droits daccs au systme.
36
Figure 1.27 Diagramme de cas dutilisation dune mdiathque.
Une mdiathque Grer les uvres inclut Rechercher les uvres inclut Grer les adhrents inclut Sauthentifier Rechercher les adhrents inclut inclut Grer les emprunts Grer les contentieux Grer les comptes utilisateurs Administrateur Points dextension : procdureJudiciaire : {pas chaque fois que le gestionnaire utilise le cas mais une fois par mois} tend Dclencher une procdure judiciaire inclut
Bibliothcaire
inclut
Gestionnaire des contentieux
Condition : {si plus dun an de retard} Point dextension : procdureJudiciaire
Exercice 8 : Identification des acteurs, recensement des cas dutilisation internes et relation de gnralisation entre cas
Modlisez laide dun diagramme de cas dutilisation le systme informatique qui gre la distribution dessence dans une station-service. Le fonctionnement de la distribution de lessence est dcrit ci-aprs. Avant de pouvoir tre utilise par un client, la pompe doit tre arme par le pompiste. La pompe est ainsi apprte, mais ce nest que lorsque le client appuie sur la gchette du pistolet de distribution que lessence est pompe. Si le pistolet est dans son tui de rangement et si la gchette est presse, lessence nest pas pompe. La distribution de lessence un client est termine quand celui-ci remet le pistolet dans son tui. La mesure de lessence distribue se fait par un dbitmtre. Quatre types de carburants sont proposs : diesel, sans plomb avec un indice doctane de 98, sans plomb avec un indice doctane de 95, et plomb. Le paiement peut seffectuer en espces, par chque ou par carte bancaire. En fin de journe, les transactions sont archives. Le niveau des cuves ne doit pas descendre en dessous de 5 % de la capacit maximale. Sinon les pompes ne peuvent plus tre armes.
37
Solution
P Pour un systme t complexe, il vaut mieux se concentrer sur les fonctions essentielles puis passer aux cas moins importants.
Identification des principaux acteurs et recensement des cas dutilisation essentiels

Lacteur principal est videmment le client. Il utilise le systme pour obtenir de lessence. Il est associ au cas dutilisation Se servir . Rappel : dans un diagramme de cas dutilisation, on ne dtaille pas la squence des oprations. Par exemple, le type dessence choisi sera pris en compte quand on dcrira le cas. Imaginons le fonctionnement de la pompe : lessence ne peut tre distribue que si la pompe est arme ; le client prend un pistolet ; sur le pupitre du pompiste est indiqu le type dessence choisi ; le pompiste arme la pompe en appuyant sur un bouton de son pupitre, ce qui initialise la pompe. Ainsi, le cas Se servir doit inclure larmement de la pompe. Deux solutions sont possibles : La premire utilise un cas unique (Se servir), et deux acteurs (Client et Pompiste), comme le montre la figure 1.28.
Figure 1.28 Se servir de lessence : solution avec un cas unique.
Se Servir Client Pompiste
La deuxime solution met en uvre deux cas : Se servir et Armer pompe
(figure 1.29).
Figure 1.29 Se servir de lessence : solution avec deux cas. Client inclut Se Servir Armer pompe Pompiste
38
Larmement de la pompe est indispensable, sinon lessence ne peut tre distribue, do la relation dinclusion entre les cas Se servir et Armer pompe . Larmement de la pompe se fait en une seule action pour le pompiste : celle darmer la pompe en appuyant sur un bouton. La description de larmement se rsume donc une squence trs sommaire dactions. Faut-il alors reprsenter cela par un cas dutilisation ? Largument qui fait pencher pour le maintien du cas Armer pompe est que larmement est une opration bien isole des autres fonctions : il sagit dinitialiser la pompe et donc de piloter des priphriques (mcaniques, lectroniques). Vu sous cet angle, larmement est suffisamment complexe et bien isol des autres fonctions pour en faire un cas (figure 1.31). Le pompiste est un acteur secondaire du cas Armer pompe (cest un cas interne pour lequel le pompiste est consult). Larmement de la pompe nest possible que si le niveau de la cuve est suffisant. Un dtecteur de niveau (priphrique externe au systme informatique) est ncessaire. Ce priphrique est reprsent par lacteur Capteur niveau
cuve pour armement . Il est secondaire car linformation sur le niveau de la cuve ne lui est pas destine. Si le niveau est trop bas, cest le pompiste qui doit en tre inform. Il saura ainsi ce qui empche larmement de la pompe. La vrification du niveau de la cuve est importante pour le systme. De plus, cette opration constitue une transaction bien isole des autres fonctions (il sagit de contrler un priphrique matriel). Cest la raison pour laquelle on dcide de crer un cas Vrifier niveau cuve pour armement . Pour transmettre le niveau de la cuve au pompiste, il faut relier lacteur Pompiste au cas Vrifier niveau cuve pour armement . Le pompiste est inform que le niveau est trop bas, mais la vrification doit tre automatique pour que les pompes soient ventuellement bloques. Une relation dinclusion intervient donc entre les cas Armer pompe et Vrifier niveau cuve pour armement (figure 1.31).
Recensement des cas de moindres importances

Aprs avoir trouv les principaux cas, il est temps de se consacrer ceux de moindre importance. Il ne faut pas oublier de couvrir tous les besoins et ne pas hsiter introduire des cas auxquels le matre douvrage na pas pens. Il validera ou pas le modle a posteriori. Lnonc naborde pas le problme du remplissage des cuves dessence. Cette opration est ralise par une entreprise tierce de livraison dessence. Elle doit cependant tre consigne dans le systme informatique de la station-service. Une solution consiste alerter le pompiste ds que le niveau des cuves descend au-dessous dun certain seuil. Ce deuxime seuil, appel seuil de remplissage des cuves , doit tre suprieur au seuil des 5 % de lnonc (celui qui empche les pompes dtre armes). Quand il est atteint, le pompiste prvient lentreprise de livraison dessence de sorte viter de tomber au seuil des 5 %. Si la station-service est sur une autoroute, la livraison dessence doit tre garantie 24 heures sur 24. Il faut peut-tre contacter la socit de livraison automatiquement sans passer par lintermdiaire du pompiste ds que le niveau devient trop bas. Le capteur du niveau de remplissage est reprsent par un acteur appel Capteur niveau cuve pour remplissage (figure 1.31). Il est associ au cas Vrifier niveau cuve pour remplissage , lui-mme associ lacteur Pompiste. Abordons prsent le problme du paiement. De concert avec le matre douvrage, le matre duvre imagine un fonctionnement possible du systme : ds que le client raccroche le pistolet, le montant payer est calcul ; il saffiche sur le pupitre du pompiste ; le client qui vient payer indique son mode de paiement (espces, chque ou carte bancaire) ; le pompiste slectionne le mode de paiement choisi. partir de l, les cas divergent : Pour un paiement en espces, le pompiste encaisse le montant demand, puis valide la transaction, qui est mmorise dans le systme informatique (le montant, la date de la transaction et le mode de paiement sont conservs). Si le paiement se fait par chque, ce dernier est rempli automatiquement, puis le pompiste lencaisse. La transaction est mmorise dans le systme informatique (en plus de la date, du montant et du mode paiement, sont conservs les rfrences dune pice didentit ou le numro dimmatriculation du vhicule). Pour un paiement par carte bancaire, la banque de la station-service ralise une transaction avec la banque du client. Les seules informations conserver dans le systme
39
informatique de la station-service sont le montant, la date de la transaction et le mode de paiement. Comment reprsenter cela dans un diagramme de cas dutilisation ? Une premire solution (prsente la figure 1.31) consiste crer un cas gnral appel Payer , et trois cas particuliers relis par une relation de spcialisation au cas Payer . Chacun des trois cas reprsente un mode de paiement. Une autre solution (prsente la figure 1.30) repose sur un cas, Payer , qui se droule jusquau choix du mode de paiement, puis, selon le type de paiement, un des trois modes est activ ( Payer en espces , Payer par chque ou Payer par carte bancaire ). Ces trois cas sont typiquement des extensions du cas Payer , o lextension est soumise condition.
Figure 1.30 Utilisation de relations dextension pour modliser le paiement.
Payer Points dextension : - paiementEspce, - paiementParChque - paiementParCarteBancaire {les trois extensions sexcluent mutuellement et une extension intervient au tout dbut du paiement} Condition : {si le client choisit de payer en espce} Point dextension : paiementEnEspce
Condition : {si le client choisit de payer par carte bancaire} Point dextension : paiementParCarteBancaire tend tend tend
Payer par carte bancaire
Payer en espces
Condition : {si le client choisit de payer par chque} Point dextension : paiementParChque
Payer par chque
Ces deux solutions sont possibles. Il est difficile de dire laquelle est la meilleure. La suite de lexercice se fonde arbitrairement sur la reprsentation avec des relations de gnralisation (figure 1.31). Le modlisateur se retrouve rgulirement face ce dilemme. La rponse est souvent la mme : peu importe la faon de modliser un systme du moment que le modle est correct un modle est correct sil montre une solution qui satisfait le matre douvrage ainsi que les futurs utilisateurs du systme.
Aboutir une modlisation correcte

Il faut prendre le temps dlaborer le diagramme de cas dutilisation, bien quil soit gnralement simple btir, afin dviter les a priori qui peuvent conduire une modlisation errone. la relecture du fonctionnement du paiement tel quil est dcrit prcdemment, le pompiste devient lacteur principal du cas de paiement. Cest un peu surprenant car on pourrait croire au premier abord quil sagit du client. Or, la seule fois o le client intervient directement sur le systme informatique de la station-service est quand il saisit son numro de carte bancaire. Toutes les autres situations ncessite lintervention du
40
pompiste. Attardons-nous un instant encore sur le paiement par carte bancaire. Il faut de toute vidence faire figurer un acteur supplmentaire qui reprsente la banque, car elle interagit avec le systme sans en faire partie. Cest un acteur secondaire qui est sollicit uniquement pour confirmer le bon droulement de la transaction. Quel est le rle de cet acteur ? Le plus souvent, les solutions de paiement par carte bancaire sont disponibles cls en main sur le march. Elles incluent un lecteur de cartes ainsi quun logiciel pour le piloter. Le matre duvre doit proposer plusieurs solutions prsentes sur le march au matre douvrage, et ventuellement une solution propritaire si aucune solution du march ne lui convient. Le matre douvrage dcidera. Dans le cadre de cet exercice, dfaut de pouvoir dialoguer avec un matre douvrage, nous choisissons lachat dune solution cls en main pour le paiement par carte bancaire. Dans ce cas, le client, lorsquil saisit le code de sa carte, ninteragit plus directement avec le systme informatique de la station-service. Ainsi, quel que soit le mode de paiement, tout passe par lintermdiaire du pompiste. Le client nest donc pas un acteur du systme. Le calcul automatique du montant payer peut se faire ds que le client raccroche le pistolet (ce qui intervient la fin du cas Se servir ). Pour indiquer le moment o le montant est calcul, on peut ajouter une relation dextension entre les cas Se servir et Payer , avec un point dextension qui prcise le moment o le calcul du montant intervient, comme le montre la figure 1.31. Le paiement peut aussi intervenir avant de se servir. Dans ce cas, il est possible dajouter un deuxime point dextension.
Modlisation des concepts abstraits

Parfois, le langage UML peut paratre limit. Il faut alors trouver, parmi les lments du langage, celui qui convient le mieux une situation donne. Un dernier besoin nest pas dcrit par le diagramme de cas dutilisation : cest larchivage en fin de journe des transactions. Faut-il prendre en compte ce cas et, si oui, quel acteur lutilise ? Un cas dutilisation est dclench par un vnement. Les vnements peuvent tre classs en trois catgories : Les vnements externes. Ils sont dclenchs par des acteurs. Les vnements temporels. Ils rsultent de latteinte dun moment dans le temps. Les vnements dtats. Ils se produisent quand quelque chose dans le systme ncessite un traitement. Ici, il sagit dun vnement temporel. Il est difficile de dfinir un acteur qui dclencherait cet vnement. Comment le temps peut-il interagir avec un systme ? Cela dit, larchivage quotidien est une fonctionnalit essentielle. Il faut la faire figurer dans la modlisation du systme. quelle tape de la modlisation doit-on prendre en compte cette fonctionnalit ? Comme nous en sommes produire le premier modle du systme et que cette fonctionnalit est importante, nous choisissons, pour ne pas loublier, den faire un cas dutilisation. Pour dclencher ce cas, nous introduisons un acteur appel Timer qui, une fois par jour, dclenche un vnement temporel. Timer est un acteur, il est donc en dehors du systme. Cela signifie que lheure est donne par une horloge externe notre systme informatique (par exemple, lhorloge du systme dexploitation du systme informatique). La prise en compte des vnements dtats est plus dlicate puisque, par dfinition, ils se produisent lintrieur dun systme. Ils ne peuvent donc pas tre dclenchs par un
41
acteur, qui est forcment en dehors du systme. Il est toutefois possible quun vnement dtat active un cas dutilisation condition que ce cas soit interne au systme. Une faon de reprsenter un cas de ce type consiste le relier dautres cas via des relations dextension et faire figurer comme condition dextension lvnement dtat. Cest cette solution qui a t adopte entre les cas Se servir et Payer , en considrant ce dernier comme un cas interne vis--vis du cas Se servir .
Nom de lacteur Rle
Client Pompiste Capteur niveau cuve pour armement Capteur niveau cuve pour remplissage Timer Banque
Acteur principal du cas dutilisation Se servir . Reprsente le client qui se sert de lessence. Acteur principal des cas Payer et Vrier niveau cuve pour remplissage . Acteur secondaire pour le cas Armer pompe . Acteur secondaire du cas Vrier niveau cuve pour armement . Acteur secondaire du cas Vrier niveau cuve pour remplissage . Acteur secondaire du cas Archiver les transactions . Acteur secondaire du cas Payer par carte bancaire .
42
Figure 1.31 Diagramme de cas dutilisation dune station-service.
Capteur niveau cuve pour armement
Capteur niveau cuve pour remplissage
Station-Service Vrifier niveau cuve pour armement Vrifier niveau cuve pour remplissage
inclut Se servir inclut Armer pompe Pompiste
Client
Points dextension : paiement : { la fin du cas se servir } tend Payer
Condition : {si le client a pris de lessence avant de raccrocher le pistolet}
Payer par carte bancaire Banque Payer par chque
Payer en espce Archiver les transactions
Tous les soirs minuit Timer
43

7466 Chap01

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

7466 Chap01

Transféré par

Droits d'auteur :

Formats disponibles

1 e r t i p a h C c

Diagramme de cas dutilisation

1. Limportance L de bien recueillir les l besoins

2. Le L diagramme de cas dutilisation d

Figure 1.2 et 1.3 Reprsentations dun cas dutilisation.

strotype Nom du cas Liste de proprits

Nom du cas Liste de proprits

Chapitre 1 Diagramme de cas dutilisation

Figure 1.4 Autre reprsentation dun acteur.

Rle de lacteur acteur Nom de lacteur

Le rectangle de la figure 1.5 est appel classeur .

2.2. Relations entre acteurs et cas dutilisation

2.3. Relations entre cas dutilisation

Chapitre 1 Diagramme de cas dutilisation

Borne interactive dune banque

Effectuer un virement Point dextension : vrificationSolde {aprs avoir demand le montant}

Consulter sur Internet

Figure 1.9 Relations entre cas pour dcomposer un cas complexe.

2.4. Relations entre acteurs

Passer une commande

Suivre une commande Prpos aux commandes

Grer le stock Directeur des ventes

Chapitre 1 Diagramme de cas dutilisation

2.5. Regroupement des cas dutilisation en paquetages

3. M Modlisation des besoins avec a UML

3.2. Comment recenser les cas dutilisation ?

Chapitre 1 Diagramme de cas dutilisation

3.3. Description des cas dutilisation

Les diffrentes faons de dcrire les cas dutilisation

Chapitre 1 Diagramme de cas dutilisation

Description textuelle des cas dutilisation

Description dun retrait dargent

Chapitre 1 Diagramme de cas dutilisation

Exercice 1 : Identification des acteurs et recensement de cas dutilisation simples

Grer la station Chef datelier

Exercice 2 : Relations entre cas dutilisation

Appuyer sur la gchette

Exercice 3 : Relations entre cas dutilisation cas internes

Organiser un voyage Agent de voyages

inclut Organiser un voyage

Rserver un billet de train

Organiser un voyage Agent de voyages Points dextension : tablirUneFacture

Condition : { la demande du client} Point dextension : tablirUneFacture

tablir une facture dtaille

Figure 1.21 Relation de gnralisation entre cas dutilisation.

inclut Organiser un voyage

Points dextension : tablirUneFacture

Condition : { la demande du client} Point dextension : tablirUneFacture

Rserver un billet de train tend

Rserver un billet davion

tablir une facture dtaille

Emprunter une vido

Restituer une vido

Reprsente un client du magasin de location de cassettes vido.

Emprunter une vido

inclut Rechercher une vido

Restituer une vido

Exercice 5 : Description dun cas dutilisation

Description du cas Emprunter une vido

Description du cas Emprunter une vido (suite)

Enchanements dexception E1 : La carte introduite nest pas valide.

E2 : La cassette nest pas prise par le client.

E3 : La carte nest pas reprise par le client.