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.
Vue externe
Diagrammes :
cas dutilisation
Vue logique
statique
Vue implantation
Vue logique
dynamique
Vue dploiement
conceptuel physique
analyse conception implantation
Diagrammes :
classe, objet,
collaboration,
squence
Diagrammes :
tats,
activit
Diagrammes :
composants
Diagrammes :
dploiement

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 (Addison-
Wesley, 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.

la structuration
des objets
la dynamique
des objets
les fonctions
du systme
les composants
logiciels
larchitecture
physique













Figure 2 : les cas dutilisation, fil conducteur du projet
SYSTEME
Cas d'utilisation X
Cas d'utilisation Y Acteur
Acteur
Notations :
Lacteur est source ou destination dune communication.
communication

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).
<<tend>>
Vi r ement par
Int ernet
Ident i fi cat i on
Vi r e me nt
Cl i ent l ocal
<<I ncl ut>>
Cl i ent di s t ant

Figure 4 : structuration des cas dutilisation
Utilisateur
Analyste
Programmeur
Testeur
Comprend
Cas d'utilisation
Utilisateur
Analyste
Programmeur
Testeur
Exprime
Ralise
Vrifie
Cas d'utilisation
acteur humain
<<acteur>>
acteur systme
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, ...
Ap r s u n p a r c o u r s
d e 1 0 0 K m
Une v oi t ur e
Une v oi t ur e
Es s enc e = 30 l i t r es
Es s enc e = 20 l i t r es
Une v oi t ur e
Coul eur = Rouge
Po i d s = 9 7 9 k g
Pu i s s a n c e = 1 6 CV
Es s enc e = 25 l i t r es

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.









Figure 6 : comportement dun objet

Un objet
Un autre objet
{...}
{...}
Un message
Opration 1
Opration 2
tat
comportement
Un objet
Un autre objet
{...}
{...}
Un message
Opration 1
Opration 2
tat
Son tat
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.






Figure 7 : un diagramme de collaboration

A
B
C
3: Z
1: X
2: Y
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).
















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.

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).
Nom de classe
Attributs
Oprations( )
Motocyclette
Couleur
Cylindre
Vitesse maximale
Dmarrer( )
Acclrer( )
Freiner( )
Tlviseur
Allumer( )
Eteindre( )
Changer de programme( )
Rgler le volume( )
Modle
Nom de classe
Attributs
Oprations( )
Motocyclette
Couleur
Cylindre
Vitesse maximale
Dmarrer( )
Acclrer( )
Freiner( )
Tlviseur
Allumer( )
Eteindre( )
Changer de programme( )
Rgler le volume( )
Modle
Rgles de visibilit
+ attribut public
# attribut protg
- attribut priv
+ opration publique()
# opration protge()
- opration prive()
Rgles de visibilit
+ attribut public
# attribut protg
- attribut priv
+ opration publique()
# opration protge()
- opration prive()
A B C
M1
M2
M3
M4
M5
M6
M7
M8
M9
M10
(ligne de vie)
temps

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.










Figure 11 : gnralisation/spcialisation
Exemple :







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).
Sous - classe
Super - classe
Classe plus
gnrale
Classe plus
spcialise
Sous - classe
Super - classe
Classe plus
gnrale
Classe plus
spcialise
opration
(mthode)
prive
opration
(mthode)
publique
Classe
Etat
interface
opration
(mthode)
prive
opration
(mthode)
publique
Classe
Etat
Classe
Etat
interface
gnralisation spcialisation
Animal
Carnivore Herbivore
Lion Mouton Lapin
Animal
Carnivore Herbivore
Lion Mouton Lapin
La relation de spcialisation/gnralisation est une relation non-rflexive, non-
symtrique 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.










Figure 13 : polymorphisme

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.
Universit Personne
* 1
*
0..1
Etudiant
Employ Employeur
*
*
0..1
1
1 U n e t u n s e u l
0 . . 1 Z r o o u u n
M . . N D e M N ( e n t i e r s n a t u r e l s )
* P l u s i e u r s
0 . . * D e z r o p l u s i e u r s
1 . . * D ' u n p l u s i e u r s
Mu l t i p l i c i t p l a c e s u r l a d e s t i n a t i o n
< I n s c r i p t i o n
E m p l o i e >

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

calculerPaie()
Mensualis

calculerPaie()
A_la_tche

calculerPaie()
mthode abstraite
mthodes concrtes
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.






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 :







Une tarte aux pommes est de mme nature quune tarte. Une pomme nest pas de
mme nature quune tarte !

Autres concepts :
- Attributs dassociations :




Figure 16 : attributs dassociation

- Classe-association : association porteuse dattributs ou doprations,
reprsente comme une classe anonyme associe lassociation.







Figure 17 : classe association

Circuit autobus
1
1..*
Voiture
Moteur
1
1
Roue Carrosserie
1
*
Arrt
Circuit autobus
1
1..*
Voiture
Moteur
1
1
Roue Carrosserie
1
*
Voiture
Moteur
1
1
Roue Carrosserie
1
*
Arrt
Buveur
Vin
Boire
Date
Quantit
A_bu Est_bu
Tarte
TarteAuxPommes
Pomme
Fruit
Etudiant Matire
Note
Pas de nom
1..* 0..*
Suit >
- Association darit n : reprsente par un losange avec n pattes auquel peut
tre associ une classe porteuse dattributs et doprations.











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



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.









Figure 20 : classe abstraite


- 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).
paquetage
Window
{abstract}

toFront()
toBack()
Windows_
window

toFront()
toBack()
Mac_
window

toFront()
toBack()
Salle
Cours
Enseignant
Etudiant
Dbut
Fin
2..* 1
1
Salle
Cours
Enseignant
Etudiant
Dbut
Fin
2..* 1
1









Figure 21 : les diagrammes dtat tendus dUML

Ces diagrammes permettent aussi la dcomposition dtats en sous tats (cf. Figure
22). On parle aussi dtat composite.












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












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
tat de dpart
tat d'arrive
Evnement [Condition] / Action
garde
Etat A
entry :
on UnEvnement :
exit :
actions
A
B1
B2
B
Etat initial
Transition d'entre portant sur le super - tat
avec un tat initial spcifi dans le super - tat
S
A
Y
X
Z
B
E1
E2
E3
T U
E1 E4
L'tat S appartient au produit cartsien des tats T et U
S
A
Y
X
Z
B
E1
E2
E3
T U
E1 E4
L'tat S appartient au produit cartsien des tats T et U
A un niveau microscopique, les diagrammes dactivit permettent, par exemple, de
dcrire lalgorithme dune action dun diagramme dtats.




















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.







acteur1
acteur2
couloir
dpart
fin
flot dobjet
objet
[tat]
activit
transition (automatique)
conditionnelle
[garde]
barre de synchronisation
activits parallles






















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.

Cas d'utilisation Collaboration
m1
m3
m2
m4
m5
m6
A B
C D
m1
m3
m2
m4
m5
m6
A B C D
fonctionnel objet

Figure 26 : des cas dutilisation aux classes

Le vi rage
vers l obj et
Cas 2
Cas 1
<<Utilise>>
Cas 3
dcomposi t i on
f onct i onnel l e
dcomposi t i on obj et

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.