uml conception

Upload: gley-ben-daoud

Post on 16-Jul-2015

4.497 views

Category:

Documents


27 download

TRANSCRIPT

Informatique

Synthse de cours exercices corrigs

&

UML 2Pratique de la modlisation2e ditionLes principaux diagrammes dUML Une quarantaine dapplications corriges et une tude de cas complte Un comparatif des logiciels de modlisation

collection

Synthex

Benot CHARROUX Aomar OSMANI Yann THIERRY-MIEG

Informatique

Synthse de cours

&

exercices corrigs

UML 22e ditionBenot CharrouxEFREI (cole dingnieur)

Aomar Osmaniuniversit Paris XIII

Yann Thierry-Mieguniversit Paris VI

Synthex

collection

ISBN : 978-2-7440-4050-4 ISSN : 1768-7616 Copyright 2009 Pearson Education FranceTous droits rservs Composition sous FrameMaker : TyPAO Aucune reprsentation ou reproduction, mme partielle, autre que celles prvues larticle L. 122-5 2 et 3 a) du code de la proprit intellectuelle ne peut tre faite sans lautorisation expresse de Pearson Education France ou, le cas chant, sans le respect des modalits prvues larticle L. 122-10 dudit code.

SommaireLes auteurs Introduction V VII 1 35 85 127 155 187 233 237 238 240 241 247 252 253

Chapitre 1 Diagramme de cas dutilisation Chapitre 2 Diagramme de classes Chapitre 3 Diagramme dinteraction Chapitre 4 Diagramme dtats-transitions Chapitre 5 Diagramme dactivits Chapitre 6 UML en pratique Annexe A Comparatif des outils de modlisation Annexe B Classeurs structurs

Annexe C Composants Annexe D Diagramme de dploiement Annexe E Annexe F Implmentation dun modle objet en Java Organisation dUML 2

Annexe G BibliographieIndex

Sommaire III

Les auteursBenot Charroux est docteur en informatique. Aprs avoir men des travaux de recherche en traitement dimages, il se consacre maintenant exclusivement la formation. Ayant dirig le dpartement informatique de lESIGETEL, il gre prsent les enseignements de linformatique lEFREI (cole dIngnieurs des Technologies de lInformation et du Management). Il enseigne les technologies orientes objet (UML, Java, C++, EJB) dans de nombreux tablissements : coles dingnieurs, universits, et entreprises. Aomar Osmani est docteur en informatique et matre de confrences luniversit Paris XIII. Il mne des travaux de recherche en diagnostic de systmes dynamiques, en raisonnement temporel et en apprentissage articiel. Ces activits denseignement portent sur la plupart des domaines de linformatique (architecture des ordinateurs, rseaux, systmes, bases de donnes). Il a principalement enseign ces dernires annes les technologies orientes objet et le gnie logiciel, et a particip, linstitut universitaire de technologie de Paris XIII, la cration et la direction de groupes de licence professionnelle. Yann Thierry-Mieg est docteur en informatique et matre de confrences. Ses problmatiques de recherche sont centres sur la modlisation et la vrication formelle de systmes informatiques, plus particulirement rpartis, en vue de fournir des outils pour vrier de manire automatique le comportement dun systme partir de son modle. Il enseigne Paris VI ainsi qu lEFREI les systmes dinformation, les technologies orientes objet et les mthodologies de dveloppement.

Les auteurs V

IntroductionLapproche objet est incontournable dans le cadre du dveloppement de systmes logiciels complexes, capables de suivre les volutions incessantes des technologies et des besoins applicatifs. Cependant, la programmation objet est moins intuitive que la programmation fonctionnelle. En effet, il est plus naturel de dcomposer les problmes informatiques en termes de fonctions quen termes densembles dobjets en interaction. De ce fait, lapproche objet requiert de modliser avant de concevoir. La modlisation apporte une grande rigueur, offre une meilleure comprhension des logiciels, et facilite la comparaison des solutions de conception avant leur dveloppement. Cette dmarche se fonde sur des langages de modlisation, qui permettent de saffranchir des contraintes des langages dimplmentation. Le besoin dune mthode de description et de dveloppement de systmes, prenant en compte la fois les donnes et les traitements, a grandi en mme temps que la taille des applications objet. Au milieu des annes 90, plusieurs dizaines de mthodes objet sont disponibles, mais aucune ne prdomine. Lunication et la normalisation des trois mthodes dominantes, savoir Booch, du nom de son auteur, OOSE (Object Oriented Software Engineering), dIvan Jacobson et OMT (Object Modeling Technique), de James Rumbaugh, sont lorigine de la cration du langage UML (Unied Modeling Language). UML est une notation graphique conue pour reprsenter, spcier, construire et documenter les systmes logiciels. Ses deux principaux objectifs sont la modlisation de systmes utilisant les techniques orientes objet, depuis la conception jusqu la maintenance, et la cration dun langage abstrait comprhensible par lhomme et interprtable par les machines. UML sadresse toutes les personnes charges de la production, du dploiement et du suivi de logiciels (analystes, dveloppeurs, chefs de projets, architectes), mais peut galement servir la communication avec les clients et les utilisateurs du logiciel. Il sadapte tous les domaines dapplication et tous les supports. Il permet de construire plusieurs modles dun systme, chacun mettant en valeur des aspects diffrents : fonctionnels, statiques, dynamiques et organisationnels. UML est devenu un langage incontournable dans les projets de dveloppement. Une mthode de dveloppement dnit la fois un langage de modlisation et la marche suivre lors de la conception. Le langage UML propose uniquement une notation dont linterprtation est dnie par un standard, mais pas une mthodologie complte. Plusieurs processus de dveloppement complets fonds sur UML existent, comme le Rational Unied Process (RUP), de Booch, Jacobson et Rumbaugh, ou lapproche MDA (Model Driven Architecture) propose par lOMG, mais ils ne font pas partie du standard UML.

Introduction VII

Le processus RUP propose de bien matriser les tapes successives de la modlisation et du dveloppement par une approche itrative. Lapproche MDA propose une architecture du dveloppement en deux couches : le PIM (Platform Indepent Model) reprsente une vision abstraite du systme, indpendante de limplmentation ; le PSM (Platform Specic Model) reprsente les programmes excutables, qui doivent tre obtenus en partie automatiquement partir du PIM ; cela sajoute le PDM (Platform Denition Model), en loccurrence une description de larchitecture physique voulue (langages de programmation, architecture matrielle). UML intgre de nombreux concepts permettant la gnration de programmes. Cest un langage de modlisation fond sur des vnements ou des messages. Il ne convient pas pour la modlisation de processus continus, comme la plupart des procds en physique. Ce nest pas un langage formel, ni un langage de programmation. Il ne peut pas tre utilis pour valider un systme, ni pour gnrer un programme excutable complet. Mais, il permet de produire des parties de code, comme le squelette des classes (attributs et signatures de mthode). Mme si la version 2 apporte des avances signicatives au niveau du formalisme, UML na pas encore atteint la rigueur syntaxique et smantique des langages de programmation. UML est le rsultat dun large consensus, continuellement enrichi par les avances en matire de modlisation de systmes et de dveloppement de logiciels. Cest le rsultat dun travail dexperts reconnus, issus du terrain. Il couvre toutes les phases du cycle de vie de dveloppement dun systme et se veut indpendant des langages dimplmentation et des domaines dapplication.

Historique du langage UML la n des annes 80, lindustrie commence utiliser massivement les langages de programmation orients objet, tels que C++, Objective C, Eiffel et Smalltalk. De lindustrialisation de ce type de programmation est n le besoin de penser objet , indpendamment du langage dimplmentation. Plusieurs quipes proposent alors des mthodes (OMT, OOSE, Booch, Coad, Odell, CASE) qui, pour la plupart, modlisent les mmes concepts fondamentaux dans diffrents langages, avec une terminologie, des notations et des dnitions diffrentes. Les diffrents protagonistes conviennent rapidement du besoin dunier ces langages en un standard unique. Lors de la confrence OOPSLA doctobre 1995, Booch et Rumbaugh prsentent la version 0.8 de leur mthode unie (Unied Method 0.8). Ils sont rejoints la mme anne par Jacobson. Les trois auteurs amliorent la mthode unie et proposent en 1996 la version 0.9 du langage UML. Rational Software, qui emploie dsormais le trio, publie en 1997 la documentation de la version 1.0 dUML et la propose lOMG en vue dune standardisation. Des modications sont apportes la version propose par Rational, puis lOMG propose, la mme anne, la version UML 1.1, qui devient un standard. LOMG constitue ensuite un groupe de rvision nomm RTF (Revision Task Force). Entretemps, de trs nombreux utilisateurs industriels adoptent UML et apportent quelques modications, ce qui conduit la proposition de la version 1.2 en 1999. La premire rvision signicative du langage est la version 1.3, propose en 1999, dont la spcication complte est publie en mars 2000. En mars 2003, la version 1.5 voit le jour. Concrtement, UML 1 est utilis lors de la phase danalyse et de conception prliminaire des systmes. Il sert spcier les fonctionnalits attendues du systme (diagrammes de cas dutilisation et de squence) et dcrire larchitecture (diagramme de classes). La description de la partie comportementale (diagrammes dactivits et dtats) est moins utilise. Cela est d essentiellement linsufsance de la formalisation de la conception dtaille dans UML 1. La plupart du temps, en matire de spcication des algorithmes et des mthodes de traitement, le seul moyen est de donner une description textuelle informelle.

VIII

UML 2

Certes, des outils comme les automates et les diagrammes dactivits sont disponibles, mais leur emploi est limit. Les utilisateurs restent sur le vieux paradigme centr sur le code : ils se contentent de recourir UML lors des phases prliminaires et passent un langage de programmation classique lors des phases de codage et de tests. Lun des objectifs de lOMG est de proposer un paradigme guid par des modles dcrivant la fois le codage, la gestion de la qualit, les tests et vrications, et la production de la documentation. Il sagit de recentrer lactivit des informaticiens sur les fonctions que le systme doit fournir, en conformit avec les exigences du client et les standards en vigueur.

Objectif du livreLobjectif de cet ouvrage est de fournir une rfrence concise des concepts de base dUML, illustre par de nombreux exemples. Nous adoptons le point de vue pragmatique des utilisateurs du langage. Il permet de comprendre limportance de la modlisation et lintrt demployer une notation graphique. Selon le principe de cette collection, chaque chapitre commence par une synthse de cours prsentant les concepts de base du langage, avec leur syntaxe prcise, et illustre de nombreux exemples, remarques pratiques et commentaires. Vient ensuite une srie dexercices. Ce livre donne la vue utilisateur des concepts de la notation UML : ils sont dcrits avec prcision dans la norme par un mtamodle, mais cet aspect un peu complexe nest pas dtaill dans cet ouvrage. Le langage UML ne sappuie pas sur un processus dcrivant les tapes du dveloppement. Cependant, il est bien adapt aux processus itratifs guids par les besoins des utilisateurs et axs sur larchitecture. Les exemples et les exercices corrigs, prsents au l des chapitres, donnent des indications sur les approches suivre pour laborer un modle dune situation donne. Le problme difcile et rcurrent de lenchanement des modles est trait dans une tude de cas prsente au chapitre 6.

Structure du livreLe livre est compos de chapitres qui peuvent tre lus sparment. Cependant, le plan respecte toujours la mme dmarche dont la premire tape correspond une prsentation du point de vue fonctionnel. Lanalyse fonctionnelle permet de mettre au point une reprsentation graphique, compacte et complte des besoins, appele diagramme de cas dutilisation . Les cas sont ventuellement dcrits textuellement an de spcier les diffrents scnarios attendus du systme. Vient ensuite la partie analyse statique , dans laquelle on spcie les classes et les relations entre classes (diagramme de classes). Des cas particuliers ou explicatifs sont aussi prsents par des diagrammes dobjets. Une fois que les diffrents objets sont dnis (diagramme de classes), on revient sur lanalyse fonctionnelle dans laquelle on spcie les interactions entre les diffrents objets du systme. On peut tre intress par les changes dans le temps (diagramme de squence) ou encore par les collaborations existantes entre les objets (diagramme de communication). La description de la partie dynamique du systme est prsente par les diagrammes dtats et les diagrammes dactivits. Chaque chapitre est divis en deux parties : le rappel de cours puis les exercices corrigs, qui occupent une part importante de louvrage. Ils illustrent via des exemples simples les concepts prsents dans le rappel de cours et expliquent comment utiliser UML dans des situations pratiques. Ils donnent quelques indications sur la manire de modliser (ce qui ne fait pas partie de la description du langage). travers une application concrte, le chapitre 6 introduit le diagramme de composants, qui permet une organisation statique du systme, et prsente une mthodologie complte intgrant la plupart des concepts prsents dans les chapitres prcdents.

Introduction IX

PrrequisSi cet ouvrage peut tre abord par toute personne ayant une certaine culture informatique, certains passages ncessitent la connaissance des notions minimales de programmation objet. De nombreux concepts dUML (classes, hritage, encapsulation) sont directement proposs par les langages de programmation orients objet, comme le C++ ou Java. Certains exemples sont donc compars ces langages, et supposent donc une exprience minimale de la programmation oriente objet. Les ouvrages sur le C++ et Java 5, publis dans la mme collection, sont de bonnes rfrences en la matire.

Pourquoi modliser ?Un modle est une reprsentation simplie dune ralit. Il permet de capturer des aspects pertinents pour rpondre un objectif dni a priori. Par exemple, un astronaute modlisera la Lune comme un corps cleste ayant une certaine masse et se trouvant une certaine distance de la Terre, alors quun pote la modlisera comme une dame avec laquelle il peut avoir une conversation. Le modle sexprime sous une forme simple et pratique pour le travail [Rumbaugh2004]. Quand le modle devient compliqu, il est souhaitable de le dcomposer en plusieurs modles simples et manipulables. Lexpression dun modle se fait dans un langage compatible avec le systme modlis et les objectifs attendus. Ainsi, le physicien qui modlise la lune utilisera les mathmatiques comme langage de modlisation. Dans le cas du logiciel, lun des langages utiliss pour la modlisation est le langage UML. Il possde une smantique propre et une syntaxe compose de graphique et de texte et peut prendre plusieurs formes (diagrammes). Les modles ont diffrents usages : Ils servent circonscrire des systmes complexes pour les dominer. Par exemple, il est inimaginable de construire une fuse sans passer par une modlisation permettant de tester les racteurs, les procdures de scurit, ltanchit de lensemble, etc. Ils optimisent lorganisation des systmes. La modlisation da la structure dune entreprise en divisions, dpartements, services, etc. permet davoir une vision simplie du systme et par l mme den assurer une meilleure gestion Ils permettent de se focaliser sur des aspects spciques dun systme sans sembarrasser des donnes non pertinentes. Si lon sintresse la structure dun systme an de factoriser ses composants, il est inutile de sencombrer de ses aspects dynamiques. En utilisant, par exemple, le langage UML, on sintressera la description statique (via le diagramme de classes) sans se soucier des autres vues. Ils permettent de dcrire avec prcision et compltude les besoins sans forcment connatre les dtails du systme. Ils facilitent la conception dun systme, avec notamment la ralisation de maquette approximative, chelle rduite, etc. Ils permettent de tester une multitude de solutions moindre cot et dans des dlais rduits et de slectionner celle qui rsout les problmes poss. La modlisation objet produit des modles discrets permettant de regrouper un ensemble de congurations possibles du systme et pouvant tre implments dans un langage de programmation objet. La modlisation objet prsente de nombreux avantages travers un ensemble de proprits (classe, encapsulation, hritage et abstraction, paquetage, modularit, extensibilit, adaptabilit, rutilisation) qui lui confre toute sa puissance et son intrt.

X

UML 2

UML 2UML 2 apporte des volutions majeures par rapport UML 1.5, sans toutefois tre rvolutionnaire : les principales fonctionnalits de base se ressemblent. Au niveau du mtamodle, qui concerne surtout les dveloppements doutils, UML 2 se rapproche davantage des standards de modlisation objet proposs par lOMG. En particulier, lunication du noyau UML et des parties conceptuelles de modlisation MOF (Meta-Object Facility) permet aux outils MOF de grer les modles UML ; lajout du principe de prols permet de mieux dnir les extensions du domaine ; enn, la rorganisation du mtamodle UML limine les redondances prsentes dans les versions prcdentes (voir la n de louvrage pour plus de dtails concernant la structuration du langage UML). Du point de vue de lutilisateur, les changements concernent certaines notations. La notation des diagrammes de squence se rapproche de la norme dchanges de messages MSC (Message Sequence Chart) de lIUT (Union Internationale des Tlcommunications). Le concept de classeurs sinspire des avances de lingnierie temps rel du langage de description et de spcication SDL. De plus, UML 2 unie la modlisation des activits et la modlisation des actions introduites dans UML 1.5 et utilise des notations de modlisation de processus mtier. Des lments de modlisation contextuels amliorent la souplesse et formalisent mieux le concept dencapsulation des classes et des collaborations. An de formaliser le modle utilisateur du langage et de le rapprocher davantage des normes OMG, le langage UML est structur en quatre couches (gure 0.1) ; seules les deux couches user model et run time instance sont destines lutilisateur.

Figure 0.1Organisation en quatre couches du langage UML.

Lutilisateur na pas besoin de mettre en vidence cette organisation quand il utilise UML. Il doit se contenter de respecter la syntaxe et la smantique du langage dtailles dans ce livre. Il doit galement connatre les diffrents diagrammes mettant en valeur tantt des aspects statiques, tantt des aspects comportementaux du systme. Une organisation conceptuelle des diffrents diagrammes UML permet davoir une vision plus claire des vues offertes par ce langage. Les trois auteurs lorigine du langage UML proposent un dcoupage conceptuel en quatre domaines : structurel, dynamique, physique et gestion de modles (voir la n de louvrage pour plus de dtails).

Introduction XI

Chapitre

Diagramme de cas dutilisation1. Limportance de bien recueillir les besoins ................................ 2 2. Le diagramme de cas dutilisation 2 3. Modlisation des besoins avec UML ................................ 9 Problmes et exercices 1. Identification des acteurs et recensement de cas dutilisation simples .................................... 2. Relations entre cas dutilisation.... 3. Relations entre cas dutilisation cas internes ........................... 4. Identification des acteurs, recensement des cas dutilisation et relations simples entre cas...... 5. Description dun cas dutilisation 6. Relations dextension entre cas dutilisation, regroupement de cas dutilisation en paquetages .. 7. Relations entre acteurs, extensions conditionnelles entre cas dutilisation ................ 8. Identification des acteurs, recensement des cas dutilisation internes et relation de gnralisation entre cas.......................

1

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

16 18 18

(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.

20 22

25

27

29

1

(1)

Limportance de bien recueillir les besoinsLe 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 : dnir 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 an 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 dnir ce que doit faire le systme ?

(2)

Le diagramme de cas dutilisationCAS DUTILISATIONParlons 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 sufsamment 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 moyen simple dexprimer leurs besoins. Cest prcisment le rle des diagrammes de cas dutilisation. Ils permettent de recenser les grandes fonctionnalits dun systme.

2.1 LES

EXEMPLE

La gure 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.

2

UML 2

Chapitre

Figure 1.1Diagramme de cas dutilisation modlisant une borne daccs une banque.

frontire du sujet

Borne interactive dune banque

nom du sujet cas dutilisation

1

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.

DnitionUn cas dutilisation est une manire spcique 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 n, pour lacteur qui linitie.

Notation et spcicationUn cas dutilisation se reprsente par une ellipse (gure 1.2). Le nom du cas est inclus dans lellipse ou bien il gure dessous. Un strotype (voir la dnition 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 (gure 1.3). Un acteur se reprsente par un petit bonhomme ayant son nom inscrit dessous (gure 1.1) ou par un rectangle contenant le strotype acteur avec son nom juste en dessous (gure 1.4). Il est recommand dajouter un commentaire sur lacteur pour prciser son rle.

Figures 1.2 et 1.3Reprsentations dun cas dutilisation.

strotype Nom du cas Liste de proprits

Nom du cas Liste de proprits

Figure 1.4Autre reprsentation dun acteur.

Rle de lacteur acteur Nom de lacteur

Diagramme de cas dutilisation 3

La gure 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.

DnitionUn 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 gure 1.5 montre comment un tel rectangle peut remplacer tous les cas dutilisation de la gure 1.1.

Figure 1.5Reprsentation des cas dutilisation un niveau dabstraction lev.

Borne interactive dune banque

Le rectangle de la gure 1.5 est appel classeur .

DnitionUn 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 par ties dun systme, etc.

NotationUn classeur se reprsente par un rectangle contenant ventuellement des compar timents (la gure 1.6 montre comment il est possible de faire gurer explicitement des cas dutilisation dans un classeur).

Figure 1.6Les compartiments dun classeur.

Borne interactive dune banque

Retirer argent

Effectuer un virement

Consulter comptes

4

UML 2

Chapitre

2.2 RELATIONS

ENTRE ACTEURS ET CAS DUTILISATION

1

Un acteur peut utiliser plusieurs fois le mme cas dutilisation.EXEMPLELa gure 1.7 montre un internaute qui tlcharge plusieurs morceaux de musique sur Internet.Logiciel de tlchargement Tlcharger une musique

Figure 1.7Association avec multiplicit.* Internaute

Le symbole * qui signie 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 signie 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 clarier 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 dauthentication avec un mot de passe (gure 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 gure 1.8 prsente lexemple dune banque o la vrication 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 gure 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 gure 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.

Diagramme de cas dutilisation 5

Notation et spcicationUne dpendance se reprsente par une che pointille. Un strotype est souvent ajout au-dessus du trait. Le strotype inclut indique que la relation de dpendance est une inclusion (gures 1.8 et 1.9). Le strotype tend indique une extension (gure 1.8). Lextension peut intervenir un point prcis du cas tendu ; ce point sappelle le point dextension ; il porte un nom, qui gure dans un compartiment du cas tendu sous la rubrique point dextension , et est ventuellement associ une contrainte indiquant le moment o lextension inter vient. Une extension est souvent soumise une condition (indique dans une note attache la che pointille). Le symbole utilis pour la gnralisation est une che en traits pleins dont la pointe est un triangle ferm. La che pointe vers le cas le plus gnral (gure 1.8).

Figure 1.8Relations entre cas dans un diagramme de cas dutilisation.Retirer argent

Borne interactive dune banque

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.9Relations 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

Un cas reli un autre cas peut ne pas tre directement accessible un acteur (gure 1.9). Un tel cas est appel cas interne .

6

UML 2

Chapitre

DnitionUn cas dutilisation est dit interne sil nest pas reli directement un acteur.

1

Les relations entre cas ne sont pas obligatoires. Elles permettent de clarier et denrichir les cas dutilisation. Par exemple, la gure 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 gurer 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.

RemarqueAttention lorientation des ches : si le cas A inclut B on trace la che de A vers B, mais si B tend A, la che 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).EXEMPLELa gure 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.Systme de vente par correspondance

Figure 1.10Relations entre acteurs.

Passer une commande

inclut

Suivre une commande Prpos aux commandes

inclut

Rechercher article

inclut

Grer le stock Directeur des ventes

Diagramme de cas dutilisation 7

NotationLe symbole utilis pour la gnralisation entre acteurs est une che en traits pleins dont la pointe est un triangle ferm. La che pointe vers lacteur le plus gnral.

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.

DnitionUn paquetage permet dorganiser des lments de modlisation en groupe. Un paquetage peut contenir des classes, des cas dutilisations, des interfaces, etc.

EXEMPLE

la gure 1.11, trois paquetages ont t crs : Client, Stock et Suppor t. Ces paquetages contiennent les cas dutilisation du diagramme de la gure 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.Dpendance entre paquetages qui reflte linclusion des cas dutilisation. Support

Figure 1.11Regroupement des cas dutilisation en paquetage.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.

8

UML 2

Chapitre

(3)

Modlisation des besoins avec UMLSONT LES ACTEURS

1

3.1 QUI

? 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 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 difciles 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 vrie le solde du compte est un acteur secondaire. En gnral, lacteur principal initie le cas dutilisation par ses sollicitations.

DnitionLacteur est dit principal pour un cas dutilisation lorsque le cas dutilisation rend ser vice 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).

Diagramme de cas dutilisation 9

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.

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 difciles 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 afns lors de lcriture des spcications on parle de spcications techniques des besoins (voir la section Description textuelle des cas dutilisation ).

RemarqueIl 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 impor tant, il faut se demander si on a fait preuve de sufsamment 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 vrication 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.EXEMPLELexemple de la gure 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 spcication. Spcier un produit, cest le dcrire de la faon la plus prcise possible.

10

UML 2

Chapitre

Figure 1.12Diagramme de cas dutilisation pour une banque.Guichetier

Gestion dune banque Retirer argent

1

Consulter compte

Systme central

Les spcications peuvent tre divises en deux catgories selon quelles sont fonctionnelles ou techniques. Les spcications fonctionnelles concernent les fonctions du systme, la fonction de retrait dargent par exemple, tandis que les spcications 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 spcications 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 gure 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.13Description 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

Diagramme de cas dutilisation 11

Les diffrentes faons de dcrire les cas dutilisationUML 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 sufrait pas.

RemarqueUne 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.

Description textuelle des cas dutilisationBien 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 didentier 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). Signier 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 suft 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).

12

UML 2

Chapitre

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 vrier la validit du compte est interrompue.

1

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 spcications non fonctionnelles (ce sont le plus souvent des spcications 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 dargentIdentication 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 notie 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. Condentialit : 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.

Diagramme de cas dutilisation 13

La squence nominale, les squences alternatives, les exceptions, etc., font quil existe une multitude de chemins depuis le dbut du cas jusqu la n. Chaque chemin est appel scnario . Un systme donn gnre peu de cas dutilisation, mais, en gnral, beaucoup de scnarios.

RemarqueParfois, 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 xer les ides ; il offre une excellente base pour la discussion avec le matre douvrage, qui le considre comme plus parlant .

ConclusionLes phases de recueil des besoins et dcriture des spcications 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 spcications permettant dapprofondir les besoins (on parle dailleurs juste titre de spcications techniques des besoins), la frontire entre ces deux notions est oue. 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 spcications de tous les besoins jusqu son terme. Cest ce moment seulement, que des priorits sont mises sur les spcications. 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 spcications. Le diagramme de cas dutilisation est un premier modle dun systme. Que savons-nous 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 dnir les spcications fonctionnelles. Il faut sattarder un instant sur lexpression partiellement connue pour mesurer les limites du modle des cas dutilisation. Les spcications 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.

14

UML 2

ChapitreLobjectif de cette phase de la modlisation est donc de clairement identier 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 rexion est sufsamment pousse, de poser les bases de la structure interne du systme, et donc dalterner analyse des besoins et bauche des solutions envisages. Aux spcications fonctionnelles sajoutent des spcications 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.

1

Diagramme de cas dutilisation 15

Problmes et exercicesLa 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

IDENTIFICATIONSIMPLES

DES ACTEURS ET RECENSEMENT DE CAS DUTILISATION

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 ? 1. Pour le 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 gure 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.

16

UML 2

ChapitreLe client est donc lacteur principal du systme. Or, bien souvent, le pompiste note le numro dimmatriculation du vhicule du client dans le systme informatique. 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.

1

Figure 1.14Le 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 dnit une nouvelle fonctionnalit modliser. Le grant prend le rle principal ; cest donc un nouvel acteur (gure 1.15).

Figure 1.15Deux acteurs pour deux rles.Client

Station-service

Se servir

Grer la station Grant

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 (gure 1.16) signiant que le chef datelier peut, en plus dassurer la gestion, entretenir des vhicules.

Figure 1.16Relation de gnralisation entre acteurs.Client

Station-service Se servir

Entretenir des vhicules Mcanicien

Grer la station Chef datelier

Diagramme de cas dutilisation 17

Exercices

EXERCICE 2

RELATIONS

ENTRE CAS DUTILISATION

Quel est le dfaut du diagramme prsent la gure 1.17 ?

Figure 1.17Exemple dun diagramme erron.Dcrocher le pistolet Client Station-service

Appuyer sur la gchette

Reposer le pistolet

Payer

Il ne faut 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.18Diagramme 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 ? 1.Le 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 sufsamment isoles les unes des autres pour tre des cas dutilisation. De plus, ces cas sont mutuellement

18

UML 2

Chapitreindpendants. Ils constituent des cas internes du systme car ils ne sont pas relis directement un acteur.

1

Figure 1.19Relations dinclusion entre cas dutilisation.Rserver une chambre dhtel inclut

Agence de voyages 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.20Relation dextension entre cas dutilisation.Rserver une chambre dhtel

Agence de voyages

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

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 .

Diagramme de cas dutilisation 19

Exercices

Figure 1.21Relation de gnralisation entre cas dutilisation.Rserver une chambre dhtel

Agence de voyages 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 x 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).

Le seul acteur 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. Il ne faut pas faire apparatre un squencement temporel dans un diagramme de cas dutilisation. On ne fait donc pas gurer 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

20

UML 2

Chapitrefaut 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 nal). Il ny a donc que deux cas : Emprunter une vido et Restituer une vido (gure 1.22).

1

Figure 1.22Diagramme 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 lms en salles ? Si la recherche se fait par genres, quels sont-ils ? Rechercher un lm 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 gure 1.23.

Figure 1.23Diagramme de cas dutilisation complt par la recherche dune vido.Client

Magasin de location de cassettes vido

Emprunter une vido

inclut Rechercher une vido

Restituer une vido

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 spcications 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.

Diagramme de cas dutilisation 21

Exercices

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 gure 1.23. La recherche dune vido peut se faire par genres ou par titres de lm. Les diffrents genres sont action, aventure, comdie et drame. Quand une liste de lms safche, le client peut trier les lms par titres ou par dates de sortie en salles.

Avant de 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 Identication 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. Pr-conditions Le client possde une carte quil a achete au magasin. Le distributeur est aliment en cassettes. Enchanement nominal 1. Le systme vrie la validit de la carte. 2. Le systme vrie que le crdit de la carte est suprieur ou gal 1 euro. 3. Appel du cas Rechercher une vido . 4. Le client a choisi une vido. 5. Le systme indique, daprs la valeur de la carte, pendant combien de temps (tranches de 6 heures) le client peut garder la cassette. 6. Le systme dlivre la cassette.

22

UML 2

Chapitre

Description du cas Emprunter une vido (suite)7. Le client prend la cassette. 8. Le systme rend la carte au client. 9. 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, identiant du client, identiant du lm). 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. Lidentiant du client. Lidentiant du lm emprunt. Rubriques optionnelles Contraintes non fonctionnelles Le distributeur doit fonctionner 24 heures sur 24 et 7 jours sur 7. La vrication de la validit de la carte doit permettre la dtection des contrefaons. Contrainte lie linterface homme-machine Avant de dlivrer la cassette, demander conrmation au client.

1

Diagramme de cas dutilisation 23

Exercices

Description du cas Rechercher une vido Identication 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 lm se fait par genres) 1. Le systme demande au client quels sont ses critres de recherche pour un lm (les choix possibles sont : par titres ou par genres de lm). 2. Le client choisit une recherche par genres. 3. Le systme recherche les diffrents genres de lm prsents dans le distributeur. 4. Le systme afche une liste des genres (les choix possibles sont action, aventure, comdie et drame). 5. Le client choisit un genre de lm. 6. Le systme afche la liste de tous les lms du genre choisi prsents dans le distributeur. 7. Le client slectionne un lm. 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 afche la liste de tous les lms 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 lm choisi par le client. Rubriques optionnelles Contraintes non fonctionnelles Contraintes lies linterface homme-machine Quand une liste de lms safche, 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 afcher plus de 10 lms la fois dans la liste.

24

UML 2

Chapitre

EXERCICE 6

RELATIONS DEXTENSION ENTRE CAS DUTILISATION, DE CAS DUTILISATION EN PAQUETAGES

REGROUPEMENT

1

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 lmer 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 afche 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. Le systme informatique 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 gure 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 signie que le systme de pilotage utilise le robot.

Figure 1.24Reprsentation 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 dnition 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 (gure 1.25). Le sens de rotation du moteur peut tre command. Le moteur est lacteur ; il est associ un cas appel Commander le moteur . La direction des roues peut tre modie, 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

Diagramme de cas dutilisation 25

Exercices

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 ots 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 spcications techniques du systme. Elles doivent gurer 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.Systme de contrle dun robot Capturer images Points dextension : envoiImage

Figure 1.25Diagramme de cas dutilisation du robot.

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

26

UML 2

ChapitreIntressons-nous prsent au sous-systme de pilotage. La gure 1.26 prsente le diagramme de cas dutilisation, qui se dduit sans problme du diagramme prcdent.Nom de lacteur Rle

1

Pilote metteur Rcepteur

Reprsente un pilote qui agit sur les commandes distance. Permet denvoyer des ondes radio. Permet de recevoir des ondes radio.Systme de pilotage dun robot Recevoir des images Points dextension : afficheImage

Figure 1.26Diagramme de cas dutilisation du systme de pilotage.

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 DUTILISATION

ACTEURS, EXTENSIONS CONDITIONNELLES ENTRE CAS

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.

Diagramme de cas dutilisation 27

Exercices

La mdiathque nemploie quune employe. Nanmoins, un acteur est dtermin par le rle quil joue vis--vis du systme modliser. Ici, lemploye a deux rles essentiels : le rle de bibliothcaire qui gre les uvres ainsi que les adhrents ; le rle de gestionnaire des contentieux ayant les connaissances juridiques sufsantes 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 (gure 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. Lauthentication 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 justie la dnition dun acteur supplmentaire : Administrateur. Tous les cas dutilisation lis aux acteurs incluent la procdure dauthentication matrialise par le cas Sauthentier . Dans le diagramme, la gestion des adhrents et la gestion des emprunts sont spares : Grer les adhrents consiste ajouter, supprimer ou modier 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.

28

UML 2

Chapitre

Figure 1.27Diagramme de cas dutilisation dune mdiathque.Grer les uvres

Une mdiathque inclut Rechercher les uvres inclut Grer les adhrents Bibliothcaire inclut Rechercher les adhrents inclut inclut Grer les emprunts Grer les contentieux Gestionnaire des contentieux Points dextension : procdureJudiciaire : {pas chaque fois que le gestionnaire utilise le cas mais une fois par mois} tend Dclencher une procdure judiciaire Grer les comptes utilisateurs Administrateur inclut Sauthentifier inclut

1

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

Diagramme de cas dutilisation 29

Exercices

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 n 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.

Pour un systme complexe, il vaut mieux se concentrer sur les fonctions essentielles puis passer aux cas moins importants.

Identication des principaux acteurs et recensement des cas dutilisation essentielsLacteur 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 gure 1.28.

Figure 1.28Se 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 (gure 1.29).

Figure 1.29Se servir de lessence : solution avec deux cas.Se Servir Client

inclut Armer pompe Pompiste

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 sufsamment complexe et bien isol des autres fonctions pour en faire un cas (gure 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 sufsant. 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 vrication 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 Vrier niveau cuve pour armement . Pour transmettre le niveau

30

UML 2

Chapitrede la cuve au pompiste, il faut relier lacteur Pompiste au cas Vrier niveau cuve pour armement . Le pompiste est inform que le niveau est trop bas, mais la vrication doit tre automatique pour que les pompes soient ventuellement bloques. Une relation dinclusion intervient donc entre les cas Armer pompe et Vrier niveau cuve pour armement (gure 1.31).

1

Recensement des cas de moindres importancesAprs 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 stationservice 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 (gure 1.31). Il est associ au cas Vrier 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 safche 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 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 gure 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 gure 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.

Diagramme de cas dutilisation 31

Exercices

Figure 1.30Utilisation 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 par carte bancaire} Point dextension : paiementParCarteBancaire tend tend tend Condition : {si le client choisit de payer en espce} Point dextension : paiementEnEspce

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 difcile de dire laquelle est la meilleure. La suite de lexercice se fonde arbitrairement sur la reprsentation avec des relations de gnralisation (gure 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 correcteIl faut prendre le temps dlaborer le diagramme de cas dutilisation, bien quil soit gnralement simple btir, an 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 nce