CNAM - CRA Nancy 2003

Jacques Lonchamp

SIXIEME PARTIE La modlisation objet. UML

1. Les mthodes danalyse et de conception

Une mthode : propose une dmarche, distinguant les tapes du dveloppement dans le cycle de vue du logiciel et exploitant au mieux les principes fondamentaux : modularit, rduction de la complexit, rutilisation, abstraction, etc., propose des formalismes (langages) et des types de documents (modles), qui facilitent la communication, lorganisation et la vrification, Il existe de nombreuses mthodes : mthodes fonctionnelles de dcomposition hirarchique (dites de premire gnration) comme SADT, SA-SD, ... : application du principe diviser pour rgner (problme sous problmes) ; mthodes systmiques (dites de deuxime gnration) comme MERISE, SSADM, ... : sparation donnes/traitements, niveaux conceptuels, organisationnels, physiques. mthodes objets (dites de troisime gnration) comme OMT, OOA, OOD, Hood, OOSE, OOM, Fusion, ... Parmi les principaux objectifs des mthodes objets, on peut noter la volont de : regrouper lanalyse des donnes et des traitements, tablir un couplage explicite entre les concepts du monde rel et les composants excutables ( rduire la distance smantique entre le langage des concepteurs et celui des utilisateurs ), faciliter la rutilisation, simplifier les transformations entre le niveau conceptuel et limplantation. Au dbut des annes 90, il existait une cinquantaine de mthodes objet, lies par un certain consensus autour dides communes : objets, classes, sous-systmes, etc. Mais chacune possdait sa propre notation, ses points forts et ses manques, et son orientation privilgie vers un domaine dapplication. Lide dune certaine unification des mthodes objet est ne de ce constat. La communaut informatique, autour de lOMG (Object Management Group) qui standardise les technologies de lobjet, sest attache la dfinition dun langage commun unique, utilisable par toutes les mthodes objets, dans toutes les phases du cycle de vie et compatible avec les techniques de ralisation du moment.

2. UML
Ce langage commun sappelle UML (Unified Modeling Language). UML est une notation base principalement sur les mthodes OOD (de Booch), OMT (de Rumbaugh) et OOSE (de Jacobson). UML a t propos afin de standardiser les produits du dveloppement (modles, notations, diagrammes) sans standardiser le processus de dveloppement. Il est en effet trs difficile de standardiser le processus de dveloppement qui dpend des personnes, des applications, des cultures, etc. UML se propose de crer un langage de modlisation utilisable la fois par les humains (forme graphique) et les machines (syntaxe prcise). La Figure 1 rsume UML avec ses 5 vues et ses 9 diagrammes.

conceptuel

physique Vue implantation

Diagrammes : composants

la structuration des objets

Vue logique statique

Diagrammes : classe, objet, collaboration, squence

les composants logiciels

Vue externe
Diagrammes : cas dutilisation Diagrammes : dploiement

les fonctions du systme

Diagrammes : tats, activit

Vue logique dynamique

Vue dploiement

la dynamique des objets

analyse conception implantation

larchitecture physique

Figure 1 : les vues et les diagrammes de Merise

En rsum : UML est une notation, pas une mthode. UML est un langage de modlisation objet. UML convient pour toutes les mthodes objet. UML est dans le domaine public. UML a pour but de documenter les modles objets.

3. Les cas dutilisation

Formaliss par Ivar Jacobson dans Object-Oriented Software Engineering (AddisonWesley, 1992), les cas dutilisation (use cases) servent exprimer le comportement du systme en termes dactions et de ractions, selon le point de vue de chaque utilisateur ( approche centre utilisateur ). Les cas dutilisation dlimitent le systme, ses fonctions (ses cas), et ses relations avec son environnement. Ils constituent un moyen de dterminer les besoins du systme. Ils permettent dimpliquer les utilisateurs ds les premiers stades du dveloppement pour exprimer leurs attentes et leurs besoins (analyse des besoins). Ils constituent un fil conducteur pour le projet et la base pour les tests fonctionnels (cf. Figure 2). Un acteur est une personne ou un systme qui interagit avec le systme tudi, en changeant de linformation (en entre et en sortie). On trouve les acteurs en observant les utilisateurs directs du systme, les responsables de sa maintenance, ainsi que les autres systmes qui interagissent avec lui. Un acteur reprsente un rle jou par un utilisateur qui interagit avec le systme. La mme personne physique peut jouer le rle de plusieurs acteurs. Dautre part, plusieurs personnes peuvent jouer le mme rle, et donc agir comme un mme acteur.

Exprime Utilisateur

Comprend Analyste

Cas d'utilisation

Ralise

Vrifie

Programmeur

Testeur

Figure 2 : les cas dutilisation, fil conducteur du projet

Notations :

SYSTEME

communication Cas d'utilisation X Acteur

acteur humain
<<acteur>>

Cas d'utilisation Y Lacteur est source ou destination dune communication.

Acteur

acteur systme

Figure 3 : notations des cas dutilisation

Les cas dutilisations reprsentent le dialogue entre lacteur et le systme de manire abstraite. Les communications sont orientes (avec une flche) ou non. Les cas dutilisations peuvent aussi tre vus comme des classes de scnarios. Enfin, les cas peuvent tre structurs par les relations <<Inclut>> (un cas inclut obligatoirement un autre cas) et <<Etend>> (un cas est une variante dun autre) (cf. Figure 4). On peut aussi avoir de la gnralisation/spcialisation entre acteurs et entre cas (cf. paragraphe 6).

Client local Client distant Virement par Internet <<tend>>

<<Inclut>> Virement Identification

Figure 4 : structuration des cas dutilisation

Dmarche dutilisation des cas dutilisation : (1) Identifier les acteurs et les cas. (2) Dcrire les cas en crivant des scnarios sous forme textuelle. (3) Dessiner les diagrammes de cas. (4) Rcapituler les cas, les structurer et sassurer de la cohrence densemble.

4. Les objets
Les objets informatiques dfinissent une reprsentation simplifie des entits du monde rel, quil sagisse dentits concrtes (avec une ralit physique) ou conceptuelles. Les objets sont des abstractions qui mettent en avant les caractristiques essentielles et dissimulent les dtails. Une abstraction se dfinit par rapport un point de vue (tout dpend de lintrt que lon porte lobjet). Exemples dobjets : une transaction bancaire, un client, un pop-up menu. Les trois caractristiques fondamentales des objets sont ltat, le comportement, lidentit. Ltat correspond aux valeurs instantanes de tous les attributs (ou donnes membres) de lobjet. Ltat volue au cours du temps. Ltat dun objet un instant donn est la consquence de ses comportements passs. Exemples : pour un signal lectrique : valeurs de lamplitude, de la pulsation, de la phase, ... ; pour une voiture : valeurs de la marque, de la puissance, de la couleur, du nombre de places assises, de la quantit dessence, ... Son tat
Une voiture Essence = 30 litres

Une voiture Couleur = Rouge

Aprs un parcours de 100 Km

Poids = 979 kg Puissance = 16 CV

Essence = 25 litres

Une voiture Essence = 20 litres

Figure 5 : objet et tat

Le comportement dcrit les actions et les ractions dun objet (ou comptences dun objet). Le comportement se matrialise sous la forme dun ensemble doprations (ou mthodes ou fonctions membres). On distingue souvent les oprations selon leur finalit de constructeur, accesseur, modificateur, destructeur et itrateur.
Un autre objet Un message Opration 1{...} Opration 2{...}

tat comportement

Un objet

Figure 6 : comportement dun objet

Un objet peut faire appel aux comptences dun autre objet par linvocation dune opration (ou envoi de message). Les messages servent implanter les flots de donnes, les flots de contrle, les vnements , etc. Ltat et le comportement sont lis : le comportement dpend de ltat (cf. la pr condition de lopration); le message peut tre accept ou refus; ltat est modifi par le comportement (cf. la post condition de lopration). Tout objet possde une identit interne (non modifiable) qui lui est propre et qui le caractrise. Lidentit permet de distinguer tout objet de faon non ambigu, indpendamment de son tat (de ses attributs). Les langages objets utilisent des identifiants internes. Les identifiants et cls primaires des bases de donnes sont inutiles en objet. Intrt des objets : Concurrence : les objets sont autonomes et voluent indpendamment les uns des autres. Matrise de la complexit : o l'encapsulation permet de se concentrer sur un objet et un seul, o il est possible de tester de faon quasi exhaustive un objet. Evolution facilite : rajouter de nouveaux objets est simple. Rutilisation possible. Difficult des objets : Tout n'est pas naturellement objet. Tester un systme OO est difficile. Penser objet oblige changer de mentalit !

5. Les collaborations
Une application est une socit d'objets qui collaborent afin de raliser les fonctions de lapplication. Le comportement global dune application repose donc sur la communication entre les objets qui la composent (changes de messages). 5.1. Les diagrammes de collaboration Les diagrammes de collaboration mettent laccent sur les relations spatiales entre objets. Les messages peuvent tre numrots pour introduire une dimension temporelle. De nombreuses notations annexes permettent de caractriser les messages. Ils sont souvent utiliss pour dcrire grossirement la ralisation des cas dutilisation. Exemple : Un objet A envoie un message X un objet B, puis lobjet B envoie un message Y un objet C, et enfin C senvoie lui mme un message Z.
A 1: X 3: Z 2: Y C

Figure 7 : un diagramme de collaboration

5.2. Les diagrammes de squence Ils mettent laccent sur les relations temporelles. De nombreuses notations annexes permettent de prciser la nature des messages (appel de procdure, simple signal, message rptitif, conditionnel, rflexif, rcursif, etc.) et les donnes vhicules. Ils peuvent tre utiliss aussi bien pour prciser la ralisation des cas dutilisation que pour spcifier de manire trs dtaille la dynamique dun ensemble dobjets (appels de mthodes).

A
M1 M3 M4

B
M2

M5 M6 M7 M9
temps (ligne de vie)

M8 M10

Figure 8 : un diagramme de squence

6. Les classes
Le monde qui nous entoure est constitu de trs nombreux objets. Pour comprendre le monde, ltre humain a tendance regrouper les lments qui se ressemblent. Regrouper des objets suivants des critres de ressemblance sappelle classer. Les humains ont class les animaux les plantes, les champignons, les atomes, ... La classe est la description abstraite dun ensemble dobjets. Elle peut tre vue comme la factorisation des lments communs un ensemble dobjets.
Nom de classe Attributs

Rgles de visibilit + attribut public # attribut protg - attribut priv

Motocyclette Couleur Cylindre Vitesse maximale Dmarrer( ) Acclrer( ) Freiner( )

Oprations( )

Tlviseur
Modle

Allumer( ) Eteindre( ) Changer de programme( ) Rgler le volume( )

+ opration publique() # opration protge() - opration prive()

Figure 9 : des exemples de classe

La classe intgre les concepts de type (en tant que moule instances ) et de module (avec lide dinterface + corps).

opration (mthode) publique

Classe Etat

interface

opration (mthode) prive

Figure 10 : interface et corps dune classe

La hirarchisation des classes permet de grer la complexit. Dans un sens, la gnralisation correspond la factorisation des lments communs de classes (attributs, oprations) ce qui favorise la rduction de la complexit et la gnricit. Dans lautre sens, la spcialisation permet dadapter une classe gnrale un cas particulier ce qui favorise la rutilisation et la modification incrmentielle.
Super - classe Classe plus gnrale

gnralisation

spcialisation

Sous - classe

Classe plus spcialise

Figure 11 : gnralisation/spcialisation

Exemple :
Animal

Carnivore

Herbivore

Lion

Mouton

Lapin

Figure 12 : un exemple de hirarchisation.

Les instances de la classe spcialise hritent de la description des attributs (variables) et des oprations (mthodes) de la super-classe. Elles peuvent en ajouter dautres et/ou en redfinir certaines. On peut dire aussi que le type Lion est un sous type du type Carnivore. Tout lion est un carnivore (on parle aussi de relation est-un ou isa en anglais). Lensemble des lions est un sous ensemble des carnivores. Mais lensemble des attributs dun lion est un sur ensemble de lensemble des attributs dun carnivore ! (do le mot extends quutilise Java pour lier sous-classe et super-classe).

La relation de spcialisation/gnralisation est une relation non-rflexive, nonsymtrique et transitive. Lhritage multiple (plusieurs super classes) est possible. Un mme message peut tre trait de manire diffrente selon la nature de lobjet receveur. On parle de polymorphisme. Lmetteur na pas besoin de connatre la classe du receveur. Exemple : on paye des employs de 2 types (mensualiss et la tache). Il suffit denvoyer la mthode calculerPaie() tous les employs. Si un nouveau type demploy apparat le programme de paie na pas tre modifi.
Employ calculerPaie() mthode abstraite

Mensualis calculerPaie() Figure 13 : polymorphisme

A_la_tche calculerPaie() mthodes concrtes

7. Les diagrammes de classes

Les diagrammes de classes expriment la structure statique du systme. Ils dcrivent lensemble des classes et leurs associations. Une classe dcrit un ensemble dobjets (instances de la classe). Une association exprime une connexion smantique bidirectionnelle entre classes. Une association dcrit un ensemble de liens (instances de lassociation). Le rle dcrit une extrmit dune association. Les cardinalits (ou multiplicit) indiquent le nombre dinstances dune classe pour chaque instance de lautre classe.

Etudiant 1 Universit 0..1 Employeur

< Inscription Emploie >

* Personne *

Employ

1 Un et un seul 0..1 Zro ou un M .. N De M N (entiers naturels) * Plusieurs 0 .. * De zro plusieurs 1 .. * D 'un plusieurs Multiplicit place sur la destination

Figure 14 : les associations et leurs caractristiques

Exemple : association Inscription entre Etudiant et Universit (cf. Figure 14); lien dinscription entre lobjet Pierre et lobjet U niversit de Nancy. Rles Employeur et Employ de lassociation Emploie.

Lagrgation est une association qui dcrit une relation dinclusion entre une partie et un tout (lagrgat). Elle est rflexive, transitive, non symtrique. Si la relation dagrgation est une composition (composant/compos avec des dures de vie lies pour les objets), elle est symbolise par un losange plein ; sinon (pour des dures de vie indpendantes), elle est reprsente par un losange vide du ct de lagrgat.
Voiture 1 * Roue 1 Moteur 1 Carrosserie Circuit autobus 1 1..* Arrt

Figure 15 : Composition et autre forme dagrgation

Attention ne pas confondre gnralisation/spcialisation et agrgation ! Quand une classe est une spcialisation dune autre elle est de mme nature, ce qui nest pas le cas avec lagrgation. Exemple : Fruit Tarte

TarteAuxPommes

Pomme

Une tarte aux pommes est de mme nature quune tarte. Une pomme nest pas de mme nature quune tarte ! Autres concepts : - Attributs dassociations :
Buveur
A_bu Date Quantit Boire Est_bu

Vin

Figure 16 : attributs dassociation

Classe-association : association porteuse dattributs ou doprations, reprsente comme une classe anonyme associe lassociation. Etudiant
0..* Suit > 1..*

Matire

Pas de nom Note

Figure 17 : classe association

Association darit n : reprsente par un losange avec n pattes auquel peut tre associ une classe porteuse dattributs et doprations.
Salle
1 2..* 1

Etudiant

Enseignant

Cours Dbut Fin

Figure 18 : association n-aire

Paquetage (sous modle) : cest une notion qui peut apparatre dans beaucoup de diagrammes pour spcifier le regroupement dlments au sein dun sous systme (cas, classes, objets, composants, autres paquetages, ...).
paquetage

Figure 19 : un paquetage

Contraintes dintgrit entre associations (inclusion, exclusion, ...). Classes abstraites : elles sont non instanciables directement ; elles dcrivent des mcanismes gnraux et laissent non dcrits certains aspects (mthodes abstraites) ; elles sont spcialises par des classes concrtes (instanciables) qui prcisent les mthodes abstraites. Windows_ Window window {abstract} toFront() toFront() toBack() toBack() Mac_ window
Figure 20 : classe abstraite

toFront() toBack()

Interfaces : ce sont des classes ne contenant que des oprations abstraites ; elles prcisent les fonctionnalits que les classe qui les implantent doivent fournir.

7. Les diagrammes dtat

Les diagrammes dtat servent a dcrire le comportement des objets (classes) complexes. Ce sont des diagrammes dtat tendus avec des conditions (gardes) sur les transitions et des actions sur les transitions et les tats (cf. Figure 21).

Evnement [Condition] / Action garde Etat A A tat de dpart actions entry : on UnEvnement : exit :
Figure 21 : les diagrammes dtat tendus dUML

tat d'arrive

Ces diagrammes permettent aussi la dcomposition dtats en sous tats (cf. Figure 22). On parle aussi dtat composite. B Etat initial B1 A B2
Transition d'entre portant sur le super - tat avec un tat initial spcifi dans le super - tat

Figure 22 : dcomposition dtats Enfin, il est possible de dcrire du paralllisme entre sous systmes, ce qui rapproche les diagrammes dtat des rseaux de Petri (cf. Figure 23).
L'tat S appartient au produit cartsien des tats T et U

X E3 Z

E1 Y

A E1 E4 B

E2

Figure 23 : du paralllisme au sein dun tat

8. Les diagrammes dactivit

Ils permettent de dcrire un flot de contrle entre oprations (calculs). Il sagit en gros dorganigrammes incluant ventuellement du paralllisme (cf. Figure 24). A un niveau macroscopique, les diagrammes dactivit permettent de dcrire des enchanements de fonctionnalits. Ils compltent donc bien les cas dutilisation au niveau de lanalyse des besoins.

A un niveau microscopique, les diagrammes dactivit permettent, par exemple, de dcrire lalgorithme dune action dun diagramme dtats.
acteur1 activit dpart transition (automatique) flot dobjet objet [tat] [garde] acteur2

conditionnelle

barre de synchronisation

activits parallles fin couloir Figure 24 : notations des diagrammes dactivit

9. Autres lments
9.1. Les diagrammes de composants Les composants sont des codes (sources, excutables), des scripts, des fichiers, des tables, etc. (cf. Figure 25). 9.2. Les diagrammes de dploiement Ces diagrammes illustrent (cf. Figure 25) : la disposition physique des diffrents matriels (ou noeuds) qui entrent dans la composition du systme, la rpartition des composants (cf. diagrammes de composants) au sein des noeuds, les supports de communication entre noeuds. 9.3. Le langage OCL UML offre un langage formel pour lexpression des contraintes (Object Constraint Language). Cest un langage dclaratif typ. Il peut servir spcifier les invariants de classe, les pr et post conditions des oprations, les gardes, etc.

Figure 25 : un diagramme de dploiement

10.

Elments dune dmarche

UML nimpose pas de processus. La dmarche naturelle, implique par la notation UML, part des cas dutilisation qui expriment un point de vue fonctionnel sur le systme. Puis les diagrammes de collaboration et de squence associs aux cas font apparatre les classes dobjets impliques dans le systme et donc passer une vue objets (cf. figure 26). Mais on peut aussi bien passer une vue hirarchie de fonctions partir des cas dutilisation, comme le montre la Figure 27. Diagrammes essentiels par phase : Analyse des besoins : cas dutilisation. Analyse du systme : diagrammes de classes, de collaboration, dactivits (enchanement des cas). Conception : diagrammes de classes, de squences, dactivits (conception des mthodes), dtats, de composants, de dploiement.

fonctionnel

objet

Cas d'utilisation

Collaboration

m1

A
m1

B
m2

C
m3 m5

A
m6 m4

B
m3 m2 m5

m6 m4

Figure 26 : des cas dutilisation aux classes

Cas 1
<<Utilise>>

Cas 2

Cas 3

Le virage vers lobjet

dcomposition objet

dcomposition fonctionnelle

Figure 27 : des cas dutilisation aux fonctions ou aux objets

EXERCICES

Exercice 6.1 : Le GAB - cas dutilisation Modlisation dun GAB (Guichet Automatique de Banque). Les principales fonctions sont les suivantes : - distribution dargent tout porteur dune carte de la banque (autorisation dun certain montant par le Systme dInformation de la banque) ou dune carte VISA (autorisation distance par le Systme dAutorisation VISA), - consultation du solde, dpt en numraire et de chques pour les possesseurs dune carte de la banque. Toutes les transactions sont scurises (code personnel vrifi avec le code enregistr sur la puce de la carte ; la carte est avale aprs trois checs). Il faut parfois recharger le GAB et retirer des choses ... Identifier les acteurs et les cas. Structurer les cas. Exercice 6.2 : Le GAB - diagramme dactivits et diagramme de squence a) Modliser le retrait dargent avec une carte VISA avec un diagramme dactivits. La carte peut tre invalide. Si elle est valide, le client doit taper son code. La carte est avale aprs trois essais infructueux. Le SA VISA autorise un certain montant ou refuse tout retrait. Une carte non rcupre est avale. Les billets non rcuprs par le client sont repris. Un ticket est toujours imprim pendant que les billets sont proposs. b) Modliser le scnario nominal (succs) avec un diagramme de squence. Exercice 6.3 : Le cirque diagramme de classes Le propritaire dun cirque souhaite informatiser une partie de la gestion de ses spectacles. Proposer un modle conceptuel UML (diagramme de classes) qui rponde aux spcifications, fournies ci-dessous. Les membres du personnel du cirque sont caractriss par un numro (en gnral leur numro INSEE), leur nom, leur prnom, leur date de naissance et leur salaire. On souhaite de surcrot stocker les pseudonymes des artistes et le numro du permis de conduire des chauffeurs de poids lourds. Les artistes sont susceptibles dassurer plusieurs numros, chaque numro tant caractris par un code, son nom, le nombre dartistes prsents sur scne et sa dure. De plus, on souhaite savoir linstrument utilis pour les numros musicaux, lanimal concern par les numros de dressage et le type des acrobaties (contorsionnisme, quilibrisme, trapze volant). Par ailleurs, chaque numro peut ncessiter un certain nombre daccessoires caractriss par un numro de srie, une dsignation, une couleur et un volume. On souhaite galement savoir, individuellement, quels artistes utilisent quels accessoires. Enfin, les accessoires sont rangs aprs chaque spectacle dans des camions caractriss par leur numro dimmatriculation, leur marque, leur modle et leur capacit (en volume). Selon la taille du camion, une quipe plus ou moins nombreuses de chauffeurs lui est assign (de un trois chauffeurs).

Exercice 6.4 : Linstitut de formation diagramme de classes Il s'agit d'tablir le schma des donnes pour la gestion des formations d'un institut priv. Un cours est caractris par un numro de cours (NOCOURS), un libell (LIBELLE), une dure en heures (DUREE) et un type (TYPE). Un cours peut faire l'objet dans l'anne de plusieurs sessions identiques. Une session est caractrise par un numro (NOSES), une date de dbut (DATE) et un prix (PRIX). Une session est le plus souvent assure par plusieurs animateurs et est place sous la responsabilit d'un animateur principal. Un animateur peut intervenir dans plusieurs sessions au cours de l'anne. On dsire mmoriser le nombre d'heures (NBH) effectu par un animateur pour chaque session. Un animateur est caractris par un numro (NOANI), un nom (NOMA) et une adresse (ADRA). Chaque session est suivie par un certain nombre de participants. Un participant est une personne indpendante ou un employ d'une entreprise cliente. Un participant est caractris par un numro (NO-PAR), un nom (NOMP) et une adresse (ADRP). Dans le cas dun employ, on enregistre le nom (NO-MEN) et ladresse de lentreprise (ADREN). On dsire pouvoir grer dune manire spare (pour la facturation notamment) les personnes indpendantes dune part, et les employs dautre part. Exercice 6.5 Gestion de parc informatique diagramme de classes Une entreprise souhaite informatiser la gestion de son parc informatique (ordinateurs, imprimantes, etc.) pour en optimiser la maintenance. Proposer un schma de classes UML modlisant les spcifications ci-dessous (classes, associations entre classes, cardinalits des associations, attributs des classes). Un ordinateur est caractris par son numro dinventaire, son adresse rseau (adresse IP), son modle, la date de son acquisition, la date de la prochaine maintenance planifie et le systme dexploitation install. Sur chaque ordinateur est install un ensemble de logiciels caractriss par un numro de licence, un nom et une version. Grce un systme de mots de passe, chaque ordinateur peut tre utilis par plusieurs employs mais, pour des raisons de scurit des donnes, un employ na le droit dutiliser quun seul ordinateur. Un employ est caractris par son nom, son prnom et sa fonction dans lentreprise. Les ordinateurs sont relis un certain nombre de priphriques en rseau (imprimantes, scanners, etc.). Chaque priphrique est caractris par un numro dinventaire, son adresse IP, son type, son modle, sa date dacquisition et la date de la prochaine maintenance planifie. Les priphriques pouvant servir plusieurs ordinateurs simultanment, un indice de priorit est affect chaque ordinateur pour chaque priphrique auquel il est connect. Chaque ordinateur et chaque priphrique est localis dans un bureau donn. Les bureaux sont caractriss par un numro de bureau et le numro du btiment dans lequel ils se trouvent. Un numro de bureau est unique dans un btiment donn. Exercice 6.6 Cas dutilisation, diagramme de classes, diagramme de squence Une entreprise souhaite modliser avec UML le processus de formation de ses employs afin dinformatiser certaines tches. Le processus de formation est initialis quand le responsable formation reoit une demande de formation dun employ. Cet employ peut ventuellement consulter le

catalogue des formations offertes par les organismes agrs par lentreprise. Cette demande est instruite par le responsable qui transmet son accord ou son refus lemploy. En cas daccord, le responsable cherche la formation adquate dans le catalogues des formations agres quil tient jour. Il informe lemploy du contenu de la formation et lui soumet le liste des prochaines sessions prvues. Lorsque lemploy fait son choix il inscrit lemploy la session retenue auprs de lorganisme de formation concern. En cas dempchement lemploy doit avertir au plus vite le responsable formation pour que celui-ci demande lannulation de linscription. A la fin de la formation lemploy transmet une apprciation sur le stage suivi et un document attestant sa prsence. Le responsable formation contrle la facture envoye par lorganisme de formation. a) Dessiner le diagramme des cas dutilisation. b) Dessiner le schma des classes de cette application, incluant toutes les classes que lon peut dduire de lnonc, ainsi que les associations entre classes avec leurs cardinalits. c) Dessiner le diagramme de squence associ la demande initiale de lemploy dcrite dans le deuxime paragraphe de lnonc ; assurer la cohrence avec votre rponse la question prcdente.