Vous êtes sur la page 1sur 270

Informatique

Synthse de cours exercices corrigs

&

UML 2
Pratique de la modlisation
2e dition
Les 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 2
2e dition
Benot Charroux
EFREI (cole dingnieur)

Aomar Osmani
universit Paris XIII

Yann Thierry-Mieg
universit Paris VI

Synthex

collection

ISBN : 978-2-7440-4050-4 ISSN : 1768-7616 Copyright 2009 Pearson Education France


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

Sommaire
Les 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 Bibliographie
Index

Sommaire III

Les auteurs
Benot 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

Introduction
Lapproche 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 livre
Lobjectif 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 livre
Le 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

Prrequis
Si 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.

UML 2

UML 2
UML 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.1
Organisation 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 dutilisation


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

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)

Limportance de bien recueillir les 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 : 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 dutilisation


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

UML 2

Chapitre

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.

Dnition
Un 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 spcication
Un 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.3


Reprsentations dun cas dutilisation.

strotype Nom du cas Liste de proprits

Nom du cas Liste de proprits

Figure 1.4
Autre 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.

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

Figure 1.5
Reprsentation des cas dutilisation un niveau dabstraction lev.

Borne interactive dune banque

Le rectangle de la gure 1.5 est appel classeur .

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

Notation
Un 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.6
Les compartiments dun classeur.

Borne interactive dune banque

Retirer argent

Effectuer un virement

Consulter comptes

UML 2

Chapitre

2.2 RELATIONS

ENTRE ACTEURS ET CAS DUTILISATION

Un acteur peut utiliser plusieurs fois le mme cas dutilisation.


EXEMPLE
La gure 1.7 montre un internaute qui tlcharge plusieurs morceaux de musique sur Internet.
Logiciel de tlchargement Tlcharger une musique

Figure 1.7
Association 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 spcication
Une 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.8
Relations 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.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

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

UML 2

Chapitre

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

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.

Remarque
Attention 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).
EXEMPLE
La 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.10
Relations 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

Notation
Le 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.

Dnition
Un 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.11
Regroupement 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.

UML 2

Chapitre

(3)

Modlisation des besoins avec UML


SONT LES ACTEURS

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.

Dnition
Lacteur 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 ).

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 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.
EXEMPLE
Lexemple 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.12
Diagramme de cas dutilisation pour une banque.
Guichetier

Gestion dune banque Retirer argent

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

Diagramme de cas dutilisation 11

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

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

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 dargent


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

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 xer 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 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

Chapitre
Lobjectif 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.

Diagramme de cas dutilisation 15

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
SIMPLES

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

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

Figure 1.15
Deux 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.16
Relation 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.17
Exemple 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.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 ? 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

Chapitre
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.
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.20
Relation 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.21
Relation 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

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

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

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.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 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.25
Diagramme 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

Chapitre
Intressons-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

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.26
Diagramme 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.27
Diagramme 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

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

Figure 1.29
Se 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

Chapitre
de 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).

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


Il 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 ncessite lintervention du pompiste. Attardonsnous un instant encore sur le paiement par carte bancaire. Il faut de toute vidence faire gurer 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 conrmer 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 n du cas Se servir ). Pour indiquer le moment o le montant est

32

UML 2

Chapitre
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 gure 1.31. Le paiement peut aussi intervenir avant de se servir. Dans ce cas, il est possible dajouter un deuxime point dextension (voir la gure 6.17 du chapitre 6).

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 n 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 difcile de dnir 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 gurer 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 signie 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 dnition, ils se produisent lintrieur dun systme. Ils ne peuvent donc pas tre dclenchs par un 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 gurer 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 remplissage . Acteur secondaire du cas Archiver les transactions . Acteur secondaire du cas Payer par carte bancaire .

Diagramme de cas dutilisation 33

Exercices

Acteur secondaire du cas Vrier niveau cuve pour armement .

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

34

UML 2

Chapitre

Diagramme de classes
1. 2. 3. 4. 5. 6. 7. 8. Exemple de diagramme de classes De lobjet la classe ..................... Interface ....................................... Relations entre classes ................... Connecteurs, signaux et ports ........ Diagramme dobjets .................... Contraintes ................................... Construction dun diagramme de classes ..................................... 36 36 44 45 54 54 56 57

Le diagramme de classes est considr comme le plus important de la modlisation oriente objet. Alors que le diagramme de cas dutilisation montre un systme du point de vue des acteurs, le diagramme de classes en montre la structure interne. Il contient principalement des classes. Une classe contient des attributs et des oprations. Le diagramme de classes nindique pas comment utiliser les oprations : cest une description purement statique dun systme. Laspect dynamique de la modlisation est apport par les diagrammes dinteractions (voir chapitre 3).

Problmes et exercices 1. Proprits dune classe ................... 61 2. Classe strotype ......................... 63 3. Nom dune classe .......................... 64 4. Dnition dun message asynchrone 64 5. classe active .................................. 65 6. Contrainte sur une classe................ 65 7. Classe paramtrable ...................... 66 8. Relations simples............................ 66 9. Ralisation dune interface ............. 68 10. Utilisation dune interface ............... 69 11. Relations ....................................... 70 12. Hritage ........................................ 71 13. Hritage ....................................... 73 14. Diagramme dobjets ...................... 75 15. Patron de conception objets composites .................................. 75 16. Application htelire ...................... 76 17. Application bancaire ..................... 77 18. Rservation de billets davion ......... 79 19. Patron Bridge .......................... 81 20. Patron Adapteur ..................... 82 21. Organisation du langage UML ....... 84

35

(1)

Exemple de diagramme de classes


Les classeurs dcrivent les caractristiques structurelles et comportementales de certains lments du modle UML. Les classes, les interfaces, les associations, les cas dutilisation, les collaborations, les acteurs, les types primitifs, les composants, les signaux sont des spcialisations possibles de classeurs. Le diagramme de classes prsente un ensemble de classeurs. Il dcrit les classes et leurs relations, comme le montre lexemple suivant. Il peut galement dcrire les regroupements de classes en paquetages, les interfaces et les objets, les classes qui participent une collaboration ou qui ralisent un cas dutilisation, etc.

EXEMPLE

La gure 2.1 modlise une entreprise laide de cinq classes : Entreprise, Ser vice, Bureau, Employ et Sige. Les classes possdent ventuellement des attributs (la classe Ser vice est caractrise par un nom, un employ se caractrise par un nom et un identiant). Elles contiennent aussi des oprations (demandeCongs pour la classe Employ). Les classes sont relies entre elles par des associations symbolises par des traits. Plusieurs types dassociations existent, qui se reprsentent diffremment (par des losanges, des ches).
Une agrgation Entreprise

Figure 2.1
Exemple de diagramme de classes.

1..* Une contrainte entre relations

1..* Service

1..* utilise Bureau

nom : String {subset} 1..* membre 1 chef Sige

Opration

Employ nom : String identifiant : Number demandeCongs() :bool

Pour crer un diagramme de classes, vous avez besoin dabord de dnir les classes et leurs responsabilits, les paquetages ainsi que les relations (association, composition, agrgation, hritage, dpendance) possibles entre ces lments. Dautres lments peuvent galement apparatre dans le diagramme de classes, comme les objets et les interfaces. Nous prsenterons, dans ce chapitre, les lments indispensables pour bien russir la modlisation du diagramme de classes. Commenons par dcrire la gense des classes.

(2)

De lobjet la classe
Beaucoup dobjets naturels ou informatiques se ressemblent tant au niveau de leur description que de leur comportement. An de limiter la complexit de la modlisation, vous pouvez regrouper les objets ayant les mmes caractristiques en classes. Ainsi, une classe dcrit les tats (ou attributs) et le comportement haut niveau dabstraction dobjets similaires. De cette faon, vous pouvez dnir la classe comme le regroupement des donnes et des traitements applicables aux objets quelle reprsente, comme le montre la gure 2.2. Dans

36

UML 2

Chapitre
lapproche objet, il faut, avant tout, pouvoir identier les objets, les diffrencier des autres avant de les dnir. Lidentit associe une classe est essentielle car elle conditionne la perception des structures et des comportements des objets quelle reprsente.
EXEMPLE
La gure 2.2 modlise la situation suivante : Jean est un homme clibataire g de 40 ans et Anne est une femme marie.
Le nom de la classe doit tre significatif et complet. Il commence par une majuscule. Sil est compos de plusieurs mots, la premire lettre de chaque mot doit tre une majuscule. Personne Liste des attributs de la classe avec les modificateurs daccs ventuels. Certains attributs napparaissent pas directement, ils seront dduits partir des relations entre classes. Liste des mthodes de la classe. Quand la mthode accepte des paramtres alors ces paramtres et leurs types sont ajouts entre les parenthses.

Figure 2.2
Reprsentation UML de la classe Personne.
Personne prnom : String dateNaissance : Date sexe : {M,F} calculAge() : Integer renvoyerNom() : String

Dans cet exemple, on regroupe les similarits entre les deux objets Jean et Anne dans une classe Personne. Les informations qui apparaissent dans lexemple sont le prnom, le sexe et la situation matrimoniale. De ce fait, la classe Personne est munie des attributs suivants : prnom, sexe et situation matrimoniale. Lge est une donne qui change. On le calcule en faisant la diffrence entre la date courante et la date de naissance. On parle dans ce cas dattributs drivs. Cette dernire analyse permet de complter la description de la classe en ajoutant lattribut date de naissance et une opration permettant le calcul de lge. En UML, la classe Personne est reprsente graphiquement par un rectangle divis en plusieurs compartiments. Le premier compartiment indique le nom de la classe, le deuxime ses attributs, le troisime ses mthodes. En fonction de ltat de la modlisation et des lments mettre en valeur, dautres compartiments, comme les compartiments de responsabilits et dexceptions, peuvent tre ajouts la description de la classe.

Dnition
Une classe est une description dun ensemble dobjets ayant une smantique, des attributs, des mthodes et des relations en commun. Un objet est une instance dune classe.

Remarque
Dans les langages de programmation objet, on confond souvent la notion dinstance et la notion dobjet alors que la premire est plus gnrale que la seconde. Un objet est une instance dune classe. Mais une instance peut tre une instance de plusieurs autres lments du langage UML. Par exemple, un lien est une instance dune association.

Un objet dune classe doit avoir des valeurs uniques pour tous les attributs dnis dans la classe et doit pouvoir excuter (sans exception) toutes les mthodes de la classe.

Diagramme de classes 37

2.1 CLASSE

ET MTHODE ABSTRAITES
Dans votre environnement quotidien, vous faites abstraction dune quantit de dtails qui permettent davoir une vision globale et gnralisante du monde. Cette notion dabstraction se retrouve, au sein de lapproche objet, dans les classes et les mthodes abstraites. Imaginez une classe modlisant une gure gomtrique. Toutes les gures gomtriques doivent pouvoir tre dessines. Ajoutez cette classe une opration qui permet de dessiner une gure. ce stade de la modlisation, vous tes dans lincapacit de dnir limplmentation de cette opration. On lappelle mthode abstraite .

Dnition
Une mthode est dite abstraite lorsquon connat son entte mais pas la manire dont elle peut tre ralise. Une classe est dite abstraite lorsquelle dnit au moins une mthode abstraite ou lorsquune classe parent contient une mthode abstraite non encore ralise.

EXEMPLE

Chaque lment graphique du langage UML est reprsent par une gure gomtrique. Les caractristiques communes de ces gures gomtriques sont le type de trait utilis pour les dessiner et la possibilit de les dessiner.

Il est vident que si nous ne connaissons pas la forme exacte de la gure dessiner nous ne pouvons pas le faire. On dira de ce fait que la mthode dessiner est abstraite dans la classe FigureGomtrique et la classe FigureGomtrique est donc elle-mme abstraite. Cependant, si on dnit un rectangle comme particularisation de la gure gomtrique alors le rectangle pourra tre dessin et la mthode dessiner fournit ainsi un corps lopration dessiner qui sera dite concrte. Une classe abstraite contient au moins une mthode abstraite. La gure 2.3 donne un exemple dune classe abstraite contenant une mthode abstraite et les consquences de cette proprit sur les classes drives. En particulier, une classe qui drive dune classe abstraite doit implmenter toutes les mthodes abstraites sinon elle reste aussi abstraite.

Figure 2.3
Exemple de classe abstraite.
FigureGomtrique{abstract} typeTrait : Trait dessiner() {abstract}

Rectangle dessiner() FigurePleine{abstract}

Implmentation de lopration dessiner

Cette classe reste abstraite car elle nimplmente pas la mthode dessiner

2.2 NOM

DE LA CLASSE
La modlisation dune classe passe par plusieurs tapes auxquelles participent ventuellement plusieurs intervenants. Par exemple, une classe peut tre extraite des cas dutilisation par un analyste programmeur, et aprs analyse et factorisation opres par un ingnieur de dveloppement, tre mise dans un paquetage prdni et considre comme valide. Pour distinguer ces tapes de modlisation, vous devez ajouter au nom de la classe toutes les informations pertinentes.

38

UML 2

Chapitre
Les informations les plus souvent utilises sont le nom de la classe, les paquetages qui la contiennent, le strotype ventuel de la classe, lauteur de la modlisation, la date, le statut de la classe (elle est valide ou pas). Par dfaut, une classe est considre comme concrte. Sinon, ajoutez le mot-cl abstract pour indiquer quelle est abstraite.

Spcication
La syntaxe de base de la dclaration dun nom dune classe est la suivante :
[strotype] [<NomDuPackage1>:::<NomDuPaquetage N>::] <NomDeLaClasse>[{[abstract],[auteur],[tat],}]

Figure 2.4
Quelques exemples de noms de classe.

NomSimple

nomPackage::NomSimple

Personne

java::util::Vector

FigureGomtrique {abstract, auteur : osmani tat : valide}

Controleur LeGardien

Remarque
Le nom de la classe doit voquer le concept dcrit par la classe. Il commence par une majuscule. Quand le nom est compos, chaque mot commence par une majuscule et les espaces blancs sont limins. En UML 2, les guillemets (comme dans lexemple de contrleur ser vent, la fois, indiquer les strotypes et les mots-cls du langage. Dans les versions prcdentes dUML, ils ne servent qu dsigner les strotypes.

2.3 ENCAPSULATION
Un principe de conception largement utilis (mme au-del de lapproche objet) consiste protger le cur dun systme des accs intempestifs venant de lextrieur. Cest le principe du coffre-fort : seuls les dtenteurs dune clef peuvent louvrir. Transpos la modlisation objet, ce principe sappelle lencapsulation. Il permet de dnir les droits daccs aux proprits dun classeur. UML dnit quatre niveaux dencapsulation dune proprit dune classe. Une proprit peut tre visible partout. Dans ce cas, elle est dite publique . Si elle nest visible qu lintrieur dune classe, elle est dite prive . En utilisant le principe de lhritage, les descendants dune classe peuvent avoir un accs privilgi aux proprits des classes parentes. Une classe parent qui souhaite autoriser laccs une de ses proprits ses seuls descendants doit dnir cette proprit comme protge . Lors de la modlisation dapplications complexes, les classes sont regroupes dans des paquetages ddis des domaines ou activits particulires. Le langage Java, par exemple, propose un paquetage ddi aux entres/sorties (java.io), un paquetage contenant les utilitaires (java.util), etc. La visibilit par dfaut dune classe et de ses proprits se limite au paquetage dans lequel elle est dnie.

Diagramme de classes 39

Notation
Les modicateurs daccs ou de visibilit associs aux classes ou leurs proprits sont nots comme suit : Le mot-cl public ou le caractre +. Proprit ou classe visible partout. Aucun caractre, ni mot-cl. Proprit ou classe visible uniquement dans le paquetage o la classe est dnie. Le mot-cl protected ou le caractre #. Proprit ou classe visible dans la classe et par tous ses descendants. Le mot-cl private ou le caractre -. Proprit ou classe visible uniquement dans la classe. Par ailleurs, le langage UML 2 donne la possibilit dutiliser nimpor te quel langage de programmation pour la spcication de la visibilit des classeurs et de leurs proprits. Il suft pour cela de prciser le langage utilis.

Le paquetage Paquetage1 utilise le paquetage Paquetage2. La classe Classe1 dnit quatre attributs avec des visibilits diffrentes (gure 2.5). Lattribut priv attribut1 nest accessible que dans la classe Classe1. Lattribut attribut2 est public dans le paquetage, accessible partir des classes Classe1, Classe2 et Classe3. Lattribut attribut3 est accessible partir des quatre classes alors que lattribut attribut4 nest visible que dans les classes Classe1 et Classe2.

Figure 2.5
Visibilit des proprits dune classe.

Paquetage1 + Classe1 -attribut1 attribut2 +attribut3 #attribut4 + Classe3 accessibles attribut2 attribut3 Paquetage2 + Classe2 accessibles attribut2 attribut3 attribut4 import + Classe4 accessibles attribut3

2.4 ATTRIBUTS

DE LA CLASSE

Les attributs dnissent les informations quune classe ou un objet doivent connatre. Ils reprsentent les donnes encapsules dans les objets de cette classe. Chacune de ces informations est dnie par un nom, un type de donnes et une visibilit. Le nom de lattribut doit tre unique dans la classe. En UML, les attributs correspondent des instances de classes dj prdnies. Pour des raisons de programmation, ce principe nest pas toujours respect par les langages de programmation objet, comme en tmoigne lexistence de types de base (int, oat,) dans les langages Java et C++.
EXEMPLE
La classe Htel possde un nom et un propritaire. Un htel contient entre une et deux cents chambres. Le propritaire de lhtel nest pas visible partir des autres classes. Par ailleurs, lhtel respecte les textes de lois communs tous les htels.

40

UML 2

Chapitre
Pour pouvoir modliser la classe Htel, vous avez besoin de connatre les classes String, Chambre, Personne et TexteDeLoi. Vous avez galement besoin de savoir modliser la multiplicit (entre une et deux cents chambres) et la possibilit dassocier une proprit la classe, et non linstance de la classe (texte de loi).

Figure 2.6
Classe Htel mettant en vidence les modicateurs daccs, la multiplicit et les attributs de classes.
Htel + chambres : Chambre[1..200] + nom : String -propritaire : Personne + texte : TexteDeLoi

Description des attributs en mettant en vidence la visibilit et la multiplicit. Dans le cas ou la multiplicit est reprsente par plusieurs intervalles, ils sont ordonns par ordre croissant. Quand les intervalles sont continus,ils doivent tre regroups. Exemple : [5..6] doit tre prfr "5,6 ". Le texte de loi qui rgit la profession nest pas propre un htel. Elle existe en un seul exemplaire, partage par toutes les instances dhtel. Il sagit dun attribut de classe (soulign).

Notation
Un attribut peut tre initialis et sa visibilit est dnie lors de sa dclaration. La syntaxe de la dclaration dun attribut est la suivante :
<modificateur daccs> [/]<NomAttribut>: <NomClasse>[[multiplicit]] [ = valeur(s) initiale(s)]

Les attributs de classes


Par dfaut, les valeurs des attributs dnis dans une classe diffrent dun objet un autre. Parfois, il est ncessaire de dnir un attribut qui garde une valeur unique et partage par toutes les instances de la classe. Cest par exemple le cas de la valeur de la variable PI=3,14 dnie dans la classe Math du langage Java. Quel que soit lobjet de cette classe, la valeur de PI reste la mme. De plus, cette valeur est accessible mme sil nexiste aucun objet de la classe Math. On dit alors que PI est un attribut de la classe Math, et non un attribut de ses instances. Les instances ont accs cet attribut, mais nen possdent pas une copie. Graphiquement, un attribut de classe est soulign, comme le montre lexemple de TexteDeLoi de la gure 2.6. En Java, comme en C++, par exemple, un attribut de classe saccompagne du mot-cl static.

Les attributs drivs


Les attributs drivs, symboliss par lajout dun slash (/) devant leur nom, peuvent tre calculs partir dautres attributs et des formules de calcul. Lors de la conception, un attribut driv peut tre utilis comme marqueur jusqu ce que vous puissiez dterminer les rgles lui appliquer.
EXEMPLE
La plupart des calculs concernant la pension de retraite sont bass sur lge. Lge est vu comme un attribut. Pourtant, lors de la modlisation de la classe Personne, cest la date de naissance qui est dterminante, et non lge, car celui-ci change en fonction de la date du jour. De ce fait, on dit que lattribut ge est un attribut driv : il est utilis comme un vrai attribut mais calcul par une mthode. Il est not /age : integer.

Diagramme de classes 41

2.5 MTHODES

ET OPRATIONS

Le comportement dun objet est modlis par un ensemble de mthodes. Chaque mthode correspond une implmentation bien prcise dun comportement. En gnral, lors de la conception des classes, on commence par donner les en-ttes des mthodes sans prciser la manire de les implmenter. Cependant, avant toute instanciation dune classe, il est ncessaire de donner une implmentation possible de ses mthodes. videmment, pour chaque en-tte, plusieurs implmentations sont possibles. UML distingue la spcication dune mthode, qui correspond la dnition de son entte, de son implmentation. La spcication est appele opration et limplmentation est appele mthode . Vous pouvez donc associer plusieurs mthodes une opration, comme le montre lexemple suivant :
EXEMPLE
Soit la factorielle de n (n!), une fonction dnie de faon inductive pour tout entier positif n par : 0! = 1 et n! = n * (n 1)!. On dit que : + fact (n : integer) : integer est une opration et que
+fact(n:integer):integer { if (n==0 || n==1) renvoyer (1); renvoyer (n * fact(n-1); *= i; } et +fact(n:integer):integer { int resultat = 1; pour (int i = n; i>0; i--) resultat*=i; renvoyer resultat; }

sont deux mthodes possibles implmentant lopration fact().

Dans une classe, une opration (mme nom et mmes types de paramtres) doit tre unique. Quand le nom dune opration apparat plusieurs fois avec des paramtres diffrents, on dit que lopration (et/ou la mthode) est surcharge. En revanche, il est impossible que deux oprations ne se distinguent que par la valeur retourne.

Spcication
La spcication dune opration contient les types des paramtres et le type de la valeur de retour. UML 2 ne prvoit pas de type de la valeur de retour dune opration. Mais lutilit de ce paramtre nous conduit garder la syntaxe dUML 1.5. La syntaxe de la dclaration est la suivante :
<modificateur daccs><nomDeLaMthode ([paramtres])>: [<valeurRenvoye>][{proprit}]

La syntaxe de la liste des paramtres est la suivante :


<NomClasse> nomVariable, <NomClasse> nomVariable, <NomClasse> nomVariable,

Les proprits correspondent des contraintes ou des informations complmentaires, comme les exceptions, les pr-conditions, les post-conditions, ou encore lindication quune classe est abstraite, etc. UML 2 autorise galement la dnition des oprations dans nimporte quel langage condition que celui-ci soit prcis a priori. Vous pouvez, par exemple, utiliser la syntaxe du langage C++ ou du langage Java pour exprimer toutes les mthodes des classes.

42

UML 2

Chapitre

2.6 OPRATIONS

DE CLASSE

Comme pour les attributs de classe, vous aurez peut-tre besoin de dnir une opration qui ne dpend pas des valeurs propres de chaque objet, mais qui porte sur les attributs de la classe ou uniquement sur les paramtres de lopration. Dans ce cas, lopration devient proprit de la classe, et non de ses instances. Elle na pas accs aux attributs des objets de la classe. Graphiquement, une mthode de classe est souligne.
EXEMPLE
Lexcution dune application cre plusieurs objets de la classe Processus. Pour af cher le nombre dobjets de cette classe disponible simultanment dans le systme, vous pouvez ajouter un attribut de classe qui compte le nombre de processus (lors de la cration et de la destruction des objets) et une mthode qui afche ce nombre.
Le nombreProc est un attribut de classe priv. Contrairement au nom qui est associ chaque processus, le nombreProc nest disponible quen un seul exemplaire. Il est associ la classe. Les indiquent que tous les attributs ne sont pas reprsents. Le strotype type de mthodes est utilis pour simplifier la notation ou lorsque les oprations ou leurs signatures ne sont pas encore connues, La mthode affiche() est une mthode de classe. Elle est publique et ne renvoie aucune valeur.

Figure 2.7
Opration de classe et strotype dopration.
Processus + nom : String - nombreProc : integer constructeurs + afficheNombreProc() : void

2.7 COMPARTIMENTS

COMPLMENTAIRES DUNE CLASSE

Le processus de modlisation se fait pas pas. De ce fait, lors de la construction des classes, les caractristiques ne sont pas toutes connues de faon prcise. Pour prendre en compte cette construction incrmentale, vous ajoutez des informations complmentaires aux classes telles que les responsabilits, les contraintes gnrales, les exceptions, etc. Pour ce faire, vous disposez de deux nouveaux compartiments dans la description graphique dune classe, savoir le compartiment des responsabilits et celui des exceptions. Si la modlisation concerne une application informatique implmenter, ces deux compartiments disparatront quand vous arriverez la phase de gnration de code ; ils seront transforms en un ensemble dattributs et de mthodes.
EXEMPLE
La classe ConnexionInformatique doit respecter une charte dnissant les modalits de connexion. Dans un premier temps, cette charte nest ni une mthode, ni un attribut : il sagit dune responsabilit de la classe. Dans la description de cette classe, comme le montre la gure 2.8, il faut aussi grer le cas o la connexion est impossible.

Diagramme de classes 43

Figure 2.8
Compartiment de responsabilit et dexception.
Connexion +ip : Byte [4] Respecter la charte Possder une adresse IP + seConnecter( ) exceptions Connexion impossible

Compartiment des responsabilits numrant lensemble des tches devant tre assures par la classe.

numre les situations exceptionnelles et les anomalies devant tre gres par la classe.

(3)

Interface
Le rle dune interface est de regrouper un ensemble doprations assurant un service cohrent offert par un classeur et une classe en particulier. Le concept dinterface est essentiellement utilis pour classer les oprations en catgories sans prciser la manire dont elles sont implmentes. La dnition dune interface ne spcie pas contrairement celle dune classe une structure interne et ne prcise pas les algorithmes permettant la ralisation de ses mthodes. Elle peut prciser les conditions et les effets de son invocation. Une interface na pas dinstances directes. Pour tre utilise, elle doit tre ralise par un classeur, qui est souvent une classe. Une interface peut tre spcialise et/ou gnralise par dautres interfaces. La ralisation dune interface par une classe est reprsente graphiquement par un trait discontinu qui se termine par une pointe triangulaire. Une manire simplie de reprsenter une interface consiste placer un petit cercle, souvent appel lollipop (sucette), rattach la classe qui ralise linterface, comme le montre la gure 2.9.

Spcication
Une interface est dnie comme une classe, avec les mmes compartiments. Les principales diffrences sont la non-utilisation du mot-cl abstract, car linterface et toutes ses mthodes sont, par dnition, abstraites, et lajout du strotype interface avant le nom de linterface.

Figure 2.9
Deux manires de reprsenter linterface et le lien avec la classe qui la ralise. Linterface NomInterface est ralise par la classe NomClasse.

interface NomInterface

NomClasse NomInterface

NomClasse

EXEMPLE

Selon des critres dnir a posteriori, les objets de la classe Htel et les objets de la classe Personne doivent tre comparables. Lopration qui compose linterface et permet la comparaison entre les instances des classes Personne et Htel doit tre la mme. Cependant, les critres de comparaison sont, videmment, diffrents. La gure 2.10 modlise cette interface commune, ralise par chacune des classes drives.

44

UML 2

Chapitre

Figure 2.10
Les classes Htel et Personne ralisent linterface Comparable.
Htel

realize interface Comparable CompareTo() : Integer realize Htel Comparable Personne Comparable

Personne

Quand une classe dpend dune interface (interface requise) pour raliser ses oprations, elle est dite classe cliente de linterface . Graphiquement, cela est reprsent par une relation de dpendance entre la classe et linterface. Une notation lollipop quivalente est aussi possible, comme le montre la gure 2.11.

Figure 2.11
La classe NomClasse dpend de linterface NomInterface.

interface NomInterface use NomClasse

NomClasse NomInterface

(4)

Relations entre classes


Les classes sont les lments de base du diagramme de classes. Une application ncessite videmment la modlisation de plusieurs classes. Aprs avoir trouv les classes, il convient de les relier entre elles. Les relations entre classes expriment les liens smantiques ou structurels. Les relations les plus utilises sont lassociation, lagrgation, la composition, la dpendance et lhritage. Dans la plupart des cas, ces relations sont binaires (elles relient deux classes uniquement). Mme si les relations sont dcrites dans le diagramme de classes, elles expriment souvent les liens entre les objets. De ce fait, mme les relations binaires entre classes peuvent faire intervenir plusieurs objets de chaque classe. La notion de multiplicit permet le contrle du nombre dobjets intervenant dans chaque instance de la relation.

4.1 MULTIPLICIT
Dans le mtamodle UML, la multiplicit est dnie par un ensemble non vide dentiers positifs lexclusion dun ensemble ne contenant que zro {0}. Elle apparat chaque extrmit dune relation et indique le nombre dobjets de la classe apparaissant cette extrmit pouvant sassocier un seul et unique objet de la classe apparaissant lautre extrmit.
EXEMPLE
Un objet de la classe Voiture est compos dau moins trois roues et dau plus dix roues. Pour ajouter cette information dans le diagramme de classes, on ajoutera le lien de composition entre les classes Voiture et Roue et on ajoutera la multiplicit [3..10] du ct de la classe Roue.
Voiture 3..10 Roue

Figure 2.12
Exemple de multiplicit.

Diagramme de classes 45

Cette relation entre deux classes indique quun objet de la classe Voiture doit tre compos de trois dix objets de la classe Roue. Les principales multiplicits normalises sont plusieurs (*), exactement n (n), au minimum n (n..*) et entre n et m (n..m). Il est aussi possible davoir un ensemble dintervalles convexes: n1..n2, n3..n4 ou n1..n2, n5, n6..*, etc.

4.2 ASSOCIATION
Une association reprsente une relation smantique entre les objets dune classe. Elle est reprsente graphiquement par un trait plein entre les classes associes. Elle est complte par un nom qui correspond souvent un verbe linnitif, avec une prcision du sens de lecture en cas dambigut. Parfois, un strotype qui caractrise au mieux lassociation remplace le nom. Chaque extrmit de lassociation indique le rle de la classe dans la relation et prcise le nombre dobjets de la classe qui interviennent dans lassociation. Quand linformation circule dans un sens uniquement, le sens de la navigation est indiqu lune des extrmits. UML 2 donne, aussi, la possibilit dexprimer la non-navigabilit dune extrmit par lajout dune croix sur lassociation, comme le montre la gure 2.15.

Figure 2.13
Lassociation et ses diffrents ornements.
multiplicit rle nom multiplicit rle

Indique le sens de lecture du nom ou du strotype. Dans le cas dun strotype, ce dernier est mis entre guillemets.

EXEMPLE

Association Une personne travaille pour une et une seule entreprise. Lentreprise emploie au moins une personne. Lentreprise est lemployeur des personnes qui travaillent pour elle et une personne a un statut demploy dans lentreprise.

Figure 2.14
Rle, multiplicit et nom de lassociation sans restriction de navigabilit.

Personne

1..* employ

travailler pour

1 employeur

Entreprise

EXEMPLE

Association avec navigabilit et contraintes Un polygone est dni par un ensemble de points jouant le rle de sommets. Les sommets du polygone ne sont accessibles que par la classe et par ses descendants. Par ailleurs, il est inutile et encombrant que les points aient un lien vers le polygone et, de manire gnrale, vers les gures auxquelles ils appartiennent.

Figure 2.15
Association oriente.

Polygone

dfini par

3..* #sommet

Point

La navigation est possible uniquement du polygone vers les points. Vous pouvez modliser lassociation entre les classes Polygone et Point et mettre en vidence la navigabilit de lassociation en ajoutant un attribut sommet dans Polygone (gure 2.16).

46

UML 2

Chapitre
Cependant, la classe Point ne doit pas avoir dattribut de type Polygone, ni de mthode qui renvoie les polygones dnis par ce point.

Figure 2.16
Exemple de modlisation de la navigation par des attributs.

Polygone #sommets : Point[3..*]

Lassociation la plus utilise est lassociation binaire (reliant deux classeurs). Parfois, les deux extrmits de lassociation pointent vers le mme classeur. Dans ce cas, lassociation est dite rexive .

Figure 2.17
Exemples dassociations rexives.
+parent 2

a le mme age Personne +enfant * * * amie de

La premire est asymtrique (parent de), la deuxime est symtrique et non transitive (amie de) et la dernire est la fois symtrique et transitive. Il est conseill dajouter les rles des extrmits dans le cas des relations asymtriques. Lassociation rexive entre classes a pour principale fonction de structurer les objets dune mme classe. Quand lassociation est asymtrique, elle permet de crer une hirarchie entre les objets sinon elle partitionne les instances de la mme classe. Quand lassociation est la fois symtrique et transitive, les objets sont regroups en classes dquivalence. Dans lexemple de la gure 2.17, lassociation rexive parent de permet de crer un arbre (hirarchie) gnalogique entre les instances de la classe Personne. La relation symtrique et transitive a le mme ge permet de regrouper les objets de la classe Personne en classes dquivalence (toutes les personnes ayant le mme ge appartiendront au mme groupe).

Remarque
De nombreux concepts sont dnis autour de la notion dassociation. Nous avons slectionn cinq concepts qui nous paraissent importants : lassociation avec contraintes, lassociation drive, la classe-association, la classe reprsentante (ou qualiante) et lassociation n-aire (n > 2).

4.3 ASSOCIATION

AVEC CONTRAINTES

Une association entre classes indique que des proprits sont changes ou partages par les classes relies. Lajout de contraintes une association ou bien entre associations apporte plus dinformations car cela permet de mieux prciser la porte et le sens de lassociation. Les contraintes sont mises entre accolades et peuvent tre exprimes dans nimporte quel langage. Cependant, il est prfrable dutiliser le langage OCL (Object Constraint Language). Le premier exemple de la gure 2.18 montre une association entre un polygone et ses sommets en prcisant que les sommets dun polygone sont ordonns, ce qui permet de rduire 1 le nombre de gures pouvant tre dessines partir de n sommets. Le deuxime exemple montre une contrainte entre deux associations : elle indique que le responsable du dpartement fait ncessairement partie du personnel.

Diagramme de classes 47

Figure 2.18
Exemples dassociations dont la porte est restreinte par les contraintes du langage OCL.

Polygone

dfini par

3..* #sommet {ordered}

Point lment du langage OCL qui indique que les sommets, dans un polygone, sont ordonns. Personne

1 Dpartement 1

emploie {subset} est responsable

4.4 ASSOCIATION

DRIVE

Une association drive est conditionne ou peut tre dduite partir dune autre association. Souvent un ensemble de contraintes, exprimes en OCL, est ajout une association drive pour dnir les conditions de drivation. Graphiquement, une association drive est symbolise par lajout dun slash avant le nom de lassociation. Dans lexemple de la gure 2.19, lassociation drive /emploi indique que la personne qui travaille pour une entreprise est la mme que celle qui est associe lun de ses dpartements.

Figure 2.19
Association drive dnie par une contrainte du langage OCL.
Entreprise

/emploie {Context : Personne self.departement.entreprise = self.entreprise}

n..* Personne

Dpartement

Cette contrainte suppose que la classe Personne contienne un attribut de la classe Dpartement et que la classe Dpartement contienne un attribut de la classe Entreprise

4.5 CLASSE-ASSOCIATION
Une association peut tre rafne et avoir ses propres proprits, qui ne sont disponibles dans aucune des classes quelle lie. Comme, dans le modle objet, seules les classes peuvent avoir des proprits, cette association devient alors une classe appele classe-association . partir du moment o elle est dnie, elle est considre comme toutes les autres classes du modle.
EXEMPLE
Les personnes qui travaillent dans une entreprise occupent un poste. Parmi les proprits associes au poste gure le salaire. Par ailleurs, quand une personne occupe un poste dans une entreprise, elle peut tre responsable de plusieurs personnes.
Personne employ Association rflexive oriente Poste salaire : Salaire * responsable Classe association employeur

Figure 2.20
Une classeassociation est caractrise par lajout dun trait discontinu entre la classe et lassociation quelle reprsente.

Entreprise

48

UML 2

Chapitre

4.6 ASSOCIATION

QUALIFIE

Parfois, lassociation entre deux classes donne peu dindications sur limplication effective des classes dans la relation, ce qui rend la modlisation imprcise. Cette imprcision concerne, en particulier, la multiplicit dune extrmit de lassociation et/ou la porte de lassociation par rapport aux classes associes. La qualication dune association permet, dans certains cas, de transformer une multiplicit indtermine ou innie en une multiplicit nie, comme le montre la gure 2.21.
EXEMPLE
Changement de multiplicit avec un qualicateur La classe Vector du langage Java permet de rfrencer un ensemble quelconque dobjets de la classe Object. On suppose quun objet est rfrenc une seule fois. La gure 2.21 donne une modlisation de cette situation avec et sans qualicateur. Un objet de la classe Object est rfrenc par un indice de type integer.

Figure 2.21
Intrt de la qualication dune classe pour prciser la multiplicit.

Vector

Object

Vector

indice:integer

Object

EXEMPLE

Qualication dune association pour limiter son impact sur les classes associes Lobjectif est de modliser lassociation entre une personne et une banque. Lunique lien entre les deux est le fait de possder au plus deux comptes. La banque assure bien dautres activits qui ne concernent pas le client. Pour mettre en vidence le fait que le lien entre la banque et une personne se limite la possession de plusieurs comptes, on ajoute une classe Compte qui reprsente la classe Banque dans lassociation avec la classe Personne.

Figure 2.22
Une classe qualiante est colle la classe principale.
Banque #Compte

0..2

possder

* client

Personne

4.7 ASSOCIATION N-AIRE


Une association n-aire lie plus de deux classes. La gestion de ce type dassociation est trs dlicate, notamment quand on ajoute la multiplicit (voir exercice 5). Pour cette raison, elles sont trs peu utilises. On leur prfre des associations binaires combines avec des contraintes du langage OCL.

Notation
Les traits pleins qui viennent de toutes les classes associes convergent vers un losange central pouvant ventuellement accueillir une classe-association. La multiplicit apparaissant sur le lien de chaque classe sapplique sur une instance du losange. Une instance du losange par rapport une classe est un ensemble contenant une seule et unique instance de chacune des classes, lexclusion de la classe-association et de la classe considre.

Diagramme de classes 49

EXEMPLE

Chaque anne, les tudiants sinscrivent dans un seul groupe et suivent des modules. Pour un groupe dtudiants donn (ne dpassant pas vingt-cinq individus), un module est assur par un seul enseignant. Un module nouvre que si au moins quatre tudiants sont inscrits. Par ailleurs, la politique de lcole fait quun enseignant ne peut pas assurer plus de trois modules pour un tudiant donn et un tudiant suit entre cinq et dix modules.
tudiant 4..* * 5..10 Module 4..25 1..3 Enseignant

Figure 2.23
Relation entre trois classes (relation ternaire).

4.8 RELATION DAGRGATION


Une agrgation est une forme particulire dassociation. Elle reprsente la relation dinclusion structurelle ou comportementale dun lment dans un ensemble. Contrairement lassociation, lagrgation est une relation transitive.

Notation
Une agrgation se distingue dune association par lajout dun losange vide du ct de lagrgat.

EXEMPLE

Une cole dispose dau moins une salle de cours. Dans chaque salle, on trouve des chaises et un vido-projecteur x au plafond.
cole 1 2..* Salle 1 1 Projecteur * * Chaise

Figure 2.24
Relation dagrgation.

Lagrgation permet galement la dlgation dopration : une opration dnie comme pouvant tre ralise par une classe est en ralit ralise par ses parties. Par exemple, on ralisera lopration de nettoyage dune cole en dlguant cette tche toutes ses salles. La dure de vie de lagrgat est indpendante des lments qui le constituent. La destruction dune instance de la classe Salle nimplique pas la destruction des instances de la classe String. Par ailleurs, un composant peut apparatre dans plusieurs agrgats (pas de restriction sur la multiplicit du ct de lagrgat). Une instance de la classe Projecteur peut tre partage par plusieurs salles.

4.9 RELATION

DE COMPOSITION

La composition, appele galement agrgation composite , est une agrgation particulire. Cela signie que toute composition peut tre remplace par une agrgation, qui elle-mme peut tre remplace par une association. La seule consquence est la perte dinformations. La relation de composition dcrit une contenance structurelle entre instances. Ceci implique, en particulier, que llment composite est responsable de la cration, de la copie et de

50

UML 2

Chapitre
la destruction de ses composants. Par ailleurs, la destruction ou la copie de lobjet composite implique respectivement la destruction ou la copie de ses composants. Une instance de la partie appartient toujours au plus une instance de llment composite.

Notation
Une composition se distingue dune association par lajout dun losange plein du ct de lagrgat. La multiplicit du ct de lagrgat ne peut prendre que deux valeurs : 0 ou 1. Par dfaut, la multiplicit vaut 1.

Comme tous les autres lments du langage UML, la composition ne rete pas forcment la ralit. Cependant, elle doit tre dle la situation modlise, comme le montre ce qui suit.
EXEMPLE
On peut complter lexemple prcdent en indiquant quune salle est compose dune seule porte et de plusieurs fentres. De plus, si le tableau est x, on considre que la relation de composition rete mieux le lien qui le lie la salle.
cole 1 2..* Salle 0..1 * Projecteur * Fentre 1 Porte

Figure 2.25
Exemple de relation de composition.

Chaise

Remarque
La relation de composition tant structurelle, le langage UML autorise la reprsentation suivante :

Figure 2.26
Reprsentation imbrique de la composition. Une salle est compose dune porte et de plusieurs fentres.
Porte 1
mp

Salle Fentre *

4.10 RELATION

DE DPENDANCE

Une dpendance est une relation unidirectionnelle exprimant une dpendance smantique entre les lments du modle. Elle est reprsente par un trait discontinu orient. Elle indique que la modication de la cible implique le changement de la source. La dpendance est souvent strotype pour mieux expliciter le lien smantique entre les lments du modle. Les strotypes normaliss sont, entre autres, friend (on accorde une visibilit spciale la classe source dans la cible), drive (la source est calcule partir de la cible), appel (appel dune opration par une autre), instantiate (une opration de la source cre une instance de la cible), send (une opration envoie un signal vers un lment cible), trace (la cible est une version prcdente de la source), rene , copie et create .
EXEMPLE
Le droulement des cours dpend des cours.
EmploiDuTemps Cours

Figure 2.27
Relation de dpendance.

Diagramme de classes 51

4.11 RELATION DHRITAGE


Un des intrts de la modlisation objet est la possibilit de manipuler des concepts abstraits. Cette notion est trs importante car elle permet de simplier la reprsentation. Elle est, par ailleurs, proche de la faon dont on modlise le monde : continuellement, sans mme sen rendre compte, on fait abstraction de certaines choses : par exemple, quand on parle dun vhicule, cest une vue de lesprit ; dans la ralit, il sagit de voitures, de camions, etc. Les camions se distinguent par des marques, des tailles diffrentes, etc. Ces diffrents niveaux dabstraction permettent, entre autres, de simplier le langage et de factoriser les proprits. Ce principe dabstraction est assur par le concept de lhritage. Ce concept permet tout simplement de partitionner rcursivement les objets en ensembles densembles. Quand les partitions sont grossires, on les rafne (spcialisation) et quand elles sont trs nes, on les gnralise. Chaque partition est modlise par une classe. Ce processus de gnralisation et de spcialisation est souvent guid par le sens smantique donn chaque partition dobjets et la granularit de la modlisation. En UML, la relation dhritage nest pas propre aux classes. Elle sapplique dautres lments du langage UML, comme les paquetages ou les cas dutilisation.
EXEMPLE
Les animaux sont des tres vivants qui ont tous une dure de vie limite. Ltre humain est un animal dont la dure de vie ne dpasse pas cent cinquante ans.

Dans cet exemple, lensemble des objets considrs est celui de la classe Animal. Celle-ci est une spcialisation de la classe EtreVivant dont elle reprend la proprit dureDeVie. Le partitionnement des objets de la classe Animal fait apparatre la partition reprsente par la classe EtreHumain. Linformation spcique de cette classe est la dure de vie qui ne dpasse pas cent cinquante ans.

Figure 2.28
Exemple dune relation dhritage.
EtreVivant

Animal

EtreHumain

La classe EtreVivant est dite classe parent ou superclasse de la classe Animal. La classe EtreHumain est dite classe enfant, classe drive ou sousclasse de la classe Animal.

Comme le montre lexemple, lhritage simplie la modlisation en utilisant les principes dabstraction et de dcomposition. Labstraction consiste dnir une hirarchie de sousproblmes devant tre traits en fonction de leur importance. La dcomposition, quant elle, consiste dnir un ensemble de sous-problmes pouvant tre traits sparment. La spcialisation de classes consiste rduire le domaine de dnition des objets. Cela se fait principalement de deux manires : en ajoutant de nouveaux attributs, indpendants de ceux existants, ou en rduisant le domaine de dnition des attributs existants.
EXEMPLE
Un rectangle et un cercle sont des gures gomtriques. Un carr est un rectangle dont la longueur et la largeur sont identiques. Les classes dcrivant cette situation sont FigureGomtrique, Rectangle, Carr. La classe Rectangle spcialise FigureGomtrique en ajoutant des attributs et la classe Carr spcialise la classe Rectangle en rduisant le domaine de dnition des attributs existants (largeur = longueur).

52

UML 2

Chapitre

Figure 2.29
Exemple dune relation dhritage.

FigureGomtrique

Rectangle
largeur: integer longueur: integer

Cercle

carr

La liste suivante donne quelques proprits de lhritage : La classe enfant possde toutes les proprits de ses classes parents. Mais elle na pas accs aux proprits prives de celles-ci. Une classe enfant peut rednir (mme signature) une ou plusieurs mthodes de la classe parent. Sauf indications contraires, un objet utilise les oprations les plus spcialises dans la hirarchie des classes. La surcharge doprations (mme nom, mais signatures des oprations diffrentes) est possible dans toutes les classes. Toutes les associations de la classe parent sappliquent, par dfaut, aux classes drives. Une instance dune classe peut tre utilise partout o une instance de sa classe parent est attendue (principe de la substitution). Par exemple, toute opration acceptant un objet dune classe Animal doit accepter tout objet de la classe Chat (linverse nest pas toujours vrai). Une classe peut avoir plusieurs classes parents. On parle alors dhritage multiple. Le langage C++ est un des langages objet permettant son implmentation effective. Ce mcanisme est largement considr comme une source derreurs, en raison de la complexit des relations entre attributs quil introduit.

Remarque
Lors de la rednition dun attribut dune classe dans une sous-classe, il est fortement conseill de le faire uniquement en restreignant son domaine de dnition. Deux cas sont possibles : soit garder le mme type et rduire le champ des valeurs, soit rednir lattribut comme objet dune sous-classe de sa classe prcdente. Dans le cas de la rednition de mthode, celle-ci est utilise an de restreindre les arguments (en xant certains), en tendant la dnition initiale de la mthode, en proposant dautres alternatives dimplmentation (par exemple pour optimiser le temps de calcul).

EXEMPLE

Hritage multiple Un bateau est la fois un vhicule moteur et un vhicule marin. Si les classes VhiculeAMoteur et VhiculeMarin existent, il est souhaitable dindiquer que le bateau hrite de lune et de lautre et de proter ainsi de toutes les proprits dj dnies. Cependant, la question se pose de savoir quelle est la proprit associe lobjet lorsque celle-ci apparat dans les deux parents directs. La solution la plus simple consiste dnir une priorit dhritage.

Diagramme de classes 53

Figure 2.30
Exemple dhritage multiple.

Bateau

Si on donne la priorit au VhiculeMarin alors le type du nom dans Bateau sera String.

VhiculeMarin nom: String

VhiculeMoteur nom: Char [1..10]

Remarque
Quand une classe (ou une opration) ne peut tre rednie, il faut ajouter la proprit {leaf} la dnition de la classe ou de lopration. Lexercice 5 prsente certaines proprits de la relation dhritage.

(5)

Connecteurs, signaux et ports


Les connecteurs spcient les liens de communication possibles entre les instances de classeur. Ces liens peuvent correspondre des instances dassociation ou des communications via des passages de paramtres, des appels dopration, etc. Une connexion peut tre ralise par un simple pointeur ou par un rseau de communication complexe. Le port est une proprit dun classeur lui permettant de prciser ses points dinteraction avec son environnement ou bien, parfois, avec ses propres parties. Les ports sont connects via des connecteurs. Ils peuvent spcier les services dun classeur ou les services quil attend de son environnement. Deux principaux types de ports existent : le port protocole, qui dcrit les connectiques interne et externe dun classeur (souvent classe active), et le port comportemental, qui est directement associ la machine dtats (automate) du classeur qui porte ce port. Un signal modlise un message asynchrone chang entre les instances. Il est caractris par un nom et un ensemble dattributs qui correspondent aux donnes transportes par le signal.

Figure 2.31
Reprsentations graphiques dun connecteur, dun port et dun signal.
connecteur port Port comportemental Port protocole signal estAllum fait:boolean Signal

(6)

Diagramme dobjets
Bien souvent, la description statique dun systme est faite travers le diagramme de classes. Cela permet de simplier la modlisation en synthtisant les caractristiques communes et en couvrant un grand nombre dobjets. Parfois, il est utile, voire ncessaire, dajouter un diagramme dobjets. Le diagramme dobjets permet, selon les situations, dillustrer le modle de classes (en montrant un exemple qui explique le modle), de prciser certains

54

UML 2

Chapitre
aspects du systme (en mettant en vidence des dtails imperceptibles dans le diagramme de classes), dexprimer une exception (en modlisant des cas particuliers, des connaissances non gnralisables) ou de prendre une image (snapshot) dun systme un instant donn. Le diagramme de classes modlise les rgles et le diagramme dobjets modlise des faits. Souvent, le diagramme de classes sert de modle pour instancier les classeurs an dobtenir le diagramme dobjets. Le diagramme de classes de la modlisation dune entreprise montre quune entreprise emploie au moins une personne et quune personne travaille dans au plus deux entreprises (gure 2.31(a)). En revanche, le diagramme dobjets modlise lentreprise qui emploie trois personnes (gure 2.31(b)).

Figure 2.32
Diagramme de classes et exemple de diagramme dobjets associ.

Entreprise nom: String 0..2 travailler pour 1..* Personne (a)

e:Entreprise nom: String="OSKAD" travailler pour travailler pour travailler pour

p1:Personne

:Personne (b)

p2:Personne

Les deux principaux classeurs instancis dans le diagramme dobjets sont les classes et les relations.

6.1 REPRSENTATION

DES OBJETS

Graphiquement, un objet se reprsente comme une classe, avec deux compartiments, celui du nom et celui des attributs. Le compartiment des oprations des classes nest pas utile dans les objets puisque linterprtation des oprations est la mme pour tous les objets et que tous les objets dune classe possdent les mmes oprations. Contrairement au nom dune classe, le nom dun objet est soulign et son identiant peut tre ajout devant le nom de la classe. Les attributs reoivent des valeurs. Quand certaines valeurs dattribut dun objet ne sont pas renseignes, on dit que lobjet est partiellement dni (gure 2.33(a)). Parmi les diffrentes formes dobjet, on trouve les instances nommes (gure 2.33(b)), les instances anonymes avec indication de paquetage (gure 2.33(c)), les instances multiples (gure 2.33(d)), les instances orphelines (gure 2.33(e)) et les instances strotypes (gure 2.33(g)). La gure 2.33(f) montre un objet sans valeur dattribut, mais avec un tat explicite. Cela est particulirement utile lorsque plusieurs valeurs des attributs dun objet correspondent une seule interprtation smantique. la gure 2.33(f), ltat grand correspond toutes les valeurs de lattribut taille suprieure un mtre quatre-vingts, par exemple.

Figure 2.33
Exemples dinstances dobjet.

:Personne nom:String="toto" age :integer="inconnu" (a)

albert:Adhrent (b)

:Adhrent ::Asso (c) albert:Adhrent [grand] (f)

:Adhrent (d) exception e.IOException (g)

albert: (e)

Diagramme de classes 55

6.2 INSTANCES

DE RELATION

Un diagramme de classes contient essentiellement des classes et des relations entre classes. Quand un diagramme dobjets est cr partir dun diagramme de classes, les classes sont instancies et deviennent des objets, tandis que les relations deviennent des liens au moment de leurs instanciations. Graphiquement, un lien se reprsente comme une relation, mais le nom de la relation est soulign. Lexemple de la gure 2.34 indique que le portable achet par Jean est compos dun cran et est livr avec une alimentation.

Figure 2.34
Instances de relation montrant des instances dassociation, de composition et dagrgation.

SonyVaio1:Portable

:Alimentation

:cran

6.3 RELATION

DE DPENDANCE DINSTANCIATION

La relation de dpendance dinstanciation dcrit la relation entre un classeur et ses instances. Elle relie, en particulier, les associations aux liens et les classes aux objets, comme le montre la gure 2.35.

Figure 2.35
Dpendances dinstanciation entre les classeurs et leurs instances.

Enseignant

1..*

donner cours

1..*

Etudiant instanceof :Etudiant

instanceof :Enseignant

instanceof donner cours

(7)

Contraintes
Les contraintes permettent de rendre compte des dtails que nexpriment pas les lments du langage UML an de restreindre la porte du modle. En UML, les contraintes sont vues comme un mcanisme dextension. Elles sont exprimes par une expression mathmatique, un langage de programmation, le langage naturel, etc. Cependant, un langage dexpression des contraintes est maintenant associ UML et permet dexprimer la plupart des contraintes : il sagit du langage OCL. OCL permet dexprimer principalement quatre types de contraintes : les invariants, les pr-conditions et les post-conditions lexcution doprations ainsi que les conditions de garde. Dans le diagramme de classes, les contraintes les plus couramment utilises permettent de spcier les valeurs initiales dun objet ou dune extrmit dune association, de spcier les rgles dhritage ({complete}, {incomplete}, {overlaps}, {distinct}, ), de spcier une mthode, de restreindre la porte dune association ({subset}, {xor},), dexprimer le mode dvolution des objets ({frozen}, {addOnly}, ), leur organisation ({ordered}, {frozen}, ). Dans le cadre dUML 2, les spcications du langage OCL gurent dans un document indpendant, dcrivant en dtail la syntaxe formelle et la faon dutiliser ce langage.

56

UML 2

Chapitre

EXEMPLE

1. Un comit est compos dau moins deux personnes. Le comit est prsid par un de ses membres. 2. Un polygone est compos dune srie dau moins trois sommets ordonns. Chaque sommet est un point. 3. Une voiture peut avoir entre trois et dix roues. Durant la vie dune instance de la classe Voiture, le nombre de roues ne change jamais.

Figure 2.36
Exemple dutilisation des contraintes pour afner la modlisation.
membre de 2..*

Comit

Polygone

Voiture

{subset} 1 Personne

prside {ordered} 3..* sommet Personne {frozen} 2..* Roue

Une contrainte, dans le modle de donnes, est associe au modle sauf si elle est associe un strotype. Dans ce dernier cas, la contrainte concerne le mtamodle, et non le modle de donnes. Pour plus de dtails, reportez-vous au document normatif ddi au langage OCL.

(8)

Construction dun diagramme de classes


La construction du diagramme de classes, comme celle des autres diagrammes, dpend la fois de lobjectif et de la nalit de la modlisation. Si on sintresse la nalit de la modlisation, souligne Steve Cook et John Daniels, il y a au moins trois points de vue qui guident la modlisation. Le point de vue spcication. Dans le domaine du logiciel, il met laccent sur les interfaces des classes plutt que sur leurs contenus. Le point de vue conceptuel. Il capture les concepts du domaine et les liens qui les lient. Il sintresse peu ou prou la manire ventuelle dimplmenter ces concepts et relations et aux langages dimplmentation. Le point de vue implmentation. Cest le plus courant. Lobjectif est de dtailler le contenu et limplmentation de chaque classe. En fonction des objectifs xs, vous obtiendrez des modles ventuellement diffrents. Pour cette raison, il faut absolument situer le contexte de la modlisation avant de commencer la construction de tout diagramme. Une dmarche couramment utilise pour btir un diagramme de classes consiste trouver les classes, puis les associations entre elles, trouver ensuite les attributs de chaque classe, et enn organiser et simplier le diagramme en utilisant notamment le principe de gnralisation. Il faut ritrer ce processus an damliorer la qualit du modle. Trouver les classes du domaine. La premire tape consiste, avec laide dun expert du domaine, trouver une liste de classes candidates. La dmarche est souvent empirique. Dans un premier temps, ne soyez pas trop restrictif. Les classes correspondent souvent des concepts ou des substantifs du domaine. Parfois, elles correspondent des oprations : une transaction pour une banque est une classe, tout comme un appel tlphonique pour un oprateur de tlphonie. Nanmoins, une opration qui sapplique un objet est rarement

Diagramme de classes 57

une classe : payer ou appeler ne sont pas des bons choix, mme pour une banque ou un oprateur de tlphonie. Aprs avoir tabli une premire liste, liminez les classes redondantes (celles qui modlisent des concepts similaires), ainsi que les classes superues (celles qui ne sont pas en rapport direct avec le domaine). Le nom des classes est important ; il ne doit pas tre vague. Par exemple, EmployDanscurieDeCourseAutomobile est trop vague. Prfrez Pilote et Mcanicien. Il faut cependant faire attention aux classes qui portent un nom de rle : PremierPilote et DeuximePilote ne sont pas des bons choix. Le niveau de granularit dune classe est important. Gnralement, une classe contient plusieurs attributs. Si un substantif ne peut pas tre dcompos en plusieurs entits, il sagit bien souvent dun attribut : un nom, par exemple, est considr comme un attribut dune classe Personne, qui a par ailleurs dautres attributs (lge, le sexe), tandis que lauteur dun livre ne peut pas se rduire lattribut dune classe Livre, car lauteur a un nom, une date de naissance, etc. Les classes ne doivent pas modliser des implmentations possibles dlments du domaine : une liste de clients nest pas une bonne ide de classe car vous pouvez crer un ensemble de clients de plusieurs faons, et pas seulement sous forme de liste. Dailleurs, un modle contient rarement la fois des classes et leurs conteneurs. Le modle dune banque, par exemple, ne doit pas runir simultanment les classes Clients au pluriel et Client au singulier, moins quil soit important de constituer un portefeuille de clients. Dans ce cas, il faut avoir recours deux classes, Client et PorteFeuilleDeClients et les associer par une relation de un vers plusieurs . Trouver les associations entre les classes. Les associations correspondent souvent des verbes mettant en relation plusieurs classes, comme est compos de , ou pilote , ou bien encore travail pour . Les relations entre classes doivent tre modlises par des associations, et non par des attributs (conducteur pour une classe Pilote est un mauvais choix dattribut mais conduire en tant quassociation entre les classes Pilote et Voiture est appropri). vitez les associations qui mettent en jeu plus de deux classes. Souvent, une association ternaire peut tre transforme en une association binaire qualie. Par exemple, un conducteur a besoin dune assurance pour conduire une voiture peut tre ramen un conducteur a une voiture et lassurance est un attribut de lassociation binaire entre conducteur et voiture . Quand plusieurs classes sont associes, plusieurs chemins sont ventuellement possibles entre les classes. Le problme qui se pose souvent est le suivant : faut-il limiter les chemins, ou au contraire, multiplier les associations en gnralisant les raccourcis ? Multiplier les associations facilite lutilisation des classes lors de limplmentation car il nest pas ncessaire de parcourir de nombreuses associations pour accder une information. Cependant, multiplier nimporte comment les associations conduit des chemins redondants, qui napportent aucune valeur ajoute au diagramme de classes. De plus, multiplier les associations rduit la rutilisabilit de lapplication, car deux classes associes peuvent difcilement tre utilises sparment. Dans la plupart des cas, vitez les chemins redondants durant la phase danalyse. Il sera toujours temps, au moment de limplmentation, dajouter des chemins si vraiment cela facilite la programmation. Ne confondez pas une association avec un attribut car un attribut est propre une classe tandis quune association met en jeu plusieurs classes. Dans certaines situations, cette rgle intangible est viole de faon presque indiscernable. Considrez les deux classes Avion et Camion : devez-vous considrer "est plus lourd que" comme une association ? Non, car le plus simple est de placer un attribut masse dans chaque classe et dutiliser une simple fonction de comparaison pour obtenir la rponse.

58

UML 2

Chapitre
Trouver les attributs des classes. Les attributs correspondent gnralement des substantifs tels que la masse dune voiture ou le montant dune transaction . Les adjectifs tels que rouge ou des expressions telles que 50 euros reprsentent souvent des valeurs dattribut. Un attribut ne doit pas tre driv dun autre attribut : lge dune personne, par exemple, peut tre dduit de sa date de naissance et de la date courante. Vous pouvez ajouter des attributs toutes les tapes du cycle de vie dun projet (implmentation comprise). Nesprez pas trouver tous les attributs ds la construction du diagramme de classes. Organiser et simplier le diagramme en utilisant lhritage. Un hritage dnote une relation de gnralisation/spcialisation entre plusieurs classes. Vous pouvez construire un graphe dhritage vers le bas , en partant dune classe du domaine et en la spcialisant en une ou plusieurs sous-classes, ou vers le haut , en factorisant les proprits de plusieurs classes pour former une classe plus gnrale. Cependant, ne confondez pas numration et hritage. Une numration est un type de donnes qui a un ensemble ni de valeurs possibles (les couleurs dune voiture par exemple). Un hritage reprsente une relation de gnralisation entre classes ; cela implique quune des sous-classes au moins a un attribut, une mthode ou une association spcique. Tester les chemins daccs aux classes. Suivez les associations pour vrier les chemins daccs aux informations contenues dans les classes. Manque-t-il des chemins ou des informations ? Si le monde modliser parat simple, le modle ne devrait pas tre complexe. Veillez nomettre aucune association. Cependant, ne cherchez pas relier systmatiquement toutes les classes. Certaines peuvent trs bien tre isoles. Itrer et afner le modle. Un modle est rarement correct ds sa premire construction. La modlisation objet est un processus, non pas linaire, mais itratif. Plusieurs signes dnotent des classes manquantes : des asymtries dans les associations et les hritages, des attributs ou des oprations disparates dans une classe, des difcults gnraliser, etc. La dmarche prsente dans cette section est une dmarche indicative. Diffrents processus permettent la construction dun diagramme de classes. Dans tous les cas, respectez les rgles simples et efcaces suivantes : liminez les classes redondantes.
EXEMPLE
Un avion est associ un aroport de dpart et un aroport darrive. Une premire modlisation permet dobtenir trois classes : AroportDpart, AroportArrive et Avion (voir exercice 11). En ralit, tous les aroports jouent le rle daroport de dpart pour certains avions et daroport darrive pour dautres. Il est donc insens de garder deux classes Aroport. On limine la redondance en ne crant quune classe Aroport et en modlisant les aroports de dpart et darrive comme des rles des associations qui lient lavion laroport.

Retardez lajout des classes faisant intervenir les choix de conception et de ralisation.
EXEMPLE
Lapplication dcrite dans lexercice 1 indique que le systme gre les salaris de lentreprise. Il nest pas souhaitable dintroduire une classe FichierEmploys car cela impose un choix de ralisation. Ce choix doit tre retard dans la mesure du possible.

Najoutez pas les tableaux ou listes dobjets dans les classes. Souvent, cette information est explicitement visible dans les multiplicits associes aux relations entre les classes. Une bonne faon de reprsenter la prsence dun tableau dinstances dune classe dans une autre est dutiliser les relations dagrgation ou de composition.

Diagramme de classes 59

Quand une classe dispose de beaucoup de responsabilits, trouvez un moyen de la simplier (voir le principe dabstraction et de dcomposition). Lors de la modlisation et du choix des relations entre classes, distinguez bien les objets physiques de leur description (du modle dobjets). Une proprit structurelle (attribut) peut tre reprsente par une association, une description textuelle dans un classeur ou une combinaison des deux. vitez les oprations daccs aux attributs (get et set) car celles-ci ajoutent beaucoup de bruits et sont souvent inutiles. Pour des applications complexes, souvent plusieurs diagrammes de classes sont dnis. Chaque diagramme met en vidence des parties particulires du modle. Par exemple, un diagramme montre les classes appartenant un paquetage, un autre montre les classes participant la ralisation dun cas dutilisation, etc.

Conclusion
Dans ce chapitre, nous avons dabord dni la notion de classe et dobjet. Un objet reprsente une entit concrte (par exemple un emplacement mmoire dans un ordinateur). La classe, quant elle, adopte un niveau plus lev dabstraction car elle modlise, dune faon concise, un ensemble dobjets. Cependant, souvent le diagramme dobjets est nglig lors de la modlisation. Cest pourtant lui qui permet de dnir les liens concrets entre les entits avant que ceux-ci ne soient gnraliss dans le diagramme des classes. Par exemple, lassociation rexive de la gure 2.17 ne permet pas de donner le nombre exact dobjets mis en jeu. Plusieurs consquences peuvent en dcouler. Par exemple, il nest pas possible de dnir la quantit de mmoire prvoir pour les instances de cette classe. Malgr leur importance, le diagramme de classes et le diagramme dobjets ont plusieurs limites la bonne comprhension dun systme. Notamment, ils ne montrent pas le cycle de vie des objets : nous ne savons pas, la lecture de tels diagrammes, dans quel ordre les objets sont crs, utiliss puis dtruits, pas plus quils nindiquent lordre dans lequel senchanent les oprations. Nanmoins, le diagramme des classes est le plus utilis pour la modlisation dun systme car il en montre la structure interne. Avec le diagramme des cas dutilisation, vu au chapitre 1, nous disposons, prsent, de deux faons de voir un systme. En effet, le diagramme des classes donne une approche objet tandis que celui des cas dutilisation montre un ct fonctionnel. Mais, rien nindique que ces deux modles sont cohrents entre eux : la structure interne donne par le diagramme des classes supportera-t-elle les fonctionnalits prvues par les cas dutilisation ? Ce passage du fonctionnel lobjet est dlicat. Une des solutions possibles pour garantir la cohrence des deux modles est de faire un dcoupage en couches horizontales : la couche du bas dcrit limplantation du diagramme des classes et la couche du haut permet, via une interface (homme-machine et graphique par exemple), daccder aux fonctions de lapplication. Le lien entre les deux couches est assur par ladjonction dune couche supplmentaire (dite couche applicative). Une tude de cas, dcrite la n de cet ouvrage dtaille comment dcomposer un systme en couches.

60

UML 2

Chapitre

Problmes et exercices
Les exercices suivants utilisent les principaux concepts des diagrammes de classes.

EXERCICE 1

PROPRITS DUNE

CLASSE

Proposez une modlisation, en vue dune implmentation informatique, de la situation suivante en mettant en vidence les diffrents compartiments et ornements des classes. Ralisez la modlisation tape par tape, en faisant apparatre, en fonction des connaissances disponibles, les changements du modle. 1. Une personne est caractrise par son nom, son prnom, son sexe et son ge. Les responsabilits de la classe sont entre autres le calcul de lge, le calcul du revenu et le paiement des charges. Les attributs de la classe sont privs ; le nom, le prnom ainsi que lge de la personne font partie de linterface de la classe Personne. 2. Deux types de revenus sont envisags, le salaire et toutes les sources de revenus autres que le salaire, qui sont tous deux reprsents par des entiers. On calcule les charges en appliquant un coefcient xe de 15 % sur les salaires et un coefcient de 20 % sur les autres revenus. 3 Un objet de la classe Personne peut tre cr, en particulier, partir du nom et de la date de naissance. Il est possible de changer le prnom dune personne. Par ailleurs, le calcul des charges ne se fait pas de la mme manire lorsque la personne dcde. 1. La modlisation implique la cration dune classe Personne. Les attributs de la classe sont le nom, le prnom, le sexe et lge. Dans lapproche objet, tout est objet ou classe. Sauf exceptions, les types des attributs sont aussi des classes. Mme si les types des attributs ne sont pas prciss, dnissez le nom et le prnom comme une chane de caractres (classe String). Partez du principe que le sexe peut avoir deux valeurs ('M' ou 'F') et que la date de naissance peut tre de type Date (classe Date). Cela impose videmment lexistence des classes String et Date, sinon il faut les crer. Tous ces attributs sont privs. Il faut donc les faire prcder du modicateur daccs private ou -. Les services offerts par cette classe sont le calcul de lge, la possibilit de voir le nom et le prnom dune personne ainsi que le calcul des charges et du revenu. cette tape, vous navez pas sufsamment dinformations pour dduire les oprations permettant le calcul des charges et du revenu ; elles resteront donc dans le compartiment de responsabilits de la classe. Elles seront, par la suite, ralises par lajout dun ensemble doprations et/ou dattributs.

Diagramme de classes 61

Exercices

Figure 2.37
Classe Personne.

Personne {tat :non valide} - nom : String - prnom : String - sexe : {F, M} - dateNaissance : Date +getNom : String +getPrnom : String +calculAge() : Date Responsabilits - calcul revenu - calcul charges

Dautres informations peuvent tre ajoutes comme lauteur, la date, etc.

Age = dateDuJour DateNaissance

Remarque
Dans la solution propose, la modlisation de lge est reprsente par un attribut dateNaissance et une mthode calculAge(). Une autre solution possible est de reprsenter lge par un attribut et de laisser au programmeur le choix dun modle dimplmentation. Dans ce cas, ajoutez lattribut driv /age ; sa valeur sera alors calcule partir dune mthode.

2. Au vu de ces nouvelles informations, les responsabilits de la classe se transforment en proprits de la manire suivante : Le calcul du revenu est reprsent par les attributs salaire et autreRevenu, avec ventuellement deux mthodes permettant la mise jour de leurs valeurs. Le calcul des charges est reprsent par deux attributs de classe, chargeSalaire et autreCharge, et par une mthode de calcul des charges (puisque celle-ci est bien dtaille dans lnonc). Le calcul des charges est invalid en cas de dcs de la personne. De ce fait, ajoutez un compartiment dexceptions pour prvoir le traitement ultrieur de cette exception.

Figure 2.38
Ajout des oprations la classe Personne.

Personne -chargeSalaire :Float =0.15 -autreCharge :Float =0.2 - nom : String - prnom : String - sexe : {F, M} - dateNaissance : Date - salaire : Integer - autreRevenu : Integer +getNom : String +getPrnom : String +calculAge() : Date +calculCharges () : Float

La mthode correspondante est : Renvoie (salaire * chargeSalaire + autreRevenu * autreCharge)

3. Pour crer un objet de la classe Personne, il faut par exemple disposer dun nom et dune date de naissance. Mais il est ventuellement possible de crer un objet personne en disposant dautres informations. Au lieu dajouter le constructeur indiqu seul, ajoutez le strotype constructor, qui permet la fois dorganiser des oprations en groupes et dindiquer quil est possible dajouter dautres constructeurs.

62

UML 2

Chapitre
Les oprations assurant le changement des valeurs des attributs peuvent galement tre regroupes sous le strotype update. Lnonc indique que le calcul des charges ne sapplique plus si la personne est dcde. Il sagit, dans ce cas, dune exception qui doit tre ajoute dans le compartiment ddi an quelle soit traite lorsque les informations sufsantes seront disponibles.

Figure 2.39
Ajout du compartiment numrant les exceptions.

Personne -chargeSalaire :Float =0.15 -autreCharge : Float =0.2 - nom : String - prnom : String - sexe : {F,M} - dateNaissance : Date - salaire : Integer - autreRevenu : Integer constructor Personne (String nom, Date dNaissance) update +setPrenom (String prenom) +setAge(Date dNaissance) +getNom : String +getPrnom : String +calculAge() : Date +calculCharges () : Float Exceptions Calcul charge si dcs La mthode correspondante est : Renvoie (salaire * chargeSalaire + autreRevenu * autreCharge)

EXERCICE 2

CLASSE

STROTYPE

En trigonomtrie, on a besoin de calculer le sinus, le cosinus, la tangente des angles et la valeur du nombre PI. La classe Angle existe dj. Proposez une structure qui regroupe ces fonctions. Les proprits de lnonc ne correspondent pas rellement une classe. Mais pour des besoins dimplmentation, par exemple, on peut vouloir les regrouper ensemble. UML offre un moyen de regrouper les variables et les oprations globales sous forme dune classe en utilisant le strotype Utility. Ces classes sont dites utilitaires car elles ne rpondent pas directement un besoin fonctionnel mais contribuent sa ralisation.

Figure 2.40
Utilisation du strotype Utility.

Utility Math PI :Real = 3,14 sinus(Angle) : Real cosinus(Angle) : Real tangente(Angle) : Real

Diagramme de classes 63

Exercices

EXERCICE 3

NOM DUNE

CLASSE

La classe Livre est dnie dans le paquetage Ressource se trouvant lui-mme dans le paquetage Bibliothque. Parmi les attributs de la classe Livre gurent le nom de type String se trouvant dans le paquetage Base et lemprunteur de type Adhrent se trouvant dans le paquetage Bibliothque. Donnez la reprsentation graphique de la classe Livre. Quand une classe est dnie dans un paquetage, celui-ci peut tre prcis dans la dclaration du nom de la classe. Du point de vue implmentation, le paquetage correspond souvent au chemin daccs la classe.

Figure 2.41
Espace de nommage des classes.

bibliothque::ressource :: Livre emprunteur:Bibbliothque ::Adhrent nom :base ::String

EXERCICE 4

DFINITION DUN

MESSAGE ASYNCHRONE

Lors de lenvoi dun e-mail, on souhaite lui associer un signal permettant de savoir que le message envoy est approuv par le destinataire. Utilisez le mcanisme de classe strotype pour modliser ce message. Les messages changs entre les instances de classe sont modliss par des oprations. Les oprations sont, par dnition, synchrones. UML 2 a prvu un mcanisme pour lchange des donnes asynchrones. Il sagit des signaux. Un signal est un message asynchrone. Comme une opration, le signal possde un nom et des paramtres. Cependant, un signal peut se modliser comme une opration, une classe ou une interface, en fonction de sa complexit et de sa nature. Quand il est modlis comme une opration, il est prcd du mot-cl signal. Quand il est modlis par une classe, le nom de la classe est prcd du strotype signal. On suppose que le signal associ le-mail a une valeur boolenne qui indique si le message est approuv ou pas.

Figure 2.42
Modlisation dun signal.
signal estAllum fait : Boolean

Ce signal aurait pu tre modlis dans la classe message sous forme dun message asynchrone comme suit : signal estOk():Boolean

64

UML 2

Chapitre

EXERCICE 5

CLASSE ACTIVE

Votre tlphone mobile dispose dun gestionnaire dvnements qui permet de suspendre lactivit du tlphone lorsque celui-ci nest pas sollicit, dafcher un message quand un rendez-vous est programm. Proposez une modlisation UML de ce gestionnaire dvnements. Le gestionnaire dvnements peut tre modlis par une classe. Linstance de cette classe cre elle-mme des instances de la classe vnements et contrle certaines activits de votre tlphone. Il sagit dune classe particulire qualie d active par UML. Une classe active initie et contrle le ux dactivits alors quune classe passive (par dfaut) sauvegarde les donnes et offre les services aux autres. Graphiquement, une classe active est reprsente comme une classe standard, avec une paisseur de trait plus prononce. Le gestionnaire dvnements contient des vnements. Il est capable de crer un vnement, de le suspendre, de lafcher ou de le dtruire. Cela donne le modle prsent la gure 2.43.

Figure 2.43
Exemple de classe active.

Gestionnairevnements evts : venement[1..n] +cration(vnement) +destruction(vnement) +afficher(vnement) +suspendre(vnement)

Lpaisseur du trait indique quil sagit dune classe active.

EXERCICE 6

CONTRAINTE

SUR UNE CLASSE

Les cartes de visite contiennent diverses informations. Leur caractristique commune est que leurs proprits sont immuables durant toute la vie de la carte. Proposez une modlisation UML de cet lment.

Vous pouvez geler une association en utilisant la contrainte standard {frozen}. Cette contrainte prcise que la valeur de lassociation est gele durant toute la vie de lassociation. Ce principe sapplique de la mme manire pour les classes et les attributs. Dans le cas de la classe, cela signie que les valeurs sont affectes lors de la cration de lobjet et ne changent pas.

Figure 2.44
Ajout des contraintes dans la description dune classe.

CarteDeVisite {frozen, ReadOnly}

Diagramme de classes 65

Exercices

Dans le cas de la carte de visite, deux types de contraintes saccumulent. En effet, la carte de visite est en lecture seule et, en principe, une fois imprime, ses proprits restent immuables durant toute la vie de la carte. Dans le cas gnral, les deux contraintes sont indpendantes.

EXERCICE 7

CLASSE

PARAMTRABLE

La gestion dune liste, indpendamment des objets quelle contient, utilise les oprations dajout, de suppression et de recherche. Proposez une modlisation UML de concept.

Certains langages de programmation typage fort, comme le C++, utilisent des classes paramtrables (patrons). Lintrt principal est de regrouper les comportements associs la structure de la classe indpendamment des objets quelle contient. Il appartient, par la suite, au programmeur de prciser le type dobjet concern pour que toutes les oprations soient applicables. Modlisez la classe Liste comme une classe standard, en ajoutant cette dnition un ou plusieurs paramtres substituables ClasseCible1ClasseCiblen qui reprsentent les classes des objets cibles. La gure 2.45 donne la reprsentation graphique de la classe paramtrable Liste et un exemple de classe cible utilisant cette classe paramtrable. Une fois que la classe Livre est dnie, les oprations permettant dinsrer, denlever, de chercher un livre sappliquent automatiquement.

Figure 2.45
En utilisant la classe paramtrable Liste et la classe standard Livre, on dnit une liste de livres utilisant les proprits de la classe Liste.

Liste

ClasseCible Livre Liste<Livre>

+inserer(ClasseCible) + supprimer(ClasseCible) +chercher(ClasseCible) (1)

EXERCICE 8

RELATIONS

SIMPLES

Donnez les diagrammes de classes correspondant aux situations suivantes : 1. Les personnes qui sont associes luniversit sont des tudiants ou des professeurs. 2. Un rectangle est caractris par quatre sommets. Un sommet est un point. On construit un rectangle partir des coordonnes de quatre sommets. Il est possible de calculer sa surface et son primtre et de le translater. 3. Un crivain possde au moins une uvre. Ses uvres sont ordonnes selon lanne de publication. Si la premire publication est faite avant lge de dix ans, lcrivain est dit prcoce . 4. Tous les jours, le facteur distribue le courrier aux habitants de sa zone daffectation. Quand il sagit de lettres, il les dpose dans les botes aux lettres. Quand il sagit dun colis, le destinataire du courrier doit signer un reu. Proposez les classes candidates et dduisez-en le diagramme de classes.

1. Cet exercice met en vidence lassociation multiple entre deux classes et la ncessit dajouter une contrainte (mcanisme dextension dUML) pour exprimer le fait que le rle dune personne luniversit est tudiant ou bien professeur. Seuls les noms des

66

UML 2

Chapitre
deux classes, des deux associations et la contrainte entre associations apparaissent dans la solution. En effet, vu les informations disponibles dans lnonc et lobjectif de la modlisation (mettre en vidence les relations entre classes), il est inutile dajouter dautres informations.

Figure 2.46
Contraintes entre associations.

tudier

Universit

{ ou } enseigner

Personne

2. Il sagit de reprsenter la fois les dtails dune classe et ses liens avec une autre classe. La classe principale modliser est la classe Rectangle. Elle est associe la classe Point qui joue le rle de ct dans lassociation avec la classe Rectangle. En labsence dinformations complmentaires permettant, en particulier, de savoir lutilit de modliser la classe Point, vous pouvez proposer deux solutions, lune faisant apparatre uniquement la classe Rectangle, et lautre, plus dtaille, faisant apparatre les classes Rectangle et Point. Cela dit, si seule la classe Rectangle est reprsente, vous perdez linformation sur lassociation du point vers le rectangle. Cela correspond une modlisation dune association unidirectionnelle de Rectangle vers Point alors que cette information nest pas disponible directement dans lnonc. Ce choix peut tre justi par lobjectif de la modlisation et par le choix de limplmentation (pour limplmentation de lassociation, un attribut point sera ajout dans Rectangle).

Figure 2.47
La gure de gauche transforme lassociation entre les classes Rectangle et Point en une relation de composition.

Rectangle -sommet : Point[2] constructor Rectangle(Point, Point) query + surface () : Float update +translater (Point)

Rectangle constructor Rectangle(Point, Point) query + surface () : Float update +translater (Point)

-sommet 2

Point

3. Les deux classes principales sont crivain et uvre. Une association bidirectionnelle nomme possder relie les deux classes. Les uvres sont ordonnes selon la date de publication. Ajoutez donc lattribut datePublication de type Date dans uvre et la contrainte {ordered} du langage OCL. Celle-ci signie que les uvres sont ordonnes. Pour indiquer que lcrivain est prcoce, ajoutez un commentaire en langage naturel sous forme de note. Cette note peut prciser galement le critre utilis pour lordonnancement. Il est aussi ncessaire dajouter deux attributs dans la classe crivain : dateDeNaissance de type Date et /prcoce de type Boolean. Lattribut /prcoce est un attribut drive de lassociation entre crivain et uvre. Par ailleurs, la multiplicit du ct de lcrivain nest pas prcise car celle-ci nest pas indique dans lnonc.

Figure 2.48
Ajout de contraintes pour limiter la porte dune association.
crivain #dateNaissance : Date

{ordered} 1..*

uvre #datePublication : Date

Diagramme de classes 67

Exercices

Si datePublication dateNaissance <10 lcrivain est dit prcoce

4. La lecture du texte permet de slectionner les classes candidates suivantes : Facteur, Courrier, Habitant, ZoneDAffectation, Lettre, BoteAuxLettres, Colis, Destinataire. La rdaction dune liste de classes candidates intervient en phase danalyse prliminaire. Lobjectif est de dgager les principaux concepts partir de lanalyse fonctionnelle. Les phases danalyse et de conception permettent de slectionner les classes qui apparatront dans le diagramme de classes. Pour trouver les candidates, il faut recourir un expert du domaine, consulter le cahier des charges du client et parfois tenir compte du langage dimplmentation qui sera utilis pour la ralisation (notamment pour les classes utilitaires). Si la modlisation concerne la mise en vidence du lien entre le facteur et les habitants ainsi que la zone daffectation du facteur, vous pouvez proposer la solution qui suit : La classe BoteAuxLettres nest pas pertinente. Elle ne fera pas partie du diagramme de classes. Un colis et une lettre sont des courriers particuliers. Le destinataire est le rle dun habitant quand il reoit un courrier. Il ne sera pas reprsent par une classe. Un facteur dessert une zone daffectation qui abrite plusieurs habitants. Le seul lien entre le facteur et lhabitant est la distribution du courrier (classe-association).

Figure 2.49
Modlisation dune classe-association.
Lettre Courrier

Habitant * destinataire ZoneDAffectation

affecter Colis Facteur

EXERCICE 9

RALISATION DUNE

INTERFACE

Les tudiants peuvent tre compars par rapport lattribut moyenne gnrale et les livres sont comparables par rapport leurs prix de vente. Pour des raisons dhomognit des interfaces prsentes par les classes, tous les objets comparables utilisent la mme opration compareTo(Instance). Proposez le diagramme de classes mettant en vidence lopration de comparaison. Les classes qui interviennent dans cette application sont tudiant et Livre. Lopration compareTo(Instance) compare tout type dobjet. Elle est donc abstraite. Si elle est commune toutes les classes, vous devez la dnir dans une interface que vous appellerez par exemple

68

UML 2

Chapitre
Comparable. Cette interface sera ralise par les classes qui lutilisent. Pour lapplication considre, vous obtenez le diagramme prsent la gure 2.50.

Figure 2.50
Ralisation dune interface.

tudiant moyenneGn :float realize interface Comparable CompareTo()

Livre

realize

EXERCICE 10 UTILISATION DUNE

INTERFACE

Luniversit propose des cours de langue accessibles aux agents administratifs et aux enseignants. La procdure dinscription est la mme pour les deux catgories de personnes. Une personne inscrite peut galement rsilier son inscription. Modlisez les classes pour reprsenter cette situation. Simpliez la modlisation en faisant apparatre uniquement les classes Enseignant et AgentAdministratif. Les agents administratifs et les enseignants sont des personnes particulires. Ils partagent les oprations inscrire() et rsilier(), qui font partie de la mme interface : Inscription. Dans un premier temps, crez les classes Personne, Enseignant, AgentAdministratif, et linterface Inscription qui contient deux oprations : inscrire() et rsilier(). Faites volontairement abstraction de la classe Cours car lobjectif ici est de mettre en vidence les relations de dpendance et de ralisation. La ralisation de linterface Inscription est faite de la mme manire par les deux classes drives de Personne. De ce fait, et pour viter la redondance de la ralisation, il suft quune seule des deux classes sen charge (relation de ralisation) et que la deuxime utilise les mthodes obtenues (relation de dpendance strotype par use ), comme le montre la gure 2.51.

Figure 2.51
La classe Enseignant ralise linterface Inscription et la classe AgentAdministratif utilise le rsultat.

Personne

Enseignant interface Inscription +inscrire() +rsilier()

AgentAdministratif

realize

use

Figure 2.52
Utilisation dune interface.

Enseignant use

AgentAdministratif

Diagramme de classes 69

Exercices

Pour mettre en vidence uniquement les deux classes Enseignant et AgentAdministratif, utilisez le lien simpli de la gure 2.52, qui indique que la classe Enseignant implmente linterface Inscription utilise par la classe AgentAdministratif.

EXERCICE 11 RELATIONS
Une commande est lie plusieurs produits. chaque produit de la commande sont associes des dates. 1. Donnez une modlisation UML de lassociation entre ces trois classes. Plus prcisment, deux dates sont affectes chaque produit dune commande, une date et un produit sont associs une seule commande et, une commande et une date donne sont lis deux dix produits. 2. Compltez la modlisation UML de lapplication. Soit la base de donnes suivante : (commande, produit, date) = {(c1,p1,d1), (c1,p2,d2), (c2,p1,d2), (c2,p4,d4)}. 3. Vriez quelle respecte bien le diagramme UML de la question 1. Sinon, ajoutez-lui les tuples ncessaires pour la rendre conforme. 1. Trois classes peuvent tre extraites de la description de lapplication : Commande, Produit et Date. Les deux relations entre les classes dnies dans lnonc sont les suivantes : Une relation binaire intervient entre Produit et Commande. La commande est compose de plusieurs produits. Mais, les dures de vie des objets ne sont pas lies. De ce fait, cette relation peut tre modlise par une agrgation. La commande est compose de plusieurs produits. En principe, il faut dnir une multiplicit *. Une relation ternaire met en jeu les trois classes Commande, Date et Produit.

Figure 2.53
Relation ternaire.

Commande 1 2 Date

Produit

2. Pour dnir la multiplicit mettre ct dune classe dans une relation n-aire, calculez le nombre dobjets de ladite classe consistant avec chaque ensemble de (n-1) objets des autres classes. Lunion de ces nombres calculs constitue la cardinalit de la relation. Pour cette application, calculez le nombre dobjets de la classe Date consistant avec chaque couple dobjets des classes Commande et Produit, le nombre dobjets de la classe Commande consistant avec chaque couple des classes Produit et Date et le nombre dobjets de la classe Produit consistant avec chaque couple dobjets des classes Commande et Date. Par exemple, lnonc indique qu chaque couple dobjets des classes Commande et Produit sont associes exactement deux dates (gure 2.54).

70

UML 2

Chapitre
Par ailleurs, mme si lnonc ne le dit pas explicitement, vous savez quune commande na de sens que si elle porte sur au moins un produit et quun produit peut apparatre dans plusieurs commandes. La multiplicit de lagrgation est, de ce fait, restreinte.

Figure 2.54
Multiplicits associes aux relations n-aires.

Commande 1

1..* 2..10 2 Date

Produit

3. La contrainte de cardinalit est viole plusieurs fois par la base de donnes. Par exemple, il est indiqu qu chaque couple dinstances des classes Commande et Produit correspondent exactement deux instances de la classe Date. Les couples (c2,p1) et (c2,p4) ne vrient pas cette contrainte.
Commande Produit Date

c1 c1 c1 c1 c2 c2 c2 c2

p1 p1 p2 p2 p1 p1 p4 p4

d1 d3 d2 d5 d2 d6 d4 d7

EXERCICE 12 HRITAGE
1. Le chat et le chien sont des animaux. Les animaux possdent tous un nom. Proposez une modlisation de cette situation en faisant apparatre que dautres animaux que les chats et les chiens existent et quun animal ne peut pas tre la fois un chat et un chien. 2. Les animaux, en fonction de leur catgorie (chat, chien), ont un cri spcique. Si la catgorie de lanimal nest pas connue, le cri ne peut tre ralis. Compltez la modlisation prcdente pour inclure cette proprit. 3. Tous les animaux sont comparables par rapport la puissance, en dcibels, du cri dgag. La valeur maximale est connue pour chaque catgorie danimaux. De plus, pour des soucis dhomognit, toutes les comparaisons doivent respecter une interface commune. Compltez le modle prcdent avec ces nouvelles informations.

Diagramme de classes 71

Exercices

1. Vous avez besoin de trois classes : Chat, Chien et Animal. La classe Animal est plus gnrale (hritage) que les deux classes Chien et Chat. Une instance de la classe Chat (respectivement Chien) ne peut pas tre instance de la classe Chien (respectivement Chat) : il sagit dun hritage exclusif (utilisation de la contrainte {disjoint} du langage OCL). Par ailleurs, dautres animaux que les chats et les chiens existent. La contrainte {incomplete} du langage OCL permet dexprimer cette contrainte.

Figure 2.55
Hritage avec contraintes. Lhritage est incomplet et les hritiers sont tous disjoints.

Animal nom : String {incomplete, disjoint} Chat Chien

2. Lopration crier() est partage par tous les animaux. Elle doit donc apparatre au niveau de la classe Animal. Cependant, la mthode associe nest connue quau niveau des descendants de cette classe. Cette mthode est donc abstraite. Les classes Chat et Chien doivent absolument rednir la mthode crier().

Figure 2.56
Ajout de la mthode abstraite partage par tous les hritiers de la classe Animal.
Chat

Animal {abstract} nom : String abstract crier() {incomplete, disjoint} Chien

3. La valeur en dcibels de la puissance des cris est pareille pour chaque catgorie danimaux . Utilisez donc une variable statique. Pour oprer les comparaisons, dnissez une interface commune, par exemple Comparable, contenant les oprations ncessaires, en loccurrence oat compareTo(type) qui est ralise par chaque catgorie danimaux comme le montre la gure 2.57.

Figure 2.57
Implmentation de linterface Comparable par les classes drives de la classe Animal.
interface Comparable float compareTo(type) realize

use

Animal {abstract} nom : String abstract crier()

realize {incomplete,disjoint} Chat static float bitCri Chien static float dbitCri

72

UML 2

Chapitre

EXERCICE 13 HRITAGE
Un tudiant et un enseignant sont des personnes particulires. 1. Proposez un modle de classes correspondant. Un doctorant est un tudiant qui assure des enseignements. La modlisation sera suivie par une implmentation en Java ou en C++. 2. Compltez le modle de classes prcdent en exploitant au mieux les possibilits du langage cible. Un doctorant et un tudiant doivent sinscrire au dbut de lanne et ventuellement modier leur inscription. En fonction des deux modles proposs. 3. Ajoutez cette fonctionnalit aux deux prcdents modles. 1. Les tudiants et les enseignants hritent de la classe Personne. Dautres personnes, qui ne sont ni des tudiants, ni des enseignants, drivent de la classe Personne. Ajoutez la contrainte{incomplete} du langage OCL pour expliciter cette situation.

Figure 2.58
Relation dhritage.

Personne {incomplete} tudiant Enseignant

2. Un doctorant est la fois un tudiant et un enseignant. Le doctorant hrite la fois des proprits des enseignants et de celles des tudiants. Il sagit bien dun hritage multiple. Cela ncessite, galement, lajout de la contrainte {overlapping}, qui indique quun tudiant et un enseignant peuvent instancier le mme objet (lintersection entre les ensembles dobjets des classes Enseignant et tudiant nest pas vide). Ce modle est correct pour une implmentation en C++, car ce langage autorise lhritage multiple.

Figure 2.59
Solution en utilisant lhritage multiple.
tudiant

Personne {incomplete, overlapping} Enseignant Doctorant

Diagramme de classes 73

Exercices

Java naccepte que lhritage simple. Cette contrainte implique une modlisation hirarchique de lhritage. En dautres termes, une classe peut avoir au plus un seul parent. Lajout de cette contrainte implique implicitement lajout de la contrainte {disjoint} entre les classes qui drivent directement de toute classe du modle. Vous pouvez modliser

cela en sparant les instances des doctorants de celles des tudiants et des enseignants. Vous obtenez le modle prsent la gure 2.60.

Figure 2.60
Solution en utilisant lhritage simple
tudiant

Personne {incomplete, disjoint} Enseignant Doctorant

3. Linscription ncessite au moins deux oprations. Dans le cas de lhritage simple, la solution consiste dnir une interface Inscription contenant les deux oprations. Celles-ci peuvent tre ralises par la classe tudiant et utilises par la classe Doctorant (gure 2.61).

Figure 2.61
Solution dans le cas de lhritage simple.
tudiant

Personne

{incomplete, disjoint} Enseignant Doctorant use interface Inscription

realize

La solution propose par la gure 2.61 est aussi valable dans le cas o le langage supporte lhritage multiple. Cependant, dans ce dernier cas, deux autres solutions sont possibles comme le montre la gure 2.62.

Figure 2.62
Les deux solutions possibles dans le cas de lhritage multiple.

Personne {incomplete, tudiant Enseignant overlapping}

Personne {incomplete, Enseignant overlapping}

tudiant inscrire() ; modifier()

Doctorant realize interface Inscription inscrire() ; modifier() ; Doctorant

74

UML 2

Chapitre

EXERCICE 14 DIAGRAMME DOBJETS


Un robot se dplace dans un environnement compos de zones, de murs et de portes. Proposez le diagramme dobjets dcrivant la situation suivante : le robot Mars est en mouvement. Il est li une instance mondeCourant de la classe Monde dcrivant les mondes possibles o peut voluer le robot. Le robot peut manipuler des objets se trouvant dans le monde dans lequel il volue. linstant qui nous intresse, le robot Mars est en mouvement et mondeCourant est li aux zones z1 et z2. La zone z2 est compose de deux murs (m1 et m2) et dune porte. La largeur de la porte est de un mtre. Donnez le diagramme dobjets associ cette situation. Vous avez besoin des classes Robot, Monde, Objet, Zone, Mur et Porte. La classe Robot est active. Le diagramme dobjets prsent la gure 2.63 correspond un snapshot dune situation particulire et varie selon la position du robot.

Figure 2.63
Diagramme dobjets.

mars:Robot [enMouvement]

m1:Mur z2:Zone :Porte largeur:integer=1m z1:Zone m2:Mur

mondeCourant:Monde

:Objet

EXERCICE 15 PATRON

DE CONCEPTION

OBJETS COMPOSITES

Une gure gomtrique est compose de gures simples ou composes. Une gure compose est constitue de plusieurs gures et une gure simple peut tre un point, une ligne ou un cercle. Une gure peut tre dessine ou translate. 1. Donnez la modlisation des classes de cette situation. 2. De manire plus gnrale, la notion dobjets composites se retrouve dans beaucoup dapplications. De ce fait, il est intressant de proposer un patron de conception qui modlise les objets composites et de les instancier en fonction des objets considrs. tendez la solution prcdente an de modliser nimporte quel ensemble dobjets dcrits par une hirarchie dagrgation dobjets ayant le mme comportement. 1. Toutes les gures comportent les oprations dessiner() et translater(). Les mthodes associes ne sont pas connues, donc la classe Figure est abstraite. Une gure peut tre spcialise en gure simple ou en gure compose. Cette dernire peut tre compose (relation dagrgation) de plusieurs gures.

Diagramme de classes 75

Exercices

Figure 2.64
Diagramme de classes modlisant les gures simples et composes.
FigureSimple +dessiner() +translater()

Figure{abstract} Elment de +dessiner() +translater()

FigureCompose +dessiner() +translater()

Cercle +dessiner() +translater()

Point +dessiner() +translater()

Ligne +dessiner() +translater()

2. Le patron de conception dobjets composites permet de reprsenter des objets qui se dcrivent par une hirarchie dagrgation dobjets dans laquelle tous les objets, jusquau plus haut niveau, prsentent un mme comportement (on peut leur appliquer un mme ensemble de mthodes). Cette solution est propose par Erich Gamma.

Figure 2.65
Le diagramme de classes modlisant le patron de conception objets composites .

Les oprations communes dont certaines sont abstraites. Composant{abstract}

Composant{abstract} +operation Feuille


+operation()

fils de

Composite
+operation()

Appliquer lopration tous les descendants.

+ajout(c :Composant)

EXERCICE 16 APPLICATION

HTELIRE

Un htel est compos dau moins deux chambres. Chaque chambre dispose dune salle deau qui peut tre une douche ou une salle de bain. Lhtel hberge des personnes. Il peut employer du personnel et est dirig par un des employs. Lhtel a les caractristiques suivantes : une adresse, le nombre de pices, la catgorie. Une chambre est caractrise par le nombre et le type de lits, le prix et le numro. On peut calculer le chiffre daffaires, le loyer en fonction des occupants. 1. Donnez le diagramme de classes. 2. Utilisez les contraintes pour afner les relations.

76

UML 2

Chapitre
La gure 2.66 propose une solution qui rpond aux deux questions.

Figure 2.66
Diagramme de classes reprsentant lapplication htelire.

Htel adresse : String catgorie : String


calculChiffreAffaires() : double

Chambre 2..* nombreLit : int typeLit : String lePrix : double numro : int
Loyer() : double

Le loyer est calcul en fonction du nombre de personnes, de la saison, etc.

hberge emploie {ou} {ou} 0..1 1 dirige 1 loue {element de} * 1..* Personne * client

1 1 SalleDEau

douche

Baignoire

EXERCICE 17 APPLICATION

BANCAIRE

Diagramme de classes 77

Exercices

Une banque compte plusieurs agences rparties sur le territoire franais. Une banque est caractrise parle nom de son directeur gnral, son capital global, son propre nom et de ladresse de son sige social. Le directeur gnral est identi par son nom, son prnom et son revenu. Une agence a un numro dagence et une adresse. Chaque agence emploie plusieurs employs, qui se caractrisent par leurs nom, prnom et date dembauche. Les employs peuvent demander leur mutation dune agence une autre, mais un employ ne peut travailler que dans une seule agence. Les employs dune agence ne font que grer des clients. Un client ne peut avoir des comptes que dans une seule agence de la banque. Chaque nouveau client se voit systmatiquement attribuer un employ de lagence (conseiller). Les clients ont un nom, un prnom et une adresse. Les comptes sont de nature diffrente selon quils soient rmunrs ou non (comptes courants). Les comptes rmunrs ont un taux dintrt et rapportent des intrts verss annuellement. 1. Donnez la description complte de toutes les classes (remplissez tous les compartiments). Prcisez les types des attributs et les types de retour des fonctions. Les attributs sont tous privs. Chaque attribut possde deux mthodes publiques (getAttribut renvoie la valeur dun attribut et setAttribut affecte une nouvelle valeur un attribut). Toutes les autres mthodes sont accessibles uniquement dans le package de la classe. 2. Analysez les classes trouves en (1) et modlisez-les en factorisant (par gnralisation ou autre) au mieux la description des proprits. 3. Une relation particulire lie lagence, le client, lemploy et le compte. De quelle relation sagit-il ? Dessinez le modle de cette relation. 4. Donnez le diagramme de classes en nutilisant que leur nom et ajoutez tous les ornements possibles aux relations.

1. Les classes qui apparaissent dans cette application sont Banque, Directeur, Agence, Employ, Client, CompteRmunr, CompteNonRmunr.

Figure 2.67
Description dtaille des classes de lapplication.

Banque
-nomDirecteur : String -capital : int -adresseSiege : String +getNomDirecteur() : String +setNomDirecteur(String n) +getCapital():int +setCapital(int capital) +getAdresseSiege():String +setAdresseSiege(String s) Banque(String Adresse)

Directeur
-nom : String -prenom : String -revenu : float +getNom() : String +setNom (String n) +getPrenom ():String +setPrenom(String p) +getRevenu():float +setRevenu(float s)

Employ
-nom : String -prenom : String -dateEmbauche : Date +getNom: String +setNom(String n) +getPrenom():String +setPrenom(String s) +getDate(): Date +setDate(Date s) mutation(Agence g): boolean

Client
-nom : String -prenom : String -adresse : String -conseiller : Employer -agence : Agence -comptes : [1..N] Compte +getNom: String +setNom(String n) +getPrenom():String +setPrenom(String s) +getDate(): Date +setDate(Dates) mutation(Agence g):boolean

CompteNonRmunr
-solde : float -numero : int ...

Agence
-nomAgence :String -adresseAgence : String +getNomAgence() : String +setNomAgence(String n)

CompteRmunr
-solde : float -numero : int -taux : float ... verserInteret() : void

2.

Figure 2.68
Les liens de gnralisation entre les classes de lapplication.
CompteRemunr Compte Directeur

Personne

Employ CompteNonRemunr Client

3.

Figure 2.69
Associations ternaires avec classe-association.

Agence

Employ

1..* Compte Client

78

UML 2

Chapitre
4.

Figure 2.70
Diagramme de classes de lapplication bancaire.
Banque

Personne

1 1 1..* Agence 1..* 1

Directeur 1..* 1 Client 1..* Employ

Compte

CompteRmunr

CompteNonRmunr

EXERCICE 18 RSERVATION

DE BILLETS DAVION

Un avion assure plusieurs vols et un vol est assur par un seul avion. Un vol peut tre un vol cargo ou un vol de passagers. Les avions utiliss pour ces deux types de vols ne sont pas les mmes. 1. Donnez le diagramme de classes exprimant cette situation. 2. Ajoutez les contraintes du langage OCL pour exprimer le fait quun vol cargo soit assur par un avion-cargo et quun vol de passagers soit assur par un avion de passagers. Les vols sont proposs par des compagnies ariennes. Pour un meilleur remplissage des avions, un vol est partag par plusieurs affrteurs. Un des affrteurs assure louverture et la fermeture de chaque vol. Un vol est caractris par une date et un lieu de dpart, une date et un lieu darrive. 3. Donnez la modlisation des classes de cette situation. Quand un client fait une rservation auprs dune compagnie arienne pour un ou plusieurs passagers, il est inform du fait que le vol compte plusieurs escales. Une escale est caractrise par des dates darrive et de dpart ainsi quun aroport qui dessert plusieurs villes. 4. Proposez le diagramme de classes pour cette situation. 5. partir de ces diagrammes partiels, proposez un diagramme de classes modlisant cette application.

1. Tous les avions assurent plusieurs vols. Il est donc utile de remonter lassociation "assurer vol" au niveau des classes Avion et Vol. Cependant, si vous nutilisez pas les contraintes et si la contrainte spciant quun avion-cargo (respectivement de passagers) assure exclusivement des vols cargos (respectivement de passagers) alors la seule solution consiste, non pas remonter lassociation entre Avion et Vol, mais la prciser entre tous les types de vols et davions (gure 2.71).

Diagramme de classes 79

Exercices

Figure 2.71
Diagramme de classes.

Avion

Vol

AvionCargo *

assurer

VolCargo

AvionPassagers

assurer

VolPassagers

2. Lajout des contraintes du langage OCL permet une meilleure gnralisation travers lexpression de cas particuliers et dexceptions. Vous pouvez remonter lassociation entre un avion et un vol au niveau des classes Vol et Avion et ajouter une contrainte qui restreint limpact de lassociation sur les instances des classes (gure 2.71).

Figure 2.72
Gnralisation de lassociation assure par lajout de contraintes OCL.

Avion

assurer

Vol

context Vol inv: type=cargo implies Avion.type=cargo inv: type=passager implies Avion.type=passager

AvionCargo

VolCargo

AvionPassagers

VolPassagers

3. Le rle de la compagnie arienne par rapport un vol est celui daffrteur. Laffrteur qui ouvre un vol est aussi celui qui le ferme. De plus, un vol ne peut tre ouvert puis ferm quune seule fois. UML ne fournit pas un moyen dexprimer cette double synchronisation. De ce fait, une note est ajoute au diagramme pour exprimer cette contrainte. Les caractristiques dun vol (dates et lieux) ne sont pas dtailles et seront reprsentes par de simples attributs.

Figure 2.73
Modlisation dtaille de la classe Vol.

Vol #dateDpart:Date #dateArrive:Date #lieuDpart:Lieu #lieuArrive:Lieu +ouvrirVol() +fermerVol()

1..*

propose

1..*

CompagnieArienne

Prconditions ouvrir(): instance de vol jamais ouverte former(): instance de vol ouverte par le mme objet et jamais ferme.

4. Lassociation qui lie le client et la compagnie arienne concerne la rservation. La rservation nat de cette association et se compose de toutes les donnes la concernant. Il sagit donc dune classe-association. La rservation concerne un passager et un vol. Dans la modlisation prcdente, les lieux de dpart et darrive ne sont pas dtaills (reprsentation sous forme dattributs). Cette fois, le lieu est connu : il sagit de laroport. Les deux attributs modlisant le lieu se transforment en rle dans les associations reliant le vol et laroport.

80

UML 2

Chapitre
Une escale se caractrise par des dates et un aroport. Elle est dcrite par les attributs de la classe Vol mais pas par ses mthodes (ouvrir(), fermer()). Ce nest donc pas un vol particulier. Un vol peut compter plusieurs escales ordonnes. Chaque escale est lie un aroport. Lescale nat dune relation entre un vol et un aroport, qui nest ni un aroport de dpart, ni un aroport darrive. Les escales sont reprsentes par une classe-association entre un vol et un aroport.

Figure 2.74
Modlisation des vols des compagnies ariennes.

Client

Vol Reservation

* * * Escale

dpart 1 arrive 1 {ordered} *

Aroport

Passager CompagnieArienne

dateDpart:Date dateArrive:Date Ville

EXERCICE 19 PATRON BRIDGE


Une gure gomtrique peut tre un cercle ou rectangle. On souhaite proposer aux clients un outil de dessin des gures gomtriques qui sadapte lenvironnement informatique. Les interfaces, la qualit des dessins dpendent de lenvironnement. 1 .Proposez une modlisation qui isole le dessin dune gure gomtrique et qui la spcialise en fonction de lenvironnement. 2. Selon le mme principe et dune manire plus gnrale, on souhaite concevoir une structure qui permet un client de voir une classe et ses oprations de haut niveau. Cette structure doit sparer compltement la dnition abstraite des classes et leur implmentation. Proposez un schma de modlisation. 1. Le client est associ aux gures gomtriques. Son objectif est de les dessiner. La gure gomtrique est compose dun ensemble de proprits, dont celles lies au dessin (trait, couleur, etc.). Ces proprits dpendent de lenvironnement (elles sont spcialises). La gure gomtrique peut tre spcialise, en particulier, en cercle ou en rectangle.

Figure 2.75
Modlisation gnrique dune gure gomtrique.

Client

FigureGomtrique

Cercle

Rectangle

DessinInterface1

DessinInterface2

Diagramme de classes 81

Exercices

Dessin

Labstraction est visible par les clients, renvoie les demandes vers limplmentation (operation=Implementation.operation) et fournit des fonctions de haut niveau. Les classes RenedAbstraction implmentent les diffrentes abstractions, la faon des classes FigureGeometrique qui implmentent diffrentes gures. Implementation est une interface entre plusieurs implmentations possibles. Elle offre des oprations de bas niveau. Les classes Implementation1 et Implementation2 permettent dimplmenter linterface Implementation en proposant des mthodes concrtes.

Figure 2.76
Diagramme de classes du patron de conception Bridge .
+Implementation.operations()
Client Abstraction +operation() Implementation +operation()

RefinedAbstraction

RefinedAbstraction

Implementation1

Implementation2

EXERCICE 20

PATRON ADAPTEUR
Un diteur de jeux possde un jeu permettant aux enfants de connatre les animaux. Les enfants peuvent, en particulier, apprendre la forme et le cri des animaux parmi lesquels le chat et la vache. Le chat est modlis par la classe LeChat possdant au moins les deux mthodes formeChat() et criChat() et la vache est modlise par la classe LaVache possdant les deux mthodes criVache() et formeVache(). Comme le montrent les noms des mthodes, la premire spcication de ce jeu est propre aux animaux modliss. Lditeur souhaite amliorer ce jeu en crant une interface commune tous les animaux qui lui permette den ajouter de nouveaux, sans modier linterface avec le client, et dutiliser le polymorphisme dans la gestion des animaux (manipuler des troupeaux). 1. Proposez une modlisation des classes pour cette nouvelle version du jeu en faisant apparatre le client. 2 .On souhaite rutiliser tout le code dvelopp dans la version prcdente. Proposez une modlisation permettant dincorporer les anciennes mthodes pour viter de les rcrire. 3. Est-il possible de gnraliser ce raisonnement pour les applications de mme type ? Si cest le cas, proposez le patron gnrique correspondant.

1. Chaque animal est modlis par une classe : Chat, Vache, etc. Ces classes possdent au moins les comportements suivants : crier() et forme(). Les mthodes implmentes dans les diffrentes classes danimaux ont toutes les mmes oprations (mmes signatures de mthodes). Cela signie que le client qui utilise un animal na pas besoin de savoir a priori de quel animal il sagit exactement ; il doit pouvoir accder un ensemble doprations. En ce sens, il suft de crer une classe gnrale appele Animal, qui regroupe les oprations communes. Cela permet de traiter tous les animaux de la mme manire, sans

82

UML 2

Chapitre
se soucier des diffrences dimplmentation, et dajouter ultrieurement de nouveaux animaux sans devoir modier le client.

Figure 277
Gnralisation des proprits des animaux dans la classe Animal, seule interface avec le client.
Client

Animal{abstract} +crier():{abstract} +forme():{abstract}

Chat +crier() +forme()

Vache +crier() +forme()

Lajout dune classe danimaux quelconques doit se faire par drivation de la classe Animal. Cette nouvelle classe doit absolument implmenter les mthodes abstraites de la classe Animal. 2. Pour pouvoir rutiliser les mthodes dj dveloppes et garder la proprit du polymorphisme, vous devez trouver un moyen dadapter les noms des anciennes mthodes aux noms gnriques choisis dans la nouvelle version du jeu. Par exemple, pour le cas de la classe Chat, il suft de trouver un moyen dappeler les mthodes criChat() et formeChat() de la classe LeChat. La solution simple qui permet de rsoudre ce problme consiste mettre la classe LeChat dans la classe Chat. La composition permet la dlgation doprations. Ainsi, la classe Chat se contente tout simplement de dlguer les oprations quon lui demande la classe LeChat et dutiliser par l mme le code dj dvelopp.

Figure 2.78
La classe LeChat existante et la nouvelle classe Chat.
La mthode crier() se contentera dappeler la mthode criChat() de la classe LeChat

Chat +crier() +forme()

LeChat

1 +formeChat()

+criChat()

Ce processus dencapsulation des classes de lancienne version est dcrit la gure 2.78.

Figure 2.79
Les classes Chat et Vache encapsulent respectivement les classes LeChat et LaVache.
Client

Animal{abstract} +crier() + forme()

Chat +crier() +forme()

Vache +crier() +forme()

Lion +crier() +forme()

3. Ce mcanisme dadaptation par encapsulation peut tre utile dans le contexte dutilisation du polymorphisme. Il permet aussi de ne plus se poser de questions sur lintgration de classes existantes lors de la phase de conception : la solution prsente ici ne prsente aucune contrainte et peut tre utilise facilement. Il sagit dune instance du patron Adaptateur .

Diagramme de classes 83

Exercices

LeChat +criChat() +formeChat()

LaVache +criVache() +formeVache()

La solution gnrique du patron Adaptateur consiste donc faire correspondre une interface donne un objet existant contenant des mthodes quelconques. En simpliant la gure 2.79, vous obtenez la solution gnrique prsente la gure 2.80.

Figure 2.80
Vue simplie du patron Adaptateur .
Client

ClasseCible +mthode()

Adaptateur +mthode()

ClasseAdapte +mthodeAdapte()

+mthode(){ instanceClasseAdapte.mthodeAdapte() ; }

EXERCICE 21 ORGANISATION

DU LANGAGE

UML

La spcication du langage UML 2 dnit un type de donnes comme un classeur particulier dans le paquetage Noyau. Un type de donnes est compos de plusieurs proprits et de plusieurs oprations ordonnes. Un type primitif, comme les entiers, et un type numr sont deux spcialisations dun type de donnes. Un type numr est compos de littraux ordonns. Utilisez cette description et vos connaissances de la modlisation des types en UML pour proposer le modle de classes des types de donnes. Cette solution est extraite de la norme UML 2.0 superstructure spcication publie par lOMG.

Figure 2.81
Diagramme de classes dun type de donnes dans le mtamodle UML.

Classifier

+datatype

+ownedAttribute * {ordered, subsets attribute, subsets ownedMember} +ownedOperation * {ordered, subsets feature, subsets ownedMember}

DataType

Property

0..1

{subsets namespace, subsets featuringClassifier, subsets classifier}

+datatype 0..1 {subsets namespace, subsets redefinitionContext, subsets featuringClassifier}

Operation

InstanceSpecification

PrimitiveType

Enumeration

+enumeration 0..1 {subset namespace}

+ownedLiteral * {ordered, subsets ownedMember}

EnumerationLiteral

84

UML 2

Chapitre

Diagramme dinteraction
1. Intrt des interactions ................... 86 2. Diagramme de squence en dtail ....................................... 91 3. Diagramme de communication en dtail ..................................... 101 4. Rutilisation dune interaction ...... 104

Le diagramme de cas dutilisation montre des acteurs qui interagissent avec les grandes fonctions dun systme. Cest une vision fonctionnelle et externe dun systme. Le diagramme de classes, quant lui, dcrit le cur dun systme et montre des classes et la faon dont elles sont associes. Cest une vision statique et structurelle. Les diagrammes dinteraction permettent dtablir un pont entre ces deux approches : ils montrent comment des instances au cur du systme communiquent pour raliser une certaine fonctionnalit. Les interactions sont nombreuses et varies. Il faut un langage riche pour les exprimer. UML propose plusieurs diagrammes : diagramme de squence, diagramme de communication, diagramme de timing. Ils apportent un aspect dynamique la modlisation du systme.

Problmes et exercices 1. Syntaxe des messages.................. 107 2. Ajouter un aspect dynamique un diagramme de classes et traduction dun diagramme de squence en diagramme de communication ....................... 109 3. Messages synchrones vs messages asynchrones ................................ 111 4. Messages perdus, trouvs ou envoys dans des flots dexcution parallles .................................... 114 5. Fragments dinteraction combins pour dcrire une mthode complexe .................................... 115 6. Oprateurs dinteraction .............. 116 7. Diagrammes de squence pour illustrer des cas dutilisation .. 117 8. Fragments dinteraction combins . 120 9. Diagrammes de squence pour illustrer des collaborations .... 121 10. Rutilisation dune interaction ....... 124 11. Diagrammes de squence pour illustrer les interactions dans un classeur structur ............. 125

85

(1)

Intrt des interactions


Les diagrammes de cas dutilisation montrent des interactions entre des acteurs et les grandes fonctions dun systme. Cependant, les interactions ne se limitent pas aux acteurs : par exemple, des objets au cur dun systme, instances de classes, interagissent lorsquils schangent des messages.

EXEMPLE

Le diagramme de classes prsent la gure 3.1 montre la structure interne dun systme de pilotage automatique compos des trois classes : PiloteAutomatique, Voiture et Moteur. Ce diagramme nindique pas comment le pilotage est ralis. Pour ajouter un aspect dynamique la modlisation, il faut descendre au niveau des instances et montrer comment elles interagissent. Des instances de ces classes peuvent gurer sur un diagramme dinteraction particulier, appel diagramme de communication (gure 3.2). Dans cet exemple, les instances senvoient les messages dmarrer et allumer. Pratiquement, lenvoi des messages dclenche lappel des mthodes dmarrer et allumer, ce qui a pour effet de consulter ou de changer ltat de la voiture et du moteur respectivement. Plus gnralement, une interaction montre le comportement dun classeur tel quun sous-systme, un cas dutilisation, une classe, un composant, etc.
PiloteAutomatique Voiture Moteur

Figure 3.1
Diagramme de classes dun systme de pilotage automatique.

dmarrer()

allumer()

Figure 3.2
Diagramme de communication dun systme de pilotage automatique.

com Piloter dmarrer unPilote : PiloteAutomatique uneVoiture : Voiture allumer leMoteur : Moteur

Dnition
Une interaction dcrit le comportement dun classeur en se focalisant sur lchange dinformations entre les lments du classeur. Les participants une interaction sont appels lignes de vie . Une ligne de vie reprsente un participant unique une interaction.

Le terme ligne de vie est utilis car, souvent, les interactions montrent des objets (instances de classes). Au cours dune interaction, des objets peuvent tre crs, utiliss, et parfois dtruits. Ce cycle de vie des objets est matrialis par une ligne (la ligne de vie) qui court dans les diagrammes dinteraction (gure 3.3). UML propose principalement deux diagrammes pour illustrer une interaction : le diagramme de squence et celui de communication. Une mme interaction peut tre reprsente aussi bien par lun que par lautre.

86

UML 2

Chapitre

EXEMPLE

Le diagramme de squence de la gure 3.3 et le diagramme de communication de la gure 3.2 reprsentent la mme interaction.
sd Piloter unPilote : PiloteAutomatique sens du temps dmarrer allumer uneVoiture : Voiture leMoteur : Moteur

Figure 3.3
Un diagramme de squence la place dun diagramme de communication.

ligne de vie

Diagrammes de squence et de communication peuvent reprsenter la mme interaction, mais le point de vue est diffrent. Un diagramme de squence met laccent sur le squencement temporel des messages (le temps y gure implicitement et scoule de haut en bas) ; en revanche, le lien qui unit les lignes de vie, et qui est le vecteur du message, ny gure pas (alors quil est prsent sur un diagramme de communication).

Dnition
Les diagrammes de communication et de squence reprsentent des interactions entre des lignes de vie. Un diagramme de squence montre des interactions sous un angle temporel, et plus particulirement le squencement temporel de messages changs entre des lignes de vie, tandis quun diagramme de communication montre une reprsentation spatiale des lignes de vie.

Remarque
Aux diagrammes de squence et de communication sajoute un troisime type de diagramme dinteraction : le diagramme de timing. Son usage est limit la modlisation des systmes qui sexcutent sous de fortes contraintes de temps, comme les systmes temps rel. Cependant, mme dans ces situations extrmes, les diagrammes de squence conviennent bien souvent. Cest la raison pour laquelle les diagrammes de timing ne sont pas abords dans cet ouvrage. Le lecteur intress trouvera dans le manuel de rfrence dUML 2.0 [Rumbaugh 2004] des explications sur le sujet.

Notation
Un diagramme dinteraction se reprsente par un rectangle (gure 3.4) contenant, dans le coin suprieur gauche, un pentagone accompagn du mot-cl sd lorsquil sagit dun diagramme de squence, et de com lorsquil sagit dun diagramme de communication. Le mot-cl est suivi du nom de linteraction. La liste des lignes de vie qui gurent dans le diagramme peut suivre le nom de linteraction. Des attributs peuvent tre indiqus prs du sommet du rectangle contenant le diagramme. La syntaxe de ces attributs est la mme que celle des attributs dune classe (voir chapitre 2). Une ligne de vie se reprsente par un rectangle auquel est accroche une ligne ver ticale pointille. Le rectangle contient un identiant dont la syntaxe est la suivante :
[<nomDeLaLigneDeVie> [[slecteur]]]: <NomDeClasseur> [dcomposition]

o le slecteur permet de choisir un objet parmi n (par exemple objet[2]).

Diagramme dinteraction 87

Figure 3.4
Un diagramme de squence dun distributeur de billets.
Attribut de linteraction

Contrainte sur la valeur de lattribut

Ligne de vie

sd Retrait argent lifelines :Client, :Distributeur, :Banque +code : integer { readonly 1000 <= code <= 9999 }

: Distributeur Client introduireCarte

comBanque : Reseau

affichercranSaisieCode

saisieCode( code )

vrifierCode( code ) banqueOK = vrifierCode( _ )

1.1 UTILISATION

DES INTERACTIONS

Les diagrammes dinteraction sont utiliss tout au long du cycle de vie dun projet (depuis le recueil des besoins jusqu la phase de conception). Ils servent dcrire les cas dutilisation dans les phases en amont, modliser la mise en uvre dune classe ou dune opration dune classe et, plus gnralement, ajouter un aspect dynamique la modlisation dun systme. Le diagramme de classes modlise avant tout le domaine dans lequel le systme sera utilis ; ce domaine, celui dune banque par exemple, est relativement indpendant des applications bancaires qui viennent se greffer dessus ; limplmentation dun diagramme de classes nest quune base de dveloppement pour des applications ; ce qui caractrise une application, cest la faon dont elle utilise le diagramme de classes, ou plus prcisment, comment des instances des classes interagissent pour raliser les fonctionnalits de lapplication ; sans cet aspect dynamique, un systme serait purement statique et noffrirait aucune fonctionnalit. Lapproche objet du dveloppement dun systme recommande une conception modulaire (de sorte que les parties du systme soient rutilisables). Le langage de modlisation doit permettre la reprsentation de cette modularit. Il nest pas souhaitable de faire gurer toutes les interactions sur un seul diagramme. Le modlisateur doit pouvoir focaliser son attention sur un sous-ensemble dlments du systme et tudier leur faon dinteragir pour donner un comportement particulier au systme. UML permet de dcrire un comportement limit un contexte prcis de deux faons : dans le cadre dun classeur structur ou dans celui dune collaboration.

Interactions dans les classeurs structurs


La structure imbrique dun classeur structur limite les interactions possibles entre ses parties, chacune delles ne pouvant appartenir un autre classeur structur (voir lannexe B pour de plus amples informations).

88

UML 2

Chapitre

EXEMPLE

Considrons une classe qui est dcompose pour montrer sa structure inter ne (gure 3.5) : une classe Moteur est compose des classes Allumage et Bougie. Un diagramme de squence montre comment les bougies et lallumage interagissent pour dmarrer le moteur.
Moteur sd allumer moteur interaction boucle pour allumer les bougies : Allumage loop( 1,4) bougie [ i ] : Bougies allumer

Figure 3.5
Un diagramme de squence pour illustrer le comportement interne dune classe.

structure interne de la classe

: Allumage

1..4

: Bougies

Les classeurs structurs sont surtout utiliss dans la phase de conception dun systme, quand on dtermine la faon dont il va tre ralis. Le concepteur prend pour point de dpart les classeurs mis en vidence au moment de lanalyse ; il dcide de leur structure interne et illustre ventuellement leur comportement par des interactions. Les classeurs ainsi structurs sont repris par les dveloppeurs qui implmentent une solution.

Interactions dans le cadre dune collaboration


Les parties de la structure interne dun classeur structur sont cres ds que le classeur est instanci. Leur dure de vie est celle de linstance du classeur. Parfois, des instances existent avant dtre utilises. Elles peuvent tre runies temporairement, le temps de collaborer la ralisation dune certaine fonctionnalit dun systme. Une fois leur rle jou, leur tche sachve et la runion est dissoute. Certaines instances devenues obsoltes sont dtruites, dautres libres jusqu leur prochaine utilisation. Ce type de runion dinstances est une collaboration.

Dnition
Une collaboration montre des instances qui collaborent dans un contexte donn pour mettre en uvre une fonctionnalit dun systme.

EXEMPLE

La gure 3.6 montre une collaboration entre instances pour raliser une transaction immobilire.

Notation
Une collaboration se reprsente par une ellipse en trait pointill comprenant deux compartiments. Le compartiment suprieur contient le nom de la collaboration ayant pour syntaxe :
<nomDuRle>[: <NomDuType>][multiplicit]

Le compartiment infrieur montre les participants la collaboration.

Diagramme dinteraction 89

Figure 3.6
Diagramme de collaboration dune transaction immobilire.
venteImmobilire

acqureur : Personne

contratVente : Transaction

propritaire : Personne

notaire : Notaire connecteur

Comme dans les classeurs structurs, des connecteurs relient les instances dune collaboration. Un connecteur reprsente souvent une association transitoire (tablie le temps que dure la collaboration concrtement, ce peut tre largument dune mthode, une variable locale, une association).

Notation
Une collaboration peut aussi se reprsenter par une ellipse sans compar timent, portant le nom de la collaboration en son sein (gure 3.7). Les instances sont relies lellipse par des lignes qui portent le nom du rle de chaque instance.

Figure 3.7
Reprsentation possible dune collaboration.
Personne propritaire acqureur notaire Notaire venteImmobilire contratVente Transaction

Les interactions au sein dune collaboration peuvent tre reprsentes par un diagramme dinteraction comme le montre la gure 3.8.

Figure 3.8
Un diagramme de squence pour illustrer une collaboration.

sd venteImmobilire notaire : Notaire contratVente : Transaction propritaire : Personne acqureur : Personne

tablir signer signer

90

UML 2

Chapitre

(2)

Diagramme de squence en dtail


Les principales informations contenues dans un diagramme de squence sont les messages changs entre les lignes de vie. Un message dnit une communication particulire entre des lignes de vie. Plusieurs types de messages existent. Les plus communs sont : lenvoi dun signal ; linvocation dune opration ; la cration ou la destruction dune instance. Lenvoi dun signal dclenche une raction chez le rcepteur, de faon asynchrone et sans rponse : lmetteur du signal ne reste pas bloqu le temps que le signal parvienne au rcepteur et il ne sait pas quand, ni mme si le message sera trait par le destinataire. Un exemple typique de signal est une interruption (lorsque des donnes sont saisies au clavier dun ordinateur par exemple, le processeur reoit un signal lectrique dinterruption lui donnant lordre de lire les donnes du clavier, mais la lecture ne bloque pas le clavier). Plus encore que lenvoi dun signal, linvocation dune opration est le type de message le plus utilis en programmation objet. Si, par exemple, une classe C possde une opration op, linvocation se fait par c.op(), o c est une instance de la classe C. Linvocation peut tre synchrone (lmetteur reste bloqu le temps que dure linvocation de lopration) ou asynchrone. Dans la pratique, la plupart des invocations sont synchrones. Une des techniques utilises pour raliser une invocation asynchrone consiste crer un thread (un thread est un ot dexcution parallle) et excuter la mthode associe lopration dans ce thread. Pour UML, lenvoi dun signal ou linvocation dune opration sont deux sortes de messages qui se reprsentent de la mme faon. Par contre, UML fait la diffrence entre un message synchrone et un message asynchrone.

Notation
Un message synchrone se reprsente par une che lextrmit pleine qui pointe sur le destinataire du message (gure 3.9). Ce message peut tre suivi dune rponse qui se reprsente par une che en pointill. Un message asynchrone se reprsente par une che lextrmit ouverte (gure 3.10). La cration dun objet est matrialise par une che qui pointe sur le sommet dune ligne de vie (gure 3.11). La destruction dun objet est matrialise par une croix qui marque la n de la ligne de vie de lobjet (gure 3.12).

Figures 3.9 et 3.10


Reprsentation dun message synchrone (3.9) et dun message asynchrone (3.10).

Figures 3.11 et 3.12

nouvelObjet : Classe

Reprsentation de la cration (3.11) et destruction (3.12).

Lmetteur dun message asynchrone ntant pas bloqu le temps que le message parvienne au rcepteur, une srie de messages peut tre envoye avant quun seul ne soit reu. De plus, les messages peuvent tre reus dans un ordre diffrent de lordre denvoi.

Diagramme dinteraction 91

EXEMPLE

La gure 3.13 montre une communication sur un rseau dordinateurs (cer tains protocoles de communication tel UDP ne garantissent pas lordre darrive des messages).
sd communication sur un rseau dordinateurs : Client : Serveur

Figure 3.13
Messages asynchrones reus dans un ordre diffrent de lordre denvoi.

question

question

2.1 MESSAGE

ET VNEMENTS

Linvocation dune opration ou lenvoi dun signal peut dclencher une raction chez le rcepteur. La raction la plus courante est lexcution dune mthode (rappel : une mthode est limplmentation dune opration). Ce nest cependant pas la seule raction possible. Par exemple, un signal derreur (souvent appel exception ) peut tre interprt comme une simple alerte qui ne dclenchera pas ncessairement lexcution dune mthode. Mme dans le cas de linvocation dune opration, il nest pas vident que linvocation soit suivie de lexcution dune mthode : dans les middlewares objets qui forment aujourdhui lossature des systmes dinformations des entreprises, des objets sont rpartis sur un rseau dordinateurs ; linvocation se fait donc distance et des erreurs de transmission peuvent empcher le message dinvocation darriver au rcepteur. UML permet de sparer clairement lenvoi du message de sa rception, ainsi que le dbut de lexcution de la raction de sa n. Des vnements sont utiliss pour marquer chaque tape. Ainsi, la transmission dun message est contrle par loccurrence de deux vnements : un pour lenvoi et un pour la rception.
EXEMPLE
La gure 3.14 montre un diagramme dinteraction o un message envoy provoque lexcution dune mthode chez le rcepteur.
sd Retrait argent

Figure 3.14
Diagramme de squence o gurent, pour explication, les occurrences dvnement.

: Distributeur vnement denvoi Client introduireCarte

vnement de dbut dexcution

vnement de rception

vnement de fin dexcution

92

UML 2

Chapitre

Notation
La spcication de lexcution dune raction se fait par un rectangle blanc ou gris plac sur la ligne de vie (gure 3.14). Autre notation : un rectangle portant un label.

EXEMPLE

La gure 3.15 spcie diffremment lexcution de la raction dcrite la gure 3.14.


sd Retrait argent

Figure 3.15
Autre spcication dune excution.

: Distributeur vnement de rception vnement denvoi

introduireCarte

vnement de dbut dexcution vrifierCarte vnement de fin dexcution

Grce aux vnements denvoi et de rception, UML dnit trois types de messages : Un message complet est tel que les vnements denvoi et de rception sont connus. Un message perdu est tel que lvnement denvoi est connu, mais pas lvnement de rception. Un message trouv est tel que lvnement de rception est connu, mais pas lvnement dmission. Ces diffrents messages se reprsentent de la faon suivante.

Notation
Un message complet se reprsente par une simple che dirige de lmetteur vers le rcepteur. Un message perdu se reprsente par une che qui pointe sur une boule noire (gure 3.16). Une che qui part dune boule noire symbolise un message trouv (gure 3.17).

Figure 3.16
Reprsentation dun message perdu.

Figure 3.17
Reprsentation dun message trouv.

Diagramme dinteraction 93

2.2 SYNTAXE

DES MESSAGES
UML permet de modliser tout type de systme. Mais bien souvent, les implmentations se font via des langages de programmation. Dans la plupart des cas, la rception dun message est suivie de lexcution dune mthode dune classe. Cette mthode peut recevoir des arguments et la syntaxe des messages permet de transmettre ces arguments.

Notation
La syntaxe des messages est :
<nomDuSignalOuDeOpration> [( [<argument>, )]

o la syntaxe des arguments est la suivante :


[ <nomDeParamtre> = ] <valeur de largument>

Par dfaut, les paramtres transmis ne peuvent pas tre modis par le rcepteur (les arguments sont en entre ). Pour indiquer que des paramtres peuvent tre modis (argument en sortie ou en entre/sortie ), il faut crire :
<nomDuParamtreEnSortie> [: <valeur de largument> ]

Quand un message doit transmettre uniquement la valeur des arguments, le caractre - peut tre utilis en lieu et place de nimporte quel argument pour signier : valeur indnie. Le caractre * peut tre utilis en lieu et place du message complet. Il signie que tout type de message est accept.
EXEMPLE
Appeler( "Capitaine Hadock", 54214110 ) afficher( x, y ) initialiser( x = 100 ) est un message dont largument en entre reoit la valeur 100. f( x:12 ) est un message avec un argument en entre/sortie x qui prend initialement la valeur 12. appeler( "Castafiore", - )

Le rcepteur du message peut aussi vouloir rpondre et transmettre un rsultat via un message de retour.

Notation
La syntaxe de rponse un message est la suivante :
[<attribut> =] message [: <valeur de retour> ]

o message reprsente le message denvoi.

EXEMPLE

La gure 3.18 montre un message de rponse signalant que quarante-deux occurrences de la rfrence Tintin gurent dans une mdiathque.

94

UML 2

Chapitre

Figure 3.18
Exemple dun message de rponse.
sd Rechercher livre

Contrainte sur les valeurs dun attribut

+nombreLivres : integer { nombreLivres >= 0 } : Mdiathque Client chercher( "Tintin" ) nombreLivres = chercher( "Tintin" ) : 42

2.3 CONTRAINTES

SUR LES LIGNES DE VIE

La gure 3.18 contient un attribut, nombreLivres, auquel est accole une contrainte qui limite les valeurs possibles du nombre de livres. Les lignes de vie dune interaction peuvent aussi porter toutes sortes de contraintes. Si la ligne de vie est un objet par exemple, une contrainte sur la valeur dun attribut peut tre pose.
EXEMPLE
La gure 3.19 montre que, pour dmarrer le moteur dun avion, il est impratif de vrier le niveau dessence ; aprs vrication lattribut essence doit avoir une valeur suprieure 0.
sd Piloter Avion : Pilote : Avion dmarrerMoteur() Oprateur dassertion qui rend indispensable lenvoi du message vrifierEssence (voir le paragraphe ci-dessous sur les fragments combins) assert vrifierEssence() { Avion.essence > 0 }

Figure 3.19
Exemple dune contrainte sur une ligne de vie.

contrainte

dcoller()

Notation
Une contrainte est indique sur une ligne de vie par un texte entre accolades. Une contrainte peut aussi tre contenue dans une note attache loccurrence de lvnement sur lequel elle agit.

Une contrainte est value au cours de lexcution de linteraction. Si la condition de la contrainte nest pas vrie, les occurrences dvnement qui suivent cette contrainte sont considres comme invalides, alors quune contrainte qui se vrie rend valides les vnements suivre. Ainsi, la gure 3.19, si la quantit dessence est nulle, dcoller devient un message invalide.

Diagramme dinteraction 95

Remarque
Un diagramme dinteraction peut dcrire des messages non valides, cest--dire qui ne doivent absolument pas tre envoys : dans le cas de la modlisation dune centrale nuclaire par exemple, il est trs important de prvoir les squences des messages invalides.

2.4 FRAGMENTS DINTERACTION

COMBINS

Les langages de programmation sont limits par leur syntaxe. Certes, ils permettent dcrire des tests et des boucles trs simplement. Par contre, crire un programme avec des ots dinstructions devant sexcuter en parallle nest pas simple (il faut crire des instructions pour crer, soit des tches, soit des threads, puis utiliser dautres instructions pour synchroniser les ots dinstructions). UML, sans tre un langage de programmation, propose une syntaxe qui se veut complte. Quand le modlisateur doit reprsenter une situation complexe, UML permet de dcomposer une interaction en fragments sufsamment simples pour les faire tenir sur un schma. La combinaison des fragments permet de reconstituer la complexit du systme. Le terme gnrique en vigueur pour UML est fragments combins .
EXEMPLE
La gure 3.20 montre comment reprsenter, laide dUML, lquivalent du test des langages de programmation.
sd Retrait argent

Figure 3.20
Reprsentation dun choix dans un diagramme de squence.

: Client

: Distributeur condition du choix

choixTypeRetrait ( EurosOuDollards ) Oprateur dinteraction alt [ EurosOuDollards == Euros ]

affichercranEnFranais Sparateur doprandes [ else ] affichercranEnAnglais

Notation
Un fragment combin se reprsente de la mme faon quune interaction : par un rectangle dont le coin suprieur gauche contient un pentagone. Dans le pentagone gure le type de la combinaison (appel oprateur dinteraction ).

la gure 3.20, loprateur dinteraction alt indique que le fragment est un choix. Les deux options de choix sont appeles oprandes de loprateur alt .

96

UML 2

Chapitre

Notation
Les oprandes dun oprateur dinteraction sont spars par une ligne pointille. Les conditions de choix des oprandes sont donnes par des expressions boolennes entre crochets. La liste suivante regroupe les oprateurs dinteraction par fonctions : les oprateurs de choix et de boucle : alternative, option, break et loop ; les oprateurs contrlant lenvoi en parallle de messages : parallel et critical region ; les oprateurs contrlant lenvoi de messages : ignore, consider, assertion et negative ; les oprateurs xant lordre denvoi des messages : weak sequencing, strict sequencing.

EXEMPLE

La gure 3.21 montre comment une boucle peut tre reprsente. Lexemple illustre la fermeture en boucle de toutes les portes dun train.

Notation
La syntaxe dune boucle est la suivante :
loop [( <minint> [, <maxint> ] ) ]

o la boucle est rpte au moins minint fois avant quune ventuelle condition boolenne ne soit teste (la condition est place entre crochets sur la ligne de vie) ; tant que la condition est vraie, la boucle continue, au plus maxint fois (minint est un entier suprieur ou gal 0, maxint est un entier suprieur ou gal minit). loop( valeur ) est quivalent loop( valeur, valeur ). loop est quivalent loop ( 0, * ), o * signie illimit .

Figure 3.21
Diagramme de squence montrant une boucle.

sd Dmarrer train

: Conducteur

: Train porte[ i ] : Porte

fermerPortes()

loop(1, n)

fermer()

Loprateur par permet denvoyer des messages en parallle. Ses oprandes se droulent en parallle. Plus prcisment, les vnements qui jalonnent un oprande (lenvoi du message, la rception du message) forment une trace. Soumise loprateur par, la trace dun oprande est conserve (lordre des vnements est le mme), mais les diffrentes traces des diffrents oprandes sentrelacent nimporte comment. En consquence, la trace nale, obtenue par la fusion des traces des oprandes, peut varier dun droulement lautre. La gure 3.22 montre un exemple.

Diagramme dinteraction 97

Les oprateurs ignore et consider permettent de focaliser lattention du modlisateur sur une partie des messages qui peuvent tre envoys durant une interaction. Quand de nombreux messages sont possibles, certains sont importants, dautres moins. Le modlisateur peut choisir de ne pas tenir compte de tous les messages. Pour un systme en phase de test par exemple, de nombreux messages servent tester exhaustivement le bon fonctionnement du systme mais ne seront pas mis lors dune utilisation particulire (quand le systme sera en production). Loprateur ignore dnit lensemble des messages ignorer, tandis que loprateur consider dnit lensemble de ceux quil faut prendre en compte. la gure 3.23, un oprateur assert sapplique au message fermer. Ce message doit imprativement tre envoy avant que le train puisse dmarrer.

Figure 3.22
Utilisation de loprateur par.

sd :A :B

par a

oprandes qui se droulent en parallle

EXEMPLE

La gure 3.23 est un exemple dutilisation des oprateurs assert, ignore et consider.
sd Dmarrer train, ignore { testerMoteur }, consider{ fermer, dmarrer }

Figure 3.23
Utilisation des oprateurs ignore, consider et assert.

: Conducteur assert fermer()

: Portes

: Moteur

dmarrer()

Notation
La syntaxe de loprateur ignore est :
ignore { listeDesNomsDesMessagesIgnorer }

La syntaxe de loprateur consider est :


consider { listeDesNomsDesMessagesConsidrer }

Dans les listes, les messages sont spars par des virgules.

98

UML 2

Chapitre
Loprateur strict sequencing impose que ses oprandes se droulent dans lordre strict de leur prsentation, cest--dire de haut en bas. Lordre impos ne sapplique qu ses oprandes, et dventuels fragments imbriqus peuvent avoir, en interne, un squencement quelconque.
EXEMPLE
La gure 3.24 illustre un scnario de dcollage dun avion qui utilise loprateur strict sequencing. Avant de faire dcoller un avion, il faut contrler sa ckeck-list. Le dtail des interactions pour contrler la check-list et pour faire dcoller lavion nest pas donn. Dautres diagrammes rfrencs sous le label ref sen chargent.
sd Dcollage dun avion : TourDeContrle : Pilote : Avion

Figure 3.24
Droulement des oprandes dun oprateur dans un ordre strict.

strict

ref Contrler check list

ref Procdure de dcollage

2.5 DCOMPOSITION DUNE

LIGNE DE VIE

Parfois, une interaction est trop complexe pour tre dcrite sur un seul diagramme. UML permet de dcomposer volont une ligne de vie sur plusieurs diagrammes.
EXEMPLE
Lexemple suivant modlise un contrle daccs pour entrer dans un btiment. La ligne de vie SystmeContrleAccs a un comportement complexe dcrit sur un diagramme spar : SystmeContrleAccsUtilisateur (gure 3.26).

Notation
Une dcomposition est rfrence dans le rectangle en tte de ligne de vie, sous le label ref (gure 3.25). la gure 3.26, la ligne de vie PointDAccs est dcompose en deux lignes p1 et p2. Cette notation est une autre manire de dcomposer une ligne de vie dans un diagramme dinteraction.

On remarque la gure 3.26, la prsence dun message entrant vrifier( code ) et dun message sortant message( "Entrez!" ) ; ces messages entrent et sortent du diagramme par un point appel porte . Ces mmes messages sont prsents sur le diagramme de la gure 3.25.

Diagramme dinteraction 99

Dnition
Une porte est un point de connexion qui permet de relier un mme message reprsent par des ches diffrentes dans plusieurs fragments dinteraction.

Figure 3.25
Dcomposition dune ligne de vie.
sd vrifier accs

Ligne de vie dcompose sur la figure 3.26

+code : integer { 1000 <= code <= 9999 } : SystmeContrleAccs ref SystmeContrleAccsUtilisateur vrifier( code ) ref VrifierAccs( code )

: Utilisateur

Rfrences des diagrammes existants

ref message( "Entrez !" ) ref OuvrirPorte

[ code ok ]

Figure 3.26
Ligne de vie dcompose.

sd SystmeContrleAccsUtilisateur +PointDAccs.code : integer { 1000 <= code <= 9999 } : PointDAccs Autre notation pour la dcomposition p1 vrifier( code ) ref SystmeVrifierAccs( code ) portes opt [ code ok ] message( "Entrez !" ) opt SystmeOuvrirPorte P2 : Contrleur

100

UML 2

Chapitre

2.6 LES

TATS INVARIANTS
Une ligne de vie peut aussi reprsenter un classeur ayant un comportement complexe. Cest le cas des instances de classes qui peuvent tre dans plusieurs tats (voir chapitre 4). Il est possible de placer un certain tat dune machine tats sur une ligne de vie.

Dnition
Un tat est dit invariant lorsquil reste constant sur une ligne de vie, cest--dire lorsquil ne change pas quel que soit le contexte dexcution de linteraction.

EXEMPLE

La gure 3.27 montre un tat plac sur une ligne de vie. Au moment de lexcution de linteraction, ltat est test conformment la machine tats spcie.
sd Piloter Avion : Avion contrler() : Pilote

Figure 3.27
Ajouter le contrle de ltat dune ligne de vie dans une interaction.

AvionPrtAuDcollage dcoller()

(3)

Diagramme de communication en dtail


Un diagramme de squence montre un squencement temporel des messages (le temps scoule de haut en bas). Par contre, lorganisation spatiale des participants linteraction napparat pas. Un diagramme de communication est un autre moyen de dcrire une interaction. Il rend compte des relations entre des lignes de vie qui communiquent. Il reprsente des interactions du point de vue spatial. Les diagrammes de communication servent le plus souvent illustrer un cas dutilisation ou dcrire une opration.

Diagramme dinteraction 101

EXEMPLE

Le diagramme de la gure 3.28 montre la mise en uvre dune opration (fermerPortes) qui permet de fermer toutes les portes dun train.

Figure 3.28
Un diagramme de communication pour illustrer la fermeture des portes dun train.

com Dmarrer train

fermerPortes() : Train

1 : fermerLesPortes()

connecteur

1.1 *[i :=1..n] : fermerPorte( i )

portes : Portes i

ligne de vie

numro de squence

itration

nom de rle

nom de classe

Un diagramme de communication contient des lignes de vie, linstar des diagrammes de squence : elles reprsentent toujours des participants uniques une interaction, mais les pointills qui matrialisaient leur dure de vie ont disparu.

Notation
Les lignes de vie sont reprsentes par des rectangles contenant une tiquette dont la syntaxe est :
<nomDuRle>: <NomDuType>

Au moins un des deux noms doit tre mentionn dans ltiquette (si le nom du rle est omis, le caractre : est obligatoire).

Le rle permet de dnir le contexte dutilisation de linteraction. Si la ligne de vie est un objet, celui-ci peut avoir au cours de sa vie plusieurs rles : une instance dune classe Personne peut jouer le rle dun tudiant dans un contexte donn, et devenir le conducteur dune voiture un autre moment. Les diagrammes de communication sont proches des diagrammes de classes auxquels ils ajoutent un aspect dynamique en montrant des envois de messages. Cependant, les relations entre les lignes de vie sont appeles connecteurs alors quelles se nomment associations dans les diagrammes de classes. Un connecteur se reprsente de la mme faon quune association mais la smantique est plus large : les associations qui gurent dans un diagramme de classes reprsentent des relations indpendamment de tout contexte, tandis que, pour un systme en tat de marche, il est possible de connecter ses lments de nombreuses faons : un objet par exemple, peut tre transmis comme un paramtre une procdure ou tre une variable locale.

102

UML 2

Chapitre
Les connecteurs peuvent montrer la multiplicit des lignes de vie qui participent une interaction, comme le montre la gure 3.29.

Figure 3.29
Reprsentation de la multiplicit dans un diagramme de communication.

com Dmarrer train

fermerPortes() : Train multiplicit fermerPorte() * porte : Porte

3.1 NUMROS

DE SQUENCE DES MESSAGES

Dans un diagramme de communication, les messages peuvent tre ordonns selon un numro de squence croissant. Quand plusieurs messages sont envoys en cascade (par exemple quand une procdure appelle une sous-procdure), ils portent un numro dembotement qui prcise leur niveau dimbrication. la gure 3.28, le message fermerLesPortes porte le numro 1 et dclenche le message fermerPorte qui porte le numro 1.1.

3.2 MESSAGES

ET FLOTS DEXCUTION PARALLLES

Il est possible denvoyer des messages simultanment dans des ots dexcution qui se droulent en parallle (dans les applications multitches ou multithreads, plusieurs ots dinstructions sexcutent en parallle et une mme mthode peut tre excute simultanment dans plusieurs ots). Les ots parallles sont dsigns par des lettres (a, b).
EXEMPLE
La gure 3.30 illustre le parcours dun arbre binaire : le message visiter est envoy aux deux ls (gauche et droit) dun nud pre ; ce message est transmis deux ots parallles portant les lettres a et b.
com Parcourir nud arbre visiter() pre : Nud

Figure 3.30
Envoi dun message dans des ots dexcution parallles.

1.a, 1.b : visiter() 2 fils : Nud

Diagramme dinteraction 103

3.3 OPRATEURS

DE CHOIX ET DE BOUCLE

Les diagrammes de squence permettent de reprsenter divers oprateurs (choix, boucle) dans des fragments combins. Il nest pas permis dutiliser les fragments combins dans un diagramme de communication. Malgr tout, des choix et des boucles peuvent y gurer selon une syntaxe particulire.

Notation
* [ <clause ditration> ] reprsente une itration (gure 3.28). La clause ditration peut tre exprime dans le format i := 1n. [ <clause de condition> ] reprsente un choix. La clause de condition est une condition boolenne.

3.4 SYNTAXE

DES MESSAGES

Notation
La syntaxe complte des messages est (voir les exemples ci-aprs) :
[ <numro_squence> ] [ <expression> ]: <message>

o message a la mme forme que dans les diagrammes de squence, numro_squence reprsente le numro de squencement des messages tel quil a t dni prcdemment et expression prcise une itration ou un embranchement.

EXEMPLE

2: affiche( x, y ) est un message simple. 1.3.1: trouve("Hadock" ) est un appel embot. 4 [x < 0]: inverse( x, couleur ) est un message conditionnel. 3.1 *[i:=1..10]: recommencer() reprsente une itration.

(4)

Rutilisation dune interaction


Une bonne pratique de lapproche objet consiste concevoir un systme en modules qui pourront tre extraits de leur contexte initial et rutiliss ailleurs. Un langage de modlisation doit permettre de prvoir la rutilisabilit. UML propose les diagrammes de composants pour dcomposer un systme en modules (voir lannexe C). un niveau de dtails plus n, il est possible de dcrire compltement une interaction une fois, puis de la rutiliser volont, en y faisant simplement rfrence. Les diagrammes de squence et les diagrammes de communication peuvent tre rfrencs.

EXEMPLE

La gure 3.31 montre le travail dun contrleur arien. Un pilote vrie la check-list de son avion (le diagramme correspondant appel contrlerCheckList nest pas dcrit en dtail mais simplement rfrenc). La check-list est transmise en argument car elle est utilise par linteraction contrlerCheckList. Cette interaction retourne un boolen qui est affect lattribut ok de lavion. Lorsque le contrleur demande contrler lavion, le boolen ok est test. Si lavion

104

UML 2

Chapitre
est prt partir, son plan de vol est valid ; dans le cas contraire, le plan de vol est invalid. Linteraction contrleAvion (dont le nom gure dans le pentagone en haut gauche du diagramme) reoit en argument une instance de CheckList. Cet argument est en entre/sor tie (inout) car il est utilis dans le diagramme et pourra ser vir encore dans un autre diagramme qui rfrencera contrleAvion. contrleAvion retourne un rsultat du type PlanDeVol. Linstance correspondante est la ligne de vie appele planDeVol dans le diagramme.

Figure 3.31
Utilisation dune interaction avec des arguments et une valeur de retour.

Argument en entre Rfrence une / sortie interaction existante sd contrleAvion( inout checkList : CheckList ) : PlanDevol +Avion.ok : boolen : Contrleur ref :Avion.ok = contrlerCheckList( checkList ) : Pilote : Avion

Instance du PlanDeVol retourne

checkList : CheckList

planDeVol

contrler() alt [ ok == true ] valider()

[ ok == false ] invalider()

Notation
Rutiliser une interaction consiste placer un fragment portant la rfrence ref l o linteraction est utile. La syntaxe complte pour spcier linteraction rutiliser est la suivante :
[ <nomAttributPourValeurRetour> =] <nom de linteraction> [( [<argument>], ) ] [: <valeur de retour> ]

La valeur de retour est affecte un attribut. Les arguments peuvent tre en entre (ils portent alors la marque in), en sortie (out), ou en entre et en sortie (inout).

Diagramme dinteraction 105

Conclusion
Les diagrammes de squence et de communication montrent laspect dynamique dun systme. Ce ne sont pas les seuls : les diagrammes dactivit et les diagrammes dtats-transitions, prsents aux chapitres suivants, dcrivent eux aussi un systme sous cet angle. Cependant, les diagrammes de squence et de communication sont mieux appropris la description des interactions entre les lments dun systme. Une interaction montre un comportement typique dun systme dans un contexte donn. Le contexte est dlimit par un classeur structur ou une collaboration. La vision du systme donne par les diagrammes dinteraction est donc partielle (car limite un contexte donn) mais cohrente (car elle montre comment un comportement dun systme est ralis par des lments qui le compose). Une interaction peut illustrer un cas dutilisation, le fonctionnement dun sous-systme, la mise en uvre dune classe ou dune opration. Les diagrammes dinteraction peuvent tre afns : les interactions dcouvertes lors des phases en amont du cycle de vie dun projet peuvent tre compltes par les modlisateurs. Chaque intervenant na pas les mmes exigences et nenvisage pas les mmes interactions de la mme faon. Malgr ces exigences diffrentes, il est important dassurer une continuit dans la modlisation. Les diagrammes dinteraction peuvent tre complts mesure que la modlisation progresse et ports un niveau de dtails requis pour limplmentation du systme. Diagrammes de squence et de communication peuvent dcrire une mme interaction mais de faons diffrentes. Le modlisateur a le choix : les diagrammes de squence montrent le squencement temporel de messages, tandis que les diagrammes de communication dcrivent la structure spatiale des participants une interaction. Arriv ce stade de la lecture du livre, et si vous avez parcouru les chapitres prcdents dans lordre, vous savez prsent comment construire les trois modles essentiels dun systme : le modle fonctionnel et externe laide du diagramme des cas dutilisation ; le modle structurel et interne grce au diagramme des classes ; le modle des interactions au sein du systme avec les diagrammes de squence et de communication. partir de l, vous pouvez passer directement au chapitre 6 pour voir sur une tude de cas comment tous ces modles sassemblent, ou continuer la lecture des chapitres suivants. Deux diagrammes supplmentaires y sont prsents : le diagramme dtats-transitions ; le diagramme dactivits. Les diagrammes dtats-transitions sont utiliss avant tout pour dcrire le cycle de vie des objets dun systme : tout objet est forcment cr un moment donn, utilis via les mthodes de la classe dont il est issu et, ventuellement, dtruit sil devient inutile. Les diagrammes dactivits sont des organigrammes. Ils montrent les ots de contrle qui grent les activits dun systme. Ils permettent de modliser tout processus squentiel (un processus de fabrication industriel, le fonctionnement dun systme dinformation, le corps dune opration).

106

UML 2

Chapitre

Problmes et exercices
Les diagrammes dinteraction reposent sur la transmission de messages. Avant dutiliser les interactions, il est ncessaire de matriser la syntaxe des messages, qui est riche et complexe. Parmi les premiers exercices, certains sont consacrs la syntaxe, dautres aux diffrents types de messages (synchrone, asynchrone, perdu, trouv). Plusieurs exercices montrent lquivalence entre les diagrammes de squence et de communication. Une fois ces notions de base matrises, vous pourrez raliser les exercices suivants, qui mettent en pratique les diagrammes dinteraction. Bien souvent, ces diagrammes sont utiliss pour ajouter un aspect dynamique au modle du diagramme de classes. Le lien entre diagramme de classes et diagramme dinteraction est illustr par des exercices, tout comme les autres utilisations des interactions (dcrire un cas dutilisation, une opration, le comportement dun classeur structur ou dune collaboration). Tout au long des exemples, il est fait appel aux fragments dinteraction combins, qui permettent denrichir les modles.

EXERCICE 1

SYNTAXE

DES MESSAGES

1. Expliquez la syntaxe des messages suivants extraits dun diagramme de squence :


f f( 0 ) f( x ) f( x = 0 ) f( y = x ) f( - ) f( x, y ) * y = f y = f( 0 ) y = f( x = 0 ) y = f( x ): 0

Diagramme dinteraction 107

Exercices

2. Expliquez la syntaxe des messages suivants extraits dun diagramme de communication :


f y:= f( x ) 1: f 1.1: f [x>0]: f *[x>0]: f *[i:=0..10]: f 1 *[i:=0..10]: f 1.a *[i:=0..10]: f

1. La plupart des messages portent f comme nom. f est un message sans argument. f( 0 ) est un message qui reoit en argument la valeur 0. f( x ) est un message qui reoit la valeur de x en argument. f( x = 0 ) est un message qui reoit un argument x ayant pour valeur 0. f( y = x ) est un message ayant un argument y qui prend la valeur de x. f( - ) est un message avec un argument non dni. f( x, y ) est un message qui reoit en arguments les valeurs de x et de y. * est un message de type quelconque. y = f est un message de rponse un message f ; la valeur de retour est affecte y. y = f( 0 ) est un message de rponse un message f( 0 ) ; la valeur de retour est affecte y. y = f( x = 0 ) est un message de rponse un message f( x = 0) ; la valeur de retour est affecte y. y = f( x ): 0 est un message de rponse un message f( x ) ; la valeur de retour 0 est affecte y. 2. La syntaxe des messages dans les diagrammes de communication est de la forme :
[<numroSquence>] [<expression>]: <message>

o message a la mme syntaxe et la mme signication que dans les diagrammes de squence. f est un message sans argument. y:= f( x ) est un message qui est suivi de lexcution chez le rcepteur dune raction (par exemple, linvocation dune opration) ; le rsultat de la raction est affect y. 1: f est un message sans argument qui porte le numro de squence 1. 1.1: f est un message embot sans argument qui porte le numro de squence 1.1. [x>0]: f est un message sans argument qui nest mis que si la condition x > 0 est vraie. *[x>0]: f est un message sans argument qui est mis tant que la condition x > 0 est vraie. *[i:=0..10]: f est un message sans argument qui est mis onze fois (pour i allant de 0 10). 1 *[i:=0..10]: f est un message sans argument, portant le numro de squence 1, qui est mis onze fois (pour i allant de 0 10). 1.a *[i:=0..10]: f est un message sans argument, portant le numro de squence 1, qui est mis onze fois (pour i allant de 0 10) dans un ot dexcution parallle identi par le caractre a.

108

UML 2

Chapitre

EXERCICE 2

AJOUTER

UN ASPECT DYNAMIQUE UN DIAGRAMME DE CLASSES

ET TRADUCTION DUN DIAGRAMME DE SQUENCE EN DIAGRAMME DE COMMUNICATION

Le diagramme de classes prsent la gure 3.32 modlise un robot qui dispose dun bras articul se terminant par une pince. Le fonctionnement du robot est le suivant : le robot dplie son bras, attrape la pice avec sa pince, replie son bras puis relche la pice.

Figure 3.32
Diagramme de classes dun robot.
Robot chercherPice BrasArticul Pince

dplier replier

ouvrir fermer

1. Reprsentez laide dun diagramme de squence lchange des messages entre les objets robot, brasArticul et pince. 2. Transformez le diagramme de squence en un diagramme de communication. 3. crivez en pseudo-code les classes Robot, BrasArticul et Pince.

1. Le diagramme de squence est prsent la gure 3.33. Le message chercherPice parvient au robot via une porte. Lmetteur du message est suppos apparatre dans un diagramme non reprsent ici. chercherPice entrane lenvoi des messages dplier et replier au bras articul. Conformment ce qui est stipul dans le rectangle spciant lexcution de la mthode dplier (respectivement replier), le message fermer (respectivement ouvrir) est envoy la pince.

Figure 3.33
Diagramme de squence du robot.

sd Attraper pice : Robot chercherPice porte replier ouvrir dplier fermer : BrasArticul : Pince

spcifications de lexcution des mthodes

2. Le diagramme de communication (gure 3.34) se dduit aisment du diagramme de squence prcdent (gure 3.33). Il faut cependant veiller numroter correctement les messages pour indiquer leur ordre denvoi : le premier message, chercherPice, porte le numro 1 ; le message suivant, dplier, est embot dans le message chercherPice et porte

Diagramme dinteraction 109

Exercices

en consquence le numro 1.1 ; le message fermer (numro 1.1.1) est embot dans le message dplier. Le mme raisonnement a permis de numroter les messages replier et ouvrir.

Figure 3.34
Diagramme de communication quivalent au diagramme de squence de la gure 3.33.

com Attraper pice 1 : chercherPice() : Robot 1.2 : replier 1.1 : dplier : BrasArticul 1.1.1 : fermer 1.2.1 : ouvrir : Pince

3. Le pseudo-code montre que lobjet brasArticul est inclus dans la partie des attributs de la classe Robot. Cest la faon la plus courante dimplmenter une relation de composition : le robot est compos dun bras articul. Il en est de mme des classes BrasArticul et Pince.
class Robot{ prive: BrasArticul brasArticul; publique: void chercherPice(){ brasArticul.dplier(); brasArticul.replier(); } } class BrasArticul { prive: Pince pince; publique: void dplier (){ pince.fermer(); } void replier (){ pince.ouvrir(); } } class Pince { prive: publique: void fermer (){ }

/* objet brasArticul (instance de la classe BrasArticul) */

/* appel de la mthode dplier de lobjet brasArticul */ /* appel de la mthode replier de lobjet brasArticul */

/* objet pince (instance de la classe Pince) */

/* instructions pour dplier le bras */ /* fermeture de la pince pour attraper la pice */

/* instructions pour replier le bras */ /* ouverture de la pince pour relcher la pice */

/* instructions pour fermer la pince */

110

UML 2

Chapitre
void ouvrir (){ } } Dbut programme principal Robot robot; robot.chercherPice(); Fin programme principal

/* instructions pour ouvrir la pince */

/* cration dun objet robot (instance de la classe Robot) */ /* appel de la mthode chercherPice de la classe Robot */

Remarque
Les associations sont souvent implmentes comme des attributs. Il ne faut cependant pas confondre les deux (voir chapitre 2). Malheureusement, de nombreux langages de programmation ne permettent pas de faire la distinction. Lannexe E donne des indications pour implmenter un modle objet avec le langage de programmation Java.

EXERCICE 3

MESSAGES

SYNCHRONES VS MESSAGES ASYNCHRONES

Compltez les messages des gures 3.35 3.39 en choisissant le type de message appropri (synchrone ou asynchrone). 1. Envoi dun message pour calculer la valeur de la constante pi avec 3 dcimales.

Figure 3.35
Calcul de Pi avec 3 dcimales.
: ProgrammePrincipal : FonctionDeCalculDePi

Envoi du message Message de rponse

calculerPI( nombreDcimales = 3 ) PI = calculerPI( nombreDcimales = 3 )

2. Envoi dun message pour calculer la valeur de pi avec 3 000 dcimales.

Figure 3.36
Calcul de pi avec 3 000 dcimales.
: ProgrammePrincipal : FonctionDeCalculDePi

Envoi du message Message de rponse

calculerPI( nombreDcimales = 3000 ) PI = calculerPI( nombreDcimales = 3000 )

Diagramme dinteraction 111

Exercices

3. Transmission dun courrier lectronique.

Figure 3.37
Transmission dun courrier lectronique.
: metteur transmettre( message ) : Destinataire

4. Transmission dun courrier lectronique via un serveur de messagerie qui rceptionne les messages et les conserve le temps que le destinataire les rcupre.

Figure 3.38
Transmission dun courrier lectronique via un serveur de messagerie.
: metteur : ServeurDeMessagerie poster( message ) message = rcuprer : Destinataire

5. Transmission dun courrier lectronique deux destinataires.

Figure 3.39
Transmission dun courrier deux destinataires.
: metteur destinataire1 : Destinataire destinataire2 : Destinataire transmettre( message ) transmettre( message )

1. On considre que le programme principal est actif tout le temps. Le calcul de pi avec 3 dcimales ne doit pas prendre beaucoup de temps. Le programme principal peut donc tre bloqu par un appel synchrone de la mthode calculerPI le temps deffectuer le calcul (gure 3.40).

Figure 3.40
Calcul de Pi avec 3 dcimales utilisant un message synchrone.
objet actif

objet actif : ProgrammePrincipal : FonctionDeCalculDePi

calculerPI( nombreDcimales = 3 ) PI = calculerPI( nombreDcimales = 3 ) objet passif

112

UML 2

Chapitre

Remarque
La tte de la ligne de vie ProgrammePrincipal contient deux traits ver ticaux qui indiquent que lobjet est actif. Le double trait qui court tout au long de la ligne de vie indique aussi un objet actif. Ces deux notations prsentes simultanment sont redondantes. Dans un diagramme de squence, les deux traits verticaux dans la tte de la ligne de vie sont superus, tandis que dans un diagramme de communication, comme aucun pointill nindique la dure de vie dun objet, ces deux traits sont indispensables (gure 3.48). Un objet actif possde son propre thread de contrle, cest--dire quon peut lui appliquer des mthodes dans un ot dexcution indpendant des autres ots dexcution existants. Un objet passif, au contraire, a besoin quon lui donne un ot de contrle pour lui appliquer une mthode.

2. Calculer Pi avec 3 000 dcimales peut prendre du temps. Dans ce cas, il vaut mieux utiliser un message asynchrone pour ne pas bloquer le programme principal le temps deffectuer le calcul (gure 3.41).

Figure 3.41
Calcul de Pi avec 3 000 dcimales utilisant un message asynchrone.

: ProgrammePrincipal

: FonctionDeCalculDePi

calculerPI( nombreDcimales = 3000 ) PI = calculerPI( nombreDcimales = 3000 )

3. La rception dun courrier lectronique peut se faire nimporte quand aprs lmission. Il ne faut donc pas bloquer lmetteur et utiliser un message asynchrone (gure 3.42).

Figure 3.42
Transmission asynchrone dun courrier lectronique.

: metteur transmettre( message )

: Destinataire

4. Lmetteur et le destinataire sont des objets actifs qui sont bloqus le temps denvoyer ou de rcuprer un courrier (gure 3.43).

Figure 3.43
Transmission synchrone dun courrier lectronique via un serveur de messagerie.

: metteur

: ServeurDeMessagerie

: Destinataire

poster( message )

message = rcuprer

5. Les transmissions sont asynchrones et les messages peuvent tre reus dans un ordre diffrent de lordre denvoi (gure 3.44).

Diagramme dinteraction 113

Exercices

Figure 3.44
Transmission dun courrier deux destinataires via des messages asynchrones.

: Destinataire

destinataire1 : Destinataire

destinataire2 : Destinataire

transmettre( message )

transme

ttre( me

ssage )

Remarque
La dure de transmission dun message peut tre indique en ajoutant des contraintes sur un diagramme, comme le montre la gure 3.45.

Figure 3.45
Contraintes de dure exprimes sur un diagramme.

: metteur
transmett re( mess age )

: Destinataire

{ < 1 jour }

d d { d - d < 1 jour }

transmettre( message ) transmettre( message )

EXERCICE 4

MESSAGES PERDUS, TROUVS DEXCUTION PARALLLES

OU ENVOYS DANS DES FLOTS

Compltez les messages des gures 3.46 et 3.47 en choisissant le type de message appropri (perdu, trouv ou sexcutant dans des ots dexcution parallles). 1. Demande dexcution de deux programmes par un systme dexploitation.

Figure 3.46
Demande dexcution de programmes.
: SystmeDExploitation excuter( programme = "lecteur CD" ) excuter( programme = "diteur de texte" ) : Processeur

2. Transmission dun virus un ordinateur.

Figure 3.47
Transmission dun virus un ordinateur.
virus : Virus : Ordinateur

114

UML 2

Chapitre
1. Si le systme dexploitation est considr comme multitche, lexcution des deux programmes se fait simultanment, dans deux ots dexcution parallles nots a et b.

Figure 3.48
Envoi simultan de deux messages.

objet actif

: SystmeDExploitation a : excuter( programme = "lecteur CD" ) b : excuter( programme = "diteur de texte" )

: Processeur

2 .La plupart du temps, un ordinateur contamin ne connat pas la source du virus et lauteur du virus ne souhaite pas tre connu, do lutilisation de messages perdu et trouv.

Figure 3.49
Utilisation de messages perdu et trouv.
: Virus : Ordinateur

diffuser( virus )

attraper( virus )

message perdu

message trouv

EXERCICE 5

FRAGMENTS DINTERACTION
COMPLEXE

COMBINS POUR DCRIRE UNE MTHODE

Le programme suivant, crit en pseudo-code, permet de calculer le factoriel dun nombre n:


int factoriel( int n ){ if( n == 0 ) return 1; return n * factoriel( n-1); }

o n 0 et factoriel( 0 ) = 1. Reprsentez le programme prcdent sur un diagramme de squence. La solution (gure 3.50) utilise loprateur alternative pour raliser le test sur la valeur de n. Notez aussi la superposition dune deuxime ligne de vie sur la premire pour matrialiser lappel rcursif de lopration factorielle. Le nom de la ligne de vie, X, est ctif.

Diagramme dinteraction 115

Exercices

Figure 3.50
Reprsentation du calcul de la fonction factorielle sur un diagramme de squence.

sd calcul dun factoriel +n : integer { n >= 0} +f : integer

:X factoriel( n)

alt factoriel( n)

[ n == 0 ]

[ else ] factoriel( n-1 ) appel rcursif f = factoriel( n-1 ) factoriel( n ) : n * f

EXERCICE 6

OPRATEURS DINTERACTION
Dessinez un diagramme de squence qui prsente trois objets : un robot + deux capteurs (une camra et un dtecteur de chocs). Le diagramme doit contenir un fragment dinteraction qui montre que les capteurs fonctionnent en mme temps (ils peuvent envoyer tout moment des messages au robot).

Figure 3.51
Utilisation de loprateur par pour un problme de robotique.

sd Dplacement dun robot

: Camra par

: Robot

: DtecteurChocs

analyserImage( image )

viterObstacle()

116

UML 2

Chapitre

Remarque
Avec loprateur par, la squence des vnements dun oprande peut tre interrompue par dautres occurrences dvnement venant dautres oprandes. cer tains moments, les interruptions sont malvenues. Si lon ajoute au robot un pilote et un moteur (gure 3.52), le pilote a un rle prpondrant et doit pouvoir tout moment demander larrt durgence du robot. La demande darrt doit tre imprativement suivie de larrt du moteur du robot. Loprateur critical est utilis pour dnir une section critique, cest--dire une rgion dune interaction o les traitements sont atomiques (raliss en un bloc inscable). Parfois, lentrelacement des vnements provenant de plusieurs oprandes nest pas souhaitable pour tous les participants (les lignes de vie) une interaction. Loprateur seq empche lentrelacement des occurrences dvnement sur une mme ligne de vie par tage par plusieurs oprandes (cest lordre des oprandes qui xe le squencement). Lentrelacement nest possible que sur des lignes de vie diffrentes non soumises loprateur seq.

Figure 3.52
Une rgion o les oprations sont atomiques.

sd Dplacement dun robot

: Pilote par

: Camra

: Robot

: Moteur

: DtecteurChocs

analyserImage( image )

viterObstacle()

critical arrterDUrgence()

arrter ()

EXERCICE 7

DIAGRAMMES

DE SQUENCE POUR ILLUSTRER DES CAS DUTILISATION

Le diagramme de cas dutilisation prsent la gure 3.53 modlise la gestion simplie dune bibliothque.

Figure 3.53

Bibliothcaire

Le fonctionnement de la bibliothque est le suivant : une bibliothque propose ses adhrents des uvres littraires ; les uvres peuvent tre prsentes en plusieurs exemplaires ; un adhrent peut emprunter jusqu trois livres.

Diagramme dinteraction 117

Exercices

Diagramme de cas dutilisation dune bibliothque.

Gestion des emprunts

1. crivez laide dun diagramme de squence un scnario nominal demprunt. 2. crivez laide de diagrammes de squence des scnarios demprunt alternatifs et dexceptions. 1. Pour dcrire un scnario dutilisation dun cas, il faut considrer le systme comme une bote noire et ne pas chercher montrer des objets au cur du systme. Rappel : un cas dutilisation est une grande fonction du systme vue par un acteur ; il ne faut donc pas faire gurer la structure interne dun systme (cest le rle du diagramme de classes). la gure 3.54, le systme est reprsent par une seule ligne de vie appele Bibliothque.

Figure 3.54
Description dun scnario nominal laide dun diagramme de squence.

sd gestion des emprunts

: Bibliothque Bibliothcaire rechercher un adhrent adhrent trouv vrifier si ladhrent peut emprunter ladhrent peut emprunter rechercher une uvre uvre trouve vrifier sil y a un exemplaire disponible pour cette uvre Il y a un exemplaire disponible dcrmenter le nombre dexemplaires dans la bibliothque attribuer lexemplaire ladhrent

Remarque
Quand un diagramme de squence dcrit un cas dutilisation, le formalisme strict dUML (la syntaxe des messages par exemple) est plus libre. La description dun scnario par un diagramme de squence nempche pas de dcrire le cas sous forme textuelle (voir chapitre 1), ce qui permet de faire gurer des renseignements supplmentaires (pr- et post-conditions, contraintes).

118

UML 2

Chapitre
2. Le diagramme de la gure 3.55 complte le diagramme prcdent (gure 3.54) en incluant la vrication de contraintes. Si une contrainte nest pas vrie, les vnements qui suivent cette contrainte sont invalides. De plus, la squence doit imprativement se terminer par les deux messages dcrmenter le nombre dexemplaires dans la bibliothque et attribuer lexemplaire ladhrent cause de lutilisation de loprateur assert.

Figure 3.55
Utilisation de contraintes et de loprateur assert dans un diagramme de squence.

sd gestion des emprunts

: Bibliothque Bibliothcaire rechercher ladhrent { adhrent trouv }

vrifier si ladhrent peut emprunter { adhrent peut emprunter }

rechercher une uvre { uvre trouve }

vrifier sil y a un exemplaire disponible pour cette uvre { exemplaire disponible }

assert dcrmenter le nombre dexemplaires dans la bibliothque attribuer lexemplaire ladhrent

Le formalisme des diagrammes de squence est trs riche. Souvent, il est possible de reprsenter des scnarios de plusieurs faons. Au lieu dutiliser des oprateurs dassertion, il est possible de recourir des oprateurs dalternative.

Diagramme dinteraction 119

Exercices

La gure 3.56 prsente une troisime solution qui utilise un oprateur doption (loprateur doption opt est identique un oprateur dalternative, mais avec un choix unique).

Figure 3.56
Utilisation des oprateurs opt et neg.

sd gestion des emprunts

: Bibliothque Bibliothcaire rechercher ladhrent

opt [ adhrent non trouv ] neg

vrifier si ladhrent peut emprunter rechercher une uvre

vrifier sil y a un exemplaire disponible pour cette uvre dcrmenter le nombre dexemplaires dans la bibliothque attribuer lexemplaire ladhrent

La gure 3.56 utilise loprateur negative pour indiquer que les messages sur lesquels il sapplique sont invalides.

EXERCICE 8

FRAGMENTS DINTERACTION

COMBINS

Construisez un diagramme de squence ayant trois lignes de vie : Conducteur, Train et Passager. Comment interdire aux passagers douvrir les portes quand le train a dmarr ? La solution utilise loprateur negative pour interdire louverture des portes (gure 3.57).

120

UML 2

Chapitre

Figure 3.57
Utilisation de loprateur negative pour interdire louverture des portes dun train.

sd Conduire Train : Conducteur dmarrer() neg ouvrirPorte() : Train : Passager

EXERCICE 9

DIAGRAMMES

DE SQUENCE POUR ILLUSTRER DES COLLABORATIONS

Lexercice 7 montre comment utiliser des diagrammes de squence pour dcrire des cas dutilisation. Lexercice 9 prolonge lexemple de la bibliothque en partant de lhypothse quun diagramme de classes a t construit (gure 3.58). Le but prsent est de montrer comment des objets au cur du systme interagissent pour raliser les fonctions des cas dutilisation. Le diagramme de classes prsent la gure 3.58 modlise la structure interne de la bibliothque. Un adhrent peut emprunter un exemplaire dune uvre donne. Lemprunt se fait de la faon suivante : lopration emprunter de la classe uvre est invoque pour un adhrent donn en argument ; sil reste des exemplaires dans la bibliothque, lun des exemplaires associs luvre est extrait via la mthode extraireExemplaire, une instance de la classe Prt est cre, puis lexemplaire extrait de la bibliothque est attribu ladhrent grce linvocation de lopration attribuer.

Figure 3.58
Diagramme de classes dune mdiathque.
Adhrent attribuer( Exemplaire ) Prt date Exemplaire 0..3 emprunte 1..n extraireExemplaire() : Exemplaire emprunter( Adhrent ) uvre

1. Parmi les classes du diagramme prcdent (gure 3.58), donnez la liste de celles qui permettent de raliser le comportement entour par un cercle dans le diagramme de squence prsent la gure 3.59.

Diagramme dinteraction 121

Exercices

Figure 3.59
Diagramme de squence de lemprunt dun livre.
sd gestion des emprunts

: Bibliothque Bibliothcaire rechercher un adhrent adhrent trouv vrifier si ladhrent peut emprunter ladhrent peut emprunter rechercher une oeuvre uvre trouve vrifier sil y a un exemplaire disponible pour cette uvre Il y a un exemplaire disponible dcrmenter le nombre dexemplaires dans la bibliothque attribuer lexemplaire ladhrent

2. Dessinez une collaboration montrant des instances des classes trouves la question 1. 3. Reprsentez les interactions au sein de la collaboration laide dun diagramme de squence.

1. Les classes impliques sont Exemplaire, uvre, Adhrent et Prt. La classe Prt nest pas mentionne dans le diagramme de squence, et pourtant elle est incluse dans la liste. Cest une classe dassociation prsente dans le diagramme de classes. Une instance de la classe Prt doit tre cre au moment de lemprunt. 2. Des instances des classes Exemplaire, uvre, Adhrent et Prt sont runies dans une collaboration (gure 3.60). Rappel : les liens entre les instances sont des connecteurs qui reprsentent des associations transitoires tablies le temps que dure la collaboration. Parmi les connecteurs, on retrouve les associations du diagramme de classes. En plus, un nouveau lien apparat entre les instances dAdhrent et duvre an de matrialiser la transmission dun adhrent comme argument de lopration emprunter de la classe uvre.

122

UML 2

Chapitre

Figure 3.60
Diagramme de collaboration pour lemprunt dun exemplaire.

Argument dune opration

Attribution dun exemplaire un adhrent

uvreTrouve : uvre adhrentTrouv : Adhrent : Prt associations exemplaireDisponible : Exemplaire

3 .Le diagramme de squence est prsent la gure 3.61. Linteraction est dcompose en fragments combins qui utilisent loprateur alternative : le choix porte sur la prsence ou non dun exemplaire disponible dans la mdiathque. Notez la cration dune instance de la classe Prt matrialise par un message qui pointe sur la tte de la ligne de vie.

Figure 3.61
Diagramme de squence pour lemprunt dun exemplaire.

sd AttributionExemplaireAAdhrent( inout adhrentTrouv : Adhrent, inout uvreTrouve : uvre ) +uvre.nombreExemplaires : integer { nombreExemplaires >= 0}

uvreTrouve: uvre emprunter( adhrentTrouv )

exemplaireTrouv : Exemplaire

adhrentTrouv : Adhrent

alt

[ nombreExemplaires > 0 ] extraireExemplaire() : Exemplaire : Prt attribuer( exemplaireTrouv )

emprunter : ok

[ else ] emprunter : non ok

Remarque

Diagramme dinteraction 123

Exercices

Le formalisme des diagrammes de squence est trs proche de celui des langages de programmation (on peut reprsenter aisment des tests, des boucles). Les diagrammes de squence sont principalement utiliss durant la phase danalyse. Cette tape ne doit pas tre confondue avec les phases de conception et dimplmentation. Durant lanalyse, les interactions servent souvent valider un diagramme de classes (en montrant comment des instances de classes interagissent). Veillez ne pas faire ce moment-l des choix de conception ou dimplmentation (voir chapitre 6).

La cration dune instance dans un diagramme de communication peut tre matrialise par une contrainte, comme le montre la gure 3.62. Les contraintes {dtruit} et {transitoire} peuvent tre places sur des liens ou sur des objets pour indiquer leur destruction ou bien quils sont temporaires.

Figure 3.62
Reprsentation de la cration dun objet et dun lien dans un diagramme de communication.

com emprunter emprunter() : uvre { nouveau }

: Prt

EXERCICE 10 RUTILISATION DUNE

INTERACTION

Le diagramme de squence de lexercice 9 (gure 3.61) reprsente la n du scnario nominal de lemprunt (partie entoure par un cercle dans le diagramme de la gure 3.59). Supprimez la partie encercle du scnario nominal et indiquez comment vous pouvez rutiliser le diagramme de squence de la gure 3.61 la place.

Figure 3.63
Diagramme de squence qui rfrence une interaction.

sd gestion des emprunts

: Bibliothque Bibliothcaire rechercher un adhrent adhrent trouv vrifier si ladhrent peut emprunter ladhrent peut emprunter rechercher une uvre uvre trouve

ref AttributionExemplaireAAdhrent( adhrentTrouv, uvreTrouve )

124

UML 2

Chapitre

EXERCICE 11 DIAGRAMMES

DE SQUENCE POUR ILLUSTRER LES INTERACTIONS DANS

UN CLASSEUR STRUCTUR

Au moment de la conception dun systme, le concepteur part du rsultat de lanalyse (qui a dni ce que doit faire le systme), et cherche comment raliser ce systme. Il procde par dcompositions successives des classes pour dnir les structures de donnes sousjacentes. Le but de cet exercice est dutiliser les classeurs structurs dUML pour dcomposer une classe, puis dillustrer les interactions entre les lments dun classeur structur par un diagramme de squence. Une le est une structure de donnes dans laquelle les donnes sont ajoutes la n et extraites partir du dbut. La le est modlise par une classe possdant les oprations ajouter et extraire (gure 3.64).

Figure 3.64
Une classe reprsentant une le.
File

ajouter( Donne ) extraire() : Donne

Un classeur structur peut tre utilis pour montrer la structure interne de la le (gure 3.65). Le concepteur choisit dimplmenter la le en recourant un tableau (une le est un tableau dans lequel on a restreint les accs aux deux extrmits). An de dcrire le comportement du tableau lors de lextraction dun lment, le concepteur dcide dutiliser une interaction appele Extraire de la le.

Figure 3.65
La le vue comme un classeur structur.
File ref Extraire de la file

: Tableau

Reprsentez linteraction Extraire de la le laide dun diagramme de squence. Indication : la faon la plus simple dextraire le premier lment dun tableau est de mmoriser la valeur de celui-ci avant de dcaler les lments suivants, comme le montre la gure 3.66.

Figure 3.66

mmoriser

Diagramme dinteraction 125

Exercices

Extraire le premier lment dun tableau.

La solution est prsente la gure 3.67, o une boucle est utilise pour raliser le dcalage. Les oprations add et get permettent dajouter et dextraire un lment du tableau.

Figure 3.67
Un diagramme de squence pour illustrer lextraction du premier lment dune le.

sd extraire de la file

premier : Exemplaire suivant : Exemplaire : File : Tableau

extraire() get( 0 ) premier = get( 0 loop(1, n) prcdent = get( 0 ) add(prcdent, i ) )

extraire() : premier

126

UML 2

Chapitre

Diagramme dtats-transitions
1. Modlisation laide dautomates ......................... 2. Hirarchie dans les machines tats ................................. 3. Contrat de comportement ....... 4. Gestion de la concurrence ...... Problmes et exercices 1. Diagramme dtats-transitions dun individu du point de vue de lINSEE ............................ 2. Diagramme dtats-transitions dune porte........................... 3. Diagramme dtats-transitions dune montre chronomtre ..... 4. Modlisation de la socket TCP... 128 133 138 139

Les diagrammes dtats-transitions (ou statecharts) dUML dcrivent le comportement interne dun objet laide dun automate tats finis. Ils prsentent les squences possibles dtats et dactions quune instance de classe peut traiter au cours de son cycle de vie en raction des vnements discrets (de type signaux, invocations de mthode).
142 143 145 148

Ils spcifient habituellement le comportement dune instance de classeur (classe ou composant), mais parfois aussi le comportement interne dautres lments tels que les cas dutilisation, les sous-systmes, les mthodes. Ils sont bien adapts la description dobjets ayant un comportement dautomate. Cependant, la vision globale du systme est moins apparente sur ces diagrammes, car ils ne sintressent qu un seul lment du systme indpendamment de son environnement. Les diagrammes dinteractions (voir chapitre 3) permettent de lier les parties du systme entre elles.

127

(1)

Modlisation laide dautomates

1.1 TAT
Un diagramme dtats-transitions est un graphe qui reprsente un automate tats nis, cest--dire une machine dont le comportement des sorties ne dpend pas seulement de ltat de ses entres, mais aussi dun historique des sollicitations passes : cet historique est caractris par un tat. Ainsi, leffet dune action sur un objet dpend de son tat interne, qui peut varier au cours du temps. Par exemple, considrez une lampe munie de deux boutons-poussoirs : une pression sur On allume la lampe et une pression sur Off lteint. Une pression sur On ne produit pas deffet si la lampe est dj allume ; la raction dune instance de Lampe cet vnement dpend de son tat interne.
EXEMPLE
La lampe Cet exemple simple prsente la notion dtat et leffet des invocations en fonction de ltat courant.

Figure 4.1
Un diagramme dtats-transitions simple.
Off allume On

On

teinte

Off

Les tats sont reprsents par des rectangles aux coins arrondis, tandis que les transitions sont reprsentes par des arcs orients liant les tats entre eux. Certains tats, dits composites , peuvent contenir des sous-diagrammes. UML offre galement un certain nombre de constructions la smantique particulire, telles que lhistorique, qui permet de retrouver un tat prcdent, les points de choix, qui permettent dexprimer des alternatives, ou encore un moyen dexprimer des mcanismes concurrents.
EXEMPLE
Fentre dapplication Le diagramme de la gure 4.2 prsente le comportement simpli dune fentre dapplication, qui rpond aux stimuli de trois boutons placs dans langle. Une fentre peut tre dans trois tats : rduite, normale, agrandie. Lorsquelle est rduite, elle est reprsente par une icne dans la barre des tches. ltat normal, elle peut tre dplace et redimensionne. Lorsquelle est agrandie, elle occupe toute la surface disponible de lcran et ne peut tre dplace ou redimensionne. Les arcs portent une tiquette indiquant le nom de lvnement qui dclenche la transition associe. Ltat initial (Init 1 et Init 2 ici), not par un cercle plein, dsigne le point dentre du diagramme ou du sous-diagramme. Une nouvelle instance de fentre sera initialise ltat cre, dans le sous-tat ouverte et dans le sous-tat normale. Le pseudo-tat historique, dsign par un H dans un cercle, permet de retrouver la fentre son tat prcdent (normale ou agrandie) quand on quitte ltat rduite. Ltat nal, dsign par un point dans un cercle correspond la n de vie de linstance et sa destruction.

128

UML 2

Chapitre

Figure 4.2
Le comportement dune fentre dapplication.

cre ouverte Init 1 normale Init 2 positionner() maximiser() dimensionner() maximiser() agrandie

H
minimiser()

minimiser() Final rduite

1.2 VNEMENT
La vue propose par les diagrammes dtats-transitions met en vidence les ractions dune partie du systme des vnements discrets. Un tat reprsente une priode dans la vie dun objet dans laquelle ce dernier attend un vnement ou accomplit une activit. Quand un vnement est reu, une transition peut tre dclenche qui va faire basculer lobjet dans un nouvel tat. Les transitions dun diagramme dtats-transitions sont donc dclenches par des vnements, appels dclencheurs ou triggers. La notion dvnement est assez large en UML : Un appel de mthode sur lobjet courant gnre un vnement de type call. Le passage de faux vrai de la valeur de vrit dune condition boolenne gnre implicitement un vnement de type change. La rception dun signal asynchrone, explicitement mis par un autre objet, gnre un vnement de type signal. Lcoulement dune dure dtermine aprs un vnement donn gnre un vnement de type after. Par dfaut, le temps commence scouler ds lentre dans ltat courant. La n dune activit de type do/, interne un tat gnre implicitement un vnement appel completion event. Cela peut dclencher le tir des transitions dites automatiques , qui ne portent pas de dclencheur explicite.

Notation et spcication
Un vnement de type call ou signal est dclar ainsi :
nom-vnement ( liste-paramtres )

o chaque paramtre a la forme :


nom-paramtre : type-paramtre

Les vnements de type call sont donc des mthodes dclares au niveau du diagramme de classes. Les signaux sont dclars par la dnition dune classe portant le strotype signal, ne fournissant pas doprations, et dont les attributs sont interprts comme des arguments. Un vnement de type change est introduit de la faon suivante :
when ( condition-boolenne )

Diagramme dtats-transitions 129

Notation et spcication (suite)


Il prend la forme dun test continu et se dclenche potentiellement chaque changement de valeurs des variables intervenant dans la condition. Un vnement temporel de type after est spci par :
after ( paramtre )

o le paramtre svalue comme une dure, a priori coule depuis lentre dans ltat courant. Par exemple : after(10 secondes) ou after(10 secondes aprs lentre dans ltat A). Vous pouvez aussi spcier un dclencheur li une date prcise par une clause when( ), par exemple when(date=1 janvier 2000).

Les dclarations dvnement ont une porte de niveau paquetage et peuvent tre utilises dans tout diagramme dtats-transitions des classes du paquetage. Leur porte nest en aucun cas limite une classe.

Particularits des vnements de type signal


Un signal est un message mis de faon asynchrone, cest--dire que lappelant peut poursuivre son excution sans attendre la bonne rception du signal. Ce type de communication a un sens uniquement lorsque plusieurs processus ou objets actifs sont en concurrence, en particulier lorsque linstance cible est munie dun ot de contrle indpendant de celui de lappelant. Lutilisation de signaux la place de mthodes peut accrotre les possibilits de concurrence et permet de modliser certains types de communications matrielles (interruptions matrielles, entres/sorties) ou en mode dconnect (le protocole UDP sur IP par exemple). Lmission et la rception dun signal constituent donc deux vnements distincts.
EXEMPLE
Dclaration de signaux la gure 4.3, trois signaux sont dclars comme des classes du paquetage et peuvent tre lis entre eux par des relations dhritage. Si le signal A drive du signal B, il dclenche par transitivit toutes les activits lies B en plus des siennes propres. Les attributs de classe sont interprts comme les arguments de lvnement de type signal.

Figure 4.3
Dclarations de signaux et hritage.

signal Interruption E/S +pripherique :int

signal Souris +posx:int +posy:int

signal Clavier +caractre: int

130

UML 2

Chapitre

1.3 TRANSITION

SIMPLE

Une transition entre deux tats simples E1 et E2 est reprsente par un arc qui les lie lun lautre. Elle indique quune instance dans ltat E1 peut entrer dans ltat E2 et excuter certaines activits, si un vnement dclencheur se produit et que les conditions de garde sont vries. On parle de tir dune transition quand elle est dclenche.

Notation
Une transition dun diagramme dtats-transitions est reprsente par un arc plein, liant un tat dit source un tat cible . Elle est dote dune tiquette contenant une expression de la forme :
nom-vnement ( liste-param-vnement ) [ garde ] / activit

o les paramtres ventuels de lvnement sont spars par des virgules, la garde (par dfaut vraie) dsigne une condition qui doit tre remplie pour pouvoir dclencher la transition, et lactivit exprime dans une syntaxe laisse libre dsigne des instructions effectuer au moment du tir. Le dclencheur de la transition est un vnement de type call, signal, change ou after, ou nest pas spci pour les transitions automatiques (voir la section vnement ). Lvnement peut porter des paramtres, visibles dans les activits associes la transition ainsi que dans lactivit exit de ltat source et lactivit entry de ltat cible. Les vnements entrants sont traits squentiellement. Si aucune transition nest dclenche par lvnement, il est dtruit. Si une transition est dclenche, sa garde est value ; celle-ci est exprime en fonction des variables dinstance et ventuellement de tests dtat des instances dobjet accessibles (par exemple, obj1 in tat1 ou obj1 not in tat1) ; si elle est fausse, lvnement est dtruit. Si plusieurs transitions sont simultanment franchissables, lune dentre elles est choisie de faon arbitraire.

1.4 POINT

DE DCISION
Il est possible de reprsenter des alternatives pour le franchissement dune transition. On utilise pour cela des pseudo-tats particuliers : les points de jonction (reprsents par un petit cercle plein) et les points de choix (reprsents par un losange). Les points de jonction sont un artefact graphique qui permet de partager des segments de transition. Plusieurs transitions peuvent viser et/ou quitter un point de jonction. Tous les chemins travers le point de jonction sont potentiellement valides. On peut donc reprsenter un comportement quivalent en crant une transition pour chaque paire de segments avant et aprs le point de jonction. Lintrt est de permettre une notation plus compacte et de rendre plus visibles les chemins alternatifs.

EXEMPLE

quivalences de reprsentation Les deux reprsentations des gures 4.4 et 4.5 sont quivalentes. Lutilisation des points de jonction rend les diagrammes plus lisibles.

Diagramme dtats-transitions 131

Figure 4.4
Utilisation de points de jonction.
tat1 e1[a>0]

[b>0]

tat3

[b=0]

tat4

tat2

e2[a>0] [b<0]

tat5

Figure 4.5
Equivalence avec des transitions gardes.
tat1

e1[a>0 and b<0]

e1[

a>0

e1[a>
and b>0 ]

0 and

tat3

b=0]

tat4
nd 0a b<0 ]

a e2[

>

e2[a>

0 and

b=0]

tat5

tat2

e2[a>0 and b>

0]

Cette quivalence avec une reprsentation par plusieurs transitions implique que, pour que lon puisse emprunter un chemin, toutes les gardes le long de ce chemin doivent svaluer vrai ds le franchissement du premier segment. Les points de jonction ne constituent donc quun sucre syntaxique, sans smantique particulire. On dispose galement du point de choix dit dynamique , reprsent par un losange. Au contraire dun point de jonction, les gardes aprs ce point de choix sont values au moment o il est atteint. Cela permet en particulier de baser le choix sur des rsultats obtenus en franchissant le segment avant le point de choix. Si, quand le point de choix est atteint, aucun segment en aval nest franchissable, le modle est mal form. Au contraire, si plusieurs segments sont franchissables, on suit la rgle habituelle : quand plusieurs transitions sont simultanment franchissables, lune dentre elles est choisie alatoirement.
EXEMPLE
Point de choix dynamique Un formulaire en ligne est rempli par un utilisateur. Quand il valide son formulaire en appuyant sur le bouton go, une vrication de la cohrence des donnes fournies est ralise par validerEntre(). Si les informations paraissent correctes, on lui demande de conrmer, sinon on afche les erreurs dtectes et il doit remplir de nouveau le formulaire. Notez que la validation se fait sur le segment avant le point de choix. Ce fonctionnement ne peut tre dcrit par un simple point de jonction.

Figure 4.6
Utilisation dun point de jonction.

saisie formulaire

go/validerEntre()

[entre valide] [else]

demander confirmation

afficher problmes

132

UML 2

Chapitre
Il est possible dutiliser une garde particulire sur un des segments aprs un point de choix ou de jonction en introduisant une clause [else]. Ce segment nest franchissable que si les gardes des autres segments sont toutes fausses. Lutilisation dune clause [else] est recommande aprs un point de choix car elle garantit un modle bien form. Si lon utilise un point de jonction pour reprsenter le branchement dune clause conditionnelle, il est conseill dutiliser galement un point de jonction pour faire apparatre la n du branchement et tre homogne.
EXEMPLE
Point de jonction reprsentant des alternatives Le point de jonction est bien adapt la reprsentation de clauses conditionnelles de type if/endif.

Figure 4.7
Deux points de jonction pour reprsenter des alternatives.

associer client et commande [client trouv] /afficher numero client

chercher client

associer client

[client non trouv]

crer client

(2)

Hirarchie dans les machines tats


ET TRANSITION INTERNE
Un tat est une priode dans la vie dun objet o il vrie une condition donne, excute une certaine activit, ou plus gnralement attend un vnement. Conceptuellement, un objet reste donc dans un tat durant une certaine dure, au contraire des transitions qui sont vues comme des vnements ponctuels (sauf dans le cas particulier o la transition dclenche elle-mme un traitement). Un tat peut tre dcompos en deux compartiments spars par une barre horizontale. Le premier compartiment contient le nom de ltat, le second contient les transitions internes de ltat, ou activits associes cet tat. Vous pouvez omettre la barre de sparation en labsence de transitions internes. Une transition interne ne modie pas ltat courant, mais suit globalement les rgles dune transition simple entre deux tats. Trois dclencheurs particuliers sont introduits permettant le tir de transitions internes : entry/, do/, et exit/.

2.1 TAT

EXEMPLE

Reprsentation dun tat simple


saisie mot de passe entry/ set echo invisible character/ traiter cararctre help/ afficher aide exit/ set echo normal

Figure 4.8
La saisie dun mot de passe.

Diagramme dtats-transitions 133

Notation
La syntaxe de la dnition dune transition interne est la suivante :
Nom-vnement (liste-paramtres) [garde] / activit--raliser

Le nom de lvnement peut tre celui dune mthode de lobjet auquel appar tient ltat, dun vnement dclar comme tel au niveau paquetage, ou un des mots-cls rser vs suivants : entry dnit une activit effectuer chaque fois que lon rentre dans cet tat. exit dnit une activit effectuer quand on quitte cet tat. do dnit une activit continue qui est ralise tant que lon se trouve dans cet tat, ou jusqu ce que le calcul associ soit termin. On pourra dans ce dernier cas grer lvnement correspondant la n de cette activit (completion event). include permet dinvoquer un sous-diagramme dtats-transitions. La liste des paramtres (optionnelle) correspond aux arguments de lvnement dclencheur de lactivit. La condition dactivation, ou garde, est une condition boolenne qui permet dautoriser ou non le dclenchement de lactivit. La faon de spcier lactivit raliser est laisse libre. En gnral, on utilise le langage naturel pour dcrire lactivit entreprendre, ou du pseudo-code mentionnant les arguments de lvnement dclencheur. On peut galement utiliser une rfrence vers un autre diagramme (activit ou collaboration) pour dcrire ce traitement.

Une transition interne se distingue dune transition reprsente par un arc qui boucle sur ltat, car lors de lactivation dune transition interne, les activits entry et exit ne sont pas appeles (on ne quitte pas ltat courant). Implicitement, tout diagramme dtats-transitions est contenu dans un tat externe qui nest usuellement pas reprsent. Cela apporte une plus grande homognit dans la description : tout diagramme est implicitement un sous-diagramme.

2.2 TAT

COMPOSITE
Un tat composite, par opposition un tat dit simple , est graphiquement dcompos en deux ou plusieurs sous-tats. Tout tat ou sous-tat peut ainsi tre dcompos en soustats enchans sans limite a priori de profondeur. Un tat composite est reprsent par les deux compartiments de nom et dactions internes habituelles, et par un compartiment contenant le sous-diagramme.

EXEMPLE

Combin tlphonique Cet exemple prsente les tapes de laction composer numro. lentre dans ltat composite (par exemple suite une action dcrocher), une tonalit sonore annonce que le tlphone est prt pour la composition du numro. Les chiffres sont saisis un par un suite lappel de lopration chiffrer. La transition automatique de numroter vers ltat nal est franchie ds que sa garde devient vraie.

134

UML 2

Chapitre

Figure 4.9
Composition dun numro et transitions automatiques.
Dbut entry/tonalit prt exit/ cesser tonalit

Composer numro Numroter [numro.valide()] entry/numero.append(n) chiffrer(n)

chiffrer(n)

Un nouvel objet est cr dans ltat initial le plus externe du diagramme et franchit la transition par dfaut qui en part. Un objet qui atteint ltat nal le plus externe est dtruit. Ces transitions peuvent tre accompagnes dune tiquette qui indique un vnement correspondant au constructeur ou destructeur dinstance, et ventuellement associes une activit. Une transition qui atteint ltat nal dun sous-diagramme correspond la n de laction associe ltat lencapsulant. La n dune activit interne dun tat peut tre associe au dclenchement dun changement dtat, reprsent par une transition sans tiquette qui quitte ltat externe courant. On parle alors de transition automatique, dclenche par un vnement implicite de terminaison (completion event). Un completion event est galement dclench par la n dune activit interne de type do/. Lutilisation dtats composites permet de dvelopper une spcication par rafnements. Il est parfois souhaitable de ne pas reprsenter les sous-tats chaque utilisation de ltat englobant. Vous pouvez noter graphiquement le fait quun tat est composite et que sa dnition est donne sur un autre diagramme.
EXEMPLE
Notation abrge des tats composites

Figure 4.10
Reprsentation compacte dun tat composite.
Composer numro

2.3 TRANSITION

ET TAT COMPOSITE

Les transitions peuvent avoir pour cible la frontire dun tat composite et sont alors quivalentes une transition ayant pour cible ltat initial de ltat composite. De mme, une transition ayant pour source la frontire dun tat composite est quivalente une transition qui sapplique tout sous-tat de ltat composite source. Cette relation est transitive : la transition est franchissable depuis tout tat imbriqu, quelle que soit sa profondeur. Si la transition ayant pour source la frontire dun tat composite ne porte pas de dclencheur explicite (en dautres termes, si elle est dclenche par un completion event), elle est franchissable quand ltat nal de ltat composite est atteint. Par exemple, la transition minimiser de la fentre dapplication est franchissable depuis les tats normale et agrandie (voir gure 4.2). Les transitions peuvent galement toucher des tats de diffrents niveaux dimbrication, en traversant les frontires des tats. Dans tous les cas, avant lentre dans un tat (respectivement la sortie), les activits entry/ (respectivement exit/) sont ralises. En cas de transition menant vers un tat imbriqu, les activits entry/ de ltat englobant sont ralises avant celles de ltat imbriqu. En cas de transition depuis la frontire de ltat englobant, les activits exit/ du sous-tat actif sont ralises, puis celles de ltat englobant le sont leur tour.

Diagramme dtats-transitions 135

EXEMPLE

Ordre dappel Depuis ltat tat11, la rception de lvnement event1 provoque la squence dactivits QuitterE11, QuitterE1, action1, EntrerE2, EntrerE21, initialiser, EntrerE22, et place le systme dans ltat tat22.

Figure 4.11
Ordre des actions dans un cas complexe.
tat 1

tat2 tat21 tat11 exit/QuitterE11 event1/action1 tat22 initialiser() entry/EntrerE22

exit/QuitterE1

entry/EntrerE21 entry/EntrerE2

2.4 HISTORIQUE

ET TAT COMPOSITE

Chaque rgion ou sous-diagramme dtats-transitions peut avoir un pseudo-tat historique, not par un cercle contenant un H. Une transition ayant pour cible le pseudo-tat historique est quivalente une transition qui a pour cible le dernier tat visit dans la rgion contenant le H. Dans lexemple de la fentre prsent prcdemment la gure 4.2, le pseudo-tat historique permet de retrouver ltat prcdent (normale ou agrandie) quand on sort de ltat rduite. Il est possible de dnir un dernier tat visit par dfaut laide dune transition ayant pour source le pseudo-tat H. Cet tat par dfaut sera utilis si la rgion na pas encore t visite. Il est galement possible de dnir un pseudo-tat historique profond, not par un cercle contenant H*. Cet historique profond permet datteindre le dernier tat visit dans la rgion, quel que soit son niveau dimbrication, alors que le pseudo-tat H limite laccs aux tats de son niveau dimbrication dans la rgion. Toute rgion peut avoir la fois un historique profond et un historique de surface.
EXEMPLE
Historique Lutilisation dun historique profond permet de retrouver, aprs une interruption, le sous-tat prcdent. la gure 4.12, lutilisation dun historique de surface H, au lieu de H*, permettrait de retrouver ltat Traitement1 ou Traitement2 dans leur sous-tat initial, mais pas les sous-tats imbriqus E11, E12, E21, E22, qui taient occups avant linterruption.

136

UML 2

Chapitre

Figure 4.12
Historique et historique profond.
Traitement 1

Traitement reprendre

H*
Traitement 2

Traite Interruption

E11

E21

interrompre

E12

E22

2.5 INTERFACE

DES TATS COMPOSITES

Pour cacher la complexit, il est possible de masquer, sur un diagramme, les sous-tats dun tat composite et de les dnir dans un autre diagramme. Pour exprimer la connexion des diagrammes entre eux, vous pouvez utiliser des points de connexion. Les points dentre et de sortie sont respectivement reprsents par un cercle vide et un cercle barr la frontire de ltat. Pour utiliser le comportement par dfaut dune machine tat, cest--dire entrer par ltat initial par dfaut et considrer les traitements nis quand ltat nal est atteint, il est inutile de se servir de ces points de connexion. Recourez plus simplement des transitions ayant pour cible la frontire de ltat englobant. Employez plutt des points de connexion lorsquil est possible dentrer ou de sortir de la machine tats de plusieurs faons, par exemple pour reprsenter des transitions traversant la frontire de ltat englobant et visant directement un autre sous-tat que ltat initial (comme ltat historique par exemple), ou ayant pour source un sous-tat et visant un tat externe. Un point de connexion nest quune rfrence un tat dni ailleurs. Ltat quil dsigne est signal par lunique transition quittant le pseudo-tat. Cette transition peut ventuellement porter une tiquette indiquant une action (qui sera excute avant lactivit entry de ltat cible), mais pas de garde ni de dclencheur explicite : cest le prolongement de la transition qui vise le point de connexion. Plusieurs transitions peuvent cibler un mme point de connexion. Cela peut rendre les diagrammes plus lisibles.
EXEMPLE
Points de connexion Cet exemple montre lutilisation des points de connexion. Ltat distribuer boisson a deux entres et trois sorties. Lentre par dfaut vrie dabord que le crdit de lutilisateur est sufsant pour la boisson slectionne, et peut provoquer une sortie sur erreur par le point de connexion crdit insufsant. Un deuxime point dentre est fourni pour loprateur de maintenance qui peut dclencher la prparation dune boisson sans insrer dargent. La prparation de la boisson peut elle-mme tre soumise des erreurs. Dans le cas nominal, la boisson est prpare et la sortie de ltat distribuer boisson se fait par ltat nal.

Diagramme dtats-transitions 137

Figure 4.13
Points de connexion pour la composition de diagrammes.

distribuer boisson

[crdit < prix] vrifier crdit

Crdit insuffisant

[crdit >= prix] Test oprateur prparer boisson Produit puis Erreur matrielle

Erreur boisson non distribue

Les points de connexion sont plus quune facilit de notation : ils permettent de dcoupler la modlisation du comportement interne dun tat et la modlisation dun comportement plus global. Ils offrent une faon de reprsenter linterface (au sens objet) dune machine tats, en masquant limplmentation du comportement. Cela permet un dveloppement par rafnements (ou en bottom-up), en deux tapes indpendantes du processus de conception, ce qui est essentiel pour traiter des modles de grande taille.

(3)

Contrat de comportement
UML 2 introduit la notion de contrat de comportement (ou protocole dutilisation dun classeur), reprsent laide dun diagramme de protocole (une version simplie des diagrammes dtats-transitions reconnaissable au mot-cl {protocol}). Un contrat de comportement dnit les squences dactions lgales sur un classeur, ainsi quun certain nombre de pr- et post-conditions qui doivent tre valides. Il est relativement abstrait et nexprime pas la nature des traitements raliss, mais indique simplement leur enchanement logique. Ainsi, les tats dun diagramme de protocole nont pas de clauses dclenchant des activits (entry/, exit/, do/), et les transitions nont pas dactivits dclencher.

Notation
La syntaxe de ltiquette dune transition liant un tat source E1 un tat destination E2 sur un diagramme de protocole est la suivante :
[pr-condition] Dclencheur / [post-condition]

Une telle transition a le sens suivant : si le classeur est dans ltat protocolaire E1 et si la pr-condition est vraie, la rception de lvnement dclencheur doit provoquer le passage dans ltat E2, et lissue du franchissement, la post-condition doit tre vraie.

138

UML 2

Chapitre
Les protocoles servent expliquer la faon correcte de se servir dune classe ou dun composant, sans spcier les traitements qui ralisent laction. Plusieurs implmentations diffrentes dune classe peuvent respecter un protocole donn.
EXEMPLE
Protocole dune classe Fichier Ce diagramme dcrit la faon de se servir dune instance de classe descripteur de chier. Avant de pouvoir lutiliser vraiment (lecture, criture, positionnement du curseur dans le chier), il faut lassocier un chier laide de la mthode open. Avant de dtruire linstance, lutilisateur doit appeler la mthode close, pour viter dventuels problmes dentre/ sortie. Sur cet exemple, il ny a pas de gardes.

Figure 4.14
Diagramme de protocole dune classe chier.

stm {protocol} fichier write/ close/ dconnect open/ delete/ read/ connect seek/

(4)

Gestion de la concurrence
Les diagrammes dtats-transitions permettent de dcrire efcacement les mcanismes concurrents. Un tat composite dot de sous-tats peut avoir un comportement concurrent, travers lutilisation de rgions concurrentes. Celles-ci permettent de reprsenter des zones o laction est ralise par des ots dexcution parallles. Chaque rgion dun tat peut avoir un tat initial et nal. Une transition qui atteint la bordure dun tat composite est quivalente une transition qui atteint ltat initial du sous-diagramme ou les tats initiaux de toutes ses rgions concurrentes si elles existent. Les transitions ayant pour origine un tat initial interne ne sont pas tiquetes et correspondent toute transition atteignant la frontire de ltat externe. Quand un tat prsente des rgions concurrentes, elles doivent toutes atteindre leur tat nal pour que laction soit considre comme termine (gnration dun completion event).

EXEMPLE

tat concurrent Cet exemple montre un tat concurrent, au sein dun distributeur de type machine caf. Quand la boisson a t slectionne et le montant valid par rappor t au crdit, deux squences dactions sont dclenches en parallle : la prparation de la boisson et le rendu de la monnaie.

Diagramme dtats-transitions 139

Figure 4.15
Rgions concurrentes au sein dun tat.
prparer boisson entry/placer gobelet do/servir liquide boisson slectionne

terminer prparation do/ajouter sucre exit/signal sonore

rendre monnaie entry/monnaie= credit - boisson.prix() do/monnayeur.rendre(monnaie)

Il est galement possible de reprsenter ce type de comportement au moyen de transitions concurrentes dites complexes . Ces transitions sont reprsentes par une barre verticale paisse et courte, ventuellement associe un nom. Un ou plusieurs arcs peuvent avoir pour origine ou destination la transition. La smantique associe est celle dun fork/join.
EXEMPLE
Transition concurrente Ltat concurrent du distributeur de boisson peut tre spci de faon quivalente laide de deux transitions concurrentes. La transition nomme ici fork correspond la cration de deux tches concurrentes cres dans les tats prparer boisson et rendre monnaie. La transition nomme join correspond une barrire de synchronisation par rendez-vous. Pour pouvoir continuer leur excution, toutes les tches concurrentes doivent pralablement tre prtes franchir la transition de rendez-vous.

Figure 4.16
Transition complexe pour lexpression de la concurrence.
fork

prparer boisson entry/placer gobelet do/servir liquide nominal

terminer prparation join do/ajouter sucre exit/signal sonore gobelet bloqu do/a fficher retirer boisson

rendre monnaie entry/monnaie= credit - boisson.prix() do/monnayeur.rendre(monnaie)

gobelet retir/

Une transition ayant pour destination un tat cible muni de rgions concurrentes est quivalente une transition complexe de type fork ayant pour cibles les tats initiaux de chaque rgion concurrente. Une transition ayant pour origine un tat source muni de rgions concurrentes est quivalente une transition complexe de type join ayant pour sources les tats naux de chaque rgion concurrente.

140

UML 2

Chapitre

Conclusion
Les diagrammes dtats-transitions permettent de reprsenter le comportement interne dun objet, a fortiori actif, sous une forme qui met en avant le modle vnementiel ou ractif des traitements. Ils sont bien adapts au gnie logiciel orient objet, en raison des mcanismes quils proposent (vnement de type call, signal, after), qui permettent de faire le lien avec les autres diagrammes de la norme. La grande exibilit apporte par la possibilit de dnir des transitions internes (entry, do, exit) et par les mcanismes de hirarchisation des diagrammes permet de reprsenter de faon concise et formelle lensemble des comportements dune instance modlise. De ce point de vue, les diagrammes dtats-transitions sont les seuls de la norme offrir une vision complte et non ambigu de lensemble des comportements (les diagrammes dinteractions noffrant que la vue dun scnario, sans vraiment prciser comment les diffrents scnarios bauchs peuvent interagir entre eux). Dun autre ct, en raison de leur grand niveau de dtails et de leur lourdeur relative, ils sont surtout adapts la phase de ralisation. En outre, ils conviennent peu la modlisation de systmes composs de plusieurs sous-systmes car ils noffrent pas de vision globale. Les diagrammes de protocole donnent une vision de haut niveau du comportement dun composant en spciant ses responsabilits, sans entrer dans les dtails de son implmentation. Ils sont relativement proches de la notion dinterface dun composant, tout en ajoutant une information supplmentaire par rapport la seule description des signatures des oprations quil porte, savoir des contraintes sur lordre dappel des oprations dclares. Outre leur intrt lors de la modlisation, certains outils sont capables de gnrer automatiquement un programme partir dune description sous forme de diagrammes tatstransitions. Ainsi, chaque objet dun systme passe sous le contrle dun automate. Ce dernier connat ltat de lobjet tout instant, et en agissant comme un ltre, nautorise les changements dtats que sil reoit une demande de transition valide. Le code produit est alors trs robuste car lobjet ne peut pas tre corrompu. De plus, le mode de contrle du logiciel devient alors vnementiel. Avec les diagrammes prsents dans la partie prcdente du livre (diagramme des cas dutilisation, diagramme de classes et dobjets, diagramme de squence et de communication, diagramme dtats-transitions), un systme peut tre presque entirement modlis. La modlisation nest cependant pas assez avance pour implanter le systme. Les dveloppeurs par exemple ont besoin de dcrire les algorithmes utiliss pour dnir les mthodes des classes, sans pour autant avoir recours un langage de programmation. Par ailleurs, certains modles sont trop approximatifs. Considrez par exemple un systme dont le comportement est complexe. Dans ce cas, les diagrammes de squence peuvent ne pas sufre dtailler les cas dutilisation. Une partie de ces lacunes peuvent tre combles grce aux diagrammes dactivits qui sont tudis au chapitre suivant.

Diagramme dtats-transitions 141

Problmes et exercices
Les exercices suivants utilisent les principaux concepts des diagrammes dtats-transitions.

EXERCICE 1

DIAGRAMME DTATS-TRANSITIONS DUN DE LINSEE

INDIVIDU DU POINT DE VUE

Reprsentez par un diagramme dtats-transitions les tats que peut prendre un individu du point de vue de lINSEE : vivant, dcd, mineur, majeur, clibataire, mari, veuf et divorc. Supposez que seul un individu majeur peut se marier. Utilisez des tats composites pour cumuler les tats : un individu peut tre simultanment vivant, majeur, et divorc par exemple.

Figure 4.17
Un individu du point de vue de lINSEE.
mineur clibataire after (18 ans)

vivant majeur marier mari dcs conjoint divorcer majoritAnticipe divorc marier marier veuf

dcder dcd

La machine tats englobante est implicite ici. Lutilisation dun vnement de type after permet de dclencher le passage ltat majeur. Seules les transitions lgales sont reprsentes : une personne ne peut se marier si elle est dj marie. La transition dcder est franchissable quel que soit le sous-tat de vivant dans lequel se trouve un individu.

142

UML 2

Chapitre

EXERCICE 2

DIAGRAMME DTATS-TRANSITIONS DUNE

PORTE

Une porte munie dune serrure offre les oprations ouvrir, fermer, verrouiller, dverrouiller et franchir. La serrure peut tre ferme simple ou double tour. 1. Commencez par modliser les tats et transitions de la serrure. Mettez en avant les tats o la serrure est verrouille par rapport aux tats o elle ne lest pas. 2. Exprimez travers un diagramme de protocole la faon normale de se servir dune porte verrou. 3. Modlisez les tats et transitions dune porte sans serrure. Ajoutez ensuite des annotations exprimant des contraintes pour lier ce diagramme lutilisation de la serrure. 1.La serrure rpond aux vnements verrouiller et dverrouiller. Vous pouvez dans un premier temps vous contenter de modliser les trois tats dverrouille, simple tour et double tour. Utilisez un tat composite pour distinguer les tats o la serrure est verrouille. Sur le schma de la gure 4.18, nous avons employ la notation frame (cadre), avec lindication stm (State Machine), pour spcier le type et le nom du diagramme.

Figure 4.18
Les tats dune serrure de porte.

stm Serrure verrouille verrouiller dverrouille dverrouiller simple tour dverrouiller verrouiller double tour

2. Un diagramme de protocole exprime la faon correcte de se servir dun composant. Ici vous devez spcier quon ne verrouille la porte que quand elle est ferme. Une premire version prsente la gure 4.19 fait apparatre quatre tats.

Figure 4.19
Le protocole dutilisation dune porte.

{protocol} porte avec verrou fermer() verrouiller() ferme simple tour dverrouiller() verrouiller() ferme double tour dverrouiller()

ouverte

ferme

franchir()

ouvrir()

Cependant pour amliorer la cohrence avec le diagramme prsent la gure 4.18, vous pouvez utiliser un tat composite, dans lequel les tats prcdemment identis de la serrure sont prsents.

Diagramme dtats-transitions 143

Exercices

Figure 4.20
Une autre modlisation du protocole dutilisation dune porte.

{protocol} porte avec verrou fermer() verrouiller()

ferme verrouiller()

ouverte

dverrouille

simple tour

double tour

franchir()

ouvrir()

dverrouiller()

dverrouiller()

Ces deux modlisations sont trs similaires, mais la deuxime dcouple mieux les tats de la serrure et ceux de la porte elle-mme. 3. La porte na que de deux tats (ouverte ou ferme) et ragit aux vnements ouvrir, fermer et franchir. Vous pouvez dabord modliser les tats ouverte et ferme et les transitions associes. Ajoutez ensuite les gardes qui contraignent les transitions par rapport aux tats de la serrure. La rfrence ltat de lobjet serrure suppose une variable de contexte accessible depuis lobjet englobant ce diagramme, cest--dire la porte.

Figure 4.21
Les tats dune porte.

stm porte [serrure dverrouille] fermer()/ ouverte [serrure dverrouille] ouvrir()/ franchir() ferme

Cette modlisation exploite la dnition composite des tats de la serrure : il ne sagit pas de savoir si la serrure est ferme simple ou double tour, mais simplement si elle est verrouille ou non.

Remarque
Cette modlisation dcouple mieux les objets porte et serrure quune modlisation qui mlangerait leurs machines tats. Vous seriez alors oblig de faire gurer des tats comme ouverte et verrouille simple tour, ouverte et verrouille double tour, ferme et verrouille, ce qui augmenterait la complexit du diagramme inutilement et forcerait copier-coller des parties de diagramme. Lutilisation de gardes est mieux adapte ici que lutilisation dune barre de synchronisation qui forcerait mlanger les diagrammes de la serrure et de la por te. Avec le modle obtenu, vous pourrez aisment rutiliser des parties pour modliser une porte avec un digicode par exemple. Enn, notez que la porte telle quelle est dnie par le diagramme de la gure 4.21 admet des scnarios absents du diagramme de protocole : il est galement possible de la verrouiller quand elle est ouverte (ce qui empche de la fermer correctement). Le diagramme de protocole donne donc des informations non redondantes par rapport aux diagrammes dtats-transitions : il dcrit la bonne faon de se servir dune porte.

144

UML 2

Chapitre

EXERCICE 3

DIAGRAMME DTATS-TRANSITIONS DUNE

MONTRE CHRONOMTRE

Cet exercice runit trois exercices relativement indpendants, correspondant aux diffrentes fonctionnalits proposes. Larchitecture logicielle propose sappuie sur le design pattern Observer.

Remarque
Le design pattern (ou patron de solution) Observer [Gamma 95] offre une solution propre aux problmes de mise jour des donnes de classes lies entre elles. Un des problmes du partitionnement dune application en classes est le maintien de la cohrence des par ties de lapplication. Pour favoriser la rutilisabilit, il nest pas souhaitable de coupler for tement les classes stockant les donnes (classes de type sujet) et celles qui les afchent ou plus gnralement les utilisent (classes de type observateur). Pourtant, il faut assurer quune mise jour des donnes des classes de type sujet sera correctement rpercute sur les classes de type observateur. Le design pattern Observer dcrit une solution ce problme. Un sujet peut avoir un nombre indtermin dobservateurs et tous les observateurs sont notis du changement quand le sujet subit une mise jour. En rponse, les observateurs interrogent le sujet pour connatre son nouvel tat et mettre ainsi jour leur propre tat. Une architecture de ce type est parfois qualie de publish/subscribe (publication/abonnement) : le sujet publie des notications, les observateurs sy abonnent sils le souhaitent. Le point important est que le sujet ignore quels sont ses observateurs, ce qui donne un modle bien dcoupl.

Figure 4.22
Design pattern Observer.

Sujet observateurs +attacher(Observateur) +dtacher(Observateur) +notify()

Observateur update() pour chaque o de observateurs { o.update(); }

SujetConcret tatSujet setEtat() getEtat()

sujet

ObservateurConcret tatObservateur

mettre jour ltat ; self.notify();

update()

tatObservateur = foo (sujet.getEtat()); return tatSujet;

Le bouton mode active successivement trois modes principaux de la montre : lafchage de lheure courante, le mode chronomtre et le mode rglage (pour mettre jour lheure courante).

Diagramme dtats-transitions 145

Exercices

Une montre digitale propose une fonction horloge et une fonction chronomtre. Elle est munie de quatre boutons : Le bouton light, quand il est press, allume une lumire pendant une dure de deux secondes.

Le bouton start-stop lance et arrte le chronomtre en mode chronomtre. Il active successivement les fonctions de rglage de lheure, des minutes ou des secondes en mode rglage. Le bouton set incrmente les heures, minutes et secondes en mode rglage et remet zro le chronomtre.
Vous allez dcomposer ltude du fonctionnement de cette montre en plusieurs tapes. On vous donne la classe Timer qui sait grer les dates/heures et est munie de toutes les oprations de mise jour utiles. Sa mthode start() lance lcoulement du temps et stop() larrte. 1. laborez un diagramme de classes qui permet de raliser le lien entre lafcheur cristaux liquides de la montre et les instances de Timer grant respectivement le chronomtre et lheure courante. 2 .Modlisez dans un premier temps le comportement li lutilisation du bouton mode de la montre. Ajoutez le comportement li lutilisation de la lumire (bouton light). 3. En mode chronomtre, le bouton start-stop lance ou arrte le chronomtre. Le bouton set remet le chronomtre zro sil est arrt. Modlisez ces comportements. Ajoutez la possibilit de retrouver ltat prcdent en changeant de mode : il est possible de lancer le chronomtre, puis de basculer en mode afchage de lheure et de revenir au mode chronomtre : le chronomtre continue de tourner pendant cette opration. (Vous pourrez utiliser un pseudo-tat historique.) 4. En mode rglage, le bouton start-stop active successivement les fonctions de rglage de lheure, des minutes ou des secondes. Le bouton set incrmente lheure courante dune heure en mode rglage de lheure, dune minute en mode rglage des minutes, ou remet les secondes zro en mode rglage des secondes. Lafcheur fait clignoter le champ slectionn. Modlisez ces comportements. 1. La montre dispose de deux instances de Timer, et dun afcheur, accessibles depuis son contexte. On utilise une instance du design pattern Observer pour assurer la cohrence continue entre lafchage et ltat interne de la montre.

Figure 4.23
Diagramme de classes simpli dune montre.
Sujet Observateur

Timer start() stop() chrono time

sujet

Afficheur afficher(t: Timer) afficheur

sujet.dtacher(self); t.attacher(self); sujet = t;

Montre

146

UML 2

Chapitre
2. Lalternance entre les trois modes principaux se reprsente facilement laide de trois tats. Le comportement li lclairage est indpendant du mode principal slectionn. Utilisez donc des rgions concurrentes pour exprimer cette indpendance.

Figure 4.24
Les principaux modes dafchage et la lumire.
mode/ mode chrono affichage heure entry/ afficheur.afficher(time) mode/ mode rglage mode/

light/ lumire teinte after(2 sec) lumire allume light/

Le mode afchage de lheure est relativement simple : quand on entre dans cet tat, on lie lafcheur lheure courante ; les boutons set et start-stop sont alors sans effet. Les modes chronomtre et rglage sont plus complexes et par l mme dtaills sparment. Notez graphiquement que ce sont des tats composites, sans plus de prcision. On introduit le point dentre de ltat mode chrono par souci de cohrence avec la solution propose la question 3. ce stade de la modlisation, vous pourriez vous contenter de toucher la frontire de ltat. La gestion de la lumire donne lieu deux tats, isols dans une rgion concurrente. after(2sec) se mesure par dfaut ds lentre dans ltat lumire allume. Une nouvelle pression sur le bouton light quand la lumire est dj active a donc pour effet de remettre ce compteur zro, puisque la transition associe fait quitter et entrer de nouveau dans ltat lumire allume. 3. Le mode chronomtre sappuie sur linstance de Timer chrono. Chaque fois que lon entre en mode chronomtre, lafcheur est li linstance de Timer chrono. Le chronomtre est initialis zro la premire fois que lon entre dans cet tat. Ce fonctionnement est modlis par la transition partant de ltat historique, qui est la transition par dfaut (portant laction chrono.set(0)) utilise uniquement la premire fois que lon pntre dans cette rgion. Celle-ci a ensuite deux sous-tats, selon que le chronomtre est lanc ou arrt. Si on la quitte et quon la retrouve ensuite, le dernier tat visit est atteint, ce qui reprsente bien le mcanisme de reprise dcrit dans lnonc. Lvnement not s-s correspond la pression sur le bouton start-stop. Le point dentre de cet tat composite mne directement ltat historique. Labsence de pseudo-tat initial est compense par la prsence dun tat historique qui permet dentrer dans la rgion. Un pseudo-tat nal est galement inutile puisque les transitions quittant cette rgion touchent la frontire de ltat et sont donc franchissables depuis les deux tats stopp et lanc.

Diagramme dtats-transitions 147

Exercices

Figure 4.25
Le mode chronomtre.
H
stopp /chrono.set(0) set/chrono.set(0) entry/afficheur.afficher(chrono)

mode chrono s-s/chrono.stop() lanc s-s/chrono.start()

4. Le mode rglage a trois sous-tats reprsentant le rglage de lheure, des minutes et des secondes. lentre dans cette rgion, lafcheur est li au Timer time reprsentant lheure courante. Les actions do/ sont continues et durent tant que lon reste dans ltat, mais sont interrompues par une transition qui le quitte. Les mthodes increment et reset incrmentent ou remettent zro le champ mentionn.

Figure 4.26
Le mode rglage.
s-s/ set/time.increment(heure)

mode rglage set/time.increment(minute) rglage minute do/afficheur.clignoter(minute) s-s/ set/time.reset(seconde)

rglage heure do/afficheur.clignoter(heure) s-s/

rglage seconde do/afficheur.clignoter(seconde)

entry/afficheur.affiche(time)

EXERCICE 4

MODLISATION

DE LA SOCKET

TCP

Cet exercice rcapitulatif aborde la modlisation dune socket de communication en mode connect utilisant le protocole TCP (Transfer Control Protocol). Les tats utiliss dans cette modlisation sont ceux afchs par la commande standard netstat et spcis dans la norme IEEE. Cet exercice correspond donc la modlisation dun protocole rel. Ne soyez pas drout par la complexit apparente du sujet : le passage des diagrammes de squence proposs aux diagrammes dtats-transitions est relativement direct.

148

UML 2

Chapitre

Les sockets sont des points extrmes de communication bidirectionnels : cest une interface standardise, implmente sur quasiment toutes les plates-formes de faon homogne, pour permettre la portabilit dapplications interagissant travers un rseau. Le modle offert pour lutilisation de sockets TCP est de type client-serveur : Le serveur offre un service aux clients, sur un numro de port bien connu (80 pour HTTP par exemple). Il ouvre pour cela une socket quil place dans ltat LISTEN (coute) et attend les requtes de client.

Le client est lutilisateur du service. Il ouvre une socket et demande la connexion au serveur, en fournissant ladresse du service souhait (par exemple : nom.de.serveur.fr:80).
Si, ladresse spcie, un serveur est bien en attente, une connexion entre le client et le serveur est tablie. Le diagramme de squence de la gure 4.27 reprsente les tapes de cette ouverture de connexion. Les rectangles arrondis sur la ligne de vie donnent ltat de linstance de socket concerne. Les messages provenant de la bordure du cadre reprsentent les messages provenant de lapplication. Les messages (ou trames) SYN sont un des types de messages de contrle du protocole TCP. Les trames ACK correspondent des acquittements. Chaque trame TCP porte un numro de squence, qui permet de grer les pertes de trames et les acquittements. Toute trame peut porter, en plus de sa valeur propre, un acquittement encapsul dans le mme objet (piggy-back), pour des questions defcacit.

Figure 4.27
Ouverture de connexion TCP.
sd tablissement de connexion TCP client:Socket CLOSED server:Socket CLOSED accept() connect() SYN_SENT SYN J SYN K,ACK J+1 SYN_RCVD ACK K+1 ESTABLISHED ESTABLISHED LISTEN

La n de connexion est initie par lun des participants, quand son application appelle la mthode close(). Pour que la connexion se termine proprement, un certain nombre de trames sont encore changes, comme le montre le schma prsent la gure 4.28.

Diagramme dtats-transitions 149

Exercices

Une fois la connexion tablie, le protocole devient symtrique : les deux participants peuvent lire et envoyer des messages. Vous ne modliserez pas cette partie du protocole relativement complexe, qui assure la transmission sans pertes, duplications ou dsquencement des messages, et la gestion transparente des congestions du rseau.

Figure 4.28
Fermeture de connexion TCP.
sd Fermeture de connexion TCP On note client et serveur, mais cette partie du protocole est totalement symtrique

client:Socket

server:Socket

close()

ESTABLISHED

ESTABLISHED

FIN_WAIT_1

FIN M ACK M+1 CLOSE_WAIT close() FIN N LAST_ACK

FIN_WAIT_2

TIME_WAIT

ACK N+1

La fin du timeout de 2 MSL (Maximum Segment Lifetime) ramne ltat CLOSED

CLOSED

On dit de lextrmit note client sur ce schma quelle fait une fermeture active, car elle initie la n de connexion. Au contraire, lextrmit serveur subit une fermeture passive, linitiative de lautre participant. ltat CLOSE_WAIT, les lectures de lapplication sur la socket vont rendre le caractre de n de chier EOF, et lon attend de lapplication quelle appelle la mthode close() pour une fermeture propre de la connexion. Lensemble du protocole prvoit des problmes matriels tels quune interruption du rseau ou un crash dun des participants : chaque envoi dune trame, on initialise une horloge, qui dclenche la rmission de la trame si elle nest pas acquitte temps (on suppose que la trame sest perdue sur le rseau) ou la n de la connexion si la trame a dj t mise trois fois (on suppose un crash rseau ou de lautre participant). 1. En vous basant sur les diagrammes de squence fournis, laborez un diagramme dtats-transitions reprsentant les tats dune socket TCP. Vous distinguerez les tats correspondant ltat initial (CLOSED), lattente dune connexion ct serveur, lattente dtablissement de la connexion ct client, la connexion tablie (ESTABLISHED), et la fermeture active et passive de la connexion. Certains de ces tats peuvent tre afns en sous-tats.

150

UML 2

Chapitre

2. Une fermeture simultane de la connexion se produit lorsque les deux participants demandent en mme temps cette fermeture (par appel de close()). Leurs trames de FIN se croisent et sont rceptionnes alors que la socket est ltat FIN_WAIT_1 o lon attend habituellement un simple acquittement. Ce cas est dcrit par le diagramme de squence prsent la gure 4.29.

Figure 4.29
Fermeture simultane de connexion TCP.
sd Fermeture de connexion simultane TCP client:Socket server:Socket

ESTABLISHED close() FIN J FIN_WAIT_1 FIN K

ESTABLISHED close() FIN_WAIT_1

ACK K+1 CLOSING

ACK J+1 CLOSING

TIME_WAIT La fin du timeout de 2 MSL (Maximum Segment Lifetime) ramne ltat CLOSED

TIME_WAIT

Modiez le diagramme de la rponse la question 1 pour permettre ce nouveau cas de gure.

1. Cet exercice modlisant un systme rel est plus complet que les prcdents. La solution propose ici est une version simplie du protocole, inspire du chapitre 18 de louvrage TCP/IP illustr, volume 1 de Stevens (1993, Addison Wesley). Il faut dcomposer le problme en tapes. Dans ce but, laborez dans un premier temps un diagramme o napparaissent que les messages provenant de lapplication et les tats proposs par lnonc (voir gure 4.30).

Diagramme dtats-transitions 151

Exercices

Figure 4.30
tats dune socket TCP du point de vue dune application.

[timeout et trame rmise 2 fois]

CLOSED accept() connect()

Attente dun client

Connexion au serveur

ESTABLISHED Fin par correspondant close()

Fermeture passive

Fermeture active

Ce premier diagramme donne une bonne vue densemble du comportement de la socket. Sont mentionns les informations et comportements principaux du protocole : une socket est initialement ltat CLOSED et peut tre sollicite par un accept() (du ct serveur) ou un connect() (du ct client). La connexion est alors tablie (tat ESTABLISHED). La connexion peut se terminer soit de faon active, avec un appel de close(), soit de faon passive, si cest lautre participant qui met n la connexion. La solution propose utilise un point de sortie alternatif pour reprsenter ce dernier cas, au lieu de porter la trame FIN/ACK directement sur une transition de la bordure de ltat ESTABLISHED ltat Fermeture passive. Ce parti pris assure une certaine cohrence et permet de cacher sur ce diagramme toutes les trames de contrle. Cela donne une vision de plus haut niveau du comportement. La n nominale de la connexion correspond ltat nal, atteint par une transition automatique depuis un des tats de fermeture. La transition sans tiquette qui ramne ltat CLOSED est alors franchie. Le mcanisme de timeout ramne ltat CLOSED et est franchissable depuis tout tat o la connexion est engage. Vient ensuite la description dtaille des tats recenss (gures 4.31 4.35), ce qui est relativement direct tant donn les diagrammes de squence proposs. Sont omis sur ces diagrammes les numros de squence des messages.

152

UML 2

Chapitre

Figure 4.31
Ct serveur, attente dun client.
LISTEN

attente dun client

SYN_RCVD SYN / SYN,ACK ACK/

Figure 4.32
Ct client, tapes de la connexion.
/ SYN

connexion au serveur

SYN,ACK / ACK SYN_SENT

Figure 4.33
Symtrique, phase connecte dchanges de donnes.

ESTABLISHED

Transfert de donnes FIN/ACK

Fin par correspondant

Figure 4.34
Fermeture active, linitiative de lapplication.
/FIN ACK/

fermeture active FIN/ACK after (2MSL) TIME_WAIT

FIN_WAIT_1

FIN_WAIT_2

Figure 4.35
Fermeture passive, suite une demande de lautre participant.

fermeture passive close()/FIN CLOSE_WAIT LAST_ACK ACK/

Diagramme dtats-transitions 153

Exercices

2. Lajout de ce nouveau scnario se traduit par lintroduction dune nouvelle transition depuis ltat FIN_WAIT_1. Le schma densemble dcrivant les tats nest pas transform : seul le comportement interne de ltat composite fermeture active est modi (gure 4.36).

Figure 4.36
Introduction de la fermeture simultane ou double fermeture active.

fermeture active

/FIN

FIN/ACK FIN_WAIT_1 CLOSING

ACK/ FIN/ACK

ACK/ after (2MSL)

FIN_WAIT_2

TIME_WAIT

La bonne modularit de la description prcdemment labore permet de limiter le nombre et la porte des modications ncessaires pour prendre en compte ce nouveau scnario.

154

UML 2

Chapitre

Diagramme dactivits
1. 2. 3. 4. Action ................................... Activit ................................. Flot de contrle ...................... Mcanismes avancs ............. 156 160 161 171

Les diagrammes dactivits permettent de spcifier des traitements a priori squentiels. Ils offrent un pouvoir dexpression trs proche des langages de programmation objet : spcification des actions de base (dclaration de variables, affectation), structures de contrle (conditionnelles, boucles), ainsi que les instructions particulires la programmation oriente objet (appels doprations, exceptions). Ils sont donc bien adapts la spcification dtaille des traitements en phase de ralisation. On peut aussi les utiliser de faon plus informelle pour dcrire des enchanements dactions de haut niveau, en particulier pour la description dtaille des cas dutilisation.

Problmes et exercices 1. Programmation en activits...... 177 2. Vente en ligne ........................ 178 3. Algorithmique ........................ 179 4. Vidoclub .............................. 182 5. Cache doprations................. 183

155

(1)

Action
Les modles servent dabord expliquer le fonctionnement dun systme, en fournissant une vision abstraite de ses comportements. Cependant, UML 2 a vocation aller au-del dune simple description informelle, en fournissant la possibilit de dcrire un systme un niveau de dtails qui permette son excution. Cela sinscrit dans le cadre du MDA (Model Driven Architecture), mis au point par lOMG, qui propose de centrer le dveloppement des systmes au niveau de leur modle. terme, lobjectif est de fournir un langage de spcication qui permette de se dtacher des langages de programmation classiques : les dveloppeurs de demain pourront utiliser UML pour dvelopper leur systme sans jamais descendre jusquau niveau de langages de programmation tels que Java, C++. Pour cela, UML doit tre dot de mcanismes offrant la prcision dun langage de programmation au niveau de la description de leffet des actions. Comme UML se veut universel, aucune syntaxe concrte nest propose dans la norme pour dcrire les actions : cest la charge des outils den dnir une ou dutiliser la syntaxe dun langage de programmation existant. Cependant, UML propose une dnition des instructions de base qui constituent le langage orient objet : cest la description des actions UML. Sans aller dans les dtails de la dnition, nous prsentons ici les grandes catgories dactions que propose la norme, et donnons des exemples concrets dinstructions offrant en C++ ou Java la mme smantique.

1.1 GESTION

DES APPELS DE PROCDURE

Ces actions de communication grent le passage et le retour de paramtres et les mcanismes dappels doprations synchrones et asynchrones.

Appel synchrone
Les actions de type call correspondent des appels de procdure ou de mthode. Dans les deux cas, il est possible de spcier des arguments et dobtenir des valeurs en retour. Ce type dappel est bloquant : lappelant attend la rponse de lappel avant de continuer son excution. Call operation correspond lappel dune opration sur un classeur. Call behavior correspond linvocation dun comportement spci laide dun diagramme UML, par exemple un diagramme dactivits ou dinteractions. Cela offre la possibilit, dans les diagrammes dactivits, de directement rfrer dautres types de diagrammes. Vous pouvez donc utiliser un diagramme de squence par exemple (imbriqu dans un diagramme dactivits) pour illustrer le comportement dune activit, et rciproquement. Les actions accept call et reply peuvent tre utilises du ct rcepteur pour dcomposer la rception de lappel. Reply correspond prcisment au return des langages de programmation.
EXEMPLE
Linvocation dune mthode, ou dune procdure plus complexe (un autre programme par exemple), correspond une instance de call. Pour dcrire un traitement rcursif, il faut utiliser une action call behavior pour r-invoquer le comportement en cours de description.

156

UML 2

Chapitre

Appel asynchrone
Les appels asynchrones de type send correspondent des envois de messages asynchrones : lappelant poursuit son excution sans attendre que lentit cible ait bien reu le message. Ce type dappel est bien adapt la modlisation de systmes matriels (communications sur un bus, interruptions dentre/sortie avec send signal) ou de protocoles de communication particuliers (UDP dans le domaine Internet, ou MPI dans le contexte multiprocesseur avec send object). Le broadcast signal permet dmettre vers plusieurs destinataires la fois, une possibilit rarement offerte par les langages de programmation. Laction symtrique ct rcepteur est accept event, qui permet la rception dun signal.
EXEMPLE
La smantique dun appel dans les langages objet (C++, Java) est toujours synchrone (cest-dire de type appel de procdure). Cependant, certains mcanismes de communication peuvent tre vus comme des appels asynchrones. En Java par exemple, la mthode notify() de la classe Object permet de signaler un autre thread Java loccurrence dun vnement. Cet appel nest pas bloquant : lexcution se poursuit sans attendre la bonne rception de lappel. Lautre thread nen est inform quaprs un dlai, quand la machine virtuelle llit pour sexcuter.

vnements particuliers
Laction raise exception permet de lever une exception au cours dun traitement. Une exception est un lment important de lapproche oriente objet ; elle permet de traiter des cas particuliers. Le comportement complet associ la gestion des exceptions est dcrit la section 4.2 de ce chapitre.
EXEMPLE
Le mot-cl standard throw (en Java et en C++) correspond prcisment la smantique dune action raise exception.

Un time event est un vnement temporel dclench aprs lcoulement dune certaine dure (spcie librement). On distingue graphiquement les actions associes une communication : send signal, accept event et accept time event. Cela permet de mieux mettre en valeur les changes entre les diagrammes de la spcication.

Figure 5.1
Les actions de communication.
Appui bouton lumire action accept event

clairer Affichage action send signal

attendre 2 secondes

action accept time event

teindre Affichage action send signal

Diagramme dactivits 157

1.2 MANIPULATION

DES VARIABLES

Les variables en UML sont toujours considres comme des instances dune classe : les actions proposes sur les variables correspondent donc des accs sur un objet. On retrouve ici toutes les oprations usuelles des langages de programmation.

Accs et mise jour


Les variables UML sont en principe des objets. Cependant, nous incluons aussi les types de base (int, oat, boolean, string), qui ne sont pas proprement parler des objets parmi les types de variables. Cela suppose que loutillage permettra de les grer par des prols ou des bibliothques. Par exemple, lopration i++ doit se rsoudre comme un appel de la mthode ++ sur lobjet i de la classe Int. UML propose en outre des variables dites multivalues , qui correspondent des collections, tries ou non. Leur introduction permet de faire mieux abstraction de limplmentation : elles peuvent reprsenter une liste, un tableau, une table associative, etc. de faon homogne. En Java, linterface Collection correspond bien la notion de variable multivalue. La lecture dune variable par read variable permet daccder son contenu. Laction clear variable permet de rinitialiser une variable. Si elle est multivalue, clear la vide de ses valeurs. Pour les variables monovalues, clear na pas dquivalent direct en programmation objet, si ce nest laffectation dun objet construit par dfaut la variable. Les actions dcriture permettent non seulement daffecter une valeur une variable, mais galement dajouter ou de supprimer des valeurs une variable multivalue (type collection dobjets). En consquence, les actions dcriture se dclinent en add variable value et remove variable value. Enn, une action value specication correspond la dnition dune constante ou dun littral (la valeur 3, le caractre a, la chane "hello").

Manipulations des objets


Pour la manipulation des objets, UML offre les actions de base associes la programmation objet. Create object et destroy object permettent la cration et la destruction dinstances dobjets. Il est ainsi possible de crer et de dtruire des variables locales, ainsi que des variables de porte plus grande (attribut statique de classe, par exemple). Une fois lobjet construit, laccs ses champs se fait laide dactions read structural feature, qui permettent daccder ses attributs comme ses oprations. Elles correspondent la notation pointe (monObjet.attribut1.laMthode()) des langages de programmation. Toute action qui se droule dans un contexte dinstance (non statique) peut accder linstance courante par read self (self correspond lidentit de lobjet courant, not this en Java et en C++, par exemple). Enn, des actions permettent de modier le type dun objet (reclassify object) ou de tester lappartenance dun objet un type donn (is classied). En gnral, il nest possible de reclassier un objet quen respectant larbre dhritage : typer une instance de classe drive en instance de classe de base est une opration toujours lgale. La rciproque est fausse.

158

UML 2

Chapitre

EXEMPLE

Ces mcanismes de typage sont frquemment utiliss dans limplmentation doprateurs de comparaison dnis au niveau dune classe de base.
public boolean equals (Object o) { if (! (o instanceof MaClasse) ) { return false; } else { MaClasse a = (MaClasse) o; return this.attrib1.equals(a.attrib1); } } #include <typeinfo> bool operator== (const ClasseBase & o) const { if ( typeid(o)!= typeid(MaClasse) ) { return false; } else { MaClasse * pa = (MaClasse *) &o; return this->attrib1 == pa->attrib1; } }

Gestion des pointeurs et rfrences


UML intgre la notion de pointeur, sous le nom link . Les actions associes permettent de manipuler directement une rfrence un objet (ou pointeur). On dclare, en gnral, un objet de type rfrence avec create link object et on lui affecte ensuite des valeurs avec create link. destroy link correspond un clear et ne dtruit pas lobjet link mais bien le lien vers lobjet quil rfrence. Laccs la valeur rfrence par le lien est assur par une action read link. Larithmtique des pointeurs nest pas totalement prise en charge, mais laction test identity permet de comparer des rfrences. Cette action teste lidentit (galit physique en mmoire) de deux objets. Cela revient comparer les adresses des objets.
EXEMPLE
En Java, tout objet est manipul par rfrence ; il nexiste pas de faon par ticulire de lire la valeur associe la rfrence : les deux notions sont confondues. En C++, un pointeur est explicitement manipulable. Une instance dobjet ou une rfrence sur objet se manipulent de la mme faon. Loprateur toile (*) de drfrencement correspond la notion de read link dUML.

Modication du modle de classes


La modication du modle de classes (ajout dattributs ou doprations) est assure par des actions de type add ou remove structural feature. Ces actions ont peu dintrt dans le cadre dune utilisation usuelle de langage objet. Lobjectif est de modier en cours dexcution la structure dune classe.
EXEMPLE
Smalltalk et Python sont deux exemples de langages objet qui permettent ce niveau de rectivit en cours dexcution. En Java, ce type dopration nest pris en charge quau niveau bytecode, pas directement au niveau des fonctionnalits standard du langage. Certaines bibliothques spcialises offrent cependant une interface de haut niveau pour raliser ces oprations. Elles sont utilises dans des approches rexives, comme le tissage daspect (Aspect Oriented Programming). Le modle de compilation statique de C++ ne permet pas ce type dopration, aprs la dclaration dune classe.

Diagramme dactivits 159

1.3 ACTION

OPAQUE
Une action opaque na pas de smantique ou de contrainte particulire, et na donc pas un sens dni par UML. Cest donc aux outils de savoir interprter ce type daction, qui dpasse le cadre dUML, limit aux actions prcites dans cette section. Les actions opaques permettent lintgration de librairies ou routines de traitements existants. Elles peuvent galement correspondre des traitements qui nont simplement pas t modliss. Parmi les actions opaques gurent galement les oprations sur les types machine de base : arithmtique entire et ottante, masques et vecteur de bits, etc. Bien que communes la majorit des langages de programmation, elles ne sont pas standardises en UML.

1.4 UML 2

ET LES ACTIONS
UML dnit des actions qui couvrent les instructions lmentaires dun langage de programmation, mais ne propose pas de mcanismes pour exprimer des boucles, des conditionnelles, des blocs dactions conscutives. Il sagit l dune volution importante dUML 2 par rapport aux versions prcdentes dUML 1.x, qui intgraient ces mcanismes dans les actions. En UML 2, la description de la structuration des actions est laisse aux activits. Ainsi, le modle est plus clair et mieux dcoupl. Les activits englobent les actions et offrent des mcanismes pour exprimer clairement le cheminement du ot de contrle. On peut cependant regretter labsence doprations explicitement dnies sur les types de base habituels (oprations arithmtiques, par exemple). On peut esprer quun prol UML standardis verra bientt le jour pour prendre en charge ces types.

(2)

Activit
DES TRAITEMENTS

2.1 MODLISATION

Les actions lmentaires sont dcrites sparment en UML. Les traitements complets sont dcrits par des activits, qui offrent une manire concise et sans ambigut de prsenter graphiquement un traitement squentiel, avec tout larsenal propos par un langage de programmation orient objet (actions de base, boucles et conditionnelles, appels de mthode, gestion des exceptions). Les activits donnent donc une description complte des traitements associs des comportements au sens interaction dUML. On les utilise couramment pour tiqueter les autres diagrammes (traitements associs aux messages des diagrammes de squence, transitions des diagrammes dtats-transitions) ou pour dcrire limplmentation dune opration dun classeur. Les diagrammes dactivits sont relativement proches des diagrammes dtats-transitions dans leur prsentation, mais leur interprtation est sensiblement diffrente. En particulier, ils offrent un support pour lexpression de mcanismes concurrents, mais ce nest pas l leur fonction premire.

160

UML 2

Chapitre

2.2 UNE

VISION TRANSVERSALE, DCOUPLE DE LA VISION STRUCTURELLE CLASSES/COMPOSANTS


La vision des diagrammes dtats-transitions est en effet oriente vers des systmes ractifs, les transitions tant dclenches par la rception de sollicitations, sans que la source de lvnement soit spcie. Cela est bien adapt aux systmes concurrents, o chaque composant a son propre ot de contrle, par exemple les systmes bass sur des objets actifs ou les systmes matriels. Leur avantage est de spcier sans ambigut leffet de toute action sur le composant, sans a priori sur le comportement de lenvironnement. Mais ils ne donnent pas une vision satisfaisante dun traitement faisant intervenir plusieurs composants ou classes, et doivent tre complts par des scnarios dinteraction, usuellement dcrits laide de diagrammes de squence. Au contraire, les diagrammes dactivits permettent une description centre sur le traitement, en saffranchissant (partiellement) de la structuration de lapplication en classeurs.

2.3 PROGRAMMATION

STRUCTURE

Un ot de contrle est associ chaque processus ou thread dune application : il reprsente le curseur dexcution (program counter) qui excute les instructions dun programme. un instant donn, il excute une certaine instruction ; le choix de linstruction suivante excuter est dtermin par les structures de contrle du langage (if/else, for, while, switch/ case). Les activits capturent de faon graphique ce comportement a priori squentiel de lexcution. En mettant laccent sur le traitement, la vision des diagrammes dactivits se rapproche des langages de programmation procduraux type C ou Pascal. Une activit se comporte par bien des points de vue comme une procdure, possdant des arguments en entre et des valeurs de sortie et pouvant causer des effets de bord sur les variables accessibles depuis leur contexte. Il est possible, dans un premier temps, de raisonner purement sur les traitements et, lors dune phase de conception dtaille, daffecter les diffrentes activits recenses des classeurs du systme.

(3)

Flot de contrle
ET TRANSITION
La vision des diagrammes dactivits est centre sur les ots de contrle. On y trouve deux lments fondamentaux : Les activits, reprsentes par un rectangle aux coins arrondis, dcrivent un traitement. Le ot de contrle reste dans lactivit jusqu ce que les traitements soient termins. On peut dnir des variables locales une activit et manipuler les variables accessibles depuis le contexte de lactivit (classe contenante en particulier). Les activits peuvent tre imbriques hirarchiquement : on parle alors dactivits composites.

3.1 ACTIVIT

Diagramme dactivits 161

Les transitions, reprsentes par des ches pleines qui connectent les activits entre elles, sont dclenches ds que lactivit source est termine et dterminent la prochaine activit dclencher. Contrairement aux activits, les transitions sont franchies de manire atomique, en principe sans dure perceptible.
EXEMPLE
La commande Cet exemple fait apparatre un certain nombre de possibilits des diagrammes dactivits. On y trouve la description dun traitement Passer Commande. Les trois cadres, appels lignes deau , permettent de situer les actions par rapport aux entits du systme : on identie trois intervenants dans ce traitement, savoir le client, le ser vice comptable et le service livraison. Les cercles noirs pleins dsignent un tat initial, utilis pour dbuter le traitement. Les cercles contenant un point noir dsignent des tats naux, o le traitement est considr comme termin. Laction se droule comme suit : le client commence par passer une commande, ce qui donne lieu llaboration dun devis par le service comptable. Llaboration du devis est elle-mme dcompose en deux sous-activits : vrier la disponibilit des produits commands et calculer le prix de la commande. Pour mieux faire apparatre la transmission du devis au client, on fait gurer un nud dobjets. Cela reprsente un ux de donnes changes entre le service comptable et le client. Devis est le nom dune classe du systme : les ots de donnes sont typs. Le client peut ensuite dcider de modier sa commande (retour dans lactivit initiale Passer commande), de lannuler (passage dans ltat nal, signiant la n de ce traitement), ou de valider le devis. Sil valide, deux actions peuvent tre engages en parallle : la prparation de la commande par le service livraison et le traitement de la facturation et du paiement. Le ser vice comptable cre une facture quil envoie au client (lobjet facture transmis est alors dans ltat mise). Celui-ci effectue le paiement et renvoie la facture (qui se trouve prsent dans ltat rgle). Quand la commande est prte et le paiement du client conrm (synchronisation par rendezvous de ces deux activits), la commande est livre au client et le traitement sachve.

Notation
Une activit UML est reprsente par un rectangle aux coins arrondis (gure 5.3) et contient la description textuelle des actions de base quelle ralise, ou simplement son nom si le niveau de spcication nest pas encore assez prcis pour dtailler les actions. Aucune syntaxe spcique nest propose dans la norme pour lexpression de ces actions : on utilise le plus souvent une syntaxe proche dun langage de programmation ou, dfaut, du pseudo-code. Les activits sont lies par des transitions reprsentes par des arcs orients pouvant porter des gardes, qui reprsentent le cheminement du ot de contrle de lapplication. Certaines actions sont distingues par un graphisme particulier (gure 5.1).

162

UML 2

Chapitre

Figure 5.2
La commande.

Client

Service comptable

Service livraison

tat Initial Passer Commande tablir Devis Vrifier disponibilit Sous-activit Lignes deau

Calculer Prix [modifier] Activit composite Transition Devis Garde Valider [valider] [annuler] Fork Activit

Facture [mise] Rgler facture

tablir facture

Prparer Commande

Facture [rgle] Nud Objet Join Invariant dtat

Valider Paiement

Livrer Commande

Clturer Dossier

tat final

Figure 5.3
Notation des activits.

Flot de contrle entrant

Flot de contrle sortant

Prparer Commande

Activit

Diagramme dactivits 163

3.2 STRUCTURES

DE CONTRLE

Structure de contrle conditionnelle


La faon la plus naturelle dexprimer les conditions est dutiliser des transitions munies dune garde : de telles transitions ne peuvent tre empruntes que si la garde svalue vrai. Une garde est un test pouvant faire intervenir les variables accessibles depuis le contexte de lactivit. En principe, une garde na pas deffets de bord, car elle peut tre value plusieurs fois. On peut ajouter une garde toute transition dun diagramme dactivits. Elle est note entre crochets. Si plusieurs transitions sont simultanment franchissables, le choix de la transition emprunte est indterministe ; en gnral, il est donc prfrable de sassurer quune seule transition la fois est franchissable. On peut utiliser une clause [else] dans une garde, qui est valide si et seulement si toutes les autres gardes des transitions ayant la mme source sont fausses. Les gardes peuvent porter sur des transitions ayant pour source une activit. Cependant, si lon veut mieux mettre en valeur le branchement conditionnel, on peut utiliser un point de jonction, reprsent par un losange. Les points de jonction expriment un aiguillage du ot de contrle : ils peuvent avoir plusieurs transitions en entre comme en sortie. Ils ont la smantique dun if/endif ou dun switch/case des langages de programmation. Ce sont des tats dits de contrle (comme les tats initiaux ou naux), dans lesquels le ot de contrle ne sattarde pas : le franchissement dune transition entre une activit et la suivante est globalement atomique, mme si lon traverse des points de jonction.
EXEMPLE
Le distributeur de billets Cet exemple illustre diffrentes reprsentations des alternatives. Aprs la vrication prliminaire, deux activits sont potentiellement dclenches : la restitution de la car te si la vrication choue ou lactivit taper PIN (Personal Identication Number) sinon. Aprs le contrle du code PIN, on trouve trois alternatives, connectes un point de dcision ; une seule dentre elles sera utilise. Enn, la note portant le mot-cl decisionInput indique que les gardes sur les transitions aprs le point de choix comparent la variable autorisation accorde oui ou non. Cet exemple est modlis un niveau relativement lev dabstraction, les actions tant exprimes en langage naturel. Il dcrit de faon concise un comportement relativement complexe. Ce niveau de description conceptuelle est bien adapt la spcication dtaille des cas dutilisation, car il rsume de faon synthtique plusieurs scnarios.

164

UML 2

Chapitre

Figure 5.4
Le distributeur automatique de banque.

external Client

Insrer Carte

Vrification prliminaire

[chec]

[else] Taper PIN [Code faux et essai < 3]

Contrler code [else] Saisir montant [Code bon]

Avaler Carte

Obtenir Autorisation [non] Restituer Carte decisionInput Autorisation accorde [oui] Dlivrer Billets

Les points de dcision peuvent aussi modliser la n dune alternative. On les appelle alors points de dbranchement .
EXEMPLE
Compter les mots, les lignes, les caractres Lexemple de la gure 5.5 illustre la possibilit de reprsenter le ot de contrle dun programme laide dun diagramme dactivits. Lactivit appele wc ralise le comportement de loutil Unix wc (word count). On utilise ici la notation frame (qui sert aussi dans les diagrammes de squence) pour la reprsenter, et le strotype activity. On dclare les variables locales de lactivit, nc, nw, nl, qui servent compter respectivement le nombre de caractres, de mots et de lignes de lentre. On utilise une variable c de type char pour stocker le dernier caractre lu de lentre (par la fonction getchar()). Ltat courant de la lecture (dans mot ou hors mot) est reprsent par une variable boolenne inWord. On suppose ici que print, getchar, isWhitespace, lopration dincrment ++ sont fournies (sous la forme dactions opaques). Comme on le voit sur cet exemple, les diagrammes dactivits dun niveau de spci cation dtaille permettent datteindre le pouvoir dexpression de langages de programmation classiques.

Diagramme dactivits 165

Figure 5.5
Compter les lignes, les mots et les caractres.

activity wc

nc : int ; nw : int ; nl : int ; c = getchar();

c : char ;

inWord : bool

nc = nw = nl = 0; inWord = false;

nc++; decisionInput c

print nc nw nl;

[EOF] [else] [\n] [else] [true] nl++; [inWord==true] [else] [else] inWord = false; decisionInput isWhitespace(c)

[inWord==false]

inWord=true; nw++;

Activit structure
La norme prvoit galement des activits dites structures , qui utilisent les structures de contrle usuelles (conditionnelles et boucle) travers une syntaxe qui dpend de loutil. La syntaxe prcise de ces annotations, comme celle des actions de base, nest donc pas dnie dans la norme : on utilise du pseudo-code ou la syntaxe dun langage de programmation.
EXEMPLE
Avec une syntaxe C++, on dcrit une activit contenant une boucle (le calcul du prix total dune facture) et une activit contenant une conditionnelle (une implmentation possible de isWhitespace() de lexemple prcdent). Les arguments et valeurs de retour sont dcrits laide de pins, prsents en dtail la section 3.4.

Figure 5.6
Activit structure.
total=0; for (int i=lignes.size()-1 ; i >= 0 ; i--) total += lignes[i].prixUnitaire * lignes[i].quantit if(c== || c== \t || c== \n ) return true; else return false; total:float c : char bool
| | | | | |

lignes : vector<ligneCommande>

Ce type dactivit est fourni par commodit, mais son utilisation rend peu visible le cheminement du ot de contrle.

3.3 ACTIVIT

ET CLASSEUR
Les activits peuvent tre utilises pour des descriptions de diffrents niveaux de dtails, de la plus lmentaire (description conceptuelle dun comportement par exemple) la plus fouille, faisant alors intervenir des actions UML pour tre la hauteur de ce que permet un langage de programmation. Une de leurs utilisations principales est de dcrire leffet doprations de classeur. Les activits peuvent, dans un premier temps, ne pas avoir un contexte bien dni. Cest le cas dans lexemple du distributeur de banque : le systme complet du DAB ntant pas encore dcompos en sous-lments, seules les activits affrentes au client ont t places sur une

166

UML 2

Chapitre
ligne deau. Une description plus dtaille ncessiterait sans doute de dcomposer plus nement les actions, en vue de reprsenter plus explicitement les appels dopration sur les composants du systme (lecteur de cartes, serveur dauthentication, imprimante pour le ticket). Sur le diagramme de la gure 5.4, le mot-cl extern, sis au-dessus de la partition du client, indique que ce dernier nest pas un lment du systme en cours de conception. Les lignes deau (ou partitions) permettent dattribuer les activits des lments particuliers du modle. Une partition peut elle-mme tre dcompose en sous-partitions. La liste suivante runit les types standard dune tiquette de partition : Classeur. Les activits de la partition sont sous la responsabilit du classeur indiqu : le contexte de lactivit est donc celui du classeur concern. Lappel effectif de lactivit dans un scnario de comportement doit se faire sur une instance du classeur. Instance. En plus des contraintes imposes par la notion de classeur, lappel effectif doit se faire sur linstance cite. Attribut et valeur. Ce cas est assez diffrent des prcdents. On a toujours au moins deux niveaux de partition : la partition englobante donne le nom de lattribut concern, et ses sous-partitions spcient une valeur de lattribut.
EXEMPLE
Utilisation de partitions Il est possible dafner le modle de la commande prsent prcdemment en spciant plus nement le type des lignes deau. Il sagit dindiquer, dune part, que les activits du service comptable sont rattaches une instance qui a, pour lattribut libellService de type Service, la valeur Service Comptable et, dautre part, que le client ne fait pas partie intgrante du systme tudi.

Figure 5.7
Lignes deau.

external Client

attribute libellService : Service Service comptable Service livraison

Les activits peuvent appartenir plusieurs partitions, si ces dernires fournissent une information qui nest pas conictuelle (par exemple, une activit donne ne peut appartenir qu un unique classeur). On peut mme cumuler graphiquement des partitions en les plaant horizontalement et verticalement.
EXEMPLE
Partitions multidimensionnelles La version simplie de la commande prsente la gure 5.8 exprime que la rception des commandes se fait au sige social Paris, que la validation du paiement est ralise par le service comptable de Roubaix, et que les commandes sont prpares et livres par un ser vice livraison situ galement Roubaix. Lutilisation de partitions multidimensionnelles ne facilite pas la lisibilit des diagrammes.

Diagramme dactivits 167

Figure 5.8
Partitions multidimensionnelles.

Client

Service comptable

Service livraison

Valider Commande

Enregistrer Commande

Paris "attribute" siteExploitation : Localisation

Facture [mise] Rgler Facture

tablir Facture

Facture [rgle]

Valider Paiement

Prparer Commande

Roubaix

Clturer Dossier

Livrer Commande

Il est possible de spcier la partition laquelle appartient une activit directement dans ltiquette de lactivit, entre parenthses. Si une activit est ainsi tiquete, cette information prvaut sur lappartenance ventuelle une partition graphiquement reprsente.
EXEMPLE
Partition explicite Cette notation est moins encombrante graphiquement, mais met moins bien en valeur lappartenance de groupes dactivits un mme conteneur.
external (Client) Rgler facture

Figure 5.9
Partition explicite.

(Service Comptable) Etablir facture

(Service Livraison) Livrer Commande

3.4 ARGUMENT

ET VALEUR RETOURNE

Si les diagrammes dactivits prsents jusquici montrent bien le comportement du ot de contrle, le ot de donnes napparat pas clairement. Or, cest un lment essentiel des traitements : si une activit est bien adapte la description dune opration dun classeur, il faut un moyen de spcier les arguments et valeurs de retour de lopration. Cest le rle des pins, des nuds et des ots dobjets associs.

168

UML 2

Chapitre

Pin
Pour spcier les valeurs passes en argument une activit et les valeurs de retour, on utilise des pins. Un pin reprsente un point de connexion pour une action : laction ne peut dbuter que si lon affecte une valeur chacun de ses pins dentre ; quand elle se termine, une valeur doit tre affecte chacun de ses pins de sortie. La smantique associe est celle des langages de programmation usuels : les valeurs sont passes par copie, une modication des valeurs dentre au cours du traitement de laction nest visible qu lintrieur de lactivit. Un pin est reprsent par un petit carr attach la bordure dune activit. Il est typ et ventuellement nomm. Il peut contenir des ches indiquant sa direction (entre ou sortie) si cela nest pas dtermin par le contexte dutilisation de lactivit.
EXEMPLE
Utilisation de pins Soit lactivit reprsentant lopration produit entre deux entiers a et b. On utilise un pin pour reprsenter chaque argument, et un pin de sortie pour reprsenter la valeur retourne.

Figure 5.10
Reprsentation de pins.

a:int b:int

res = a * b ;

res:int

Les valeurs associes aux pins peuvent tre utilises comme les variables du contexte dans les traitements associs lactivit. Introduisez un pin par argument du traitement. Vous pouvez ainsi de dnir des traitements paramtrs, ce qui manquait cruellement aux versions prcdentes dUML. Les pins servent galement reprsenter des mcanismes dexceptions. Un triangle signale un pin dexception.
EXEMPLE
Reprsentation des pins dexceptions La mthode elementAt de la classe Vector de la librairie standard Java renvoie llment du vecteur situ lindice donn en argument, mais peut chouer si cet indice est ngatif ou au-del de la taille courante du vecteur. On met alors une exception.

Figure 5.11
Pin dexception.
index:int (java.util.Vector) elementAt IndexOutOfBoundsException o : Object

Vous avez donc les moyens de reprsenter graphiquement une opration dun classeur, avec sa signature complte : arguments, type de retour et exceptions potentiellement leves. Vous avez en outre la possibilit de dnir une activit comme appartenant une classe. En conclusion, les mcanismes essentiels de la programmation oriente objet sont prsents dans les diagrammes dactivits.

Nud et ot dobjets
Un ot dobjets permet de passer des donnes dune activit une autre. De fait, un arc qui a pour origine et destination un pin correspond un ot dobjets. Le type du pin rcepteur doit tre parent (au sens hritage) du type du pin metteur ; le ot dobjets est lui-mme typ. Il est possible de mieux mettre en valeur les donnes par lutilisation dun nud dobjets dtach dune activit particulire. Un nud dobjets, reprsent par un rectangle, est un

Diagramme dactivits 169

conteneur typ qui permet le transit des donnes. Il sert galement de stockage : il peut contenir plusieurs instances dobjet, la manire dun tampon (buffer). Un nud dobjets (ou un pin) peut imposer des contraintes, que doivent vrier les objets quil contient. Elles sont exprimes sous la forme dinvariants dtat, nots entre crochets. Implicitement, tout arc ayant pour source ou destination un nud dobjets est un ot dobjets plutt quun ot de contrle. Un ot dobjets peut porter une tiquette mentionnant deux annotations particulires : transformation indique une interprtation particulire de la donne transmise par le ot. selection indique lordre dans lequel les objets sont choisis dans le nud pour le quitter. Une annotation de slection peut galement gurer sur un nud dobjets : lordre spci est alors commun tout arc ayant pour source ce nud.

Figure 5.12
Deux notations pour un ot de donnes.

:Type1

:Type1

Type1

Figure 5.13
Annotations des ots de donnes et invariants dtat.

selection priorit maximale, FIFO priorit gale remplir commande :Commande [remplie] expdier commande :Commande [remplie]

transformation Commande.client clturer commande :Commande [clture] expdier reu au client :Client

Enn, certains ots dobjets correspondent mieux la notion de ot continu de donnes : ils portent ltiquette {stream} ou ont pour cible un pin de type {stream} (reprsent par un carr noir plein). Le comportement usuel dune activit consiste consommer un objet sur chaque pin dentre, sexcuter et fournir une valeur sur chaque pin de sortie. Une activit peut cependant consommer (respectivement mettre) plusieurs donnes sur ses pins dentre (respectivement de sortie) qui sont du type stream.
EXEMPLE
Filtres Unix La plupart des commandes standard Unix sont conues comme des ltres, qui lisent sur leur entre standard stdin et crivent sur leur sortie standard stdout. Le signalement des erreurs passe par un troisime ux : stderr. Il est possible de chaner les commandes, ce qui permet de construire facilement des commandes plus puissantes.

Figure 5.14
Le chanage des commandes tar et gzip permet de crer des archives compresses.
Liste<fichiers>

"tar | gzip" stdout tar stdin stderr stderr gzip stdout

stdout

stderr {stream}

deux notations quivalentes de stream

170

UML 2

Chapitre

(4)

Mcanismes avancs
Les constructions prsentes la section 3 sont sufsantes pour la majorit des usages. Ce jeu dlments de base constitue le cur du formalisme des diagrammes dactivits. Il est recommand de bien comprendre ces mcanismes avant daborder cette section, qui prsente des concepts plus complexes proposs par les diagrammes dactivits.

4.1 CONCURRENCE
La vocation premire des diagrammes dactivits est de dcrire des traitements a priori squentiels : on ne dbute lactivit aprs une transition que lorsque celle qui la prcde est termine. Cependant, il est possible de dcrire des mcanismes concurrents laide de diagrammes dactivits. Cela ne signie pas ncessairement que limplmentation est concurrente, mais plutt que les actions dcrites ne sont pas lies par une dpendance causale : lordre dexcution na pas dincidence sur le comportement global. Dans lexemple de la commande prsent la section 3.1, lactivit prparer commande peut tre ralise avant ou aprs lactivit tablir facture, ou mme simultanment. La gestion de la concurrence ajoute deux nouveaux lments graphiques aux diagrammes dactivits : Les barres de synchronisation. Elles sont reprsentes par une barre noire paisse et courte. Plusieurs transitions peuvent avoir pour source ou pour cible une barre de synchronisation. Lorsque la barre de synchronisation a plusieurs transitions en sortie, on parle de transition de type fork, qui correspond une duplication du ot de contrle en plusieurs ots indpendants ; quand la barre de synchronisation est atteinte, un jeton de contrle est produit sur chaque arc de sortie. Quand la barre de synchronisation a plusieurs transitions en entre, on parle de transition de type join, qui correspond un rendez-vous entre des ots de contrle ; la transition ne peut tre franchie que si un jeton de contrle est prsent sur chacune de ses entres. Pour plus de commodit, il est possible de fusionner des barres de synchronisation de type join et fork, et donc davoir sur une mme barre plusieurs transitions entrantes et sortantes. Dans tous les cas, le franchissement des transitions se fait de manire atomique, la barre de synchronisation ne stocke pas les jetons : ils restent dans les activits en amont jusqu ce que la transition puisse tre franchie. Les nuds de contrle de type ow nal. Ils sont reprsents par un cercle contenant une croix et correspondent la n de vie dun jeton de contrle. Un jeton de contrle qui atteint un tel nud est dtruit. Les autres ots de contrle ne sont pas affects. Au contraire, si un ot de contrle atteint un nud de contrle nal, tous les autres ots de contrle de lactivit sont interrompus et dtruits.
EXEMPLE
Fabrication dun produit manufactur Cet exemple montre une barre de synchronisation de type fork et des nuds de contrle ow nal. Il reprsente une procdure de fabrication dun produit manufactur. Les pices ncessaires lassemblage sont produites squentiellement par lactivit Fournir pice. Ds quune pice est prte, elle peut tre monte. Le franchissement de la barre de synchronisation produit deux jetons de contrle : lun ralise lactivit Monter pice, lautre soccupe de fournir la pice suivante si toutes les pices nont pas encore t fournies. Quand il ne reste plus de pice fournir, le ot se termine. Lactivit

Diagramme dactivits 171

Monter pice peut avoir des dures variables ; chaque fois quelle se termine, on teste si le montage est termin ou non. Une fois la dernire pice monte, le produit est emball et lactivit englobante se termine. Si ce diagramme suggre lexistence de concurrence, ce nest l quune possibilit dimplmentation : un seul oprateur physique peut raliser lensemble des activits (de faon squentielle) sans dvier de la smantique du modle.

Figure 5.15
Mcanismes exprimant la concurrence.
Fournir Pice Monter Pice [montage fini] [else] Emballer

[manque pice]

[else]

Les barres de synchronisation permettent donc dexprimer que des actions peuvent dbuter en parallle, alors que les transitions ordinaires des diagrammes dactivits imposent une excution squentielle. Les transitions de type join imposent, au contraire, dattendre la n dun ensemble dactivits avant de poursuivre lexcution.

4.2 EXCEPTIONS
Les exceptions sont un concept important en programmation oriente objet : elles permettent dinterrompre un traitement quand une situation qui dvie du traitement normal se produit et assurent une gestion plus propre des erreurs qui peuvent se produire au cours dun traitement. Un exemple typique est la gestion de la division par zro dans une opration arithmtique : si lon dclare une opration oat diviser (oat dividende, oat diviseur), comment signaler lappelant quune erreur de dbordement se produit quand le diviseur vaut zro ? On ne peut utiliser une valeur de retour particulire que lappelant pourrait tester car toutes les valeurs de retour sont potentiellement valides. La solution prconise est donc de recourir une exception, qui ne correspond pas une valeur de retour de la signature normale de lopration. Lappelant a alors le choix, quand il appelle lopration diviser, de traiter lexception ou de la laisser remonter son propre appelant. Une exception qui nest traite aucun niveau correspond une faute du programme. Dans la plupart des langages orients objet, elle induit la n du processus ; en UML, le comportement nest pas spci, mais le modle est alors considr comme incomplet ou mal form.

Dnition : gestion des exceptions


Toute activit peut avoir un ou plusieurs pins dexception (not par un triangle). La leve de lexception se reprsente par une transition qui vise le pin dexception, ou par une annotation textuelle, dans le cas dactivits structures, dont la forme dpend de loutil utilis (mot-cl throw par exemple). Lorsquune exception est leve, lexcution de lactivit en cours est interrompue sans gnrer de valeurs de sortie. la place, un jeton de donnes reprsentant lexception est gnr. Le mcanisme dexcution recherche alors un gestionnaire dexception susceptible de traiter ce type dexception ou une de ses classes parentes. On dit dun gestionnaire dexception (ou clause catch des langages de programmation) quil protge une activit.

172

UML 2

Chapitre

Dnition : gestion des exceptions (suite)


On examine dabord lactivit qui a donn lieu la leve de lexception. Si un gestionnaire dexception existe, il est invoqu avec pour argument ladite exception. Il doit avoir les mmes pins de sortie, en nombre et en type, que le bloc quil protge. Un gestionnaire dexception se reprsente par une activit ordinaire, munie dun pin dentre du type de lexception quil gre, et lie au bloc (activit) quil protge par un arc en zigzag. Quand lexcution du gestionnaire se termine, lexcution se poursuit comme si lactivit protge stait termine normalement, avec les valeurs de sortie du gestionnaire en lieu et place de celles du bloc protg. Il est inutile de faire gurer des transitions depuis lactivit reprsentant le gestionnaire dexception. Si lactivit qui a lev lexception nest pas protge, lexception interrompt lactivit englobante et un gestionnaire dexception est recherch ce niveau. Ce mcanisme de propagation se poursuit jusqu ce quun gestionnaire adapt soit trouv (ou que lon quitte lapplication).

EXEMPLE

Traitement des exceptions dans le calcul du produit dune matrice par un vecteur Cet exemple montre un mcanisme de gestion dexceptions. Lactivit protge calcule un produit dune matrice par un vecteur en deux tapes : on inverse dabord la matrice argument m, puis on ralise le produit par le vecteur argument v. Linversion de matrice est susceptible de lever une exception si lopration est impossible (discriminant nul par exemple). Linversion et le produit sont susceptibles de provoquer un dbordement de capacit de ottants. On protge lensemble du bloc par deux gestionnaires dexception distincts : selon lexception leve, on fournit une constante (de type vecteur) diffrente. Dans tous les cas, laction afcher vecteur est ralise la n du traitement.

Figure 5.16
Gestionnaire dexception.

m : matrice

v : vecteur ExceptionMatriceSingulire rendre la constante vecteur1 res : vecteur

inverser matrice : matrice m : matrice v : vecteur

Deux notations quivalentes

calculer produit

rendre la constante vecteur2 ExceptionDbordement res : vecteur

res : vecteur

afficher vecteur

Les exceptions sont des classeurs part entire et peuvent, ce titre, porter des informations sous la forme dattributs, et des oprations. Vous pouvez galement dcrire des arbres dhritage dexceptions. Cela permet de spcier des messages dtaills associs aux erreurs et des donnes supplmentaires dcrivant lesdites erreurs. Un gestionnaire dexception spcie le type dexception quil est capable de traiter : toute exception drivant de ce type est galement traite par un tel gestionnaire.

Diagramme dactivits 173

EXEMPLE

Spcication des exceptions Java Cet extrait de la spcication des exceptions Java illustre le fonctionnement des arbres dhritage dexceptions. Toutes les exceptions en Java drivent de la classe Exception du paquetage java.lang ou de linterface Throwable du mme paquetage. Linterface Throwable dnit des oprations permettant de dterminer lorigine de lexception, telles que printStackTrace, qui afche les numros de ligne du source qui ont abouti la leve de lexception. La classe Exception est munie dun message s, qui dcrit prcisment lexception leve. Les exceptions correspondant des problmes dentre/sortie drivent de la classe IOException. Parmi ces erreurs, la classe InterruptedIOException porte un attribut qui indique ltat du transfert de donnes au moment de la leve de lexception. Un gestionnaire dexception qui accepte en entre la classe gnrale Exception est aussi capable de grer des IOException, des EOFException, etc.

Figure 5.17
Hritage et exceptions.

interface Throwable +printStackTrace() ...

Exception message : String +getMessage ()

IOException

InterruptedIOException bytesTransferred : int

EOFException

Rgion interruptible et interruption


Le mcanisme de gestion dexceptions permet de les reprsenter telles quon les trouve dans les langages de programmation objet. UML propose un deuxime mcanisme analogue, mais moins prcis, de gestion des interruptions : les rgions interruptibles. Il est mieux adapt aux phases de modlisation conceptuelle ou de modlisation mtier, qui demandent une moins grande prcision. Le but est de reprsenter graphiquement un enchanement nominal et une alternative qui interrompt le cours du traitement. Une rgion interruptible est reprsente par un cadre arrondi en pointills. Si lvnement dinterruption se produit, toutes les activits en cours dans la rgion interruptible sont stoppes et le ot de contrle suit la che en zigzag qui quitte la rgion. Aucune contrainte sur la suite du traitement nest impose : a priori, lactivit ainsi interrompue nest pas reprise. Cette smantique est diffrente de celle des gestionnaires dexception et correspond mieux aux interruptions dans les activits mtier.
EXEMPLE
Dans cet exemple, lactivit dbute la rception dune commande dun client. Toute la suite de lactivit grer commande est interruptible : le client est libre dannuler sa commande tout moment. Sil passe lordre dannuler, le dossier est effac. Une fois que le paiement est effectif et que la commande est prte, il devient impossible de lannuler : la transaction est dment enregistre et le dossier cltur. Aprs rception dun ordre dannulation, et durant lactivit annuler dossier, lactivit traiter paiement peut continuer sexcuter. Cependant, elle est, elle aussi, interrompue quand le ot de traitement a ni dannuler le dossier et que ltat nal est atteint (cela termine tous les ots de lactivit).

174

UML 2

Chapitre

Figure 5.18
Rgion interruptible.

activity grer commande

Ordre dannuler

annuler dossier

Commande

crer dossier

prparer commande

clturer dossier

traiter paiement client

4.3 SQUENCE

ET ITRATION

Une zone dexpansion, graphiquement reprsente par un cadre en pointills, exprime une action rpte sur chaque lment dune collection. Une collection peut tre implmente par un tableau ou une liste par exemple. Le type des objets contenus dans la collection doit tre connu. La collection est passe la zone dexpansion travers un pin dexpansion, graphiquement reprsent par un rectangle divis en compartiments, cens voquer la notion de liste dlments. Lactivit lintrieur de la rgion dexpansion est excute une fois pour chaque item de la collection, la manire dun foreach des langages Python, Perl ou Fortran. Cette activit interne doit prendre en entre un objet respectant le type de la collection : vu de lextrieur de la rgion, le pin dexpansion est de type Collection<Objet>, mais vu de lintrieur, il est de type Objet. chaque excution de lactivit interne, sa valeur de retour est insre dans la collection de sortie la mme position (indice) que son entre. Lactivit interne peut galement se terminer sans rendre de valeur, ce qui correspond un mode ltre : la collection rsultante compte alors moins de valeurs que lentre. Une zone dexpansion peut tre de lun des trois types suivants, signal par un mot-cl plac dans langle de la rgion dexpansion : parallel. Les excutions de lactivit interne sur les lments de la collection sont indpendantes et peuvent tre ralises dans nimporte quel ordre ou mme simultanment. Une implmentation sur une architecture parallle peut donc efcacement raliser ce traitement. iterative. Les occurrences dexcution de lactivit interne doivent senchaner squentiellement, en suivant lordre de la collection dentre. Si cette dernire na pas dordre de parcours bien dni (table de hachage par exemple), un ordre quelconque est choisi de faon indterministe. stream. Les lments de la collection sont passs sous la forme dun ux de donnes lactivit interne, qui doit tre adapte aux traitements de ux. Cela permet de contrler plus nement le paralllisme des excutions.
EXEMPLE
Passer un texte en majuscules Cette activit permet de passer un texte en majuscules. Quel que soit lordre des traitements, le rsultat est correct. Elle porte donc le mot-cl parallel.

Diagramme dactivits 175

Figure 5.19
Zone dexpansion.

string : char[] parallel c : char if (c >= a && c <= z) return c-a+A; else return c; :char

: char[]

UML 2 a introduit le mcanisme des zones dexpansion pour permettre une meilleure expression du paralllisme des actions.

Conclusion
La vue offerte par les diagrammes dactivits est centre sur les traitements. Elle permet de modliser efcacement le cheminement de ots de contrle et de ots de donnes. Les apports importants dUML 2 au niveau de ces diagrammes assurent lexpression prcise du comportement : la gnration de code est un objectif central dans ces diagrammes. En fournissant une vision abstraite des traitements, la modlisation des activits ne xe cependant pas compltement les choix dimplmentation. Lexpression de mcanismes concurrents, par exemple, nimpose pas leur ralisation sur une architecture parallle. De mme, la manipulation de variables multivalues et de collections permet un bon niveau dabstraction. Les diagrammes dactivits sont particulirement utiles dans la phase de conception pour la description dtaille des cas dutilisation. On utilise alors une syntaxe libre, qui dcrit des actions conceptuelles de haut niveau. Ils sont galement utiles dans la phase de ralisation pour la description prcise des traitements, avec un niveau de dtails qui se rapproche dune spcication pleinement excutable. On utilise alors une syntaxe inspire dun langage de programmation pour dcrire les actions et lon peut prciser nement la gestion des exceptions ou le passage des paramtres. La description graphique des traitements permet de mieux cerner le cheminement des alternatives. Les mcanismes dimbrication et dappels (call) permettent de prserver une certaine concision. Cependant, vitez les diagrammes dactivits quand le traitement est trs linaire : une description textuelle de lenchanement est alors sufsante dans la plupart des cas. Arriv ce stade du livre, sept diagrammes ont t prsents : le diagramme des cas dutilisation, celui des classes et des objets, le diagramme de squence et de communication, le diagramme dtats-transitions et, enn, le diagramme dactivits. Ils permettent de modliser quasiment tout systme. Deux autres diagrammes ont volontairement t relgus dans les annexes : le diagramme de composants et celui de dploiement. Ils sont, en effet, sufsamment simples pour ne pas faire lobjet dun chapitre entier. Le chapitre suivant, quant lui, prsente comment tous ces diagrammes sassemblent et se compltent pour donner une vision globale et cohrente dun systme. La partie pratique de ce chapitre est constitue dune tude de cas.

176

UML 2

Chapitre

Problmes et exercices
Les exercices suivants couvrent les principaux concepts des diagrammes dactivits.

EXERCICE 1

PROGRAMMATION

EN ACTIVITS

1. Les chanes de caractres du langage C sont codes comme un tableau de caractres non nuls, termin par un caractre \0. Par exemple, la chane s="hello!" est code comme suit :
s[0] h s[1] e s[2] l s[3] l s[4] o s[5] ! s[6] \0

Dcrivez une activit implmentant la fonction strlen, qui prend en entre un tableau de caractres et rend un entier correspondant la taille de la chane. Exemple : strlen("hello!")=6. 2. Proposez le diagramme dactivits qui compte les mots, les lignes et les caractres de son entre. La fonction getchar() lit le prochain caractre disponible sur lentre. Sil sagit du caractre spcial EOF, le programme afche ses rsultats et se termine. Lopration bool isWhitespace(c:char) rpond vrai si le caractre pass en argument est considr comme un espace. 1. Le traitement est relativement simple : on itre sur le tableau de caractres de lentre ; quand la valeur du caractre est \0, on rend lindex courant. Une implmentation efcace en C manipulerait plutt deux pointeurs sur caractre que lindice len, mais cela suppose lexistence doprations arithmtiques sur les pointeurs, absentes en UML.

Figure 5.20
Calcul de la longueur dune chane de caractres.
char[] s decisionInput s[len] len++

len=0 [\0] int len

2. Une solution est propose la gure 5.5.

Diagramme dactivits 177

Exercices

[else]

EXERCICE 2

VENTE

EN LIGNE

Un site de vente en ligne propose des produits, placs dans un panier virtuel tandis que lutilisateur navigue. Pour valider ses achats, il clique sur le bouton Sortir du magasin. On lui propose alors de se connecter un compte existant, ou den crer un sil nen a pas encore. Pour crer un nouveau compte, lutilisateur doit fournir une adresse de messagerie, qui sert galement de login, son nom et son adresse, ventuellement une adresse de livraison, et ses coordonnes bancaires. On prvoit le cas o ladresse de messagerie est dj associe un compte. Si la validation de ces informations russit, on cre un nouveau compte et lon propose lutilisateur de sy connecter. On passe ensuite la conrmation des achats. Modlisez cette procdure laide dun diagramme dactivits. Lnonc est sufsamment vague pour donner lieu de nombreuses interprtations. Cela est typique dune spcication textuelle des besoins, telle quon en trouve dans un cahier des charges. La solution propose ici xe donc un certain nombre de choix dorganisation de la procdure. On se concentre sur la partie concernant lauthentication de lutilisateur, et la cration dun compte le cas chant.

Figure 5.21
Une interface web pour lauthentication.
remplir panier confirmer des achats

loger utilisateur [else] [compte invalide]

[oui] compte existant? [non] [adresse connue] saisie email [else]

saisie login, mot de passe

crer le compte mot de passe perdu?

saisie nom, adresse [adresse diffrente]

saisie rfrences bancaires

modifier adresse de livraison

178

UML 2

Chapitre
Lorganisation propose correspond une interface de type wizard : il faut valider tous les champs dune page, cliquer sur Suivant, pour passer la validation des prochains champs. Si les informations sont incorrectes, un message avertit lutilisateur et lcran suivant safche. Cette vrication des champs nest donc pas reprsente ici : il revient lactivit de saisie de se terminer quand la saisie est valide. Chaque activit correspond donc assez bien un cran dinterface, les transitions exprimant une navigation possible entre ces crans. Vous pourrez rutiliser ces activits ailleurs. Par exemple, la modication de ladresse de livraison est accessible depuis un menu quand lutilisateur est connect son compte. Ce niveau de description est bien adapt la description dinterfaces homme-machine et permet de se concentrer sur la vision logique dun traitement, sans se perdre dans le modle structurel en classes.

EXERCICE 3

ALGORITHMIQUE
Les diagrammes dactivits permettent de raisonner sur des algorithmes, au cours de lactivit de spcication dtaille. Vous allez utiliser les diagrammes dactivits pour dcrire des algorithmes de tri. 1. laborez une activit swap qui prend trois arguments, un tableau tab et deux indices a et b, et change le contenu de la case tab[a] et tab[b]. 2. En utilisant swap, dcrivez un tri par bulles dun tableau tab de taille n. Lalgorithme consiste en n 1 parcours du tableau, chacun amenant (par des appels successifs swap sur des cases contigus) le plus grand lment du tableau en dernire position (donc en position n 1 i litration numro i). 3 .Lalgorithme glouton du tri par bulles est peu efcace, en raison du grand nombre de copies inutiles ralises. crivez un tri par insertion, qui opre en n itrations : chaque itration de numro i, considrez la plage de valeurs de 0 i 1 comme trie. Lalgorithme consiste chercher le bon endroit o insrer la valeur en position i, an de trier la plage de valeurs de 0 i. Copiez la valeur en position i dans une variable temporaire et dcalez les valeurs avant cette position vers la droite (une par une) jusqu trouver lendroit ou recopier la valeur de la variable temporaire. 4. Lalgorithme prcdent a encore une complexit leve. Les tris les plus efcaces sont fonds sur des appels rcursifs qui font chuter la complexit. La fusion de deux tableaux tris en un tableau tri est une opration de complexit linaire sur la taille du tableau rsultant. Pouvez-vous concevoir un algorithme (tri par fusion) qui sappuie sur cette proprit et des appels rcursifs pour trier plus efcacement un tableau ? Indication : vous pouvez dnir une activit tri fusion qui prend un tableau t et deux indices, g et d, et trie la portion du tableau comprise entre les indices g et d. Notons que les algorithmes prsents ici sont fonds sur le trs classique livre Le Langage C, de Kernighan et Ritchie. La lecture compare des versions en C et en diagrammes dactivits est instructive. 1. Utilisez une variable temporaire pour stocker lune des deux valeurs des variables changer avant de lcraser en la remplaant par la valeur de lautre variable. Ce diagramme met bien en avant le ot des valeurs. La variable temporaire est reprsente par un pin.

Diagramme dactivits 179

Exercices

Comme vous navez pas plus de prcisions sur le type des objets contenus dans le tableau, utilisez un template pour reprsenter ce type : lopration est en effet gnrique et valable quel que soit le type T contenu dans le tableau.

Figure 5.22
change de valeurs de deux variables.
swap a : int tmp:T tab : T[] tmp = T[a]

T[a] = T[b] b : int

T[b] = tmp

2. Le diagramme de la gure 5.23 prsente une structure intressante pour la reprsentation de boucles, qui fait apparatre clairement les deux boucles imbriques. Les cycles dans le graphe traduisent le phnomne de bouclage , et limbrication est visible grce la hirarchie. Le placement des objets constituant les boucles (corps de boucle, condition darrt) est reconnaissable visuellement ; il est rutilis plusieurs fois dans les diagrammes qui suivent. Deux points de dcision font apparatre plus clairement la fois le dbut et la n de lalternative dans la boucle interne. Une nouvelle contrainte sur le type contenu dans le tableau impose que ce type soit muni dune relation dordre total pour que puisse soprer la comparaison de ses lments. Indiquez-la en mentionnant que le type T doit raliser linterface Comparable. (Voir aussi la section 3.3 et lexercice 4 du chapitre 3.)

Figure 5.23
Tri par bulles .

incrment entre chaque boucle

condition darrt Comparable T Tri bulles i : int

i++ tab : T[] [i <= n] [else] [else] j=1 [j<= i] [else] [ tab[j-1]>tab[j] ] swap(j-1,j,tab) j : int j++ i=1

n : int

initialisation

corps de boucle

si la valeur est plus petite que la voisine de droite...

on les change

180

UML 2

Chapitre
3. Cette version du tri limite le nombre de copies intermdiaires de valeur. Elle ralise un roulement des variables (au lieu de les changer deux deux) qui dplace tout un bloc avant de recopier la variable temporaire. La structure de lalgorithme reste assez proche du tri par bulles. De ce fait, il a la mme complexit thorique en O(n2) en nombre doprations que le tri par bulles, mais ralise un peu moins de copies que lui. Vous vous en apercevrez en comparant les deux schmas : limbrication des deux boucles apporte le facteur n2 et les diffrences entre les actions dans chaque boucle napportent quun facteur constant, donc thoriquement ngligeable en complexit.

Figure 5.24
Tri par slection.

copie dans le temporaire = crer un trou

teste si la bonne position du trou est atteinte Comparable T Tri par insertion i : int

i++ tab : T[] j-i=1 [i <= n] tmp = tab[i] tmp : T j : int

[j>0 et t[j-1]>tmp] [else] j=i [else] tab[j] = tmp tab[j] = tab[j-1]

n : int

recopier le temporaire dans le tableau = remplir le trou

dcaler droite la valeur (en crasant) = dcaler le trou gauche

4. Le tri par fusion permet de montrer la modlisation de concepts algorithmiques avancs, en particulier la rcursivit et le paralllisme. Ce type de tri est relativement puissant : il a une complexit comparable au quicksort, devenu standard, et se prte galement une implmentation sur des listes chanes. Cest rcemment devenu lalgorithme de tri standard (au lieu de quicksort) du langage Perl par exemple. Comme le montre le diagramme prsent la gure 5.25, il est possible de limplmenter avec des traitements en parallle, ce qui se prte aux architectures parallles. Pour autant, il nest pas obligatoire de limplmenter avec du paralllisme : toute excution qui respecte lenchanement des actions et les barres de synchronisation est correcte. Les numros indiqus ct des pins donnent lordre des arguments. Lappel rcursif est reprsent comme un appel de fonction normal. Lalgorithme correspond lapproche diviser pour rgner . chaque profondeur dans lappel rcursif, vous triez un tableau deux fois plus petit : la moiti du tableau prcdent. La complexit thorique totale des traitements nest quen O(n log n), au lieu de O(n2), comme les deux algorithmes prcdents.

Diagramme dactivits 181

Exercices

Figure 5.25
Tri par fusion.

cas terminal pour la rcursion : un tableau un seul lment est dj tri.

trouver le milieu m de lintervalle trier Tri fusion

tri rcursif des deux moitis Comparable T m : int s : int [d-g+1]

m = (g+d)/2

[d <= g]

tri fusion (t,g,m)

tri fusion (t,m+1,d)

Attention, i dcroit : deuxime moiti copie en ordre inverse !

i : int j : int

i++ j++ [i<=m] s[j]=t[i] [else]

i : int j : int

i-j++ [i>m] s[j]=t[i] [else]

1 t : T[] 2 g : int 3 d : int

i=g j=0

i=d j=m-g+1

copies dans s des deux moitis i : int j : int k : int i=g j=0 k=d-g [else] [i<=d] i++

t[i]=s[k] k-[else]

t[i]=s[j] j++ [ s[j] <= s[k] ]

fusion des moitis tries et recopie dans t

On part des deux extrmits de s dindices j et k et on copie dans t[i] le plus petit des deux

EXERCICE 4

VIDOCLUB
En vous basant sur la description textuelle du vidoclub de lexercice 5 du chapitre 1, reprsentez par un diagramme dactivits le cas dutilisation Emprunter une vido . La description des cas dutilisation est lune des applications immdiates des diagrammes dactivits. Elle permet daccompagner la description textuelle par un schma synthtique, mais ne la remplace pas.

182

UML 2

Chapitre

Figure 5.26
Le cas dutilisation Emprunter vido .

(client) introduire carte

Exception E3

avaler carte

Exception E1 valider carte [else] valider crdit suprieur ou gal un euro [else] [carte invalide] Alternatif A1

15 secondes

(client) prendre carte

proposer rechargement

[crdit suffisant] Exception E4 rechercher video [annulation] jecter carte

dlivrer cassette 15 secondes avaler cassette annuler opration Exception E2 afficher temps et prix de location

(client) prendre cassette

On retrouve sur ce diagramme la fois la squence nominale et les diffrents enchanements alternatifs et dexceptions. On distingue les actions se rapportant au client, qui ne fait pas directement partie du systme. valeur dexemple, deux mcanismes diffrents sont utiliss pour reprsenter le dlai de 15 secondes pendant lequel le client rcupre sa cassette ou sa carte. Dans le premier cas, une exception gre cet vnement : cela permet, en cas de leve de lexception, de reprendre le traitement au mme point que si le client avait rcupr sa cassette et denchaner sur jecter carte. Dans le deuxime cas, deux actions sont mises en concurrence : prendre carte et le time event de 15 secondes. Lastuce ici est que le premier ot de contrle qui atteint le nud nal force la terminaison de tous les autres ots. Si ce comportement nest pas celui souhait, il faut utiliser un nud ow nal (cercle avec une croix) pour terminer un ot sans affecter les autres ots de la rgion.

EXERCICE 5

CACHE DOPRATIONS
Cet exercice aborde la modlisation dun mcanisme de cache, permettant de limiter le cot des calculs rpts. Cette stratgie est trs utile pour les calculs coteux en temps, mais consomme en contrepartie plus de mmoire.

Diagramme dactivits 183

Exercices

Cet exercice propose de modliser un mcanisme de cache. Une classe Map reprsente une table associative. Elle contient conceptuellement des couples <cl,valeur>. La recherche de la valeur associe une cl donne (opration get) est trs rapide (complexit thoriquement constante, quel que soit le nombre de couples dans la table). Une seule valeur peut tre associe chaque cl distincte : si une valeur est dj associe la cl, lopration put dajout la table crase lancienne valeur. Les tables de hash ou les arbres de recherche sont des implmentations frquemment rencontres de tables associatives.

Figure 5.27
Les classes proposes pour implmenter un cache.
Map Object get (Object key) Object put (Object key, Object value) postcondition si la cl key nest pas dans la table rends la rfrence nulle. sinon rends la valeur associe la cl key

postcondition la valeur value t associe la cl key dans la table.

{abstract} Cache -map : Map +Object compute (arg: Object)

Fonction2 #Object doComputation (Object) Fonction1 Ralisent un calcul coteux

#Object doComputation (Object) {abstract} #Object doComputation (Object)

Vous allez raliser une classe abstraite Cache qui offre ses classes drives une fonctionnalit de cache. Elle est munie, pour cela, dune instance de la classe Map, qui sert stocker les rsultats dj calculs par cette instance de fonction. Les classes drives de Cache ralisent un calcul coteux en temps. De telles classes, qui servent raliser un calcul, sont parfois appeles foncteurs . Elles doivent implmenter lopration de visibilit protge doComputation (coteuse). Elles offrent publiquement lopration compute aux utilisateurs de la fonction. 1. Dcrivez laide dun diagramme dactivits le comportement de lopration compute. 2. Prvoyez que largument pass compute nest pas du bon sous-type de Object pour la fonction concrte. Si cest le cas, lopration doComputation risque de lever une exception de typage quand elle essaie dinterprter lobjet pass en argument (ClassCastException par exemple en Java standard). Pour offrir une gestion propre, si une erreur de ce type se produit, vous voulez que compute lve une exception (non standard) de type TypeException. Enrichissez le diagramme prcdent pour reprsenter ce mcanisme. 1. Lopration compute cherche si le rsultat de lopration a dj t calcul pour son argument. Si cest le cas, elle rend la valeur stocke dans le cache. Sinon, elle ralise le calcul par un appel la fonction abstraite doComputation. Ensuite, elle ajoute ce nouveau rsultat dans la table avant de le rendre lappelant.

184

UML 2

Chapitre

Figure 5.28
Comportement associ lopration compute du cache.
arg : Object

(Cache) compute [else] res = map.get (arg) [res != null] map.put(arg,res) res = doComputation (arg)

res: Object

2. Supposez que doComputation peut lever une exception : il faut protger lactivit qui appelle cette fonction par un gestionnaire dexception. Enrichissez donc le diagramme en ajoutant ce gestionnaire et un pin pour reprsenter la nouvelle signature complte (avec lexception TypeException) de compute. Le corps du gestionnaire dexception se contente de lever lexception approprie : lopration dajout dans la table qui suit lactivit doComputation nest pas ralise.

Figure 5.29
Opration compute avec la gestion des exceptions.
arg : Object

(Cache) compute raise TypeException :ClassCastException [else] res = map.get (arg) [res != null] map.put(arg,res) res = doComputation (arg) :TypeException

res: Object

Diagramme dactivits 185

Exercices

Chapitre

UML en pratique

1. Un processus pour la modlisation dun systme ...... 188 2. Guide mthodologique ........... 189 tude de cas ............................... 196

Les principaux diagrammes raliss avec UML ont t prsents dans les chapitres prcdents. Or, les modles labors avec ces diffrents diagrammes sassemblent et se compltent pour donner une vision globale et cohrente dun systme. Dautre part, la modlisation dun systme nest pas un processus linaire (o les modles sont labors selon un enchanement immuable), mais au contraire un processus itratif, voire incrmental. Ainsi, lordre de prsentation des diagrammes dans les chapitres prcdents, sans tre dnu dintrt, est quelque peu arbitraire, et ne dfinit pas un processus immuable applicable la modlisation de nimporte quel systme. Ce chapitre prsente un processus qui est suffisamment gnral pour convenir, moyennant quelques adaptations, la plupart des problmes. Dans la partie exercices, ce processus est illustr par une tude de cas.

187

(1)

Un processus pour la modlisation dun systme


limage des langages de programmation qui permettent de dvelopper des applications pour tous les domaines, UML est un langage capable de dcrire nimporte quel systme. Ses lments de base (les rectangles qui reprsentent des classes, les traits qui matrialisent des associations entre classes, etc.) sassemblent pour former des diagrammes. Un diagramme est un modle. laborer tous les modles donne lassurance davoir une vision complte dun systme, mais parfois, une vision partielle suft. Le modlisateur est donc libre de choisir les modles qui conviennent une application particulire. Cest cette libert de choix qui fait la force dUML. A contrario, cet aspect bote outils en fait un langage difcile appliquer : le modlisateur dbutant se trouve souvent perdu face tant de possibilits. La richesse dUML se retrouve dans la profusion de diagrammes quil permet de construire : diagramme de cas dutilisation ; diagramme de classes et dobjets ; diagramme dinteraction (diagrammes de squence, de communication, de timing) ; diagramme dtats-transitions ; diagramme dactivit ; diagramme de composants ; diagramme de dploiement. Les deux derniers diagrammes de la liste, que nous navons pas encore abords, sont dcrits la n de louvrage. Ce nombre important de diagrammes pose la question de lordre dans lequel il faut les laborer. Y a-t-il une marche suivre ? Un processus immuable ? videmment, et malheureusement non ! La diversit des systmes modliser rend illusoire la dnition dun tel processus. Toutefois, dfaut dtre immuable, la marche suivre doit respecter les tapes du cycle de dveloppement dun systme : planication du projet ; phase danalyse ; conception ; implmentation ; tests ; dploiement ; maintenance. La planication du projet comprend notamment la dnition du problme, ltablissement dun calendrier ainsi que la vrication de la faisabilit du projet. Lanalyse permet de prciser ltendue des besoins auxquels doit rpondre le systme, puis de spcier et de comprendre ce que doit faire ce systme (sans se proccuper de la ralisation). La conception dnit comment le systme va tre ralis (cest ltape o des choix techniques sont faits). Limplmentation, quant elle, correspond la ralisation du systme (dans le cas dun logiciel, il sagit de la phase dimplmentation dans un langage de programmation). Les tests permettent, avant la mise en production, de vrier ladquation entre la solution et les besoins initiaux. Enn, la maintenance permet de conserver en tat de marche un systme en production.

188

UML 2

Chapitre
UML couvre la plupart des tapes du cycle de vie dun projet (gure 6.1).

Figure 6.1
La place dUML dans le cycle de dveloppement dun systme.

planification analyse conception implmentation tests dploiement maintenance UML UML

Historiquement, cest dabord durant la phase danalyse quUML a t utile. La version 2 dUML a considrablement tendu le langage, notamment avec lapparition des classeurs structurs qui sont utiles en phase de conception. Cependant, il est encore trop tt pour afrmer quUML va simposer comme un standard dans ce domaine. Dautre part, lOMG, lorganisme qui supporte UML, a lambition dviter la rupture trop brutale qui a toujours exist entre les phases de modlisation et la phase dimplmentation (l o UML est abandonn au prot dun langage de programmation). Son objectif est quUML puisse, terme, tre utilis tout au long du cycle de vie dun projet, y compris pour donner une implmentation un systme, ce qui nest pas le cas aujourdhui. En revanche, le langage permet depuis longtemps de reprsenter un systme tel quil sera dploy grce aux diagrammes de dploiement (voir lannexe D). De plus, les scnarios qui prsentent des ralisations des cas dutilisation (sous forme textuelle, avec des diagrammes de squence ou dactivit) peuvent servir de base pour dnir les tests du systme implment. La recherche dun processus uni qui sadapte tous les projets a donn lieu de nombreux travaux. Parmi ceux-ci, deux se distinguent : le RUP (Rational Unied Process) et le MDA (Model Driven Architecture). Lampleur de ces travaux dpasse le cadre de ce livre, aussi, nous nous contenterons dans ce chapitre de dcrire une mthode relativement simple, mais largement utilise dans le domaine du dveloppement de logiciels [Blaha 2005]. Elle est illustre par une tude de cas dans la partie exercices de ce chapitre.

(2)

Guide mthodologique
Considrons un projet de dveloppement dun systme logiciel. La premire tape du cycle de vie, la planication, a permis de dnir le problme, dtablir un calendrier, et de vrier la faisabilit du projet. Notre description commence ltape danalyse. Rappelons quelle sert prciser le besoin auquel doit rpondre un systme, et spcier et comprendre ce que ce systme doit faire.

Remarque
La description qui suit est succincte mais assez complte car nous dcrivons toutes les tapes dun processus (mme celles o UML nest daucune utilit), an que vous puissiez vous rendre compte de la porte, mais galement des limites dUML. Nous insistons particulirement sur les phases danalyse et de conception car cest l o UML est le plus utile. La phase de dploiement est aborde dans lannexe D et dans ltude de cas. Des indications sur la faon dimplmenter un diagramme de classes dans un langage de programmation objet sont galement donnes dans lannexe E.

UML en pratique 189

Remarque (suite)
Nous avons spar la description du processus de ltude de cas, an de ne pas encombrer la partie thorique (et donc gnrale) avec des dtails lis une application. Cependant, nous conseillons, lors de la premire lecture, de ne pas parcourir dune seule traite la par tie cours avant de passer ltude de cas. Il vaut mieux alterner partie thorique et mise en pratique. Plus tard, le lecteur pourra revenir sur la partie thorique seule, quil verra alors comme le rsum dune mthode.

2.1 PHASE DANALYSE


Le concept de rutilisabilit, qui consiste reprendre une partie dun logiciel pour lutiliser dans une autre application, et le concept dvolutivit, qui permet dajouter des nouvelles fonctionnalits un logiciel existant, ont t des raisons fondamentales au dveloppement de lapproche objet du gnie logiciel. Pour tre effectifs dans une application, ces mcanismes doivent tre mis en place ds la phase danalyse. Il faut sparer ltude du domaine de lapplication de lapplication elle-mme. Le domaine, cest par exemple celui dune banque, et lapplication, un logiciel de gestion de comptes bancaires : dune application bancaire une autre, le domaine ne va pas changer car cest toujours dune banque quil sagit. La phase danalyse dun logiciel se compose de deux parties : lanalyse du domaine de lapplication ; lanalyse de lapplication.

Analyse du domaine de lapplication


Cest durant la phase danalyse du domaine quune premire version du diagramme de classes est labore. Ce modle doit capturer les classes qui modlisent des entits prsentes dans le domaine de lapplication. Cette premire version du diagramme de classes est btie avec des experts du domaine (des banquiers pour un systme bancaire par exemple). Ce modle est labor plutt au dbut de la phase danalyse, et, en tout cas, indpendamment de la phase danalyse de lapplication : le modle du domaine sera ainsi plus stable, et il pourra facilement voluer car il sera indpendant des dtails de lapplication (le modle du domaine ne sintresse pas aux fonctionnalits de lapplication). Aprs avoir labor le modle des classes du domaine, lanalyse se poursuivra par la construction de diagrammes dtats-transitions pour les classes ayant des tats complexes. Modle des classes du domaine. Le chapitre 2 donne des indications pour construire un diagramme de classes. La dmarche pour btir le diagramme de classes du domaine est la mme. Aussi nous contenterons-nous de donner un rsum des tapes suivre : trouver les classes du domaine ; prparer un dictionnaire des donnes ; trouver les associations entre les classes ; trouver les attributs des classes ; organiser et simplier le diagramme en utilisant lhritage ; tester les chemins daccs aux classes ; itrer et afner le modle ; regrouper des classes dans des paquetages.

190

UML 2

Chapitre

Remarque
Un modle est rarement correct ds sa premire construction. Il est souvent ncessaire de revenir plusieurs fois dessus an de lafner. Par exemple, il ne faut pas sattendre trouver toutes les associations ds la premire construction du diagramme de classes. La modlisation ne se fait pas par une succession linaire dtapes, mais progresse souvent par itrations.

Modle des tats du domaine. Un diagramme de classes nest quun modle et, dans un logiciel en cours de fonctionnement, il ny a pas de classe mais des objets, instances de classes. Un diagramme de classes nest quune abstraction de la ralit. Le modlisateur a besoin de descendre un niveau plus bas (cest--dire au niveau des objets). Durant lanalyse, il ne faut cependant pas descendre jusquau niveau physique : il est tout fait prmatur de sintresser lallocation des ressources mmoire pour les objets, et du temps processeur pour les mthodes. En revanche, il est ncessaire de connatre le cycle de vie des objets ( quelle tape de la vie du logiciel en production les classes vont donner naissance des objets, comment ceux-ci vont tre utiliss et quelle tape ils seront dtruits). La description de ce cycle revient aux diagrammes dtats-transitions. Cependant, seules les classes dont les instances ont un cycle de vie complexe doivent donner lieu des diagrammes dtats-transitions. La dmarche pour construire le modle des tats du domaine est la suivante : identier des classes du domaine ayant des tats complexes ; dnir les tats ; trouver les vnements qui vont engendrer des transitions entre tats ; construire les diagrammes dtats.

Remarque
Il est important de suivre les diffrentes tapes de la dmarche dans lordre indiqu ci-dessus. Notamment, il faut trouver les tats avant les vnements. De nombreux vnements sont produits par les utilisateurs dun systme. Ils sont pris en compte au moment o sont dcrits les cas dutilisation, et donc lis une application particulire. Or, le modle du domaine doit tre indpendant des applications.

Analyse de lapplication
Limplmentation du modle des classes du domaine donne lieu un systme statique. Ce modle nindique pas comment des instances de classes interagissent pour raliser les fonctionnalits dune application. Un diagramme de classes, mme implment, noffre aucune fonctionnalit aux utilisateurs. Pas plus quune implmentation du modle des tats du domaine qui se contente de dnir le cycle de vie des objets sparment les uns des autres. Aprs avoir construit le modle du domaine, il faut sintresser aux applications qui utilisent ses classes. Modle des interactions de lapplication. Cest durant la phase danalyse de lapplication quun modle des interactions du systme est produit. Lanalyse dbute par la construction du diagramme de cas dutilisation et se poursuit par la description des scnarios dutilisation des cas. La dmarche est dcrite en dtail dans le chapitre 1. Nous nous contentons ici den donner un rsum : dterminer les limites du systme ; trouver les acteurs ;

UML en pratique 191

trouver les cas dutilisation ; construire le diagramme de cas dutilisation ; prparer les scnarios pour dcrire les cas ; ajouter des squences alternatives et des squences dexceptions aux scnarios ; prparer des diagrammes dactivit pour des cas dutilisation complexes ; raliser une vrication croise des modles du domaine et de lapplication. La vrication se fait partir des scnarios. Elle permet de contrler si les classes ont tous les attributs et tous les chemins (les associations) ncessaires pour y accder. Modle des classes de lapplication. Les classes du diagramme de classes ne sufsent pas raliser une application. Des instances de ces classes doivent interagir avec les acteurs du logiciel (les utilisateurs, les priphriques, etc.). Il nest pas souhaitable que les acteurs interagissent directement avec les instances des classes du domaine. La logique interne de lapplication doit tre indpendante des acteurs. Linterface utilisateur du logiciel, par exemple, doit pouvoir voluer tandis que le cur de lapplication doit rester identique. Cest le principe fondamental du dcoupage en couches dune application (gure 6.2) : lune des extrmits de lapplication se trouve linterface utilisateur et, de lautre ct, le logiciel interagit avec des supports de stockage (bases de donnes, annuaires, chiers, etc.) via une couche de services. Limplmentation du diagramme des classes trouvera sa place dans la couche mtier.

Figure 6.2
Le dcoupage en tiers dune application.
Interface utilisateurs Logique applicative Logique mtier Services : accs aux donnes, transactions...

Utilisateurs

Supports de stockage

Remarque
La tendance actuelle du dveloppement de logiciels, prne notamment par lapproche dite composant de la programmation, va vers la multiplication du nombre de couches. On parle alors dun dcoupage en N-tiers !

Le modle des classes de lapplication concerne toutes les classes supplmentaires quil convient dajouter pour interfacer la logique applicative avec les acteurs du logiciel. La dmarche est la suivante : spcier linterface homme-machine ; dnir les classes la priphrie du systme.

192

UML 2

Chapitre
En modlisation objet, linterface est un objet, ou un groupe dobjets, qui permet dinteragir avec lapplication. Durant la phase danalyse, vous devez vous intresser non pas la prsentation de linterface utilisateur mais uniquement aux ots de donnes et de contrle transmis via linterface. Il ne faut pas non plus trop dtailler les entres-sorties, mais considrer globalement les requtes qui permettent daccder un service, la rservation dune place de cinma, par exemple. Cela ne doit cependant pas vous empcher de construire les maquettes des interfaces pour vous aider tablir leurs spcications. Les classes la priphrie du systme ont pour rle de convertir les informations utiles au logiciel, du format comprhensible par le monde extrieur au format interne du logiciel, et vice versa. En plus des objets dnissant les interfaces de lapplication, un logiciel contient un ou plusieurs objets actifs qui le contrlent. Ces objets sont appels contrleurs . Ils reoivent des signaux du monde extrieur, ou des objets lintrieur du systme, et ragissent en invoquant des oprations sur dautres objets. Chaque contrleur a pour tche de traiter un comportement particulier du logiciel.

Remarque
UML nest pas dun grand secours lors de cette phase de lanalyse, mme si les classes qui y sont dcouvertes peuvent tre reprsentes avec le formalisme du diagramme de classes. La couche daccs aux donnes est construite lors de la phase de conception et non pas pendant la phase danalyse. Il faut dabord avoir dcompos successivement les classes et les mthodes pour arriver aux supports de stockage.

La dernire tape pour llaboration du modle des classes de lapplication consiste contrler la cohrence de ce modle avec celui des interactions. Il sagit de reprendre les cas dutilisation an de vrier comment les modles interagissent : par exemple, une donne saisie via linterface homme-machine est cone un objet contrleur qui la transmet un objet du domaine via linvocation dune opration, etc. Lors de cette tape, le langage OCL peut tre utilis pour naviguer parmi les classes. Modle des tats de lapplication. Tout comme les classes du domaine, les classes de lapplication peuvent avoir des tats complexes. Chacune delles ncessite donc un diagramme dtats-transitions. Pour construire un tel diagramme, la dmarche est la suivante : identier des classes de lapplication ayant des tats complexes ; trouver les vnements ; construire les diagrammes dtats ; vrier la cohrence avec les modles prcdents.

Remarque
Les diagrammes des tats-transitions de lapplication se construisent peu prs de la mme manire que ceux du domaine de lapplication. Seul lordre des tapes diffre : pour lapplication, il faut dabord trouver les vnements avant les tats, alors que cest le contraire pour le domaine. En effet, les tats de lapplication sont labors aprs que les cas dutilisation, qui sont dclenchs par des vnements provenant des acteurs, ont t d nis. On dispose donc des vnements avant de construire les tats. Il nen est pas de mme pour ltude du domaine qui, parce quelle doit tre indpendante des applications, ne peut pas reposer sur des vnements.

UML en pratique 193

Ajout des oprations. ce stade de lanalyse, les classes du domaine de lapplication peuvent contenir quelques oprations (celles qui ont t suggres par ltude du domaine). Ces oprations sont intressantes car elles sont propres au domaine, et donc indpendantes des applications. Cependant, les oprations lies lapplication ne sont pas forcment toutes dcouvertes. Elles peuvent tre dduites de ltude des cas dutilisation et de leurs descriptions par les diagrammes de squence et/ou dactivit produits.

2.2 PHASE

DE CONCEPTION

Avertissement
La phase de conception requiert beaucoup dexprience. Cela dpasse largement le cadre de cet ouvrage. La description qui en est faite ici est trs sommaire, mais nanmoins utile pour se rendre compte de lintrt dutiliser UML lors de cette phase.

Les concepteurs ont pour tche principale de prparer limplmentation. Pour un logiciel, limplmentation consiste traduire le plus mcaniquement possible des modles danalyse et de conception dans un ou plusieurs langages de programmation. Les modles produits lors de lanalyse dcrivent ce que doit faire le systme indpendamment de la faon dont on va le raliser. La conception va permettre de dcider comment raliser le systme. La phase de conception est compose de deux tapes : la conception du systme ; la conception des classes.

Conception du systme
Au nal, le logiciel va sexcuter sur des ressources matrielles (processeurs, mmoire). Le concepteur du logiciel doit choisir les ressources adquates. Gnralement, il est guid par les besoins du logiciel. Le choix ne peut pas se faire directement partir des modles danalyse, notamment pour les raisons suivantes : Les ressources matrielles sont limites. Les ressources matrielles sont diverses, varies et souvent htrognes. La principale limitation des ressources concerne les microprocesseurs des ordinateurs et les systmes dexploitation qui les grent. Ce sont des ressources partages auxquelles peuvent accder toutes les applications qui sexcutent en mme temps sur une machine. Lors de ltape danalyse dun logiciel, on fait la supposition que tous les objets disposent de ressources illimites. Or, au vu des ressources processeur limites, il convient de dcider, parmi toutes les mthodes des classes du logiciel, lesquelles doivent sexcuter squentiellement, et lesquelles doivent le faire en parallle. Pour reprer les mthodes concurrentes, on peut analyser les modles des tats produits au moment de lanalyse. Le choix des ressources matrielles doit tre guid par les besoins du logiciel. Une fois le choix fait, il faut sadapter aux capacits des ressources. La principale difcult rside dans leur grande diversit. Certains systmes dexploitation ou certains langages de programmation par exemple, fonctionnent selon un mode vnementiel, dautres sur un mode procdural, voire concurrent, etc. Le concepteur doit donc choisir une stratgie de contrle pour son logiciel. De plus, si le logiciel est rparti sur plusieurs machines, la stratgie de contrle ne sera pas forcment la mme pour les parties du logiciel qui sexcutent sur des machines diffrentes. UML nest daucune aide pour choisir la stratgie de contrle. En revanche, il est

194

UML 2

Chapitre
possible de dcrire les parties dun logiciel qui sexcutent sur des matriels laide des diagrammes de dploiement (voir lannexe D). Au dpart, le concepteur ne dispose que des modles issus de lanalyse, cest--dire des diagrammes de classes, des tats-transitions, des squences, etc. Or, le passage des modles de lanalyse au diagramme de dploiement est loin dtre immdiat. Le concepteur procde par tapes. Tout dabord, le systme (dans notre cas, un systme logiciel) est dcompos en sous-systmes. La partition du systme doit permettre de regrouper dans un soussystme des classes, des associations, des oprations, des vnements, etc., qui collaborent aux mmes fonctionnalits, ou dont les contraintes techniques les destinent sexcuter sur les mmes ressources. UML ne donne pas dindication sur les critres prendre en compte pour partitionner un systme, mais permet simplement de reprsenter des soussystmes. Aprs que le systme a t dcompos en sous-systmes, les tapes suivantes consistent : reprer les objets qui sexcutent concurremment ; allouer les sous-systmes des matriels ; choisir sur quel(s) support(s) stocker les donnes (bases de donnes, chiers, etc.) ; identier les ressources ncessaires (processeurs, disques, crans, claviers, etc.) ; choisir une (ou plusieurs) stratgie(s) de contrle du logiciel (vnementielle, procdurale, etc.) ; sassurer du bon fonctionnement du logiciel dans des conditions limites (comment linitialiser, larrter, grer les erreurs, etc.).

Remarque
UML nest daucune utilit dans les quatre dernires tapes.

Conception des classes


ce stade de la conception, le systme a t dcoup en sous-systmes et les ressources utiles au logiciel ont t choisies. La dernire tape de la conception avant limplmentation consiste dnir et appliquer une stratgie pour combler la distance qui spare les oprations des classes des ressources choisies. La technique utilise ici rejoint lapproche fonctionnelle du dveloppement logiciel. Le concepteur procde par dcomposition des fonctions en sous-fonctions, puis choisit des algorithmes pour raliser ces fonctions. Les choix de conception faits ce moment-l sont plutt techniques, mais ils doivent toujours tre guids par les cas dutilisation. Les diagrammes dactivit dUML permettent de dcrire les algorithmes complexes, et les classeurs structurs sont utiles lors de la dcomposition des classes et des oprations des classes. Les algorithmes sont choisis principalement pour les performances quils offrent. Le concepteur peut aussi tre amen optimiser laccs aux attributs des classes en ajoutant de nouvelles associations au diagramme de classes.

Conclusion
Dans ce chapitre, nous avons rassembl tous les lments de modlisation qui ont t abords dans cet ouvrage et prsent un processus visant modliser un systme logiciel. Ce processus gnral pourra tre adapt des projets spciques.

UML en pratique 195

tude de cas
nonc du problme
Le problme concerne un projet de dveloppement dun logiciel. La premire tape du cycle de vie du projet, la planication, a permis de dnir le problme, dtablir un calendrier, et de vrier la faisabilit du projet. Notre description commence ltape danalyse. Cette section contient lessentiel de ltude de cas. Des informations complmentaires sont disponibles sur le site http://www.pearsoneducation.fr.

DESCRIPTION

DU PROBLME
Le but de ce projet est de dvelopper un logiciel qui gre la distribution de carburant dans une station-service. Le fonctionnement de la distribution de lessence est le suivant : avant de pouvoir tre utilise par un client, la pompe doit tre arme par le pompiste. 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 lon appuie sur la gchette, lessence nest pas pompe. La prise dessence est termine quand le client remet le pistolet dans son tui. Il existe quatre types de carburants : diesel, sans plomb avec 98 comme indice doctane, sans plomb avec 95 pour indice doctane, plomb. Le paiement peut seffectuer en espces, par chque ou par carte bancaire. En n de journe, les transactions sont archives. Les pompes ne peuvent tre armes que si le niveau des cuves dpasse 5 % de leurs capacits maximales.

CONTEXTE

TECHNIQUE DU SYSTME
Le contexte technique du logiciel est impos (gure 6.3). Le logiciel doit sexcuter sur une unit centrale laquelle sont relis : des capteurs pour mesurer le niveau de carburant dans les cuves ; des pompes qui puisent le carburant dans les cuves ; le pupitre du pompiste (cran et clavier) ; un systme cls en main de paiement par carte bancaire.

196

UML 2

Chapitre

Figure 6.3
Contexte technique du logiciel (ce diagramme nest pas un diagramme UML).

Pupitre pompiste

Banque

Cuves carburant

Unit centrale

Systme de paiement par carte bancaire

Pompe 1

Pompe n

SP98 Super SP95 Diesel

SP98 Super SP95 Diesel

DIAGRAMME

DE DPLOIEMENT DES PRIPHRIQUES DU SYSTME


Pour prciser le contexte technique du systme, il est parfois utile de montrer un exemple de solution. Lexemple doit tre donn titre purement indicatif et la solution nale pourra tre diffrente. Pour que lanalyse, qui na pas encore dbut, ne soit pas biaise, il faut cependant veiller ne donner aucune consigne de conception (architecture interne, structure de donnes, algorithmes, etc.). La gure 6.4 prsente le diagramme de dploiement des priphriques du systme informatique de la station-service. Le systme informatique, quand il sera dploy, sexcutera sur le nud unit centrale . ce stade du projet, il sagit dune bote noire. Outre lunit centrale, on retrouve sur ce diagramme les priphriques de la gure 6.3.

Figure 6.4
Diagramme de dploiement des priphriques du systme.
clavier clavier du pompiste cran cran du pompiste

Priphrique de gestion des cuves

unit centrale Systme informatique de la station-service

Priphrique de paiement par carte bancaire

disque Base de donnes

Priphrique de gestion des pompes

On suppose que les priphriques matriels (de gestion des cuves, des pompes et du terminal de paiement) sont pilots par des composants existants. La gure 6.5 montre uniquement les composants qui pilotent une pompe : les deux premiers permettent de connatre respectivement les tats des gchettes (appuyes ou relches) et des pistolets ; le troisime fournit une interface (InterfacePompe) permettant darmer et dactiver la pompe.

UML en pratique 197

Figure 6.5
Les composants qui grent une pompe.

Gchette super Gchette diesel Gchette SP95 Gchette SP98

Pistolet super Pistolet diesel Pistolet SP95

Pompe super Pompe diesel Pompe SP95 Pompe SP98

Pistolet SP98

Priphriques de gestion dune pompe

unit centrale Systme informatique de la station-service InterfaceCapteurGchette InterfaceCapteurPistolet

: Capteur Gchette

: Capteur Pistolet

: Pompe

InterfacePompe

Informations transmises : Informations transmises : - numro de pompe, - gchette appuye, - gchette relche. - type carburant choisi, - pistolet dcroch, - pistolet raccroch.

interface InterfacePompe armer : boolen dsarmer : boolen activer : boolen dsactiver : boolen

Analyse du domaine de lapplication


Nous choisissons arbitrairement de commencer par lanalyse du domaine de lapplication. Il est possible davoir une lecture diffrente et de commencer par lanalyse de lapplication (voir plus loin dans ce chapitre). La seule contrainte, cest quil faut mener ces deux analyses de faon indpendante. Le premier modle du domaine produire est celui des classes.

198

UML 2

Chapitre

MODLE

DES CLASSES DU DOMAINE

1. 2. 3. 4.

Trouvez les classes qui font partie du domaine de lapplication. Trouvez les associations entre les classes. Trouvez les attributs des classes. Organisez et simpliez le diagramme en utilisant lhritage. Testez les chemins daccs aux classes. Itrez et afnez le modle. 5. Regroupez des classes dans des paquetages. 1. Avant de dresser une liste de classes, commenons par dlimiter le domaine de lapplication. Le contexte technique du logiciel concevoir impose dutiliser des priphriques matriels qui interagissent avec notre logiciel via des capteurs (les dtecteurs de niveau des cuves, par exemple). Notre but nest pas de concevoir ces priphriques mais de les modliser an de pouvoir les piloter. Bien entendu, un modle du domaine doit dpendre le moins possible des applications qui vont sappuyer sur lui. Plus le nombre dapplications qui peuvent tre construites partir dun seul modle du domaine est lev, et meilleur est ce modle. Cependant, dans notre cas, le domaine est clairement limit une station-service : notre modle nest pas destin lalimentation en carburant de voitures de course pendant une comptition, ni au remplissage des rservoirs dun avion. Lanalyse de domaine est ralise avec un expert. Il connat les priphriques qui grent la distribution dessence, et notamment les capteurs et les actionneurs qui les contrlent. Commenons par en dresser une liste exhaustive : capteurs de niveau des cuves ; dispositifs de pompage qui pompent le carburant dans les cuves ; gchettes des pistolets de distribution de carburant qui contrlent les dispositifs de pompage ; capteurs de prsence des pistolets dans les tuis de rangement. Le domaine ainsi dlimit, nous pouvons en commencer lanalyse. Ltude de la description du problme donne une premire liste de classes candidates : Pistolet, Gchette, Pompe, Etui, Carburant, Cuve, Client, Transaction, Archive. La notion de pompe est centrale dans la prise de carburant, mais que recouvre-t-elle exactement ? Est-ce lappareil auquel fait face un client et qui contient un ensemble de pistolets, de gchettes, dtuis, etc., ou est-ce la pompe qui puise le carburant dans les cuves ? Ltude des capteurs et des actionneurs reproduite prcdemment mentionne un dispositif de pompage qui pompe le carburant dans les cuves . Cest avant tout le dispositif de pompage que nous devons piloter (et donc modliser). Pour lever lambigut pesant sur le mot pompe, nous choisissons dutiliser DispositifDePompage la place. Lensemble des pistolets, des gchettes et des tuis auquel fait face un client est appel EnsemblePompe. Le dispositif de pompage est contrl par un pistolet, une gchette et un tui, do les noms de classes Pistolet, Gchette et Etui. La notion de cuve est importante dans notre domaine. Elle permet, notamment, de raliser la contrainte sur larmement dune pompe. Elle est modlise par une classe appele Cuve. La cuve contient du carburant. Carburant constitue galement un bon nom pour une classe.

UML en pratique 199

Client, transaction et archive nont pas encore t traits. Pour lapplication que nous allons concevoir, un client est celui qui se sert de lessence : cest un concept clair et non ambigu pour lapplication. Quen est-il du domaine de lapplication ? Quel concept du mtier de la distribution de carburant voulons-nous cerner ? Le client prend de lessence. Cest donc plus la prise dessence, lessence dlivre (la quantit, le type de carburant, etc.) qui nous intresse que le client en tant que tel. En ce qui concerne ce dernier, nous voulons plutt savoir quel type de paiement il a effectu (en espces, par chque ou par carte bancaire), et ventuellement, conserver le numro dimmatriculation de sa voiture. Nous sommes donc en prsence de deux concepts distincts. Le premier, qui correspond lessence dlivre, est modlis par une classe appele PriseDeCarburant. La prise de carburant nenglobe pas le type de paiement. Elle est lie au dispositif de pompage qui est au cur de notre domaine. Le type de paiement est li un client. Pour la distribution dessence des particuliers, le paiement fait partie du domaine de lapplication. Rsumons cette notion par le mot-cl TransactionClient. Le dernier substantif que nous navons pas encore abord est archive. Les transactions doivent tre archives quotidiennement. Pour quil ny ait pas dambigut, renommons lensemble des transactions quotidiennes TransactionsDuJour. La liste des classes candidates est prsent la suivante : Pistolet, Gchette, DispositifDePompage, EnsemblePompe, Etui, Carburant, Cuve, PriseDeCarburant, TransactionClient, TransactionsDuJour. An de dnir clairement chaque terme, un dictionnaire a t rdig. Voici un extrait :
Essence distribue par la station-service. Le carburant peut tre de plusieurs types (sans plomb 98, sans plomb 95, super et diesel). Conteneur du carburant de la station-service. Il y a une cuve par Cuve type de carburant. DispositifDePompage Appareil qui pompe le carburant dans les cuves. Contient toutes les informations concernant le paiement dun TransactionClient client, incluant le montant, la date et lheure de la transaction. TransactionsDuJour Lensemble des transactions ralises en une journe. Carburant

Remarque
Tous les termes lis au domaine ou lapplication doivent tre consigns dans des dictionnaires, mais pour des raisons de place, nous ne les avons pas tous reproduits.

2. Un premier diagramme de classes contenant des associations est prsent la gure 6.6. Notre objectif premier est de modliser lorganisation des priphriques an de les contrler. Le modle sarticule autour du dispositif de pompage. Cest la gchette qui contrle lactivation du dispositif de pompage. Do lassociation entre les classes Gchette et DispositifDePompage. Ce dispositif pompe le carburant dans une cuve ( noter que lassociation de 1 vers plusieurs entre les classes Cuve et DispositifDePompage indique que plusieurs pompes puisent le carburant dans une mme cuve).

200

UML 2

Chapitre
La gchette ne peut dclencher le pompage que si le pistolet qui la contient est dans son tui. Cest ltat dun capteur qui indique si le pistolet est dans son tui ou pas. Pour modliser cette information, nous tablissons une association ayant la multiplicit 0 ou 1 entre les classes Pistolet et Etui. La prise de carburant relie les classes DispositifDePompage, Carburant et TransactionClient.

Figure 6.6
Premire version du diagramme de classes du domaine.

EnsemblePompe Pompe carburant dans DispositifDePompage 1..* contient 0..1 Etui PriseDeCarburant dbite 1..* Carburant

1..* Pistolet Gchette

contrle activation

Cuve

TransactionsDuJour

0..*

TransactionClient

La navigabilit des associations nest pas prise en compte ce stade de lanalyse. 3. La plupart des attributs sont des boolens qui retent ltat des capteurs physiques (gure 6.7) : le pistolet est dans son tui, la gchette est appuye, le dispositif de pompage est arm ou actif (il est actif quand le pompage a lieu). Si le pistolet possde un boolen qui indique sil est ou non dans son tui, la classe tui devient superue : elle est supprime du modle. La classe Cuve est caractrise par son niveau de carburant. La classe Carburant contient le prix au litre ainsi que le type de carburant (sans plomb 98, etc.). La classe TransactionClient recense lensemble des donnes caractrisant le paiement par un client : le type de paiement (espces, carte bancaire ou chque), le montant ainsi que la date de la transaction. La quantit dessence prise qui permet de calculer le montant est dtenue par la classe PriseDeCarburant.

UML en pratique 201

Figure 6.7
Version du diagramme de classes du domaine incluant les attributs.

EnsemblePompe numroPompe : entier

1..* Pistolet dansEtui : boolen Gchette appuye : boolen

Pompe carburant dans contrle activation DispositifDePompage Cuve 1..* niveau : entier arm : boolen actif : boolen contient

dbite PriseDeCarburant quantitCarburant : rel { ordonnes par date} TransactionsDuJour TransactionClient typePaiement : TypePaiement date : Date montant : rel 1..*

Carburant prix : rel typeCarburant : TypeCarburant

numration TypeCarburant sansPlomb98 sansPlomb95 super diesel

0..*

archiver()

4. Les diffrents types de carburants peuvent tre modliss en crant des classes qui hritent de la classe Carburant (gure 6.8).

Figure 6.8
Modlisation des types de carburants par un hritage.
SansPlomb98

Carburant

SansPlomb95

Diesel

Super

Cependant, nous avons utilis une numration la place de lhritage, car un hritage ne se justie que si au moins une classe drive possde un attribut, une association ou une mthode spcique, ce qui nest pas le cas ici. Le diagramme de classes de la gure 6.10 contient une numration appele TypeCarburant qui est utilise pour typer lattribut typeCarburant de la classe Carburant. Le client peut choisir parmi trois modes de paiement : par carte bancaire, en espces ou par chque. Or, jusqu prsent, nous ne disposons, dans notre modle, que dune seule classe pour grer le paiement : TransactionClient (gure 6.7). Le paiement par carte bancaire est particulier car la transaction doit tre valide auprs de la banque. Si le client souhaite payer par chque, il doit donner au pompiste un identiant, son numro de carte didentit, par exemple. Ces particularits incitent transformer la classe TransactionClient en une classe de base dont hritent trois classes (gure 6.9) : TransactionEnEspces, TransactionBancaire et TransactionParChque. La classe TransactionClient est abstraite car elle possde lopration abstraite payer. Celle-ci sera implmente dans les

202

UML 2

Chapitre
classes drives et permettra ainsi de particulariser le paiement. Lattribut identiantClient a t ajout la classe TransactionParChque pour que celle-ci puisse conserver lidentiant dun client payant par chque.

Figure 6.9
Un hritage pour modliser les transactions.
TransactionClient {abstract} date : Date montant : rel payer {abstract}

TransactionEnEspces

TransactionBancaire

TransactionParChque identifiantClient : entier

payer

payer

payer

La technique de lhritage permet dtendre le domaine au plus grand nombre dapplications possibles. Or, il est rare aujourdhui quune station-service vende uniquement du carburant. En observant le graphe dhritage de la gure 6.9, on saperoit que les transactions des clients peuvent sappliquer la vente de nimporte quel produit ou service. Ce qui caractrise la vente de carburant, cest lassociation tablie entre les classes TransactionClient et PriseDeCarburant. Pour gnraliser la vente dautres services, une nouvelle classe appele Service est cre (pour ne pas trop sortir du cadre de cette tude, la vente de produits nest pas prise en compte). La prise de carburant devient alors un service, et la classe PriseDeCarburant hrite de la classe Service (gure 6.10). Pour linstant, aucun service supplmentaire na t ajout au modle, mais si, lavenir, un service dentretien de vhicules venait tre cr, le graphe dhritage des services serait prt recevoir une classe appele EntretienVhicule. Pour tester en profondeur les chemins daccs aux classes, vous pouvez dnir des requtes utilisant le langage OCL. Une autre technique consiste employer des diagrammes dinteraction (de squence ou de communication) pour montrer comment des objets, instances des classes, collaborent la ralisation des cas dutilisation. Mais avant dutiliser les interactions, il faut avoir dvelopp le modle de lanalyse de lapplication. Ce que nous ferons juste aprs avoir regroup les classes en paquetages et bti le modle des tats du domaine. 5. la gure 6.10, deux ensembles de classes correspondant deux fonctionnalits de la station-service apparaissent : un premier ensemble concerne la prise de carburant (il regroupe les classes EnsemblePompe, Pistolet, Gchette, DispositifDePompage, Cuve, Carburant, PriseDeCarburant et Service), et un deuxime a trait aux transactions (TransactionsDuJour, TransactionClient, TransactionEnEspces, TransactionBancaire, Transaction-ParChque, PriseDeCarburant et Service). Les classes lies la prise de carburant sont regroupes dans un paquetage appel ServiceCarburant, tandis que les classes relatives aux transactions sont incluses dans un paquetage appel Transactions (gure 6.11).

UML en pratique 203

Figure 6.10
Diagramme de classes du domaine.
Pistolet dansEtui : boolen Gchette appuye : boolen

contrle activation

Pompe carburant dans DispositifDePompage arm : boolen actif : boolen 1..* Cuve niveau : entier contient

1..* EnsemblePompe numroPompe : entier PriseDeCarburant quantitCarburant : rel {ordonnes par date} TransactionsDuJour Pistolet archiver() TransactionClient {abstract} date : date montant : rel payer {abstract} numration TypeCarburant sansPlomb98 sansPlomb95 super diesel Service

dbite Carburant prix : rel typeCarburant : TypeCarburant

0..*

TransactionEnEspces

TransactionBancaire

TransactionParChque identifiantClient : entier

payer( )

payer( )

payer( )

Figure 6.11
Paquetages du modle du domaine.

Transactions

ServiceCarburant

Remarque
Il faut essayer de limiter les dpendances entre paquetages car cela facilite la rutilisabilit spare des paquetages dans dautres projets. Il y a dpendance entre deux paquetages quand une association existe entre deux classes appartenant deux paquetages diffrents. Si lassociation est bidirectionnelle, la dpendance lest aussi (gure 6.12). Dans ce cas, il est peut-tre possible de limiter lassociation un seul sens (ce qui supprime une des deux dpendances entre les paquetages). Il ne faut pas oublier non plus que la dpendance entre deux paquetages dpend aussi du nombre de messages qui circulent sur lassociation. Plus le nombre de messages est lev, plus la dpendance est forte. Si ce nombre est trop important, il faut peut-tre revoir la rpartition des classes entre les paquetages an que lassociation qui est en cause ne les relie plus.

204

UML 2

Chapitre

Figure 6.12
Double dpendance entre paquetages.

Figure 6.13
Simple dpendance entre paquetages.
A B

MODLE

DES TATS DU DOMAINE


Le modle des classes du domaine est prsent complet. Il na cependant pas t valid par dautres modles qui vont lclairer sous un nouveau jour. Aprs avoir construit le diagramme de classes du domaine, il faut prsent tudier chaque classe sparment et reprer celles qui engendrent des objets au cycle de vie complexe. Pour ces classes particulires, il faut construire un diagramme dtats-transitions. 1. Identiez des classes du domaine ayant des tats complexes. 2. Pour chaque classe ayant des tats complexes : dnissez les tats ; trouvez les vnements ; construisez les diagrammes dtats. 1. Seules les classes DispositifDePompage et TransactionClient (avec ses classes drives) ont des tats complexes. 2. Un diagramme dtat dbute au moment o une instance est cre. tant donn que la classe TransactionClient contient une opration abstraite (payer), elle ne peut pas tre instancie. Ses classes drives (TransactionEnEspces, TransactionBancaire et TransactionParChque) implmentent lopration payer, ce qui leur permet dtre instanciables. Linstanciation intervient ds que le pompiste slectionne le mode de paiement choisi par le client. Il faut prsent imaginer des tats. Ltat dun objet est souvent caractris par la valeur instantane de ses attributs et de ses liens vers dautres objets. On en dduit plusieurs tats possibles : type de paiement choisi ; paye ; archive. Les vnements qui dclenchent des transitions vers ces tats sont : choix du mode de paiement ; valider la transaction.

UML en pratique 205

partir des tats et des vnements prcdents, le diagramme dtats-transitions est construit.

Figure 6.14
Diagramme des tats-transitions pour la classe TransactionClient.

type paiement choisi annuler

paiement valid valider paiement archiver

archiv

Remarque
Le modle du domaine doit dpendre le moins possible des applications qui vont reposer sur lui. Il faut donc essayer, quand on construit ce modle, de ne pas y faire inter venir des considrations lies une application particulire. Il est donc important de commencer par trouver les tats avant les vnements. Commencer par chercher les vnements conduit rchir la manire dutiliser un systme, ce qui revient imaginer une application par ticulire.

Intressons-nous prsent la deuxime classe qui engendre des objets ayant des tats complexes : la classe DispositifDePompage. quel moment des instances doivent-elles tre cres ? Cest difcile dire en ltat actuel de lanalyse : en effet, le dispositif de pompage en tant que priphrique matriel existe indpendamment du logiciel qui va le piloter, mais quen est-il des instances de la classe DispositifDePompage ? Quand le client arrive pour prendre de lessence, il a plusieurs pistolets (un par type de carburant) sa disposition. Ds quil a pris un pistolet, le type de carburant quil dsire est connu. On sait donc dans quelle cuve il faut puiser du carburant. Chaque cuve a des pompes particulires que notre logiciel va devoir piloter. Le pilotage commence donc ds que le client dcroche un pistolet (il faut alors armer le dispositif de pompage). Linstance ne doit pas forcment tre cre ce moment-l car cela a peut-tre dj t fait auparavant. Comme nous ne pouvons pas le savoir pour linstant, nous ne prcisons pas dans le diagramme suivant lvnement qui instancie un dispositif de pompage. Pour un dispositif de pompage, les tats possibles sont les suivants : arm ou dsarm en fonction des actions du pompiste ; bloqu ou dbloqu selon que le pistolet est rang ou non ; actif ou inactif selon que lessence est en train dtre pompe ou non. laide des tats et des vnements ci-dessus, on en dduit le diagramme dtats-transitions de la gure 6.15. Notons que quand le client raccroche le pistolet, la pompe est automatiquement dsarme.

206

UML 2

Chapitre

Figure 6.15
Diagramme des tatstransitions de la classe DispositifDePompage.
armer dsarm bloqu

arm

dcrocher pistolet

dbloqu pression gchette raccrocher pistolet inactif dpression gchette actif

Analyse de lapplication
Lanalyse de lapplication commence par ltude des cas dutilisation. Ce modle reprsente le systme informatique de la station-service vu par les acteurs. Il est construit indpendamment du modle du domaine de lapplication. Par la suite, ces deux modles seront confronts pour vrier que les classes du domaine permettent de raliser les cas dutilisation. Lanalyse complte de lapplication se fait en btissant trois modles : le modle des interactions de lapplication ; le modle des classes de lapplication ; le modle des tats de lapplication. La phase danalyse se conclut par lajout doprations aux classes.

MODLE

DES INTERACTIONS DE LAPPLICATION

1. Dterminez les limites du systme. Trouvez les acteurs. Trouvez les cas dutilisation. Construisez le diagramme de cas dutilisation. 2. Prparez les scnarios pour dcrire les cas. Ajoutez des squences alternatives et des squences dexceptions aux scnarios. Prparez des diagrammes dactivit pour des cas dutilisation complexes. 3. Vriez la cohrence entre le modle des classes du domaine et celui de lapplication. 1. Les quatre premires questions ont t traites dans la partie exercices du chapitre 1. Vous y trouverez des explications sur la dmarche qui a permis daboutir au diagramme prsent la gure 6.16.

UML en pratique 207

Figure 6.16
Diagramme de cas dutilisation de la station-service.

Capteur niveau cuve pour armement

Capteur niveau cuve pour remplissage

Station Service Vrifier niveau cuve pour armement inclut inclut Se servir Armer pompe Points dextension : paiement : { la fin du cas se servir } tend Payer Vrifier niveau cuve pour remplissage

Client

Pompiste

Condition : {si le client a pris de lessence avant de raccrocher le pistolet} Point dextension : paiement

Payer par carte bancaire Banque Payer par chque

Payer en espces Archiver les transactions

Tous les soirs minuit Timer

2. Les cas dutilisation doivent tre dcrits sous forme textuelle comme indiqu au chapitre 1. Certains peuvent tre dcrits laide de diagrammes de squence ou par des diagrammes dactivit. Pour chaque cas, il faut dnir une squence nominale ainsi que des squences alternatives et dexceptions. Pour des raisons de place, la description textuelle des cas et les squences alternatives et dexceptions ne sont pas prsentes. Un cas dutilisation est dclench quand un vnement survient. Le dictionnaire suivant liste les vnements qui initient les cas dutilisation. Comme nous lavons vu au chapitre 1, les vnements peuvent tre classs en trois catgories : les vnements externes ; les vnements temporels ; les vnements dtats.

208

UML 2

Chapitre
vnement temporel qui dclenche le cas Archiver les transactions . Cest aussi un vnement externe car le temps est considr comme un acteur : acteur Timer. vnement externe produit par lacteur Pompiste qui dclenche un des trois cas particuliers de paiement : Payer par carte bancaire , Payer en espces et Payer par chque . vnement externe produit lacteur Client qui dclenche le cas Se servir . vnement externe produit par lacteur Pompiste qui dclenche le cas Armer Pompe . vnement dtat, car produit lors du droulement du cas Se servir , qui dclenche le cas Vrier niveau cuve pour armement . vnement externe produit par lacteur Capteur niveau cuve pour remplissage qui dclenche le cas Vrier niveau cuve pour remplissage . vnement externe produit par lacteur Pompiste qui dclenche le cas payer .

Il est minuit lhorloge systme Choix du mode de paiement Dcrochage dun pistolet Demande armement pompe Demande niveau dans cuve pour armement Niveau dans cuve pour remplissage atteint Encaissement (pompe, typeCarburant)

On remarque sur le diagramme de la gure 6.16 que le paiement intervient aprs que le client a pris de lessence. En situation relle, il faudrait sinquiter de lvolutivit de notre application et considrer le cas o le paiement interviendrait avant. Il faudrait aussi offrir la possibilit au client de payer lui-mme, directement avec une carte de crdit dans le terminal de la pompe, sans lintervention du pompiste. La gure 6.17 montre comment le diagramme de cas dutilisation peut tre transform pour que le paiement puisse intervenir avant que le client prenne de lessence. Dans la suite de cette tude de cas, nous revenons la situation initiale (cas o le client paye aprs avoir pris du carburant).

Figure 6.17
Points dextension qui prcisent quand le paiement intervient.
Client Point dextension : paiementAvant (le paiement se fait avant de se servir) Se servir Points dextension : - paiementAvant - paiementAprs Point dextension : paiementAprs (le paiement se fait aprs stre servi)

tend Payer

Payer par carte bancaire Banque

Payer en espces

Payer par chque

UML en pratique 209

Scnario nominal pour Se servir du carburant. La gure 6.18 tablit le scnario nominal du cas dutilisation Se servir du carburant. noter la boucle qui indique que le client peut appuyer et relcher plusieurs fois la gchette avant de reposer le pistolet. Il est galement fait rfrence un diagramme appel ArmerPompe. On indique ainsi que larmement est inclus dans la prise dessence.

Figure 6.18
Scnario nominal du cas Se servir .

sd Se servir

: Station-service Client Dcrochage dun pistolet ref ArmerPompe

loop [ pistolet hors tui ] Appui sur la gchette Affiche quantit essence + montant Relchement de la gchette Raccrochage du pistolet Dsarmer pompe

La gure 6.19 donne le scnario nominal pour le cas Armer Pompe . La vrication du niveau des cuves pour larmement y est incluse. De plus, on vrie que plusieurs pistolets nont pas t dcrochs.

210

UML 2

Chapitre

Figure 6.19
Scnario nominal du cas Armer pompe .

sd ArmerPompe

: Station service Pompiste

Affiche numro de pompe + type essence prise Demande armement pompe

Tester si un autre pistolet nest pas dcroch

ref

VrifierNiveauCuvePourArmement

RAZ compteur volume et montant + prix du litre Affiche confirmation armement

Le scnario nominal pour le cas Vrier niveau cuve pour armement est donn la gure 6.20.

Figure 6.20
Scnario nominal du cas Vrier niveau cuve pour armement .

sd VrifierNiveauCuvePourArmement

: Station service

Capteur niveau pour armement Demande niveau dans cuve pour armement

Niveau dans cuve pour armement OK

UML en pratique 211

Remarque
Le diagramme de cas dutilisation dtaille de manire trs prcise les fonctions de la station-service (on y voit larmement ainsi que la vrication du niveau des cuves). Il eut t possible de dcrire le systme plus sommairement comme le montre la gure 6.21. Malgr ce changement dchelle, le scnario pour se servir de lessence ne change pas. La gure 6.22 le reproduit. On y retrouve superposes les gures 6.18, 6.19 et 6.20, qui reprsentent la station-service, avec plus de dtails. Ceci dnote limportance tout relative des relations dinclusion, dextension et de gnralisation qui peuvent agrmenter un diagramme de cas dutilisation. Dailleurs, certains modlisateurs ignorent dans un premier temps les relations entre les cas, et tablissent dabord les scnarios.

Figure 6.21
Diagramme de cas dutilisation montrant moins de dtails.
Station Service Vrifier niveau cuve pour remplissage Capteur niveau cuve pour armement Capteur niveau cuve pour remplissage

Se servir Points dextension : paiement : { la fin du cas se servir }

Client Condition : {si le client a pris de lessence avant de raccrocher le pistolet} Point dextension : paiement

Pompiste

tend

Payer

Payer par carte bancaire Banque Payer par chque

Payer en espces Archiver les transactions

Tous les soirs minuit Timer

212

UML 2

Chapitre

Figure 6.22
Scnario nominal des cas Se servir , Armer pompe et Vrier niveau cuve pour armement .

sd Se servir + Armer pompe + Vrifier niveau cuve pour armement

: Station service Client Dcrochage dun pistolet sd ArmerPompe Affiche numro de pompe + type essence pris Demande armement pompe Tester si un autre pistolet nest pas dcoch Pompiste Capteur niveau pour armement

sd VrifierNiveauCuvePourArmement Demande niveau dans cuve pour armement

Niveau dans cuve pour armement OK

RAZ compteur volume et montant + prix du litre Affiche confirmation armement loop [ pistolet hors tui ] Appui sur la gchette Affiche quantit essence + montant

Relchement de la gchette

Raccrochage du pistolet Dsarmer pompe

Scnario nominal du cas Payer . Intressons-nous prsent au cas du paiement. Le diagramme de cas dutilisation de la gure 6.16 indique une relation de gnralisation entre les cas Payer par carte bancaire , Payer par chque , Payer en espces et Payer . On signie ainsi que le paiement commence se drouler uniformment puis se spcialise en trois cas particuliers. La divergence de traitement intervient quand le pompiste choisit le mode de paiement conformment la demande du client. Le diagramme montre alors une rfrence un comportement polymorphe, TransactionClient.payer, qui correspond linvocation de lopration payer de la classe TransactionClient gurant dans le diagramme de classes du domaine (gure 6.10). noter aussi que le paiement dbute quand le pompiste slectionne la pompe et le type de carburant dont sest servi le client. La gure 6.23 illustre le scnario nominal du cas payer . On remarque aussi la rfrence faite TransactionClient.payer. On indique ainsi que cette partie du scnario peut varier en fonction du mode choisi.

UML en pratique 213

Figure 6.23
Scnario nominal pour le cas payer .
sd payer : Station-service Pompiste encaissement (pompe, typeCarburant) Affiche montant payer Choix du mode de paiement

ref

TransactionClient.payer

3. La vrication doit tre minutieuse : il sagit dtudier attentivement tous les scnarios en vriant si les classes possdent tous les attributs et les chemins (les associations) ncessaires pour y accder. La vrication tant fastidieuse, elle na pas t reproduite ici.

MODLE

DES CLASSES DE LAPPLICATION


Les classes que nous avons dcouvertes jusqu prsent sont issues du domaine de lapplication. Elles sont a priori valables pour toutes les applications possibles dans le cadre dune station-service. Cependant, elles ne sont pas sufsantes pour faire fonctionner une application particulire. Par exemple, quand le pompiste interagit avec les classes du domaine via un terminal, un ensemble de classes supplmentaires doit raliser des conversions de donnes, an de traduire les attributs des classes du domaine dans un format plus parlant pour le pompiste. 1. Spciez linterface homme-machine. 2. Dnissez les classes la priphrie du systme. 3. Dnissez des classes pour contrler le systme. Contrlez la cohrence avec le modle des interactions. 1. Pour spcier linterface homme-machine, on en construit souvent une maquette (gure 6.24). Elle reprsente lcran principal auquel fait face le pompiste. Il est compos de n zones, chacune appele Pompe i (pour i allant de 1 n). Chaque zone est constitue de quatre boutons qui permettent au pompiste de demander larmement dune pompe. Si le niveau dessence dans les cuves est sufsant, la pompe est arme et le bouton correspondant reste enfonc. Si, au contraire, le niveau dessence est insufsant, le bouton de la pompe apparat en rouge. Ds que le client a ni de se servir (il a raccroch le pistolet), le bouton de la pompe correspondant au type dessence quil a pris clignote. Les boutons correspondant aux types dessence choisis peuvent tre dans lun des tats suivants :

214

UML 2

Chapitre
non enfonc (pompe dsarme) ; enfonc (pompe arme) ; rouge (armement impossible) ; clignotant (n de prise de carburant).

Figure 6.24
cran principal du terminal du pompiste.
Pompe 1 SansPlomb98 SansPlomb95 Diesel Super Pompe n SansPlomb98 SansPlomb95 Diesel Super

Ds que le pompiste appuie sur un bouton clignotant, la zone de lcran correspondant la pompe est remplace par une zone servant au paiement (gure 6.25).

Figure 6.25
cran du terminal du pompiste tel quil apparat au moment du paiement.
Pompe 1 Pompe n

Montant payer : 30 euros Carte bancaire

SansPlomb98

SansPlomb95

Chque

Diesel

Espces

Super

Valider transaction

Zone de lcran pour le paiement

Zone de lcran montrant des pompes dsarmes

Le pompiste peut choisir, via linterface prsente la gure 6.25, le type de paiement dsir par le client (carte bancaire, chque ou espces). Le bouton correspondant au mode de paiement choisi reste enfonc une fois slectionn. Le pompiste peut appuyer sur le bouton qui valide la transaction ds que le client a pay. partir de cette maquette la dmarche consiste btir un diagramme de classes qui doit reter les changes de donnes vhicules entre cette interface et le cur du logiciel.

UML en pratique 215

La construction de ce diagramme suit les tapes habituelles suivantes : dresser une liste de classes ; trouver les associations entre les classes ; etc. Ayant dj ralis une tude similaire pour construire le diagramme de classes du domaine, ltude des classes de linterface utilisateur na pas t reproduite. 2. Notre logiciel doit tre interfac avec des priphriques matriels : des capteurs de niveau dessence dans les cuves, un terminal de paiement, etc. Nous nous contenterons dtudier les priphriques qui grent le niveau de carburant dans les cuves. Vous pourrez facilement en dduire les autres cas par analogie. La gure 6.26 est extraite du diagramme de dploiement de la gure 6.4. Seuls les nuds permettant la gestion des capteurs de niveau sont reprsents. Le priphrique de gestion des cuves est externe au systme informatique de la station-service. Il sagit par exemple dun botier dont les extrmits sont raccord un capteur de niveau et lunit centrale. Un composant qui pilote le priphrique de gestion des cuves est charg de fournir une classe du domaine le niveau du carburant via une interface (appel PiloteGestionCuve).

Figure 6.26
Composant permettant daccder aux priphriques de gestion des cuves.
Priphrique de gestion des cuves : PiloteGestionCuve InterfaceCuve

unit centrale Systme informatique de la station service

niveau

La gure 6.27 dtaille linterface InterfaceCuve et montre que la classe Cuve extraite du diagramme de classes de la gure 6.10 est cliente de cette interface.

Figure 6.27
La classe Cuve comme classe cliente de linterface InterfaceCuve.

interface InterfaceCuve getNiveau : entier

Cuve niveau : entier

3. En plus des classes qui se trouvent la priphrie dun systme et celles qui grent linterface homme-machine, un logiciel est constitu dobjets qui le contrlent. Chaque objet contrleur est ddi une fonction particulire. Dans notre cas, il sagit de trois fonctions bien distinctes : la prise dessence, le paiement et larchivage des transactions. Pour commencer, tentons dimaginer un objet qui puisse contrler la prise dessence. Session de prise dessence. Ds quun client dcroche un pistolet, des instances des classes Pistolet, Gchette et DispositifDePompage sont prtes activer le priphrique matriel qui pompe lessence. Les tats des instances vont changer en fonction des actions des clients qui sont perues par le systme au travers de capteurs. Si N clients prennent du carburant simultanment, il y aura N ensembles dinstances de Pistolet, de Gchette et de

216

UML 2

Chapitre
DispositifDePompage. Pour contrler ces trois instances, nous crons une classe appele SessionDePriseDeCarburant. Le diagramme des objets prsent la gure 6.28 montre deux clients qui se servent du super 98 simultanment, chacun ayant sa propre session.

Figure 6.28
Diagramme dobjets qui montre deux sessions de prise dessence.
client1

session1

EnsemblePompe1 numro : entier = 1

pistolet1

gchette1 pompe1 : DispositifDePompage priseDeCarburant1

carburant Cuve typeCarburant : TypeCarburant = sansPlomb98

priseDeCarburant2 EnsemblePompe2 numro : entier = 2

pistolet2

gchette2

pompe2 : DispositifDePompage

session2

client2

Pour illustrer comment la session dun client interagit avec les instances des classes Pistolet, Gchette et DispositifDePompage, on dnit une collaboration (gure 6.29).

Figure 6.29
Une collaboration qui permet de montrer le droulement dune session de prise dessence.
La SessionDePriseDeCarburant

: Pistolet

: Gchette

: DispositifDePompage

: Cuve : SessionDePriseDeCarburant

UML en pratique 217

Cette collaboration est dcrite plus en dtail la gure 6.30. Elle dbute par la cration dune session pour un client (instance de la classe SessionDePriseDeCarburant). Ensuite, des instances des classes Pistolet, Gchette et Pompe sont cres leur tour. Cest l un parti pris. Nous avons en effet dcid que ces instances nexistaient pas avant que le client dcroche un pistolet. Une autre solution aurait consist disposer dun pool dobjets prts lemploi dans lequel on aurait pris volont des instances. Ce choix relve plutt de la conception que de lanalyse. Considrons-le comme un scnario de conception possible. La gure 6.30 montre que les instances du pistolet et de la gchette sont dtruites ds que le client raccroche le pistolet. Deux autres diagrammes servant illustrer larmement de la pompe et la prise du carburant sont rfrencs.

Figure 6.30
Interaction qui illustre la collaboration de la gure 6.29.

sd SessionDePriseDeCarburant

client : Client Dcrochage dun pistolet session : SessionDePriseDeCarburant

pompiste : Pompiste

pompe : DispositifDePompage : Pistolet gchette : Gchette Affiche numro de pompe + type essence pris

ref ArmementPompe( client, pompiste, session, pompe )

ref ActivationPompe( client, session, gchette, pompe )

Raccrochage du pistolet

Affiche la fin de la prise dessence

Dsarmer pompe

Larmement de la pompe est illustr par le diagramme de la gure 6.31. On y voit que, avant darmer la pompe, il faut tester si plusieurs pistolets ne sont pas dcrochs, puis vrier le niveau de la cuve. Lacteur CapteurNiveauPourArmement nest pas reprsent ici : il est sollicit implicitement par linstance de la cuve.

218

UML 2

Chapitre

Figure 6.31
Interaction qui illustre larmement de la pompe.

sd ArmementPompe( inout client : Client, inout pompiste : Pompiste, inout session : SessionDePriseDeCarbutant, inout pompe : DispositifDePompage)

+autrePistolet : boolen

pompe : DispositifDePompage client : Client cuve : Cuve

session : SessionDePriseDeCarburant pompiste : Pompiste Demande armement pompe

ref autrePistolet = TestAutrePistoletPris

opt

[ autrePistolet == false ] Demande Armement Demande niveau dans cuve pour armement Niveau dans cuve pour armement OK

armer armement OK

RAZ compteur volume et montant + prix du litre Affiche confirmation armement

La gure 6.31 fait rfrence au diagramme TestAutrePistoletPris qui nest pas reprsent (il sagit simplement de demander linstance de lEnsemblePompe de vrier laide dune boucle quil ny a pas plusieurs pistolets dcrochs). Le diagramme reproduit la gure 6.32 dtaille linteraction ActivationPompe qui est rfrence la gure 6.30.

Figure 6.32
Interaction qui illustre lactivation de la pompe.

sd ActivationPompe( inout client : Client, inout session : SessionDePriseDeCarburant, inout gchette : Gchette, inout pompe : DispositifDePompage )

session : SessionDePriseDeCarburant client : Client loop Appui sur la gchette

gchette : Gchette

pompe : DispositifDePompage

Appuyer sur la gchette activer

Relchement de la gchette Relcher la gchette dsactiver

UML en pratique 219

Session de paiement. Intressons-nous prsent au paiement, et imaginons un objet pour le contrler. Si la session de prise de carburant (instance de la classe SessionDePriseCarburant) tait prolonge de manire englober le paiement, un objet pourrait alors contrler le service de prise dessence de bout en bout , depuis le dcrochage du pistolet jusqu la n du paiement. Ce serait la session complte dun client. Or, les classes du domaine ont t partitionnes en deux paquetages pour accrotre la modularit du logiciel : un paquetage concerne la prise dessence, lautre le paiement. Une session client unique serait donc partage entre les deux paquetages (elle dbuterait avec la prise de carburant pour se terminer par le paiement). Cest pourquoi nous avons dcid de crer une nouvelle classe contrleur (SessionDePaiement) qui se charge du paiement. La gure 6.33 tablit une collaboration entre des instances de PriseDeCarburant, de TransactionBancaire, de TransactionsDuJour et de SessionDePaiement. Les connecteurs entre les instances de PriseDeCarburant, de TransactionBancaire et de TransactionsDuJour reprsentent les associations du diagramme de classes du domaine (gure 6.10).

Figure 6.33
Collaboration pour le paiement.
: PriseDeCarburant La SessionDePaiement

: TransactionBancaire

: TransactionsDuJour

session : SessionDePaiement

La gure 6.34 illustre les interactions au sein de la collaboration prcdente. La session de paiement dbute au moment o le pompiste demande, via son terminal, encaisser la prise dessence relative une pompe et un type de carburant. Le montant de la transaction est calcul laide du type de carburant (qui permet davoir le prix du litre) et de la quantit dessence prise. Le diagramme se poursuit par le droulement du scnario nominal de paiement par carte bancaire. Une instance de TransactionBancaire est cre le temps de raliser une transaction avec la banque. Ds que le pompiste valide la transaction, celle-ci est ajoute aux transactions du jour pour tre nalement dtruite. La session de paiement se termine juste aprs, par la destruction de linstance correspondante.

220

UML 2

Chapitre

Figure 6.34
Interaction qui illustre comment le paiement est ralis durant la session de paiement.

sd payer par carte bancaire

: TransactionsDuJour pompiste : Pompiste Banque : SessionDePriseDeCarburant encaissement( pompe, typeCarburant ) session : SessionDePaiement demande la quantit pompe quantit Calcul du Montant Afficher montant payer Choix du mode de paiement

opt : TransactionBancaire validerTransaction( montant ) Transaction valide

[ paiement par carte bancaire]

Paiement effectu Informe pompiste

Valide la transaction Valider transaction

Ajouter la transaction client

Un gestionnaire pour larchivage. Aprs avoir trouv des objets contrleurs pour assurer les fonctions de prise dessence et de paiement, intressons-nous aux autres fonctions du logiciel. Pour cela, revenons au diagramme de cas dutilisation de la gure 6.16. Deux cas nont pas t traits : Vrier niveau cuve pour remplissage et Archiver les transactions . Le premier cas nest pas tudi dans cet ouvrage car il ne prsente pas un grand intrt. Larchivage des transactions est plus intressant.

UML en pratique 221

Le diagramme de la gure 6.35 montre comment, en n de journe, les transactions du jour sont archives. Pour raliser cette fonction, nous ajoutons une nouvelle classe, GestionnaireDesArchivages. Une seule instance de cette classe est ncessaire pour faire fonctionner larchivage. Lobjet correspondant est actif une fois par jour ( minuit). Il demande larchivage des transactions du jour ; aprs quoi linstance de la classe TransactionsDuJour est dtruite pour tre recre aussitt (et initialiser ainsi une nouvelle journe de transactions).

Figure 6.35
Diagramme qui illustre comment le gestionnaire des archivages ralise la sauvegarde quotidienne des transactions.
sd Archiver les transactions

: TransactionsDuJour

: GestionnaireDesArchivages Timer

loop archiver

Il est minuit lhorloge systme

: TransactionsDuJour

MODLE

DES TATS DE LAPPLICATION


Ltude de lapplication a conduit lajout de classes supplmentaires. Il faut prsent reprer parmi ces classes celles qui engendrent des instances ayant des tats complexes, et pour chacune delles, suivre la dmarche suivante : identier des classes de lapplication avec des tats complexes ; trouver les vnements ; construire les diagrammes dtats ; vrier la cohrence avec les autres modles. Cette tude, bien quindispensable, na pas t reproduite ici car elle nest pas dun grand intrt pdagogique.

AJOUT

DES OPRATIONS
La phase danalyse de notre logiciel est prsent presque acheve. Il reste ajouter des oprations aux classes. Les oprations peuvent tre dduites des cas dutilisation et des scnarios. Considrons nouveau le diagramme de la gure 6.31 (o le test sur le nombre de pistolets dcrochs a t omis). Rcrivons les messages destins aux objets en respectant la syntaxe des messages utiliss dans les diagrammes de squence (voir chapitre 3).

222

UML 2

Chapitre

Figure 6.36
Les messages destins aux objets mis la norme des diagrammes de squence.
sd ArmementPompe (inout client : Client, inout pompiste : Pompiste, inout session : SessionDePriseDeCarbutant, inout pompe : DispositifDePompage)

pompe : DispositifDePompage client : Client cuve : Cuve

session : SessionDePriseDeCarburant pompiste : Pompiste armementPompe armement

niveauSuffisantPourArmement

niveauSuffisantPourArmement : vrai armer armement : vrai RAZ compteur volume et montant + prix du litre Affiche confirmation armement

Chaque message destin un objet devient une opration pour la classe correspondante. La classe Cuve par exemple contient prsent lopration niveauSufsantPourArmement() : boolen comme le montre la gure 6.37.

Figure 6.37
Ajout dune opration la classe Cuve.

Cuve niveau : entier niveauSuffisantPourArmement() : boolen

Procder ainsi systmatiquement pour tous les diagrammes dinteraction produits permet dajouter des oprations aux classes. La gure 6.38 montre des classes qui concernent la prise de carburant auxquelles ont t ajoutes des oprations.

UML en pratique 223

Figure 6.38
Quelques classes du domaine avec leurs oprations.
SessionDePriseDeCarburant

demandeArmementPompe : boolen dcrochagePistolet( numroPompe : entier, typeCarburant : TypeCarburant ) raccrochagePistolet appuiGchette relachementGchette

Gchette appuye : boolen appuyer relcher DispositifDePompage arm : boolen actif : boolen

PriseDeCarburant quantitCarburant : rel getQuantitCarburant : rel

armement : boolen armer : boolen dsarmer : boolen activer : boolen dsactiver : boolen

Phase de conception
La phase danalyse est prsent termine. Ltude a permis de prciser ltendue des besoins auquel doit rpondre le logiciel de gestion dune station-service, mais aussi spcier et comprendre ce quil doit faire. Dans la phase suivante, la conception, il sagit de dcider comment raliser ce logiciel. Cette phase passe par de nombreuses tapes o UML nest pas utile (le choix des ressources ncessaires pour excuter le logiciel par exemple). Dans la suite de ce chapitre, nous nous intressons aux seules tapes o UML est utile.

CONCEPTION

DU SYSTME

1. Dcomposez le systme en sous-systmes. 2. Reprez les objets qui sexcutent concurremment. 1. Isoler la couche mtier pour prvoir la rutilisabilit des classes du domaine . Un dcoupage possible en sous-systmes est prsent la gure 6.39. Il y a quatre couches : Tout en haut, la couche de prsentation contient linterface homme machine du pompiste. Les classes contrleurs (SessionDePriseDeCarburant, SessionDePaiement et GestionnaireDesArchivages) constituent la couche applicative.

224

UML 2

Chapitre
La logique mtier est compose des classes du domaine (reprsentes ici par les paquetages qui les contiennent). La gestion des priphriques (capteurs de niveau des cuves, gestion des pompes et du terminal de paiement) est incluse dans la couche de services. noter la relation de dpendance qui existe entre la couche applicative et la couche de services : elle indique que larchivage dans la base de donnes (non reprsente) est directement gr par le gestionnaire de la persistance (GestionnairePersistance) sans passer par la couche mtier.

Figure 6.39
Architecture du logiciel de gestion de la station-service.
layer Prsentation

layer Logique applicative ________________________ +SessionDePriseDeCarburant +SessionDePaiement + GestionnaireDesArchivages

layer Logique mtier Transactions ServiceCarburant

layer Services ______________________ +PiloteGestionCuve +Pompe +PiloteGestionPaiement +GestionPersistance

Le systme a donc t dcoup en couches horizontales. Lapplication, essentiellement contenue dans la couche applicative, permet, grce aux classes contrleurs, de raliser les cas dutilisation. Sans ses classes contrleurs, couche applicative et couche mtier seraient

UML en pratique 225

mlanges tel point que la rutilisabilit des classes de la couche mtier serait compromise. La sparation entre logique applicative et logique mtier permettra une autre application de rutiliser les classes du domaine. Augmenter la rutilisabilit par partie du logiciel. Le dcoupage en couches prcdent a permis disoler la partie mtier (les classes du domaine) an de ne pas lencombrer avec les dtails de lapplication. Une autre partition du logiciel est possible par fonctionnalits. Dailleurs, bien souvent, ces deux types de dcoupage sont raliss simultanment. Une partition fonctionnelle a dj t ralise quand nous avons spar les classes du domaine en deux paquetages (gure 6.11). Il est possible disoler les paquetages en les plaant dans un classeur structur (voir lannexe B). La gure 6.40 prsente un classeur structur qui contient le paquetage ServiceCarburant.

Figure 6.40
Structure interne du classeur structur PriseCarburant.

PriseCarburant

ServiceCarburant

Le classeur PriseCarburant interagit avec son environnement via des ports (gure 6.41). Certains reoivent ltat des capteurs pistolet et gchette, dautres servent dinterface avec le pompiste ou avec le moteur de la pompe, dautres encore servent rcuprer la quantit dessence pompe.

Figure 6.41
Ports du classeur PriseCarburant.

InterfacePompiste

Entre tat capteur pistolet InterfacePistolet PriseCarburant InterfaceGchette Entre tat capteur gchette

Sortie commandes pompe

Sortie quantit essence pompe

InterfaceDbitmtre

226

UML 2

Chapitre
Ces interfaces ont t labores partir des classes contenues dans le paquetage du classeur structur. Par exemple, la classe SessionDePriseDeCarburant contient une opration destine au pompiste, deux oprations qui servent dinterface avec le pistolet, et deux oprations qui sont relies la gchette.

Figure 6.42
Sparation des oprations de la classe SessionDePriseDe Carburant pour prparer les interfaces.
SessionDePriseDeCarburant

demandeArmementPompe : boolen dcrochagePistolet( numroPompe : entier, typeCarburant : TypeCarburant ) raccrochagePistolet appuiGchette relachementGchette

opration invoque par le pompiste oprations lies au pistolet oprations lies la gchette

On retrouve ces trois ensembles doprations dans les trois interfaces : InterfacePompiste, InterfacePistolet et InterfaceGchette (gure 6.43). Ainsi, une seule classe interne un classeur structur peut tre accessible via plusieurs interfaces.

Figure 6.43
Interface qui indique si le pistolet est rang.
interface InterfacePistolet dcrochagePistolet( numroPompe : entier, typeCarburant : TypeCarburant ) raccrochagePistolet

interface InterfaceGchette appuiGchette relachementGchette

interface InterfaceDbitmtre getQuantitPompe : rel

interface InterfacePompiste

demandeArmementPompe() : boolen getNumeroPompe() : entier getTypeCarburant() : TypeCarburant priseCarburantTermine

La gure 6.44 montre comment le classeur structur PriseCarburant interagit avec son environnement quand un client appuie sur une gchette. Cette information est transmise au composant CapteurGchette, puis circule via linterface InterfaceGchette jusquau classeur structur PriseCarburant. Ce classeur est alors considr comme une bote noire (le composant CapteurGchette na pas accs sa structure interne). Il adopte un certain comportement qui engendre ventuellement une commande sur son port de sortie. Cette commande est rpercute jusquau moteur de la pompe en passant par le composant Pompe qui implmente linterface InterfacePompe (gure 6.45).

UML en pratique 227

Figure 6.44
Cheminement dune information depuis lappui sur une gchette jusqu la commande du moteur de la pompe.

Gchette

Moteur pompe Gchette

Priphriques de gestion des pompes

InterfaceCapteurGchette

: CapteurGchette

unit centrale Systme informatique de la station service

: Pompe

Entre tat capteur gchette PriseCarburant InterfaceGchette

Sortie commandes pompe

InterfacePompe

Figure 6.45
Vue dtaille de linterface qui contrle le moteur de la pompe.
interface InterfacePompe

armer : boolen dsarmer : boolen activer : boolen dsactiver : boolen

Le classeur PriseCarburant doit parfaitement sinsrer dans lapplication. Pour le vrier, les scnarios issus de lanalyse de lapplication peuvent tre repris an de montrer comment le classeur interagit avec son environnement. Utiliser un classeur structur muni de ports permet disoler la structure interne du classeur de son environnement. Le but tant de pouvoir facilement rutiliser ce classeur dans un environnement qui se conforme aux interactions imposes par ses ports. Le dcoupage opr avec le classeur PriseCarburant pourrait tre reproduit pour la gestion des transactions. Le systme informatique de la station-service ainsi dcoup gagne en modularit. Chaque sous-systme, qui est isol dans un classeur structur, peut tre facilement extrait du contexte de lapplication courante et utilis dans une autre application.

228

UML 2

Chapitre

Figure 6.46
Classeur structur dont le comportement est dcrit par une interaction.
PriseCarburant

ref SessionDePriseDeCarburant

ServiceCarburant

2. Le modle des tats dun systme est gnralement utilis pour reprer les objets qui sexcutent en parallle : deux objets sexcutent potentiellement en parallle sils peuvent recevoir des vnements en mme temps sans interagir. Si les vnements ne sont pas synchroniss, ces objets ne peuvent pas tre traits dans le mme thread de contrle. Dans notre cas, les vnements qui concernent la prise de carburant par un client ainsi que le paiement sont squentiels. En revanche, chaque client doit avoir sa propre session de prise de carburant et de paiement. Les instances des classes SessionDePriseDeCarburant et SessionDePaiement sexcutent toutes en parallle sans interagir, sauf au moment de larchivage des transactions. Larchivage est sous le contrle dun objet du type GestionnaireDesArchivages (gure 6.35). Que se passe-t-il alors si un client paye aprs stre servi de lessence minuit, au moment o larchivage se dclenche ? Larchivage utilise une instance des TransactionsDuJour (gure 6.35) et cette mme instance peut tre utilise concurremment par une session de paiement pour y ajouter la transaction dun client (gure 6.34). Le diagramme de la gure 6.47 utilise loprateur dinteraction par pour montrer que le gestionnaire des archivages et la session client peuvent accder concurremment linstance de TransactionsDuJour (le deuxime oprande est extrait de linteraction de la gure 6.34, o seul le message Ajouter la transaction client est pris en considration). Pour que la session de paiement ne vienne pas perturber larchivage, cette fonction est ralise dans une section critique grce loprateur dinteraction ritical (voir chapitre 3).

UML en pratique 229

Figure 6.47
Concurrence daccs sur linstance des transactions du jour.

sd archiver les transactions + se servir

: TransactionsDuJour

: GestionnaireDesArchivages Timer

: SessionDePaiement

par consider{ archiver, il est minuit lhorloge systme, ajouter la transaction client } critical archiver Il est minuit lhorloge systme

: TransactionsDuJour

critical Ajouter la transaction client

Conception des classes


Les diagrammes dactivit sont utiles toutes les tapes du dveloppement dun systme. En phase de conception, ils permettent de dcrire le fonctionnement interne des mthodes des classes an de prciser les algorithmes utiliss. Considrons le diagramme de squence suivant extrait du scnario de paiement par carte bancaire au moment o le pompiste valide la transaction du client. Celle-ci est alors ajoute lensemble des transactions du jour (instance de la classe TransactionsDuJour). Dcrivez laide dun diagramme dactivit comment la transaction du client est ajoute lensemble des transactions du jour.

230

UML 2

Chapitre

Figure 6.48
Diagramme de squence pour larchivage de transactions.
sd gestion des transactions

: TransactionsDuJour

: TransactionBancaire

session : SessionDePaiement Pompiste Valide la transaction

Valider transaction Ajouter la transaction client

Indications : on suppose que les transactions du jour sont structures en tableau, et que les transactions y sont tries par ordre croissant de leur montant en euros.

Figure 6.49
Diagramme de squence pour larchivage de transactions.

t1 : TransactionClient 10 euros

t2 : TransactionClient 12,3 euros

tn : TransactionClient 47 euros

Lalgorithme utilis pour ajouter une nouvelle transaction consiste parcourir le tableau la recherche de lemplacement o ajouter la transaction, puis faire de la place pour la nouvelle transaction en dcalant les transactions existantes. Lalgorithme propos correspond un tri par insertion, dont une modlisation est propose la question 3 de lexercice 3 du chapitre 5. La seule contrainte impose par lactivit tri insertion est que le type contenu dans le tableau pass en argument ralise linterface Comparable. Il suft donc dcrire un comparateur entre deux transactions qui corresponde lordre propos : t1 < t2 quivalent t1.montant < t2.montant. Cela peut simplmenter directement comme un oprateur en C++, ou comme une mthode en Java.

UML en pratique 231

Annexe A

Comparatif des outils de modlisation


Introduction
Pour se servir efcacement dUML, il faut utiliser un outil adapt vos besoins. Labondance de loffre en la matire rend son choix trs difcile. Lobjectif de cette annexe est den prsenter brivement quelques-uns an de permettre le choix rapide et efcace de loutil le mieux adapt. Un accent sera mis sur le cot des licences. Nous prciserons, en particulier, si les outils disposent dune licence dite acadmique, permettant aux professionnels dbutants, aux tudiants et aux formateurs dillustrer lintrt dUML, sans devoir, dans un premier temps, investir dans une licence onreuse. Pour un simple diteur de diagramme UML, adapt aux phases danalyse et de conception, loffre est large, et le choix de loutil importe nalement peu, pourvu que son ergonomie soit raisonnable (placement des objets et des arcs, navigation entre les diagrammes). On pourra alors regarder du ct de lopen-source o les plugins ou petits outils UML abondent (BoUML, ArgoUML, TopCased), ou utiliser une version modeler dun outil professionnel. Un des intrt de la modlisation qui accompagne le dveloppement informatique est, dun cot, la production de code et, de lautre, la gnration de modles partir du code. De ce fait, il est important que votre outil propose des fonctions de rtro-ingnierie (extraction de modle depuis le code) et rciproquement de gnration de code depuis le modle (en gnral surtout les diagrammes de classe, parfois aussi machines tat). Lidal dans les phases de conception dtaille et dimplmentation est que loutil sintgre dans votre environnement de dveloppement de code (IDE) pour permettre de garder une bonne synchronisation entre le code et les modles. Il faut galement exiger de loutil quil soit capable de gnrer un document lisible et imprimable, contenant les diffrents diagrammes qui composent un modle. La majorit des outils sont disponibles en version dvaluation limite dans la dure, donc nhsitez pas en tlcharger deux ou trois avant de xer votre choix ; lchange de modles entre outils est quasiment impossible. La liste ci-aprs est trie par nom dditeur.

Comparatif des outils de modlisation 233

Compagnie : vendeur de loutil Produit : nom du produit dcrit Licence acadmique : existe-t-il une licence gratuite pour les enseignements ? Licence commerciale : prix de la licence commerciale, varie beaucoup selon le nombre de postes, dutilisateurs IDE : loutil sintgre-t-il dans un environnement de dveloppement intgr ? Langages : pour quels langages les traductions code <-> UML sont-elles possibles ? Description : une brve description de loutil. + Points forts de loutil Points faibles Compagnie : Borland Produit : Together Licence acadmique : essai 15 jours Licence commerciale : prix disponible en contactant leur service commercial (!) IDE : Eclipse Langages : Java, BPMN (Business Process Modeling Notation) Description : dune ergonomie sans faille, robuste et rapide, cet outil offre de nombreux services support (vrication de contraintes OCL, audit de projet, extraction de diagrammes de squence depuis le code, transformation de modles). Outil rellement de qualit industrielle, qui accompagne le dveloppement de lanalyse des besoins au dveloppement du code. + Ergonomie, prise en main. + Synchronisation code Java. Difcult dobtention de licence. Compagnie : Gentleware Produit : Poseidon Licence acadmique : Community Edition, svrement bride Licence commerciale : Professional Edition, 700 1 200 IDE : Professional Edition intgre dans Eclipse, Community Edition outil java standalone Langages : Java Description : bas sur loutil open-source gratuit ArgoUML, lergonomie de Poseidon reste revoir. Il est parfois choisi cependant pour sa facilit de dploiement (32 Mo, tlchargement sans questions). La politique commerciale de Gentleware a voulu pousser, depuis 2005, sa communaut dutilisateurs gratuits passer la version payante, avec pour rsultat un outil CE aux fonctions appauvries (pas dextraction de modle), ce qui est un peu dommage. + diteur graphique UML entre de gamme. Ergonomie et fonctionnalits limites.

234

UML 2

Compagnie : IBM/Rational Produit : Rational Rose Enterprise Licence acadmique : complte sous programme IBM Academic Initiative ngociable par les enseignants. Licence commerciale : 5 000 10 000 IDE : Standalone, intgration partielle dans Visual Studio 2005 Langages : Visual C ++, Visual Basic 6, Ansi C ++, SQL, Java (1.4) Description : Rose a t le premier outil de modlisation UML, au dbut des annes 2000. Il na pas t mis jour pour supporter UML 2, il reste cependant un outil trs agrable manipuler, et il supporte bien linteraction avec les technologies Microsoft, ainsi quavec les bases de donnes. noter quil existe galement un produit IBM offrant du support pour C#, mais qui nest pas inclus dans Rose. + Ergonomie bien travaille. + Importation de projets Visual. Ne supporte pas UML 2. Compagnie : IBM/Rational Produit : Rational Software Architect Licence acadmique : complte sous programme IBM Academic Initiative ngociable par les enseignants. Licence commerciale : 4 000 12 000 IDE : bas sur Eclipse Langages : Java, C ++, Corba Description : un outil norme, par sa taille (6 Go disque, 1 Go RAM), mais aussi par ses capacits plus avances que la concurrence. Construit sur Eclipse, supporte bien tout UML 2. Notons que loffre de IBM/Rational se dcline en plusieurs variantes, ce produit constitue leur haut de gamme. + Modlisation trs avance, bon support des diagrammes de squence, machines tat. + Services de gnration de code/extraction de modle. Lourdeur de loutil, ncessite une grosse conguration pour tourner correctement. Compagnie : Microsoft Produit : Visio Licence acadmique : inclus dans le lot Microsoft MSDN Academic Alliance Licence commerciale : 360 780 IDE : Visual Studio (menu Visio) Langages : (partiel) C#, VB. Net Description : Visio est dabord un outil de dessin puissant, permettant de produire assez facilement des diagrammes techniques de bonne qualit graphique. Une palette contenant les lments des diagrammes UML est incluse avec loutil. Visual Studio offre galement une option permettant de produire des diagrammes de classe sous Visio partir dun projet, mais cela reste relativement limit. Certaines des illustrations de ce livre sont ralises laide de Visio. + Logiciel de dessin au rendu graphique agrable. Pas rellement un outil UML.

Comparatif des outils de modlisation 235

Compagnie : No magic Produit : MagicDraw UML Licence acadmique : version bride ldition de diagrammes disponible par ngociation des enseignants Licence commerciale : 400 2 150 IDE : Eclipse, NetBeans, JBuilder Langages : Java, C ++, C# (partiel) Description : un outil assez plaisant visuellement, et dune ergonomie globalement bonne. MagicDraw offre un certain nombre de services de transformation de modles et de dnition de prols. Linteraction avec le Java est assez bonne (cration de diagrammes de squence depuis le code), les fonctionnalits pour le C ++ et C# sont beaucoup plus limites. + Un outil honnte, au rendu graphique et lergonomie au dessus de la moyenne. La version offerte aux enseignants ne permet que le dessin. Compagnie : Omondo Produit : EclipseUML Licence acadmique : version Free edition , quelques fonctionnalits brides Licence commerciale : version Studio 2 500 7 100 IDE : Intgration Eclipse Langages : Java, J2EE Description : un des premiers plugins UML pour Eclipse, bas sur les standards open-source. Spcialement ddi au Java, offre une bonne synchronisation code/diagrammes de classe. Les autres diagrammes sont cependant dans lensemble plutt dlaisss, mme si un diteur graphique sommaire est fourni pour chaque type de diagramme. Permet davoir une visualisation UML du code du projet dans les phases de conception dtaille et dimplmentation. + Synchronisation avec le code Java (jdk < = 1.6), intgration dans Eclipse. + Facile tlcharger et installer. Supporte surtout les diagrammes de classe. Compagnie : Visual-Paradigm Produit : Visual-Paradigm for UML Licence acadmique : Programme Academic Partners, version standard gratuite ngociable par les enseignants Licence commerciale : 400 1 200 IDE : intgration dans la majorit des IDE, effort particulier pour Eclipse Langages : Java, C ++, PHP, SQL-JDBC, Ada, Python Support partiel dautres langages Description : un outil assez agrable visuellement et ergonomique pour ldition de diagrammes. La version standard offerte aux enseignants inclut sufsamment de fonctionnalits pour tre vraiment utilisable, une version logiciel de dessin UML gratuite est disponible. Les diffrents diagrammes sont faciles construire. Beaucoup de fonctionnalits sont proposes pour interagir avec les bases de donnes. + Interface ergonomique. + Bon support pour une large palette de langages. Documentation proche de la publicit, difcile parfois de trouver linformation pertinente.

236

UML 2

Annexe B

Classeurs structurs
Les classes dcouvertes au moment de lanalyse (celles qui gurent dans le diagramme de classes) ne sont pas assez dtailles pour pouvoir tre implmentes par des dveloppeurs. Lanalyse montre ce que doit faire un systme mais pas comment il doit tre ralis. Cest le rle des concepteurs de faire des choix de ralisation. Une technique de conception consiste dcomposer un systme jusqu ce quapparaissent des niveaux de dtails sufsamment ns pour permettre limplmentation. UML propose de partir des classeurs dcouverts au moment de lanalyse tels que les classes, les sous-systmes, les cas dutilisation, , et de les dcomposer. Les classeurs ainsi dcomposs sappellent des classeurs structurs. Ils se prsentent comme des classes qui montrent leurs structures internes. Un classeur structur est constitu de plusieurs parties relies par des connecteurs. La gure B.1 illustre une commande de billets de spectacle par un client via un classeur structur.

Figure B.1
Une classe structure.

rle

type commandeBillet

client : Personne

1..*

billetCommand : Billet

partie

connecteur multiplicit

Chaque classeur est constitu de parties spciques : une partie ne peut pas gurer dans deux classeurs. Cette condition permet de dcomposer un classeur sur plusieurs niveaux.

Dnition
Une partie est un fragment dun classeur structur.

Notation
Comme un classeur, une partie est reprsente par un rectangle contenant une tiquette dont la syntaxe est :
<nomDuRle> [: <nomDuType> multiplicit ]

Tandis que les parties dun classeur structur reprsentent une structure de donnes, les rles correspondent ses diffrents comportements et permettent de dnir le contexte dans lequel il est utilis.

Classeurs structurs 237

Un classeur interagit avec son environnement via des ports (voir chapitre 2) par o passent des messages. La gure B.2 illustre lutilisation des ports dans une classe structure.

Figure B.2
Une classe structure avec des ports.

signal audio entre niveau ligne Carte son entre niveau micro niveau micro interface fournie ports interface requise sortie audio [2] niveau sonore

Annexe C

Composants
Un composant est une unit autonome au sein dun systme ou sous-systme. Cest un classeur structur particulier, muni dune ou plusieurs interfaces requises ou offertes, possiblement travers des ports explicitement reprsents. Son comportement interne est totalement masqu de lextrieur, seule ses interfaces mergent du composant. Le modle de composants favorise la rutilisation en fournissant un grain plus grossier que celui des classes, qui permet davoir des entits rellement autonomes. Le programmation par composants constitue une volution technologiques en matire de programmation, soutenue par de nombreuses plateformes (composants EJB, CORBA, COM+ ou .Net, WSDL). Laccent est sur la rutilisation du composant, et son volution de faon indpendante des applications qui lutilisent. Un composant peut tre dploy dans diverses congurations, selon ses connexions avec les autres lments du systme. Au contraire, une classe est lie de faon ge au systme dont elle fait partie, les associations avec les autres classes reprsentant des liens structurels. En ce sens, sans perdre la gnralit dun classeur, un composant est plus proche dune instance de classe que dune classe, et les diagrammes de composants sapparentent plus des diagrammes des objets qu des diagrammes de classe. Un composant est reprsent laide dun rectangle comme un classeur ordinaire, muni du mot-cl component , et optionnellement dun graphisme particulier (gure C.1) plac dans un angle.

238

UML 2

Figure C.1
Un composant avec une interface requise et une interface offerte.
Persistance component Persistance BaseDeDonnes

component Persistence provided interface Persistance crer stocker charger required inteface BasesDeDonnes JDBC

Les composants sont raliss par des ensembles de classeurs, qui implmentent le comportement dclar par les interfaces du composant. Un composant peut tre ralis de diffrentes manires, sans affecter ses interfaces. La seule contrainte pour pouvoir substituer un composant un autre est de prserver les interfaces requises et offertes. La faon dont un composant est ralis peut tre dnie plusieurs niveau de dtail. Un composant peut tre vu comme une bote noire. On ne fait alors merger que ses interfaces et lon utilise une des prsentations de la gure C.1. On peut galement dcrire la structure interne du composant en bote blanche. On expose ainsi la faon dont le composant est ralis, avec une reprsentation proche de celle dun claseur structur. On connecte alors les ports externes du composant aux ports des classeurs constituant ses parties, par un arc qui reprsente une relation de dlgation (gure C.2) : les messages qui arrivent sur ce port sont directement transmis au composant interne. Cette vision hirarchique permet de dcomposer un systme en sous systmes relativement indpendants, et donc plus rutilisables. Les interfaces requises et offertes sont connectes entre elles pour exprimer lassemblage des parties ralisant le composant.

Figure C.2
La ralisation dun composant expose en bote blanche.
component Persistance Persistance delegate CollectionPersistante delegate delegate BaseDeDonnes

AnalyseurDeClasse

PersistanceTypeDeBase

Composants 239

Annexe D

Diagramme de dploiement
UML nest pas limit la production de modles utiles aux phases danalyse et de conception. Le dploiement qui prcde la mise en production constitue une tape importante du dveloppement dun systme. Au nal, ce dernier va sexcuter sur des ressources matrielles (processeurs, mmoire, etc.) dans un environnement particulier. UML permet de reprsenter un environnement dexcution ainsi que des ressources physiques (avec les parties du systme qui sy excutent) grce aux diagrammes de dploiement. Lenvironnement dexcution ou les ressources matrielles sont appels nuds . Les parties dun systme qui sexcutent sur un nud sont appeles artefacts . Un artefact peut prendre la forme dun chier binaire excutable, dun chier source, dune table dune base de donnes, dun document, dun courrier lectronique, etc. La gure D.1 reprsente le dploiement dun serveur Web avec lequel une machine cliente, dote dun navigateur Web, communique. Le serveur, qui est connect une base de donnes installe sur une machine tierce, excute lartefact siteWEB.

Figure D.1
Diagramme de dploiement pour un serveur Web qui prsente des instances de nuds et une instance dartefact dploye.
client : PC serveurWEB : Serveur serveurBaseDeDonnes : ServeurSGBD

dploy

artfact siteWEB

Le diagramme de la gure D.1 contient des instances de nuds. un niveau dabstraction plus lev (au niveau des nuds), ce diagramme peut se reprsenter de la faon suivante.

Figure D.2
Diagramme de dploiement pour un serveur Web qui prsente des nuds.
PC 1..* Serveur ServeurSGBD

240

UML 2

Les associations entre les nuds sont des chemins de communication tels que des cbles rseaux, des bus, etc., qui peuvent porter une multiplicit : la gure D2 prsente plusieurs PC qui sont connects au site Web du serveur.

Dnition
Un nud est une ressource sur laquelle des artefacts peuvent tre dploys pour tre excuts. Un artefact est la spcication dune entit physique du monde rel.

Notation
Un nud se reprsente par un cube dont le nom respecte la syntaxe des noms de classes (voir chapitre 2). Le nom dun nud instanci doit tre soulign (gure D.1). Un artefact se reprsente comme une classe par un rectangle contenant le mot-cl artefact suivi du nom de lartefact. Celui-ci est soulign quand il sagit dune instance. Un artefact dploy sur un nud est symbolis par une che en trait pointill qui porte le strotype dploy et qui pointe vers le nud (gure D.1). Lartefact peut aussi tre inclus directement dans le cube reprsentant le nud. Plusieurs strotypes standard existent pour les artefacts : document, excutable, chier, librairie, source.

Annexe E

Implmentation dun modle objet en Java


Dans le cycle de dveloppement dun systme, limplmentation correspond la phase de ralisation. Quand il sagit dun logiciel, cela consiste traduire les modles danalyse et de conception dans un langage de programmation. Cette phase peut tre automatise en partie avec des outils informatiques de modlisation. Ces outils sont nombreux (GDPro, ObjectTeam, Objecteering, OpenTool, Rhapsody, STP, Visio, Visual Modeler, WithClass, ). Certains supportent UML depuis ses dbuts (Rose de Rational Software), dautres viennent du monde du logiciel libre (ArgoUML). Nombreux sont les outils qui permettent la gnration automatique de code partir dun diagramme de classes vers des langages de programmation varis (Java, C++, C#, etc.). Dans la suite de ce paragraphe, nous montrons comment implmenter les lments essentiels dun diagramme de classes, et comment traduire les messages des diagrammes dinteraction (de squence ou de communication) en Java.

Implmentation dun modle objet en Java 241

Notation
Les implmentations vers diffrents langages sont assez proches les unes des autres. par tir dune implmentation en Java, il est donc facile de passer dautres langages. Une implmentation dans un langage donn peut tre ralise de diffrentes manires.

IMPLMENTATION
Figure E.1

DE LHRITAGE

Voiture seDeplacer

VoitureAEssence

Implmentation dun hritage


public class Voiture{ public void seDeplacer(){ // } } public class VoitureAEssence extends Voiture{ }

Figure E.2
interface Vehicule

Voiture

Implmentation dune interface


public interface Vehicule{ public void seDeplacer(); } public class Voiture implements Vehicule{ public void seDeplacer(){ // } }

242

UML 2

IMPLMENTATION

DES RELATIONS ENTRE CLASSES

Les langages de programmation comme Java noffrent pas de technique particulire pour implmenter des associations, des agrgations ou des compositions. Ce type de relation simplmente en ajoutant des attributs dans des classes.

Figure E.3
Exemplaire 0..1

range

Emplacement

Association unidirectionnelle de 1 vers 1


public class Emplacement{ } public class Exemplaire{ private Emplacement range; public void setEmplacement( Emplacement emplacement ){ this.range = emplacement; } public Emplacement getEmplacement(){ return range; } public static void main( String [] args ){ Emplacement emplacement = new Emplacement(); Exemplaire exemplaire = new Exemplaire(); exemplaire.setEmplacement( emplacement ); Emplacement place = exemplaire.getEmplacement(); } }

Remarque
Pour accder lassociation plus facilement (sans passer par les mthodes setEmplacement et getEmplacement), il est possible de supprimer le mot-cl private (ce nest possible que si les classes font partie dun mme paquetage).

Figure E.4
Voiture 0..1

0..1 Conducteur

Implmentation dun modle objet en Java 243

Association bidirectionnelle de 1 vers 1


package bagnole; public class Conducteur{ Voiture voiture; public void setVoiture( Voiture voiture ){ if( voiture!= null ){ this.voiture = voiture; voiture.conducteur = this; } } public static void main( String [] argv ){ Voiture voiture = new Voiture(); Conducteur conducteur = new Conducteur(); conducteur. addVoiture ( voiture ); } } package bagnole; public class Voiture{ Conducteur conducteur; public void setConducteur( Conducteur conducteur ){ this.conducteur = conducteur; conducteur.voiture = this; } }

Figure E.5
Entreprise 1 + clients

Client

Association unidirectionnelle de 1 vers plusieurs


public class Client{ } import java.util.Vector; public class Entreprise{ private Vector clients = new Vector(); public void addClient( Client client ){ clients.addElement( client ); } public void removeClient( Client client ){ clients.removeElement( client ); } public static void main( String [] argv ){ Entreprise monEntreprise = new Entreprise(); Client client = new Client(); monEntreprise.addClient( client ); monEntreprise.removeClient( client ); } }

244

UML 2

Figure E.6

uvre uvre 1..n exemplaires Exemplaire

Association bidirectionnelle de 1 vers plusieurs


import java.util.Vector; class Oeuvre{ Vector exemplaires = new Vector(); public void addExemplaire( Exemplaire exemplaire ){ if( exemplaires.contains( exemplaire ) == false ){ exemplaires.addElement( exemplaire ); } } public void removeExemplaire( Exemplaire exemplaire ){ if( exemplaires.removeElement( exemplaire ) == true ) exemplaire.oeuvre = null; } public static void main( String [] argv ){ Oeuvre donGiovani = new Oeuvre(); Exemplaire exemplaire = new Exemplaire( 1 ); donGiovani.addExemplaire( exemplaire ); } } class Exemplaire{ int numro; Oeuvre uvre; public Exemplaire( int numro ){ this.numro = numro; } public void setOeuvre( Oeuvre oeuvre ){ if( oeuvre!= null ){ oeuvre.exemplaires.addElement( this ); this.oeuvre = oeuvre; } } public void removeOeuvre( Oeuvre oeuvre ){ if( oeuvre.exemplaires.removeElement( this ) == true ) this.oeuvre = null; } public boolean equals( Object obj ){ if( (obj!=null) && (obj instanceof Exemplaire) ) return numero == ((Exemplaire)obj).numero; else return false; } }

Figure E.7

Voiture

Moteur

Implmentation dun modle objet en Java 245

Composition
public class Voiture{ private class Moteur{ } private Moteur moteur; }

Agrgation : une agrgation simplmente comme une association

IMPLMENTATION
Figure E.8

DE LENVOI DE MESSAGES

com Piloter

conduire

conducteur : Conducteur dmarrer voiture : Voiture

Implmenter les messages des diagrammes de communication


public class Conducteur{ private Voiture voiture; public void setVoiture( Voiture voiture ){ if( voiture!= null ){ this.voiture = voiture; } } public void conduire(){ voiture.demarrer(); } public static void main( String [] argv ){ Voiture voiture = new Voiture(); Conducteur conducteur = new Conducteur(); conducteur.setVoiture( voiture ); conducteur.conduire(); } } public class Voiture{ public void demarrer(){ // } }

Implmenter les messages des diagrammes de squence


Ce diagramme est quivalent au prcdent au niveau interprtation et donne donc lieu au mme code (voir gure E.9).

246

UML 2

Figure E.9

sd Piloter

conducteur : Conducteur conduire demarrer

voiture : Voiture

Annexe F

Organisation dUML 2
DIFFRENTES
VUES DUML

Le langage UML sintgre dans toutes les phases du cycle de vie du dveloppement, allant de la collecte des besoins au dploiement. UML ne dnit pas de processus de dveloppement. Il est utilisable avec la plupart des processus existants. UML donne la possibilit dutiliser les mmes concepts et notations, sans ncessiter de conversion, dans les diffrentes phases de dveloppement. Il est, de ce fait, bien adapt au cycle de dveloppement itratif et incrmental.

ORGANISATION

EN PAQUETAGES

Un paquetage dnit des regroupements qui rpondent aux contraintes applicatives et aux besoins du dveloppement. Dans la version 2 dUML, un modle est dni par un paquetage qui comprend une description complte dun systme partir dun point de vue spcique. Le mtamodle UML, qui est aussi compos dun ensemble de modles, est modlis par des paquetages. Les principales caractristiques des normes OMG sont regroupes dans le paquetage dit Core. UML, CWM, MOF, les prols et les autres mtamodles utilisent les standards spcis dans le modle Core, comme le montre la gure F.1.

Organisation dUML 2 247

Figure F.1
Structure du mtamodle en paquetages.

Chaque modle (paquetage) est, son tour, compos de plusieurs sous-paquetages, ce qui confre UML une organisation arborescente. Plus on remonte vers la racine, plus on slve dans le niveau dabstraction. Par exemple, le modle Core contient les sous-paquetages PrimitivesTypes, Abstractions, Basic et Prols, comme le montre la gure F.2.

Figure F.2
Structure hirarchique du modle (paquetage) Core.

Selon le mme principe, chaque paquetage est, lui-mme, compos de plusieurs sousmodles. Par exemple, le modle de la superstructure dUML 2, qui permet de spcier la syntaxe des modles utilisateurs, est compos, entre autres, dun modle de classes, dun modle dinteractions, dun modle de prols et dun modle de cas dutilisation, comme le montre la gure F.3.

248

UML 2

Figure F.3
Paquetages composant la superstructure du langage UML 2.

COUCHES

DU MTAMODLE
Les paquetages dnissent la hirarchie dabstraction entre les diffrents modles, mais ne mettent pas en vidence les diffrentes couches de modlisation, en particulier les diffrences entre les mtamodles et le modle de donnes. LOMG propose une organisation en couches de ses langages parmi lesquels gure UML 2. Les caractristiques quils partagent sont regroupes dans le mtamodle MOF. Linstanciation de ce mtamodle donne naissance des langages comme UML et CWM. Lutilisateur dUML dnit des classeurs (classes, associations) dcrivant son application en respectant les spcications du mtamodle UML. Un modle utilisateur bien employ garantit un modle dobjets physiques actifs, avec des proprits bien dnies. Une architecture de modlisation se compose de quatre couches : les couches M0, M1, M2 dnissent respectivement les instances actives du modle utilisateur, le modle de donnes utilisateur, et le mtamodle UML, la faon dont est construit ce dernier tant spcie par la couche M3. Lexemple prsent la gure F.4, extrait de la spcication de la superstructure du langage UML, illustre les quatre couches. La vido (aVido) qui est en train dtre visionne est une instance active : elle se situe au niveau M0. Cette vido est une instance de la classe Vido (diagramme de classes), en loccurrence linstance 2001 : A spaceOdyssey (diagramme dobjets). Les diagrammes de classes et dobjets correspondent au modle utilisateur : ils sont donc au niveau M1. La classe Vido et les attributs quelle contient sont modliss dans le respect du mtamodle UML, qui spcie comment dnir une classe et un attribut : ils font donc partie de la couche M2. Un attribut, une classe et une instance respectent les spcications MOF. Au niveau de la couche MOF, ils sont spcis par une classe (cela correspond la couche M3).

Organisation dUML 2 249

Figure F.4
Exemple mettant en vidence lorganisation en quatre couches du langage UML.

MODLES

CONCEPTUELS DUML

Les paquetages et les couches donnent une organisation architecturale du langage UML. Un utilisateur na pas besoin de connatre cette organisation pour bien utiliser ce langage. Il doit se contenter de respecter la syntaxe et la smantique dUML. 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 dUML proposent un dcoupage conceptuel en quatre domaines : structurel, dynamique, physique et gestion de modles. Chaque domaine est compos de plusieurs vues et chaque vue est ralise par un ensemble de diagrammes UML.

Domaine structurel
Le domaine structurel est compos des trois vues suivantes : La vue fonctionnelle. Elle conceptualise et structure les besoins de lutilisateur (diagramme de cas dutilisation). Elle dnit le contour du systme modliser en dnissant les fonctionnalits principales sans pour autant chercher lexhaustivit. Elle sert dinterface entre les diffrents intervenants dans le projet. La vue statique. Elle dnit les principaux classeurs de lapplication. Elle est modlise par un ensemble de classes dotes dattributs et doprations. Celles-ci sont organises via des relations de composition, de gnralisation, etc. Des objets en excution peuvent tre modliss pour illustrer leur comportement et leurs relations. La vue statique se prsente essentiellement sous forme de diagrammes de classes et dobjets. La vue conceptuelle. Elle met en vidence les collaborations entre classeurs et dcrit larchitecture physique du systme. Elle est ralise par le diagramme de collaborations et le diagramme de composants.

250

UML 2

Domaine dynamique
Le domaine dynamique regroupe lensemble des vues montrant le comportement du systme lexcution : la vue des interactions (diagramme dactivits), des machines tats (diagramme dtats-transitions), des interactions (diagramme de squences et diagramme de communication)

Domaine physique
Le domaine physique est compos de la seule vue de dploiement. Elle dcrit lemplacement physique du matriel utilis et la rpartition des composants sur ce matriel. Ces ressources sont modlises par des nuds interconnects. Cette vue est particulirement importante dans le cas de la modlisation des environnements distribus o une place importante est donne lexpression des exigences en termes de performances.

Domaine gestion de modles


Le domaine gestion de modles montre une organisation en paquetages du modle luimme. Il est ralis via le diagramme de paquetages et est compos de deux vues : La vue des prols. Les prols permettent dapporter des changements restreints aux modles UML pour les adapter des outils ou plates-formes tout en conservant linteroprabilit. Ces changements sont assurs par des mcanismes dextension du langage. Les deux principaux lments dextension en UML sont les contraintes et les strotypes. On appelle prol un ensemble cohrent de strotypes avec les contraintes associes. La vue de gestion de modles. Elle modlise lorganisation du modle par un ensemble de paquetages et leurs relations. Un modle est dni par un point de vue et un niveau de prcision. Le choix de la granularit des paquetages et de la manire de les organiser dnissent la vue de gestion du modle.

Organisation dUML 2 251

Annexe G

Bibliographie
[Blaha 2005] Michael Blaha, James Rumbaugh. Modlisation et conception orientes objet avec UML 2, Pearson Education, 2005 [Gamma 95] rich Gamma, Richard Helm, Ralph Johnson et John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995 [Jacobson 1999] Ivan Jacobson, Grady Booch et James Rumbaugh. Le processus uni de dveloppement logiciel, Eyrolles, 1999 [Kernighan, Ritchie 1990] Brian W. Kernighan, Dennis M. Ritchie, The C Programming Language, Prentice Hall, Inc. 1988. En franais : Le Langage C : norme ANSI, taduit par Jean-Franois Groff et ric Mottier, Dunod, coll. Sciences sup , 2e dition, 2004 [Larman] Craig Larman. UML et les design patterns, deuxime dition, CampusPress, 2005 [Norme UML 2.0] OMG (Object Management Group). UML 2.0 Superstructure (rfrence ptc/04-10-02), UML 2.0 Infrastructure (rfrence ptc/03-09-15), http://www.uml.org, 2004 [Penders 2002] Tom Penders. Introduction UML, EOM, 2002 [Rumbaugh 2004] James Rumbaugh, Ivar Jacobson et Grady Booch. UML 2.0 - Guide de rfrence, CampusPress, 2004

252

UML 2

Index
A Abstraite classe 38 mthode 38 Acteur 3, 9, 16, 27, 29 Action call 131, 156 manipulations de variables 158 opaque 160 raise exception 157 send 157 sur un link 159 time event 131 Activit argument d'une 168 concurrence 171, 181 description 161 et cas d'utilisation 178, 182 exception 172 interne 133 interruptible 174 ligne d'eau 166 partition 166 pin 168 programmation 166, 177, 179, 183 structure 166 structures de contrle 164 zone d'expansion 175 Agrgation 50 Alt, oprateur dinteraction 96 Alternative 96 Analyse du systme 1 phase d 190 Argument 94 Artefact 241 Assert 95 Assert, oprateur 98 Assertion 95 Association 46 avec contraintes 47 classe 48 drive 48 n-aire 49 qualie 49 Asynchrone, message 91, 111 Attribut driv 61 B Boucle oprateur 104 reprsentation 97 Break 97 C Cas d'utilisation 2, 9 acteur 3 dnition 3 diagramme 1, 2, 15 extension 5, 25, 27 gnralisation 5, 29 inclusion 5, 29 relations 5, 18

Index 253

Classe 37 active 64 attribut de la 40, 41 contrainte sur 65 exceptions 43 mthode de la 42 nom de la 38, 63 opration de la 42, 43 paramtrable 65 responsabilits d'une 43 strotype 63 Classeur 36 dnition 4 rle 237 structur 88, 125, 226, 237 utilisation 88 Collaboration dnition 89 rle 89 utilisation 122 Com, mot-cl 87 Composition 50 Conception 89, 194 Concurrence activits 171 barre de synchronisation 135 tats-transitions 139 zone d'expansion 175 Connecteurs 54 Consider, oprateur 98 Construction du diagramme de classes 57 Contraintes 56 de dure 114 sur les lignes de vie 95 Critical 117

Dure, contrainte de 114 E Else 96 Encapsulation 39 private 40 protected 40 public 40 tats-transitions activit interne 133 concurrence 135, 139 tat composite 134 simple 128, 133 historique 136 interface 137 point de choix 132 de connexion 137 de jonction 131 protocol 138, 143 transition automatique 135 vnement 134 dclencheur 129 dnition 129 signal 130 time event 129, 157 Exception 12, 23 gestionnaire d 172 pin d 169 raise 157 Extension entre les cas dutilisation 5, 6, 25, 27 F Flot d'objet 169 contraintes 169 de contrle 161, 164 ow nal 171 Fragment combin 96, 115, 120 d'interaction 96, 116 G Garde dans un diagramme d'activits 164 tats-transitions 131 Gnralisation de cas dutilisation 29, 31

D Dpendance, relation de 51 Dploiement, diagramme 197, 240 Diagramme d'interactions 87, 106 d'objets 74, 217 dtats-transitions 128 de cas d'utilisation 1, 2, 15 de classes 35 de communication 87, 106 de dploiement 197, 240 de squence 87, 106 objets 54

254

UML 2

Index
H Hritage 71, 72 exceptions 174 multiple 53, 72 relation 52 signal 130 Historique, pseudo-tat 136 I Ignore, oprateur 98 Implmentation en langage Java 241 Inclut 5 Inout, paramtre 94, 105 Instance 37 de relation 56 Interaction dnition 86 diagramme 87 fragment 96 message 87, 91, 92, 103 oprande 96 utilisation 106 Interface 44 ralisation d'une 68 utilisation d'une 68 Interne, structure 237 L Ligne de vie 86 M Message asynchrone 64, 91 dans un diagramme de communication 104, 108 de squence 94, 107 dnition 91 dlai de transmission 91 signal 130 synchrone 91, 156 Modle des cas dutilisation 1, 15 Modlisation d'une classe 61 Multiplicit 45 N Neg 120 Nud dans un diagramme de dploiement 240 Numro de squence 103 O Objet 37 actif 113 ligne de vie 86 passif 113 reprsentation 55 Occurrence d'vnement 92 Oprande d'interaction 96 Opt 120 P Paquetage 25 dnition 8 dpendance 25 Par, oprateur 97, 117 Parallle, envoi de messages 97 Paramtre de retour 94 inout 94, 105 Partie structure 237 Patron de conception adapteur 81 Bridge 80 objets composites 74 Phase d'implmentation 188 de dploiement 188 de maintenance 188 de tests 188 Pin d'exception 169 dnition 168 stream 170 Point d'extension 6, 28, 33 de choix 132 de jonction 131, 164 Port 54 proprits 54 protocole 54 Postcondition 12, 23 Prcondition 12, 22 protocol 138 R Rgion interruptible 174 Relation 45, 69 agrgation 50 composition 50

Index 255

d'extension 5 d'inclusion 5 dpendance 51 d'instanciation 56 gnralisation 5, 7, 28 hritage 52 n-aire 70 simple 66 S Scnario 14 Sd, mot-cl 87 Signal 54 vnement 130 Strotype, dnition 4 Strict sequencing, oprateur 99 Structure interne 237 Synchrone, message 91 Synchronisation des activits 171

T Thread 91 U Utilisation d'une collaboration 89 d'une interaction 88 V Variables, manipulation 158 Visibilit de paquetages 8 Z Zone d'expansion 175

256

UML 2

Informatique

Synthse de cours exercices corrigs


Les auteurs :
Benot Charroux dirige le dpartement informatique de lEFREI (Villejuif), o il enseigne la modlisation et la programmation objet. Il est galement formateur en entreprise.

&

UML 2
Pratique de la modlisation

2e dition

Aomar Osmani est matre de confrences luniversit Paris XIII. Il assure des enseignements sur UML, les bases de donnes, lalgorithmique, la programmation objet, le gnie logiciel et les rseaux. Il y est aussi responsable de la Licence en formation continue. Yann Thierry-Mieg est matre de confrences luniversit Paris VI. Il effectue des recherches sur UML 2 dans le cadre de mthodologies de dveloppement adaptes au domaine des logiciels critiques. Dans la mme collection :
Algorithmique, Applications en C, J.-M. Lry Algorithmique en C++, J.-M. Lry Algorithmique en Java 5, J.-M. Lry Architecture de lordinateur, E. Lazard Architecture des rseaux, D. Seret, D. Dromard Cration de bases de donnes, N. Larrousse Excel 2007 et VBA, B. Minot Java 5 et 6, R. Chevallier LaTeX, J.-C. Charpentier, D. Bitouz Le langage C, J.-M. Lry Le langage C++, M. Vasiliu Linux, J.-M. Lry Mathmatiques discrtes appliques linformatique, R. Haggarty SQL, F. Brouard, C. Soutou Systmes dexploitation, B. Lamiroy et al XML, G. Chagnon, F. Nolot

UML est le langage de modlisation le plus utilis dans lindustrie, principalement pour le dveloppement logiciel. Synthex UML 2 prsente tous les concepts fondamentaux de ce langage et les met en perspective au moyen de nombreux exemples comments. Il explique galement comment les diffrents modles ncessaires la conception dun logiciel se compltent pour en donner une vision exhaustive et cohrente. Les exercices corrigs, qui reprsentent la moiti de chaque chapitre, permettent dappliquer les notions prsentes. Une tude de cas finale rassemble les lments essentiels du langage et montre comment mettre en uvre les volutions dUML 2. Cette nouvelle dition propose notamment un comparatif des principaux outils de modlisation, avec les avantages et les inconvnients de chaque logiciel, afin que le lecteur puisse choisir le produit le plus adapt ses besoins. Louvrage sadresse aux tudiants de premier et de second cycles (IUT, BTS, universits et coles dingnieurs) ainsi quaux professionnels. Il constitue la fois une mthode pratique dapprentissage du langage UML, un support concis de rvision et dauto-valuation, et un outil de travail prcieux pour les professionnels en formation continue.

La collection Synthex informatique propose de dcouvrir les fondements thoriques et les applications pratiques des principales disciplines de science informatique. partir dune synthse de cours rigoureuse et dexercices aux corrigs dtaills, le lecteur, tudiant ou professionnel, acquiert une comprhension rapide et un raisonnement solide.

ISBN : 978-2-7440-4050-4

Pearson Education France 47 bis, rue des Vinaigriers 75010 Paris Tl. : 01 72 74 90 00 Fax : 01 42 05 22 17 www.pearson.fr