Methodologie UML Cours Du Cycle B Du Cnam

8820448.
doc
______________________________________________________________________________
Mthodologie des
systmes d'information -
UML
Cours du Cycle Probatoire
UML
UP
___________________________________________________________________
DI GALLO Frdric Page 1 15/10/200808
8820448.doc
______________________________________________________________________________
Cours dispens par Annick Lassus.

CNAM ANGOULEME 2000-2001
METHODOLOGIES
DES SYSTEMES
D'INFORMATION :
UML
___________________________________________________________________
8820448.doc
______________________________________________________________________________
UP - LE PROCESSUS UNIFI............................5
I. LE PROCESSUS DE DVELOPPEMENT : NOUVELLE APPROCHE.....................................................5
II. LE PROCESSUS UNIFI : CADRE GNRAL............................................................................6
III. LE PROCESSUS UNIFI EST PILOT PAR LES CAS DUTILISATION..............................................6
3.1) Prsentation.......................................................................................................6
3.2) Exemple: guichet de banque..............................................................................6
IV. LE PROCESSUS UNIFI EST CENTR SUR LARCHITECTURE......................................................8
4.1) Liens entre cas dutilisation et architecture ?....................................................8
4.2) Marche suivre :................................................................................................8
V. LE PROCESSUS UNIFI EST ITRATIF ET INCRMENTAL............................................................8
5.1) Avantages dun processus itratif contrl........................................................9
VI. LE CYCLE DE VIE DU PROCESSUS UNIFI............................................................................9
6.1) Prsentation du cycle de vie de UP..................................................................10
6.2) Exemple sur les diffrents modles...................................................................11
VII. CONCLUSION : UN PROCESSUS INTGR.........................................................................12
APPROCHE DU LANGAGE UML...................17

I. LES MTHODES OBJET ET LA GENSE D'UML....................................................................17
1.1) Mthodes ?.......................................................................................................17
1.2) A quoi sert UML ?............................................................................................18
1.3) Les points forts d'UML.....................................................................................20
1.4) Les points faibles d'UML..................................................................................20
II. CARACTRISTIQUES DE LA MTHODE UML......................................................................21
2.1) UML est bas sur un mta-modle...................................................................21
2.2) UML: visualisation complte d'un systme .....................................................21
III. INTRODUCTION LA NOTATION UML.............................................................................22
3.1) La notion d'objet...............................................................................................22
3.2) Les mthodes objet...........................................................................................22
3.3) Intrt d'une mthode objet..............................................................................22
3.4) La normalisation OMG....................................................................................23
IV. MODLISER AVEC UML .............................................................................................24
4.1) Qu'est-ce qu'un modle ?.................................................................................24
4.2) Comment modliser avec UML ?.....................................................................25
4.3) Modlisation UML...........................................................................................29
INTRODUCTION AU LANGAGE UML..........39

I. LES CAS DUTILISATION..................................................................................................39
1.1) Objectifs des cas dutilisation..........................................................................39
1.2) lments constitutifs des cas dutilisation.......................................................40
1.3) Description des cas dutilisation......................................................................41
1.4) Structuration des cas dutilisation...................................................................43
1.6) Notion de paquetage.........................................................................................45
1.7) Exercice TVServices (parties I et II)................................................................45
II. LE DIAGRAMME DE CLASSES...........................................................................................50
___________________________________________________________________
8820448.doc
______________________________________________________________________________
2.1) Les classes........................................................................................................50
2.2) Les associations................................................................................................51
III. LE DIAGRAMME DE COLLABORATION...............................................................................56
3.1) Interaction........................................................................................................56
3.2) De nouveaux strotypes de classe..................................................................56
3.3) Les Messages :.................................................................................................58
3.4) Exercice TVServices (parties III et IV).............................................................60
3.5) TP de synthse: Cration d'un site Web...........................................................63
___________________________________________________________________
8820448.doc
______________________________________________________________________________
METHODOLOGIE CNAM ANGOULEME 2000-2001
UP - LE PROCESSUS UNIFI
Comparaison des mthodologies UP et Merise:
UP MERISE
Cycle de vie itratif et Squentiel
incrmental
Mthode gnrique
I. Le processus de dveloppement : nouvelle approche
Dans une dmarche traditionnelle, le processus de dveloppement tait caractris par :

Un processus de type squentiel : dveloppement organis en phases qui regroupent
des tapes, elles mmes dcomposes en tche.
Les niveaux de dcoupage concident : la fin dune phase correspond la conclusion
de ses tapes, qui elles mmes se terminent avec laccomplissement des tches qui les
composent.
Dans une approche objet tout change :

Le processus est de type itratif ;
Les dcoupages ne concident pas : les activits (taches, phases, tapes, etc) se
droulent dans plusieurs dimensions.
La matrise des processus de dveloppement implique pourtant une organisation et un

suivi des activits : cest ce quoi sattachent les diffrentes mthodes qui sappuient sur
lutilisation du langage UML pour modliser un systme dinformation.
UP (Unified Process) est une mthode gnrique de dveloppement de logiciel.

Gnrique signifie qu'il est ncessaire d'adapter UP au contexte du projet, de l'quipe, du
domaine et/ou de l'organisation (exemple: R.UP ou X.UP). C'est, entre parenthses, plus ou
moins vrai pour toute mthode, qu'elle se dfinisse elle-mme comme gnrique ou pas.
Il existe donc un certain nombre de mthodes issues de UP.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
II. Le processus unifi : cadre gnral

Le processus unifi est un processus de dveloppement logiciel : il regroupe les activits
mener pour transformer les besoins dun utilisateur en systme logiciel.
Caractristiques essentielles du processus unifi :

- Le processus unifi est base de composants,
- Le processus unifi utilise le langage UML (ensemble d'outils et de diagramme),
- Le processus unifi est pilot par les cas dutilisation,
- Centr sur larchitecture,
- Itratif et incrmental.
III. Le processus unifi est pilot par les cas dutilisation

3.1) Prsentation
Lobjectif principal dun systme logiciel est de rendre service ses utilisateurs ; il faut par
consquent bien comprendre les dsirs et les besoins des futurs utilisateurs. Le processus de
dveloppement sera donc centr sur l'utilisateur. Le terme utilisateur ne dsigne pas
seulement les utilisateurs humains mais galement les autres systmes. Lutilisateur
reprsente donc une personne ou une chose dialoguant avec le systme en cours de
dveloppement.
Ce type dinteraction est appel cas dutilisation.
Cas
d'utilisation
Acteur
Les cas dutilisation font apparatre les besoins fonctionnels et leur ensemble constitue le
modle des cas dutilisation qui dcrit les fonctionnalits compltes du systme.
3.2) Exemple: guichet de banque

retirer de l'argent mettre de l'argent
dposer de l'argent
virement entre comptes
client de la banque employ de la banque
On va se demander, en premier, quels sont les utilisateurs du systme (pas forcment des
utilisateurs physiques, mais plutt des rles). Ici, l'employ est aussi un client de la banque.
On a donc une personne physique pour deux rles. Nous ne sommes pas dans une approche de
type fonctionnelle mais une approche pilote par des cas d'utilisation.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
3.3) Stratgie des cas dutilisation
Que doit pouvoir faire le systme pour chaque utilisateur ?
Les cas dutilisation ne sont pas un simple outil de spcification des besoins du systme.
Ils vont compltement guider le processus de dveloppement travers lutilisation de
modles bass sur lutilisation du langage UML
A partir du modle des cas dutilisation, les dveloppeurs crent une srie de
modles de conception et dimplmentation ralisant les cas dutilisation.
Chacun des modles successifs est ensuite rvis pour en contrler la conformit
par rapport au modle des cas dutilisation.
Enfin, les testeurs testent limplmentation pour sassurer que les composants du
modle dimplmentation mettent correctement en uvre les cas dutilisation.
Les cas dutilisation garantissent la cohrence du processus de dveloppement du

systme. Sil est vrai que les cas dutilisation guident le processus de dveloppement, ils ne
sont pas slectionns de faon isole, mais doivent absolument tre dvelopps "en
tandem" avec larchitecture du systme.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
IV. Le processus unifi est centr sur larchitecture

Ds le dmarrage du processus, on aura une vue sur l'architecture mettre en place.
Larchitecture dun systme logiciel peut tre dcrite comme les diffrentes vues du systme
qui doit tre construit. Larchitecture logicielle quivaut aux aspects statiques et dynamiques
les plus significatifs du systme. Larchitecture merge des besoins de lentreprise, tels quils
sont exprims par les utilisateurs et autres intervenants et tels quils sont reflts par les cas
dutilisation.
Elle subit galement linfluence dautres facteurs :
- la plate-forme sur laquelle devra sexcuter le systme ;
- les briques de bases rutilisables disponibles pour le dveloppement ;
- les considrations de dploiement, les systmes existants et les besoins non
fonctionnels (performance, fiabilit..)
4.1) Liens entre cas dutilisation et architecture ?

Tout produit est la fois forme et fonction. Les cas dutilisation doivent une fois raliss,
trouver leur place dans larchitecture. Larchitecture doit prvoir la ralisation de tous les cas
dutilisation. Larchitecture et les cas dutilisation doivent voluer de faon concomitante.
4.2) Marche suivre :

Larchitecte cre une bauche grossire de larchitecture, en partant de laspect qui
nest pas propre aux cas dutilisation (plate forme..). Bien que cette partie de
larchitecture soit indpendante des cas dutilisation. Larchitecte doit avoir une
comprhension globale de ceux ci avant den esquisser larchitecture.
Il travaille ensuite, sur un sous ensemble des cas dutilisations identifis, ceux qui
reprsentent les fonctions essentielles du systme en cours de dveloppement.
Larchitecture se dvoile peu peu, au rythme de la spcification et de la

maturation des cas dutilisation, qui favorisent, leur tour, le dveloppement dun
nombre croissant de cas dutilisation.
Ce processus se poursuit jusqu ce que larchitecture soit juge stable.
V. Le processus unifi est itratif et incrmental

Le dveloppement dun produit logiciel destin la commercialisation est une vaste
entreprise qui peut stendre sur plusieurs mois. On ne va pas tout dvelopper dun coup. On
peut dcouper le travail en plusieurs parties qui sont autant de mini projets. Chacun dentre
eux reprsentant une itration qui donne lieu un incrment.
Une itration dsigne la succession des tapes de lenchanement dactivits, tandis quun
incrment correspond une avance dans les diffrents stades de dveloppement.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
Le choix de ce qui doit tre implment au cours dune itration repose sur deux facteurs :
Une itration prend en compte un certain nombre de cas dutilisation qui ensemble,
amliorent lutilisabilit du produit un certain stade de dveloppement.
Litration traite en priorit les risques majeurs.
Un incrment constitue souvent un additif.
A chaque itration, les dveloppeurs identifient et spcifient les cas dutilisations

pertinents, crent une conception en se laissant guider par larchitecture choisie,
implmentent cette conception sous forme de composants et vrifie que ceux ci sont
conformes aux cas dutilisation. Ds quune itration rpond aux objectifs fixs le
dveloppement passe litration suivante.
Pour rentabiliser le dveloppement il faut slectionner les itrations ncessaires pour
atteindre les objectifs du projet. Ces itrations devront se succder dans un ordre logique.
Un projet russi suivra un droulement direct, tabli ds le dbut par les dveloppeurs et
dont ils ne sloigneront que de faon trs marginale. Llimination des problmes imprvus
fait partie des objectifs de rduction des risques.
5.1) Avantages dun processus itratif contrl
Permet de limiter les cots, en termes de risques, aux strictes dpenses lies une
itration.
Permet de limiter les risques de retard de mise sur le march du produit dvelopp
(identification des problmes ds les premiers stades de dveloppement et non en
phase de test comme avec lapproche classique ).
Permet dacclrer le rythme de dveloppement grce des objectifs clairs et

court terme.
Permet de prendre en compte le fait que les besoins des utilisateurs et les exigences
correspondantes ne peuvent tre intgralement dfinis lavance et se dgagent
peu peu des itrations successives
Larchitecture fournit la structure qui servira de cadre au travail effectu au cours des
itrations, tandis que les cas dutilisation dfinissent les objectifs et orientent le travail de
chaque itration. Il ne faut donc pas msestimer lun des trois concepts.
VI. Le cycle de vie du processus unifi

Le processus unifi rpte un certain nombre de fois une srie de cycles.
Tout cycle se conclut par la livraison dune version du produit aux clients et sarticule en 4
phases : cration, laboration, construction et transition, chacune dentre elles se subdivisant
son tour en itrations.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
Chaque cycle se traduit par une nouvelle version du systme. Ce produit se compose dun
corps de code source rparti sur plusieurs composants pouvant tre compils et excuts et
saccompagne de manuels et de produits associs. Pour mener efficacement le cycle, les
dveloppeurs ont besoin de construire toutes les reprsentations du produit logiciel :
Expose les cas dutilisation et leurs relations avec

Modle des cas dutilisation
les utilisateurs
Dtaille les cas dutilisation et procde une
Modle danalyse premire rpartition du comportement du systme
entre divers objets
Dfinit la structure statique du systme sous
forme de sous systme, classes et interfaces ;
Modle de conception Dfinit les cas dutilisation raliss sous forme
de collaborations entre les sous systmes les
classes et les interfaces
Intgre les composants (code source) et la
Modle dimplmentation
correspondance entre les classes et les composants
Dfinit les nuds physiques des ordinateurs et
Modle de dploiement
laffectation de ces composants sur ces nuds.
Modle de test Dcrit les cas de test vrifiant les cas dutilisation
Reprsentation de larchitecture Description de larchitecture
Tous ces modles sont lis. Ensemble, ils reprsentent le systme comme un tout. Les
lments de chacun des modles prsentent des dpendances de traabilit ; ce qui facilite
la comprhension et les modifications ultrieures.
6.1) Prsentation du cycle de vie de UP
___________________________________________________________________
8820448.doc
______________________________________________________________________________
Phase Description et Enchanement dactivits

Traduit une ide en vision de produit fini et prsente une
tude de rentabilit pour ce produit
- Que va faire le systme pour les utilisateurs ?
- A quoi peut ressembler larchitecture dun tel systme ?
Phase de cration - Quels sont lorganisation et les cots du dveloppement
de ce produit ?
On fait apparatre les principaux cas dutilisation.
Larchitecture est provisoire, identification des risques
majeurs et planification de la phase dlaboration.
Permet de prciser la plupart des cas dutilisation et de
concevoir larchitecture du systme. Larchitecture doit tre
exprime sous forme de vue de chacun des modles.
Phase dlaboration Emergence dune architecture de rfrence.
A lissue de cette phase, le chef de projet doit tre en
mesure de prvoir les activits et destimer les ressources
ncessaires lachvement du projet.
Moment o lon construit le produit. Larchitecture de
rfrence se mtamorphose en produit complet, elle est
maintenant stable. Le produit contient tous les cas
Phase de construction dutilisation que les chefs de projet, en accord avec les
utilisateurs ont dcid de mettre au point pour cette
version. Celle ci doit encore avoir des anomalies qui
peuvent tre en partie rsolue lors de la phase de transition.
Le produit est en version bta. Un groupe dutilisateurs
essaye le produit et dtecte les anomalies et dfauts. Cette
phase suppose des activits comme la fabrication, la
Phase de transition formation des utilisateurs clients, la mise en uvre dun
service dassistance et la correction des anomalies
constates.(o le report de leur correction la version
suivante)
6.2) Exemple sur les diffrents modles

Cas du guichet de banque
a) Diagramme de cas d'utilisation:

retirer de l'argent
dposer de l'argent
virement entre comptes
client de la banque
On va essayer de faire apparatre des cas nominaux (classiques) et des scnarios

d'exception.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
b) Modle d'analyse: ralisation d'un cas d'utilisation
c) Diagramme de collaboration
VII. Conclusion : un processus intgr

Le processus unifi est bas sur des composants. Il utilise UML et est bas sur les cas
dutilisation, larchitecture et le dveloppement incrmental. Pour mettre en pratique ces
ides il faut recourir un processus multi-facettes prenant en considration les cycles, les
phases, les enchanements dactivits, la rduction des risques, le contrle qualit, la gestion
de projet et la gestion de configuration. Le processus unifi a mis en place un cadre gnral
(framework) intgrant chacune de ces facettes.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
Approche du
langage UML
___________________________________________________________________
8820448.doc
______________________________________________________________________________
UP - LE PROCESSUS UNIFI 5
I. LE PROCESSUS DE DVELOPPEMENT : NOUVELLE APPROCHE 5
II. LE PROCESSUS UNIFI : CADRE GNRAL 6
III. LE PROCESSUS UNIFI EST PILOT PAR LES CAS DUTILISATION 6
3.1) Prsentation 6
3.2) Exemple: guichet de banque 6
IV. LE PROCESSUS UNIFI EST CENTR SUR LARCHITECTURE 8
4.1) Liens entre cas dutilisation et architecture ? 8
4.2) Marche suivre : 8
V. LE PROCESSUS UNIFI EST ITRATIF ET INCRMENTAL 8
5.1) Avantages dun processus itratif contrl 9
VI. LE CYCLE DE VIE DU PROCESSUS UNIFI 9
6.1) Prsentation du cycle de vie de UP 10
6.2) Exemple sur les diffrents modles 11
a) Diagramme de cas d'utilisation: 11
b) Modle d'analyse: ralisation d'un cas d'utilisation 12
c) Diagramme de collaboration 12
VII. CONCLUSION : UN PROCESSUS INTGR 12
APPROCHE DU LANGAGE UML 17

I. LES MTHODES OBJET ET LA GENSE D'UML 17
1.1) Mthodes ? 17
1.2) A quoi sert UML ? 18
1.3) Les points forts d'UML 20
1.4) Les points faibles d'UML 20
II. CARACTRISTIQUES DE LA MTHODE UML 21
2.1) UML est bas sur un mta-modle 21
2.2) UML: visualisation complte d'un systme 21
III. INTRODUCTION LA NOTATION UML 22
3.1) La notion d'objet 22
3.2) Les mthodes objet 22
3.3) Intrt d'une mthode objet 22
3.4) La normalisation OMG 23
IV. MODLISER AVEC UML 24
4.1) Qu'est-ce qu'un modle ? 24
Un modle est une abstraction de la ralit 24
Un modle est une vue subjective mais pertinente de la ralit 24
Quelques exemples de modles 24
Caractristiques fondamentales des modles 24
4.2) Comment modliser avec UML ? 25
Une dmarche itrative et incrmentale ? 25
Une dmarche pilote par les besoins des utilisateurs ? 25
Une dmarche centre sur l'architecture ? 25
Dfinir une architecture avec UML (dtail de la "vue 4+1") 26
Rsumons la dmarche... 27
Dtail des diffrents niveaux d'abstraction (phases du macro-processus) 28
Activits des micro-processus d'analyse (niveau d'abstraction constant) 28
___________________________________________________________________
8820448.doc
______________________________________________________________________________
Synthse de la dmarche 29
4.3) Modlisation UML 29
Qu'est-ce qu'un modle ? 29
La modlisation UML 29
Les cas d'utilisation 30
Modlisation des classes et objets 30
Modlisation d'une classe 33
La visibilit des attributs 33
INTRODUCTION AU LANGAGE UML 39

I. LES CAS DUTILISATION 39
1.1) Objectifs des cas dutilisation 39
1.2) lments constitutifs des cas dutilisation 40
Exemple : Diagramme de cas dutilisation dun guichet automatique bancaire 40
1.3) Description des cas dutilisation 41
a) Exemple : Cas dutilisation Retirer de largent 41
b) Exemple : scnario du cas dutilisation :Retirer de largent ; retrait autoris 41
1.4) Structuration des cas dutilisation 43
a) La relation dinclusion : 43
b) La relation dextension 44
c) Relation de gnralisation entre cas dutilisation 44
1.6) Notion de paquetage 45
1.7) Exercice TVServices (parties I et II) 45
Partie 1: Diagramme de cas d'utilisation - vue de l'administrateur 45
Partie II: Diagramme de cas d'utilisation - vue de l'utilisateur 48
II. LE DIAGRAMME DE CLASSES 50
2.1) Les classes 50
a) Dfinition 50
b) Reprsentation 50
c) Syntaxe 51
d) Oprations 51
2.2) Les associations 51
a) Arit des associations 52
b) Rle 52
c) Identification des associations 52
d) Identification des rles 52
e) Multiplicit des associations 53
f) Les classes associations : 54
g) Agrgation 54
h) La composition 55
i) Gnralisation : 55
III. LE DIAGRAMME DE COLLABORATION 56
3.1) Interaction 56
3.2) De nouveaux strotypes de classe 56
3.3) Les Messages : 58
3.4) Exercice TVServices (parties III et IV) 60
Partie III: Diagramme de classe mtier pour le cas d'utilisation regarder 61
Partie IV: Diagramme de collaboration d'un scnario du cas d'util. regarder 62
3.5) TP de synthse: Cration d'un site Web 63
a) L'adhsion: 63
b) La publication des articles: 63
c) La vente des ouvrages: 63
___________________________________________________________________
8820448.doc
______________________________________________________________________________
___________________________________________________________________
8820448.doc
______________________________________________________________________________
APPROCHE DU LANGAGE UML
I. Les mthodes objet et la gense d'UML

1.1) Mthodes ?
Les premires mthodes d'analyse (annes 70)

Dcoupe cartsienne (fonctionnelle et hirarchique) d'un systme.
L'approche systmique (annes 80)

Modlisation des donnes + modlisation des traitements (Merise, Axial, IE...).
L'mergence des mthodes objet (1990-1995)

Prise de conscience de l'importance d'une mthode spcifiquement objet: comment
structurer un systme sans centrer l'analyse uniquement sur les donnes ou uniquement sur
les traitements (mais sur les deux) ? Plus de 50 mthodes objet sont apparues durant cette
priode (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE...)!
Aucune mthode ne s'est rellement impose.
Les premiers consensus (1995)

OMT (James Rumbaugh) : vues statiques, dynamiques et fonctionnelles d'un systme.
Issue du centre de R&D de General Electric. Notation graphique riche et lisible.
OOD (Grady Booch) : vues logiques et physiques du systme. Dfinie pour le DOD,
afin de rationaliser de dveloppement d'applications ADA, puis C++. Ne couvre pas la
phase d'analyse dans ses 1res versions (prconise SADT). Introduit le concept de
package (lment d'organisation des modles).
OOSE (Ivar Jacobson) : couvre tout le cycle de dveloppement. Issue d'un centre de
dveloppement d'Ericsson, en Sude. La mthodologie repose sur l'analyse des
besoins des utilisateurs.
L'unification et la normalisation des mthodes (1995-1997)
UML (Unified Modeling Langage), la fusion et synthse des mthodes dominantes :
___________________________________________________________________
8820448.doc
______________________________________________________________________________
UML aujourd'hui : un standard incontournable
UML est le rsultat d'un large consensus (industriels, mthodologistes...).
UML est le fruit d'un travail d'experts reconnus.
UML est issu du terrain.
UML est riche (il couvre toutes les phases d'un cycle de dveloppement).
UML est ouvert (il est indpendant du domaine d'application et des langages
d'implmentation).
Aprs l'unification et la standardisation, bientt l'industrialisation d'UML :
les outils qui supportent UML se multiplient (GDPro, ObjectTeam, Objecteering,
OpenTool, Rational Rose, Rhapsody, STP, Visio, Visual Modeler, WithClass...).
XMI (format d'change standard de modles UML).
UML volue mais reste stable !

L'OMG RTF (nombreux acteurs industriels) centralise et normalise les volutions
d'UML au niveau international.
Les groupes d'utilisateurs UML favorisent le partage des expriences.
De version en version, UML gagne en maturit et prcision, tout en restant stable.
UML inclut des mcanismes standards d'auto-extension.
La description du mtamodle d'UML est standardise (OMG-MOF).
>>> UML n'est pas une mode, c'est un investissement fiable !
1.2) A quoi sert UML ?
UML n'est pas une mthode ou un processus !

Si l'on parle de mthode objet pour UML, c'est par abus de langage !
Ce constat vaut aussi pour OMT ou d'autres techniques / langages de modlisation.
Une mthode propose aussi un processus, qui rgit notamment l'enchanement des
activits de production d'une entreprise.
UML a t pens pour permettre de modliser les activits de l'entreprise, pas pour
les rgir (ce n'est pas CMM ou SPICE).
Un processus de dveloppement logiciel universel est une utopie :
Impossible de prendre en compte toutes les organisations et cultures d'entreprises.
Un processus est adapt (donc trs li) au domaine d'activit de l'entreprise.
Mme si un processus constitue un cadre gnral, il faut l'adapter de manire
prcise au contexte de l'entreprise.
UML est un langage pseudo-formel

UML est fond sur un mtamodle, qui dfinit :
les lments de modlisation (les concepts manipuls par le langage),
la smantique de ces lments (leur dfinition et le sens de leur utilisation).
Un mtamodle est une description trs formelle de tous les concepts d'un langage. Il
limite les ambiguts et encourage la construction d'outils.
Le mtamodle d'UML permet de classer les concepts du langage (selon leur niveau
d'abstraction ou domaine d'application) et expose sa structure.
Le mtamodle UML est lui-mme dcrit par un mta-mtamodle (OMG-MOF).
___________________________________________________________________
8820448.doc
______________________________________________________________________________
UML propose aussi une notation, qui permet de reprsenter graphiquement les
lments de modlisation du mtamodle.
Cette notation graphique est le support du langage UML.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
UML cadre l'analyse objet, en offrant :

diffrentes vues (perspectives) complmentaires d'un systme, qui guident l'utilisation
des concept objets,
plusieurs niveaux d'abstraction, qui permettent de mieux contrler la complexit dans
l'expression des solutions objets.
UML est un support de communication

Sa notation graphique permet d'exprimer visuellement une solution objet.
L'aspect formel de sa notation limite les ambiguts et les incomprhensions.
Son aspect visuel facilite la comparaison et l'valuation de solutions.
Son indpendance (par rapport aux langages d'implmentation, domaine
d'application, processus...) en font un langage universel.
1.3) Les points forts d'UML
UML est un langage formel et normalis

gain de prcision
gage de stabilit
encourage l'utilisation d'outils
UML est un support de communication performant

Il cadre l'analyse.
Il facilite la comprhension de reprsentations abstraites complexes.
Son caractre polyvalent et sa souplesse en font un langage universel.
1.4) Les points faibles d'UML
La mise en pratique d'UML ncessite un apprentissage et passe par une priode

d'adaptation.
Mme si l'Espranto est une utopie, la ncessit de s'accorder sur des modes d'expression
communs est vitale en informatique. UML n 'est pas l'origine des concepts objets, mais en
constitue une tape majeure, car il unifie les diffrentes approches et en donne une dfinition
plus formelle.
Le processus (non couvert par UML) est une autre cl de la russite d'un projet.
Or, l'intgration d'UML dans un processus n'est pas triviale et amliorer un processus est
un tche complexe et longue. Les auteurs d'UML sont tout fait conscients de l'importance du
processus, mais l'acceptabilit industrielle de la modlisation objet passe d'abord par la
disponibilit d'un langage d'analyse objet performant et standard.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
II. Caractristiques de la mthode UML

2.1) UML est bas sur un mta-modle
UML est un moyen d'exprimer des modles objet en faisant abstraction de leur
implmentation, c'est--dire que le modle fourni par UML est valable pour n'importe quel
langage de programmation. UML est un langage qui s'appuie sur un mtamodle, un modle
de plus haut niveau qui dfinit les lments d'UML (les concepts utilisables) et leur
smantique (leur signification et leur mode d'utilisation). Le mtamodle permet de se placer
un niveau d'abstraction suprieur car il est tudi pour tre plus gnrique que le modle
qu'il permet de construire. Le mtamodle d'UML en fait un langage formel possdant les
caractristiques suivantes:
un langage sans ambiguts
un langage universel pouvant servir de support pour tout langage orient objet
un moyen de dfinir la structure d'un programme
une reprsentation visuelle permettant la communication entre acteurs d'un mme projet
une notation graphique simple, comprhensible mme par des non informaticiens
Le mtamodle permet de donner des bases solides et rigoureuses ce langage graphique,
dont la reprsentations graphiques ne sont l que pour vhiculer des concepts de ralisation.
2.2) UML: visualisation complte d'un systme

UML offre une manire lgante de reprsenter le systme selon diffrentes vues
complmentaires grce aux diagrammes.
Lorsqu'une entreprise dsire un logiciel, elle le ralise parfois en interne, mais le fait plus
gnralement raliser par une socit de services. Dans un cas comme dans l'autre il est
ncessaire de dfinir l'ensemble des fonctionnalits que le logiciel doit possder. Le
demandeur du logiciel n'a parfois pas de comptences particulires en informatique et
exprime donc ses souhaits sous forme d'un CdCF (Cahier des Charges Fonctionnelles), c'est-
-dire un document dcrivant sous forme textuelle l'ensemble des particularits que le
logiciel doit possder, les conditions qu'il doit remplir (systme(s) d'exploitation vis(s)), les
cueils viter, ainsi que les dlais impartis, ventuellement des clauses sur le cot, les
langages utiliser, ...
Le CdCF est ainsi distribu diffrentes socits de services (dans le cas d'une sous-
traitance) sous forme d'un appel d'offre, auquel les socits vont rpondre par un cot, un
dlai, ...
Lorsqu'une socit obtient le march et qu'elle dcide (si elle a le choix) d'opter pour un
langage orient objet, il lui faut dans un premier temps crer un modle (c'est l qu'intervient
UML) afin:
de prsenter au client la faon de laquelle elle compte dvelopper le logiciel
d'accorder tous les acteurs du projet (une application de grande envergure est
gnralement ralise par modules dvelopps par diffrentes quipes)
Ainsi, si le modle ne convient pas au client, il sera "simple" modifier, contrairement
une application directement implmente (qui aurait mobilis beaucoup plus de personnel,
pendant une priode plus longue), ce qui signifie une perte d'argent beaucoup moins
importante pour la socit de services, ainsi qu'une meilleure probabilit de rendre dans les
temps (on parle gnralement de dead line) une application conforme aux exigences du client
___________________________________________________________________
8820448.doc
______________________________________________________________________________
(si l'application se conforme au modle prsent au client, celui-ci peut difficilement
contester la validit du logiciel).
III. Introduction la notation UML

UML (Unified Modeling Language, que l'on peut traduire par "langage de modlisation
unifi) est une notation permettant de modliser un problme de faon standard. Ce langage
est n de la fusion de plusieurs mthodes existant auparavant, et est devenu dsormais la
rfrence en terme de modlisation objet, un tel point que sa connaissance est souvent
ncessaire pour obtenir un poste de dveloppeur objet.
3.1) La notion d'objet

La programmation oriente objet consiste modliser informatiquement un ensemble
d'lments d'une partie du monde rel (que l'on appelle domaine) en un ensemble d'entits
informatiques. Ces entits informatiques sont appeles objet. Il s'agit de donnes
informatiques regroupant les principales caractristiques des lments du monde rel (taille,
la couleur, ...). La difficult de cette modlisation consiste crer une reprsentation
abstraite, sous forme d'objets, d'entits ayant une existence matrielle (chien, voiture,
ampoule, ...) ou bien virtuelle (scurit sociale, temps, ...).
3.2) Les mthodes objet

La modlisation objet consiste crer une reprsentation informatique des lments du
monde rel auxquels on s'intresse, sans se proccuper de l'implmentation, ce qui signifie
indpendamment d'un langage de programmation. Il s'agit donc de dterminer les objets
prsents et d'isoler leurs donnes et les fonctions qui les utilisent.
Cette mthode reprsente un langage permettant de spcifier, reprsenter et construire les

composantes dun systme informatique. Avec la mthode UML, un objet est par exemple
reprsent de la faon suivante:
3.3) Intrt d'une mthode objet

Les langages orients objet constituent chacun une manire spcifique d'implmenter le
paradigme objet. Ainsi, une mthode objet permet de dfinir le problme haut niveau sans
rentrer dans les spcificits d'un langage. Il reprsente ainsi un outil permettant de dfinir un
problme de faon graphique, afin par exemple de le prsenter tous les acteurs d'un projet
(n'tant pas forcment des experts en un langage de programmation).
___________________________________________________________________
8820448.doc
______________________________________________________________________________
De plus, le fait de programmer l'aide d'un langage orient objet ne fait pas d'un
programmer un concepteur objet. En effet il est tout fait possible de produire un code
syntaxiquement juste sans pour autant adopter une approche objet. Ainsi la programmation
oriente objet implique en premier lieu une conception abstraite d'un modle objet (c'est le
rle de la mthode objet), en second plan l'implmentation l'aide d'un langage oriente
objet (tel que C++/Java/...)
Une mthode objet est donc d'une part une mthode d'analyse du problme (afin de
couvrir toutes les facettes du problmes), d'autre part un langage permettant une
reprsentation standard stricte des concepts abstraits (la modlisation) afin de constituer un
langage commun.
3.4) La normalisation OMG

Ainsi, il est ncessaire qu'une mthode objet soit dfinie de manire rigoureuse et unique
afin de lever les ambiguts. De nombreuses mthodes objet ont t dfinies, mais aucune
n'a su s'imposer en raison du manque de standardisation. C'est pourquoi l'ensemble des
acteurs du monde informatique a fond en 1989 l'OMG (Object Management Group), une
organisation but non lucratif, dont le but est de mettre au point des standards garantissant la
compatibilit entre des applications programmes l'aide de langages objet et fonctionnant
sur des rseaux htrognes (de diffrents types). A partir de 1997, UML est devenue une
norme de l'OMG, ce qui lui a permis de s'imposer en tant que mthode de dveloppement
objet et tre reconnue et utilise par de nombreuses entreprises.
L'OMG est un organisme but non lucratif, cr en 1989 l'initiative de grandes socits
(HP, Sun, Unisys, American Airlines, Philips...). Aujourd'hui, l'OMG fdre plus de 850
acteurs du monde informatique. Son rle est de promouvoir des standards qui garantissent
l'interoprabilit entre applications orientes objet, dveloppes sur des rseaux
htrognes.
L'OMG propose notamment l'architecture CORBA (Common Object Request Broker
Architecture), un modle standard pour la construction d'applications objets distribus
(rpartis sur un rseau). Pour rester simple, on peut considrer CORBA comme une
gnralisation de l'architecture clients/serveurs aux objets.
Au centre de l'architecture CORBA, un routeur de messages (ORB : Object Request
Broker) permet des objets clients d'envoyer des requtes et de recevoir des rponses, sans
avoir se proccuper des dtails techniques propres l'infrastructure du rseau. L'ORB se
charge de transmettre les requtes aux objets concerns, o qu'ils se trouvent (dans le mme
processus, dans un autre, sur un autre nud du rseau...). Le bus CORBA (dont l'ORB est le
composant central) permet d'assurer la transparence des invocations de mthodes ; les
requtes aux objets semblent toujours tre locales.
De plus, l'ORB assure une coopration entre objets qui est indpendante des langages de
programmation. Le modle CORBA permet en effet de se focaliser sur les interfaces des
objets, qu'on exprime en IDL (Interface Definition Language). L'IDL dcrit de manire
standard l'interface d'un objet, en faisant abstraction des dtails qui relvent de son
d'implmentation. Avec CORBA, il n'est donc pas ncessaire de savoir comment les objets
sont cods pour utiliser leurs services. L'utilisation d'IDL comme langage pivot dans la
construction d'une architecture, permet de grer l'htrognit. Cette approche, qui
consiste masquer les couches techniques du rseau (systme d'exploitation, processeur,
langage de programmation...), permet d'assurer l'interoprabilit de toute application objets
distribus, conforme au modle CORBA.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
CORBA fait partie d'une vision globale de la construction d'applications rparties, appele
OMA (Object Management Architecture) et dfinie par l'OMG. Sans rentrer dans les dtails,
on peut rsumer cette vision par la volont de favoriser l'essor industriel des technologies
objet, en offrant un ensemble de solutions technologiques non propritaires, qui
suppriment les clivages techniques.
UML a t adopt (normalis) par l'OMG et intgr l'OMA, car il participe cette
vision et parce qu'il rpond la "philosophie" OMG.
IV. Modliser avec UML

4.1) Qu'est-ce qu'un modle ?
Un modle est une abstraction de la ralit
L'abstraction est un des piliers de l'approche objet. Il s'agit d'un processus qui consiste
identifier les caractristiques intressantes d'une entit, en vue d'une utilisation prcise.
L'abstraction dsigne aussi le rsultat de ce processus, c'est--dire l'ensemble des
caractristiques essentielles d'une entit, retenues par un observateur.
Un modle est une vue subjective mais pertinente de la ralit

Un modle dfinit une frontire entre la ralit et la perspective de l'observateur. Ce n'est
pas "la ralit", mais une vue trs subjective de la ralit.
Bien qu'un modle ne reprsente pas une ralit absolue, un modle reflte des aspects
importants de la ralit, il en donne donc une vue juste et pertinente.
Quelques exemples de modles

Modle mtorologique: partir de donnes d'observation (satellite ...), permet de
prvoir les conditions climatiques pour les jours venir.
Modle conomique: peut par exemple permettre de simuler l'volution de cours
boursiers en fonction d'hypothses macro-conomiques (volution du chmage, taux de
croissance...).
Modle dmographique: dfinit la composition d'un panel d'une population et son
comportement, dans le but de fiabiliser des tudes statistiques, d'augmenter l'impact de
dmarches commerciales, etc...
Caractristiques fondamentales des modles

Le caractre abstrait d'un modle doit notamment permettre de faciliter la comprhension
du systme tudi: un modle rduit la complexit du systme tudi. Il doit aussi
permettre de simuler le systme tudi: un modle reprsente le systme tudi et reproduit
ses comportements. Un modle rduit (dcompose) la ralit, dans le but de disposer
d'lments de travail exploitables par des moyens mathmatiques ou informatiques: modle /
ralit ~ digital / analogique.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
4.2) Comment modliser avec UML ?

UML est un langage qui permet de reprsenter des modles, mais il ne dfinit pas le
processus d'laboration des modles! Cependant, dans le cadre de la modlisation d'une
application informatique, les auteurs d'UML prconisent d'utiliser une dmarche :
itrative et incrmentale,
guide par les besoins des utilisateurs du systme,
centre sur l'architecture logicielle.
D'aprs les auteurs d'UML, un processus de dveloppement qui possde ces qualits
devrait favoriser la russite d'un projet.
Une dmarche itrative et incrmentale ?

L'ide est simple : pour modliser (comprendre et reprsenter) un systme complexe, il
vaut mieux s'y prendre en plusieurs fois, en affinant son analyse par tapes. Cette dmarche
devrait aussi s'appliquer au cycle de dveloppement dans son ensemble, en favorisant le
prototypage. Le but est de mieux matriser la part d'inconnu et d'incertitudes qui caractrisent
les systmes complexes.
Une dmarche pilote par les besoins des utilisateurs ?

Avec UML, ce sont les utilisateurs qui guident la dfinition des modles : Le primtre du
systme modliser est dfini par les besoins des utilisateurs (les utilisateurs dfinissent ce
que doit tre le systme). Le but du systme modliser est de rpondre aux besoins de ses
utilisateurs (les utilisateurs sont les clients du systme). Les besoins des utilisateurs servent
aussi de fil rouge, tout au long du cycle de dveloppement (itratif et incrmental) : chaque
itration de la phase d'analyse, on clarifie, affine et valide les besoins des utilisateurs. A
chaque itration de la phase de conception et de ralisation, on veille la prise en compte des
besoins des utilisateurs. A chaque itration de la phase de test, on vrifie que les besoins des
utilisateurs sont satisfaits.
Une dmarche centre sur l'architecture ?

Une architecture adapte est la cl de vote du succs d'un dveloppement. Elle dcrit
des choix stratgiques qui dterminent en grande partie les qualits du logiciel (adaptabilit,
performances, fiabilit...). Ph. Kruchten propose diffrentes perspectives, indpendantes
et complmentaires, qui permettent de dfinir un modle d'architecture (publication
IEEE, 1995). Cette vue ("4+1") a fortement inspir UML :
___________________________________________________________________
8820448.doc
______________________________________________________________________________
Dfinir une architecture avec UML (dtail de la "vue 4+1")

La vue logique
Cette vue de haut niveau se concentre sur l'abstraction et l'encapsulation, elle modlise les
lments et mcanismes principaux du systme. Elle identifie les lments du domaine,
ainsi que les relations et interactions entre ces lments : les lments du domaine sont lis
au(x) mtier(s) de l'entreprise, ils sont indispensables la mission du systme, ils gagnent
tre rutiliss (ils reprsentent un savoir-faire). Cette vue organise aussi (selon des critres
purement logiques), les lments du domaine en "catgories" : pour rpartir les tches dans
les quipes, regrouper ce qui peut tre gnrique, isoler ce qui est propre une version
donne, etc...
La vue des composants

Cette vue de bas niveau (aussi appele "vue de ralisation"), montre : L'allocation des
lments de modlisation dans des modules (fichiers sources, bibliothques dynamiques,
bases de donnes, excutables, etc...). En d'autres termes, cette vue identifie les modules qui
ralisent (physiquement) les classes de la vue logique. L'organisation des composants, c'est--
dire la distribution du code en gestion de configuration, les dpendances entre les
composants... Les contraintes de dveloppement (bibliothques externes...). La vue des
composants montre aussi l'organisation des modules en "sous-systmes", les interfaces des
sous-systmes et leurs dpendances (avec d'autres sous-systmes ou modules).
La vue des processus

Cette vue est trs importante dans les environnements multitches ; elle montre : La
dcomposition du systme en terme de processus (tches); les interactions entre les processus
(leur communication); la synchronisation et la communication des activits parallles
(threads).
La vue de dploiement
Cette vue trs importante dans les environnements distribus, dcrit les ressources
matrielles et la rpartition du logiciel dans ces ressources : la disposition et nature physique
des matriels, ainsi que leurs performances, l'implantation des modules principaux sur les
nuds du rseau, les exigences en terme de performances (temps de rponse, tolrance aux
fautes et pannes...).
La vue des besoins des utilisateurs

Cette vue (dont le nom exact est "vue des cas d'utilisation"), guide toutes les autres.
Dessiner le plan (l'architecture) d'un systme informatique n'est pas suffisant, il faut le
justifier ! Cette vue dfinit les besoins des clients du systme et centre la dfinition de
l'architecture du systme sur la satisfaction (la ralisation) de ces besoins. A l'aide de
scnarios et de cas d'utilisation, cette vue conduit la dfinition d'un modle d'architecture
pertinent et cohrent. Cette vue est la "colle" qui unifie les quatre autres vues de
l'architecture. Elle motive les choix, permet d'identifier les interfaces critiques et force se
concentrer sur les problmes importants.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
Rsumons la dmarche...
Modliser une application ? Mais comme UML n'est pas un processus... Quelle dmarche
utiliser ? Trouver un "bon" modle est une tche difficile mais capitale !
1. Optez pour une approche itrative et incrmentale.
2. Centrez votre dmarche sur l'analyse des besoins des utilisateurs.
3. Prenez grand soin la dfinition de l'architecture de votre application (l'approche
"4+1" permet de mieux la cerner).
OK OK , mais en pratique ? ien qu'UML n'est pas un processus, il facilite une dmarche
d'analyse itrative et incrmentale, base sur les niveaux d'abstraction. Les niveaux
d'abstraction permettent de structurer les modles. Un micro-processus rgit les itrations
niveau d'abstraction constant. Un macro-processus rgit le passage de niveau niveau. Une
dmarche incrmentale consiste construire les modles de spcification et de conception en
plusieurs tapes (cible = catgories). Le schma ci-dessous montre les niveaux d'abstraction
principaux, qu'on peut identifier dans un processus de dveloppement logiciel :
Elaboration plutt que transformation

UML opte pour l'laboration des modles, plutt que pour une approche qui impose une
barrire stricte entre analyse et conception : Les modles d'analyse et de conception ne
diffrent que par leur niveau de dtail, il n'y a pas de diffrence dans les concepts utiliss.
UML n'introduit pas d'lments de modlisation propres une activit (analyse,
conception...); le langage reste le mme tous les niveaux d'abstraction. Cette approche
simplificatrice facilite le passage entre les niveaux d'abstraction. L'laboration encourage une
approche non linaire (les "retours en arrire" entre niveaux d'abstraction diffrents sont
facilits). La traabilit entre modles de niveaux diffrents est assure par l'unicit du
langage.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
Dtail des diffrents niveaux d'abstraction (phases du macro-processus)
Conceptualisation
L'entre de l'analyse ce niveau, est le dossier d'expression des besoins client. A ce niveau
d'abstraction, on doit capturer les besoins principaux des utilisateurs. Il ne faut pas chercher
l'exhaustivit, mais clarifier, filtrer et organiser les besoins ! Le but de la conceptualisation est
de dfinir le contour du systme modliser (de spcifier le "quoi"), de capturer les
fonctionnalits principales du systme, afin d'en fournir une meilleure comprhension (le
modle produit sert d'interface entre les acteurs du projet), de fournir une base la
planification du projet.
Analyse du domaine
L'entre de l'analyse ce niveau, est le modle des besoins clients (les "cas d'utilisation"
UML). Il s'agit de modliser les lments et mcanismes principaux du systme. On
identifie les lments du domaine, ainsi que les relations et interactions entre ces lments :
les lments du domaine sont lis au(x) mtier(s) de l'entreprise, ils sont indispensables la
mission du systme, ils gagnent tre rutiliss (ils reprsentent un savoir-faire). A ce stade,
on organise aussi (selon des critres purement logiques), les lments du domaine en
"catgories" : pour rpartir les tches dans les quipes, regrouper ce qui peut tre gnrique,
etc...
Analyse applicative
A ce niveau, on modlise les aspects informatiques du systme, sans pour autant rentrer
dans les dtails d'implmentation. Les interfaces des lments de modlisation sont dfinis
(cf. encapsulation). Les relations entre les lments des modles sont dfinies. Les lments
de modlisation utiliss peuvent tre propres une version du systme.
Conception
On y modlise tous les rouages d'implmentation et on dtaille tous les lments de
modlisation issus des niveaux suprieurs. Les modles sont optimiss, car destins tre
implments.
Activits des micro-processus d'analyse (niveau d'abstraction

constant)
A chaque niveau d'abstraction, un micro-processus rgit la construction des modles. UML
ne rgit pas les activits des micro-processus, c'est le principe d'abstraction qui permet
l'laboration itrative et incrmentale des modles. Exemple de micro-processus de
construction d'un modle :
identifiez les classes (d'objets) :
recherchez les classes candidates (diffrentes suivant le niveau d'abstraction) l'aide de
diagrammes d'objets (bauches), filtrez les classes redondantes, trop spcifiques ou vagues,
qui ne reprsentent qu'une opration ou un attribut, documentez les caractristiques des
classes retenues (persistances, nombre maximum d'instances, etc.).
identifiez les associations entre classes / interactions entre objets (instances) :
recherchez les connexions smantiques et les relations d'utilisation, documentez les
relations (nom, cardinalits, contraintes, rles des classes...), en spcification, filtrez les
relations instables ou d'implmentation, dfinissez la dynamique des relations entre objets
(les interactions entre instances de classes et les activits associes).
___________________________________________________________________
8820448.doc
______________________________________________________________________________
identifiez les attributs et les oprations des classes :

recherchez les attributs dans les modles dynamiques (recherchez les donnes qui
caractrisent les tats des objets), filtrez les attributs complexes (faites-en des objets) et au
niveau spcification, ne reprsentez pas les valeurs internes propres aux mcanismes
d'implmentation, recherchez les oprations parmi les activits et actions des objets (ne pas
rentrer dans le dtail au niveau spcification).
optimisez les modles :
choisissez vos critres d'optimisation (gnricit, volutivit, prcision, lisibilit,
simplicit...), utilisez la gnralisation et la spcialisation (classification), documentez et
dtaillez vos modles, encapsulez.
validez les modles :
vrifiez la cohrence, la compltude et l'homognit des modles, confrontez les
modles la critique (comit de relecture...).
Synthse de la dmarche
Modliser une application n'est pas une activit linaire.
Il s'agit d'une tche trs complexe, qui ncessite une approche :
itrative et incrmentale (grce aux niveaux d'abstraction), car il est plus efficace de
construire et valider par tapes, ce qui est difficile cerner et matriser,
centre sur l'architecture (dfinie par la vue "4+1"), car il s'agit de la cl de vote
qui conditionne la plupart des qualits d'une application informatique,
guide par la prise en compte des besoins des utilisateurs ( l'aide des cas
d'utilisation), car ce qui motive l'existence mme du systme concevoir, c'est la
satisfaction des besoins de ses utilisateurs.
4.3) Modlisation UML

Qu'est-ce qu'un modle ?
La modlisation consiste crer une reprsentation simplifie d'un problme: le modle.
Grce au modle il es possible de reprsenter simplement un problme, un concept et le
simuler. La modlisation comporte deux composantes:
L'analyse, c'est--dire l'tude du problme
la conception, soit la mise au point d'une solution au problme
Le modle constitue ainsi une reprsentation possible du systme pour un point de vue
donn.
La modlisation UML
Le mta-modle UML fournit une panoplie d'outils permettant de reprsenter l'ensemble
des) lments du monde objet (classes, objets, ...) ainsi que les liens qui les relie. Toutefois,
tant donn qu'une seule reprsentation est trop subjective, UML fournit un moyen astucieux
permettant de reprsenter diverses projections d'une mme reprsentation grce aux vues.
Une vue est constitu d'un ou plusieurs diagrammes.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
On distingue deux types de vues:

Les vues statiques, c'est--dire reprsentant le systme physiquement
diagrammes d'objets
diagrammes de classes
diagrammes de cas d'utilisation
diagrammes de composants
diagrammes de dploiement
Les vues dynamiques, montrant le fonctionnement du systme
diagrammes de squence
diagrammes de collaoration
diagrammes d'tats-transitions
diagrammes d'activits

Les cas d'utilisation

Les cas d'utilisation (en anglais use cases) permettent de reprsenter le fonctionnement du
systme vis--vis de l'utilisateur, c'est donc une vue du systme dans son environnement
extrieur.
Modlisation des classes et objets
o Modlisation d'un objet

La modlisation objet consiste crer une reprsentation abstraite, sous forme d'objets,
d'entits ayant une existence matrielle (arbre, personne, tlphone, ...) ou bien virtuelle
(scurit sociale, compte bancaire, ...). Un objet est caractris par plusieurs notions:
Les attributs (on parle parfois de proprits): Il s'agit des donnes caractrisant
l'objet. Ce sont des variables stockant des informations d'tat de l'objet
Les mthodes (appeles parfois fonctions membres): Les mthodes d'un objet
caractrisent son comportement, c'est--dire l'ensemble des actions (appeles
oprations) que l'objet est mme de raliser. Ces oprations permettent de faire
ragir l'objet aux sollicitations extrieures (ou d'agir sur les autres objets). De plus, les
oprations sont troitement lies aux attributs, car leurs actions peuvent dpendre des
valeurs des attributs, ou bien les modifier
L'identit: L'objet possde une identit, qui permet de le distinguer des autres objets,
indpendamment de son tat. On construit gnralement cette identit grce un
identifiant dcoulant naturellement du problme (par exemple un produit pourra tre
repr par un code, une voiture par un numro de srie, ...)
UML propose une manire de reprsenter les objets de faon graphique, sous forme de
rectangle, dans lequel le nom de l'objet est soulign.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
___________________________________________________________________
8820448.doc
______________________________________________________________________________
o Les attributs d'un objet

Les attributs (proprits) d'un objet reprsentent ses caractristiques. L'ensemble des
valeurs des attributs d'un objet constituent son tat. UML propose de reprsenter les attributs
d'un objet et les valeurs associes de la manire suivante:
o Les liens entre objets

Dans l'approche objet, les objets ne sont pas des corps inertes isols. Bien au contraire,
mme s'ils possdent leurs caractristiques propres par l'intermdiaire des valeurs de leurs
attributs (ce qui constitue ce que l'on appelle l'tat), ils ont la possibilit d'interagir entre-eux
grce leurs mthodes. UML propose de reprsenter les liens qui existent entre les objets
grce un trait continu.
Un lien existe ds lors qu'un objet possde une visibilit vis--vis d'un autre, c'est--dire
lorsqu'un objet a un rapport direct avec un autre (appartenance, utilisation, communication,
...). Il est de plus possible d'ajouter des commentaires sur le modle sous forme de notes. Une
note est reprsente par un rectangle dont le coin suprieur droit est repli. Pour relier une
note un objet il faut utiliser un trait discontinu (en pointills).
___________________________________________________________________
8820448.doc
______________________________________________________________________________
Modlisation d'une classe

On appelle classe la structure d'un objet, c'est--dire la dclaration de l'ensemble des
entits qui composeront un objet. Un objet est donc "issu" d'une classe, c'est le produit qui
sort d'un moule. En ralit on dit qu'un objet est une instanciation d'une classe, c'est la
raison pour laquelle on pourra parler indifframment d'objet ou d'instance (ventuellement
d'occurence).
Une classe est compose:
d'attributs: il s'agit des donnes, dont les valeurs reprsentent l'tat de l'objet
Les mthodes : il s'agit des oprations applicables aux objets
Si on dfinit la classe voiture, les objets Peugeot 406, Volkswagen Golf seront des
instanciations de cette classe. Il pourra ventuellement exister plusieurs objets Peugeot 406,
diffrencis par leur numro de srie.
Mieux: deux instanciations de classes pourront avoir tous leurs attributs gaux sans pour
autant tre un seul et mme objet (c'est la diffrence entre tat et identit). C'est le cas dans le
monde rel, deux T-shirts peuvent tre strictement identique (avoir le mme tat) et pourtant
ils sont distincts (ils ont chacun leur identit propre). D'ailleurs en les mlangeant il serait
impossible de les distinguer...
Une classe se reprsente avec UML sous forme d'un rectangle divis en trois sections. Le
premier contient le nom donn la classe (non soulign). Les attributs d'une classe sont
dfinis par un nom, un type (ventuellement une valeur par dfaut, c'est--dire une valeur
affecte la proprit lors de l'instanciation) dans le second compartiment. Les oprations
sont rpertories dans le troisime volet du rectangle.
La visibilit des attributs

L'un des principaux concepts du paradigme objet est l'encapsulation. L'encapsulation est un
mcanisme consistant rassembler les donnes et les mthodes au sein d'une structure en
cachant l'implmentation de l'objet, c'est--dire en empchant l'accs aux donnes par un
autre moyen que les services proposs. L'encapsulation permet donc de garantir l'intgrit
des donnes contenues dans l'objet.
En effet, la programmation oriente objet permet de cacher l'implmentation dun objet en
ne lui permettant d'accder aux attributs uniquement par l'intermdiaire de mthodes cres
cet effet (on parle d'interface). Il est ainsi possible de dfinir des niveaux d'encapsulation, afin
de dfinir le type de classe ayant accs aux attributs.
On parle de niveau de visibilit des lments de la classe. Ces niveaux de visibilit
dfinissent les droits d'accs aux donnes selon que l'on y accde par une mthode de la
classe elle-mme, d'une classe hritire, ou bien d'une classe quelconque. Il existe trois
niveaux de visibilit.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
publique: Les fonctions de toutes les classes peuvent accder aux donnes ou aux
mthodes d'une classe dfinie avec le niveau de visibilit public. Il s'agit du plus bas
niveau de protection des donnes
protge: l'accs aux donnes est rserv aux fonctions des classes hritires, c'est-
-dire par les fonctions membres de la classe ainsi que des classes drives
prive: l'accs aux donnes est limit aux mthodes de la classe elle-mme. Il s'agit
du niveau de protection des donnes le plus lev
La notation UML permet de reprsenter le niveau de visibilit des attributs de faon

graphique en faisant prcder le nom de chaque attribut par un caractre reprsentant la
visibilit:
+ dfini un attribut public
# dfini un attribut protg
- dfini un attribut priv
___________________________________________________________________
8820448.doc
______________________________________________________________________________
Introduction au
langage UML
___________________________________________________________________
8820448.doc
______________________________________________________________________________
UP - LE PROCESSUS UNIFI 5
I. LE PROCESSUS DE DVELOPPEMENT : NOUVELLE APPROCHE 5
II. LE PROCESSUS UNIFI : CADRE GNRAL 6
III. LE PROCESSUS UNIFI EST PILOT PAR LES CAS DUTILISATION 6
3.1) Prsentation 6
3.2) Exemple: guichet de banque 6
IV. LE PROCESSUS UNIFI EST CENTR SUR LARCHITECTURE 8
4.1) Liens entre cas dutilisation et architecture ? 8
4.2) Marche suivre : 8
V. LE PROCESSUS UNIFI EST ITRATIF ET INCRMENTAL 8
5.1) Avantages dun processus itratif contrl 9
VI. LE CYCLE DE VIE DU PROCESSUS UNIFI 9
6.1) Prsentation du cycle de vie de UP 10
6.2) Exemple sur les diffrents modles 11
a) Diagramme de cas d'utilisation: 11
b) Modle d'analyse: ralisation d'un cas d'utilisation 12
c) Diagramme de collaboration 12
VII. CONCLUSION : UN PROCESSUS INTGR 12
APPROCHE DU LANGAGE UML 17

I. LES MTHODES OBJET ET LA GENSE D'UML 17
1.1) Mthodes ? 17
1.2) A quoi sert UML ? 18
1.3) Les points forts d'UML 20
1.4) Les points faibles d'UML 20
II. CARACTRISTIQUES DE LA MTHODE UML 21
2.1) UML est bas sur un mta-modle 21
2.2) UML: visualisation complte d'un systme 21
III. INTRODUCTION LA NOTATION UML 22
3.1) La notion d'objet 22
3.2) Les mthodes objet 22
3.3) Intrt d'une mthode objet 22
3.4) La normalisation OMG 23
IV. MODLISER AVEC UML 24
4.1) Qu'est-ce qu'un modle ? 24
Un modle est une abstraction de la ralit 24
Un modle est une vue subjective mais pertinente de la ralit 24
Quelques exemples de modles 24
Caractristiques fondamentales des modles 24
4.2) Comment modliser avec UML ? 25
Une dmarche itrative et incrmentale ? 25
Une dmarche pilote par les besoins des utilisateurs ? 25
Une dmarche centre sur l'architecture ? 25
Dfinir une architecture avec UML (dtail de la "vue 4+1") 26
Rsumons la dmarche... 27
Dtail des diffrents niveaux d'abstraction (phases du macro-processus) 28
Activits des micro-processus d'analyse (niveau d'abstraction constant) 28
___________________________________________________________________
8820448.doc
______________________________________________________________________________
Synthse de la dmarche 29
4.3) Modlisation UML 29
Qu'est-ce qu'un modle ? 29
La modlisation UML 29
Les cas d'utilisation 30
Modlisation des classes et objets 30
Modlisation d'une classe 33
La visibilit des attributs 33
INTRODUCTION AU LANGAGE UML 39

I. LES CAS DUTILISATION 39
1.1) Objectifs des cas dutilisation 39
1.2) lments constitutifs des cas dutilisation 40
Exemple : Diagramme de cas dutilisation dun guichet automatique bancaire 40
1.3) Description des cas dutilisation 41
a) Exemple : Cas dutilisation Retirer de largent 41
b) Exemple : scnario du cas dutilisation :Retirer de largent ; retrait autoris 41
1.4) Structuration des cas dutilisation 43
a) La relation dinclusion : 43
b) La relation dextension 44
c) Relation de gnralisation entre cas dutilisation 44
1.6) Notion de paquetage 45
1.7) Exercice TVServices (parties I et II) 45
Partie 1: Diagramme de cas d'utilisation - vue de l'administrateur 45
Partie II: Diagramme de cas d'utilisation - vue de l'utilisateur 48
II. LE DIAGRAMME DE CLASSES 50
2.1) Les classes 50
a) Dfinition 50
b) Reprsentation 50
c) Syntaxe 51
d) Oprations 51
2.2) Les associations 51
a) Arit des associations 52
b) Rle 52
c) Identification des associations 52
d) Identification des rles 52
e) Multiplicit des associations 53
f) Les classes associations : 54
g) Agrgation 54
h) La composition 55
i) Gnralisation : 55
III. LE DIAGRAMME DE COLLABORATION 56
3.1) Interaction 56
3.2) De nouveaux strotypes de classe 56
3.3) Les Messages : 58
3.4) Exercice TVServices (parties III et IV) 60
Partie III: Diagramme de classe mtier pour le cas d'utilisation regarder 61
Partie IV: Diagramme de collaboration d'un scnario du cas d'util. regarder 62
3.5) TP de synthse: Cration d'un site Web 63
a) L'adhsion: 63
b) La publication des articles: 63
c) La vente des ouvrages: 63
___________________________________________________________________
8820448.doc
______________________________________________________________________________
___________________________________________________________________
8820448.doc
______________________________________________________________________________
INTRODUCTION AU LANGAGE UML
UML est un langage de modlisation avec plusieurs objectifs qui en font un vritable outil
de communication:
- Comprendre et dcrire les besoins,
- Spcifier (un systme),
- Etablir l'architecture logicielle.
Les diagrammes d'UML vont mettre en place deux parties:
Statique (structure) Dynamique (comportement)

Diagramme de cas d'utilisation Diagramme de collaboration
Diagramme de classe Diagramme de squence
Diagramme objet Diagramme tat/ transition
Diagramme de composants Diagramme d'activits
Diagramme de dploiement
I. Les cas dutilisation

1.1) Objectifs des cas dutilisation
Les cas dutilisation sont une technique de description du systme tudi privilgiant le
point de vue de lutilisateur. Il sagit de la solution UML pour reprsenter le modle
conceptuel. Les cas dutilisation dcrivent sous la forme dactions et de ractions, le
comportement dun systme du point de vue dun utilisateur. Les cas dutilisation servent
structurer les besoins des utilisateurs et les objectifs correspondants du systme.
Un cas dutilisation est une manire spcifique dutiliser un systme. Cest limage
dune fonctionnalit du systme, dclenche en rponse la stimulation dun acteur
externe.
Les cas dutilisation apportent une solution au problme de la dtermination et de la

comprhension des besoins. En effet frquemment, des besoins se contredisent, des oublis et
des imprcisions sont raliss et ainsi lanalyse du systme part sur de mauvaises bases. Les
cas dutilisation recentrent lexpression des besoins sur les utilisateurs en partant du principe
quun systme est avant tout construit pour ses utilisateurs. Les cas dutilisation permettent
aux utilisateurs de structurer et darticuler leurs dsirs ; ils les obligent dfinir la manire
dont ils voudraient interagir avec le systme, prciser quelles informations ils entendent
changer et dcrire ce qui doit tre fait pour obtenir le rsultat escompt.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
1.2) lments constitutifs des cas dutilisation
Cas
d'utilisation
Acteur
Acteur : entit externe qui agit sur le systme ; Le terme acteur ne dsigne pas
seulement les utilisateurs humains mais galement les autres systmes. les acteurs
sont des classificateurs qui reprsentent des rles au travers d'une certaine
utilisation (cas) et non pas des personnes physiques. Ce sont des acteurs types.
Cas dutilisation : ensemble dactions ralises par le systme en rponse une

action dun acteur.
- les cas dutilisation peuvent tre structurs,
- les cas dutilisation peuvent tre organiss en paquetages,
- lensemble des cas dutilisation dcrit les objectifs du systme.
Exemple : Diagramme de cas dutilisation dun guichet automatique bancaire
guichet
Retirer de l'argent
Client de la banque
Dposer de l'argent
effectuer des virements entre comptes
Consulter solde compte

Employ de caisse
Ravitailler distributeur
Rparer le distributeur
Agent de maintenance
___________________________________________________________________
8820448.doc
______________________________________________________________________________
1.3) Description des cas dutilisation

Un cas dutilisation spcifie une squence dinteractions, avec ses variantes, entre les
acteurs et le systme, produisant un rsultat satisfaisant pour un acteur particulier. . On peut
donc considrer un cas dutilisation comme une abstraction de plusieurs chemins dexcution
dune utilisation du systme. Pour dcrire un cas dutilisation, il nous faut dcrire un
maximum de chemins dexcution possibles pour la squence dactions correspondant ce
cas. On tudiera donc un certain nombre de scnarios dun cas dutilisation.
Un scnario est donc une instance de cas dutilisation, un flot d'vnement.
A chaque fois quune instance dun acteur dclenche un cas dutilisation, un scnario est
cr : ce scnario suivra un chemin particulier dans la description dun cas dutilisation. Un
scnario ne contient pas de branche du type si la condition X est vraie alors faire Y , car
pendant lexcution la condition est soit vraie, soit fausse mais elle aura toujours une valeur.
Bien sr il est impossible de dcrire un cas dutilisation en crivant tous les scnarios,
lexhaustivit est difficile atteindre, mais il faut rpertorier les scnarios les plus
reprsentatifs afin de grer les risques. On recherchera donc le ou les scnarios nominaux et
les principaux cas dexceptions.
Nous aurons donc deux niveaux de description :

- Description gnrale dun cas dutilisation reprenant les divers chemins
pouvant tre runis en un mme cas.
- Description des scnarios les plus pertinents.
a) Exemple : Cas dutilisation Retirer de largent

1- Le client de la banque sidentifie
2- Le systme lui propose les diffrents comptes sur lesquels il peut effectuer un retrait
3- Le client choisit le compte dbiter et spcifie le montant du retrait
4- Le systme vrifie si le retrait est autoris, si oui il dduit le montant du compte et
dlivre largent, sinon il renvoie un message de rejet de lopration
b) Exemple : scnario du cas dutilisation :Retirer de largent ; retrait

autoris
Acteur dclencheur : M. Martin
Ce scnario commence par

1- M. Martin sidentifie
2- Le systme lui propose les diffrents comptes sur lesquels il peut effectuer un retrait
3- M. Martin choisit son compte chque et demande 200F
/*Le systme vrifie que le retrait est autoris*/
4- Le systme dlivre deux billets de 100F et demande ce que M. Martin les saisisse.
Ce scnario se termine par
___________________________________________________________________
8820448.doc
______________________________________________________________________________
5- M. Martin prend largent.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
1.4) Structuration des cas dutilisation

Aprs avoir identifi les acteurs et les cas dutilisation, il est utile de restructurer
lensemble des cas dutilisation que lon a fait apparatre afin de rechercher les
comportements partags, les cas particuliers et les gnralisations.
Les relations possibles entre cas dutilisation : UML dfinit trois types de relations
standardises entre cas dutilisation, dtailles ci-aprs :
- Une relation dinclusion : formalise par la dpendance include
- Une relation dextension : formalise par la dpendance extend
- Une relation de gnralisation / spcialisation
Etapes de construction:
1. Les acteurs
2. Pour chaque acteur, recherche des cas d'utilisation,
3. Structuration des cas d'utilisation pour faire apparatre les comportements partags
(relation d'inclusion), les cas particuliers ou options (relation d'extension), les
gnralisations / spcialisations.
a) La relation dinclusion :
Lors de la description des cas dutilisation, il apparat quil existe des sous-ensembles
communs plusieurs cas dutilisation, il convient donc de factoriser ces fonctionnalits en
crant de nouveaux cas dutilisation qui seront utiliss par les cas dutilisation qui les avaient
en commun.
Un cas dutilisation A utilise un cas dutilisation B signifie que :
- une instance de A va engendrer une instance de B et lexcuter,
- A dpend de B,
- B nexiste pas tout seul et A nexiste pas sans B
Exemple :
Retirer de
largent include
Dposer de include
largent Sauthentifier
include
Effectuer des virements
include
Consulter solde
Les cas de base Dposer de largent , Retirer de largent , Effectuer des virements
entre comptes et Consulter solde incorporent de faon explicite le cas dutilisation
Sauthentifier , un endroit spcifi dans leurs enchanements.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
Remarquez que dans une relation include , le cas dutilisation de base utilise
systmatiquement les enchanements provenant du cas inclus.
On utilise cette relation pour viter de dcrire plusieurs fois un mme enchanement
dactions. Ainsi on est amen factoriser un comportement commun plusieurs cas
dutilisation dans un cas dutilisation part.
b) La relation dextension
La relation strotype <<extend>> permet d'tendre les interactions et donc les

fonctions dcrites par les interactions. Le cas de base peut fonctionner tout seul, mais il peut
galement tre complt par un autre, sous certaines conditions, et uniquement certains
points particuliers de son flot dvnements (point dinsertion). On utilise principalement
cette relation pour sparer le comportement optionnel (les variantes) du comportement
obligatoire.
Considrons lexemple : le cas dutilisation B tend le cas dutilisation A signifie que :

- Une instance de A va engendrer une instance de B et lexcuter sous
certaines conditions, B sait o sinsrer dans A.
- B connat A et non linverse, cest dire que B dpend de A
- B nexiste pas tout seul et A existe sans B
La relation <<extend>> montre une possibilit d'excution d'interactions qui

augmenteront les fonctionnalits du cas tendu, mais de faon optionnelle, non obligatoire,
alors que la relation <<include>> suppose une obligation dexcution des interactions.
Exemple :
extend
Retenir carte
Sauthentifier
c) Relation de gnralisation entre cas dutilisation
La relation d'hritage ou de gnralisation entre cas est plus subtile. La version 1.1 de
UML ne distinguait d'ailleurs pas <<extend>> et gnralisation. Cette relation est prendre
au sens classique de spcialisation, inhrent 'hritage. Ici, la gnralisation peut tre vue
aussi comme un "polymorphisme" de cas.
Exemple : Dans un systme dagence de voyage
Rserver
voyage
Rserver voyage par Rserver voyage par

tlphone Internet
___________________________________________________________________
8820448.doc
______________________________________________________________________________
Dans un systme d'agence de voyage, un acteur touriste peut participer un cas de base qui
est "Rserver voyage", qui suppose par exemple des interactions basiques au comptoir de
l'agence. Une rservation peut aussi tre ralise par tlphone ou internet. On voit qu'il ne
s'agit pas de relation <<extend>> car la rservation par Internet n'tend pas les interactions ni
les fonctionnalits du cas 'Rserver voyage". Elle les traduit diffremment. Les interactions
Internet ne sont pas une option des interactions comptoir. Par contre les deux cas "Rserver
voyage" et "Rserver voyage par Internet" sont lis : la rservation par Internet est un cas
particulier de rservation. De faon gnrale en objet, une situation de cas particulier se
traduit par une relation de gnralisation.
ATTENTION : On peut galement gnraliser les acteurs
1.6) Notion de paquetage

Les modles UML produits dans le cadre dun projet sont parfois dune superficie trop
importante pour tre facilement utiliss. La notion de paquetage ou package est une
technique qui permet de mettre en uvre ce partitionnement des modles tout en prservant
la cohrence de lensemble.
Un paquetage est un ensemble dlments de modlisation : des classes, des associations,
des objets, des composants. Dans le cas du guichet bancaire on pourrait faire deux
diagrammes de cas dutilisation, un pour le paquetage utilisation du guichet et un autre pour
le paquetage maintenance.
1.7) Exercice TVServices (parties I et II)

TVServices est une socit qui met disposition de ses clients un ensemble de services
relatifs la tlvision (accs des chanes thmatiques, contrle des utilisations et des
utilisateurs, programme lectronique dtaill des chanes accessibles...). Ces services sont
commercialiss sous le nom d' IntelliTl
Chaque client dispose d'un botier lectronique situ entre l'antenne satellite et
l'installation de tlvisualisation (crans, magntoscopes...). C'est cet quipement
intermdiaire, appel ci-aprs "botier 'NS", constamment en veille et reli au rseau
tlphonique, qui permet au client: le paiement des services par carte bancaire, et le
dcodage des images reues.
Et TVServices, la diffusion automatique des programmes et magazines lectroniques (et
des publicits ;-); en chargeant les mmoires des botiers avec les programmes et magazines,
et l'autorisation d'accs aux services; TVS mmorise les informations relatives aux
autorisations d'accs aux services (fonction des paiements reus) dans les botiers.
Partie 1: Diagramme de cas d'utilisation - vue de l'administrateur

Voici un extrait de la brochure commerciale proposant les contrats 'IntelliTl'
Une fois le contrat sign et l'abonnement aux services de votre choix pay vous recevrez
par l'intermdiaire d'un installateur agr, un "botier TVS" prprogramm avec les
autorisations d'accs correspondant votre contrat.
Lors de l'installation, un compte "administrateur" (typiquement, pour une installation
familiale, un des parents) est cr qui aura pour tche de dclarer les futurs utilisateurs du
systme (identificateur et mot de passe) ainsi que d'administrer leurs droits (types d'mission
___________________________________________________________________
8820448.doc
______________________________________________________________________________
autoriss, plages horaires autorises, dure maximale hebdomadaire de visualisation
autorise appele "crdit hebdomadaire").
Travail faire:
I.l) Expliquer le diagramme ci-dessous par un texte dcrivant les informations qu'il contient
en les contextualisant dans le cadre de TVServices (deux sens possibles, ambigut ).
Voici une description possible du diagramme propos:

L'accs aux fonctions d'administration est protg, le contrle s'effectuant sur
l'identificateur et le mot de passe de l'administrateur. Ce qui explique que l'excution du cas
d'utilisation 'Administrer' ncessite celle du cas d'utilisation 'ContrleAccsUtil', dont
l'excution ncessite celle du cas d'utilisation 'Identifier'.
Le dcoupage fonctionnel de l'administration en cration des utilisateurs, contrle d'accs
des utilisateurs... ne me semble pas pertinent ce niveau de description avec l'approche 'cas
d'utilisation'.
I.2) Quel peut-tre l'intrt de sparer les cas d'utilisation "ContrleAccsUtil" et "Identifier"
du cas d'utilisation "Administrer"?
Il peut y avoir intrt sparer les cas d'utilisation "ContrleAccsUtil" et "Identifier" du

cas d'utilisation "Administrer" si les deux premiers sont utiliss par ('inclus dans') d'autres cas
d'utilisation; on les a en quelque sorte factoriss.
I.3) Reprsenter par un fragment de diagramme de cas d'utilisation le fait que parmi les
acteurs sollicitant le systme, "Client" et "Administrateur" sont tous deux "Utilisateur".
Utilisateur
___________________________________________________________________
8820448.doc
______________________________________________________________________________
Client Administrateur
___________________________________________________________________
8820448.doc
______________________________________________________________________________
Partie II: Diagramme de cas d'utilisation - vue de l'utilisateur

Voici un extrait de la description faite ci-dessous par un des premiers clients:
Une "IntelliTl" est un tlviseur-enregistreur, elle (ou 'il' je ne sais pas...) permet de
regarder des missions tldiffuses, et aussi de les enregistrer. C'est un systme qui, via un
rseau, connat les possibilits pour lesquelles on a pay. Par exemple, on peut acheter des
droits de rception de certaines chanes payantes ou s'abonner un service qui envoie
rgulirement une analyse dtaille des programmes des principales chanes.
Pour utiliser une "IntelliTl", on dispose d'un terminal, comme une tlcommande, avec
un petit cran tactile, qu'on manipule avec un stylet. Dans ce terminal on peut glisser si
ncessaire une carte puce, par exemple pour payer un service.
Pour pouvoir utiliser "l'IntelliTl", il faut s'identifier. Un utilisateur autoris dispose de
droits ; c'est moi qui ai dfini les droits d'accs des enfants. Je leur ai interdit des plages
horaires et certaines chanes. Il me reste interdire certains types de programme (je sais que
c'est possible car ils disent que le botier connat la catgorie de chaque mission). Mais c'est
vrai je ne vous ai pas encore parl du botier; tenez, voici la prsentation de
TVServices, la socit qui commercialise "L'IntelliTl",... (Voir la partie I).
Travail faire:
En imaginant utiliser une IntelliTl comme vous le faites (peut-tre) de votre rcepteur
TV/magntoscope, et en tenant compte de la description ci-dessus, produire un diagramme de
cas d'utilisation de l'IntelliTl vu de l'utilisateur acteur gnrique comme dfini en 1.3.
ci-avant.
Scnario du cas d'utilisation: Utiliser la TV; Enregistrement direct.

Acteur dclencheur: Mr Martin
Ce scnario commence par:
1. Mr Martin s'identifie
/* Le systme lui donne l'autorisation d'accs */
2. Mr Martin dcide d'enregistrer une mission sur M6 en direct
3. Mr Martin teint la TV
Scnario du cas d'utilisation: Utiliser la TV; Accs une chane refuse.

Acteur dclencheur: Mr Martin
1. Mr Martin s'identifie
2. Mr Martin dcide de regarder une mission d'informations sur France3
3. Le systme lui indique qu'il n'a pas les droits d'accs sur cette chane.
4. Mr Martin teint la TV
Scnario du cas d'utilisation: Utiliser la TV; Crdit de temps restant de 5 minutes.

Acteur dclencheur: La fille de Mr Martin
1. La fille de Mr Martin s'identifie
2. Le systme la reconnat et lui affiche qui ne lui reste que 5 minutes de crdit
3. Elle choisit de regarder un dessin anim
4. au bout de 5 minutes, la TV s'teint toute seule.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
U M L_ D IG A LLO
C ont rler au t oris at ion

< < include> >
< < inclu de> >

U t ilis er < < in clude> >
Ident ifier
C o nt rler A ccs
U t ilis at eur
< < include> >
R egarder m is s ion C o ns ult er m agaz ine C on s ult er lis t e im m diat em ent dis p on ible
C o ns ult er s on com p t e < < include> >

< < ext end> >
Enregis t er m is s io n A dm inis t rer
C ons ult er droit s init iaux
< < include> >

< < ext end> >
C ons ult er s olde

Enregis t rer en direct P rogram m at ion en regis t rem ent
___________________________________________________________________
8820448.doc
______________________________________________________________________________
II. Le diagramme de classes

Les diagrammes de classes expriment de manire gnrale la structure statique dun
systme, en termes de classes et de relations entre ces classes. Une classe permet de dcrire
un ensemble dobjets (attributs et comportement), tandis quune relation ou association
permet de faire apparatre des liens entre ces objets. On peut donc dire :
- un objet est une instance de classe,
- un lien est une instance de relation
Le diagramme de classe est un modle permettant de dcrire de manire abstraite et

gnrale les liens entre objets.
UML permet de dfinir trois types de strotypes pour les classes :

a) les classes frontire (interface): classes qui servent modliser les interactions
entre le systme et ses acteurs.
b) les classes contrle : classes qui servent reprsenter la coordination, le
squencement, les transactions et le contrle dautres objets.
c) les classes entit : classes qui servent modliser les informations durables et
persistantes.
Dans un premier temps cest cette dernire catgorie de classes que nous allons nous
intresser. Le diagramme de classe va tre un outil nous permettant de reprsenter le modle
du domaine. Le modle du domaine saisit les lments les plus importants pour comprendre
le contexte du systme :
- les objets mtiers (mis en uvre dans une activit professionnelle tels que les
commandes, les contrats..) ,
- les concepts du domaine modliser dont le systme doit garder une trace,
- les vnements stant produits ou devant se produire qui dclencheront un
certain comportement des objets.
2.1) Les classes

a) Dfinition
Description dun ensemble dobjets partageant la mme smantique, ainsi que les mmes
attributs, oprations et relations.
b) Reprsentation
Nom de la classe
Attributs
Oprations
___________________________________________________________________
8820448.doc
______________________________________________________________________________
Exemple :
VEHICULE
Marque
Modle
Immatriculation
Niveau du carburant
..
Acclrer()
Vidanger()
Une classe correspond un concept global dinformation et se compose dun ensemble
dinformations lmentaires, appeles attributs de la classe qui servent la dcrire.
UML dfinit trois niveaux de visibilit pour les attributs et les oprations :
Public qui rend llment visible tous les clients de la classe,
Protg qui rend llment visible aux sous classes de la classe,
Priv qui rend llment visible la classe seule.
Un attribut est caractris par un nom et par un format.
c) Syntaxe
Nom_attribut : type_attribut = valeur_par_dfaut
Dans un premier temps on ne retiendra comme attribut que des donnes non calcules,
cependant par commodit de gestion on pourra garder des attributs pouvant tre construits
partir dautres attributs (on rajoutera / devant lattribut dit driv).
d) Oprations
La dfinition dune classe est complte par lensemble des oprations quelle peut
excuter. Une opration est une fonctionnalit assure par la classe.
Le niveau de dtail retenir pour dcrire les oprations est fonction du niveau
davancement de ltude.
2.2) Les associations

Une association reprsente une relation structurelle entre classes dobjets. La plupart des
associations sont binaires, cest dire quelles connectent deux classes. On reprsente une
association en traant une ligne entre les classes associes.
A B
___________________________________________________________________
8820448.doc
______________________________________________________________________________
a) Arit des associations

On appelle arit dune association le nombre de classes qui participent lassociation.
Il arrive en effet que linformation que lon veut reprsenter ncessite la mise en relation
de plus de deux classes. Ces associations naires peuvent se reprsenter au moyen dun
losange sur lequel arrivent les diffrents brins de lassociation.
Exemple : ENSEIGNANT
ETUDIANT SALLE
COURS
DateDbut
DateFin
b) Rle
Les extrmits dune association sont appeles rles et peuvent porter un nom. Le rle
dcrit comment une classe voit une autre classe au travers dune association.
c) Identification des associations

Les associations peuvent tre nommes afin de faciliter la comprhension des modles. Il
est dusage de nommer les associations par une forme verbale. On peut galement prciser le
sens de lecture par le biais dun petit triangle dirig vers la classe dsigne par la forme
verbale.
CLIENT Passer > COMMANDE
d) Identification des rles

Un rle est nomm au moyen dune forme nominale.
SOCIETE Employeur PERSONNE
Employ
On utilise rarement les deux modes de description dassociation simultanment, mais on

cherche celui le plus adapt la situation dcrire.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
e) Multiplicit des associations

Chaque rle peut porter une multiplicit montrant combien dobjets de la classe
considre (celle qui joue ce rle) peuvent tre lis une instance de lautre classe par
lassociation. La multiplicit est reprsente sous la forme dun couple de cardinalits.
1..1 not 1 Un et un seul

0..1 Zro ou un
0..* not * De Zro n
1..* De un n
n..m De n m
o Exercice 2 : Lecture de multiplicit
GARAGE
LOCATAIRE
1
1
1..* 1..*
louer CONTRAT
BOX
1 0..1
1..* Autoriser
0..2 VEHICULE
Travail faire :
Faites une description de ce diagramme de classe en explicitant en une phrase chacune des
multiplicits.
Un box peut tre lou par au maximum un seul contrat ou peut rester non lou.
Un contrat concerne la location d'un seul box la fois.
Un box peut tre vide ou contenir au maximum 2 vhicule.
Un vhicule est autoris aller dans un box (au minimum) ou plus.
Un contrat ne concerne qu'un seul locataire.
Un locataire peut souscrire plusieurs contrat mais doit en avoir souscrit au moins un.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
f) Les classes associations :
Il peut arriver que lon ait besoin de garder des informations (attributs ou oprations)
propres une association. Une classe de ce type est appele classe association.
Exemple :
COMMANDE 1..* 1..* PRODUIT
LIG-COM LIVRAISON
1..* 1
Quantit
Ici, NumCommande + RfProduit Quantit
Une classe association est une classe comme une autre qui peut entretenir des relations
avec dautres classes
g) Agrgation
Une agrgation est un type particulier dassociation. Elle traduit la volont de renforcer la
dpendance entre les classes. Cest une association non symtrique dans laquelle une des
extrmits joue un rle prdominant par rapport lautre extrmit.
Les critres suivants impliquent une agrgation :

- une classe fait partie dune autre classe,
- une action sur une classe implique une action sur une autre classe,
- les objets dune classe sont subordonns aux objets dune autre classe.
Attention : linverse nest pas toujours vrai ; lagrgation nimplique pas ncessairement
tous les critres ci-dessus.
1 1..*
GARAGE BOX
Un agrgat peut tre multiple.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
h) La composition
La composition est un cas particulier dagrgation dans laquelle la vie des composants est
lie celle de lagrgat. Dans la composition, lagrgat ne peut tre multiple. La
composition se reprsente par un losange noir.
C om m u n e
1 1 1
1..* 1 ..* 1 ..*
M ai ri e C on s e i l M u n i ci pal S e rvi ce
Une composition est une association contraignante : la suppression dun objet agrgat
entrane la suppression des objets agrgs.
i) Gnralisation :
UML emploie le terme de gnralisation pour dsigner la relation de classification entre
un lment plus gnral et un lment plus spcifique. La relation de gnralisation
signifie est un ou est une sorte de .
Instrument
+Nom Instrument : undefined

+Date fabrication : undefined
Instrument cordes Instrument vent
+Nombre de cordes : undefined +Nombre de pistons : undefined
La classe Instrument est une classe gnrique, elle porte les attributs communs tous les
instruments. La classe Instrument cordes est une classe spcialise qui porte les attributs
spcifiques ce type dinstrument.
Une classe spcialise peut avoir des relations avec dautres classes.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
III. Le diagramme de collaboration

Nous avons jusqu prsent tudi la statique (la structure) du systme modliser
travers le diagramme des cas dutilisation et le diagramme de classe. Nous allons maintenant
passer ltude de la dynamique (le comportement) du systme. Pour cela nous allons
chercher mettre en vidence les interactions entre objets, ainsi que les messages changs.
Le diagramme de collaboration permet de mettre en vidence les interactions entre les
diffrents objets du systme tudi, ainsi que les messages quils changent entre eux.
3.1) Interaction
La squence dactions dun scnario dun cas dutilisation dbute lorsquun acteur
invoque ce cas dutilisation en envoyant une forme quelconque de message au systme. En
fait ce nest pas le systme dans son ensemble qui va recevoir le message mais un objet
frontire (ou interface). Lobjet frontire va envoyer son tour un message un autre objet,
de sorte que les objets concerns vont dialoguer pour raliser ce cas dutilisation ou plus
prcisment un scnario de ce cas dutilisation.
A laide du diagramme de collaboration, nous illustrons donc linteraction entre objets en

crant des liens entre ces objets et en associant des messages ces liens. Le nom dun
message doit voquer lintention de lobjet appelant lors de linteraction avec lobjet associ.
3.2) De nouveaux strotypes de classe

Ce diagramme de collaboration va nous permettre de complter le modle danalyse
commenc avec le diagramme de classe en ajoutant de nouvelles classes. Dans une premire
version du diagramme de classe nous nous sommes limits ltudes des classes entits.
Nous allons voir laide du diagramme de collaboration quil est ncessaire davoir recours
dautres types de classes pour grer les interactions entre objets du systme :
- Les classes frontires (ou interfaces) : servent modliser les interactions
entre le systme et ses acteurs ;
- Les classes de contrle : ces classes encapsulent souvent le contrle li un
cas dutilisation, ce qui implique quun objet de contrle est cr au
dmarrage dune instance de cas dutilisation et prend fin lissue de ce
scnario. Il y a nanmoins des exceptions : lorsquun objet de contrle
participe la ralisation de plusieurs cas dutilisation, lorsque plusieurs objets
de contrle (issus de diffrentes classes de contrle) participent la ralisation
du cas dutilisation, et enfin lorsquune ralisation de cas dutilisation ne
ncessite aucun objet de contrle.
Un diagramme de collaboration permet de dcrire les interactions entre objets

intervenant dans la ralisation dun scnario dun cas dutilisation.
___________________________________________________________________
Exemple : Utilisation dun diagramme de collaboration pour dcrire la ralisation du scnario retrait autoris du cas dutilisation
retirer de largent
IntGuichet/:IGuichetAccueil 2:DemanderAutorisation(Code)
Contrleur1/:CAutorisation
1:Identifier(Code)
4:AutoriserCration(ListeComptes) 3:[ContrleOK]ObtenirListe()
5:ChoixCompteMontant(Compte,Montant)
IntChoixMontant/:IGuichetMontant
ComptesMartin/:Compte
M. Martin/:Client de la banque
6:DemanderRetrait(Compte, Montant)
CompteClient/:Compte
9:DlivrerArgent()
7:ValiderEtEffectuerRetrait()
Contrleur2/:CRetrait Multi-objet
8:AutoriserRetrait(montant)
IntDistributeur/:Idistributeur
Le diagramme de collaboration peut tre complt par du texte dcrivant de quelle faon les objets dialoguent pour effectuer le scnario du
cas dutilisation. Cest une description de scnario un peu plus prcise.
Exemple : scnario du cas dutilisation :Retirer de largent ; retrait autoris
Acteur dclencheur : M. Martin
Ce scnario commence par

1. M. Martin active lobjet Interface Guichet et sidentifie
2. Linterface Guichet demande au contrleurAutorisation si le code est valide. Cest le cas, le contrleurAutorisation demande les comptes
de M. Martin (le message est donc envoy plusieurs objets et non un seul.) Il demande ensuite la cration dune instance de
linterface IguichetMontant IntChoixMontant prsentant la liste des comptes de M.Martin et demandant le montant.
3. M. Martin choisit son compte chque et demande 200F (message envoy lobjet IntChoixMontant)
/*Le systme vrifie que le retrait est autoris*/
4. LObjet IntChoixMontant transmet la demande de retrait du compte et du montant choisis par M. Martin un deuxime objet contrleur
charg de vrifier que M. Martin peut retirer cet argent sur son compte. Lobjet contrleur2 confirme en demandant lobjet
CompteClient de valider la requte et, si celle-ci est correcte, de dbiter le compte. Lobjet contrleur2 autorise ensuite lobjet
IntDistributeur dlivrer le montant demand par M. Martin. Enfin M. Martin reoit le montant demand.

5. M. Martin prend largent.
3.3) Les Messages :

Les messages sont les seuls moyens de communication entre les objets. Ils sont donc positionns sur le lien entre deux objets.
- Un nom est associ au message pour faciliter son identification.

- La squence permet de prciser lordre dmission des messages.
- Un message peut tre complt par un ou plusieurs arguments :le message 5 ChoixCompteMontant a pour argument le compte et le
montant choisis par le client.
- Certains messages peuvent solliciter un rsultat. On peut reprsenter ce cas par deux messages : le premier fait la demande, le second
apporte la rponse. Toutefois, lorsque le message en retour est immdiatement attendu, pour simplifier les diagrammes on peut les
omettre.
- Lmission dun message peut tre soumise une garde : .Le contrle doit tre OK pour demander la liste des comptes dun client.
8820448.doc
______________________________________________________________________________
xercice TVServices (parties III et IV)

ocit qui met disposition de ses clients un ensemble de services relatifs la tlvision (accs des
ntrle des utilisations et des utilisateurs, programme lectronique dtaill des chanes accessibles...). Ces
aliss sous le nom d' IntelliTl Chaque client dispose d'un botier lectronique situ entre l'antenne
de tlvisualisation (crans, magntoscopes...). C'est cet quipement intermdiaire, appel ci-aprs "botier
veille et reli au rseau tlphonique, qui permet au client le paiement des services par carte bancaire, et le
eues; et TvServices, la diffusion automatique des programmes et magazines lectroniques (et des
ant les mmoires des botiers avec les programmes et magazines, et l'autorisation d'accs aux services; TVS
ns relatives aux autorisations d'accs aux services (fonction des paiements reus) dans les botiers.
e cas d'utilisation rsultat de la partie II
___________________________________________________________________
8820448.doc
______________________________________________________________________________
mme de classe mtier pour le cas d'utilisation regarder
ntes compltant la description de l'installation donne en Partie I:

t des missions.
re l'objet de plusieurs diffusions. Une mission a une certaine dure.
ertaine date/heure de dbut.
relative un certain jour de la semaine, elle commence et se termine des heures rondes.
sation du systme par un utilisateur, d'une certaine date/heure de dbut une certaine date/heure de fin, au
zapper d'une chane une autre.
rise que 51 l'utilisateur qui la dclenche est un utilisateur autoris pour le type d'mission, correspondant
i l'heure de dbut de session appartient une plage horaire autorise pour cet utilisateur, et Si le crdit
isateur n'est pas atteint.
e version du diagramme de classe faisant apparatre les classes entits et les attributs ncessaires la vision
e de classe.
Em i s s i on
1..* 1
T it re : s t ring C haine
D ure : s t ring Pr op os er
1..*
App ar tenir
1..*
T ype d' m i s s i on
1..*
Reg ar der
1..*
Uti l i s ate u rs Pl age h orai re

Pr ofiter
O u v r ir
N om : s t ring 1..* 1 ..* J o ur de la s em aine : s t ring
1
M ot de p as s e : s t rin g H eure de d but : s t ring
D ureM axA ut oris e : real H eure de fin : s t ring
___________________________________________________________________
8820448.doc
______________________________________________________________________________
mme de collaboration d'un scnario du cas d'util. regarder

utilisation "Regarder"
ommence par une demande d'ouverture de session faite par l'utilisateur.
session "en cours d'ouverture" et demande l'utilisateur de s'identifier et de donner son mot de passe.
identificateur et le mot de passe associ.
ces informations et vrifie que la plage courante est une plage autorise pour l'utilisateur; il autorise
armi les chanes accessibles (fonction de l'abonnement) au client, parmi les missions en cours de diffusion,
s l'utilisateur qui a dclench la session.
t une.
images correspondantes au tlviseur.
lviseur.
30 secondes; au bout des 30 secondes, le tlviseur restant arrt, le systme ferme la session.
'utilisation.
rio nominal et un scnario d'exception du cas d'utilisation regarder.

scnarios et raliser le diagramme de collaboration correspondant.
gramme de classes en faisant apparatre les classes entits et contrleurs ainsi que les attributs ncessaires
'utilisation.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
P de synthse: Cration d'un site Web

al Waste Treatment Society), association internationale de chercheurs scientifiques, a pour objet de
de recherche sur le traitement des dchets. Elle compte diffrents collges : celui des universitaires et des
celui des ingnieurs des administrations, celui des laboratoires, celui des industriels producteurs... Pour
ation et sa ractivit, cette association souhaite fonder une communaut virtuelle internationale, elle dsire
site web orient vers tous ses partenaires et permettant d'effectuer des transactions.
sion d'un membre l'association doit se faire en ligne. Une personne peut demander devenir adhrente
e par deux membres en place. Le demandeur connect la partie du site de l'IWTS accessible au public,
demande d'adhsion. La premire partie du formulaire demande une @dresse lectronique et les rfrences
contrle de l'identit des parrains une cl est fournie au demandeur (dans sa bote aux lettres lectronique)
r au formulaire d'adhsion complet. L'association souhaite connatre; l'identit du demandeur, son adresse
e le plus important, son adresse professionnelle, sa profession (par exemple ingnieur d'tudes) et sa fonction
exemple directeur de laboratoire), ses thmes prfrs de recherche et les rcompenses obtenues (par
e la meilleure publication sur le thme du lagunage...). Le demandeur choisit les groupes thmatiques auquel
doit fournir galement sa photo numrise et les rfrences de deux articles dont il est l'auteur; ces articles
des revues scientifiques rpertories, ou tre disponibles sur un site, auquel cas c'est l'adresse rticulaire
ournit.Un des membres du conseil (compos d'un prsident, d'un vice prsident, et d'un nombre de membres
ortionnel au nombre d'adhrents de ce collge) qui dirige l'association examine la demande d'adhsion,
ientifique des deux articles cits par le demandeur et contrle le parrainage. Si le conseil apprcie le dossier
e lui est propos et il peut devenir membre. S'il confirme sa demande, le demandeur (admis) signale le mode
on qu'il souhaite. Le tarif dpend du collge du membre. Le membre admis peut, aprs s'tre acquitt du
des informations prives de l'association. L'enregistrement du paiement est effectu par le secrtariat. Il fait
diffusion du groupe thmatique auquel il a choisi d'appartenir; il pourra dialoguer avec les autres membres
charte dontologique des listes. Cela peut se faire tout moment notamment lors de la confirmation de
des articles:
ion est publie pour ses membres sur le web tous les trois mois. Les membres ont deux mois entre chaque
articles. Un article possde un titre, un thme et des mots clefs. La slection des articles est dcide par le
ux lecteurs du groupe thmatique correspondant, choisis par le conseil. Un article peut tre accept, refus
dements, pour une relecture. L'avis, aprs la deuxime lecture est dfinitif. L'auteur de l'article reoit une
sont notes les remarques prcises des lecteurs, ceux ci restent anonymes. Un rsum de chaque article
r la partie publique du site web, titre d'apritif, avec ses mots clefs.
vrages:
sociation ralisent parfois1 des ouvrages spcifiques (CDROM de photos par exemple).Ces ouvrages sont
condition qu'ils demeurent scientifiques et non publicitaires (le traitement de l'acceptation d'un ouvrage est
rticle sans que ne se pose le problme de dlai). Ces ouvrages sont alors mis en vente pour tout public sur le
bnfices entre auteur et diteur est alors calcule).
ure analytique du texte ci-dessus, produisez une premire version du diagramme des cas d'utilisation du
WTS". Veillez respecter les frontires du systme. Une des approches possibles consiste passer au crible
pes nominaux) ; ils sont candidats tre des objets du systme ou des acteurs extrieurs, utilisateurs du
___________________________________________________________________
8820448.doc
______________________________________________________________________________
rmes verbales), quand eux, marquent un aspect dynamique, un lien entre objets, un comportement du
'il rend.
mme des cas d'utilisation, on slectionnera les acteurs et les services.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
tion du cas d'utilisation "Adhrer".
dhrer" ; acteur dclencheur : "Public"; acteurs participants:

ariat"
r
mande d'adhsion manant d'un acteur "Public".
formulaire de demande d'adhsion, explicitant la procdure.
e le formulaire rempli (nom & prnom, @dresse lectronique), nommant ses deux parrains.
dentit des parrains et veille la non redondance du nom du demandeur. */
ans la bote (mail) du demandeur une cl valide. Le demandeur renouvelle sa demande d'adhsion.
formulaire d'adhsion en ligne.
te le formulaire avec la cl d'authentification qui lui a t fournie, son adresse personnelle, son diplme le plus
fessionnelle, sa profession et sa fonction dans l'organisation dont il fait partie, ses thmes prfrs de recherche et les
uels il souhaite appartenir. */
et le formulaire et un dossier comportant une photo (magntique) au format requis, et les rfrences de deux
r parues dans une revue ou publies sur un site.
mbre autoris), demande accder au dossier Le serveur lui fournit le dossier.
ou non l'adhsion un collge.
'avis du conseil. */
vis du conseil au demandeur.
itif, le demandeur peut confirmer sa demande d'adhsion au collge propos, signaler son mode de paiement
ndante, et s'il souhaite utiliser la liste de diffusion, en signer la charte.
gistre le paiement de la cotisation.
nt membre effectif. */
par l'enregistrement du paiement de l'adhsion (interaction 13), ou par le signalement au demandeur
et de sa demande par le conseil.
sion au collge des laboratoires", instance du cas d'utilisation "Adhrer".
ilisation adhrer: "adhsion au collge des laboratoires"

rre Aver (PA), connect au site, demande accder l'adhsion en ligne.
un formulaire de demande d'adhsion, explicitant la procdure.
e Aver, Pierre.Aver@eigsi.fr), nomme ses deux parrains (Lagun Hadj et Hincine R.) et expdie le dbut du
dentit des parrains (0K) et veille la non redondance du nom du demandeur (0K). */
l'@ Pierre.Aver@eigsi.fr la cl LMU3288. PA renouvelle sa demande d'adhsion
un formulaire d'adhsion en ligne.
mulaire avec la cl qui lui a t fournie (LMU3268), son adresse personnelle (18, Rue des Roses Trmires
nne, France...), son diplme le plus important (Ph D en biologie), son adresse professionnelle (...), sa
tudes) et sa fonction dans l'organisation dont il fait partie (directeur du laboratoire de biologie applique),
recherche (l'utilisation des algues dans le processus de lagunage et les groupes thmatiques auxquels il
a ntation & traitements biologiques). */
aire incluant sa photo (magntique), et les rfrences de deux articles dont il est l'auteur publies sur le site
nieur.
message vers la bal du conseil.
), membre du conseil, demande accder au dossier.
le dossier.
n au collge des laboratoires. /* Le serveur enregistre l'avis du conseil. */
vis du conseil PA.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
nde d'adhsion au collge des laboratoires, signale son mode de
ion par chque bancaire, et signe la charte afin d'utiliser les listes de
x thmes qu'il a choisi.
gistre le paiement de la cotisation. /* PA devient membre effectif */
dtail le texte de description du cas d'utilisation adhrer , produire une premire version du diagramme
cette application.
___________________________________________________________________
8820448.doc
______________________________________________________________________________
ramme de collaboration du scnario "adhsion au collge des laboratoires"
___________________________________________________________________

Methodologie UML Cours Du Cycle B Du Cnam

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Methodologie UML Cours Du Cycle B Du Cnam

Transféré par

Droits d'auteur :

Formats disponibles

8820448.

Cours dispens par Annick Lassus.

APPROCHE DU LANGAGE UML...................17

INTRODUCTION AU LANGAGE UML..........39

METHODOLOGIE CNAM ANGOULEME 2000-2001

Comparaison des mthodologies UP et Merise:

I. Le processus de dveloppement : nouvelle approche

Dans une dmarche traditionnelle, le processus de dveloppement tait caractris par :

Dans une approche objet tout change :

La matrise des processus de dveloppement implique pourtant une organisation et un

UP (Unified Process) est une mthode gnrique de dveloppement de logiciel.

Il existe donc un certain nombre de mthodes issues de UP.

II. Le processus unifi : cadre gnral

Caractristiques essentielles du processus unifi :

III. Le processus unifi est pilot par les cas dutilisation

3.2) Exemple: guichet de banque

client de la banque employ de la banque

3.3) Stratgie des cas dutilisation

Que doit pouvoir faire le systme pour chaque utilisateur ?

Les cas dutilisation garantissent la cohrence du processus de dveloppement du

IV. Le processus unifi est centr sur larchitecture

4.1) Liens entre cas dutilisation et architecture ?

4.2) Marche suivre :

Larchitecture se dvoile peu peu, au rythme de la spcification et de la

Ce processus se poursuit jusqu ce que larchitecture soit juge stable.

V. Le processus unifi est itratif et incrmental

Un incrment constitue souvent un additif.

A chaque itration, les dveloppeurs identifient et spcifient les cas dutilisations

5.1) Avantages dun processus itratif contrl

Permet dacclrer le rythme de dveloppement grce des objectifs clairs et

VI. Le cycle de vie du processus unifi

Expose les cas dutilisation et leurs relations avec

6.1) Prsentation du cycle de vie de UP

Phase Description et Enchanement dactivits

6.2) Exemple sur les diffrents modles

a) Diagramme de cas d'utilisation:

On va essayer de faire apparatre des cas nominaux (classiques) et des scnarios

b) Modle d'analyse: ralisation d'un cas d'utilisation

VII. Conclusion : un processus intgr

APPROCHE DU LANGAGE UML 17

INTRODUCTION AU LANGAGE UML 39

METHODOLOGIE CNAM ANGOULEME 2000-2001

APPROCHE DU LANGAGE UML

I. Les mthodes objet et la gense d'UML

Les premires mthodes d'analyse (annes 70)

L'approche systmique (annes 80)

L'mergence des mthodes objet (1990-1995)

Les premiers consensus (1995)

UML volue mais reste stable !

1.2) A quoi sert UML ?

UML n'est pas une mthode ou un processus !

UML est un langage pseudo-formel

UML cadre l'analyse objet, en offrant :

UML est un support de communication

1.3) Les points forts d'UML

UML est un langage formel et normalis

UML est un support de communication performant

1.4) Les points faibles d'UML

La mise en pratique d'UML ncessite un apprentissage et passe par une priode

II. Caractristiques de la mthode UML

2.2) UML: visualisation complte d'un systme

III. Introduction la notation UML

3.1) La notion d'objet