22 - Copie PDF

Modlisation objet
avec
UML
Pierre-Alain Muller
Prface
UML est le rsultat dun long processus initialis depuis maintenant deux ans par
trois des mthodologistes les plus rputs : Grady Booch, Ivar Jacobson et Jim
Rumbaugh. Conscients que leurs travaux respectifs ne reprsentaient que les
diverses facettes dun mme problme, ils ont eu lintelligence de joindre leurs
efforts plutt que de se lancer dans dinutiles querelles de chapelles. Deux ans de
travail au sein de Rational Software Corporation, soutenus dans leurs efforts par
de nombreux autres spcialistes du domaine, leur ont permis de dfinir cette
nouvelle approche de la modlisation des logiciels base dobjets. UML est la
fois la synthse et le successeur naturel de leurs diffrents travaux. De par sa
standardisation par lOMG, qui devrait aboutir dans le courant de lanne 1997, et
de par son adoption par les plus grands acteurs du monde de linformatique :
IBM, Microsoft, Oracle, Hewlett Packard, pour ne citer que les plus grands, UML
est appel devenir trs court terme le standard pour la modlisation des
applications informatiques de demain.
Pierre Alain Muller, pour avoir pass cinq ans Rational Software en contact
direct avec les gourous du domaine, tait la personne la plus mme de rdiger ce
premier ouvrage en franais sur UML. Ses comptences indiscutables dans le
domaine, allies son sens profond de la pdagogie, font de cet ouvrage un
guide indispensable tous ceux qui veulent comprendre et appliquer les principes
dUML dans le dveloppement de leurs applications.
Etienne Morel
Directeur Gnral
Rational Software Europe
Redde Caesari
quae sunt Caesaris
Les principaux auteurs de la notation UML sont Grady Booch, Ivar Jacobson et
Jim Rumbaugh. Cet ouvrage fait constamment rfrence leurs travaux et je leur
rends bien volontiers ce qui leur appartient.
Au-del de la notation UML, cet ouvrage dcrit un processus de pilotage des
projets objet qui est largement inspir du processus de dveloppement mis au
point par les consultants de Rational Software Corporation. Quils soient ici tous
remercis, en particulier Philippe Kruchten.
Je remercie galement les personnes qui ont accept de relire le manuscrit et qui
mont apport leurs prcieux commentaires ; je pense surtout Jean-Luc Adda,
Jean Bzivin, Jrme Desquilbet, Nathalie Gaertner, Yves Holvot, Nasser Kettani,
Mireille Muller, Philippe Perrin, Michel Reyrolle, Marie-Christine Roch et Philippe
Studer.
Je noublie pas toutes les personnes qui ont influenc la rdaction de cet
ouvrage, tout particulirement Etienne Morel et Bernard Thirion, mais aussi JeanJacques Bockstaller, Tom Joad, Philippe Laroque, Grard Metzger, Bernard
Monnoye et les quelques centaines de personnes qui ont assist mes
formations sur lobjet. Je ne remercie pas Dominique Griesinger.
Enfin, je remercie Anne, Jonathan, Roxane et Lara pour leur patience et je leur
ddie cet ouvrage.
pam, avril 1997
Table des matires

PRFACE
REDDE CAESARI QUAE SUNT CAESARIS
TABLE DES MATIRES
A QUI SADRESSE CE LIVRE
LA GENSE DUML
Les mthodes danalyse et de conception......................................................................5

A quoi sert une mthode ? ..........................................................................................5
Des mthodes fonctionnelles aux mthodes objet ..................................................6
La prolifration des mthodes objet .........................................................................8
Rapprochement de Booch et OMT ............................................................................9
Lunification des mthodes........................................................................................... 10
Vers un langage unifi pour la modlisation ...................................................... 10
Modle et mtamodle.............................................................................................. 12
LAPPROCHE OBJET
15
Pourquoi lapproche objet ?.......................................................................................... 15

Les objets ......................................................................................................................... 18
Caractristiques fondamentales dun objet ......................................................... 20
Contraintes de ralisation ...................................................................................... 23
Communication entre objets ................................................................................... 25
Reprsentation des interactions entre les objets................................................. 32
Les classes ...................................................................................................................... 36
II Modlisation objet avec UML
La dmarche d'abstraction...................................................................................... 36
Reprsentation graphique des classes.................................................................. 37
Description des classes ............................................................................................ 40
Les relations entre les classes .................................................................................... 44
Lassociation.............................................................................................................. 44
Lagrgation .............................................................................................................. 46
Correspondances entre diagrammes de classes et diagrammes dobjets ....... 48
Les hirarchies de classes ........................................................................................... 49
Gnralisation et spcialisation ............................................................................ 50
Des ensembles aux classes....................................................................................... 53
De la difficult de classer......................................................................................... 59
Lhritage ................................................................................................................... 64
Le polymorphisme ..................................................................................................... 70
LA NOTATION UML
83
Les diagrammes dUML ................................................................................................ 84

Concepts de base............................................................................................................. 85
Les lments communs.............................................................................................. 86
Les mcanismes communs........................................................................................ 86
Les types primitifs ...................................................................................................... 88
Les paquetages................................................................................................................ 90
Les diagrammes de classes .......................................................................................... 94
Les classes................................................................................................................... 94
Les associations......................................................................................................... 99
Les agrgations .......................................................................................................109
La navigation...........................................................................................................111
La gnralisation ....................................................................................................114
Les classes abstraites..............................................................................................118
Introduction au mtamodle.................................................................................119
Les cas dutilisation.....................................................................................................124
Intrt des cas dutilisation...................................................................................124
Le modle des cas dutilisation ............................................................................126
Les relations entre cas dutilisation....................................................................129
Construction des cas dutilisation.......................................................................130
Rgles de mise en uvre des cas dutilisation...................................................131
Processus dlaboration des cas dutilisation ..................................................133
Les derniers piges viter...................................................................................135
La transition vers les objets...................................................................................136
Les diagrammes dobjets ............................................................................................137
Reprsentation des objets......................................................................................138
Reprsentation des liens........................................................................................139
Les objets composites..............................................................................................140
Table des matires III
Similitudes avec les diagrammes de classes.......................................................141

Les diagrammes de collaboration..............................................................................142
Reprsentation des interactions...........................................................................142
La place de lutilisateur.........................................................................................145
Les objets actifs ........................................................................................................145
Reprsentation des messages................................................................................146
Les diagrammes de squence.....................................................................................151
Structures de contrle............................................................................................157
Les diagrammes dtats-transitions .........................................................................161
Les automates...........................................................................................................161
Les tats.....................................................................................................................162
Les transitions..........................................................................................................164
Les vnements.........................................................................................................165
Les gardes.................................................................................................................167
Les oprations, les actions et les activits..........................................................168
Points dexcution des oprations.......................................................................170
Gnralisation dtats............................................................................................171
Agrgation dtats ..................................................................................................173
Lhistorique..............................................................................................................175
La communication entre objets.............................................................................176
Cration et destruction des objets .......................................................................178
Les transitions temporises ...................................................................................179
Les diagrammes dactivits ........................................................................................182
Reprsentation des activits .................................................................................182
Les diagrammes de composants ................................................................................187
Les modules ..............................................................................................................187
Les dpendances entre composants.....................................................................188
Les processus et les tches.....................................................................................189
Les programmes principaux..................................................................................190
Les sous-programmes..............................................................................................190
Les sous-systmes.....................................................................................................191
Intgration avec les environnements de dveloppement.................................193
Les diagrammes de dploiement................................................................................194
Reprsentation des nuds.....................................................................................194
ENCADREMENT DES PROJETS OBJET
199
Caractrisation du logiciel.........................................................................................200
La crise du logiciel .................................................................................................200
Les catgories de logiciels ....................................................................................200
La complexit des logiciels ...................................................................................201
La porte de lapproche objet...............................................................................204
IV Modlisation objet avec UML
La transition vers lobjet........................................................................................212

Vers une mthode de dveloppement.........................................................................213
Les cas dutilisation................................................................................................216
Architecture logicielle ...........................................................................................217
Cycle de vie itratif et incrmental......................................................................239
Pilotage des projets objet............................................................................................255
La vue de lencadrement........................................................................................256
La vue technique .....................................................................................................258
Intgration des deux points de vue ......................................................................259
Gestion du risque dans un dveloppement itratif ...........................................261
Constitution de lquipe de dveloppement ......................................................269
Description dtaille des phases..........................................................................273
ETUDE DE CAS : APPLICATION DE CONTRLE DACCS UN
BTIMENT
289
Le processus .................................................................................................................289
Analyse des besoins .....................................................................................................290
Description des cas dutilisation...............................................................................292
Dtermination des cas dutilisation ....................................................................292
Configuration ..........................................................................................................294
Surveillance .............................................................................................................304
Contrle daccs .....................................................................................................309
Tableau rcapitulatif des cas dutilisation et des scnarios principaux .....310
Contrles de cohrence .........................................................................................311
Description des collaborations ..................................................................................312
Configuration ..........................................................................................................313
Surveillance .............................................................................................................333
Contrle daccs .....................................................................................................340
Analyse...........................................................................................................................342
Analyse du domaine................................................................................................342
Analyse de lexistant...............................................................................................343
Architecture..................................................................................................................354
Architecture logicielle ...........................................................................................354
Architecture matrielle ..........................................................................................356
Ralisation ...............................................................................................................357
ANNEXES
359
LES LMENTS STANDARD
361
Strotypes prdfinis.................................................................................................361
Etiquettes prdfinies ..................................................................................................363
Table des matires V
Contraintes prdfinies ..............................................................................................365

GUIDE DE TRANSITION DE BOOCH ET OMT VERS UML
367
Les mcanismes de base.............................................................................................368

Contraintes...............................................................................................................368
Notes..........................................................................................................................368
Catgories ................................................................................................................368
Sous-systmes...........................................................................................................368
Les objets .......................................................................................................................369
Les liens.........................................................................................................................369
Spcification de ralisation ..................................................................................369
Les messages ................................................................................................................370
Ordre denvoi...........................................................................................................371
Flots de donnes......................................................................................................371
Les classes ....................................................................................................................371
Classe simple............................................................................................................371
Attributs et oprations ...........................................................................................372
Visibilit....................................................................................................................372
Classe abstraite.......................................................................................................373
Classe utilitaire .......................................................................................................373
Classe paramtrable...............................................................................................373
Classe paramtre...................................................................................................374
Mtaclasse................................................................................................................374
Les relations .................................................................................................................375
Association ...............................................................................................................375
Rle............................................................................................................................375
Multiplicit...............................................................................................................375
Restriction ................................................................................................................376
Classe-association..................................................................................................376
Agrgation................................................................................................................376
Dpendance..............................................................................................................377
Hritage ....................................................................................................................377
Instanciation de Mtaclasse .................................................................................378
Instanciation de gnrique ...................................................................................378
Construction drive ..............................................................................................378
GNRATION DE CODE C++
381
Classe.............................................................................................................................381
Classe vide................................................................................................................381
Classe avec attributs et oprations .....................................................................382
Classe paramtrable...............................................................................................383
VI Modlisation objet avec UML
Association....................................................................................................................384
Association 1 vers 1 ................................................................................................384
Association N vers 1 ...............................................................................................384
Association N vers 1 avec une contrainte ..........................................................385
Classe-association..................................................................................................387
Classe-association N vers N..................................................................................388
Agrgation.....................................................................................................................388
Agrgation 1 vers 1.................................................................................................388
Agrgation navigabilit restreinte...................................................................389
Agrgation par valeur............................................................................................389
Agrgation par valeur 1 vers N ............................................................................389
Hritage .........................................................................................................................390
Hritage simple........................................................................................................390
Hritage multiple ....................................................................................................390
GNRATION DE CODE JAVA
391
Classe.............................................................................................................................391
Classe vide................................................................................................................391
Classe abstraite.......................................................................................................392
Interface ....................................................................................................................392
Association....................................................................................................................392
Agrgation.....................................................................................................................393
Agrgation 1 vers 1.................................................................................................393
Hritage .........................................................................................................................394
Hritage simple........................................................................................................394
Hritage entre interfaces .......................................................................................394
Ralisation dune interface par une classe abstraite.......................................395
Ralisation dune interface par une classe........................................................395
Ralisation de plusieurs interfaces par une classe...........................................395
GNRATION DE CODE IDL
397
Classe.............................................................................................................................397
Classe vide................................................................................................................397
Association....................................................................................................................398
Table des matires VII
Agrgation.....................................................................................................................398
Agrgation 1 vers 1.................................................................................................398
Hritage .........................................................................................................................399
Hritage simple........................................................................................................399
GNRATION DE CODE VISUAL BASIC
401
Classe.............................................................................................................................401
Classe vide................................................................................................................401
Association....................................................................................................................403
Hritage .........................................................................................................................404
Hritage simple........................................................................................................404
GNRATION DE CODE SQL
405
Classe.............................................................................................................................405
Classe vide................................................................................................................405
Association....................................................................................................................406
Classe-association N vers N..................................................................................407
Hritage .........................................................................................................................407
Hritage simple........................................................................................................408
GLOSSAIRE
409
BIBLIOGRAPHIE
419
Pour en savoir plus ......................................................................................................419

Bibliographie...........................................................................................................419
Adresses utiles sur Internet....................................................................................420
INDEX
423
CONTENU DU CD-ROM
435
A qui sadresse ce livre

Ce livre traite de modlisation objet. Il dcrit la mise en uvre de la notation UML
(Unified Modeling Language), dveloppe en rponse lappel propositions
lanc par lOMG (Object Management Group), dans le but de dfinir la notation
standard pour la modlisation des applications construites laide dobjets.
La notation UML reprsente ltat de lart des langages de modlisation objet.
Elle se place comme le successeur naturel des notations des mthodes de Booch,
OMT (Object Modeling Technique) et OOSE (Object Oriented Software
Engineering) et, de ce fait, UML sest trs rapidement impose, la fois auprs
des utilisateurs et sur le terrain de la normalisation.
Ce livre s'adresse tous ceux qui dsirent comprendre et mettre en uvre
l'approche objet, et plus particulirement aux professionnels de l'informatique qui
doivent aborder la transition vers UML. La lecture de l'ouvrage ne demande pas
de connaissances pralables en technologie objet, mais suppose des
connaissances informatiques de base. Le livre peut servir d'accompagnement un
cours de second cycle ou d'anne de spcialisation d'cole d'ingnieur.
Le contenu de ce livre, le cheminement propos et le niveau dabstraction retenu
dans la prsentation de la notation UML, sont le fruit dune pratique des
mthodes objet, dans des projets rels. La rdaction insiste tout particulirement
sur la modlisation objet, cest--dire sur lanalyse et la dfinition des besoins de
lutilisateur ; ceci non pas, parce que la conception ou la programmation seraient
des tches moins nobles, mais tout simplement, parce que les informaticiens ont
beaucoup plus de mal trouver ce quil faut faire, qu trouver comment le faire.
Louvrage est divis en 5 chapitres qui peuvent tre lus de manire quasi
indpendante :
2 Modlisation objet avec UML
le premier chapitre met en avant le besoin de mthodes et dcrit la gense de

la notation unifie UML,
le deuxime chapitre prsente les concepts de base de la technologie objet,

afin de rendre la lecture de louvrage accessible aux nophytes,
le troisime chapitre dcrit les concepts dUML, en utilisant la notation comme

support pour la description de la smantique des lments de modlisation,
le quatrime chapitre introduit les bases de lencadrement des projets objet,

avec une description du processus de dveloppement sous-tendu par UML
(pilot par les use cases, centr sur larchitecture, itratif et incrmental),
le cinquime chapitre prsente une tude de cas : la modlisation objet avec

UML dun systme de contrle des accs un btiment.
Le livre se termine par des annexes sur la transition vers UML et sur des rgles de
mise en uvre, organises de la manire suivante :
un guide de transition de Booch et OMT vers UML,
la gnration de code C++,
la gnration de code Java,
la gnration de code IDL,
la gnration de code Visual Basic,
la gnration de code SQL.
Plusieurs lectures de l'ouvrage sont possibles, selon les connaissances et les

centres d'intrts du lecteur :
Le lecteur novice est invit lire l'ensemble du livre, en suivant l'ordre des
chapitres. Ce conseil s'applique galement aux programmeurs qui ont acquis
une connaissance d'un langage de programmation objet comme C++, sans
avoir suivi de formation spcifique lanalyse et la conception objet.
Le lecteur qui possde dj une bonne connaissance d'une mthode de

modlisation, telle que Booch ou OMT, pourra entamer la lecture partir du
troisime chapitre. Il lui est par contre recommand de parcourir galement le
deuxime chapitre, car l'exprience montre que certains concepts comme celui
de gnralisation sont souvent mal compris.
Les architectes du logiciel, aprs avoir tudi la notation UML dans le

troisime chapitre, se concentreront tout particulirement sur le quatrime
chapitre qui traite darchitecture objet et prsente le modle des 4 + 1 vues.
Les chefs de projets trouveront galement dans le quatrime chapitre les

informations ncessaires pour la mise en place d'un processus de
dveloppement pilot par les cas d'utilisation (use cases), centr sur
A qui sadresse ce livre 3
l'architecture, itratif et incrmental. Il leur sera aussi profitable de parcourir les

premiers chapitres, afin de pouvoir lire et comprendre les modles.
Il est probablement utile de dire aussi que ce livre n'est :
ni un trait de programmation objet ; il ne dcrit aucun langage de

programmation en dtail,
ni une apologie dUML ; mais plutt un ouvrage de modlisation objet, qui

faut appel la notation UML.
1
La gense dUML
Linformatique sest glisse imperceptiblement dans notre vie quotidienne. Des
machines laver aux lecteurs de disques compacts, en passant par les
distributeurs de billets et les tlphones, quasiment toutes nos activits
quotidiennes utilisent du logiciel et, plus le temps passe, plus ce logiciel devient
complexe et coteux.
La demande de logiciels sophistiqus alourdit considrablement les contraintes
imposes aux quipes de dveloppement. Le futur des informaticiens sannonce
comme un monde de complexit croissante, la fois du fait de la nature des
applications, des environnements distribus et htrognes, de la taille des
logiciels, de la composition des quipes de dveloppement, et des attentes
ergonomiques des utilisateurs.
Pour surmonter ces difficults, les informaticiens vont devoir apprendre faire,
expliquer, et comprendre. Cest pour ces raisons quils ont et auront toujours
plus besoin de mthodes. Le temps de linformatique intuitive et des programmes
qui tombent en marche sachve. Place au doux rve de linformatique adulte,
raisonne, efficace !
Les mthodes danalyse et de conception

A quoi sert une mthode ?
Une mthode dfinit une dmarche reproductible pour obtenir des rsultats
fiables. Tous les domaines de la connaissance utilisent des mthodes plus ou
moins sophistiques et plus ou moins formalises. Les cuisiniers parlent de
recettes de cuisine, les pilotes droulent des check-lists avant le dcollage, les
architectes dessinent des plans et les musiciens suivent des rgles de
composition.
De mme, une mthode dlaboration de logiciels dcrit comment modliser et
construire des systmes logiciels de manire fiable et reproductible.
De manire gnrale, les mthodes permettent de construire des modles partir
dlments de modlisation qui constituent des concepts fondamentaux pour la
reprsentation de systmes ou de phnomnes. Les notes reportes sur les
partitions sont des lments de modlisation pour la musique. Lapproche objet
propose lquivalent des notes ce sont les objets pour la reprsentation des
logiciels.
Les mthodes dfinissent galement une reprsentation souvent graphique
qui permet dune part de manipuler aisment les modles, et dautre part de
communiquer et dchanger linformation entre les diffrents intervenants. Une
bonne reprsentation recherche lquilibre entre la densit dinformation et la
lisibilit.
En plus des lments de modlisation et de leurs reprsentations graphiques, une
mthode dfinit des rgles de mise en uvre qui dcrivent larticulation des
diffrents points de vue, lenchanement des actions, lordonnancement des
tches et la rpartition des responsabilits. Ces rgles dfinissent un processus
qui assure lharmonie au sein dun ensemble dlments coopratifs et qui
explique comment il convient de se servir de la mthode.
Avec le temps, les utilisateurs dune mthode dveloppent un savoir-faire li sa
mise en uvre. Ce savoir-faire, galement appel exprience, nest pas toujours
formul clairement, ni aisment transmissible.
Des mthodes fonctionnelles aux mthodes objet

Les mthodes structures et fonctionnelles se sont imposes les premires, bien
que les mthodes objet aient leurs racines solidement ancres dans les annes 60.
Ce nest gure surprenant, car les mthodes fonctionnelles sinspirent
directement de larchitecture des ordinateurs, cest--dire dun domaine prouv
et bien connu des informaticiens. La sparation entre les donnes et le code, telle
quelle existe physiquement dans le matriel, a t transpose vers les mthodes ;
cest ainsi que les informaticiens ont pris lhabitude de raisonner en termes de
fonctions du systme. Cette dmarche est naturelle lorsquelle est replace dans
son contexte historique ; aujourdhui, de part son manque dabstraction, elle est
devenue quasiment anachronique. Il ny a en effet aucune raison dinscrire des
rponses matrielles dans des solutions logicielles. Le logiciel sexcute sur du
matriel qui doit tre son service et non sur du matriel qui lui impose des
contraintes darchitecture.
1 La gense dUML 7
Plus rcemment, vers le dbut des annes 80, les mthodes objet ont commenc
merger. LHistoire avec un grand H est un ternel recommencement. La petite
histoire des mthodes se rpte elle aussi. Le cheminement des mthodes
fonctionnelles et des mthodes objet est similaire. Au dbut existait la
programmation, avec dans un cas le sous-programme et dans lautre, lobjet
comme lment structurant de base. Quelques annes plus tard, les informaticiens
poussent le concept structurant vers la conception et inventent la conception
structure dans un cas et la conception objet dans lautre. Plus tard encore, la
progression vers lanalyse est opre, toujours en exploitant le mme paradigme,
soit fonctionnel, soit objet. Chaque approche peut donc proposer une dmarche
complte, sur lensemble du cycle de vie du logiciel.
Figure 1 : Lvolution des mthodes, objet ou non, sest toujours faite de la programmation
vers lanalyse.
Dans les faits, la situation est lgrement plus complexe. En effet, souvent les
mthodes ne couvrent pas lensemble du cycle de vie. Cela se traduit alors par la
juxtaposition de mthodes : une mthode A pour lanalyse, suivie dune mthode
C pour la conception. Cette approche parcellaire, tant quelle est confine dans un
des paradigmes lapproche fonctionnelle ou lapproche objet reste
raisonnable. En revanche, le mlange de paradigmes est nettement moins
raisonnable, bien que comprhensible. Vers le milieu des annes 80, les bienfaits
de la programmation objet commencent tre largement reconnus, et la
conception objet semble une approche raisonnable pour qui veut mettre en uvre
un langage de programmation objet comme Smalltalk. Du ct de l'analyse par
contre, la notion danalyse objet nest que vapeur et supputation. Les entreprises
ont dvelopp cette poque une solide connaissance des mthodes danalyse
fonctionnelle et de modlisation smantique des donnes ; les informaticiens
semploient donc tout naturellement juxtaposer une phase de conception objet
une phase danalyse fonctionnelle. Cette manire de procder prsente de
nombreux inconvnients lis au changement de paradigme. Le passage de
lanalyse fonctionnelle la conception objet ncessite une traduction des
lments de modlisation fonctionnelle vers les lments de modlisation objet,
ce qui est loin dtre commode et naturel. En effet, il ny a pas de bijection entre
les deux ensembles, de sorte quil faut casser les lments de modlisation dune
des approches pour construire des fragment dlments de modlisation de
lautre approche. Le rsultat net de ce changement dtat desprit en cours de
dveloppement est de limiter considrablement la navigation entre lnonc des
besoins en amont de lanalyse et la satisfaction de ces besoins en aval de la
conception. Dautre part, une conception objet obtenue aprs traduction manque
trs souvent dabstraction et se limite lencapsulation des objets de bas
niveaux, disponibles dans les environnements de ralisation et dexcution. Tout
ceci implique beaucoup defforts pour des rsultats somme toute bien peu
satisfaisants.
Figure 2 : La combinaison dune approche fonctionnelle pour lanalyse et dune approche

objet pour la conception et la ralisation na plus lieu dtre aujourd'hui car les mthodes
objet actuelles couvrent lensemble du cycle de vie du logiciel.
Durant la dernire dcennie, des applications objet depuis lanalyse des

besoins, jusqu' la ralisation ont t dveloppes dans tous les secteurs
dapplications. Lexprience acquise sur ces projets permet de savoir comment
enchaner les diffrentes activits selon une approche totalement objet. A ce jour,
lvolution des pratiques nest pas totale et des adeptes de la mixit existent
toujours, prisonniers du poids de leurs habitudes. Les organisations qui sont sur
le point de faire la transition vers lobjet ne doivent pas reproduire ce travers. Il
est bien plus simple de mettre en uvre une approche totalement objet, cela
dautant plus que les logiciels dvelopps de cette faon sont plus simples, plus
robustes et mieux adapts aux attentes de leurs utilisateurs.
La prolifration des mthodes objet

La premire moiti des annes 90 a vu fleurir une cinquantaine de mthodes objet.
Cette prolifration est le signe de la grande vitalit de lobjet, mais aussi le fruit
dune multitude dinterprtations de ce qui est objet, de ce qui lest moins et de ce
1 La gense dUML 9
qui ne lest pas du tout1. Le travers de cette effervescence mthodologique est

dencourager la confusion, de sorte que les utilisateurs se placent dans une
situation dattentisme qui limite les progrs des mthodes. La meilleure validation
reste la mise en uvre ; les mthodes ne sont pas figes, elles voluent en
rponse aux commentaires des utilisateurs.
Fort heureusement, lexamen des mthodes dominantes permet de dgager un
consensus autour dides communes. Les grands traits des objets, repris par de
nombreuses mthodes, sarticulent autour des notions de classe, dassociation
(dcrite par James Rumbaugh), de partition en sous-systmes (Grady Booch) et
autour de lexpression des besoins partir de ltude de linteraction entre
lutilisateur et le systme (les use cases d'Ivar Jacobson).
Enfin, les mthodes bien implantes comme celles de Booch et OMT (Object
Modeling Technique) se sont renforces par lexprience, en adoptant les
lments mthodologiques les plus apprcis par les utilisateurs.
Rapprochement de Booch et OMT

Les deuximes moutures des mthodes de Booch et OMT, appeles
respectivement Booch93 et OMT-2, se sont rapproches tant et si bien quelles
sont devenues plus ressemblantes que diffrentes. Les variations subsistantes
sont minimes et concentres principalement dans la terminologie et dans la
notation.
Booch93 sinspire dOMT et adopte les associations, les diagrammes de Harel2,
les traces dvnements, etc.
OMT-2 sinspire de Booch et introduit les flots de message, les modles
hirarchiques et les sous-systmes, les composants modles, et surtout, retire du
modle fonctionnel les diagrammes de flot de donnes, hrits dun pass
fonctionnel et peu intgrs avec la forme gnrale dOMT.
A ce stade, les deux mthodes offrent une couverture complte du cycle de vie,
avec toutefois une diffrence notable dans lclairage. Booch-93 insiste plus sur
la construction alors qu'OMT-2 se concentre sur lanalyse et labstraction.
Nanmoins, il nexiste entre les deux mthodes aucune incompatibilit majeure.
Les concepts objet ont souvent une histoire complique et imbrique. Les
lments prsents dans le tableau suivant se sont dgags de lexprience de
Amghar Y. & al. 25-27 octobre 1995, Domaines et utilisation de la technologie

objets. Congrs AFCET95, Toulouse, pp. 43-72.
2
Harel, D. 1987. Statecharts : A Visual Formalism for Complex Systems. Science

of Computer Programming vol. 8.
mise en uvre des diffrentes mthodes et ont marqu leffort dunification des
mthodes de Booch et OMT.
Origine
Elment
Booch
Catgories et sous-systmes
Embley
Classes singletons et objets composites
Fusion
Description des oprations, numrotation des messages
Gamma et al.
Frameworks, patterns et notes
Harel
Automates (Statecharts)
Jacobson
Cas dutilisation (use cases)
Meyer
Pr- et post-conditions
Odell
Classification dynamique, clairage sur les vnements
OMT
Associations
Shlaer-Mellor
Cycle de vie des objets
Wirfs-Brock
Responsabilits (CRC)
Figure 3 : Principaux lments emprunts par Booch93 et OMT-2 aux diffrentes mthodes
objet.
Lunification des mthodes

Vers un langage unifi pour la modlisation
Lunification des mthodes de modlisation objet est rendue possible parce que
lexprience a permis de faire le tri entre les diffrents concepts proposs par les
mthodes existantes.
Partant de la constatation que les diffrences entre les mthodes samenuisent et
que la guerre des mthodes ne fait plus progresser la technologie objet, Jim
Rumbaugh et Grady Booch dcident fin 94 dunifier leurs travaux au sein dune
mthode unique : la mthode unifie (The Unified Method). Une anne plus tard,
ils sont rejoints par Ivar Jacobson, le crateur des cas dutilisation (use cases),
une technique trs efficace pour la dtermination des besoins.
Booch, Jacobson et Rumbaugh se fixent quatre objectifs :
reprsenter des systmes entiers (au-del du seul logiciel) par des concepts
objets,
1 La gense dUML 11
tablir un couplage explicite entre les concepts et les artefacts excutables,
prendre en compte les facteurs dchelle inhrents aux systmes complexes et

critiques,
crer un langage de modlisation utilisable la fois par les humains et les

machines.
Les auteurs de la mthode unifie atteignent trs rapidement un consensus sur

les concepts fondamentaux de lobjet. En revanche, la convergence sur les
lments de notation est plus difficile obtenir et la reprsentation graphique
retenue pour les diffrents lments de modlisation connatra plusieurs
modifications.
La premire version de la description de la mthode unifie a t prsente en
octobre 1995, dans un document intitul Unified Method V0.8. Ce document a t
largement diffus et les auteurs ont recueilli plus dun millier de commentaires
dtaills de la part de la communaut des utilisateurs. Ces commentaires ont t
pris en compte dans la version 0.9 parue en juin 1996, mais cest surtout la version
0.91, disponible depuis octobre 1996, qui permet de noter lvolution de la
mthode unifie.
La principale modification consiste en la rorientation de la porte de leffort
dunification, dabord vers la dfinition dun langage universel pour la
modlisation objet, et ventuellement ensuite vers la standardisation du
processus de dveloppement objet. La mthode unifie (Unified Method) se
transforme en UML (The Unified Modeling Language for Object-Oriented
Development).
En 1996, il apparat clairement quUML est perue comme un lment de base
dans la stratgie de plusieurs grandes entreprises. Cest ainsi que se cr un
consortium de partenaires pour travailler la dfinition de la version 1.0 dUML ;
il regroupe notamment : DEC, HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI
Systemhouse, Microsoft, Oracle, Rational Software, TI et Unisys.
De cette collaboration nat la description d'UML version 1.0 remise lOMG le 17
janvier 1997, en vue de sa standardisation durant lanne 1997.
Figure 4 : Principales tapes de la dfinition dUML.
Les crateurs dUML insistent tout particulirement sur le fait que la notation
UML est un langage de modlisation objet et non pas une mthode objet. Les
commentaires recueillis en rponse la publication de la version 0.8 ont
clairement montr que les utilisateurs attendaient une formalisation des artefacts
du dveloppement, plutt que du processus dlaboration de ces artefacts. En
consquence, la notation UML a t conue pour servir de langage de
modlisation objet, indpendamment de la mthode mise en uvre. La notation
UML peut ainsi se substituer sans perte dinformation aux notations des
mthodes de Booch, OMT ou encore OOSE (Object Oriented Software
Engineering galement appele Objectory).
UML nest pas une notation propritaire : elle est accessible tous et les
fabricants doutils ainsi que les entreprises de formation peuvent librement en
faire usage. La volont douverture, la richesse de la notation et la dfinition
smantique prcise des lments de modlisation font dUML une notation
gnrale et simple, sans tre simpliste.
En franais, UML pourrait se traduire par langage unifi pour la modlisation
objet, mais il est plus que probable quUML se traduise plutt par notation
unifie, voire notation UML, sur le mme schma que mthode OMT.
Modle et mtamodle
Leffort initial porte sur lidentification et la dfinition de la smantique des
concepts fondamentaux qui forment les briques de base de la modlisation objet.
Ces concepts constituent les artefacts du dveloppement et ils doivent pouvoir
1 La gense dUML 13
tre changs entre les diffrents intervenants des projets. Pour raliser ces
changes, il faut dabord saccorder sur limportance relative de chaque concept,
tudier les consquences de ces choix et choisir une reprsentation graphique
dont la syntaxe soit la fois simple, intuitive et expressive.
Pour faciliter ce travail de dfinition et pour formaliser UML, tous les diffrents
concepts ont t eux-mmes modliss avec UML. Cette dfinition rcursive,
appele mtamodlisation, prsente le double avantage de permettre de classer
les concepts par niveau dabstraction, de complexit et de domaine dapplication,
et aussi de faire la preuve de la puissance dexpression de la notation, capable
entre autres de se reprsenter elle-mme.
Un mtamodle dcrit de manire formelle les lments de modlisation et la
syntaxe et la smantique de la notation qui permet de les manipuler. Le gain
dabstraction induit par la construction dun mtamodle facilite lidentification
dventuelles incohrences et encourage la gnricit. Le mtamodle dUML sert
de description de rfrence pour la construction doutils et pour le partage de
modles entre outils diffrents.
Un modle est une description abstraite dun systme ou dun processus, une
reprsentation simplifie qui permet de comprendre et de simuler. Le terme
modlisation est souvent employ comme synonyme danalyse, cest--dire de
dcomposition en lments simples, plus faciles comprendre. En informatique, la
modlisation consiste tout dabord dcrire un problme, puis dcrire la
solution de ce problme ; ces activits sappellent respectivement lanalyse et la
conception.
La forme du modle dpend du mtamodle. La modlisation fonctionnelle
dcompose les tches en fonctions plus simples raliser. La modlisation objet
dcompose les systmes en objets collaborants. Chaque mtamodle dfinit des
lments de modlisation et des rgles pour la composition de ces lments de
modlisation.
Le contenu du modle dpend du problme. Un langage de modlisation comme
UML est suffisamment gnral pour tre employ dans tous les domaines
informatiques et mme au-del, par exemple pour lingnierie des affaires.
Un modle est lunit de base du dveloppement ; il est fortement cohrent avec
lui-mme et faiblement coupl avec les autres modles par des liens de navigation.
En rgle gnrale, un modle est reli une phase prcise du dveloppement et
est construit partir dlments de modlisation avec leurs diffrentes vues
associes.
Un modle nest pas directement visible par les utilisateurs. Il capture la
smantique sous-jacente dun problme et contient des donnes exploites par
les outils pour lchange dinformation, la gnration de code, la navigation, etc.
UML dfinit plusieurs modles pour la reprsentation des systmes :
le modle des classes qui capture la structure statique,
le modle des tats qui exprime le comportement dynamique des objets,
le modle des cas dutilisation qui dcrit les besoins de lutilisateur,
le modle dinteraction qui reprsente les scnarios et les flots de messages,
le modle de ralisation qui montre les units de travail,
Le modle de dploiement qui prcise la rpartition des processus.
Les modles sont regards et manipuls par les utilisateurs au moyen de vues
graphiques, vritables projections au travers des lments de modlisation
contenus par un ou plusieurs modles. De nombreuses vues peuvent tre
construites partir des modles de base ; elles peuvent montrer tout ou partie des
modles. A chaque vue correspondent un ou plusieurs diagrammes. UML dfinit
neuf types de diagrammes diffrents :
les diagrammes de classes,
les diagrammes de squence,
les diagrammes de collaboration,
les diagrammes dobjets,
les diagrammes dtats-transitions,
les diagrammes dactivits,
les diagrammes de cas dutilisation,
les diagrammes de composants,
les diagrammes de dploiement.
Des notations diffrentes peuvent tre des vues du mme modle. Les notations
de Booch, OMT et OOSE utilisent des syntaxes graphiques diffrentes, mais
reprsentent les mmes concepts objet. Ces notations graphiques diffrentes ne
sont en fait que des vues diffrentes des mmes lments de modlisation, de
sorte quil est tout fait possible dutiliser diffrentes notations sans perdre le
contenu smantique. UML nest quune autre reprsentation graphique dun
modle smantique commun.
2
Lapproche objet
Ce chapitre prsente les concepts de base de lapproche objet. Il sadresse tout
particulirement aux informaticiens qui sorientent vers lobjet. La matrise des
notions prsentes dans ce chapitre est essentielle pour une bonne lecture de la
suite de louvrage. Les exemples prsents introduisent graduellement quelques
bases de la notation UML.
Pourquoi lapproche objet ?

Quelle est la raison qui rend lapproche objet tellement attractive ? A cette
question, les adeptes de lobjet rpondent invariablement que les avantages de
lapproche objet sont la stabilit de la modlisation par rapport aux entits du
monde rel, la construction itrative facilite par le couplage faible entre
composants et la possibilit de rutiliser des lments dun dveloppement un
autre. Certains insistent galement sur la simplicit du modle qui ne fait appel
qu cinq concepts fondateurs (les objets, les messages, les classes, lhritage et
le polymorphisme) pour exprimer de manire uniforme lanalyse, la conception et
la ralisation dune application informatique. Tous ces points sont parfaitement
exacts, mais ils ne sont que la consquence de la fantastique capacit
dintgration dunification de lapproche objet.
Dune manire gnrale, toute mthode de construction de logiciels doit prendre
en compte l'organisation, la mise en relation et l'articulation de structures pour en
faire merger un comportement macroscopique complexe : le systme raliser.
L'tude du systme doit donc ncessairement prendre en considration
l'agencement collectif des parties, et conduire une vue plus globale des
lments qui le composent. Elle doit progresser diffrents niveaux d'abstraction
et, par effet de zoom, s'intresser aussi bien aux dtails qu' l'ordonnancement de
l'ensemble.
La construction dun logiciel est par consquent une suite ditrations du genre
division-runion ; il faut dcomposer diviser pour comprendre et il faut
composer runir pour construire. Ceci conduit une situation paradoxale : il
faut diviser pour runir !
Face ce paradoxe, le processus de dcomposition a t dirig traditionnellement
par un critre fonctionnel. Les fonctions du systme sont identifies, puis
dcomposes en sous-fonctions, et cela rcursivement jusqu lobtention
dlments simples, directement reprsentables dans les langages de
programmation (par les fonctions et les procdures).
Figure 5 : Dcomposition fonctionnelle et hirarchique.
Larchitecture du logiciel ainsi ralis est le reflet des fonctions du systme. Cette
dmarche, dont les mcanismes intgrateurs sont la fonction et la hirarchie,
apporte des rsultats satisfaisants lorsque les fonctions sont bien identifies et
lorsquelles sont stables dans le temps. Toutefois, tant donn que la fonction
induit la structure, les volutions fonctionnelles peuvent impliquer des
modifications structurelles lourdes, du fait du couplage statique entre architecture
et fonctions.
L'approche objet repose la fois sur le rationalisme d'une dmarche cartsienne et
sur une dmarche systmique qui considre un systme comme une totalit
organise, dont les lments solidaires ne peuvent tre dfinis que les uns par
rapport aux autres. Elle propose une mthode de dcomposition, non pas base
uniquement sur ce que le systme fait, mais plutt sur l'intgration de ce que le
systme est et fait.
2 Lapproche objet 17
Porte
Cabine
Ouvrir
Aller au RDC
Lumire
Bouton
Faire clignoter
Figure 6 : Dcomposition objet intgrant la structure et le comportement (notation de

Booch).
Initialement base sur l'utilisation d'objets en tant quabstractions du monde rel,

lapproche objet a pour but une modlisation des proprits statiques et
dynamiques de lenvironnement dans lequel sont dfinis les besoins, appel le
domaine du problme. Elle formalise notre perception du monde et des
phnomnes qui s'y droulent, et met en correspondance lespace du problme et
lespace de la solution (lensemble des artefacts de ralisation), en prservant la
structure et le comportement du systme analys. Les fonctions se reprsentent
alors par des formes de collaboration entre les objets qui composent le systme.
Le couplage devient dynamique, et les volutions fonctionnelles ne remettent
plus en cause la structure statique du logiciel.
Lorsque le problme est totalement compris, le systme informatique est ralis en
composant les reprsentations informatiques des lments simples, identifis par
lune des techniques de dcomposition prcdentes. La construction dun
systme apparat donc comme une dmarche dintgration, une organisation
harmonieuse de composants plus lmentaires, dont la raison dtre est notre
manire de grer la complexit par la dcomposition.
Dans une organisation unifie, la distinction des composants va de pair avec leur
intgration. La force de lapproche objet provient alors de sa double capacit
dcomposer diffrencier et recomposer runir du fait de la richesse de
ses mcanismes dintgration, qui concernent la fois les aspects statiques et les
aspects dynamiques des logiciels. Lintgration apparat comme la qualit
fondamentale des objets ; elle assure la cohrence entre les composants dun
systme informatique, au sein dun modle uniforme applicable toutes les
phases du cycle de vie du logiciel.
Lapproche objet tire sa force de sa capacit regrouper ce qui a t spar,
construire le complexe partir de llmentaire, et surtout intgrer statiquement
et dynamiquement les constituants dun systme.
Les objets
Lobjet est une unit atomique forme de l'union d'un tat et d'un comportement.
Il fournit une relation d'encapsulation qui assure la fois une cohsion interne
trs forte et un faible couplage avec l'extrieur. Lobjet rvle son vrai rle et sa
vraie responsabilit lorsque, par l'intermdiaire de l'envoi de messages, il s'insre
dans un scnario de communication.
Comportement visible
Un objet
Etat interne cach
Figure 7 : Chaque objet contient un tat interne qui lui est propre et un comportement
accessible aux autres objets.
Le monde dans lequel nous vivons est constitu d'objets matriels de toutes
sortes. La taille de ces objets est trs variable : certains sont petits, comme les
grains de sable, et dautres trs gros, comme les toiles. Notre perception intuitive
de ce qui constitue un objet est fonde sur le concept de masse, c'est--dire sur
une grandeur qui caractrise la quantit de matire d'un corps.
Par extension, il est tout fait possible de dfinir d'autres objets, sans masse,
comme les comptes en banques, les polices d'assurance ou encore les quations
mathmatiques. Ces objets correspondent alors des concepts plutt qu' des
entits physiques.
Toujours par extension, les objets peuvent galement appartenir des mondes
virtuels, par exemple, en association avec Internet, pour crer des communauts
de personnes qui ne sont pas situes au mme point gographique.
Les objets informatiques dfinissent une reprsentation abstraite des entits dun
monde rel ou virtuel, dans le but de les piloter ou de les simuler. Cette
reprsentation abstraite peut tre vue comme une sorte de miroir informatique, qui
renvoie une image simplifie d'un objet qui existe dans le monde peru par
l'utilisateur. Les objets informatiques, que nous appellerons dsormais objets,
encapsulent une partie de la connaissance du monde dans lequel ils voluent.
Les utilisateurs des technologies objet ont pris l'habitude de considrer les objets
comme des tres anims d'une vie propre, de sorte qu'ils les prsentent souvent
dans une vision anthropomorphique3. Ainsi, les objets sont souvent dsigns en
anglais par she ou he plutt que par it.
Comme les tres vivants, les objets du monde rel qui nous entourent naissent,
vivent et meurent. La modlisation objet permet de reprsenter le cycle de vie des
objets au travers de leurs interactions.
En UML, un objet se reprsente sous la forme dun rectangle ; le nom de l'objet
est soulign. Le diagramme suivant reprsente trois objets.
Un autre objet
Un objet
Encore un objet
Figure 8 : En UML les objets se reprsentent au moyen dicnes rectangulaires.
Le diagramme suivant reprsente plusieurs clients dune banque et les comptes

associs chacun de ces clients. Les traits qui relient les objets symbolisent les
liens qui existent entre un client particulier et un compte particulier. Le graphique
prsente galement un rectangle dont le coin haut droit est repli : il sagit de la
reprsentation dune note, cest--dire dune information de clarification
optionnelle exprime dans un format libre, afin de faciliter la comprhension du
diagramme. Les traits discontinus permettent de relier n'importe quel ensemble
dlments de modlisation une note descriptive.
Deux clients
de la banque
Compte courant
Philippe
Compte pargne logement
Didier
Assurance vie
Compte pargne
Compte courant
Figure 9 : Reprsentation graphique dobjets ayant un lien entre eux.
Wirfs-Brock R., Wilkerson B., Wiener L. 1990, Designing Object-Oriented

Software. Prentice-Hall, Englewood Cliffs, NJ.
Il est souvent difficile de trouver un nom pour dsigner chaque objet ; cest
pourquoi la notation permet dindiquer un nom gnrique plutt que leur nom
individuel. Cet artifice permet de parler des objets en termes gnraux, tout en
vitant la multiplication de noms du type ga, bu, zo ou meu, qui vhiculent un
contenu smantique trs approximatif.
Le diagramme suivant montre des lves et des professeurs. Les deux points
prcisent quil sagit dobjets anonymes, de genre Elve et Professeur.
: Elve
: Elve
: Professeur
: Elve
: Elve
: Professeur
Figure 10 : Reprsentation dobjets anonymes.
Caractristiques fondamentales dun objet

La prsentation des caractristiques fondamentales dun objet permet de
rpondre de manire plus formelle la sempiternelle question : mais quest-ce
qui dfinit un objet ? . Tout objet prsente les trois caractristiques suivantes :
un tat, un comportement et une identit.
Objet = Etat + Comportement + Identit
Un objet doit apporter une valeur ajoute par rapport la simple juxtaposition
dinformations ou de code excutable. Un objet sans tat ou sans comportement
peut exister marginalement, mais dans tous les cas, un objet possde une identit.
Ltat
Ltat regroupe les valeurs instantanes de tous les attributs dun objet sachant
quun attribut est une information qui qualifie lobjet qui le contient. Chaque
attribut peut prendre une valeur dans un domaine de dfinition donn. L'tat dun
objet, un instant donn, correspond une slection de valeurs, parmi toutes les
valeurs possibles des diffrents attributs.
Le diagramme suivant montre une voiture qui contient les valeurs de trois
attributs diffrents : la couleur, la masse et la puissance fiscale.
Une voiture
Bleu
979 kg
12 CV
Figure 11 : Ltat regroupe les valeurs des diffrents attributs qui caractrisent un objet. Dans
le cas dune voiture, la couleur ou la masse font partie de ltat.
L'tat volue au cours du temps ; ainsi, lorsquune voiture roule, la quantit de

carburant diminue, les pneus s'usent et la temprature dans l'habitacle varie.
Certaines composantes de l'tat peuvent tre constantes : c'est le cas par exemple
de la marque de la voiture, ou encore du pays de sa construction. Toutefois, en
rgle gnrale, l'tat d'un objet est variable et peut tre vu comme la consquence
de ses comportements passs.
Dans lexemple suivant, une voiture donne parcourt une centaine de kilomtres ;
pendant quelle se dplace, la valeur qui symbolise la quantit de carburant
diminue avec la distance parcourue.
Une voiture
30 litres
Aprs un parcours
de 100 Km
Une voiture
20 litres
Figure 12 : L'tat d'un objet un moment donn est la consquence des comportements
passs.
Le comportement
Le comportement regroupe toutes les comptences dun objet et dcrit les actions
et les ractions de cet objet. Chaque atome de comportement est appel
opration. Les oprations dun objet sont dclenches suite une stimulation
externe, reprsente sous la forme dun message envoy par un autre objet.
Dans le diagramme suivant, selon la valeur du message, lOpration 1 ou
lOpration 2 est dclenche.
Un autre objet
Un message
Un objet
Opration 1
{...}
Opration 2
{...}
Figure 13 : En rponse un message, lobjet destinataire dclenche un comportement. Le

message sert de slecteur pour dterminer lopration excuter.
Les interactions entre objets se reprsentent au moyen de diagrammes dans

lesquels les objets qui interagissent sont relis entre eux par des lignes continues
appeles liens. La prsence dun lien signifie quun objet connat ou voit un autre
objet. Les messages naviguent le long des liens, a priori dans les deux directions.
Dans l'exemple suivant, l'objet A demande l'objet B de manger, et l'objet B
demande l'objet C de dormir. Ceci sous-entend que l'objet B possde la facult
de manger et que l'objet C est capable de dormir.
Manger
A
Dormir
Figure 14 : Reprsentation dune interaction entre des objets.
Ltat et le comportement sont lis ; en effet, le comportement un instant donn

dpend de l'tat courant, et l'tat peut tre modifi par le comportement. Il nest
possible de faire atterrir un avion que sil est en train de voler, c'est--dire que le
comportement Atterrir nest valide que si l'information En Vol est valide.
Aprs latterrissage, l'information En Vol devient invalide, et lopration
Atterrir na plus de sens. Lexemple suivant montre les liens entre ltat et le
comportement.
: Avion
En vol
Atterrir
Dcoller
: Tour de contrle
: Avion
Au sol
Figure 15 : Le comportement et les attributs sont lis.
Lidentit
En plus de son tat, un objet possde une identit qui caractrise son existence
propre. Lidentit permet de distinguer tout objet de faon non ambigu, et cela
indpendamment de son tat4. Cela permet, entre autres, de distinguer deux objets
dont toutes les valeurs dattributs sont identiques.
Lidentit est un concept, elle ne se reprsente pas de manire spcifique en
modlisation. Chaque objet possde une identit de manire implicite.
En phase de ralisation, lidentit est souvent construite partir dun identifiant
issu naturellement du domaine du problme. Nos voitures possdent toutes un
numro dimmatriculation, nos tlphones un numro dappel, et nous-mmes
sommes identifis par notre numro de scurit sociale. Ce genre didentifiant,
appel galement cl naturelle, peut tre rajout dans ltat des objets afin de les
distinguer. Il ne s'agit toutefois que d'un artifice de ralisation, car le concept
d'identit reste indpendant du concept d'tat.
Contraintes de ralisation
Les notions dtat, de comportement et didentit dcrites dans le chapitre
prcdent, sappliquent aux objets de manire trs gnrale, quel que soit
lenvironnement de ralisation. Toutefois, les objets peuvent galement possder
des caractristiques plus informatiques, lies aux contingences de
ralisation comme la distribution des programmes, les bases de donnes ou les
dveloppements multilangages.
Khoshafian, S. N., Copeland G. P. 1986, Object Identity. OOPSLA86 Conference

Proceedings.
La persistance des objets

La persistance dsigne la capacit d'un objet transcender le temps ou l'espace.
Un objet persistant sauvegarde son tat dans un systme de stockage permanent,
de sorte qu'il est possible d'arrter le processus qui l'a cr sans perdre
l'information reprsente par l'objet (passivation de l'objet). Par la suite, l'objet
peut tre reconstruit (activation de l'objet) par un autre processus et se
comportera exactement comme dans le processus initial. Les objets non
persistants sont dits transitoires ou phmres. Par dfaut, les objets ne sont pas
considrs comme persistants.
: Objet persistant
Stockage
permanent
Figure 16 : Ltat des objets persistants est sauvegard dans un systme de stockage
permanent.
Dans leur ensemble, les langages de programmation objet ne proposent pas de

support direct pour assurer la persistance des objets. Cela est regrettable et
oblige recourir des artifices extrieurs pour assurer la persistance des objets.
Les constructeurs de bases de donnes fournissent des solutions pour la
sauvegarde des objets, soit totalement objet, soit hybrides.
La transmission des objets

La problmatique de la persistance des objets est trs proche de celle de la
migration des objets d'un processus vers un autre. En effet, il s'agit alors
d'envoyer un objet par un moyen de communication quelconque d'un espace
d'adressage vers un autre espace d'adressage. Cette opration s'apparente
troitement la dmarche de passivation et d'activation dcrite prcdemment.
Les objets ne voyagent pas rellement : lobjet original est analys lors de
lmission, la description de lobjet est transmise au travers du support de
communication, un clone de lobjet est reconstruit lors de la rception et lobjet
initial est supprim. Les amateurs de Star Trek auront reconnu le principe de la
tl-transportation5.
Metzger G. 1996, Beam me up, Spock. There is no life on this planet.

Communication prive.
Le clone est la
copie conforme
de l'objet
d'origine
Un objet
Un clone
: Support de communication
Figure 17 : Les objets peuvent tre transmis le long dun support de communication.
Les objets miroirs

Les objets miroirs constituent une alternative la transmission des objets. Un
objet miroir se comporte comme un autre objet avec lequel il est synchronis. Le
client manipule le miroir comme sil manipulait lobjet distant, ce qui permet de
dissimuler toute la complexit de la communication au fond des objets miroirs.
Contexte A
Un miroir
Contexte B
Un objet
Un client
Figure 18 : Le miroir renvoie dans le contexte A, limage dun objet dfini dans le contexte B.
Communication entre objets

Les systmes informatiques objets peuvent tre vus comme des socits
d'objets qui travaillent en synergie afin de raliser les fonctions de lapplication.
Lors de lexcution dun programme, les objets contribuent solidairement au bon
droulement de lapplication informatique. Le comportement global dune
application repose donc sur la communication entre les objets qui la composent.
De ce fait, l'tude des formes de communication entre objets du domaine est de
premire importance dans la modlisation objet et, d'ailleurs, la grande diffrence
entre l'approche fonctionnelle et l'approche objet rside prcisment dans cette
articulation qui rduit le couplage entre la structure et la fonction.
Catgories de comportement
Les objets interagissent pour raliser les fonctions de lapplication. Selon la
nature des interactions, c'est--dire selon la direction des messages changs, il
est possible de dcrire de manire gnrale le comportement des objets. Il est

frquent de retenir trois catgories de comportement : les acteurs, les serveurs et
les agents.
Un agent
Un acteur
Un serveur
Figure 19 : Les objets peuvent tre regroups dans trois catgories selon la nature de leur
comportement.
Les acteurs 6 sont toujours des objets lorigine dune interaction. Ce sont
gnralement des objets actifs, cest--dire quils possdent un fil dexcution
(thread) et que ce sont eux qui passent la main aux autres objets.
Les serveurs, au contraire, ne sont jamais lorigine dune interaction, mais sont
toujours les destinataires des messages. Ce sont souvent des objets passifs qui
attendent quun autre objet ait besoin de leurs services. Dans ce cas, le flot de
contrle est pass au serveur par lobjet qui envoie le message et est rcupr
aprs excution du service.
Un client
Un serveur
Figure 20 : Lobjet client passe la main lobjet serveur, puis attend la fin du service avant
de reprendre son excution.
Les agents cumulent les caractristiques des acteurs et des serveurs. Ces objets
ont un comportement trs proche de celui des humains ; ils peuvent interagir avec
les autres objets tout moment, de leur fait ou suite une sollicitation externe.
Le terme acteur est galement employ pour dsigner une catgorie

dutilisateurs dans le modle des cas dutilisation (use case) qui est prsent plus
loin dans louvrage.
Les agents sont la base du mcanisme de dlgation qui permet un objet de se

comporter comme un paravent devant un autre objet. Les agents dcouplent les
objets clients des objets fournisseurs, en introduisant une indirection dans le
mcanisme de propagation des messages. De cette manire, un client peut
communiquer avec un serveur quil ne connat pas directement et, de plus, le
serveur peut changer entre deux passages de messages.
Dans lexemple suivant, le client communique indirectement avec le premier
serveur sans le connatre et sans savoir quil existe deux autres serveurs. Le
routage des messages du client vers le serveur est assur dynamiquement par
lagent intermdiaire.
Routage
dynamique
Serveur 1
Un client
Un agent
Serveur 2
Serveur 3
Objet
paravent
Figure 21 : Illustration du mcanisme de dlgation.
Le concept de message
L'unit de communication entre objets s'appelle le message. Le message est le
support d'une relation de communication qui relie, de faon dynamique, les objets
qui ont t spars par le processus de dcomposition. Il permet l'interaction de
manire flexible, en tant la fois agent de couplage et agent de dcouplage. C'est
lui qui assure la dlgation des tches et garantit le respect des contraintes. Le
message est un intgrateur dynamique qui permet de reconstituer une fonction de
lapplication par la mise en collaboration dun groupe dobjets. Il acquiert toute sa
force d'intgration lorsqu'il est associ au polymorphisme et la liaison
dynamique, dfinis plus loin dans ce chapitre. Les messages, comme le montre la
figure suivante, sont reprsents par des flches places le long des liens qui
unissent les objets.
Message B
Objet 1
Message A
Objet 2
Message C
Message E
Objet 3
Objet 4
Message D
Figure 22 : Les objets communiquent en changeant des messages.
Un message regroupe les flots de contrle et les flots de donnes au sein d'une
entit unique. La notion de message est un concept abstrait qui peut tre mis en
uvre selon de nombreuses variantes, comme l'appel de procdure, l'vnement
discret, l'interruption, le datagramme UDP, la recherche dynamique, etc.
Le diagramme suivant dcrit compltement un message. La flche simple indique
le flot de contrle et les flches dcores de petits cercles montrent les flots de
donnes.
Message
Donne A
Objet 1
Donne B
Objet 2
Figure 23 : Les diffrentes flches montrent le flot de contrle et les flots de donnes.
Catgories de messages
Il existe cinq catgories principales de messages :
les constructeurs qui crent des objets,
les destructeurs qui dtruisent des objets,
les slecteurs qui renvoient tout ou partie de ltat dun objet,
les modificateurs qui changent tout ou partie de ltat dun objet,
les itrateurs qui visitent ltat dun objet ou le contenu dune structure de
donnes qui contient plusieurs objets.
Lexemple suivant montre une classe C++ dont les fonctions membres ont t
regroupes selon la classification propose plus haut :
class Lapin
{
public:
// Constructeurs
Lapin();
Lapin(const Lapin &right);
// Destructeur
~Lapin();
// Assignation
const Lapin & operator=(const Lapin &right);
// Egalit
int operator==(const Lapin &right) const;
int operator!=(const Lapin &right) const;
// Autres Operations
void Manger();
void Dormir();
// Slecteurs
const String Nom() const;
const Int Age() const;
// Modifieurs
void ChangerNom(const String value);
void ChangerAge(const Int value);
private:
String Nom;
Int Age;
};
Figure 24 : Exemple de classe C++ dont les fonctions membres ont t regroupes selon les
grandes catgories de messages.
Formes de synchronisation des messages

Les formes de synchronisation des messages dcrivent la nature des mcanismes
de communication qui permettent le passage de messages dun objet vers un
autre objet.
La notion de synchronisation prend tout son intrt lorsque plusieurs objets sont
actifs simultanment et quil faut, par exemple, protger laccs des objets
partags. Le diagramme suivant montre un objet partag qui assure linterface
vers un dispositif dentre-sortie.
Ecrivain 1
Afficher
: Terminal
Ecrivain 2
Afficher
Afficher
Ecrivain 3
Ressource
critique
Figure 25 : Exemple dun objet Terminal accd par plusieurs objets Ecrivain.
Dans une application purement squentielle, les crivains parlent au terminal

chacun leur tour et laffichage sur lcran ne pose aucun problme. En revanche,
ds lors que plusieurs objets Ecrivain peuvent tre actifs simultanment,
lobjet Terminal devient une ressource critique dont il convient de protger les
accs par synchronisation des envois de messages.
La notion de synchronisation prcise la nature de la communication, et les rgles
qui rgissent le passage des messages. Il existe cinq grandes catgories denvoi
de message :
Envoi de message simple. Cette catgorie convient pour les systmes un

seul flot dexcution, dans lesquels un seul objet la fois est actif. Le passage
du contrle seffectue lors de lenvoi dun message de lobjet actif vers un
objet passif. Un envoi de message simple se reprsente par une flche simple.
Un expditeur
Un destinataire
Envoi simple
Figure 26 : Reprsentation dun envoi de message simple.
Envoi de message synchrone. Un message synchrone ne dclenche une

opration que lorsque le destinataire accepte le message. Une fois le message
envoy, lexpditeur est bloqu jusqu ce que le destinataire accepte le
message. Un envoi de message synchrone se reprsente par une flche barre
dune croix.
Un expditeur
Un destinataire
Envoi synchrone
Figure 27 : Reprsentation dun envoi de message synchrone.
Envoi de message drobant. Un message drobant dclenche une opration

seulement si le destinataire sest pralablement mis en attente du message. Ce
type de synchronisation correspond une tolrance dattente inverse de celle
de lenvoi de message synchrone. Dans le cas dun message synchrone,
lexpditeur accepte dattendre ; dans le cas dun message drobant, le
destinataire accepte dattendre. Un envoi de message drobant se reprsente
par une flche qui se retourne vers lexpditeur.
Un expditeur
Un destinataire
Envoi drobant
Figure 28 : Reprsentation dun envoi de message drobant.
Envoi de message minut. Un message minut bloque lexpditeur pendant un

temps donn, en attendant la prise en compte par le destinataire. Lexpditeur
est libr si la prise en compte na pas eu lieu au bout du temps spcifi dans
la description de lenvoi du message minut. Lenvoi de message drobant
correspond au cas limite dun envoi minut avec un dlai dattente nul. Un
envoi de message minut se reprsente par une flche dcore dune montre
symbolise par un petit cercle.
Un expditeur
Un destinataire
Envoi minut
Figure 29 : Reprsentation dun envoi de message minut.
Envoi de message asynchrone. Un message asynchrone ninterrompt pas

lexcution de lexpditeur. Lexpditeur envoie le message sans savoir quand,
ni mme si, le message sera trait par le destinataire. Du point de vue du
destinataire, un envoi asynchrone doit pouvoir tre pris en compte tout
moment. Un envoi de message asynchrone se reprsente par une demi-flche.
Un expditeur
Un destinataire
Envoi asynchrone
Figure 30 : Reprsentation dun envoi de message asynchrone.
La prcision de la forme de synchronisation des messages est souvent opre en

conception, pour raliser par exemple une exclusion mutuelle autour dune
ressource critique. Le diagramme suivant montre que les diffrents crivains
communiquent de faon synchrone avec le terminal. Le terminal srialise les

affichages et les diffrents crivains doivent attendre chacun leur tour.
Ecrivain 1
Ecrivain 2
Afficher
: Terminal
Afficher
Afficher
Ecrivain 3
Ressource
critique
Figure 31 : Exemple de communication par messages synchrones.
La reprsentation de la synchronisation des messages est galement utile en

analyse, comme le montre le diagramme suivant qui illustre une communication
par tlphone. Antoine appelle Marc au tlphone ; la communication ne peut
avoir lieu que si Marc dcroche. Antoine nattend pas indfiniment et peut
raccrocher aprs trois sonneries.
Marc
{3 sonneries}
Antoine Appel
Figure 32 : Exemple dune communication minute.
La communication par voie pistolaire suit un schma asynchrone. Grard

envoie une lettre Bernard ; il ne sait pas quand la lettre arrivera, ni mme si la
lettre arrivera, et il nattend pas que Bernard la reoive.
Grard
Bernard
Lettre par la poste
Figure 33 : Exemple dune communication asynchrone.
Reprsentation des interactions entre les objets

Les objets interagissent pour raliser collectivement les services offerts par les
applications. Les diagrammes dinteraction reprsentent les objets les uns par
rapport aux autres et montrent comment ils communiquent au sein d'une
interaction. Chaque interaction possde un nom et un contexte de validit qu'il

convient de prciser de manire textuelle.
Il existe deux sortes de diagrammes dinteraction : les diagrammes de
collaboration et les diagrammes de squence.
Les diagrammes de collaboration

Les diagrammes de collaboration correspondent aux diagrammes utiliss dans les
exemples prcdents. Ces diagrammes montrent quelques objets dans une
situation donne. Les objets sont reprsents sous forme de rectangles, des liens
relient les objets qui se connaissent (c'est--dire qui peuvent interagir) et les
messages changs par les objets sont reprsents le long de ces liens. Lordre
denvoi des diffrents messages est matrialis par un numro plac en tte du
message.
A
1: X
3: Z
2: Y
C
Figure 34 : Exemple de diagramme de collaboration.
Le diagramme ci-dessus se lit de la manire suivante :

le scnario dbute par un objet A qui envoie un message X un objet B, puis
lobjet B envoie un message Y un objet C, et enfin C senvoie un message Z.
Le message Z est un artifice de notation pour reprsenter une activit ayant lieu
dans l'objet C.
Les diagrammes de collaboration sont particulirement indiqus pour la phase
exploratoire qui correspond la recherche des objets. Lagencement des objets
dans le diagramme peut voquer la disposition spatiale des objets dans le monde
rel, tout en montrant une forme dinteraction. Les diagrammes dobjets dcrivent
la fois la structure statique par des liens entre objets, et le comportement,
travers des envois de messages le long de ces liens. Ce type de diagramme
possde cependant les limites habituelles des reprsentations graphiques la
visualisation claire dun nombre limit dinformations de sorte que seule une
petite collaboration est reprsentable. Le diagramme suivant illustre les limites du
diagramme de collaboration : le grand nombre de messages obscurcit le
diagramme.
8: M8
3: M3
5: M5
C
A
1: M1
4: M4
10: M10
2: M2
9: M9
7: M7
6: M6
Figure 35 : Illustration de la limite dexpressivit dun diagramme de collaboration.
Les diagrammes de squence

Les diagrammes de squence montrent peu prs les mmes informations que les
diagrammes prcdents, mais l'accent est mis sur la communication, au dtriment
de la structure spatiale. Chaque objet est reprsent par une barre verticale. Le
temps s'coule de haut en bas, de sorte que la numrotation des messages est
optionnelle.
Le passage d'un diagramme l'autre est possible automatiquement, ds lors que
seules les informations de prsence d'objets et de communication sont retenues.
Le diagramme de collaboration prcdent correspond au diagramme de squence
suivant :
B
M1
C
M2
M3
M4
M5
M6
M7
M8
M9
M10
Figure 36 : Diagramme de squence driv du diagramme de collaboration prcdent.
Le diagramme prcdent montre uniquement la chronologie des messages. Les

barres verticales peuvent tre dcores de bandes rectangulaires, afin de montrer
la distribution du flot de contrle parmi les diffrents objets.
A
B
M1
C
M2
M3
M4
M5
M6
M7
M8
M9
M10
Figure 37 : Reprsentation de la distribution du flot de contrle parmi les objets.
Les deux types de diagrammes dinteraction sont intressants pour la

modlisation objet. Le diagramme de squence est particulirement bien adapt
pour la reprsentation d'interactions complexes, du fait de sa forme quasi
tabulaire. Le diagramme de collaboration se prte mieux la dcouverte des
abstractions, car il permet de montrer les objets du domaine dans une disposition
physique proche de la ralit. Dans la pratique, il est frquent de commencer par
reprsenter les principaux objets du domaine dans des diagrammes de
collaboration, puis, une fois les objets bien identifis, de migrer vers les
diagrammes de squence pour la reprsentation des interactions dans toute leur
complexit.
Les classes
Le monde rel est constitu de trs nombreux objets en interaction. Ces objets
constituent des amalgames souvent trop complexes pour tre compris dans leur
intgralit du premier coup. Pour rduire cette complexit ou du moins pour la
matriser et comprendre ainsi le monde qui l'entoure, ltre humain a appris
regrouper les lments qui se ressemblent et distinguer des structures de plus
haut niveau d'abstraction, dbarrasses de dtails inutiles.
La dmarche d'abstraction
L'abstraction est une facult des tres humains qui consiste concentrer la
rflexion sur un lment d'une reprsentation ou d'une notion, en portant
spcialement l'attention sur lui et en ngligeant tous les autres. La dmarche
dabstraction procde de lidentification des caractristiques communes un
ensemble dlments, puis de la description condense analogue la
description dun ensemble en comprhension de ces caractristiques dans ce
quil est convenu dappeler une classe. La dmarche d'abstraction est arbitraire :
elle se dfinit par rapport un point de vue. Ainsi, un objet du monde rel peut
tre vu au travers d'abstractions diffrentes, ce qui implique qu'il est important de
dterminer quels sont les critres pertinents dans le domaine d'application
considr.
La classe dcrit le domaine de dfinition dun ensemble dobjets. Chaque objet
appartient une classe. Les gnralits sont contenues dans la classe et les
particularits sont contenues dans les objets. Les objets informatiques sont
construits partir de la classe, par un processus appel instanciation. De ce fait,
tout objet est une instance de classe.
Les langages objet permettent de dcrire et de manipuler des classes et leurs
instances. Cela signifie que l'utilisateur peut construire en machine une
reprsentation informatique des abstractions qu'il a l'habitude de manipuler
mentalement, sans traduction vers des concepts de plus bas niveau (comme les
fonctions ou les procdures des langages de programmation non objet).
Les langages objet rduisent la distance entre notre faon de raisonner (par
abstraction) et le langage compris par les ordinateurs, de sorte quil est
globalement plus facile de raliser une application avec un langage objet quavec
un langage traditionnel, mme si lapproche objet demande une remise en cause
des habitudes acquises.
Objets
Programmation
plus abstraite
Types de donnes abstraits
Fonctions
Simplification
Mnmoniques
Programmation
plus difficile
Codes binaires
Figure 38 : Les langages de programmation objet permettent une programmation plus

abstraite.
Reprsentation graphique des classes

Chaque classe est reprsente sous la forme d'un rectangle divis en trois
compartiments. Le premier compartiment contient le nom de la classe, le second
les attributs et le dernier les oprations. Par dfaut, les attributs sont cachs et les
oprations sont visibles. Les compartiments peuvent tre supprims pour allger
les diagrammes.
Nom de classe
Attributs
Oprations( )
Figure 39 : Reprsentation graphique des classes.
Les quelques exemples suivants illustrent lemploi des classes pour dcrire de
manire gnrale quelques objets de notre entourage.
La classe Motocyclette contient les attributs Couleur, Cylindre et

Vitesse maximale. La classe regroupe galement les oprations applicables
aux instances de la classe, comme ici les oprations Dmarrer(),
Acclrer() et Freiner().
Motocyclette
Couleur
Cylindre
Vitesse maximale
Dmarrer( )
Acclrer( )
Freiner( )
Figure 40 : Exemple dune classe Motocyclette.
L'ensemble des nombres complexes regroupe des nombres qui ont une partie
relle et une partie imaginaire. La connaissance de la reprsentation interne du
nombre complexe cartsienne ou polaire nest pas ncessaire pour utiliser les
oprations dcrites dans lexemple suivant. La classe Nombre complexe
cache les dtails de sa ralisation.
Nombre complexe
Additionner( )
Soustraire( )
Multiplier( )
Diviser( )
Prendre le module( )
Prendre l'argument( )
Prendre la partie relle( )
Prendre la partie imaginaire( )
Figure 41 : La classe Nombre complexe dissimule les dtails de sa reprsentation interne.
Un tlviseur est un quipement lectronique dune complexit non ngligeable,

qui peut nanmoins tre utilis aisment mme par de trs petits enfants. Le
tlviseur offre une abstraction simple, au travers de quelques oprations
lmentaires comme Changer de programme ou Rgler le volume
sonore.
Tlviseur
Allumer( )
Eteindre( )
Changer de programme( )
Rgler le volume( )
Figure 42 : Exemple dune classe Tlviseur.
Une transaction bancaire est une abstraction dune opration immatrielle, qui
rifie une interaction entre un client et une banque. Le dtail de ralisation des
transactions courantes, comme le retrait ou le dpt, ne sont pas connus du client
qui se contente dindiquer le compte sur lequel il dsire oprer et le montant
concern. Le compte est une autre abstraction du domaine bancaire.
Labstraction dissimule la complexit de la gestion des comptes, de sorte que les
transactions peuvent tre ralises simplement par le client tout seul, depuis un
guichet automatique ou depuis un Minitel.
Dpt
Retrait
Montant
Date
Montant
Date
Effectu sur
Compte d'pargne
Solde
Taux
Dposer( )
Retirer( )
Effectu partir
Compte courant
Solde
Dposer( )
Retirer( )
Figure 43 : Reprsentation dune partie du domaine bancaire.
Llectronique des circuits intgrs exploite la notion dabstraction avec

beaucoup de succs. La complexit lectronique et les dtails internes sont
totalement invisibles pour lutilisateur de ces composants. Dans le cas des portes
logiques, le circuit intgr rifie une abstraction fonctionnelle.
Ou {Y=A+B}
A
B
Y( )
Figure 44 : Exemple de rification dune abstraction fonctionnelle.
Tous les types de donnes abstraits manipuls par les informaticiens sont,
comme leur nom lindique, des abstractions dcrites en termes doprations
applicables sur des valeurs. Ce genre dabstraction appartient typiquement la
conception, et napparat jamais en analyse o le terme collection est suffisant
pour dsigner les regroupements dobjets.
Liste
Pile
Premier( )
Dernier( )
Ajouter( )
Retirer( )
Cardinalit( )
Empiler( )
Dpiler( )
Cardinalit( )
Arbre binaire
Sous-arbre gauche( )
Sous-arbre droit( )
Traverser en profondeur( )
Figure 45 : Types de donnes abstraits prsents sous la forme de classes.
Description des classes

La description des classes est spare en deux parties :
la spcification dune classe qui dcrit le domaine de dfinition et les

proprits des instances de cette classe, et qui correspond la notion de type
telle quelle est dfinie dans les langages de programmation classiques,
la ralisation qui dcrit comment la spcification est ralise et qui contient le

corps des oprations et les donnes ncessaires leur fonctionnement.
Une classe passe un contrat avec dautres classes ; elle sengage fournir les
services publis dans sa spcification et les autres classes sengagent ne pas
faire usage de connaissances autres que celles dcrites dans cette spcification.
Fournisseur
Client 1
Les contrats
dcrivent les
dpendances
entre les
classes.
Client 2
Figure 46 : Les classes passent un contrat bas sur la spcification du fournisseur.
Les langages modulaires permettent la compilation spare de la spcification et

de la ralisation, de sorte quil est possible de valider tout dabord la cohrence
des spcifications (appeles aussi interfaces) et de sattaquer plus tard la
ralisation.
Selon les langages de programmation, les concepts de type, de description et de
modules sont plus ou moins intgrs dans le concept de classe :
En Ada 95 par exemple, une classe est construite explicitement, en plaant un

type (priv) accompagn de ses oprations dans un module (paquetage).
Cette approche permet notamment de placer plusieurs types dans un module
et donc de raliser lquivalent des classes amies de C++.
En C++ au contraire, la classe est ralise directement par une construction

syntaxique qui englobe les notions de type, de description et de module. La
classe peut tre dgrade afin dobtenir un module seul, par lajout du mot-cl
static devant toutes les oprations.
En Java, comme en C++, la classe est lintgration des notions de type, de

description et de module, mais il existe en plus une notion de module plus
large (le paquetage) qui peut contenir plusieurs classes.
La sparation entre la spcification et la ralisation des classes participe

llvation du niveau dabstraction. Les traits remarquables sont dcrits dans les
spcifications alors que les dtails sont confins dans les ralisations.
Loccultation des dtails de ralisation est appele encapsulation.
Lencapsulation prsente un double avantage. D'une part, les donnes
encapsules dans les objets sont protges des accs intempestifs ce qui
permet de garantir leur intgrit et d'autre part, les utilisateurs dune abstraction
ne dpendent pas de la ralisation de labstraction mais seulement de sa
spcification, ce qui rduit le couplage dans les modles.
Figure 47 : Les donnes encapsules dans un objet ne sont pas accessibles depuis lextrieur.
Par dfaut, les valeurs dattributs dun objet sont encapsules dans lobjet et ne
peuvent pas tre manipules directement par les autres objets. Toutes les
interactions entre les objets sont effectues en dclenchant les diverses
oprations dclares dans la spcification de la classe et accessibles depuis les
autres objets.
Les rgles de visibilit viennent complter ou prciser la notion dencapsulation.
Ainsi, il est possible dassouplir le degr dencapsulation, mais aussi de
protection, au profit de certaines classes utilisatrices bien particulires, dsignes
dans la spcification de la classe fournisseur. Lintrt de briser lencapsulation
est par exemple de rduire le temps daccs aux attributs en supprimant la
ncessit de recourir des oprations de type slecteur.
Les trois niveaux distincts dencapsulation couramment retenus correspondent
ceux proposs par le langage de programmation C++ :
Le niveau le plus fort est appel niveau priv ; la partie prive de la classe est
alors totalement opaque et seuls les amis (au sens C++) peuvent accder aux
attributs placs dans la partie prive.
Il est possible de relcher lgrement le niveau dencapsulation, en plaant

certains attributs dans la partie protge de la classe. Ces attributs sont alors
visibles la fois pour les amis et les classes drives de la classe fournisseur.
Pour toutes les autres classes, les attributs restent invisibles.
Le niveau le plus faible est obtenu en plaant les attributs dans la partie
publique de la classe. Ceci revient se passer de la notion dencapsulation et
rendre visibles les attributs pour toutes les classes.
Le niveau de visibilit peut tre prcis dans les reprsentations graphiques des
classes au moyen des caractres +, # et -, qui correspondent respectivement aux
niveaux public, protg et priv.
Rgles de visibilit
+ Attribut public
# Attribut protg
- Attribut priv
+ Opration publique( )
# Opration protge( )
- Opration prive( )
Figure 48 : Prcision des niveaux de visibilit dans les reprsentations graphiques des classes.
Lexemple des nombres complexes dcrit prcdemment fournit une bonne

illustration des vertus de lencapsulation. Parce que la spcification des nombres
complexes qui regroupe entre autres les oprations d'addition, de soustraction,
de multiplication et de division n'est pas du tout affecte par le changement de
reprsentation interne (de la notation polaire la notation cartsienne), les objets
qui utilisent des nombres complexes et qui dpendent uniquement de la
spcification ne sont pas affects par cette modification. Le diagramme suivant
montre les deux reprsentations des nombres complexes. La partie publique de
labstraction est identique dans les deux cas, mais la partie prive est diffrente.
Nombre complexe
- Module
- Argument
Nombre complexe
- Partie relle
- Partie imaginaire
+
+
+
+
+
+
+
+
Addition( )
Soustraction( )
Multiplication( )
Division( )
Addition( )
Soustraction( )
Multiplication( )
Division( )
Figure 49 : La spcification nest pas affecte par un changement de reprsentation interne.
L'encapsulation rduit le couplage au sein du modle, favorise la modularit et

facilite la maintenance des logiciels. Lencapsulation agit comme lenceinte de
confinement dune centrale nuclaire : les dfauts restent enferms dans la classe
concerne, ils ne se propagent pas dans tout le modle.
Les critres dencapsulation reposent sur la forte cohrence interne lintrieur
dune classe et sur le faible couplage entre les classes. Il ne suffit pas pour
obtenir une bonne abstraction, de rassembler des donnes et de fournir des
oprations pour la lecture et l'criture de ces donnes. Une classe doit offrir une
valeur ajoute par rapport la simple juxtaposition d'information. C'est le cas de la
classe Nombre complexe qui fournit des oprations arithmtiques.
Les relations entre les classes

Les liens particuliers qui relient les objets peuvent tre vus de manire abstraite
dans le monde des classes : chaque famille de liens entre objets correspond une
relation entre les classes de ces mmes objets. De mme que les objets sont
instances des classes, les liens entre objets sont instances des relations entre
classes.
Lassociation
Lassociation exprime une connexion smantique bidirectionnelle entre classes.
Une association est une abstraction des liens qui existent entre les objets
instances des classes associes. Le diagramme suivant reprsente des objets lis
entre eux et les classes associes correspondantes. Les associations se
reprsentent de la mme manire que les liens. La distinction entre un lien et une
association est opre en fonction du contexte du diagramme.
Pierre-Alain : Etudiant
Un lien
Mulhouse : Universit
Un lien
Jean-Jacques : Etudiant
Purdue : Universit
Eric : Etudiant
Un lien
Anne : Etudiant
Un lien
Strasbourg : Universit
Un lien
Laurence : Etudiant
Une association
Universit
Etudiant
Figure 50 : Les liens entre les universits et les tudiants sont tous instances de lassociation
entre la classe Universit et la classe Etudiant.
Il faut noter que lassociation est un concept de mme niveau dabstraction que
les classes. Lassociation nest pas contenue par les classes ou subordonne aux
classes ; elle est le reflet dune connexion qui existe dans le domaine
dapplication.
Pour amliorer la lisibilit des diagrammes, lassociation peut tre dcore par une
forme verbale active ou passive. Dans les exemples suivants, le sens de lecture
est prcis par les signes < et >.
Hberge >
Universit
Etudiant
< Etudie dans

Universit
Etudiant
Figure 51 : Clarification de la nature dune association par une forme verbale.
Il est possible de prciser le rle dune classe au sein dune association : un nom
de rle peut tre spcifi de part et dautre de lassociation. Lexemple suivant
montre deux associations entre la classe Universit et la classe Personne.
Le diagramme prcise que certaines personnes jouent le rle dtudiant, alors que
dautres personnes jouent le rle denseignant. La deuxime association porte
galement un nom de rle du ct de la classe Universit pour indiquer que
luniversit joue le rle demployeur pour ses enseignants. Le nommage des rles
prend tout son intrt lorsque plusieurs associations relient deux mmes classes.
Etudiant
Universit
Employeur
Personne
Enseignant
Figure 52 : Clarification du rle des associations par une forme nominale.
Les rles portent galement une information de multiplicit qui prcise le nombre
dinstances qui participent la relation. Linformation de multiplicit apparat
dans les diagrammes de classes proximit du rle concern.
Le tableau suivant rsume les valeurs de multiplicit les plus courantes :
1
Un et un seul
0..1
Zro ou un
M .. N
De M N (entiers
naturels)
De zro plusieurs
0 .. *
De zro plusieurs
1 .. *
D'un plusieurs
Figure 53 : Valeurs de multiplicit conventionnelles.
La multiplicit peut galement tre exprime au moyen de formules plus

complexes. Par dfaut, il ny a pas de corrlation entre les valeurs * dans un mme
diagramme.
Le diagramme suivant donne un exemple de reprsentation des valeurs de
multiplicit.
Etudiant
1
Universit
*
Personne
0..1
Employeur
*
Enseignant
Figure 54 : Reprsentation du nombre dinstances qui participent aux associations.
Le diagramme prcdent se lit de la manire suivante :

une universit donne regroupe de nombreuses personnes ; certaines jouent le
rle dtudiant, dautres le rle denseignant. Un tudiant donn appartient
une seule universit, un enseignant donn peut tre en activit ou non.
Lagrgation
Une relation exprime une forme de couplage entre abstractions. La force de ce
couplage dpend de la nature de la relation dans le domaine du problme. Par
dfaut, lassociation exprime un couplage faible, les classes associes restant
relativement indpendantes lune de lautre. Lagrgation est une forme
particulire dassociation qui exprime un couplage plus fort entre classes. Une
des classes joue un rle plus important que lautre dans la relation. Lagrgation
permet de reprsenter des relations de type matre et esclaves, tout et parties ou
compos et composants.
Les agrgations reprsentent des connexions bidirectionnelles dissymtriques. Le
concept dagrgation est une notion purement logique, compltement
indpendante des choix de reprsentation qui relvent de la conception dtaille
et non de la modlisation. Mathmatiquement, lagrgation est une relation
transitive, non symtrique et rflexive.
Lexemple suivant montre quune personne peut soccuper de plusieurs enfants.
La relation est de nature dissymtrique dans le domaine considr : ladulte est
responsable des enfants. La relation est galement rflexive : certaines personnes
jouent le rle de parent, dautres jouent le rle denfant. Une agrgation se

reprsente comme une association, avec en plus un petit losange plac du ct de
lagrgat.
Personne
Parent
0..2
Enfants
*
<S'occupe de
Figure 55 : Exemple dagrgation rflexive.
Lagrgation favorise la propagation des valeurs dattributs et des oprations de

lagrgat vers les composants. Lorsque la multiplicit de lagrgat vaut 1, la
destruction de lagrgat entrane la destruction des composants.
Lexemple suivant prsente le cas des voitures. Chaque voiture possde un
moteur qui ne peut tre partag avec dautres voitures. La destruction intgrale
de la voiture entrane la destruction du moteur.
Voiture
Moteur
1
Figure 56 : La voiture est un tout qui contient un moteur.
Une agrgation non rflexive, dont la valeur de multiplicit vaut 1 du ct de

lagrgat, peut se raliser par contenance physique.
Agrgat
Composants
*
Agrgat par contenance physique

: Composant
: Composant
Figure 57 : Forme dagrgation ralisable par contenance physique.
Lorsque cette multiplicit est suprieure 1, la relation dagrgation peut se

raliser par une forme idiomatique de type pointeur malin (smart pointer) :
plusieurs pointeurs rfrencent le mme objet tout en se synchronisant pour
dsallouer lobjet au moment o il ne sera plus rfrenc par aucun pointeur.
Agrgat
Composants
*
: Composant
: Agrgat
: Composant
: Agrgat
: Composant
Composants
partags
Figure 58 : Ralisation dune agrgation par un pointeur malin.
Correspondances entre diagrammes de classes et

diagrammes dobjets
Les diagrammes de classes et les diagrammes dobjets appartiennent deux vues
complmentaires du modle. Un diagramme de classes montre une abstraction de
la ralit, concentre sur lexpression de la structure statique dun point de vue
gnral. Un diagramme dobjets reprsente plutt un cas particulier, une situation
concrte un instant donn ; il exprime la fois la structure statique et un
comportement.
Classe
*
0..*
1..*
1..*
*
Relation
1 *
Lien
*
*
Objet
*
*
Diagramme de classes
Diagramme d'objets
*
Figure 59 : Correspondances entre diagram mes de classes et diagrammes dobjets.
Les rgles suivantes gouvernent la transition entre les deux types de diagramme :
chaque objet est instance dune classe et la classe de lobjet ne peut pas
changer durant la vie de lobjet,
certaines classes appeles classes abstraites ne peuvent pas tre

instancies,
chaque lien est instance dune relation,
les liens relient les objets, les relations relient les classes,
un lien entre deux objets implique une relation entre les classes des deux
objets,
un lien entre deux objets indique que les deux objets se connaissent et quils
peuvent changer des messages,
les diagrammes dobjets qui contiennent des objets et des liens sont
instances des diagrammes de classes qui contiennent des classes et des
relations.
Les diagrammes de classes et les diagrammes dobjets doivent tre cohrents les
uns par rapport aux autres. Toutefois, il faut tre conscient que le processus de
modlisation objet nest pas un processus linaire, de sorte quil nest pas
souhaitable de construire un type de diagramme et ensuite den driver
intgralement lautre type. Forcer la cration dun type de diagramme avant un
autre limite la libert de cration. Pour prendre une image musicale, dissocier la
construction des diagrammes dobjets de celle des diagrammes de classes,
reviendrait demander un compositeur de considrer sparment la hauteur des
notes et leur dure.
En pratique, les diagrammes dobjets et les diagrammes de classes se construisent
en parallle, par de nombreux allers et retours entre les deux reprsentations. Il ny
a aucune raison de dfinir les classes avant les objets. Il est vrai que chaque objet
est instance dune classe, mais la dtermination de la classe peut trs bien tre
postrieure celle des objets. Le monde rel qui nous entoure contient des objets
et non des classes : il semble donc naturel de trouver dabord les objets puis den
abstraire les classes. En fait, il ny a pas de rgle gnrale ; dans certains cas, la
structure des classes est vidente, dans dautres cas, les objets sont plus faciles
identifier que les classes.
Les hirarchies de classes

Les hirarchies de classes ou classifications permettent de grer la complexit en
ordonnant les objets au sein darborescences de classes dabstraction croissante.
Gnralisation et spcialisation
La gnralisation et la spcialisation sont des points de vue ports sur les
hirarchies de classes.
La gnralisation consiste factoriser les lments communs (attributs,
oprations et contraintes) d'un ensemble de classes dans une classe plus
gnrale appele super-classe. Les classes sont ordonnes selon une hirarchie ;
une super-classe est une abstraction de ses sous-classes.
La gnralisation est une dmarche assez difficile car elle demande une bonne
capacit d'abstraction. La mise au point dune hirarchie optimale est dlicate et
itrative. Les arbres de classes ne poussent pas partir de leur racine. Au
contraire, ils se dterminent en partant des feuilles car les feuilles appartiennent
au monde rel alors que les niveaux suprieurs sont des abstractions construites
pour ordonner et comprendre.
Lexemple suivant montre une hirarchie des moyens de transport. La flche qui
symbolise la gnralisation entre deux classes pointe vers la classe plus gnrale.
Abstractions plus gnrales
Vhicule
Vhicule terrestre
Voiture
Camion
Vhicule arien
Avion
Hlicoptre
Figure 60 : Exemple de hirarchie de classes construite par gnralisation.
La spcialisation permet de capturer les particularits dun ensemble dobjets non

discrimins par les classes dj identifies. Les nouvelles caractristiques sont
reprsentes par une nouvelle classe, sous-classe d'une des classes existantes.
La spcialisation est une technique trs efficace pour l'extension cohrente d'un
ensemble de classes.
Lexemple suivant montre une classification partielle des quipements de
transmission, selon deux grandes familles : les systmes continus et les systmes
discrets. Les dispositifs concrets sont ajouts dans la hirarchie par drivation du
parent le plus proche.
Transmission
Continue
Variateur
Discrte
Drailleur
Bote de vitesses
Extension par spcialisation
Figure 61 : Exemple dextension par spcialisation.
La gnralisation et la spcialisation sont deux points de vue antagonistes du

concept de classification ; elles expriment dans quel sens une hirarchie de
classes est exploite. Dans toute application relle, les deux points de vue sont
mis en uvre simultanment. La gnralisation est plutt employe une fois que
les lments du domaine ont t identifis afin de dgager une description
dtache des solutions. La spcialisation, quant elle, est la base de la
programmation par extension et de la rutilisation. Les nouveaux besoins sont
encapsuls dans des sous-classes qui tendent harmonieusement les fonctions
existantes.
Super-classe
Sous-classe
Classe plus
gnrale
Classe plus
spcialise
Figure 62 : La gnralisation et la spcialisation offrent deux points de vue antagonistes sur

une hirarchie de classes.
Llaboration dune hirarchie de classes demande de la part des dveloppeurs

des qualits et des comptences diffrentes selon le point dentre dans
larborescence. Lidentification des super-classes fait appel avant tout la
capacit dabstraction, indpendamment de toutes connaissances techniques,
alors que la ralisation des sous-classes demande surtout une expertise
approfondie dun domaine particulier.
En fait, la situation est tout fait paradoxale ! Il est plutt difficile de trouver les
super-classes, mais les programmes crits dans leurs termes sont plus simples
dvelopper. Il est assez facile de trouver les sous-classes, mais difficile de les
raliser.
La gnralisation ne porte aucun nom particulier ; elle signifie toujours : est un ou
est une sorte de. La gnralisation ne concerne que les classes, elle nest pas
instanciable en liens et, de fait, ne porte aucune indication de multiplicit. Dans
l'exemple suivant, le lion est une sorte de carnivore et il nest pas possible pour
un lion dtre plusieurs fois un carnivore : un lion est un carnivore.
Animal
Carnivore
Lion
Herbivore
Mouton
Lapin
Figure 63 : La gnralisation ne porte ni nom particulier ni valeur de multiplicit.
La gnralisation est une relation non rflexive : une classe ne peut pas driver
d'elle-mme.
A
B
Impossible !!!
Figure 64 : La gnralisation est une relation non rflexive.
La gnralisation est une relation non symtrique : si une classe B drive d'une
classe A, alors la classe A ne peut pas driver de la classe B.
Impossible !!!
C
B
Figure 65 : La gnralisation est une relation non symtrique.
La gnralisation est par contre une relation transitive : si C drive d'une classe B
qui drive elle-mme d'une classe A, alors C drive galement de A.
A
Figure 66 : La gnralisation est une relation transitive.
Des ensembles aux classes

La notion de classe est trs proche de la notion densemble. La spcification
dune classe est une description abstraite, analogue la description en
comprhension dun ensemble. Les objets instances dune classe partagent des
caractristiques gnrales, exprimes dans la classe sous forme dattribut,
dopration et de contrainte.
Ces caractristiques constituent la proprit caractristique de lensemble des
instances. La proprit caractristique dun ensemble X est note P (X). Dans les
paragraphes suivants, le terme proprit caractristique est appliqu directement
la classe et non lensemble de ses instances. La figure suivante montre
lanalogie entre une classe et un ensemble.
X
Proprit caractristique de X
Figure 67 : Une classe donne une description abstraite dun ensemble dobjets qui partagent
des caractristiques communes.
Lensemble X peut tre divis en sous-ensembles, afin de distinguer par exemple

des particularits supplmentaires partages seulement par certains des lments
de X. Le diagramme suivant montre deux sous-ensembles de X, les ensembles Y et
Z. Les proprits caractristiques des ensembles Y et Z sont des extensions de la
proprit caractristique de X :
P (X) P(Y) et P (X) P(Z) et P (Y) P (Z) = P (X)
Figure 68 : Les lments des ensembles Y et Z sont dabord des lments de lensemble X. Les
proprits caractristiques P (Y) et P (Z) englobent la proprit caractristique P (X).
Les classes et les sous-classes sont lquivalent des ensembles et des sousensembles. La gnralisation des classes correspond la relation dinclusion des
ensembles. De ce fait, les objets instances dune classe donne sont dcrits par la
proprit caractristique de leur classe, mais galement par les proprits
caractristiques de toutes les classes parents de leur classe. Les sous-classes ne

peuvent pas nier les proprits caractristiques de leurs classes parentes. La
proprit caractristique dune sous-classe englobe la proprit caractristique de
toutes ses super-classes. Ce qui est vrai pour un objet instance dune superclasse est vrai pour un objet instance dune sous-classe. A limage de linclusion
dans les ensembles, la gnralisation ordonne les objets au sein dune hirarchie
de classes. Le diagramme suivant montre qu'il existe deux sortes dlments de X
particuliers, respectivement dcrits par les classes Y et Z.
X
Proprit caractristique de Y
Proprit caractristique de Z
Figure 69 : La proprit caractristique des sous-classes est une extension de la proprit

caractristique des super-classes.
Le diagramme suivant illustre un exemple concret. Il existe de trs nombreux

livres ; certains sadressent tout particulirement aux enfants, dautres ont pour
objectif lenseignement. La classification nest pas exhaustive : les livres qui ne
sadressent ni aux enfants, ni lenseignement ne sont pas distingus et
appartiennent collectivement la classe des livres. Les proprits gnrales des
livres, comme le nom de lauteur ou le nombre de pages, sont dfinies dans la
super-classe Livre. Chaque sous-classe reprend ces caractristiques et peut en
ajouter de nouvelles, comme la fourchette dge des lecteurs dans le cas du livre
pour enfants.
Livre
Auteur
Nombre de pages
Livre pour les enfants

Fourchette des ges
Livre pour l'enseignement

Discipline
Niveau
Figure 70 : Les livres pour enfants et ceux pour lenseignement reprennent les caractristiques
gnrales des livres.
La gnralisation sous sa forme dite multiple existe galement entre arbres de

classes disjoints. Dans lexemple suivant, la classe T est issue de la combinaison
des classes Y et Z.
Y
T
Proprit caractristique de T
Figure 71 : Exemple de gnralisation multiple partir darbres de classes disjoints.
Dans le monde des ensembles, la situation prcdente correspond lintersection

de deux ensembles qui ne sont pas sous-ensembles du mme sur-ensemble.
Figure 72 : Reprsentation ensembliste de la gnralisation multiple entre classes sans

anctre commun.
Le diagramme suivant illustre une situation particulirement intressante. Les

ensembles Y et Z partitionnent lensemble X, de sorte que les objets de
lensemble X appartiennent forcment lun de ses sous-ensembles. La proprit
caractristique P (X) ne dcrit pas directement les lments de X. P(X) est une
description abstraite des lments de Y et Z obtenue par une factorisation opre
sur P (Y) et P (Z).
Figure 73 : Lensemble X est scind en deux sous-ensembles disjoints Y et Z qui contiennent

collectivement tous les objets de X. P (X) est une factorisation opre sur P (Y) et P (Z).
Dans le monde des classes, la situation prcdente met en jeu une classe
abstraite, cest--dire une classe qui ne donne pas directement des objets. Elle
sert en fait de spcification plus abstraite pour des objets instances de ses sousclasses. Le principal intrt de cette dmarche est de rduire le niveau de dtails
dans les descriptions des sous-classes. Le nom dune classe abstraite est en
italique dans les diagrammes de classes.
Classe abstraite
Classe concrte A
Le nom des
classes abstraites
est en italique
Classe concrte B
Figure 74 : Reprsentation graphique dune classe abstraite.
Les classes abstraites facilitent llaboration de logiciels gnriques, facilement

extensibles par sous-classement. Lensemble des mcanismes qui servent de
charpente pour les fonctions des applications est construit partir des lments
gnraux fournis par les classes abstraites. Les spcificits et les extensions sont
encapsules dans des sous-classes concrtes.
Dans les exemples prcdents, les sous-ensembles Y et Z sont disjoints. Dans
lexemple suivant, lintersection de Y et Z est non nulle et dfinit lensemble T. T
regroupe lensemble des objets qui appartiennent la fois la classe Y et la
classe Z. T est simultanment sous-ensemble de Y et de Z. La proprit
caractristique de lensemble T est lunion des proprits caractristiques des
ensembles Y et Z et de la proprit caractristique de T lui-mme.
Figure 75 : La proprit caractristique de lensemble T intersection des ensembles Y et Z

contient lunion des proprits caractristiques des ensembles Y et Z.
En termes de classes, la situation prcdente se reprsente de la manire

suivante :
X
T
Proprit caractristique de T
Figure 76 : Exemple de gnralisation en losange. Les objets instances de la classe T sont

dcrits simultanment par les classes X, Y, Z et T.
Les objets de la classe T sont dcrits une seule fois par la proprit
caractristique de X. Le nombre de branches de la gnralisation nest pas
significatif pour la propagation des proprits caractristiques et ainsi T ne
possde pas deux fois la proprit caractristique de X.
Les objets sont instances dune classe ou ne le sont pas ; il nest pas possible
dtre plusieurs fois instance de la mme classe.
De la difficult de classer
La classification n'est pas toujours une opration triviale. En effet, la
dtermination des critres de classification est difficile et dans certains cas il n'est
pas possible de se dterminer. En 1755, bien avant UML, Jean-Jacques Rousseau,
dans louvrage Discours sur lorigine et les fondements de lingalit parmi les
hommes, voque le problme de la classification dans les termes suivants :
Chaque objet reut dabord un nom particulier, sans gard aux genres et aux
espces (...). Si un chne sappelait A, un autre chne sappelait B ; car la
premire ide que lon tire de deux choses, cest quelles ne sont pas la mme ;
et il faut souvent beaucoup de temps pour observer ce quelles ont de commun :
de sorte que plus les connaissances taient bornes, et plus le dictionnaire
devint tendu. Lembarras de toute cette nomenclature ne put tre lev
facilement, car, pour ranger les tres sous des dnominations communes et
gnriques, il en fallait connatre les proprits et les diffrences ; il fallait des
observations et des dfinitions, cest--dire de lhistoire et de la mtaphysique,
beaucoup plus que les hommes de ce temps-l nen pouvaient avoir.
Les classifications doivent avant tout bien discriminer les objets. Les bonnes
classifications sont stables et extensibles. Il arrive quelles comportent des
exceptions inclassables selon les critres retenus. Le grand panda, par exemple,
fait partie de la famille des ours alors que le petit panda est plus proche des ratons
laveurs. Lornithorynque appartient la famille des mammifres tout en tant
ovipare.
Les classifications seffectuent selon des critres dpendant du point de vue. Il
n'y a donc pas une classification, mais des classifications, chacune adapte un
usage donn.
Ainsi, pour les animaux, de nombreux critres peuvent tre retenus :
la station,
le type de nourriture,
la protection.
La dtermination des critres pertinents et de lordre dans lequel ils doivent tre
appliqus nest pas toujours facile. Une fois les critres arrts, il faut les suivre
de manire cohrente et uniforme selon lordre dtermin.
Lordre dapplication des critres est souvent arbitraire, et conduit des
dcompositions covariantes qui se traduisent par des parties de modle
isomorphes.
Dans lexemple suivant, le critre de la station a t appliqu avant le critre de la
nourriture. Sans informations supplmentaires, il est bien difficile de dire pourquoi
ce choix a t effectu.
Animal
Bipde
Herbivore
Quadrupde
Carnivore
Herbivore
Carnivore
Covariance
Figure 77 : Premire forme de dcomposition covariante.
Les animaux peuvent tout aussi bien tre spcialiss dabord par rapport leur
type de nourriture.
Animal
Herbivore
Bipde
Quadrupde
Carnivore
Bipde
Quadrupde
Covariance
Figure 78 : Deuxime forme de dcomposition covariante.
En fait, aucune des solutions prcdentes nest satisfaisante, car le phnomne

de covariance induit des points de maintenance multiples dans le modle.
La gnralisation multiple apporte une solution lgante pour la construction de
classifications comportant des critres indpendants, difficiles ordonner. Les
critres indpendants dterminent diffrentes dimensions de spcialisation et les
classes concrtes sont obtenues par produit cartsien de ces diffrentes
dimensions.
Animal
Station
Protection
Nourriture
Bipde
Quadrupde
Herbivore Carnivore
A plumes
A poils
A cailles
Lapin
Figure 79 : Exemple de rduction de la covariance au moyen de la gnralisation multiple.
Dans certains cas, la covariance existe du fait mme de la nature du domaine de

lapplication. Lexemple suivant illustre ce propos : un pilote de moto d'enduro
doit possder une licence d'enduro et un pilote de moto de cross doit possder
une licence de cross. Cette forme de covariance nest pas rductible car elle
concerne deux hirarchies distinctes.
Pilote
1
0..*
0..*
Moto
Cross
Enduro
Licence
Cross
Enduro
Covariance non rductible
Figure 80 : Exemple de covariance non rductible.
Les classifications doivent galement comporter des niveaux dabstractions

quilibrs. Dans lexemple suivant, la dcomposition n'est pas effectue de
manire homogne. Les deux premires sous-classes spcialisent selon la
fonction du vhicule alors que la troisime sous-classe correspond une marque
de moto.
Vhicule terrestre
Voiture
Camion
Monet et Goyon
Figure 81 : Exemple de classification dsquilibre.
Lnumration de toutes les marques nest pas non plus une bonne ide car cela
cr normment de sous-classes. Il vaut mieux favoriser le critre le plus global
car cest lui qui donnera des sous-classes plus extensibles. En rgle gnrale, il
vaut mieux limiter le nombre de sous-classes chaque niveau hirarchique, quitte
augmenter le nombre dobjets par classe et se rserver les attributs dobjets
pour qualifier finement les objets.
La drive vers un trop grand nombre de classes est illustre dans lexemple
suivant. Dune part, le critre de la couleur est trop prcis pour dterminer une
classe et dautre part, il gnre trop de classes. Enfin, du fait du lien statique entre
classe et instance, le modle ne permet pas de changer la couleur dune voiture !
Il faut en fait que le critre de gnration dune classe soit statique. La couleur
doit tre un attribut des vhicules, pas un critre de spcialisation.
Vhicule terrestre
Voiture
Voiture bleue
Voiture rouge
Voiture verte
Figure 82 : Exemple de mauvais critre pour la dtermination des classes.
La forme classique de la relation de gnralisation de classes introduit un

couplage statique trs fort dans le modle, non mutable, comme le lien entre un
objet et sa classe. De ce point de vue, la gnralisation nest pas adapte pour
reprsenter les mtamorphoses. Lexemple suivant ne reprsente pas
correctement le cas du papillon qui passe successivement du stade de chenille, au
stade de chrysalide puis au stade de lpidoptre.
Papillon
Chenille
Chrysalide
Lpidoptre
Figure 83 : Le modle ci-dessus nest pas adapt pour reprsenter les papillons, car la
relation qui lie un objet sa classe nest pas mutable.
La solution pour la reprsentation des papillons consiste sortir llment

mutable. Dans notre cas, lapparence dun papillon donn est traduite par un lien
vers un objet spcifique qui dcrit son stade.
Papillon
Apparence
Stade
Chenille
Chrysalide
Lpidoptre
Figure 84 : Exemple dextraction de llment mutable. Lobjet qui matrialise lapparence

du papillon peut changer pendant son existence.
Lapproche gnrale pour dynamiser une classification consiste, comme dans le

cas de la mutabilit, extraire le ou les lments sujets spcialisation. Cette
approche permet galement la classification multiple, au moyen dune multiplicit
de valeur illimite.
Classe
Ralise >
Type
*
Type A
Type B
Type C
Figure 85 : Forme gnrale de la classification dynamique.
Le diagramme suivant montre un exemple de ralisation dune classification selon

la forme prcdente, mais sans gnralisation. Sur chaque livre est colle une
gommette dont la couleur permet par de distinguer le propritaire ou de prciser la
nature de louvrage.
Livre
Gommette
1 Couleur
Figure 86 : Exemple de classification ralise par un systme de gommettes de couleur.
Lhritage
Il existe de nombreuses manires de raliser la classification. En programmation
objet, la technique la plus utilise repose sur lhritage entre classes.
Principe gnral
Lhritage est une technique offerte par les langages de programmation pour
construire une classe partir dune ou plusieurs autres classes, en partageant des
attributs, des oprations et parfois des contraintes, au sein d'une hirarchie de
classes. Les classes enfants hritent des caractristiques de leurs classes
parents ; les attributs et les oprations dclars dans la classe parent, sont
accessibles dans la classe enfant, comme sils avaient t dclars localement.
Lhritage est utilise pour satisfaire deux besoins distincts : la classification et la
construction. Cette ambivalence de la relation dhritage, qui peut la fois classer
et construire, est la source de beaucoup dincohrences de programmation. Il en
est de lhritage comme de la conduite automobile ; il faut se tenir ni trop droite
ni trop gauche, mais bien au milieu de la voie, sinon le risque daccident est
lev. Il faut apprendre utiliser correctement lhritage, comme il faut apprendre
conduire les voitures.
En programmation, avec un langage objet comme C++, la classification se ralise
trs souvent par une relation dhritage entre la classe plus gnrale et la classe
plus spcifique. Lhritage propage les caractristiques de la classe parent dans
les classes enfants, de sorte que plusieurs classes peuvent partager une mme
description. De ce point de vue, lhritage permet une description conomique
dun ensemble de classes relies par une relation de classification.
De nombreux programmeurs effectuent un amalgame entre la notion de
classification implique par lhritage et la composition virtuelle qui en rsulte.
Ces programmeurs recherchent avant tout une conomie dexpression court
terme ; ils ont pris lhabitude dintgrer des composants dans un compos en
exploitant la propagation des caractristiques ralise automatiquement par la
relation dhritage. La construction de composants par hritage est une technique
de programmation parfaitement respectable, condition de clairement matrialiser
le fait dans le programme. Lorsque le programmeur construit par hritage, il doit
indiquer que la relation dhritage concerne est utilise pour la construction et
non pour la classification. Le langage C++, par exemple, permet de distinguer
lhritage pour la classification, de lhritage pour la construction, par lusage des

mots-cls public et private.
class Truc : private
Parent_Pour_Construction,
public Parent_Pour_Classification
{
...
} ;
Figure 87 : Distinction entre hritage pour la classification et hritage pour la construction.
La distinction doit tre opre visuellement dans les diagrammes de classes,

comme le montre lexemple suivant : un smaphore nest ni une liste chane, ni
un compteur, mais peut se construire partir de ces deux composants.
Liste chane
Compteur
Construction
Construction
Smaphore
Figure 88 : Reprsentation graphique de lhritage pour la construction.
Cette distinction se fait essentiellement en conception o, sauf indication

contraire, lhritage reprsente une relation de gnralisation plutt quune
relation de composition.
Lhritage est entach de contingences de ralisation et, en particulier, lhritage
neffectue pas une union des proprits caractristiques des classes, mais plutt
une somme de ces proprits. Ainsi, certaines caractristiques peuvent tre
indment dupliques dans les sous-classes. Lhritage multiple doit donc tre
mani avec beaucoup de prcautions car les techniques de ralisation de
lhritage peuvent induire des problmes de collision de noms lors de la
propagation des attributs et des oprations des classes parents vers les sousclasses.
Lexemple suivant illustre un conflit de nom, consquence dune relation
dhritage multiple ralise par copie. Les super-classes dfinissent toutes les
deux un attribut A de sorte que la classe Z possde deux attributs A. Si A
reprsente exactement la mme notion dans les classes X et Y, il ny a pas de
raison de propager deux attributs dans la sous-classe. En revanche, si A dsigne
deux proprits diffrentes, il serait judicieux den renommer une afin de pouvoir
les distinguer. Il nexiste pas de rponse toute faite ce problme : les langages
objet diffrent dans leur manire de le traiter.
Z
A de X
A de Y
Figure 89 : Exemple de collision de noms. Le nom A est dfini dans les deux super-classes X
et Y.
Le conflit prcdent apparat galement dans les formes de gnralisation en

losange, la diffrence prs quil ny a vraiment pas de raisons de dupliquer
lattribut A dans la classe Z, tant donn que lattribut A est unique dans la classe
T. Z est une sorte de T, et non plusieurs fois une sorte de T ! Ici aussi, chaque
langage objet apporte sa propre rponse ce type de problme.
T
A
A de T
A de T
Z
A de T par X
A de T par Y
Figure 90 : Exemple de collision de noms dans le cas dune forme dhritage en losange.
Cette situation est suffisamment ennuyeuse pour que certains langages objet,
comme Java ou Ada 95, noffrent pas dhritage multiple. Dans la pratique,
lhritage multiple peut tre employ sans trop de soucis lorsque sa mise en
uvre a accompagn llaboration du modle depuis le dbut. Par contre, il y a
fort peu de chances pour que lhritage multiple soit la manire deffectuer une
fusion entre deux ensembles de classes construits de manire totalement

indpendante. En conclusion : lusage de lhritage multiple doit tre anticip !
Paquetage A
Paquetage B
XA
XB
Mlange
Hasardeux !!!
Figure 91 : Lhritage multiple nest pas adapt pour la construction dune classe par fusion
de plusieurs classes issues de paquetages labors de manire indpendante.
La dlgation
Lhritage nest pas une ncessit absolue et peut toujours tre remplac par la
dlgation. La dlgation prsente lavantage de rduire le couplage dans le
modle : dune part, le client ne connat pas directement le fournisseur, et dautre
part, le fournisseur peut tre modifi en cours de route. Cette approche permet la
mise en uvre de la gnralisation multiple avec les langages qui ne possdent
que lhritage simple. Le diagramme suivant illustre le mcanisme de dlgation ;
le client communique avec une interface qui propage les questions un ou
plusieurs dlgus.
: Client
Question
Propagation
: Dlgu 1
: Interface
Propagation
: Dlgu 2
Figure 92 : Exemple de mcanisme de dlgation. Linterface dcouple le client et les

fournisseurs.
La dlgation permet galement de contourner le problme de la covariance,

voqu plus haut, au dtriment toutefois de la propagation automatique des
caractristiques des super-classes vers les sous-classes. Le diagramme suivant
illustre une construction base de dlgation qui peut remplacer la gnralisation
multiple.
Animal
Station
Bipde
Nourriture
Quadrupde
Herbivore
Carnivore
Figure 93 : Exemple de rduction de la covariance par la dlgation.
Dans le systme de fentres X Window, plus prcisment dans la couche des

Intrinsics, lhritage est entirement simul la main, grce la mise en uvre de
structures de donnes qui dsignent les structures de donnes des parents. Les
diagrammes suivants illustrent lexemple de Douglas A. Young7 pour la ralisation
de lhritage lors de la construction de widgets.
Core
...
Basic
ignore : int
foreground : int
gc : GC
Figure 94 : Exemple dhritage entre widgets dans le systme de fentres X Window.
Le systme X Window est entirement ralis en C, sans support direct pour

lhritage. Le diagramme suivant montre comment lhritage est simul la main,
en incorporant une description de la classe parent CoreClassPart dans la
classe drive BasicClassRec. La classe BasicPart regroupe les variables
Young D. A. 1990, The X Window System, Programming and Applications with

Xt. Prentice Hall, Englewood Cliffs, New Jersey, pp 340-341.
dinstance et contient une rfrence vers la description de la classe

BasicClassRec.
BasicClassRec
class
1
core_class 1
BasicPart
foreground : int
* gc : GC
basic_class
CoreClassPart
BasicClassPart
...
ignore : int
Figure 95 : Exemple de ralisation de lhritage la main par incorporation de la classe

parent dans la classe drive.
Le principe de substitution
La classification propage ltat, le comportement et les contraintes. Il ny a pas de
demi-mesure : toutes les proprits de la classe parent sont valables intgralement
pour la classe enfant. Le besoin dhriter partiellement est le signe que la relation
dhritage considre ne ralise pas vraiment une relation de classification.
Le principe de substitution, nonc originellement par Liskow8, permet de
dterminer si une relation dhritage est bien employe pour la classification. Le
principe de substitution affirme que :
il doit tre possible de substituer nimporte quel objet instance dune sousclasse nimporte quel objet instance dune super-classe sans que la
smantique du programme crit dans les termes de la super-classe ne soit
affecte.
Lillustration suivante montre un programme symbolis par un rectangle qui
fait rfrence des objets de la classe parent. Si le principe de substitution est
vrifi, tout objet instance de la classe CP doit pouvoir tre remplac par un objet
instance de la classe CE, sans que cela naffecte le programme crit dans les
termes de la classe CP.
Liskow B. 1987, Proceedings of OOPSLA87. ACM SIGPLAN Notices 23 (5), pp

17-34.
CP
CE
Un programme crit selon les termes de la classe parent

Figure 96 : Illustration du principe de substitution.
La notion de gnralisation implique que la proprit caractristique de la superclasse est incluse dans la proprit caractristique de la sous-classe. Or, les
compilateurs de certains langages ne sont pas capables de vrifier intgralement
que cette condition est satisfaite dans le cas de lhritage, car la syntaxe seule ne
suffit pas toujours pour exprimer lensemble des proprits. Les attributs et les
oprations sont propags automatiquement, mais les contraintes ne le sont pas
ncessairement. Souvent, une contrainte est traduite par une forme de code
particulire, implante dans la ralisation dune opration. Comme les langages
objet permettent la redfinition des oprations dans les sous-classes, les
programmeurs peuvent involontairement introduire des incohrences entre la
spcification dune super-classe et la ralisation dans une des sous-classes. Ces
incohrences concernent principalement les contraintes exprimes de manire
programme et non dclarative. Ladhrence au principe de substitution garantit
quune relation dhritage entre classes correspond bien une gnralisation.
Malheureusement, la mise en uvre du principe de substitution est du ressort du
programmeur et non du compilateur et, comme le programmeur est humain, il nest
pas labri dune erreur. Sans respect du principe de substitution, le
polymorphisme dcrit dans le paragraphe suivant ne peut tre mis en uvre.
Le polymorphisme
Le terme polymorphisme dcrit la caractristique dun lment qui peut prendre
plusieurs formes, comme leau qui se trouve ltat solide, liquide ou gazeux. En
informatique, le polymorphisme dsigne un concept de la thorie des types, selon
lequel un nom dobjet peut dsigner des instances de classes diffrentes issues
dune mme arborescence.
Principe gnral
Les interactions entre objets sont crites selon les termes des spcifications
dfinies, non pas dans les classes des objets, mais dans leurs super-classes.
Ceci permet dcrire un code plus abstrait, dtach des particularismes de chaque
classe, et dobtenir des mcanismes suffisamment gnraux pour tre encore
valides dans le futur, quand seront crs de nouvelles classes.
Le terme polymorphisme dsigne dans ce cas particulier le polymorphisme

dopration, cest--dire la possibilit de dclencher des oprations diffrentes en
rponse un mme message. Chaque sous-classe hrite de la spcification des
oprations de ses super-classes, mais a la possibilit de modifier localement le
comportement de ces oprations, afin de mieux prendre en compte les
particularismes lis un niveau dabstraction donn. De ce point de vue, une
opration donne est polymorphe puisque sa ralisation peut prendre plusieurs
formes.
Le polymorphisme est un mcanisme de dcouplage qui agit dans le temps. Les
bnfices du polymorphisme sont avant tout rcolts durant la maintenance. Le
polymorphisme ninfluence pas lanalyse, mais dpend de lanalyse : sa mise en
uvre efficace repose sur lidentification de mcanismes abstraits, applicables de
manire uniforme des objets instances de sous-classes diffrentes. Il ne faut pas
penser lanalyse en termes de polymorphisme, il faut penser lanalyse en termes
dabstraction et ainsi, par effet de bord bnfique de cette abstraction, rendre
possible le polymorphisme.
Application
Le diagramme suivant reprsente une collection polymorphe, le zoo. Le zoo
contient de nombreux animaux qui peuvent tre soit des lions, soit des tigres, soit
des ours. Le nom Animal, connu de la classe Zoo, dcrit collectivement toutes
les sortes danimaux. Le logiciel, crit au niveau dabstraction du zoo, na pas
besoin de connatre les dtails propres chaque animal.
Zoo
Animal
1
Lion
Tigre
Ours
Figure 97 : Exemple de collection polymorphe.
Les animaux de lexemple prcdent savent tous dormir, mais chaque race a ses
habitudes particulires. La spcification de lanimal dit que les animaux peuvent
dormir. Les sous-classes particularisent lopration Dormir() selon les gots
de chaque race. Le diagramme suivant montre comment chaque race danimaux
lhabitude de dormir.
Animal
Zoo
1
* Dormir( )
Lion
Dormir ()
{
Sur le ventre
}
Tigre
Dormir ()
{
Sur le dos
}
Ours
Dormir ()
{
Dans un arbre
}
Figure 98 : Exemple de spcialisation dune opration.
Les mcanismes gnraux crits selon la spcification du zoo nont pas besoin de
connatre les gots particuliers de chaque genre danimal pour invoquer
lopration Dormir(). Ainsi, le soir venu, le gardien se promne au travers du
zoo et informe chaque animal quil est temps de dormir.
Le zoo
Dormir
Le gardien
: Animal
Figure 99 : Envoi du message Dormir() tous les animaux du zoo.
En termes plus informatiques, ceci revient visiter la collection Zoo en utilisant

ventuellement un itrateur, et envoyer le message Dormir chaque animal.
Un itrateur est un objet associ une collection qui permet den visiter tous ses
lments sans en dvoiler sa structure interne.
Litrateur est dit actif lorsque le contrle de litration est laiss lutilisateur, au
moyen des quatre oprations suivantes :
Initialiser qui permet de prendre en compte des lments prsents un

instant donn dans la collection,
Suivant qui permet le passage llment suivant,
Valeur qui retourne llment courant,
Termin qui est vrai lorsque tous les lments ont t visits.
Itrateur
Collection
Liste
Pile
< Manipule
Suivant( )
Initialiser( )
Valeur( )
Termin( )
File
Figure 100 : Exemple ditrateur actif.
Le fragment de code suivant illustre lusage dun itrateur sur le zoo.

La variable UnAnimal est polymorphe : elle peut contenir nimporte quel animal
retourn par la fonction Visite.Valeur(). Lenvoi du message Dormir()
lanimal contenu par la variable UnAnimal dclenche une manire spcifique
de dormir qui dpend en fait de la sous-classe de lanimal.
Visite : Itrateur ;
UnAnimal : Animal ; -- variable polymorphe
...
Visite.Initialiser(leZoo);
while not Visite.Termin()
loop
UnAnimal := Visite.Valeur () ;
UnAnimal.Dormir();
Visite.Suivant();
end loop;
Figure 101 : Exemple de code pour endormir tous les animaux du zoo.
Le mcanisme qui endort les animaux du zoo est indpendant des animaux qui se
trouvent rellement dans le zoo un moment donn : leffectif de chaque espce
nest pas inscrit dans lalgorithme qui se contente dexploiter un itrateur sur une
collection. Le mcanisme ne dpend pas non plus de la sous-classe prcise de
lanimal courant : si de nouveaux animaux sont ajouts dans le zoo, il nest pas
ncessaire de modifier le code qui endort les animaux existants pour endormir les
nouveaux arrivants. Les particularits des nouveaux animaux sont encapsules
dans leur classe qui est rajoute dans le modle par drivation de la classe
Animal dj existante. Pour prendre en compte un nouvel animal, il suffit donc
de crer une sous-classe, de raliser lopration Dormir() dont il hrite, et
ventuellement de recompiler.
Animal
Zoo
1
* Dormir( )
Lion
Dormir ()
{
Sur le ventre
}
Tigre
Dormir ()
{
Sur le dos
}
Ours
Paresseux
Dormir ()
{
Dans un arbre
}
Dormir ()
{
Sans fin
}
Figure 102 : Exemple de prise en compte dun nouvel animal par ajout dune sous-classe.
La recherche automatique du code excuter est le fruit de la liaison dynamique.

Dans les langages traditionnels comme Pascal, le choix dune opration est une
activit compltement statique, effectue la compilation en fonction du type des
variables. Dans les langages liaison dynamique, le dclenchement dune
opration requiert une activit durant lexcution pour retrouver la ralisation de
lopration qui correspond au message reu. Sans liaison dynamique, le code
prcdent devrait tre transform de la faon suivante :
Visite : Itrateur ;
UnAnimal : Animal ; -- variable polymorphe
...
Visite.Initialiser(leZoo);
while not Visite.Termin()
loop
UnAnimal := Visite.Valeur () ;
case UnAnimal.Classe ()
when Lion
-- Dormir sur le ventre
When Tigre
-- Dormir sur le dos
When Ours
-- Dormir dans un arbre
When Paresseux
-- Dormir sans fin
end case;
Visite.Suivant();
end loop;
Figure 103 : Sans liaison dynamique, le programmeur doit effectuer lui-mme le choix de
lopration qui correspond au message Dormir().
Cette solution sans liaison dynamique prsente le dsavantage dintroduire de

nombreux points de maintenance dans le code. Chaque fois quun nouvel animal
est ajout dans le zoo, il faut ajouter une branche dans linstruction case pour
prendre en compte les spcificits du nouvel arrivant.
Le polymorphisme supprime ces points de maintenance et du mme coup rduit
considrablement lusage des instructions branchements multiples dans les
mcanismes qui nont pas besoin de connatre explicitement la classe dun objet.
Les oprations du type Class_Of, comme celle employe dans lexemple
prcdent (case UnAnimal.Classe()), qui retournent la classe dun objet,
doivent alors tre utilises avec circonspection, car leur usage va lencontre du
polymorphisme. Un mcanisme crit selon les termes dune super-classe doit
pouvoir ignorer les dtails prciss dans les sous-classes.
Lexemple prcdent montre galement quil est possible demployer un langage
liaison statique plutt que dynamique aprs une analyse objet, mais que leffort
de ralisation est suprieur puisquil faut organiser manuellement le
dclenchement des oprations.
Exploitation du principe de substitution

Lexemple prcdent ne fonctionne que si chaque animal comprend le message
Dormir(). Les mcanismes qui mettent en uvre le polymorphisme manipulent
des objets au travers des spcifications de leurs super-classes. Dans le cas dun
langage typ, le compilateur peut vrifier statiquement que les messages seront
compris par un objet, soit parce quune opration est dclare dans la classe
mme de lobjet, soit parce que cette opration est hrite dune des superclasses. Cette vrification syntaxique ne suffit toutefois pas garantir un bon
comportement polymorphe ; il faut en plus que les ralisations des oprations
dans les sous-classes soient conformes aux spcifications donnes dans les
super-classes, en particulier aux contraintes qui les accompagnent. Pour que le
polymorphisme fonctionne effectivement, il faut au-del de la syntaxe seule
que le principe de substitution soit vrifi.
Lexemple suivant illustre une violation du principe de substitution. Le
programmeur dcide de faire driver lautruche de loiseau pour obtenir les
plumes et le bec, mais ne respecte pas la spcification de lopration Voler()
en ralisant un code qui ne fait pas voler lautruche.
Oiseau
Plumes
Bec
Voler ()
{
Mettre la tte dans le sable
}
Voler( )
Msange
Moineau
Autruche
Figure 104 : Exemple de violation du principe de substitution.
La malversation prcdente ne porte pas consquence tant que personne ncrit

de mcanisme gnral pour manipuler les oiseaux. En revanche, ds lors que des
mcanismes gnraux exploitent la spcification de la classe Oiseau, par
exemple pour faire senvoler tous les types doiseaux en cas de danger,
lincohrence introduite dans la classe Autruche se traduit au mieux par une
autruche qui se fait manger et au pire par la situation la plus catastrophique qui
puisse arriver en application de la loi de Murphy.
Le diagramme de collaboration suivant montre comment une petite autruche se
fait manger par un gros chat !
S'envoler
S'envoler
: Moineau
Voler
Voler
: Msange
: Sauveteur
Voler
Enterrer sa tte
Une petite autruche

Un gros chat
Miam miam !!!
Figure 105 : Exemple de non respect du principe de substitution. La petite autruche ne se

comporte pas comme un oiseau et se fait dvorer par le gros chat.
Dclenchement des oprations

Ce paragraphe a pour objectif de prsenter les grandes lignes du mcanisme de
liaison dynamique, indpendamment des particularits syntaxiques des langages
de programmation. Les diffrentes tapes de lexemple montrent les formes de
dclenchement dune opration en fonction de la classe de lobjet qui reoit le
message.
Le diagramme de classes suivant dcrit la hirarchie des classes qui sert de
support la discussion, et montre la dfinition et les ralisations de lopration Z
qui sera dclenche. Les classes abstraites I et J ne sont pas instanciables.
I
Z( )
Classe
abstraite
J
Classe
abstraite
Z de I( )
K
Z selon K( )
L
Z de K( )
M
Z selon M( )
Ralisation
de Z
Hritage
de Z
Modification
de Z
Figure 106 : Exemple de hirarchie de classes. Lopration Z est dfinie dans la classe de
base I, puis ralise dans la classe K et modifie dans la classe M.
Les objets de la classe Client possdent des liens polymorphes vers des
objets des classes K, L ou M.
: K, L ou M
Un_I
Un Client
Un_K
: K, L ou M
Un_L
Un_M
: L ou M
:M
Figure 107 : Chaque objet de la classe Client peut communiquer avec quatre objets
instances des classes concrtes K, L ou M.
Le lien Un_I est polymorphe et peut dsigner un objet instance dune classe
concrte drive de I par exemple la sous-classe K. Le client peut ainsi manipuler
un objet instance dune sous-classe, au travers de la spcification dune superclasse. Toutes les caractristiques de la super-classe sappliquent aux objets
instances des sous-classes, en particulier le message Z peut tre envoy
lobjet Un_K le long du lien polymorphe Un_I.
Le code correspondant lopration Z est recherch lexcution en descendant
larbre dhritage jusqu la classe prcise de lobjet. La classe K ralise
lopration Z, le message est compris et lopration ralise dans la classe K est
excute.
Un Client
Un_I
Un K
Z()
Lien
polymorphe
Dclenchement
de l'opration Z
ralise dans K
Figure 108 : Le lien Un_I dsigne un objet de la classe K. Le message est compris, car la
classe K ralise lopration Z.
Le cas de figure suivant est proche du cas prcdent, si ce nest que la recherche
seffectue un cran plus bas dans la hirarchie. La classe L nayant pas modifi la
ralisation de lopration Z hrite de la classe K, le mme comportement que
prcdemment est dclench.
Un Client
Un_I
Un L
Z()
Lien
polymorphe
Dclenchement
de l'opration Z
ralise dans K
Figure 109 : La ralisation de lopration Z prsente dans la classe L est hrite de la classe
K. A lexcution, le comportement ralis dans la classe K sera dclench.
Toute classe intermdiaire dans larborescence des classes peut fournir une
spcification pour manipuler les objets instances de ses sous-classes. A ce titre,
le lien Un_L peut tre exploit de manire polymorphe pour manipuler des objets
instances de la classe M. Comme M modifie lopration Z, lexpression Un_L.Z()
dclenche le code ralis dans la classe M.
Un Client
Un_L
Un M
Z()
Lien
polymorphe
Dclenchement
de l'opration Z
modifie dans M
Figure 110 : Utilisation de la spcification dune classe de niveau intermdiaire.
La liaison dynamique nest ncessaire que pour rechercher automatiquement le

code modifi dans les sous-classes et appel depuis la spcification dune superclasse. Lorsque la liaison dynamique nest pas requise, les passages de messages
peuvent tre avantageusement remplacs par de simples appels de procdures
rsolus statiquement. Les langages comme C++ ou Ada 95 autorisent le
programmeur choisir le type de liaison au coup par coup, opration par
opration, selon les besoins. En Eiffel, le programmeur na pas se soucier du
choix de la liaison car le compilateur est suffisamment intelligent pour reconnatre
les liaisons qui seront toujours statiques.
Dans lexemple suivant, la liaison peut tre statique dune part parce que le lien
Un_K dsigne un objet de classe K et dautre part parce que lopration Z est
ralise dans cette classe.
Un Client
Un_K
Un K
Z()
Lien
polymorphe
Dclenchement
de l'opration Z
ralise dans K
Figure 111 : Situation rsoluble statiquement.
Le code qui exploite le polymorphisme se caractrise par la quasi-absence

dinstructions branchements multiples (case, switch). Ceci est d au fait que
les branchements sont raliss de manire implicite en fonction de la classe de
lobjet destinataire du message lors de la recherche de lopration excuter en
rponse la rception dun message.
Influence du typage
Le polymorphisme existe dans les environnements typs comme dans les
environnements non typs, mais seuls les environnements typs garantissent
une excution sans surprise des programmes condition toutefois de respecter
le principe de substitution. La notion de typage permet au compilateur de vrifier
statiquement que les messages envoys un objet seront compris lors de
lexcution. En Ada 95, en Eiffel, en C++ ou en Java, les messages sont toujours
compris par le destinataire du fait du typage fort. En labsence de typage fort,
nimporte quel message peut tre envoy nimporte quel objet. En Smalltalk, un
message peut ne pas tre compris et lexpditeur doit donc se prparer cette
ventualit. Ceci nenlve rien la vertu de la liaison dynamique, toujours utile
pour trouver le code le plus adapt en fonction de la classe. Mais la diffrence
des langages typs, la recherche peut tre infructueuse.
Il importe de ne pas confondre le polymorphisme avec la surcharge des
oprations, parfois appele polymorphisme ad hoc. Certains langages autorisent
lemploi dun mme nom pour dsigner une famille doprations, avec un profil de
paramtres diffrent pour chaque opration. La surcharge est un moyen lgant
doffrir la notion de signature variable, sans tomber dans le travers des oprations
nombre de paramtres variable comme en C. La surcharge est toujours rsolue
statiquement par les compilateurs, elle na rien voir avec la liaison dynamique.
Les heureux parents reconnatront le comportement de leur progniture dans la
classe suivant. Lopration Manger() est surcharge : elle existe sous trois
formes diffrentes, identifiables statiquement par le compilateur en fonction de la
signature.
Enfant
Manger ()
Manger (Lentement : Boolen = Vrai)
Manger (Lentement : Boolen, Comme_Un_Cochon : Boolen)
Figure 112 : Exemple dune opration surcharge. La classe Enfant propose trois
oprations Manger() diffrentes, identifiables statiquement par leur signature.
3
La notation UML
La notation UML est une fusion des notations de Booch, OMT, OOSE et dautres
notations. UML est conue pour tre lisible sur des supports trs varis comme
les tableaux blancs, le papier, les nappes de restaurants, les crans dordinateurs,
les impressions en noir et blanc, etc. Les concepteurs de la notation ont recherch
avant tout la simplicit ; UML est intuitive, homogne et cohrente. Les symboles
embrouills, redondants ou superflus ont t limins en faveur dun meilleur
rendu visuel.
UML se concentre sur la description des artefacts du dveloppement de logiciel,
plutt que sur la formalisation du processus de dveloppement lui-mme : elle
peut ainsi tre utilise pour dcrire les lments logiciels, obtenus par
lapplication de diffrents processus de dveloppement. UML nest pas une
notation ferme : elle est gnrique, extensible et configurable par lutilisateur.
UML ne recherche pas la spcification outrance : il ny a pas une reprsentation
graphique pour tous les concepts imaginables ; en cas de besoins particuliers,
des prcisions peuvent tre apportes au moyen de mcanismes dextension et de
commentaires textuels. Une grande libert est donne aux outils pour le filtrage et
la visualisation dinformation. Lusage de couleurs, de dessins et dattributs
graphiques particuliers est laiss la discrtion de lutilisateur.
Ce chapitre propose un survol de la smantique des lments de modlisation
dUML, dcrits de manire prcise dans le document UML 1.0, Semantics 9. Cette
prsentation a pour objectif dintroduire les principaux concepts de modlisation
et de montrer leur articulation au sein de la notation UML. Les lments de
visualisation et les lments de modlisation sont prsents conjointement, en se
Rational Software Corporation 1997, UML Semantics V 1.0.
servant de la notation comme dun support pour faciliter la prsentation de la

smantique.
UML dfinit neuf sortes de diagrammes pour reprsenter les diffrents points de
vue de modlisation. Lordre de prsentation de ces diffrents diagrammes ne
reflte pas un ordre de mise en uvre dans un projet rel, mais simplement une
dmarche pdagogique qui essaie de minimiser les prrequis et les rfrences
croises.
Les diagrammes dUML

Un diagramme donne lutilisateur un moyen de visualiser et de manipuler des
lments de modlisation. Les diffrents types de diagrammes dUML sont
prsents dans lextrait du mtamodle suivant.
Diagramme
Composants
Dploiement
Classes
Cas d'utilisation
Squence
Etats-Transitions
Activit
Objets
Collaboration
Figure 113 : Diffrents types de diagrammes dfinis par UML.
Un diagramme contient des attributs de placement et de rendu visuel qui ne

dpendent que du point de vue. La plupart des diagrammes se prsentent sous la
forme de graphes, composs de sommets et darcs. Les diagrammes contiennent
des lments de visualisation qui reprsentent des lments de modlisation
ventuellement issus de paquetages distincts, mme en labsence de relations de
visibilit entre ces paquetages 10.
Les diagrammes peuvent montrer tout ou partie des caractristiques des lments
de modlisation, selon le niveau de dtail utile dans le contexte dun diagramme
donn. Les diagrammes peuvent galement rassembler des informations lies
entre elles, pour montrer par exemple les caractristiques hrites par une classe.
Voici, par ordre alphabtique, la liste des diffrents diagrammes :
10
Car lutilisateur peut tout voir !
3 La notation UML 85
les diagrammes dactivits qui reprsentent le comportement dune opration

en termes dactions,
les diagrammes de cas dutilisation qui reprsentent les fonctions du

systme du point de vue de lutilisateur.
les diagrammes de classes qui reprsentent la structure statique en termes de

classes et de relations,
les diagrammes de collaboration qui sont une reprsentation spatiale des

objets, des liens et des interactions,
les diagrammes de composants qui reprsentent les composants physiques

dune application,
les diagrammes de dploiement qui reprsentent le dploiement des

composants sur les dispositifs matriels,
les diagrammes dtats-transitions qui reprsentent le comportement dune

classe en terme dtats,
les diagrammes dobjets qui reprsentent les objets et leurs relations et

correspondent des diagrammes de collaboration simplifis, sans
reprsentation des envois de message,
les diagrammes de squence qui sont une reprsentation temporelle des

objets et de leurs interactions.
Les diagrammes de collaboration et les diagrammes de squence sont tous deux

appels diagrammes dinteraction. Les diagrammes dtats-transitions sont
galement appels Statecharts11, nom donn par leur auteur, David Harel.
Concepts de base
Il est pratique de reprsenter la smantique des lments de modlisation dUML
selon le formalisme dUML.
Ce type de reprsentation rcursive pose cependant le problme de luf et de la
poule, principalement lors de lapprentissage. Cest pourquoi il est conseill, en
premire lecture, de considrer les diagrammes comme des exemples de la
notation, plutt que de chercher approfondir leur comprhension
Quoi quil en soit, les diagrammes montrent des vues simplifies du mtamodle
afin de rendre le texte accessible au plus grand nombre de lecteurs.
11

Les lments communs

Les lments sont les briques de base dUML. Les lments comprennent les
lments de modlisation et les lments de visualisation. Les lments de
modlisation reprsentent les abstractions du systme en cours de modlisation.
Les lments de visualisation procurent des projections textuelles ou graphiques
qui permettent la manipulation des lments de modlisation.
Les lments sont regroups en paquetages qui contiennent ou rfrencent les
lments de modlisation. Un modle est une abstraction dun systme,
reprsent par une arborescence de paquetages.
Paquetage
0..1
Possde
0..1
Modle
0..*
0..*
0..*
Rfrence
Elment
Elment de modlisation
Elment de visualisation
1..*
0..*
Projection
Figure 114 : Extrait du mtamodle. Reprsentation des deux grandes familles d'lments qui
forment le contenu des modles.
Les mcanismes communs

UML dfinit un petit nombre de mcanismes communs qui assurent lintgrit
conceptuelle de la notation. Ces mcanismes communs comprennent les
strotypes, les tiquettes, les notes, les contraintes, la relation de dpendance et
les dichotomies (type, instance) et (type, classe). Chaque lment
de modlisation possde une spcification qui contient la description unique et
dtaille de toutes les caractristiques de llment.
Les strotypes, les tiquettes et les contraintes permettent lextension dUML.
Les strotypes spcialisent les classes du mtamodle, les tiquettes tendent
les attributs des classes du mtamodle et les contraintes tendent la smantique
du mtamodle.
Relation
Dpendance
Source
Classification
Strotype
0..*
Cible
0..*
1..*
Elment
Note
0..*
name : Name
ValeurEtiquete
0..*
nom : Nom
0..1
0..*
0..*
Contrainte
0..* Proprit
0..1
Figure 115 : Extrait du mtamodle. Reprsentation des mcanismes communs.
Les strotypes
Les strotypes font partie des mcanismes dextensibilit, prvus dans UML.
Chaque lment de modlisation d'UML a au plus un strotype, lorsque la
smantique de base de l'lment est insuffisante. Un strotype permet la
mtaclassification dun lment d'UML. Il permet aux utilisateurs
(mthodologistes, constructeurs doutils, analystes et concepteurs) dajouter de
nouvelles classes dlments de modlisation, en plus du noyau prdfini par
UML. Les strotypes facilitent galement lunification de concepts proches,
comme les sous-systmes ou les catgories, qui sont exprims au moyen de
strotypes de paquetage.
Les strotypes permettent lextension contrle des classes du mtamodle, par
les utilisateurs dUML. Un lment spcialis par un strotype S est
smantiquement quivalent une nouvelle classe du mtamodle, nomme elle
aussi S. A lextrme, toute la notation aurait pu tre construite partir des deux
classes Truc et Strotype, les autres concepts en drivant par strotypage
de la classe Truc.
Les concepteurs dUML ont recherch lquilibre entre les classes incluses
dorigine, et les extensions apportes par les strotypes. Ainsi, seuls les
concepts fondamentaux ont t exprims sous la forme de classes distinctes. Les
autres concepts, drivables de ces concepts de base, ont t traits comme des
strotypes.
Les tiquettes
Une tiquette est une paire (nom, valeur) qui dcrit une proprit dun
lment de modlisation. Les proprits permettent lextension des attributs des
lments du mtamodle. Une tiquette modifie la smantique de llment quelle
qualifie.
Les notes
Une note est un commentaire attach un ou plusieurs lments de modlisation.
Par dfaut, les notes ne vhiculent pas de contenu smantique. Toutefois, une
note peut tre transforme en contrainte au moyen dun strotype, et dans ce
cas, elle modifie la smantique des lments de modlisation auxquels elle est
attache.
Les contraintes
Une contrainte est une relation smantique quelconque entre lments de
modlisation. UML ne spcifie pas de syntaxe particulire pour les contraintes,
qui peuvent ainsi tre exprimes en langage naturel, en pseudo-code, par des
expressions de navigation ou par des expressions mathmatiques.
La relation de dpendance
La relation de dpendance dfinit une relation dutilisation unidirectionnelle entre
deux lments de modlisation, appels respectivement source et cible de la
relation. Les notes et les contraintes peuvent galement tre source dune relation
de dpendance.
Dichotomies (type, instance) et (type, classe)

De nombreux lments de modlisation prsentent une dichotomie (type,
instance), dans laquelle le type dnote lessence de llment, et l'instance
avec ses valeurs correspond une manifestation de ce type.
De mme, la dichotomie (type, classe) correspond la sparation entre la
spcification dun lment qui est nonc par le type et la ralisation de cette
spcification qui est fournie par la classe.
Les types primitifs

Les types primitifs regroupent toutes les abstractions situes en marge dUML.
Ces types lmentaires ne sont pas des lments de modlisation et ne possdent
donc ni strotypes, ni tiquettes, ni contraintes.
Liste
Boolen
Expression
Point
Multiplicit
Chane
Temps
Nom
Non interprt
Figure 116 : Extrait du mtamodle. Reprsentation des types primitifs dUML.
Les types suivants forment les types primitifs d'UML :
Boolen. Un boolen est un type numr qui comprend les deux valeurs
Vrai et Faux.
Expression. Une expression est une chane de caractres dont la syntaxe est
hors de la porte dUML.
Liste. Une liste est un conteneur dont les parties sont ordonnes et peuvent
tre indexes.
Multiplicit. Une multiplicit est un ensemble non vide dentiers positifs,

tendu par un lexme particulier, le caractre *, qui signifie que la multiplicit
est illimite. La syntaxe de la multiplicit est donne par la rgle suivante :
multiplicit ::= [intervalle | nombre]
{, multiplicit}
intervalle ::= nombre " .. " nombre
nombre ::= nombre_positif | nom | *
Nom. Un nom est une chane de caractres qui permet de dsigner un lment.
Des noms composs peuvent tre forms partir de noms simples, selon la
rgle suivante :
nom_compos ::= nom_simple { . nom_compos }
Le nom dun lment peut tre qualifi par le nom du paquetage qui le contient
ou qui le rfrence, selon la syntaxe suivante :
nom_qualifi ::= qualificateur "::" nom_simple
qualificateur ::= nom_de_paquetage
{ "::" qualificateur }
Point. Un point est un tuple (x, y, z) qui dcrit une position dans
lespace. Par dfaut, la composante z prend la valeur 0.
Chane. Une chane est une suite de caractres, dsigne par un nom.
Temps. Un temps est une chane qui reprsente un temps absolu ou relatif et
dont la syntaxe est hors de la porte d'UML.
Non-interprt. Un non-interprt est un truc12 dont la signification dpend

du domaine.
Les paquetages
Les paquetages offrent un mcanisme gnral pour la partition des modles et le
regroupement des lments de modlisation. Chaque paquetage est reprsent
graphiquement par un dossier.
Nom de
paquetage
Figure 117 : Reprsentation des paquetages.
Les paquetages divisent et organisent les modles de la mme manire que les
rpertoires organisent les systmes de fichiers. Chaque paquetage correspond
un sous-ensemble du modle et contient, selon le modle, des classes, des objets,
des relations, des composants ou des nuds, ainsi que les diagrammes associs.
La dcomposition en paquetages nest pas lamorce dune dcomposition
fonctionnelle ; chaque paquetage est un regroupement dlments selon un
critre purement logique. La forme gnrale du systme (larchitecture du
systme) est exprime par la hirarchie de paquetages et par le rseau de relations
de dpendance entre paquetages.
Les strotypes <<Catgorie>> et <<Sous-systme>> permettent de
distinguer, si besoin est, les paquetages de la vue logique et les paquetages de la
vue de ralisation (ces vues sont dtailles dans le quatrime chapitre).
Cat
<<Catgorie>>
Sub
<<Sous-systme>>
Figure 118 : Les paquetages peuvent tre strotyps, pour distinguer par exemple les
catgories de la vue logique et les sous-systmes de la vue de ralisation.
12
UML parle de blob.
Un paquetage dfinit un espace de nom, de sorte que deux lments diffrents,

contenus par deux paquetages diffrents, peuvent porter le mme nom.
Un paquetage peut contenir dautres paquetages, sans limite du niveau
dembotement. Un niveau donn peut contenir un mlange de paquetages et
dautres lments de modlisation, de la mme manire quun rpertoire peut
contenir des rpertoires et des fichiers.
Figure 119 : Exemple de reprsentation mixte. Un paquetage contient des lments de

modlisation, accompagns ventuellement dautres paquetages.
Chaque lment appartient un paquetage. Le paquetage de plus haut niveau est

le paquetage racine de lensemble dun modle. Une classe contenue par un
paquetage peut galement apparatre dans un autre paquetage sous la forme dun
lment import, au travers dune relation de dpendance entre paquetages.
Les imports entre paquetages se reprsentent dans les diagrammes de classes, les
diagrammes de cas dutilisation et les diagrammes de composants, au moyen
dune relation de dpendance strotype, oriente du paquetage client vers le
paquetage fournisseur.
Fournisseur
<<Import>>
Client
Figure 120 : Reprsentation des imports entre deux paquetages au moyen dune relation de
dpendance strotype.
Une relation de dpendance entre deux paquetages signifie quau moins une
classe du paquetage client utilise les services offerts par au moins une classe du
paquetage fournisseur. Toutes les classes contenues par un paquetage ne sont
pas ncessairement visibles de lextrieur du paquetage.
Loprateur :: permet de dsigner une classe dfinie dans un contexte diffrent
du contexte courant. Lexpression Zoo::Kangourou dsigne la classe
Kangourou dfinie dans le paquetage Zoo.
Un paquetage est un regroupement dlments de modlisation, mais aussi une
encapsulation de ces lments. A limage des classes, les paquetages possdent
une interface et une ralisation. Chaque lment contenu par un paquetage
possde un paramtre qui signale si llment est visible ou non lextrieur du
paquetage. Les valeurs prises par le paramtre sont : public ou
implementation (priv).
Dans le cas des classes, seules celles indiques comme publiques apparaissent
dans linterface du paquetage qui les contient ; elles peuvent alors tre utilises
par les classes membres des paquetages clients. Les classes de ralisation ne
sont utilisables quau sein du paquetage qui les contient.
Classe
exporte
Fournisseur
Client
Ralisation
Figure 121 : Seules les classes exportes sont visibles lextrieur des paquetages.
Les relations de dpendance entre paquetages entranent des relations

dobsolescence entre les lments de modlisation contenus dans ces
paquetages.
Pour des raisons de compilation lors de la ralisation, il est fortement conseill
que les dpendances entre paquetages ne forment que des graphes acycliques. Il
faut donc viter la situation suivante :
P1
P2
Figure 122 : Exemple de dpendance circulaire entre paquetages, viter.
De mme, il convient dviter les dpendances circulaires transitives, illustres cidessous :
P1
P2
P3
Figure 123 : Exemple de dpendance circulaire transitive, viter.
En rgle gnrale, les dpendances circulaires peuvent tre rduites en clatant

un des paquetages incrimins en deux paquetages plus petits, ou en introduisant
un troisime paquetage intermdiaire.
Certains paquetages sont utiliss par tous les autres paquetages. Ces paquetages
regroupent par exemple des classes de base comme des ensembles, des listes, des
files, ou encore des classes de traitement des erreurs. Ces paquetages possdent
une proprit qui les dsigne comme paquetages globaux. Il nest pas ncessaire
de montrer les relations de dpendances entre ces paquetages et leurs utilisateurs
ce qui limite la charge graphique des diagrammes.
IHM
Mtier
Erreur
global
Persistance
Com
Figure 124 : Afin de rduire la charge graphique, les dpendances envers les paquetages
visibles globalement ne sont pas portes dans les diagrammes.
Les diagrammes 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. De mme
quune classe dcrit un ensemble dobjets, une association dcrit un ensemble de
liens ; les objets sont instances des classes et les liens sont instances des
relations. Un diagramme de classes nexprime rien de particulier sur les liens dun
objet donn, mais dcrit de manire abstraite les liens potentiels dun objet vers
dautres objets.
Classe
Instance de
Objet
*
Relie
*
Relation
Relie
Instance de
Diagramme de classes
Lien
Diagramme d'objets
Figure 125 : Extrait du mtamodle. Les diagrammes de classes reprsentent les classes et les
relations.
Les classes
Les classes sont reprsentes par des rectangles compartiments. Le premier
compartiment contient le nom de la classe. Le nom de la classe doit permettre de
comprendre ce que la classe est, et non ce quelle fait. Une classe nest pas une
fonction, une classe est une description abstraite condense dun ensemble
dobjets du domaine de lapplication. Les deux autres compartiments contiennent
respectivement les attributs et les oprations de la classe.
Nom de classe
Figure 126 : Reprsentation graphique des classes.
Une classe contient toujours au moins son nom. Lorsque le nom na pas encore
t trouv, ou nest pas encore arrt, il est conseill de faire figurer un nom
gnrique facile identifier, comme A_Dfinir. Les compartiments dune
classe peuvent tre supprims lorsque leur contenu nest pas pertinent dans le
contexte dun diagramme. La suppression des compartiments reste purement
visuelle, elle ne signifie pas quil ny a pas dattribut ou dopration.
Nom de classe
Figure 127 : Reprsentation graphique simplifie par suppression des compartiments.
Le rectangle qui symbolise la classe peut galement contenir un strotype et des

proprits. UML dfinit les strotypes de classe suivants :
<<signal>>, une occurrence remarquable qui dclenche une transaction

dans un automate,
<<interface>>, une description des oprations visibles,
<<mtaclasse>>, la classe dune classe, comme en Smalltalk,
<<utilitaire>>, une classe rduite au concept de module et qui ne peut

tre instancie.
Les proprits dsignent toutes les valeurs attaches un lment de

modlisation, comme les attributs, les associations et les tiquettes. Une tiquette
est une paire (attribut, valeur) dfinie par lutilisateur ; elle permet de
prciser par exemple des informations de gnration de code, didentification ou
de rfrences croises.
Nom de classe
<<Strotype>>
Proprit
Vhicule
<<Utilitaire>>
Etat = test
Auteur = pam
Figure 128 : Les compartiments de classes peuvent contenir un strotype et des proprits,
dfinis librement par lutilisateur.
Les attributs et les oprations

Les attributs et les oprations peuvent tre montrs de manire exhaustive ou non
dans les compartiments des classes. Par convention, le premier compartiment
contient les attributs et le deuxime compartiment contient les oprations.
Nom de classe
Nom : type = valeur initiale
Nom( )
Figure 129 : Visualisation des attributs et des oprations dans les compartiments de la classe.
La syntaxe retenue pour la description des attributs est la suivante :
Nom_Attribut : Type_Attribut = Valeur_Initiale

Cette description peut tre complte progressivement, lors de la transition de
lanalyse vers la conception.
Il arrive que des proprits redondantes soit spcifies lors de lanalyse des
besoins. Les attributs drivs offrent une solution pour allouer des proprits
des classes, tout en indiquant clairement que ces proprits sont drives
dautres proprits dj alloues. Dans lexemple suivant, la classe Rectangle
possde un attribut Longueur, un attribut Largeur, ainsi quun attribut
driv Surface, qui peut tre construit partir des deux autres attributs.
Rectangle
Longueur
Largeur
/Surface
Figure 130 : Exemple dattribut driv. La surface dun rectangle peut tre dtermine
partir de la longueur et de la largeur.
Par la suite, en conception, lattribut driv /Surface sera transform en une

opration Surface() qui encapsulera le calcul de surface. Cette transformation
peut toutefois tre effectue sans attendre, ds lors que la nature drive de la
proprit surface a t dtecte.
Rectangle
Longueur
Largeur
Surface( )
Figure 131 : Transformation de lattribut driv en une opration de calcul de la surface.
La syntaxe retenue pour la description des oprations est la suivante :

Nom_Opration
(Nom_Argument : Type_Argument = Valeur_Par_Dfaut,...)
: Type_Retourn
Toutefois, tant donn la longueur de la spcification, les arguments des
oprations peuvent tre supprims dans les graphiques.
Visibilit des attributs et des oprations

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.
Linformation de visibilit ne figure pas toujours de manire explicite dans les

diagrammes de classes, ce qui ne veut pas dire que la visibilit nest pas dfinie
dans le modle. Par dfaut, le niveau de visibilit est symbolis par les caractres
+, # et -, qui correspondent respectivement aux niveaux public, protg et
priv.
Certains attributs et certaines oprations peuvent tre visibles globalement, dans
toute la porte lexicale de la classe. Ces lments, galement appels variables et
oprations de classe, sont reprsents comme un objet par un nom soulign. La
notation se justifie par le fait quune variable de classe apparat comme un objet
partag par les instances dune classe. Par extension, les oprations de classe
sont aussi soulignes.
A
+Attribut public
#Attribut protg
-Attribut priv
Attribut de classe
+Opration publique( )
#Opration protge( )
-Opration prive( )
Opration de classe( )
Figure 132 : Reprsentation des diffrents niveaux de visibilit des attributs et des oprations.
Les interfaces
Une interface utilise un type pour dcrire le comportement visible dune classe,
dun composant (dcrits plus loin dans louvrage) ou dun paquetage. Une
interface est un strotype dun type. UML reprsente les interfaces au moyen de
petits cercles relis par un trait llment qui fournit les services dcrits par
linterface.
Figure 133 : Reprsentation dune interface au moyen dun petit cercle reli la classe qui
fournit effectivement les services.
Les interfaces peuvent galement se reprsenter au moyen de classes

strotypes.
Une classe
<<Interface>>
<<Interface>>
Vue A
Vue B
Un utilisateur
Un autre utilisateur
Figure 134 : Exemple de reprsentation des interfaces au moyen de classes strotypes.
Une interface fournit une vue totale ou partielle dun ensemble de services offerts
par un ou plusieurs lments. Les dpendants dune interface utilisent tout ou
partie des services dcrits dans linterface.
Les classes paramtrables

Les classes paramtrables sont des modles de classes. Elles correspondent aux
classes gnriques d'Eiffel et aux templates de C++. Une classe paramtrable ne
peut tre utilise telle quelle. Il convient d'abord de l'instancier, afin d'obtenir une
classe relle qui pourra son tour tre instancie afin de donner des objets. Lors
de l'instanciation, les paramtres effectifs personnalisent la classe relle obtenue
partir de la classe paramtrable. Les classes paramtrables permettent de
construire des collections universelles, types par les paramtres effectifs.
Classe gnrique
Figure 135 : Reprsentation graphique des classes paramtrables.
Ce type de classes napparat gnralement pas en analyse, sauf dans le cas

particulier de la modlisation dun environnement de dveloppement. Les classes
paramtrables sont surtout utilises en conception dtaille, pour incorporer par
exemple des composants rutilisables. La figure suivante reprsente
linstanciation dune table gnrique, pour raliser un annuaire de personnes. Le
paramtre gnrique formel apparat dans le rectangle pointill de la classe
paramtrable alors que le paramtre gnrique effectif est accol au nom de la
classe obtenue par instanciation. Linstanciation est matrialise par une flche
pointille, oriente de linstance vers la classe paramtrable.
Elment
Table gnrique
Annuaire<Personne>
Figure 136 : Exemple de reprsentation de linstanciation dune classe paramtrable.
Les classes utilitaires

Il est parfois utile de regrouper des lments (les fonctions d'une bibliothque
mathmatique par exemple) au sein d'un module, sans pour autant vouloir
construire une classe complte. La classe utilitaire permet de reprsenter de tels
modules et de les manipuler graphiquement comme les classes conventionnelles.
Les classes utilitaires ne peuvent pas tre instancies car elles ne sont pas des
types de donnes. Il ne faut pas pour autant les confondre avec les classes
abstraites qui ne peuvent pas tre instancies car elles sont des spcifications
pures (voir le paragraphe qui traite de la gnralisation). En C++, une classe
utilitaire correspond une classe qui ne contient que des membres statiques
(fonctions et donnes).
Le strotype <<Utilitaire>> spcialise les classes en classes utilitaires.
UML propose galement une reprsentation graphique alternative, avec une
bordure grise.
<<Utilitaire>>
Math
Math
Figure 137 : Exemple de reprsentation graphique dune classe utilitaire.
Les associations
Les associations reprsentent des relations structurelles entre classes dobjets.
Une association symbolise une information dont la dure de vie nest pas
ngligeable par rapport la dynamique gnrale des objets instances des classes
associes. La plupart des associations sont binaires, cest--dire quelles
connectent deux classes. Les associations se reprsentent en traant une ligne
entre les classes associes.
Figure 138 : Les associations se reprsentent en traant une ligne entre les classes associes.
Les associations peuvent tre reprsentes par des traits rectilignes ou obliques,
selon les prfrences de lutilisateur. Lusage recommande de se tenir le plus
possible un seul style de reprsentation des traits afin de simplifier la lecture
des diagrammes au sein dun projet.
Figure 139 : Les associations peuvent tre reprsentes par des traits rectilignes ou obliques
selon les prfrences de lutilisateur.
Arit des associations

La plupart des associations sont dites binaires car elles relient deux classes. Des
arits suprieures peuvent cependant exister et se reprsentent alors au moyen
dun losange sur lequel arrivent les diffrentes composantes de lassociation.
Figure 140 : Exemple de relation ternaire qui matrialise un cours.
Les associations n-aires peuvent gnralement se reprsenter en promouvant

lassociation au rang de classe et en ajoutant une contrainte qui exprime que les
multiples branches de lassociation sinstancient toutes simultanment, en un
mme lien. Dans lexemple suivant, la contrainte est exprime au moyen dun
strotype qui prcise que la classe Cours ralise une association ternaire.
Salle
<<Association ternaire>>
Etudiant
Enseignant
Cours
Dbut
Fin
Figure 141 : Reprsentation dune association ternaire au moyen dune classe avec
strotype.
Comme pour les associations binaires, les extrmits dune association n-aire sont
appeles rles et peuvent porter un nom. La difficult de trouver un nom diffrent
chaque rle dune association n-aire est souvent le signe dune association
darit infrieure.
Nommage des associations

Les associations peuvent tre nommes ; le nom de lassociation apparat alors en
italique, au milieu de la ligne qui symbolise lassociation, plus prcisment
dessus, au-dessus ou au-dessous.
A
Nom
Figure 142 : Les associations peuvent tre nommes afin de faciliter la comprhension des
modles.
Sans en faire une rgle systmatique, lusage recommande de nommer les

associations par une forme verbale, soit active comme travaille pour, soit passive
comme est employ par.
Personne
Travaille pour
Socit
Figure 143 : Nommage dune association par une forme verbale active.
Personne
Est employe par
Socit
Figure 144 : Nommage dune association par une forme verbale passive.
Dans les deux cas, le sens de lecture du nom peut tre prcis au moyen dun
petit triangle dirig vers la classe dsigne par la forme verbale et plac
proximit du nom de lassociation.
Dans un but de simplification, le petit triangle peut tre remplac par les signes <
et > disponibles dans toutes les fontes.
Socit
<Travaille pour
Personne
Figure 145 : Prcision du sens dapplication du nom dune association.
Les associations entre classes expriment principalement la structure statique ; de

ce fait, le nommage par des formes verbales qui voquent plutt le comportement
se trouve un peu en porte--faux avec lesprit gnral des diagrammes de classes.
Le nommage des extrmits des relations permet de clarifier les diagrammes,
comme le nommage des associations, mais dune manire plus passive, plus en
phase avec la tonalit statique des diagrammes de classes.
Nommage des rles

Lextrmit dune association est appele rle. Chaque association binaire
possde deux rles, un chaque extrmit. Le rle dcrit comment une classe voit
une autre classe au travers dune association. Un rle est nomm au moyen dune
forme nominale. Visuellement, le nom dun rle se distingue du nom dune
association, car il est plac prs dune extrmit de lassociation tre en italique.
Socit Employeur
Personne
Employ
Figure 146 : Le nommage des rles exprime comment une classe voit une autre classe au
travers dune association. Dans lexemple ci-dessus, la personne voit la socit comme son
employeur, et la socit voit la personne comme son employ.
Le nommage des associations et le nommage des rles ne sont pas exclusifs lun
de lautre ; toutefois, lusage mlange rarement les deux constructions. Il est
frquent de commencer par dcorer une association par un verbe, puis de se
servir plus tard de ce verbe pour construire un substantif verbal qui nomme le rle
qui convient.
Lorsque deux classes sont relies par une seule association, le nom des classes
suffit souvent caractriser le rle ; le nommage des rles prend tout son intrt
lorsque plusieurs associations relient deux classes. Dans ce cas, il ny a aucune
corrlation par dfaut entre les objets qui participent aux deux relations. Chaque
association exprime un concept distinct. Dans lexemple suivant, il ny a pas de
relation entre les passagers et le pilote.
Pilote
Avion
Personne
Passagers
Figure 147 : Exemple dassociations multiples entre un avion et des personnes.
La prsence dun grand nombre dassociations entre deux classes peut tre
suspecte. Chaque association augmente le couplage entre les classes associes
et un fort couplage peut tre le signe dune mauvaise dcomposition. Il est
galement frquent que les dbutants visualisent plusieurs fois la mme
association en nommant chaque association avec le nom dun des messages qui
circulent entre les objets instances des classes associes.
Personne
Conduire
Voiture
Dmarrer
Laver
Arrter
Figure 148 : Exemple de confusion entre association et messages. Une seule association est
suffisante pour permettre une personne de conduire, dmarrer, laver et arrter sa voiture.
Multiplicit des associations

Chaque rle dune association porte une indication de multiplicit qui montre
combien dobjets de la classe considre peuvent tre lis un objet de lautre
classe. La multiplicit est une information porte par le rle, sous la forme dune
expression entire borne.
1
Un et un seul
0..1
Zro ou un
M .. N
De M N (entiers
naturels)
De zro plusieurs
0 .. *
De zro plusieurs
1 .. *
D'un plusieurs
Figure 149 : Valeurs de multiplicit conventionnelles.
Lexemple suivant montre que plusieurs personnes travaillent pour une mme
socit. La multiplicit de valeur 1 du ct de la classe Socit nest pas trs
raliste car elle signifie que toutes les personnes ont un emploi. La multiplicit de
valeur 0..* du ct de la classe Personne signifie quune socit emploie de
zro plusieurs personnes.
0..* Personne
Socit Employeur
1
Employ
Figure 150 : Ce modle supprime le chmage ! Chaque personne travaille pour une socit,
chaque socit emploie de zro plusieurs personnes.
Une valeur de multiplicit suprieure 1 implique une collection dobjets. Cette

collection nest pas borne dans le cas dune valeur *, qui signifie que plusieurs
objets participent la relation, sans prjuger du nombre maximum dobjets. Le
terme collection, plus gnral que liste ou ensemble, est employ afin dviter
toute supposition sur la structure de donnes qui contient les objets.
Les valeurs de multiplicit expriment des contraintes lies au domaine de
lapplication, valables durant toute lexistence des objets. Les multiplicits ne
doivent pas tre considres durant les rgimes transitoires, comme lors de la
cration ou de la destruction des objets. Une multiplicit de valeur 1 indique
quen rgime permanent, un objet possde obligatoirement un lien vers un autre
objet ; pour autant, il ne faut pas essayer den dduire le profil de paramtres des
constructeurs et systmatiquement prvoir un paramtre de la classe de lobjet li.
Les valeurs de multiplicit nimpliquent rien de particulier sur lordre de cration
des objets. Lexemple suivant montre deux classes connectes par une
association de multiplicit 1 vers 1, sans rien supposer sur le profil de paramtres
des constructeurs dobjets. Dans lexemple suivant, il nest pas ncessaire de
disposer dune voiture pour construire un moteur et inversement.
Voiture
Moteur
1
Figure 151 : La multiplicit dune association est le reflet dune contrainte du domaine.
La dtermination de valeurs de multiplicit optimales est trs importante pour

trouver le bon quilibre, dune part, entre souplesse et possibilit dextension, et
dautre part, entre complexit et efficacit. En analyse, seule la valeur de la
multiplicit est rellement importante. En revanche, en conception, il faut choisir
des structures de donnes (pile, file, ensemble...) pour raliser les collections qui
correspondent aux multiplicits de type 1..* ou 0..*. La surestimation des
valeurs de multiplicit induit un surcot en taille de stockage et en vitesse de
recherche. De mme, une multiplicit qui commence zro implique que les
diverses oprations doivent contenir du code pour tester la prsence ou

labsence de liens dans les objets.
Les valeurs de multiplicit sont souvent employs pour dcrire manire gnrique
les associations. Les formes les plus courantes sont les associations 1 vers 1, 1
vers N et N vers N reprsentes dans la figure suivante.
A
1
1
*
1 vers 1
1 vers N
N vers N
*
*
Figure 152 : Description gnrique des associations selon les valeurs de multiplicit.
Placement des attributs selon les valeurs de multiplicit

La rification des associations prend tout son intrt pour les associations N vers
N. Pour les associations 1 vers 1, les attributs de lassociation peuvent toujours
tre dplacs dans une des classes qui participent lassociation. Pour les
associations 1 vers N, le dplacement est gnralement possible vers la classe du
ct N ; toutefois, il est frquent de promouvoir lassociation au rang de classe
pour augmenter la lisibilit ou en raison de la prsence dassociations vers
dautres classes. Lexemple suivant illustre les diffrentes situations.
Diplme
Mention
Etudiant
0..*
Ralise >
0..*
Travail
0..*
1
1
Chambre
Note
Numro
Figure 153 : Exemples de placement des attributs selon les valeurs de multiplicit.
Lassociation entre la classe Etudiant et la classe Travail est de type N

vers N. La classe Travail dcrit le sujet, la solution apporte par ltudiant
nest pas conserve.
Dans le cas des contrles de connaissances, chaque tudiant compose
individuellement sur un travail donn et la note obtenue ne peut tre stocke ni
dans un tudiant en particulier (car il effectue de nombreux travaux dans sa
carrire), ni dans un travail donn (car il y a autant de notes que dtudiants). La
note est un attribut de la relation entre la classe des tudiants et la classe des
travaux.
En fin danne, chaque tudiant reoit un diplme avec une mention qui dpend
de la performance individuelle de ltudiant. La relation entre le diplme et
ltudiant est personnalise car un diplme ne concerne quun tudiant donn. La
mention devient un attribut du diplme. La mention nest pas stocke dans
ltudiant pour deux raisons : elle ne qualifie pas un tudiant et un tudiant peut
obtenir plusieurs diplmes. Chaque tudiant possde une chambre et une
chambre nest pas partage par plusieurs tudiants. Lassociation entre les
tudiants et les chambres est du type 1 vers 1. Le numro est un attribut de la
classe Chambre puisquun numro caractrise une chambre.
Contraintes sur les associations

Toutes sortes de contraintes peuvent tre dfinies sur une relation ou sur un
groupe de relations. La multiplicit prsente dans le paragraphe prcdent est
une contrainte sur le nombre de liens qui peuvent exister entre deux objets. Les
contraintes se reprsentent dans les diagrammes par des expressions places
entre accolades.
La contrainte {ordonne} peut tre place sur le rle pour spcifier quune
relation dordre dcrit les objets placs dans la collection ; dans ce cas, le modle
ne spcifie pas comment les lments sont ordonns, mais seulement que lordre
doit tre maintenu durant lajout et ou la suppression des objets par exemple.
Compte
Personne
1
0..*
{Ordonne}
Figure 154 : La contrainte {Ordonne} indique que la collection des comptes dune
personne est ordonne.
La contrainte {Sous-ensemble} indique quune collection est incluse dans

une autre collection. Lexemple suivant montre que les dlgus de parents
dlves sont des parents dlves.
Parents d'lves
Classe
Personne
{Sous-ensemble}
*
Dlgus
Figure 155 : La contrainte {Sous-ensemble} indique que les objets qui participent la
relation Dlgus participent galement la relation Parents dlves.
La contrainte {ou-exclusif} prcise que, pour un objet donn, une seule

association parmi un groupe dassociations est valide. Cette contrainte vite
lintroduction de sous-classes artificielles pour matrialiser lexclusivit.
Enseignants
Universit
Personne
{Ou-exclusif}
Etudiants
Figure 156 : Introduction dune contrainte {Ou-exclusif} pour distinguer deux

associations mutuellement exclusives.
Les associations peuvent galement relier une classe elle-mme, comme dans le
cas des structures rcursives. Ce type dassociation est appel association
rflexive. Le nommage des rles prend nouveau toute son importance pour
distinguer les instances qui participent la relation. Lexemple suivant montre la
classe des personnes et la relation qui unie les parents et leurs enfants en vie.
Parents
Personne
2
Enfants *
Figure 157 : Toute personne possde de zro deux parents, et de zro plusieurs enfants. Le
nommage des rles est essentiel la clart du diagramme.
Les classes-associations
Une association peut tre reprsente par une classe pour ajouter, par exemple,
des attributs et des oprations dans lassociation. Une classe de ce type, appele
parfois classe associative ou classe-association, est une classe comme les autres
et peut ce titre participer dautres relations dans le modle. La notation utilise
une ligne pointille pour attacher une classe une association. Dans lexemple
suivant, lassociation entre les classes A et B est reprsente par la classe C, qui
elle-mme est associe la classe D.
A
C
attributs
oprations( )
Figure 158 : Exemple de classe-association.
Une association qui contient des attributs sans participer des relations avec
dautres classes est appele association attribue. Dans ce cas, la classe
rattache lassociation ne porte pas de nom spcifique.
Etudiant
Ralise >
Travail
Note
Figure 159 : Reprsentation dune association attribue.
Restriction des associations

La restriction (UML parle de qualification) dune association consiste
slectionner un sous-ensemble dobjets parmi lensemble des objets qui
participent une association. La restriction est ralise au moyen dun tuple
dattributs particuliers (appel cl) et utilis conjointement avec un objet de la
classe de dpart. La cl est reprsente sur le rle de la classe de dpart, dans un
compartiment rectangulaire. La cl appartient pleinement lassociation et non
aux classes associes.
A
Cl
Figure 160 : Restriction dune association, au moyen dun attribut particulier appel cl.
Chaque instance de la classe A accompagne de la valeur de la cl, identifie un

sous-ensemble des instances de B qui participent lassociation. La restriction
rduit la multiplicit de lassociation. La paire (instance de A, valeur
de cl) identifie un sous-ensemble des instances de B. Trs souvent, la
multiplicit est rduite la valeur 1.
Figure 161 : Une restriction rduit le nom bre dinstances qui participent une association.
La restriction dune association peut tre opre en combinant les valeurs des
diffrents attributs qui forment la cl.
Echiquier
Ligne
Colonne
Case
1
Figure 162 : Combinaison dune ligne et dune colonne pour identifier une case de
lchiquier.
Les agrgations
Une agrgation reprsente une association non symtrique dans laquelle une des
extrmits joue un rle prdominant par rapport lautre extrmit. Quelle que soit
larit lagrgation ne concerne quun seul rle dune association.
Lagrgation se reprsente en ajoutant un petit losange du ct de lagrgat.
A
Une agrgation
Figure 163 : Reprsentation des agrgations.
Les critres suivants impliquent une agrgation :
une classe fait partie dune autre classe ;
les valeurs dattributs dune classe se propagent dans les valeurs dattributs
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.
Linverse nest pas toujours vrai : lagrgation nimplique pas ncessairement les
critres voqus plus haut. Dans le doute, les associations sont prfrables. De
manire gnrale, il faut toujours choisir la solution qui implique le couplage le
plus faible.
Les agrgations peuvent tre multiples, comme les associations. Tant quaucun
choix de ralisation na t effectu, il ny a aucune contrainte particulire sur les
valeurs de multiplicit que peuvent porter les rles dune agrgation. Cela
signifie, en particulier, que la multiplicit du ct de lagrgat peut tre suprieure
1. Ce type dagrgation correspond par exemple au concept de copropritaire.
Le diagramme suivant montre que des personnes peuvent tre copropritaires des
mmes immeubles.
Propritaire
Personne
1..*
Immeuble
0..*
Figure 164 : Exemple dagrgat multiple.
La notion dagrgation ne suppose aucune forme de ralisation particulire. La

contenance physique est un cas particulier de lagrgation, appel composition.
La composition
Les attributs constituent un cas particulier dagrgation ralise par valeur : ils
sont physiquement contenus par lagrgat. Cette forme dagrgation est appele
composition, et se reprsente dans les diagrammes par un losange de couleur
noire.
La composition implique une contrainte sur la valeur de la multiplicit du ct de
lagrgat : elle ne peut prendre que les valeurs 0 ou 1. La valeur 0 du ct du
composant correspond un attribut non renseign.
Agrgat
0..1
Composant
*
Figure 165 : Reprsentation graphique de la composition.
La composition et les attributs sont smantiquement quivalents ; leurs

reprsentations graphiques sont interchangeables. La notation par composition
semploie dans un diagramme de classes lorsquun attribut participe dautres
relations dans le modle. La figure suivante illustre lquivalence entre la notation
par attribut et la notation par composition.
Voiture
Moteur
<=>
Voiture
Cylindre
Moteur
...
Carburateur
Figure 166 : Une agrgation par valeur est smantiquement quivalente un attribut ; elle
permet de montrer comment un attribut participe dautres relations dans le modle.
Les classes ralises par composition sont galement appeles classes

composites. Ces classes fournissent une abstraction de leurs composants.
La navigation
Les associations dcrivent le rseau de relations structurelles qui existent entre
les classes et qui donnent naissance aux liens entre les objets, instances de ces
classes. Les liens peuvent tre vus comme des canaux de navigation entre les
objets. Ces canaux permettent de se dplacer dans le modle et de raliser les
formes de collaboration qui correspondent aux diffrents scnarios.
Par dfaut, les associations sont navigables dans les deux directions. Dans
certains cas, seule une direction de navigation est utile ; ceci se reprsente par
une flche porte par le rle vers lequel la navigation est possible. Labsence de
flche signifie que lassociation est navigable dans les deux sens. Dans lexemple
suivant, les objets instances de A voient les objets instances de B, mais les objets
instances de B ne voient pas les objets instances de A.
A
Figure 167 : Lassociation entre les classes A et B est uniquement navigable de A vers B.
Une association navigable uniquement dans un sens peut tre vue comme une
demi-association. Cette distinction est souvent ralise pendant la conception,
mais peut trs bien apparatre en analyse, lorsque ltude du domaine rvle une
dissymtrie des besoins de communication.
Expressions de navigation
UML dfinit un pseudo-langage pour reprsenter les chemins au sein des
diagrammes de classes. Ce langage trs simple dfinit des expressions qui servent
par exemple prciser des contraintes.
La partie gauche de lexpression dsigne un ensemble dobjets, ventuellement
rduit un singleton. Un nom de classe dsigne lensemble des objets instances
de la classe.
La syntaxe des expressions de navigation est donne par les quatre rgles
suivantes :
cible ::= ensemble . slecteur
Le slecteur correspond soit un nom dattribut des objets de lensemble, soit

un nom dassociation de la classe des objets, soit un nom de rle oppos sur un
lien qui concerne les objets de lensemble. La cible est un ensemble de valeurs ou
dobjets, dont le nombre dpend de la multiplicit de lensemble et de
lassociation.
Dans le cas dune association, lexpression retourne une collection dobjets qui
contient le nombre dlments spcifis par la multiplicit du rle. Lexpression
UnePersonne.Enfants dsigne toutes les enfants dune personne donne.
Personne
Parents
2
Enfants *
Figure 168 : Lexpression UnePersonne.Enfants dsigne tous les enfants dune

personne donne.
cible ::= ensemble . ~ slecteur
Le slecteur correspond un nom de rle plac du ct de lensemble. La cible est

un ensemble dobjets, obtenu par navigation dans le sens oppos au nom de rle.
Dans lexemple prcdent, les parents dune personne sont dsigns par
lexpression UnePersonne.~Enfants.
cible ::= ensemble [ expression_boolenne ]
Lexpression boolenne est construite partir des objets contenus par lensemble
et partir des liens et valeurs accessibles par ces objets. La cible est un ensemble
dobjets qui vrifient lexpression. La cible est un sous-ensemble de lensemble
de dpart.
Dans lexemple prcdent, lexpression boolenne UnePersonne.Enfants
[ge>=18ans] dsigne tous les enfants majeurs dune personne donne.
cible ::=
ensemble . slecteur [ valeur_de_cl ]
Le slecteur dsigne une association qui partitionne lensemble partir de la

valeur de la cl. La cible est un sous-ensemble de lensemble dfini par
lassociation.
Dans lexemple suivant, une restriction est opre par lajout de cls sur
lassociation, ce qui a pour effet de rduire la multiplicit. Lexpression gnrale
UnePersonne.Enfant[UnPrnom] identifie un enfant donn de manire
non ambigu puisque chaque enfant dune mme famille a un prnom diffrent.
Personne
Parent
Prnom
1
Mre/Pre
Enfant
0..1
Figure 169 : Les valeurs de cls peuvent galement tre utilises dans les expressions de
navigation.
Les expressions prcdentes se prtent particulirement bien la formalisation

des pr- et post-conditions attaches aux spcifications des oprations. Dans
lexemple prcdent, les oprations de cration des liens familiaux doivent
associer correctement les parents et leurs enfants. Ceci peut sexprimer sous la
forme de la contrainte suivante.
{UnePersonne =
UnePersonne.Enfant[UnPrnom].(Parent[Mre] ou
Parent[Pre])}
ou encore, en naviguant en sens inverse :

{UnePersonne =
UnePersonne.Enfant[UnPrnom].(~Enfant[Mre] ou
~Enfant[Pre])}
ou enfin, en posant :
{papa = UnePersonne.Parent[Pre]}
et
{papi = UnePersonne.(Parent[Pre] ou
Parent[Mre]).Parent[Pre]}
alors
{papi.Parent[Pre] =
papa.Parent[Pre].Parent[Pre]}
ce qui revient dire, comme chacun sait, que le papa de papi est le papi de papa !
La gnralisation
UML emploie le terme gnralisation pour dsigner la relation de classification
entre un lment plus gnral et un lment plus spcifique. En fait, le terme
gnralisation dsigne un point de vue port sur un arbre de classification. Par
exemple, un animal est un concept plus gnral quun chat, un chien ou un raton
laveur. Inversement, un chat est un concept plus spcialis quun animal.
Llment plus spcifique peut contenir des informations qui lui sont propres,
condition de rester totalement cohrent avec la description de llment plus
gnral. La gnralisation sapplique principalement aux classes, aux paquetages
et aux cas dutilisation.
Dans le cas des classes, la relation de gnralisation exprime le fait que les
lments dune classe sont aussi dcrits par une autre classe (en fait par le type
dune autre classe). La relation de gnralisation signifie est un ou est une sorte
de. Un chat est un animal, il sagit de gnralisation. Un chat a deux oreilles, il ne
sagit pas de gnralisation, mais de composition.
La relation de gnralisation se reprsente au moyen d'une flche qui pointe de la
classe plus spcialise vers la classe plus gnrale. La tte de la flche est ralise
par un petit triangle vide, ce qui permet de la distinguer dune flche ouverte,
symbole de la proprit de navigation des associations. Dans lexemple suivant,
la classe Animal est une abstraction des classes Chat, Chien et Raton
laveur.
Animal
Chat
Chien
Raton laveur
Figure 170 : Reprsentation de la relation de gnralisation entre classes.
Dans lexemple prcdent, la classe Animal est appele super-classe et les

classes Chat, Chien et Raton laveur sont dites sous-classes de la classe
Animal.
Dans le cas de sous-classes multiples, les flches peuvent tre agrges en une
seule, comme prcdemment, ou reprsentes de manire indpendante, comme
suit. Les deux formes de flches qui symbolisent la gnralisation ne vhiculent
aucune smantique particulire.
Figure 171 : Reprsentation de la gnralisation au moyen de flches obliques.
Les attributs, les oprations, les relations et les contraintes dfinies dans les
super-classes sont hrits intgralement dans les sous-classes. En
programmation, la relation de gnralisation est trs souvent ralise en utilisant
la relation dhritage entre classes, propos par les langages objet. Lhritage est
une manire de raliser la classification, mais ce nest pas la seule. La relation de
gnralisation dfinie par UML est plus abstraite que la relation dhritage telle
quelle existe dans les langages de programmation objet comme C++. Lhritage
est une relation statique ; elle induit un couplage trs fort entre classes, et se
rvle peu adapte la notion de classification dynamique ou la notion de
mtamorphose. En analyse, il vaut mieux parler de gnralisation ou de
classification, et se proccuper plus tard, lors de la conception, de la manire de
raliser la gnralisation.
Les classes peuvent avoir plusieurs super-classes ; dans ce cas, la gnralisation
est dite multiple et plusieurs flches partent de la sous-classe vers les diffrentes
super-classes. La gnralisation multiple consiste fusionner plusieurs classes
en une seule classe. Les super-classes nont pas ncessairement un anctre
commun. Dans lexemple suivant, la classe Tapis volant possde deux
anctres compltement disjoints, les classes Tapis et Vhicule. La forme de
gnralisation qui regroupe les classes Vhicule, Vhicule
terrestre13, Vhicule Arien et Tapis volant, est appele
gnralisation en diamant ou en losange.
13
Pour se convaincre que les tapis sont bien des vhicules terrestres, il suffit
dobserver mes enfants...
Vhicule
Tapis
Terrestre
Arien
Tapis volant
Figure 172 : Exemple de gnralisation multiple.
Une classe peut tre spcialise selon plusieurs critres simultanment. Chaque
critre de la gnralisation est indique dans le diagramme en associant un
discriminant la relation de gnralisation. Lorsque les flches sont agrges, le
discriminant napparat quune seule fois. Labsence de discriminant est
considre comme un cas particulier de gnralisation.
Vhicule
Motorisation
A voile
A moteur
Milieu
Terrestre
Marin
Figure 173 : Exemple de gnralisation selon des critres indpendants.
Diffrentes contraintes peuvent tre appliques aux relations de gnralisation,

pour distinguer par exemple les formes de gnralisation exclusives des formes
inclusives. Les contraintes sur les relations de gnralisation se reprsentent au
moyen dexpressions entre parenthses, directement attaches aux
gnralisations agrges ou associes une ligne pointill qui relie les relations
de gnralisation concernes.
Par dfaut, la gnralisation symbolise une dcomposition exclusive, cest--dire
quun objet est au plus instance dune des sous-classes. La contrainte
{Disjoint} ou {Exclusif} indique quune classe descendante dune
classe A peut tre descendante dune seule sous-classe de A.
Champignon
{Exclusif}
Agaricus
Boletus
Pas de
mlange des
dimensions
Pied bleu
Bolet de loup
Figure 174 : Exemple de classification exclusive.
La contrainte {Chevauchement} ou {Inclusif} indique quune classe

descendante dune classe A appartient au produit cartsien des sous-classes de
la classe A. Un objet concret est alors construit partir dune classe obtenue par
mlange de plusieurs super-classes.
Vhicule
Motorisation
A voile
{Inclusif}
A moteur
Milieu
Terrestre
Ptrolette
Marin
Mlange
des deux
dimensions
Figure 175 : Exemple de classification inclusive.
La contrainte {Complte} indique que la gnralisation est termine et quil

nest pas possible de rajouter des sous-classes. Inversement, la contrainte
{Incomplte} dsigne une gnralisation extensible.
Cours
{Incomplte}
Maths
Franais
Go
Figure 176 : La contrainte {Incomplte} signale quil peut exister dautres cours ; la
classification est extensible.
Il ne faut pas confondre la contrainte {Incomplte} avec une vue incomplte.

Une contrainte vhicule un contenu smantique qui affecte le modle. Une vue
incomplte ne signifie pas que le modle est incomplet.
De manire gnrale, une vue partielle se symbolise par la prsence de points
dlision qui se substituent aux lments de modlisation dans les diffrents
diagrammes. Lexemple suivant montre partiellement la gnralisation de la classe
Cours.
Cours
Maths
...
Go
Figure 177 : Exemple de vue incomplte. Les points dlision caractrisent la vue et non le
modle.
Les classes abstraites

Les classes abstraites ne sont pas instanciables directement ; elles ne donnent
pas naissance des objets, mais servent de spcification plus gnrale de type
pour manipuler les objets instances dune (ou plusieurs) de leurs sous-classes.
Les classes abstraites forment une base pour les logiciels extensibles. L'ensemble
des mcanismes gnraux est dcrit dans les termes des spcifications des
classes abstraites, sans tenir compte des spcificits rassembles dans les
classes concrtes. Les nouveaux besoins, les extensions et les amliorations sont
concentrs dans de nouvelles sous-classes, dont les objets peuvent tre
manipuls de manire transparente par les mcanismes dj en place.
Une classe est dsigne comme abstraite au moyen de la proprit boolenne
Abstraite dfinie pour tous les lments gnralisables (les types, les
paquetages et les strotypes). Par convention, le nom des classes abstraites est
en italique.
Classe Abstraite
Figure 178 : Reprsentation graphique dune classe abstraite.
La proprit abstraite peut galement tre applique une opration afin

dindiquer que le corps de lopration doit tre dfini explicitement dans les sousclasses.
Introduction au mtamodle
De nombreux lments de modlisation prsentent une dichotomie commune
(essence, manifestation), par laquelle un type reprsente lessence
dune abstraction et linstance fournit une manifestation concrte. Il existe
galement une dichotomie (spcification, ralisation) par laquelle
des classes et des types primitifs ralisent des types.
Un type spcifie un domaine de valeurs et un ensemble d'oprations applicables
ces valeurs. Une classe ralise un type : elle fournit la reprsentation des attributs
et la ralisation des oprations (les mthodes). Cette distinction se propage avec
les sous-classes de sorte que la spcification donne par un type est valable pour
toutes les sous-classes et qu'une sous-classe peut raliser plusieurs types.
Le diagramme de classes ci-dessous reprsente la dichotomie (essence,
manifestation) et la dichotomie (spcification, ralisation).
Instance
Type
Instance de >
0..*
Domaine de dfinition
0..1 Oprations
Dichotomie
(essence, manifestation)
Dichotomie
(spcification,
ralisation)
Ralise
Mthode
Classe
0..*
Figure 179 : Extrait du mtamodle. Une instance manifeste un type, une classe ralise un
type.
La classe Type comprend les sous-classes suivantes :
le type primitif qui correspond un type qui n'est pas ralis par une classe,
comme les entiers ou les types numrs,
la classe qui fournit la ralisation d'un type,
le cas d'utilisation qui est une squence d'actions effectues par un acteur et
un systme.
Le diagramme suivant reprsente les diffrentes sortes de types proposs par

UML.
Type
Type de base
Classe
Cas d'utilisation
Figure 180 : Extrait du mtamodle. Reprsentation des diffrentes sortes de types.
La classe Classe comprend les sous-classes suivantes :
la classe active qui rifie un ou plusieurs flots d'excution,
le signal qui est un vnement nomm,
le composant qui est un lment rutilisable contenant les constituants

physiques des lments de modlisation,
le nud qui est un dispositif physique sur lequel des composants peuvent
tre dploys pour leur excution.
Classe
Classe active
Signal
Composant
< Dploie
0..*
Noeud
0..*
Figure 181 : Extrait du mtamodle. Reprsentation des diffrentes sortes de classes.
Les relations
UML dfinit cinq sortes de relations. La plus gnrale est appele relation de
dpendance et sapplique de manire uniforme tous les lments de
modlisation. Lassociation et la gnralisation concernent tous les types, en
particulier les classes et les cas dutilisation. Les deux dernires, les transitions et
les liens, sappliquent certains lments de modlisation du comportement.
Ce paragraphe se limite la description des relations statiques entre classes,
prsentes dans le diagramme suivant. Les liens et les transitions sont prsents
plus loin dans ce chapitre.
Relation
Association
Gnralisation
Dpendance
Figure 182 : Extrait du mtamodle. Reprsentation des relations entre classes.
Lassociation
L'association spcifie une connexion smantique bidirectionnelle entre types. Une
association possde au moins deux rles qui dcrivent la part prise par les types
participant l'association.
Association
1
{ordonne}
2..*
Rle
0..*
multiplicit : Multiplicit
0..1
navigable : Boolen
agrgat : Boolen
changeable : Boolen
ordonne : Boolen
Participant
Cl de filtrage 0..*
Type
Attribut
Figure 183 : Extrait du mtamodle. Reprsentation des principales caractristiques des

associations.
Chaque rle comprend les attributs suivants :
Multiplicit. Spcifie le nombre d'instances qui participent la relation.
Navigable. Prcise si les liens, instances de l'association, sont navigables

dans la direction du rle considr.
Agrgat. Spcifie si les instances du type associ au rle sont le tout dans
une relation du genre (tout, parties). Seul un des rles d'une
association peut possder un attribut d'agrgation positionn Vrai. Si, de
plus, la multiplicit de ce rle vaut 1, alors le tout possde les parties et la
destruction du tout entrane la destruction des parties. Si la multiplicit est
suprieure 1, plusieurs instances jouent le rle du tout et partagent les
parties ; la destruction dune des instances du tout n'entrane pas la
destruction des parties. La destruction de toutes les instances du tout

entrane la destruction des parties.
Changeable. Prcise si la smantique de l'association est prserve

lorsqu'une instance, du type qui participe au rle, est remplace par une autre
instance.
Ordonne. S'applique lorsque la valeur de la multiplicit est suprieure 1,

pour signifier que les instances sont ordonnes.
Un rle d'association peut galement comprendre un tuple d'attributs dont la

conjonction de valeurs ralise une partition de l'ensemble des objets de la classe
associe.
La gnralisation
La gnralisation spcifie une relation de classification par laquelle une instance
d'un sous-type peut tre substitue une instance d'un super-type. Un supertype peut avoir plusieurs sous-types et un sous-type peut avoir plusieurs supertypes.
Gnralisation
Super-type
Sous-type
0..*
0..* {ordonne}
Elment gnralisable
Abstrait : Boolen
Feuille : Boolen
Racine : Boolen
Strotype
Paquetage
Type
Figure 184 : Extrait du mtamodle. Reprsentation de la relation de gnralisation et des

lments gnralisables.
Tout lment gnralisable possde les attributs boolens suivants :
Abstrait. La valeur Vrai prcise que l'lment ne peut tre instanci

directement.
Feuille. La valeur Vrai prcise que l'lment ne peut avoir des sous-types.
Racine. La valeur Vrai prcise que l'lment ne peut avoir des super-types.
UML dfinit trois sortes d'lments gnralisables :
Strotype. Les strotypes permettent la classification d'un lment de

modlisation et ventuellement la dfinition d'une reprsentation graphique
particulire. Un strotype ne peut pas avoir de sous-type.
Paquetage. Les paquetages offrent un mcanisme gnral pour le

regroupement des lments ( la fois de modlisation et de visualisation). Un
paquetage ne peut pas avoir de super-type.
Type. Un type spcifie un domaine de dfinition et les oprations applicables

ce domaine.
La dpendance
La dpendance est une relation d'utilisation unidirectionnelle entre lments (de
modlisation et de visualisation). La relation de dpendance relie des lments au
sein d'un mme modle.
Dpendance
0..*
Cible
Elment 0..*
Source
{ La cible et la source
appartiennent au
mme modle}
Figure 185 : Extrait du mtamodle. Reprsentation des relations de dpendance.
UML dfinit galement une relation de trace entre lments qui appartiennent
des modles diffrents. La trace faciliter peut servir notamment reprsenter
lhistoire des constructions prsentes dans les diffrents modles. Cette relation
de trace est une relation de dpendance strotype.
Dpendance
0..* Elment
0..*
Cible
Source
appartiennent au
mme modle}
Strotype
Trace
n'appartiennent pas
ncessairement au
mme modle}
Figure 186 : Extrait du mtamodle. La relation de trace est une relation de dpendance
strotype.
Les cas dutilisation

Les cas dutilisation (use cases) ont t formaliss par Ivar Jacobson14. Les cas
dutilisation dcrivent sous la forme dactions et de ractions, le comportement
dun systme du point de vue dun utilisateur. Ils permettent de dfinir les limites
du systme et les relations entre le systme et lenvironnement.
Les cas dutilisation viennent combler un manque des premires mthodes objet,
comme OMT-1 et Booch 91, qui ne proposaient pas de technique pour la
dtermination des besoins. En ce sens, les cas dutilisation associs aux
techniques objet permettent une approche complte pour lensemble du cycle de
vie, depuis le cahier des charges jusqu la ralisation.
Un cas dutilisation est une manire spcifique dutiliser un systme. Cest
limage dune fonctionnalit du systme, dclenche en rponse la stimulation
dun acteur externe.
Intrt des cas dutilisation

La dtermination et la comprhension des besoins sont souvent difficiles car les
intervenants sont noys sous de grandes quantits dinformation. Les besoins
sont souvent exprims de manire non structure, sans forte cohrence, de sorte
que les cahiers des charges sont de longues litanies de paragraphes qui
contiennent des expressions du genre :
14
Jacobson I. 1992, Object-Oriented Software Engineering, A Use Case Driven

Approach, Addison-Wesley.
le systme devra faire...
le systme devrait faire...
le systme fera ventuellement...
il faut absolument que...
il serait intressant de...
Frquemment, des besoins se contredisent, des oublis sont commis, des

imprcisions subsistent, et lanalyse du systme part sur de mauvaises bases. En
consquence, le cahier des charges initial est flou et en constante volution.
Lorsque les besoins se prcisent ou voluent ce qui est toujours le cas il
devient trs difficile dapprcier limpact et le cot dune modification.
Les cas dutilisation recentrent lexpression des besoins sur les utilisateurs, en
partant du point de vue trs simple qui veut quun systme est avant tout
construit pour ses utilisateurs. La structuration de la dmarche seffectue par
rapport aux interactions dune seule catgorie dutilisateurs la fois ; cette
partition de lensemble des besoins rduit considrablement la complexit de la
dtermination des besoins.
Figure 187 : Les cas dutilisation partitionnent lensemble des besoins dun systme.
Le formalisme des cas dutilisation bas sur le langage naturel est accessible
sans formation particulire des utilisateurs, qui peuvent ainsi exprimer leurs
attentes et leurs besoins en communiquant facilement avec les experts du
domaine et les informaticiens. La terminologie employe dans la rdaction des cas
dutilisation est celle employe par les utilisateurs dans leur vie de tous les jours,
de sorte que lexpression des besoins sen trouve grandement facilite. Les
informaticiens, quant eux, sont constamment ramens par les cas dutilisation
vers les proccupations premires des utilisateurs ; ils vitent ainsi de driver
vers des constructions techniquement sduisantes, mais pas forcment
ncessaires aux utilisateurs. Les cas dutilisation focalisent leffort de

dveloppement sur les vrais besoins.
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. Les cas dutilisation concrtisent
le futur systme dans une formalisation proche de lutilisateur ; ils favorisent la
dfinition dun cahier des charges qui reflte rellement les besoins, mme en
labsence dun systme critiquer.
Le modle des cas dutilisation

Le modle des cas dutilisation comprend les acteurs, le systme et les cas
dutilisation eux-mmes. Lensemble des fonctionnalits dun systme est
dtermin en examinant les besoins fonctionnels de chaque acteur, exprims sous
forme de familles dinteractions dans les cas dutilisation. Les acteurs se
reprsentent sous la forme de petits personnages qui dclenchent des cas
dutilisation ; ces derniers sont reprsents par des ellipses contenues par le
systme.
Systme
Cas d'utilisation X
Acteur A
Acteur B
Cas d'utilisation Y
Figure 188 : Reprsentation des acteurs au moyen de petits personnages.
Un acteur reprsente un rle jou par une personne ou une chose qui interagit
avec un systme. Les acteurs se dterminent en observant les utilisateurs directs
du systme, ceux qui sont responsables de son exploitation ou de sa
maintenance, ainsi que les autres systmes qui interagissent avec le systme en
question. La mme personne physique peut jouer le rle de plusieurs acteurs
(vendeur, client). Dautre part, plusieurs personnes peuvent jouer le mme rle, et
donc agir comme le mme acteur (tous les clients). Le nom de lacteur dcrit le rle
jou par lacteur.
Dans lexemple suivant, Monsieur Schmoldu, garagiste de son tat, passe le plus
clair de son temps dans le rle du mcanicien, mais peut loccasion jouer le rle
de vendeur. Le dimanche, il joue le rle de client et entretient sa voiture

personnelle.
Conduire
Client
Entretenir
Rparer
Vendeur
Mcanicien
Vendre
Figure 189 : Une mme personne physique peut jouer le rle de plusieurs acteurs.
Les candidats acteurs se recrutent parmi les utilisateurs, les clients, les
partenaires, les fournisseurs, les vendeurs, les autres systmes, en rsum, les
personnes et les choses extrieures a un systme qui interagissent avec lui en
changeant de linformation (en entre et en sortie). La dtermination des acteurs
permet de prciser les limites du systme de manire progressive : floues au
dpart, elles se prcisent au fur et mesure de llaboration des diffrents cas
dutilisation. Cette activit de dlimitation est extrmement importante car elle sert
de base contractuelle o est signal ce qui doit tre fait, ce qui fait partie du
systme dvelopper et ce qui nen fait pas partie. Elle prcise galement les
lments intangibles, que lquipe de dveloppement ne peut pas modifier.
Il existe quatre grandes catgories dacteurs :
Les acteurs principaux. Cette catgorie regroupe les personnes qui utilisent
les fonctions principales du systme. Dans le cas dun distributeur de billets,
il sagit des clients.
Les acteurs secondaires. Cette catgorie regroupe les personnes qui

effectuent des tches administratives ou de maintenance. Dans le cas dun
distributeur de billets, il sagit de la personne qui recharge la caisse contenue
dans le distributeur.
Le matriel externe. Cette catgorie regroupe les dispositifs matriels

incontournables qui font partie du domaine de lapplication et qui doivent tre
utiliss. Il ne sagit donc pas de lordinateur sur lequel sexcute lapplication,
mais des autres dispositifs matriels priphriques. Dans le cas dun
distributeur de billets, ce peut tre limprimante.
Les autres systmes. Cette catgorie regroupe les systmes avec lesquels le
systme doit interagir. Dans le cas dun distributeur de billet, le systme du
groupement bancaire qui gre un parc de distributeurs apparat comme un
acteur.
Une fois identifis, les acteurs doivent tre dcrits dune manire claire et concise,
en trois ou quatre lignes maximum. Lorsquil y a beaucoup dacteurs dans un
systme, il est conseill de les regrouper par catgories afin de faciliter la
navigation dans le modle des cas dutilisation.
Les cas dutilisation se dterminent en observant et en prcisant, acteur par
acteur, les squences dinteraction les scnarios du point de vue de
lutilisateur. Ils se dcrivent en termes dinformations changes et dtapes dans
la manire dutiliser le systme. Un cas dutilisation regroupe une famille de
scnarios dutilisation selon un critre fonctionnel. Les cas dutilisation sont des
abstractions du dialogue entre les acteurs et le systme : ils dcrivent des
interactions potentielles, sans entrer dans les dtails de chaque scnario.
Les cas dutilisation doivent tre vus comme des classes dont les instances sont
les scnarios. Chaque fois quun acteur interagit avec le systme, le cas
dutilisation instancie un scnario ; ce scnario correspond au flot de messages
changs par les objets durant linteraction particulire qui correspond au
scnario. Lanalyse des besoins par les cas dutilisation saccommode trs bien
dune approche itrative et incrmentale.
La porte des cas dutilisation dpasse largement la dfinition des seuls besoins
du systme. En effet, les cas dutilisation interviennent tout au long du cycle de
vie, depuis le cahier des charges jusquaux tests, en passant par lanalyse, la
conception, la ralisation et la rdaction de la documentation pour lutilisateur. De
ce point de vue, il est possible de naviguer vers les classes et les objets qui
collaborent pour satisfaire un besoin, puis vers les tests qui vrifient que le
systme sacquitte correctement de sa tche.
Utilisateur
Exprime
Comprend Analyste
Cas d'utilisation
Ralise
Conoit
Vrifie
Programmeur
Testeur
Architecte
Figure 190 : Les cas dutilisation servent de fil conducteur pour lensemble du projet.
Les relations entre cas dutilisation

Les diagrammes de cas dutilisation reprsentent les cas dutilisation, les acteurs
et les relations entre les cas dutilisation et les acteurs. UML dfinit trois type de
relations entre acteurs et cas dutilisation :
La relation de communication. La participation de lacteur est signale par

une flche entre lacteur et le cas dutilisation. Le sens de la flche indique
linitiateur de linteraction.
Dclenche
Cas d'utilisation
Acteur
Figure 191 : Reprsentation du dclenchement dun cas dutilisation par un acteur.
La relation dutilisation. Une relation dutilisation entre cas dutilisation

signifie quune instance du cas dutilisation source comprend galement le
comportement dcrit par le cas dutilisation destination.
<<Utilise>>
Cas d'utilisation B
Cas d'utilisation A
Figure 192 : Reprsentation de la relation dutilisation au moyen dune relation de

gnralisation strotype.
La relation dextension. Une relation dextension entre cas dutilisation

signifie que le cas dutilisation source tend le comportement du cas
dutilisation destination.
<<Etend>>
Cas d'utilisation B
Cas d'utilisation A
Figure 193 : Reprsentation de la relation dextension au moyen dune relation de

gnralisation strotype.
Le diagramme suivant donne un exemple de mise en uvre des diffrentes

relations entre cas dutilisation. Le virement par Minitel est une extension du
virement effectu en agence. Dans les deux cas, le client doit tre identifi.
Virement
par minitel
<<Etend>>
Client distant
Client local
<<Utilise>>
Virement
Identification
Figure 194 : Exemple de mise en uvre des diffrentes relations entre cas dutilisation.
Construction des cas dutilisation

Un cas dutilisation possde une valeur ajoute qui procure lutilisateur un
rsultat apprciable. Un cas dutilisation doit avant tout tre simple, intelligible,
dcrit de manire claire et concise. Le nombre dacteurs qui interagissent avec le
cas dutilisation est trs limit : en rgle gnrale, il ny a quun seul acteur par
cas dutilisation.
Lors de la construction des cas d'utilisation, il faut se demander :
quelles sont les tches de lacteur ?
quelles informations lacteur doit-il crer, sauvegarder, modifier, dtruire ou

simplement lire ?
lacteur devra-t-il informer le systme des changements externes ?
le systme devra-t-il informer lacteur des conditions internes ?
Les cas dutilisation peuvent tre prsents aux travers de vues multiples : un
acteur avec tous ses cas dutilisation, un cas dutilisation avec tous ses acteurs,
etc.
Les cas dutilisation peuvent galement tre groups selon leurs squences de
dclenchement types, cest--dire en fonction de leurs enchanements, ou encore
en fonction des diffrents points de vue, souvent corrls aux grandes catgories
dacteurs (client, fournisseur, maintenance...).
Ltape suivante consiste classer les cas dutilisation selon leur acuit par
rapport lactivit de la socit, leur intrt pour les clients, la nature des risques,
la simplicit de leur mise en uvre ou leur impact sur les processus dj en place.
Rgles de mise en uvre des cas dutilisation

Un cas dutilisation dcrit non seulement une fonctionnalit ou une motivation,
mais aussi une interaction entre un acteur et un systme sous la forme dun flot
dvnements. La description de linteraction se concentre sur ce qui doit tre fait
dans le cas dutilisation, pas sur la manire de le faire.
Un cas dutilisation doit rester simple. Il ne faut pas hsiter fragmenter un cas
dutilisation si les interactions deviennent trop complexes, trop enchevtres, ou
encore si des parties se rvlent tre indpendantes. Il faut galement veiller ne
pas mlanger les cas dutilisation ; les acteurs et les interactions dun autre cas
dutilisation ne doivent pas tre mentionns dans la description. Enfin, les cas
dutilisation doivent viter demployer des expressions floues et imprcises,
construites partir de mots comme beaucoup, plutt, suffisamment, assez, etc.
La description dun cas dutilisation comprend les lments suivants :
le dbut du cas dutilisation, autrement dit lvnement qui dclenche le cas

dutilisation ; il doit tre clairement stipul dans la phrase suivante : Le cas
dutilisation dbute quand X se produit. ;
la fin du cas dutilisation, autrement dit lvnement qui cause larrt du cas
dutilisation ; il doit tre clairement identifi et document par la phrase :
Quand Y se produit, le cas dutilisation est termin. ;
linteraction entre le cas dutilisation et les acteurs qui dcrit clairement ce

qui est dans le systme et ce qui est hors du systme ;
les changes dinformations qui correspondent aux paramtres des

interactions entre le systme et les acteurs. Une formulation non informatique
est recommande, par exemple : Lutilisateur se connecte au systme et
donne son nom et son mot de passe. ;
La chronologie et lorigine des informations qui dcrivent quand le systme

a besoin dinformations internes ou externes et quand il les enregistre
lintrieur ou lextrieur ;
Les rptitions de comportement qui peuvent tre dcrites au moyen de

pseudo-code, avec des constructions du type :
boucle
-- quelque chose
fin de boucle
ou
pendant que
-- autre chose
fin pendant
Les situations optionnelles qui doivent tre reprsentes de manire uniforme

dans tous les cas dutilisation ; les diffrentes options doivent apparatre
clairement selon la formulation :
Lacteur choisit lun des lments suivants, ventuellement plusieurs fois de
suite :
a)
choix X
b)
choix Y
c)
choix Z
puis lacteur continue en...

Ces points ne suffisent pas pour obtenir un bon cas dutilisation. Il est galement
primordial de trouver le bon niveau dabstraction, cest--dire la quantit de
dtails qui doivent apparatre, et de faire la distinction entre un cas dutilisation et
un scnario. Il ny a malheureusement pas de rponse toute faite, de sorte que
lapprciation du niveau dabstraction repose grandement sur lexprience. Les
rponses apportes aux deux interrogations suivantes peuvent nanmoins servir
de gabarit :
est-il possible dexcuter une activit donne indpendamment des autres, ou

faut-il toujours lenchaner avec une autre activit ? Deux activits qui
senchanent toujours font probablement partie du mme cas dutilisation ;
est-il judicieux de regrouper certaines activits en vue de les documenter, de

les tester ou de les modifier ? Si oui, ces activits font srement partie du
mme cas dutilisation.
Lorsquun cas dutilisation devient trop complexe (plus de dix pages par exemple),
il est possible de le dcouper en cas dutilisation plus petits. Cette opration nest
toutefois effectue que lorsque les cas dutilisation ont t dcrits en dtail, aprs
examen des principaux scnarios.
Processus dlaboration des cas dutilisation

Les cas dutilisation permettent le travail en groupe, condition de dfinir un
guide de style pour la rdaction. Ce guide contient une description de la mise en
page des cas dutilisation, du niveau de dtails, ainsi quun modle de cas
dutilisation qui sera repris par tous les intervenants.
Lquipe commence par identifier grossirement les cas dutilisation. Les
principales tapes de chaque cas dutilisation sont dcrites en une phrase ou
deux, en distinguant le cas nominal des cas alternatifs et exceptionnels. Une fois
ce premier travail ralis, des groupes issus de lquipe se chargent dapprofondir
la comprhension et la description dun cas dutilisation particulier. Pour ce faire,
chaque groupe identifie les scnarios et les conditions de diffrenciation entre
scnarios partir de la connaissance du domaine et de rencontres avec les
utilisateurs.
Un scnario est un chemin particulier au travers de la description abstraite et
gnrale fournie par le cas dutilisation. Les scnarios traversent le cas
dutilisation, en suivant le chemin nominal ainsi que tout chemin alternatif et
exceptionnel. Lexplosion combinatoire fait quil est bien souvent impossible de
drouler tous les scnarios.
Figure 195 : Un cas dutilisation dcrit (de manire abstraite) une famille de scnarios.
Lorsque le contenu du cas dutilisation a t valid par le droulement des

scnarios, les tapes stabilises doivent tre dcrites de manire plus dtaille. A
chaque tape correspond alors un paragraphe qui dcrit ce qui se passe dans
ltape, en tenant compte a priori de tous les scnarios qui traversent ltape. A
ce stade, tous les besoins identifis dans les scnarios doivent tre pris en
compte par un cas dutilisation.
Il est fortement conseill de synchroniser lvolution des cas dutilisation par des
runions rgulires entre groupes de lquipe. Ceci prsente le double avantage
dharmoniser le niveau de dtail des cas dutilisation et de permettre la
rallocation des scnarios orphelins, en mal de cas dutilisation.
Ces runions permettent galement de faire valider les cas dutilisation dun
groupe par les autres groupes. Des critres simples, issus de lexprience, aident
distinguer un bon cas dutilisation dun moins bon. Il faut par exemple se poser
les questions suivantes :
existe-t-il une brve description qui donne une vraie image du cas
dutilisation ?
les conditions de dmarrage et darrt du cas dutilisation sont-elles bien

cernes ?
les utilisateurs sont-ils satisfaits par la squence dinteractions entre lacteur

et le cas dutilisation ?
existe-t-il des tapes communes avec dautres cas dutilisation ?
les mmes termes employs dans des cas dutilisation diffrents ont-ils bien la
mme signification ?
est-ce que toutes les alternatives sont prises en compte par le cas
dutilisation ?
Les derniers piges viter

Les cas dutilisation ne sont pas la seule manire de documenter les besoins dun
systme. Les techniques traditionnelles, base de descriptions textuelles
informelles, peuvent trs bien accompagner les cas dutilisation. Il est alors
judicieux dtablir des rfrences croises entre les deux types de documentation
et dtudier les points suivants :
est-ce que tous les besoins identifis de manire informelle ont t allous
un cas dutilisation ?
est-ce quun mme besoin a t allou plusieurs cas dutilisation ?
existe-t-il des cas dutilisation qui ne sont pas rfrencs par des besoins
informels ?
Dautre part, le maquettage base de constructeurs dinterface utilisateur est trs

souvent le meilleur moyen daider lutilisateur final articuler ses dsirs. Lexamen
des interactions entre lutilisateur et la maquette procure alors une source non
ngligeable de scnarios, et donc de moyens de valider le modle des cas
dutilisation.
La principale difficult demploi lie aux cas dutilisation rside plus dans la
dtermination du niveau de dtail, que dans la formulation des cas dutilisation. Il
faut se rappeler que les cas dutilisation sont une abstraction dun ensemble de
comportements fonctionnellement lis au sein dun cas dutilisation. La prsence
dun grand nombre de dtails par exemple, est le signe dun scnario plus que
dun cas dutilisation.
Dans le mme ordre dide, un grand nombre de cas dutilisation est le signe dun
manque dabstraction. Dans nimporte quel systme, quelle que soit sa complexit
et sa taille, il y a relativement peu de cas dutilisation, mais beaucoup de
scnarios. Typiquement, un systme moyen comprend de dix vingt cas
dutilisation ; un grand nombre de cas dutilisation signifie que lessence du
systme na pas t comprise. Un cas dutilisation dcrit ce que lutilisateur veut
fondamentalement faire avec le systme. Le nom des cas dutilisation peut tre un
indicateur, les associations (objet, oprations) ou (fonction, donnes) sont
fortement suspectes.
Une autre difficult consiste rsister la tentation de trop dcrire le
comportement interne du systme, au dtriment de linteraction entre lacteur et le
systme. Il est vrai que le cas dutilisation doit dcrire ce que lutilisateur change
avec le systme et les grandes tapes dans llaboration de ces changes ; mais
cela ne va pas jusqu' expliquer comment le systme ralise ces changes. Le cas
dutilisation est un outil danalyse utilis pour dterminer ce que lutilisateur
attend du systme, cest--dire le quoi et le quoi faire du systme. Ds lors que la
description fait appel au comment, il ne sagit plus danalyse mais de conception.
La transition vers les objets

Les cas dutilisation recentrent le dveloppement sur les besoins de lutilisateur ;
ils aident donc construire le bon systme (Build the right system comme diraient
nos amis anglo-saxons). Les cas dutilisation ne dfinissent pas pour autant la
bonne manire de faire le systme (Build the system right comme diraient toujours
nos amis) ni la forme de larchitecture du logiciel ; ils disent ce quun systme doit
faire, pas comment il doit le faire.
La vue des cas dutilisation est une description fonctionnelle des besoins,
structure par rapport un acteur. Le passage lapproche objet seffectue en
associant une collaboration chaque cas dutilisation. Une collaboration dcrit
des objets du domaine, les connexions entre ces objets et les messages changs
par les objets. Chaque scnario, instance du cas dutilisation ralis par la
collaboration, se reprsente par une interaction entre les objets dcrits dans le
contexte de la collaboration.
Figure 196 : La transition vers lobjet est effectue en ralisant un cas dutilisation par une
collaboration.
La ralisation dun cas dutilisation par une collaboration est un instant crucial de
la modlisation ; cest le moment du virage vers lobjet. Une dcomposition qui
suit directement la forme des cas dutilisation conduit une approche structure
classique, avec tous les dfauts des structures calques sur les fonctions.
Une approche objet ralise un cas dutilisation au moyen dune collaboration
entre objets. Les scnarios, instances du cas dutilisation, sont reprsents par
des diagrammes dinteraction (diagrammes de collaboration et diagrammes de
squence).
La figure suivante illustre le choix de dcomposition aprs ltude des cas
dutilisation.
Cas 1
<<Utilise>>
Cas 2
Cas 3
Figure 197 : Reprsentation du virage vers lobjet aprs une tude des cas dutilisation.
Les diagrammes dobjets

Les diagrammes dobjets, ou diagrammes dinstances, montrent des objets et des
liens. Comme les diagrammes de classes, les diagrammes dobjets reprsentent la
structure statique. La notation retenue pour les diagrammes dobjets est drive
de celle des diagrammes de classes ; les lments qui sont des instances sont
souligns.
Les diagrammes dobjets sutilisent principalement pour montrer un contexte, par
exemple avant ou aprs une interaction, mais galement pour faciliter la
comprhension des structures de donnes complexes, comme les structures
rcursives.
Reprsentation des objets

Chaque objet est reprsent par un rectangle qui contient soit le nom de lobjet,
soit le nom et la classe de lobjet (spars par un double point), soit seulement la
classe de lobjet (lobjet est alors dit anonyme). Le nom seul correspond une
modlisation incomplte dans laquelle la classe de lobjet na pas encore t
prcise. La classe seule vite lintroduction de noms inutiles dans les
diagrammes, tout en permettant lexpression de mcanismes gnraux, valables
pour de nombreux objets. Le diagramme suivant illustre les trois possibilits de
reprsentation.
Nom de l'objet
Nom de l'objet : Classe
: Classe
Figure 198 : Reprsentations graphiques dun objet ; le nom ou la classe de lobjet peuvent
tre supprims du diagramme.
Le nom de la classe peut contenir le chemin complet, compos partir des noms
des diffrents paquetages englobants spars par des doubles deux points,
comme dans lexemple suivant :
BoutonOK : IHM::Contrles::BoutonPoussoir
Figure 199 : Exemple de reprsentation du chemin daccs complet de la classe de lobjet.
Le strotype de la classe peut tre repris dans le compartiment de lobjet, soit

sous la forme textuelle (entre guillemets au dessus du nom de lobjet), soit sous la
forme graphique (dans le coin haut droit), soit encore au moyen dune
reprsentation graphique particulire qui se substitue au symbole de lobjet. Il
nexiste pas de strotype dobjet ; le strotype qui figure dans un objet est
toujours le strotype de la classe de lobjet.
<<Exception>>
DivisionParZro
Figure 200 : Exemple de reprsentation du strotype de la classe dans le symbole dun

objet.
Les rectangles qui symbolisent les objets peuvent galement comporter un

deuxime compartiment qui contient les valeurs des attributs. Le type des
attributs est dj dcrit dans la classe, de sorte quil nest plus ncessaire de le
faire figurer dans les reprsentations dobjets. Le diagramme suivant reprsente
un objet anonyme de la classe Voiture, muni dun attribut Couleur dont la

valeur est rouge.
: Voiture
Couleur = rouge
Figure 201 : Exemple dobjet anonyme de la classe Voiture, muni dun attribut
Couleur dont la valeur est rouge.
Reprsentation des liens

Les objets sont relis par des liens qui sont instances des relations entre les
classes des objets considrs. La reprsentation concrte dune structure par des
objets est souvent plus parlante que celle abstraite par des classes, surtout dans
le cas de structures rcursives.
Le diagramme dobjets suivant montre une partie de la structure gnrale des
voitures. Chaque voiture possde un moteur et quatre roues (roue de secours
exclue !).
: Voiture
: Roue
: Roue
: Moteur
: Roue
: Roue
Figure 202 : Exemple de diagramme dobjets.
Le diagramme dobjets prcdent est instance du diagramme de classes suivant.

Moteur
Voiture
1
1
4
Roue
Figure 203 : Exemple de diagramme de classes. Reprsentation gnrale de la situation

particulire montre dans la figure prcdente.
Les liens instances des associations rflexives peuvent relier un objet lui-mme.
Dans ce cas, le lien est reprsent par une boucle attache un seul objet. Le
diagramme suivant reprsente deux liens, instances de la mme association
rflexive. Le premier lien montre quEtienne est le patron de Jean-Luc, le deuxime

lien montre que Denis est son propre patron.
Collaborateur
Personne
Patron
Etienne : Personne
Patron
Patron
Denis : Personne
Jean-Luc : Personne
Figure 204 : Exemple de liens instances dune relation rflexive. Etienne est le patron de
Jean-Luc, Denis est son propre patron.
La plupart des liens sont binaires. Il existe toutefois certains liens darit
suprieure, par exemple ceux qui correspondent aux relations ternaires. La
reprsentation des liens ternaires peut se combiner avec les autres lments de la
notation : le diagramme suivant reprsente une famille de liens ternaires, instances
dune association ternaire de multiplicit N du ct de la classe Etudiant. Cette
notation prsente lavantage de lever les ambiguts inhrentes la
reprsentation de la multiplicit des associations darit suprieure 2.
Figure 205 : Exemple de combinaison dlments de notation pour reprsenter de manire

condense des liens ternaires multiples.
Les objets composites

Les objets composs de sous-objets peuvent tre reprsents au moyen dun
objet composite, afin de rduire la complexit des diagrammes. Les objets
composites se prsentent comme des objets classiques, si ce nest que les
attributs sont remplacs par des objets, soit sous une forme textuelle souligne,
soit sous une forme graphique. Le diagramme suivant reprend la forme graphique
des objets composites.
Un composite
: Partie
: Partie
: Partie
Figure 206 : Reprsentation graphique des objets composites.
Les objets composites sont instances de classes composites, cest--dire de

classes construites partir dautres classes par la plus forte forme dagrgation.
Le diagramme suivant reprsente une classe composite Fentre.
2
Fentre
Ascenseur
1
1
1
Zone de dessin
Figure 207 : Exemple dune classe composite Fentre qui contient une zone de dessin et
deux ascenseurs.
Le diagramme dobjets suivant est instance du diagramme de classe prcdent : il

reprsente la forme gnrale des objets composites Fentre, du point de vue
des objets.
: Fentre
: Zone de dessin
: Ascenseur
: Ascenseur
Figure 208 : Reprsentation dun objet composite, instance de la classe composite dcrite
dans le diagramme prcdent.
Similitudes avec les diagrammes de classes

Les dcorations qui figurent dans les diagrammes de classes peuvent en grande
partie tre reportes dans les diagrammes dobjets, afin de faciliter la
comprhension de linteraction. Ceci concerne toutes les caractristiques des
associations (le nom, le nom des rles, lagrgation, la composition et la
navigation), lexception de la multiplicit qui se reprsente de manire explicite
par les liens. Le diagramme dobjets suivant se distingue graphiquement dun
diagramme de classe car les noms dobjets sont souligns.
Passagers
: Personne
: Bus
Conducteur
: Personne
: Destination
Figure 209 : Exemple de diagramme dobjets, dcor comme un diagramme de classes.
Les valeurs des cls de restriction des associations peuvent galement tre
rajoutes dans les diagrammes dobjets. Le diagramme suivant reprsente les
liens de parent entre Lara, Jonathan, Roxane, Anne et Pierre-Alain.
Figure 210 : Exemple de reprsentation des valeurs des cls de restriction des associations.
Les diagrammes de collaboration

Les diagrammes de collaboration montrent des interactions entre objets, en
insistant plus particulirement sur la structure spatiale statique qui permet la mise
en collaboration dun groupe dobjets. Les diagrammes de collaboration
expriment la fois le contexte dun groupe dobjets (au travers des objets et des
liens) et linteraction entre ces objets (par la reprsentation des envois de
messages). Les diagrammes de collaboration sont une extension des diagrammes
dobjets.
Reprsentation des interactions

Le contexte dune interaction comprend les arguments, les variables locales
cres pendant lexcution, ainsi que les liens entre les objets qui participent
linteraction.
Une interaction est ralise par un groupe dobjets qui collaborent en changeant
des messages. Ces messages sont reprsents le long des liens qui relient les
objets, au moyen de flches orientes vers le destinataire du message.
Le diagramme suivant reprsente une cabine dascenseur qui demande une
porte de souvrir.
: Cabine
Ouvrir
: Porte
Figure 211 : Exemple dinteraction entre deux objets. La cabine demande la porte de
souvrir.
Dans un diagramme de collaboration, le temps nest pas reprsent de manire

implicite, comme dans un diagramme de squence, de sorte que les diffrents
messages sont numrots pour indiquer lordre des envois.
: Ascenseur
1: Monter
: Cabine
3: Fermer
2: Allumer
: Porte
: Lumire
Figure 212 : Exemple de reprsentation de lordre des envois de message.
Les diagrammes de collaboration montrent simultanment les interactions entre

les objets et les relations structurelles qui permettent ces interactions. Le
diagramme suivant reprsente le contexte dun mcanisme pour annuler une
opration de destruction. Avant de dclencher lopration de destruction de
lobjet B, lobjet A effectue une copie locale de B, de sorte que si lopration de
destruction venait tre annule, lobjet B puisse tre restitu tel quil tait avant
le droulement de linteraction.
Destruction
A
B
{local}
Copie de B
Figure 213 : Reprsentation dune interaction entre trois objets. Lobjet B a t copi
localement par lobjet A, dans le but de permettre lannulation ventuelle de la destruction de
B.
Les objets et les liens crs ou dtruits au cours dune interaction peuvent
respectivement porter les contraintes {nouveau} ou {dtruit}. Les objets
crs, puis dtruits au sein de la mme interaction, sont identifis par la contrainte
{transitoire}.
B
{nouveau}
A
D
{dtruit}
C
{transitoire}
Figure 214 : Reprsentation de la cration et de la destruction des objets et des liens.
La notation permet de reprsenter de manire condense une famille de liens,

instances dune mme association. Cette approche est particulirement
intressante lorsque le groupe dobjets considr est trait de manire uniforme,
en tant par exemple destination dun mme message. Lexemple suivant montre
un instituteur qui demande tous ses lves de se lever ; litration est indique
par le caractre * plac devant le message.
: Instituteur
Instituteur
Elve
1
: Elve
*[tous] : Debout
Figure 215 : Reprsentation condense dune famille de liens, instances dune mme
association.
La place de lutilisateur
La notation permet de faire figurer un acteur dans un diagramme de collaboration
afin de reprsenter le dclenchement des interactions par un lment externe au
systme. Grce cet artifice, linteraction peut tre dcrite de manire plus
abstraite, sans entrer dans les dtails des objets de linterface utilisateur. Le
premier message de linteraction est envoy par lacteur, reprsent soit par le
symbole graphique des acteurs du modle des cas dutilisation, soit par un objet
muni dun strotype qui prcise sa qualit dacteur. Le diagramme suivant
montre un fragment dinteraction ; elle correspond un appel de cabine
dascenseur par une personne.
1: Venir me chercher au RDC
: Personne
: Cabine
: Ascenseur
2: Ajouter destination RDC
Figure 216 : Exemple de dclenchement dune interaction par un acteur.
Les objets actifs

Les objets qui possdent le flot de contrle sont dits dactifs. Un objet actif peut
activer un objet passif pour le temps dune opration, en lui envoyant un
message. Une fois le message trait, le flot de contrle est restitu lobjet actif.
Dans un environnement multitche, plusieurs objets peuvent tre actifs
simultanment. Un objet actif se reprsente par un rectangle dont la bordure est
plus paisse que celle des objets passifs.
: Traitement de texte
2 : Ecrire
1 : Lire
: Imprimante
: Scanner
Figure 217 : Reprsentation des objets actifs. Le cadre des objets actifs est plus pais que
celui des objets passifs.
Reprsentation des messages

Un message se reprsente par une flche place proximit dun lien et dirige
vers lobjet destinataire du message. Un lien sert de support de transmission pour
le message. Un message dclenche une action dans lobjet destinataire.
Les messages respectent la forme gnrale suivante :
synchronisation squence : rsultat := nom
arguments
Le message, ses arguments et valeurs de retour, son rang au sein de linteraction,
et diverses autres informations comme le degr dembotement ou la
synchronisation sont prciss lors de lenvoi.
Synchronisation
Le point de synchronisation dun message est exprim sous la forme dune
squence denvoi de message, termine par le caractre /. Tous les messages
rfrencs dans cette liste doivent avoir t envoys pour valider lenvoi du
message courant.
La syntaxe dun point de synchronisation prend la forme suivante :
synchronisation ::= rang {, synchronisation} /
rang ::= [entier | nom de flot dexcution]{. rang}
Lentier reprsente le rang de lenvoi de message au sein de lembotement
englobant. Le nom identifie un flot dexcution parallle au sein dun
embotement. Ainsi, lenvoi de message 3.1.3 suit immdiatement lenvoi
3.1.2 au sein de lembotement 3.1, alors que lenvoi 3.1.a est effectu
simultanment lenvoi 3.1.b.
Dans lexemple suivant, le message Message est envoy lorsque les envois A.1
et B.3 ont t satisfaits.
A.1, B.3 / Message
Figure 218 : Exemple de reprsentation de la synchronisation entre flots dexcution

parallles.
Squence
La squence indique le niveau dembotement de lenvoi de message au sein de
linteraction. La squence est constitue dune suite de termes spars par des
points. Chaque squence possde la syntaxe suivante :
squence ::= rang [rcurrence]

La rcurrence reprsente litration et les branchements conditionnels ; elle prend
les formes suivantes :
rcurrence ::= * [ clause ditration ] bloc
ou
rcurrence ::= [ clause de condition ] bloc
La clause ditration est optionnelle ; elle est exprime dans un format libre :
A
*[i :=1..n] : Message
:X
Figure 219 : Exemple de reprsentation de litration.
La notation de litration sous-entend lenvoi squentiel des messages contenus

par le bloc. Lenvoi parallle (galement appel diffusion) est matrialis par la
suite de caractres *||.
La clause de condition valide ou non lenvoi des messages contenus par le bloc.
La clause de condition est exprime dans un format libre :
B
[X>Y] : Message
A
Figure 220 : Exemple de reprsentation dun envoi de message conditionnel.
Rsultat
Le rsultat est constitu dune liste de valeurs retournes par le message. Ces
valeurs peuvent tre utilises comme paramtres des autres messages compris
dans linteraction. Ce champ nexiste pas en labsence de valeurs retournes. Le
format de ce champ est libre :
p := Question
A
Figure 221 : Reprsentation de la rcupration dun rsultat.
Nom
Il sagit du nom du message. Souvent ce nom correspond une opration dfinie
dans la classe de lobjet destinataire du message.
Arguments
Il sagit de la liste des paramtres du message. Les arguments et le nom du
message identifient de manire unique laction qui doit tre dclenche dans
lobjet destinataire. Les arguments peuvent contenir des valeurs retournes par
des messages envoys prcdemment, ainsi que des expressions de navigation
construites partir de lobjet source.
Les expressions suivantes donnent quelques exemples de la syntaxe denvoi des
messages :
4 : Afficher (x, y) -- message simple
3.3.1 : Afficher (x, y) -- message imbriqu
4.2 : ge := Soustraire (Aujourdhui,
DateDeNaissance)
-- message imbriqu avec valeur retourne
[Age >= 18 ans] 6.2 : Voter () - message
conditionnel
4.a, b.6 / c.1 : Allumer (Lampe) synchronisation avec dautres flots dexcution
1 * : Laver () - itration
3.a, 3.b / 4 *||[i := 1..n] : Eteindre () itration parallle
Les arguments des messages sont reprsents dans les diagrammes, soit en
utilisant du pseudo-code, soit directement dans la syntaxe du langage de
programmation. La notation propose galement une reprsentation graphique des
arguments sous la forme de flches termines par de petits cercles. Le diagramme
suivant donne un exemple de reprsentation graphique des arguments dun
message.
Message
Argument
Argument
Figure 222 : Reprsentation graphique des arguments dun message au moyen de flches
termines par de petits cercles.
Les collaborations
Une collaboration est un mcanisme compos dlments structurels et
comportementaux. Les collaborations fournissent un mcanisme dorganisation,
mais possdent, contrairement aux paquetages, une identit et une porte
smantique. Un mme lment peut intervenir dans plusieurs collaborations.
Une collaboration englobe deux genres de construction : un contexte compos
d'une description de la structure statique des objets concerns et une interaction
reprsente par une squence de messages changs par les dits objets. Les deux
aspects sont requis pour pleinement documenter le comportement, mais chaque
aspect peut tre visualis indpendamment.
Les collaborations s'emploient, selon leur niveau de dtail, pour dcrire des
spcifications et pour exprimer des ralisations. Le tableau suivant rsume les
lments de modlisation qui peuvent tre dcrits par une collaboration.
Spcification
Type
Opration
Cas dutilisation
Ralisation
Classe
Mthode
Ralisation de cas dutilisation
Figure 223 : Tableau rcapitulatif des lments de modlisation qui peuvent tre dcrits par
des collaborations.
Les collaborations existent galement sous une forme gnrique (modle),

paramtre par des classes, des relations, des attributs et des oprations. Une
collaboration gnrique est appele pattern, ou schme 15 et micro-architecture en

franais. Les patterns possdent toujours un nom, contrairement aux
collaborations qui peuvent rester anonymes.
Type
0..1
Reprsente
Opration
{Ou}
*
Comportement
0..1
Reprsente
*
*
0..1
Collaboration
Modle : Boolen
*
*
Type
*
*
Relation
*
*
Contrainte
*
Note
*
Instance
Figure 224 : Extrait du mtamodle. Reprsentation des collaborations.
Les interactions
Une interaction exprime le comportement qui rsulte de la collaboration dun
groupe dinstances. Une interaction peut tre visualise selon le point de vue du
temps (par les diagrammes de squence) ou selon le point de vue de lespace (par
les diagrammes de collaboration). Les interactions comprennent principalement
les lments suivants :
les instances qui sont la manifestation concrte d'un type,
les liens qui relient les instances et servent de support pour les envois de
message,
les messages qui dclenchent les oprations,
les rles jous par les extrmits des liens.
15
Ma prfrence va cette traduction, mais lheure actuelle tout le monde parle

de pattern, jen ferai donc autant !
Comportement
0..1
0..*
Relation
Collaboration
0..1 Interaction
0..*
0..*
Instance
Lien
0..*
Association
0..1
1
0..* 2..*
Participant
Message
Rle
0..*
Figure 225 : Extrait du mtamodle. Reprsentation des interactions.
Les diagrammes de squence

Les diagrammes de squence montrent des interactions entre objets selon un
point de vue temporel. Le contexte des objets nest pas reprsent de manire
explicite comme dans les diagrammes de collaboration. La reprsentation se
concentre sur lexpression des interactions.
Reprsentation des interactions

Un diagramme de squence reprsente une interaction entre objets en insistant
sur la chronologie des envois de messages. La notation est drive des Object
Message Sequence Chart16 du Siemens Pattern Group. Un objet est matrialis
par un rectangle et une barre verticale appele ligne de vie des objets.
Nom : Classe
Figure 226 : Reprsentation graphique dun objet.
Les objets communiquent en changeant des messages reprsents au moyen de

flches horizontales, orientes de lmetteur du message vers le destinataire.
Lordre denvoi des messages est donn par la position sur laxe vertical. Laxe
16
Wiley 1996, Pattern-Oriented Software Architecture : A System of Patterns.

ISBN 0471958697.
vertical peut tre gradu afin dexprimer prcisment les contraintes temporelles,
dans le cas par exemple de la modlisation dun systme temps rel.
Un objet
Un autre objet
Encore un objet
Un message
Un autre message
Figure 227 : Exemple de diagramme de squence.
En modlisation objet, les diagrammes de squence sutilisent de deux manires

bien diffrentes, selon la phase du cycle de vie et le niveau de dtail dsir.
La premire utilisation correspond la documentation des cas dutilisation ; elle
se concentre sur la description de linteraction, souvent dans des termes proches
de lutilisateur et sans entrer dans les dtails de la synchronisation. Lindication
porte sur les flches correspond alors des vnements qui surviennent dans le
domaine de lapplication. A ce stade de la modlisation, les flches ne
correspondent pas encore des envois de messages au sens des langages de
programmation, et la distinction entre flots de contrle et flots de donnes nest
gnralement pas opre. La figure suivante reprsente le dbut dune
communication tlphonique.
Appelant
Ligne
tlphonique
Appel
Dcroche
Tonalit
Numrotation
Indication de sonnerie
Sonnerie
Dcroche
All
Figure 228 : Exemple dutilisation dun diagramme de squence pour la reprsentation

dvnements qui surviennent dans le domaine.
La deuxime utilisation correspond un usage plus informatique et permet la

reprsentation prcise des interactions entre objets. Le concept de message unifie
toutes les formes de communication entre objets, en particulier lappel de
procdure, lvnement discret, le signal entre flots dexcution ou encore
linterruption matrielle.
Les diagrammes de squence distinguent deux grandes catgories denvois de
message :
les envois synchrones pour lesquels lmetteur est bloqu et attend que
lappel ait fini de traiter le message,
les envois asynchrones pour lesquels lmetteur nest pas bloqu et peut
continuer son excution.
Un envoi synchrone se reprsente par une flche qui part de lmetteur du

message et pointe vers son destinataire. Un envoi asynchrone se reprsente par
une demi-flche.
A
Message synchrone
Message asynchrone
Figure 229 : Reprsentation graphique des envois de message synchrones et asynchrones.
La flche qui symbolise un message peut tre reprsente en oblique pour

matrialiser les dlais de transmission non ngligeables par rapport la
dynamique gnrale de lapplication.
Un objet
Un autre objet
Un message
Figure 230 : Reprsentation dun dlai de propagation.
Un objet peut galement senvoyer un message. Cette situation se reprsente par

une flche qui boucle sur la ligne de vie de lobjet.
Un objet
Message
rflexif
Figure 231 : Exemple denvoi de message rflexif.
Cette construction ne correspond pas toujours un vrai message ; elle peut

indiquer un point dentre dans une activit de plus bas niveau, qui sexerce au
sein de lobjet. Les interactions internes (entre objets contenus par un objet
composite) reprsentes par un message rflexif peuvent aussi tre dcrites dans
un diagramme de squence.
Objet composite
Composant a Composant b
Point d'entre
Figure 232 : Utilisation dun message rflexif comme point dentre dune interaction
interne.
La cration des objets se reprsente en faisant pointer le message de cration sur

le rectangle qui symbolise lobjet cr. La destruction est indique par la fin de la
ligne de vie et par une lettre X, soit la hauteur du message qui cause la
destruction, soit aprs le dernier message envoy par un objet qui se suicide.
Un objet
Crer
Un autre objet
Dtruire
Figure 233 : Reprsentation de la cration et de la destruction des objets.
Les diagrammes de squence permettent galement de reprsenter les priodes

dactivit des objets. Une priode dactivit correspond au temps pendant lequel
un objet effectue une action, soit directement, soit par lintermdiaire dun autre
objet qui lui sert de sous-traitant. Les priodes dactivit se reprsentent par des
bandes rectangulaires places sur les lignes de vies. Le dbut et la fin dune
bande correspondent respectivement au dbut et la fin dune priode dactivit.
Un objet
Activation
Figure 234 : Reprsentation de la priode dactivit dun objet au moyen dune bande
rectangulaire superpose la ligne de vie de lobjet.
Le diagramme suivant montre le cas dun objet A qui active un autre objet B. La
priode dactivit de lobjet A recouvre la priode dactivit de lobjet B. Dans le
cas dun appel de procdure, le flot dexcution est pass par lobjet A lobjet B.
Lobjet A est alors bloqu jusqu' ce que lobjet B lui redonne la main.
Figure 235 : Exemple dobjet qui active un autre objet.
Dans le cas dun appel de procdure, et plus gnralement dans le cas des envois
synchrones, le retour en fin dexcution de lopration est implicite : il nest pas
ncessaire de le reprsenter dans les diagrammes. Lobjet A reprend son
excution lorsque laction dclenche dans lobjet B est termine.
A
Retour
implicite
Figure 236 : Dans le cas des envois synchrones, le retour est implicite en fin dactivit et ne
ncessite pas de reprsentation particulire.
En revanche, dans le cas des envois asynchrones, le retour doit tre matrialis
lorsquil existe. Le diagramme suivant montre un objet B initialement activ par un
objet A, qui retourne un message lobjet A avant de cesser son excution. Il faut
noter que la fin de lactivation dun objet ne correspond pas la fin de sa vie. Un
mme objet peut tre activ de nombreuses fois au cours de son existence.
X
Retour
explicite
Retour
explicite
avant suicide
Figure 237 : Reprsentation explicite du retour dans le cas des envois asynchrones. La lettre
X symbolise une fin dactivit qui correspond galement une fin de vie.
Le cas particulier des envois de messages rcursifs se reprsente par un

ddoublement de la bande rectangulaire. Lobjet apparat alors comme sil tait
actif plusieurs fois.
Un objet
Rcursion
Figure 238 : Reprsentation de la rcursion dans les diagrammes de squence.
Structures de contrle
Les formes des diagrammes de squence refltent indirectement les choix de
structure. Les deux diagrammes suivants prsentent respectivement un mode de
contrle centralis et un mode dcentralis.
Contrle dcentralis
Contrle centralis
Figure 239 : La forme des diagrammes de squence est le reflet du mode de contrle de
linteraction.
Les diagrammes de squence peuvent tre complts par des indications

textuelles, exprimes sous la forme de texte libre ou de pseudo-code. Linstant
dmission dun message, appel transition, peut tre nomm dans le diagramme
proximit du point de dpart de la flche qui symbolise le message. Ce nom sert
alors de rfrence, par exemple pour construire des contraintes temporelles,
comme dans le diagramme suivant. Lorsque la propagation dun message prend
un temps significatif par rapport la dynamique du systme, les instants
dmission et de rception des messages sont matrialiss par un couple (nom,
nom prime).
A
Message
{y-x < 3 s}
y
{z-y < 1 s}
Message
Message
z
t
Message
{t'-t < 2 s}
t'
Figure 240 : Exemples de contraintes temporelles construites partir de noms de transitions.
Lajout de pseudo-code sur la partie gauche du diagramme permet la

reprsentation des boucles et des branchements, de sorte que les diagrammes de
squence peuvent reprsenter la forme gnrale dune interaction, au-del de la
seule prise en compte dun scnario particulier.
Le diagramme suivant reprsente une boucle While. Lobjet A envoie sans

discontinuer un message B tant que la condition X est vraie.
A
while X
loop
B
Message
end loop
Figure 241 : Exemple de reprsentation dune boucle While au moyen de pseudo-code.
La boucle while peut galement tre reprsente au moyen d'une condition

ditration place directement sur le message. Litration est alors symbolise par
le caractre *, plac devant la condition entre crochets.
A
*[X] Message
Figure 242 : Reprsentation alternative de la boucle While au moyen dune condition

place devant le message.
Comme pour les boucles, les branchements conditionnels peuvent tre

matrialiss au moyen de pseudo-code plac sur la gauche du diagramme. Le
diagramme suivant montre que lobjet A envoie un message lobjet B o u
lobjet C selon la condition X.
Message
If X
else
Message
end if
Figure 243 : Reprsentation des branchements conditionnels par lajout de pseudo-code.
Comme prcdemment, des conditions places devant les messages peuvent se

substituer au pseudo-code. Les diffrentes branches sont alors matrialises par
plusieurs flches qui prennent leur origine au mme instant et se distinguent par
les conditions places devant les messages. A chaque branchement, les
conditions doivent tre mutuellement exclusives, et tous les cas doivent tre
couverts.
A
[X] Message
[non X] Message
Figure 244 : Reprsentation graphique des branchements conditionnels.
Les alternatives, du ct du destinataire du message, sont reprsentes en

ddoublant la ligne de vie de lobjet destinataire. La distinction entre les branches
est indique par une condition place cette fois-ci derrire le message, proximit
du point dentre sur la ligne de vie de lobjet destinataire.
B
[X]
Message
[Y]
Figure 245 : Reprsentation graphique des branchements conditionnels.
Le pseudo-code permet galement de mettre en correspondance linteraction

initiale, dcrite par lutilisateur lors de ltude des cas dutilisation, avec une
interaction entre objets du domaine, construite par lanalyste.
Les diagrammes dtats-transitions

Les diagrammes dtats-transitions visualisent des automates dtats finis, du
point de vue des tats et des transitions.
Les automates
Le comportement des objets dune classe peut tre dcrit de manire formelle en
termes dtats et dvnements, au moyen dun automate reli la classe
considre.
Classe
Automate
1
0..1
Figure 246 : Un automate peut tre associ chaque classe du modle.
Les objets qui ne prsentent pas un comportement ractif trs marqu peuvent
tre considrs comme des objets qui restent toujours dans le mme tat : leurs
classes ne possdent alors pas dautomate.
Le formalisme retenu par UML pour reprsenter les automates sinspire des
Statecharts17. Il sagit dautomates hirarchiques, possdant les concepts
dorthogonalit, dagrgation et de gnralisation (ces notions sont dfinies plus
loin dans le chapitre).
17

Un automate est une abstraction des comportements possibles, limage des

diagrammes de classes qui sont des abstractions de la structure statique. Chaque
objet suit globalement le comportement dcrit dans lautomate associ sa classe
et se trouve un moment donn dans un tat qui caractrise ses conditions
dynamiques.
Les automates et les scnarios sont complmentaires. Les scnarios se
reprsentent par une collaboration entre objets. La forme de linteraction entre les
objets qui collaborent au sein dun scnario est dtermine par les tats respectifs
des diffrents objets. Les automates peuvent tre utiliss pour dcrire le
comportement de groupes dobjets, en associant un automate un composite,
voire un cas dutilisation.
Un feu tricolore passe successivement de ltat vert, ltat orange puis ltat
rouge, avant de repasser ltat vert, et ainsi de suite durant toute sa priode de
fonctionnement.
Feu tricolore
Rouge
Orange
Vert
Figure 247 : De manire gnrale, tous les feux tricolores sont soit ltat rouge, soit ltat
orange, soit ltat vert.
Il est bien vident quil faut synchroniser ltat des feux qui se trouvent placs
autour du mme carrefour. Cette synchronisation, qui dpend de ltat du
carrefour, peut aussi tre dcrite dans un automate associ la classe des
carrefours.
Les tats
Chaque objet est un moment donn dans un tat particulier. Les tats se
reprsentent sous la forme de rectangles arrondis ; un chaque tat possde un
nom qui lidentifie.
Un tat
Un autre tat
Figure 248 : Les tats se reprsentent au moyen de rectangles arrondis. Chaque tat possde
un nom qui doit tre unique dans une porte lexicale donne.
Les tats se caractrisent par la notion de dure et de stabilit. Un objet est

toujours dans un tat donn pour un certain temps et un objet ne peut tre dans
un tat inconnu ou non dfini. Un tat est toujours limage de la conjonction
instantane des valeurs contenues par les attributs de lobjet, et de la prsence
ou non de liens, de lobjet considr vers dautres objets.
Le diagramme de classes suivant reprsente des personnes qui travaillent pour
des socits.
Socit
Personne
0..1
1..* Age
Figure 249 : Les personnes travaillent pour des socits.
Les personnes ne possdent pas toutes un emploi et se trouvent, un moment

donn, dans un des tats suivants : en activit, au chmage ou la retraite. La
figure suivante visualise les trois tats dune personne.
En activit
A la retaite
Au chmage
Figure 250 : Une personne peut tre soit en activit, soit au chmage, soit la retraite.
Pour connatre la situation dune personne en particulier, il faut tudier la

conjonction suivante :
ge de la personne,
prsence dun lien vers une socit.
Dans le diagramme suivant, il ny a pas de lien entre Toto, g de 30 ans, et une

socit : Toto est donc au chmage. Titi, quant lui, possde un lien vers une
socit et est g de 40 ans : Titi est donc en activit. Ernest, enfin, ne possde
pas de lien vers une socit et est g de 75 ans : Ernest est donc la retraite.
Toto
Age : 30 ans
Titi
: Socit
Age : 40 ans
Ernest
Age : 75 ans
Figure 251 : Ltat des trois personnes est diffrent. Toto est au chmage, Titi en activit et
Ernest la retraite.
Les automates retenus par UML sont dterministes. Un diagramme dtatstransitions ne doit pas laisser de place aux constructions ambigus. Cela signifie
en particulier quil faut toujours dcrire ltat initial du systme. Pour un niveau
hirarchique donn, il y a toujours un et un seul tat initial. En revanche, il est
possible davoir plusieurs tats finaux qui correspondent chacun une condition
de fin diffrente. Il est galement possible de navoir aucun tat final, dans le cas
par exemple dun systme qui ne sarrte jamais.
Ltat initial se reprsente par un gros point noir. Un tat final se reprsente par
un gros point noir encercl.
Etat intermdiaire
Etat initial
Etat final
Figure 252 : Ltat initial est reprsent par un point noir. Un tat final est reprsent par un
point noir encercl.
Les transitions
Lorsque les conditions dynamiques voluent, les objets changent dtat en
suivant les rgles dcrites dans lautomate associ leurs classes. Les
diagrammes dtats-transitions sont des graphes dirigs. Les tats sont relis par
des connexions unidirectionnelles, appeles transitions. Le passage dun tat
lautre seffectue lorsquune transition est dclenche par un vnement qui
survient dans le domaine du problme. Le passage dun tat un autre est
instantan car le systme doit toujours tre dans un tat connu.
Figure 253 : Une transition permet de passer dun tat un autre tat ; elle se reprsente au
moyen dune flche qui pointe de ltat de dpart vers ltat darrive.
Les transitions ne relient pas ncessairement des tats distincts. Lexemple

suivant dcrit un fragment danalyseur lexical. La reconnaissance des units
lexicales est effectue dans un tat de lecture. Lautomate reste dans cet tat tant
que les caractres lus ne sont pas des sparateurs.
Pas un sparateur
Lecture unit lexicale

Sparateur
B
Figure 254 : Exemple de transition dun tat vers lui-mme dans un fragment dautomate
lexical.
Les vnements
Un vnement correspond loccurrence dune situation donne dans le domaine
du problme. Contrairement aux tats qui durent, un vnement est par nature une
information instantane qui doit tre traite sans plus attendre. Un vnement
sert de dclencheur pour passer dun tat un autre. Les transitions indiquent les
chemins dans le graphe des tats. Les vnements dterminent quels chemins
doivent tre suivis. Les vnements, les transitions et les tats sont
indissociables dans la description du comportement dynamique. Un objet, plac
dans un tat donn, attend loccurrence dun vnement pour passer dans un
autre tat. De ce point de vue, les objets se comportent comme des lments
passifs, contrls par les vnements en provenance du systme.
A
Evnement
Figure 255 : Un vnement dclenche la transition qui lui est associe.
La syntaxe gnrale dun vnement suit la forme suivante :
Nom_De_L_Evnement (Nom_De_Paramtre : Type, ...)

La spcification complte dun vnement comprend :
le nom de lvnement,
la liste des paramtres,
lobjet expditeur,
lobjet destinataire,
la description de la signification de lvnement.
Dans lexemple suivant, chaque transition porte lvnement qui la dclenche.

Plus de 60 ans
En activit
Perte d'emploi
A la retraite
Embauche
Au chmage
Plus de 60 ans
Figure 256 : Exemple dautomate.
La communication par vnement est de type asynchrone, atomique, et

unidirectionnelle. Un objet peut envoyer un vnement un autre objet qui doit
toujours tre mme de linterprter.
Un vnement
Un autre objet
Un objet
Figure 257 : Un objet peut envoyer un vnement asynchrone un autre objet.
Les besoins de communication par vnements synchrones ou les changes

bidirectionnels peuvent se reprsenter au moyen de deux changes asynchrones
de direction oppose.
Une question
Un autre objet
Un objet
La rponse
Figure 258 : Les besoins de communication par vnements synchrones peuvent se raliser
au moyen de deux vnements asynchrones, de direction oppose.
Dans ce cas, il appartient lobjet metteur de la requte de se mettre en attente

de la rponse. Ceci implique que lautomate dtats finis qui le dcrit possde une
squence du type suivant :
A
Question pose
Attente rponse
Rponse reue
B
Figure 259 : Extrait de lautomate dun objet qui communique de manire synchrone
partir dvnements asynchrones. Lmetteur de la requte doit se mettre en attente de la
rponse.
Les gardes
Une garde est une condition boolenne qui valide ou non le dclenchement dune
transition lors de loccurrence dun vnement.
A
Evnement[ Condition ]
Figure 260 : Reprsentation des gardes.
Les gardes permettent de maintenir laspect dterministe dun automate dtats

finis, mme lorsque plusieurs transitions peuvent tre dclenches par le mme
vnement. Lorsque lvnement a lieu, les gardes qui doivent tre
mutuellement exclusives sont values et une transition est valide puis
dclenche. Dans lexemple suivant, lorsquil fait trop chaud, les gardes
permettent selon la saison de dclencher un climatiseur ou douvrir tout
simplement les fentres.
A
Il fait trop chaud[ t ]
Climatiser
Il fait trop chaud[ hiver ]

Arer
Figure 261 : Lvnement il fait trop chaud entrane la climatisation ou louverture

des fentres selon la saison.
Les oprations, les actions et les activits

Le lien entre les oprations dfinies dans la spcification de classe et les
vnements apparaissant dans les diagrammes dtats-transitions est effectu par
lintermdiaire des actions et des activits.
Chaque transition peut tre dcore par le nom dune action excuter lorsque la
transaction est dclenche par un vnement. Pour respecter la smantique
gnrale de la transition, laction est considre comme instantane et atomique.
A
Evnement / Action
Figure 262 : Lorsquune transition est dclenche, laction qui lui est attache est excute
instantanment.
Laction correspond une des oprations dclares dans la classe de lobjet

destinataire de lvnement. Laction a accs aux paramtres de lvnement, ainsi
quaux attributs de lobjet. En ralit, toute opration prend un certain temps
sexcuter ; la notion daction instantane doit sinterprter comme une opration
dont le temps dexcution est ngligeable devant la dynamique du systme.
Les tats peuvent galement contenir des actions ; elles sont excutes lentre
ou la sortie de ltat ou lors de loccurrence dun vnement pendant que lobjet
est dans ltat.
Etat A
entry:
on UnEvnement:
exit:
Figure 263 : Une action peut tre excute lentre ou la sortie dun tat, ou en cas
dvnement survenant dans ltat.
Laction dentre (symbolise par le mot-cl entry:) est excute de manire

instantane et atomique ds lentre dans ltat. De mme, laction de sortie
(symbolise par exit:) est excute la sortie de ltat. Laction sur vnement
interne (symbolise par on: ) est excute lors de loccurrence dun vnement
qui ne conduit pas un autre tat. Un vnement interne nentrane pas
lexcution des actions dentre et de sortie, contrairement au dclenchement
dune transition rflexive.
E1 / Action
on E1: Action
entry: Action d'entre
exit: Action de sortie
entry: Action d'entre

exit: Action de sortie
Figure 264 : Un vnement interne nentrane pas lexcution des actions de sortie et
dentre, contrairement au dclenchement dune transition rflexive.
Les actions correspondent des oprations dont le temps dexcution est

ngligeable. Une opration qui prend du temps correspond un tat plutt qu
une action. Le mot-cl do: indique une activit, cest--dire une opration qui
prend un temps non ngligeable et qui est excute pendant que lobjet est dans
un tat donn.
Etat A
do: Une opration
Figure 265 : Les oprations qui durent sont forcment excutes au sein dun tat. Elles sont
identifies par le mot-cl do: suivi du nom de lopration.
Contrairement aux actions, les activits peuvent tre interrompues tout moment,
ds quune transition de sortie de ltat est dclenche. Certaines activits sont
cycliques et ne sarrtent que lorsquune transition de sortie est dclenche.
Dautres activits sont squentielles et dmarrent lentre dans ltat (tout de
suite aprs lexcution des actions dentre).
Lorsquune activit squentielle parvient son terme, ltat peut tre quitt si une
des transitions est franchissable. Ce type de transition qui nest pas dclenche
par un vnement est appele transition automatique.
do: Activit squentielle
[X]
do: Activit squentielle
[ not X ]
Figure 266 : Lorsque lactivit se termine, les transitions automatiques sans vnements,
mais ventuellement protges par des gardes sont dclenches.
Les tats peuvent galement contenir des variables exprimes sous la forme
dattributs. Les variables dtat appartiennent la classe associe lautomate,
mais peuvent tre reprsentes dans les diagrammes dtats-transitions
lorsquelles sont manipules par les actions ou les activits.
Login
Nom
Mot de passe
Figure 267 : Exemple de reprsentation de variables dtat.
Points dexcution des oprations

En rsum, il existe six points pour spcifier les oprations qui doivent tre
excutes. Ces points sont, dans lordre dexcution :
laction associe la transition dentre (Op1),
laction dentre de ltat (Op2),
lactivit dans ltat (Op3),
laction de sortie de ltat (Op4),
laction associe aux vnements internes (Op5),
laction associe la transition de sortie de ltat (Op6).
/ Op1
Un tat
entry: Op2
do: Op3
exit: Op4
on UnEvnement: Op5
/ Op6
Figure 268 : Le formalisme des diagrammes dtats-transitions offre six points pour spcifier
les oprations qui doivent tre excutes.
Gnralisation dtats
Les diagrammes dtats-transitions peuvent devenir assez difficiles lire lorsque,
du fait de lexplosion combinatoire, le nombre de connexions entre tats devient
lev : le diagramme se met alors ressembler un plat de spaghettis.
La solution pour matriser cette situation consiste utiliser le principe de
gnralisation dtats. Les tats plus gnraux sont appels super-tats, les tats
plus spcifiques sont appels sous-tats. Cette approche dabstraction procde
de la mme dmarche que la gnralisation et la spcialisation des classes ; elle
facilite la reprsentation et permet docculter les dtails.
Un tat peut tre dcompos en plusieurs sous-tats disjoints ; les sous-tats
hritent des caractristiques de leur super-tat, en particulier des variables dtat
et des transitions externes. La dcomposition en sous-tats est galement appele
dcomposition disjonctive (dcomposition de type ou-exclusif) car lobjet doit
tre dans un seul et un seul sous-tat la fois.
Les deux diagrammes suivants illustrent la simplification apporte par la
gnralisation dtats.
A
E1
E2
E2
C
Figure 269 : Exemple dautomate dans lequel la transition E2 peut tre factorise.
E1
A
B
E2
C
Figure 270 : Reprsentation hirarchique de lautomate prcdent.
Les transitions internes peuvent tre hrites, sauf si la dcomposition en soustats a pour objet de dfinir un tat particulier pour le traitement dune transition
interne. Les transitions dentre ne sont pas hrites par tous les tats ; seul un
tat (le super-tat ou un de ses sous-tats) peut tre cible de la transition. Dans
lexemple suivant, ltat B est divis en deux sous-tats B1 et B2. La transition
dentre dans ltat B doit tre reporte sur un des sous-tats, soit directement
(comme dans le diagramme suivant), soit indirectement au moyen dun tat initial
embot.
A
B
A
B1
B2
Figure 271 : Ltat B est divis en deux sous-tats B1 et B2. La transition dentre dans ltat
B doit tre reporte directement sur un des sous tats.
Dans lexemple prcdent, ltat A est reli au sous-tat B1. Cette situation
manque dabstraction et est comparable un mcanisme crit selon la
spcification dune super-classe, mais ayant besoin de connatre le dtail des
sous-classes. Il est toujours prfrable de limiter les liens entre niveaux
hirarchiques dun automate en dfinissant systmatiquement un tat initial pour
chaque niveau. Le diagramme suivant limite les connaissances entre niveaux.
B
B1
B2
Figure 272 : Amlioration du niveau dabstraction dun automate par lajout dun tat
initial dans un super-tat.
La visualisation exhaustive des sous-tats induit une forte charge dinformation

dans les diagrammes. Le dtail des sous-tats peut tre masqu, pour donner par
exemple une vision de plus haut niveau. Grce la notion de souche il est
possible de montrer que les transitions entrantes dans un tat composite
concernent un sous-tat particulier, sans pour autant entrer dans les dtails de la
reprsentation de ces sous-tats.
B
A
Figure 273 : Les souches rduisent la charge dinformation, tout en matrialisant la prsence
des sous-tats de B.
Agrgation dtats
Lagrgation dtats est la composition dun tat partir de plusieurs autres tats
indpendants. La composition est de type conjonctive (composition de type et)
ce qui implique que lobjet doit tre simultanment dans tous les tats composant
lagrgation dtats. La conjonction dtats reprsente une forme de paralllisme
entre automates.
Lexemple suivant illustre diffrents aspects de la notion dagrgation dtats.
Ltat S est un agrgat form de deux tats indpendants T et U ; T est compos
des sous-tats X, Y et Z, et U des sous-tats A et B. Le domaine de S est le
produit cartsien de T et U.
S
T
X
E3
U
E1
A
Y
E1
Z
E2
E4[ in Z ]
B
Figure 274 : Exemple dautomate agrgation dtats. Ltat S appartient au produit

cartsien des tats T et U.
Une transition entrante dans ltat S implique lactivation simultane des

automates T et U, cest--dire que lobjet est plac dans ltat composite (Z,A).
Lorsque lvnement E3 a lieu, les automates T et U peuvent voluer
indpendamment, ce qui amne lobjet de ltat composite (Z,A) vers ltat
composite (X,A). Les automates T et U peuvent voluer simultanment, ce qui
est le cas lorsque lvnement E1 emmne lobjet de ltat composite (X,A) vers
ltat composite (Y,B).
Lajout de conditions sur les transitions, comme la garde [in Z] place sur la
transition de B vers A, permet dintroduire des relations de dpendance entre
composants de lagrgat. Lorsque lvnement E4 a lieu, la transition de B vers A
est valide uniquement si lobjet est ce moment-l galement dans ltat Z.
L'agrgation dtats, tout comme la gnralisation dtats, permet de simplifier la
reprsentation des automates. La gnralisation simplifie par factorisation,
lagrgation simplifie par segmentation de lespace des tats. Sans agrgation
dtats, lautomate quivalent serait de la forme suivante :
E1
Z, B
Z, A
E4
E3
E3
E1
X, A
E1
X, B
Y, B
Figure 275 : Automate plat quivalent lautomate agrgation prcdent.
Le nombre dtats dun tel automate plat est au maximum gal au produit du
nombre dtats de chaque automate composant. Dans le cas dune agrgation de
trois automates dune centaine dtats chacun (ce qui est dj beaucoup),
lautomate plat quivalent pourrait contenir jusqu un million dtats !
Lhistorique
Par dfaut, un automate na pas de mmoire. La notation spciale H offre un
mcanisme pour mmoriser le dernier sous-tat visit et pour le rejoindre lors
dune transition entrant dans le super-tat qui lenglobe. Le concept dhistorique
sapplique au niveau dans lequel le symbole H est dclar. Le symbole H peut tre
plac nimporte o dans ltat ; le coin bas gauche est la position par dfaut.
Le diagramme suivant reprsente un tat C qui mmorise le dernier sous-tat actif.
Lhistorique est initialis lors du dclenchement de la transition issue de ltat
initial.
C
D2
In
A
Out
D1
Figure 276 : Exemple dautomate hirarchique. Ltat C mmorise le dernier sous-tat actif.
La mmorisation, quelle que soit la profondeur des sous-tats embots, est

galement possible ; elle est indique par le symbole H*. Les niveaux de
mmorisation intermdiaires sont obtenus en plaant un symbole H par niveau
hirarchique. Dans lexemple suivant, ltat A mmorise le dernier sous-tat actif,
quelle que soit la profondeur dembotement des sous-tats.
A
H*
C
C1
C2
Figure 277 : Le mcanisme dhistorique H* permet de mmoriser le dernier sous-tat actif,

quelle que soit la profondeur dembotement.
Lexemple suivant montre lutilisation de lhistorique pour la ralisation dun lavevaisselle. Le cycle de lavage est dcoup en trois grandes tapes : le rinage, le
lavage et le schage. A tout moment, la porte peut tre ouverte, pour rajouter par
exemple une tasse ; ds que la porte est referme, le cycle de lavage reprend au
point o il a t interrompu.
Rinage
Lavage
Schage
Porte ouverte
Porte ferme
Attente
Figure 278 : Un tat englobant peut mmoriser le dernier sous-tat actif. Le contrle est
transmis directement au sous-tat mmoris lorsquune transition qui arrive sur ltat spcial
H est dclenche.
La communication entre objets

Les objets communiquent en changeant des messages. A la rception dun
message, lobjet destinataire dclenche une opration pour traiter le message. Le
message est un concept trs gnral qui peut tout aussi bien reprsenter lappel
de procdure, linterruption venant du matriel ou encore la liaison dynamique.
Le message est la manire de visualiser les changes dans les diagrammes

dinteraction entre objets, cest--dire dans les diagrammes de squence et de
collaboration. Ces diagrammes dinteraction montrent des cas particuliers de
comportement au sein dun cas dutilisation.
Les automates reprsentent des abstractions du comportement du point de vue
dun groupe dobjets (le plus souvent une classe). Le comportement dcrit par les
scnarios est une consquence particulire de ltat de tous les objets qui
collaborent au sein de ces scnarios.
Les envois de messages entre deux objets sont visualiss de manire abstraite
dans le formalisme des diagrammes dtats-transitions par lenvoi dun
vnement entre les automates dtats-finis des classes dobjets concernes. La
visualisation dans les diagrammes dtats-transitions est plus abstraite car, un
vnement envoy entre deux automates, correspond de nombreux envoi de
messages entre objets.
La syntaxe dun envoi dvnement vers une classe est :
^Cible.Evnement (Arguments)
o la cible dsigne la classe des objets destinataires de lvnement.
La syntaxe complte dune transition est :
Evnement (Arguments)[Condition]
/Action
^Cible.Evnement (Arguments)
Lexemple suivant montre des fragments dautomates dun tlviseur et de sa
tlcommande. Le tlviseur peut tre allum ou teint par manipulation dun
interrupteur basculant. La tlcommande possde un bouton-poussoir (touche
on/off) qui, lorsquil est enfonc, allume ou teint le tlviseur. Le tlviseur peut
tre command directement ou par la tlcommande.
Tlviseur
Bascul
Attente
Arrt
Bascul
Tlcommande
Bouton enfonc ^Tlviseur.Bascul
Attente
Figure 279 : Le mcanisme denvoi dvnement entre automates reprsente de manire

abstraite les changes de messages entre les objets instances des classes associes ces
automates.
Par gnralisation, lenvoi dvnement est possible vers nimporte quel

ensemble dobjets (une classe est un cas particulier densemble dobjets). Les
formes les plus courantes sont lenvoi tous les objets (la diffusion) et lenvoi
un objet particulier (le point point). Dans le cas dun automate qui dcrit une
classe composite, les actions peuvent faire rfrence directement aux oprations
dclares dans les diffrentes classes contenues par la classe composite.
Cration et destruction des objets

La cration dun objet se reprsente par lenvoi dun vnement de cration la
classe de lobjet. Les paramtres de cet vnement permettent dinitialiser le
nouvel objet, qui dbute son existence partir de ltat initial dcrit dans
lautomate de la classe. Lexemple suivant montre une transition de cration qui
immatricule un avion. En cas de crash, lavion cesse dexister.
En vol
Crash
Atterrir
Dcoller
Au sol
Crer( immatriculation )
Figure 280 : La transition de cration emmne lobjet depuis ltat initial vers son premier
tat de fonctionnement. Larrive dans ltat final implique la disparition de lobjet.
La destruction dun objet est effective lorsque le flot de contrle de lautomate

atteint un tat final non embot. Larrive dans un tat final embot implique la
remonte ltat englobant, et non la fin de lobjet.
Les transitions temporises

Les attentes sont par dfinition des activits qui durent un certain temps. Une
attente est donc naturellement rattache un tat plutt qu une transition ; elle
se reprsente au moyen dune activit dattente. Lactivit dattente est
interrompue lorsque lvnement attendu a lieu. Cet vnement dclenche en effet
une transition permettant de sortir de ltat qui hberge lactivit dattente. Le flot
de contrle est alors transmis un autre tat.
Lexemple suivant illustre une squence dattente dans un guichet automatique
de banque. La trappe qui accueille les dpts est ouverte ; le systme informe
lutilisateur quil dispose de trois minutes pour effectuer son dpt. Si le dpt
est effectu dans les trois minutes, lactivit dattente est interrompue par le
dclenchement de la transition vers ltat B. En revanche, si le dpt nintervient
pas dans le dlai imparti, la transition automatique vers ltat dannulation est
dclenche la fin de lactivit dattente. Dans tous les cas, laction de sortie de
ltat dattente referme la trappe.
A
/ Ouvrir trappe
Attente argent
do: Attendre 3 minutes
entry: Afficher message
exit: Fermer la trappe
Annulation transaction
Dpot effectu
B
Figure 281 : Reprsentation dune temporisation par combinaison dune activit dattente et
dune transition automatique.
Les temporisations peuvent se reprsenter au moyen d'une notation plus

compacte, directement attache la transition dclenche aprs le dlai dattente.
Lvnement dclencheur porte le nom gnrique de temporisation et le
paramtre spcifie la dure de la temporisation.
La syntaxe dun vnement de temporisation est :
Temporisation(dure_de_temporisation)
Le diagramme prcdent se transforme de la manire suivante :

A
/ Ouvrir trappe
Attente argent
entry: Afficher message
exit: Fermer la trappe
Tempo( 3 minutes )
Annulation transaction
Dpot effectu
B
Figure 282 : Reprsentation d'une temporisation par une transition temporise.
Les automates offrent un formalisme bien adapt pour la reprsentation des

comportements complexes. En analyse, les diagrammes dtats-transitions
capturent le comportement souhait ; durant la ralisation, les automates peuvent
scrire facilement, par exemple au moyen de tables contenant les tats et les
actions excuter lors des transitions.
Un automate reprsente un comportement qui rsulte doprations excutes
suite une squence de changements dtat. Un automate peut tre visualis
selon le point de vue des tats (par les diagrammes dtats-transitions) ou selon
le point de vue des actions (par les diagrammes dactivits). Un automate spcifie
le comportement dune collaboration.
Lexcution dune instance dautomate ne peut pas tre interrompue. A tout
moment, un automate peut ragir un vnement particulier qui lentrane dun
tat stable vers un autre tat stable. Lexcution de lautomate dbute partir du
pseudo-tat initial et se poursuit, au rythme des vnements, jusqu' ce quun
pseudo-tat final, non embot, soit atteint.
Automate
1
*
1
1..*
Source
Sommet
Pseudo tat
Transition
Cible
1..*
Etat
{initial, final, histoire}
0..1
Figure 283 : Extrait du mtamodle. Un automate est un graphe compos dtats et de

transitions.
Les vnements dclenchent des transitions. Le dclenchement dune transition

entrane lautomate de ltat source de la transition vers ltat de destination. Au
passage, une ou plusieurs actions peuvent tre dclenches sur un ou plusieurs
objets.
UML dfinit trois sortes dvnements :
lvnement signal caus par un signal,
lvnement appel caus par une opration,
lvnement temporel caus par lexpiration dune temporisation.
Le diagramme suivant reprsente les transitions, leurs actions et les diffrents

vnements qui les dclenchent.
Transition
Effet
Action
0..1
1
Dclencheur
0..1
Evnement
SignalEvt
*
0..1
Signal
Appel
*
0..1
Opration
Temporel
*
0..1
Expression
Figure 284 : Extrait du mtamodle. Reprsentation des diffrentes sortes dvnements.
Les diagrammes dactivits

Un diagramme d'activits est une variante des diagrammes d'tats-transitions,
organis par rapport aux actions et principalement destin reprsenter le
comportement interne d'une mthode (la ralisation d'une opration) ou d'un cas
dutilisation.
Reprsentation des activits

Un diagramme d'activits reprsente l'tat de l'excution d'un mcanisme, sous la
forme d'un droulement d'tapes regroupes squentiellement dans des branches
parallles de flot de contrle.
Un diagramme d'tats-transitions peut galement reprsenter ce droulement
d'tapes. Toutefois, tant donn la nature procdurale de la ralisation des
oprations dans laquelle la plupart des vnements correspondent simplement
la fin de l'activit prcdente il n'est pas ncessaire de distinguer
systmatiquement les tats, les activits et les vnements. Il est alors intressant
de disposer d'une reprsentation simplifie pour la visualisation directe des
activits. Dans ce contexte, une activit apparat comme un strotype d'tat. Une
activit est reprsente par un rectangle arrondi, comme les tats, mais plus tir
horizontalement.
La figure suivante affiche les reprsentations graphiques des activits et des
tats, et met en vidence la simplification apporte par la reprsentation directe
des activits.
E1
do: Activit
Activit finie
E2
Figure 285 : Exemple de simplification graphique par reprsentation directe des activits.
Chaque activit reprsente une tape particulire dans l'excution de la mthode

englobante. Les activits sont relies par des transitions automatiques,
reprsentes par des flches, comme les transitions dans les diagrammes d'tatstransitions. Lorsqu'une activit se termine, la transition est dclenche et l'activit
suivante dmarre. Les activits ne possdent ni transitions internes, ni transitions
dclenches par des vnements.
La figure suivante reprsente deux activits relies par une transition

automatique. Il n'est pas ncessaire de faire figurer un nom d'vnement sur la
transition.
Figure 286 : Reprsentation dune transition automatique.
Les transitions entre activits peuvent tre gardes par des conditions
boolennes, mutuellement exclusives. Les gardes se reprsentent proximit des
transitions dont elles valident le dclenchement.
Figure 287 : Exemple de reprsentation des conditions.
UML dfinit un strotype optionnel pour la visualisation des conditions. Une

condition est matrialise par un losange do sortent plusieurs transitions. Le
diagramme suivant est quivalent au diagramme prcdent, si ce n'est que la
condition est matrialise explicitement.
Figure 288 : Exemple d'activit strotype pour reprsenter une dcision.
Les diagrammes d'activits reprsentent les synchronisations entre flots de

contrles, au moyen de barres de synchronisation. Une barre de synchronisation
permet d'ouvrir et de fermer des branches parallles au sein d'un flot d'excution
d'une mthode ou d'un cas d'utilisation. Les transitions au dpart d'une barre de
synchronisation sont dclenches simultanment.
L'exemple suivant montre que pour refroidir, il faut simultanment arrter le
chauffage et ouvrir les fentres.
Figure 289 : Exemple de synchronisation de flots de contrle parallles partir d'une barre
de synchronisation.
Inversement, une barre de synchronisation ne peut tre franchie que lorsque

toutes les transitions en entre sur la barre ont t dclenches. La figure
suivante reprend l'exemple prcdent et montre que la mesure de temprature est
effectue une fois que le chauffage est arrt et la pice are.
Figure 290 : Exemple de fusion de flots de contrle parallles regroups sur une barre de
synchronisation.
Les diagrammes d'activits peuvent tre dcoups en couloirs d'activits (comme

une piscine est dcoupe en couloirs de natation) pour montrer les diffrentes
responsabilits au sein d'un mcanisme ou d'une organisation. Chaque
responsabilit est assure par un ou plusieurs objets et chaque activit est
alloue un couloir donn. La position relative des couloirs n'est pas
significative ; les transitions peuvent traverser librement les couloirs.
Figure 291 : Exemple de partition d'un diagramme d'activits en couloirs d'activits.
Il est possible de faire apparatre clairement les objets dans un diagramme

d'activits, soit au sein des couloirs d'activits, soit indpendamment de ces
couloirs. Les objets sont alors reprsents par des barres verticales, comme dans
les diagrammes de squence ; les activits apparaissent objet par objet sur la
ligne de vie de ces objets.
Souvent, diffrentes activits manipulent un mme objet qui change alors d'tat
selon le degr d'avancement du mcanisme. Pour augmenter la lisibilit, cet objet
peut figurer plusieurs reprises dans les diagrammes ; son tat est alors spcifi
chaque occurrence dans une expression entre crochets.
Les flots d'objets sont reprsents par des flches pointilles. Une flche relie
ainsi un objet l'activit qui la cr. De mme, une flche relie un objet aux
activits qui le mettent en jeu. Lorsqu'un objet produit par une activit est utilis
immdiatement par une autre activit, le flot d'objets reprsente galement le flot
de contrle ; il est alors inutile de reprsenter explicitement ce flot de contrle.
Le diagramme suivant illustre les diffrents cas de figure voqus dans ce
paragraphe. En particulier, l'exemple fait apparatre un objet Commande manipul
par diffrentes activits.
Figure 292 : Visualisation directe des objets responsables des diffrentes activits.
Les diagrammes d'activits peuvent galement contenir des tats et des

vnements reprsents de la mme manire que dans les diagrammes d'tatstransitions. Le diagramme suivant donne un exemple d'emploi simultan des deux
notations.
Figure 293 : Exemple de reprsentation mixte, incluant des tats et des activits.
UML dfinit galement des strotypes pour la reprsentation explicite des

informations de transitions. L'envoi d'un signal se symbolise par un pentagone
convexe reli par une flche pointille l'objet destinataire du signal. L'attente
d'un signal se symbolise par un pentagone concave reli par une flche pointille
l'objet metteur du signal.
Figure 294 : Exemple de strotypes qui prsentent graphiquement l'envoi et la rception de

signaux.
Les diagrammes de composants

Les diagrammes de composants dcrivent les lments physiques et leurs
relations dans lenvironnement de ralisation. Les diagrammes de composants
montrent les choix de ralisation.
Les modules
Les modules reprsentent toutes les sortes dlments physiques qui entrent
dans la fabrication des applications informatiques. Les modules peuvent tre de
simples fichiers, des paquetages du langage Ada, ou encore des bibliothques
charges dynamiquement.
Par dfaut, chaque classe du modle logique est ralise par deux composants : la
spcification et le corps. La spcification contient linterface de la classe alors que
le corps contient la ralisation de cette mme classe. La spcification peut tre
gnrique dans le cas des classes paramtrables.
Spcification
Corps
Gnrique
Figure 295 : Reprsentations graphiques des diffrentes sortes de modules.
La spcification et le corps dune mme classe peuvent tre superposs dans les
diagrammes afin de rendre la notation plus compacte. Chaque corps dpend alors
implicitement de sa spcification.
Figure 296 : Reprsentations compactes des spcifications et des corps.
En C++, une spcification correspond un fichier avec un suffixe .h et un corps

un fichier avec un suffixe .cpp. En Ada, la notion de module existe directement
dans le langage sous lappellation de paquetage.
Les dpendances entre composants

Les relations de dpendance sont utilises dans les diagrammes de composants
pour indiquer quun composant fait rfrence aux services offerts par un autre
composant. Ce type de dpendance est le reflet des choix de ralisation. Une
relation de dpendance est reprsente par une flche pointille qui pointe de
lutilisateur vers le fournisseur.
Figure 297 : La relation de dpendance permet de relier les diffrents composants.
La relation de dpendance peut tre spcialise par un strotype afin de prciser

la nature des choix de ralisation qui entranent la relation de dpendance.
Lexemple suivant montre la construction dun composant X partir dune liste
gnrique. La procdure Itrer est un ami de X, ami tant pris au sens C++ de
friend.
X
Liste
<<Instanciation>>
Itrer
<<Ami>>
Figure 298 : Emploi de strotypes pour prciser la nature des choix de ralisation.
Dans un diagramme de composants, les relations de dpendance reprsentent

gnralement les dpendances de compilation. Lordre de compilation est donn
par le graphe des relations de dpendance.
A'spec
A'body
B'spec
B'body
Figure 299 : Reprsentation des dpendances de compilation dans un diagramme de

composants.
Les processus et les tches

Les tches correspondent des composants qui possdent leur propre flot
(thread en anglais) de contrle. Les tches peuvent tre contenues par dautres
composants comme les units de compilation du langage Ada. Comme pour tous
les lments de modlisation, lajout de strotypes permet de prciser la
smantique dun composant dynamique. Les strotypes <<Processus>> et
<<Flot>> sont prdfinis par UML. Plusieurs flots peuvent partager le mme
espace dadressage au sein dun processus.
Figure 300 : Reprsentations graphiques des spcifications et corps de tches.
Les programmes principaux

Les points dentre dans les applications sont identifis par licne suivante :
Figure 301 : Reprsentation graphique des programmes principaux.
En C++, le programme principal correspond une fonction libre appele main,

stocke dans un fichier avec un suffixe .cpp. En Ada, toute procdure de
bibliothque peut tre dsigne comme programme principal.
Le nom du programme principal est souvent utilis par lditeur de lien pour
nommer le programme excutable correspondant lapplication. Ceci permet, entre
autres, de relier le modle des composants avec le modle des processus.
Les sous-programmes
Les sous-programmes regroupent les procdures et les fonctions qui
nappartiennent pas des classes. Ces composants peuvent contenir des
dclarations de types de base ncessaires pour la compilation des sousprogrammes. En revanche, ils ne contiennent jamais de classes.
Il existe deux reprsentations graphiques : une pour la spcification des sousprogrammes et une pour leur ralisation.
Figure 302 : Reprsentations graphiques des spcifications et ralisations des sousprogrammes.
En Ada, il est possible de dfinir le corps dun sous-programme seul : la

spcification est alors implicite et ne figure donc pas dans le diagramme.
Les sous-systmes
Pour faciliter la ralisation des applications, les diffrents composants peuvent
tre regroups dans des paquetages selon un critre logique. Ils sont souvent
strotyps en sous-systmes pour ajouter les notions de bibliothques de
compilation et de gestion de configuration la smantique de partition dj
vhicule par les paquetages. Les sous-systmes jouent pour les composants le
mme rle que les catgories pour les classes.
<<Sous-systme>>
Figure 303 : Reprsentation graphique des sous-systmes partir dun paquetage et dun
strotype.
Les sous-systmes organisent la vue de ralisation dun systme ; chaque soussystme peut contenir des composants et dautres sous-systmes. Par
convention, tout composant du modle est plac soit au niveau racine, soit dans
un sous-systme. Les sous-systmes doivent tre vus comme de grandes briques
pour la construction des systmes.
Figure 304 : Les sous-systmes peuvent tre embots les uns dans les autres.
La dcomposition en sous-systmes nest pas une dcomposition fonctionnelle.

Les fonctions du systme sont exprimes du point de vue de lutilisateur dans la
vue des cas dutilisation. Les cas dutilisation se traduisent en interactions entre
objets dont les classes sont elles-mmes encapsules par des catgories. Les
objets qui ralisent les interactions sont distribus dans les diffrentes
catgories ; le code correspondant est stock dans des modules et des soussystmes.
Interaction
Cas d'utilisation
<<ralisation>>
*
*
Catgorie
Objet
Classe
1
Figure 305 : Les objets interagissent pour raliser les comportements dcrits
fonctionnellement dans les cas dutilisation.
Le sous-systme est, dans la vue physique, lquivalent de la catgorie dans la

vue logique. La figure suivante montre la correspondance entre les deux vues.
Vue logique
Vue physique
Catgorie
Sous-systme
1
1..*
Classe
Module
*
Figure 306 : Extrait du mtamodle montrant la correspondance entre la vue logique et la

vue physique.
Un sous-systme est un moyen de grer la complexit par lencapsulation des

dtails. Les sous-systmes possdent une partie publique et une partie prive.
Sauf indication contraire explicite, tout module plac dans un sous-systme est
visible de lextrieur.
Les sous-systmes peuvent dpendre dautres sous-systmes et de composants.
De mme, un composant peut dpendre dun sous-systme.
Proc'spec
A
Main
Figure 307 : Relations de dpendance entre diffrents types de composants et sous-systmes.
Intgration avec les environnements de dveloppement

Les sous-systmes nexistent pas en tant que tels dans tous les environnements
de dveloppement de logiciel. Il appartient alors lutilisateur de mettre en place
une structure base de rpertoires et de fichiers pour les raliser physiquement.
Sous-systme
Interfaces
Sources
Tests
Docs
Figure 308 : Ralisation dun sous-systme partir dune structure de rpertoires et de

fichiers.
Dans cette optique, il est particulirement judicieux de se servir de la notion de

sous-systme comme dun point dintgration avec les outils danalyse et de
conception de logiciels, les systmes de compilation et les systmes de gestion
de versions et de configurations.
Chaque sous-systme est matrialis par un rpertoire qui contient des fichiers ;
ces fichiers correspondent aux diffrents composants contenus par le soussystme. Le sous-systme contient en plus les diffrents fichiers ncessaires la
compilation, la documentation et au test des composants. Lintgration avec les
systmes de compilation permet dassocier la notion de bibliothque de

programmes la notion de sous-systme. Lintgration avec un gestionnaire de
configurations conduit la construction de systmes par combinaison de
bibliothques de compilation. Lintgration peut encore tre enrichie par un
gestionnaire de versions, idalement deux niveaux de granularit. Il devient
alors possible de construire un systme par combinaison de versions de soussystmes (exprimes sous la forme de bibliothques de programmes), elles-mmes
composes de versions de composants.
Les diagrammes de dploiement

Les diagrammes de dploiement montrent la disposition physique des diffrents
matriels (les nuds) qui entrent dans la composition dun systme et la
rpartition des programmes excutables sur ces matriels.
Reprsentation des nuds

Chaque ressource matrielle est reprsente par un cube voquant la prsence
physique de lquipement dans le systme. Tout systme est dcrit par un petit
nombre de diagrammes de dploiement ; souvent un seul diagramme suffit.
Noeud
Figure 309 : Reprsentation graphique des nuds.
La nature de lquipement peut tre prcise au moyen dun strotype.

Lexemple suivant propose trois strotypes pour distinguer les dispositifs, les
processeurs et les mmoires. Au besoin, lutilisateur a la possibilit de dfinir
dautres strotypes.
Modem
<<Dispositif>>
PC
<<Processeur>>
Disque
<<Mmoire>>
Figure 310 : Exemples de strotypes de nud.
La distinction entre un dispositif et un processeur dpend fortement du point de

vue. Un terminal X sera vu comme un dispositif par lutilisateur du terminal alors
quil correspondra un processeur pour le dveloppeur du serveur X qui

sexcute sur le processeur embarqu dans le terminal X.
Les diffrents nuds qui apparaissent dans le diagramme de dploiement sont
connects entre eux par des lignes qui symbolisent un support de communication
a priori bidirectionnel. La nature de ce support peut tre prcise au moyen dun
strotype.
68K
PC
Connection
Figure 311 : Reprsentation graphique des connexions entre nuds.
Les diagrammes de dploiement peuvent montrer des classes de nuds ou des

instances de nuds. Comme dans les autres types de diagrammes, la distinction
graphique entre les classes et les objets est ralise en soulignant le nom de
lobjet. Lexemple suivant montre le diagramme de dploiement dun systme de
gestion des accs dun btiment.
TX
Console
<<TCP/IP>>
Serveur X
3
Serveur
1
SGBD
1
*
PC
<<RNIS>>
Pilote
1
Imprimante
<<Dispositif>>
Matre
Porte
1..10
Figure 312 : Exemple de classes dans un diagramme de dploiement.
La prsence dinformations de multiplicit et de rle confirme que le diagramme

prcdent reprsente des classes de nuds. Le diagramme montre que le systme
est constitu dun serveur autour duquel gravitent des PC pilotant louverture et
la fermeture de portes. Le nombre de PC nest pas prcis. En revanche, il apparat
que chaque PC peut tre le matre de 10 portes au plus. Trois terminaux X jouent
le rle de console pour accder au systme ; une imprimante est relie au serveur.
Le diagramme dcrit galement la nature des liens de communication entre les
diffrents nuds. Le serveur et les PC sont relis par une liaison RNIS ; les
terminaux X et le serveur communiquent via TCP/IP. La nature de la connexion
des autres nuds na pas t prcise.
Les nuds qui correspondent des processeurs du point de vue de lapplication
le strotype de processeurs napparat pas obligatoirement dans les
diagrammes de dploiement portent galement le nom des processus quils
hbergent. Le serveur excute un systme de gestion de bases de donnes ; les
PC hbergent le logiciel de pilotage ddi la commande et au contrle des
portes. Le nom de ces processus permet de faire le lien entre le diagramme de
dploiement et le diagramme des composants. Chaque processus nomm dans le
diagramme de dploiement excute un programme principal du mme nom, dcrit
dans le diagramme des composants.
Noeud
1
*
Processus
Programme principal
Nom
Nom
Figure 313 : Le nom des processus et des programmes principaux permet de faire le lien
entre les diagrammes de dploiement et de composants.
Les diagrammes de dploiement peuvent galement montrer des instances de

nuds (reconnaissables au nom soulign). Le diagramme suivant nous renseigne
ainsi sur la situation prcise au niveau du site dimplantation du systme. Il
apparat que les portes 6, 7, 8 et 9 sont pilotes par le PC 4.
PC4
Porte 9
Porte 6
Porte 7
Porte 8
Figure 314 : Exemple dobjets dans un diagramme de dploiement. Les noms des objets sont
souligns afin de distinguer les objets des classes.
4
Encadrement
des projets objet
La prsence dun processus de dveloppement formalis, bien dfini et bien gr,
est un facteur de russite dun projet. Un processus est stable si ses
performances futures peuvent tre prdites statistiquement18.
UML tant avant tout un langage de modlisation elle ne dfinit pas un
processus de dveloppement particulier. Nanmoins, elle peut servir de notation
pour diffrentes approches mthodologiques bases sur les objets.
Lobjectif de ce chapitre est de prsenter les grandes lignes de lencadrement des
projets objet au travers dun cadre mthodologique gnrique proche de celui
dcrit par Objectory 4.019.
Il appartiendra chaque projet ou organisation de raffiner ce cadre en fonction de
ses besoins.
18
Deming W. E. 1982, Quality, Productivity, and Competitive Position.

Massachusetts Institute of Technology Center for Advanced Engineering Study,
Cambridge, MA.
19
Rational Software Corporation 1996, Rational Objectory Process

Introduction.
Caractrisation du logiciel
Ce chapitre a pour objet de caractriser le logiciel, de mettre en vidence lorigine
des difficults lies son dveloppement et desquisser les mesures prendre
pour les matriser.
La crise du logiciel
La formule est ne il y a trente ans20 pour dcrire la limite des technologies
disponibles et lincapacit matriser le logiciel qui en rsulte. Bien sr, au cours
de ces trente dernires annes, de nombreux progrs ont t raliss, mais le
logiciel est toujours en crise. Il est probable, comme le suggre Grady Booch, qu'il
ne s'agit pas dune crise mais plutt dun tat permanent.
Les mthodes objet ont pris le relais des techniques structures traditionnelles ;
les logiciels objet sont plus extensibles, plus proches des utilisateurs, plus faciles
maintenir, mais ils restent toujours difficiles raliser.
Il faut bien le dire, une des raisons de la crise du logiciel est la fuite en avant vers
la complexit des applications. La complexit intrinsque de chaque nouvelle
gnration de systme est plus grande de sorte que les solutions techniques qui
taient adaptes pour la gnration prcdente arrivent leurs limites pour la
gnration suivante. La crise du logiciel ne connat pas de fin.
Il existe plusieurs types de logiciels qui peuvent chacun se caractriser par les
contraintes quils placent sur le processus de dveloppement.
Les catgories de logiciels

Les logiciels amateurs constituent la premire catgorie. Le terme amateur ne doit
pas tre pris dans un sens pjoratif : il dsigne tout logiciel qui na pas dimpact
conomique significatif. Ce type de logiciel est gnralement dvelopp par des
individus au sein de groupes qui partagent des centres dintrt communs,
comme par exemple les radioamateurs ou les astronomes amateurs. Les logiciels
dvelopps par les tudiants tombent galement dans cette catgorie.
La deuxime catgorie regroupe les logiciels jetables, dits aussi logiciels
consommables, comme les traitements de texte ou les tableurs. Ce type de logiciel
ne cote pas trs cher lachat (quelques milliers de francs tout au plus) et son
remplacement par un logiciel quivalent ne risque pas de mettre en pril lquilibre
financier de lentreprise qui en a fait lacquisition. Le point de vue du fabricant de
20
Buxton J. N. & Randell B. (eds) 27-31 Octobre 1969, Software Engineering

Techniques. Report on a Conference Sponsored by the NATO Science
Committee, Rome, Italy.
4 Encadrement des projets objet 201
ce type de logiciel est quelque peu diffrent, et cela dautant plus que la diffusion
de ce type de logiciel est large. Une fois le logiciel en exploitation chez des milliers
de clients, ventuellement du monde entier, il nest gure ais de proposer des
corrections de dfauts, dautant que les revenus drivs des contrats de
maintenance sont faibles. Il faut donc maintenir un quilibre difficile entre qualit
du produit, cot de dveloppement et diffusion. Lobjectif de qualit moindre
cot est difficile tenir, mais impratif pour les produits marge faible et grande
distribution. Internet et le principe du shareware simplifient normment la
diffusion de ce type de logiciel, mais ne rsorbent pas limpratif de qualit.
La troisime catgorie comprend les logiciels essentiels au fonctionnement dune
entreprise et qui ne peuvent tre changs facilement : ils ont t construits pour
une tche donne et sont le fruit dun investissement non ngligeable. Ce type de
logiciel exige un comportement fiable, sr et prvisible : leur dfaillance peut
entraner la chute de lentreprise qui les utilise. Ils sont prsents la fois dans les
secteurs industriels et tertiaires, par exemple pour piloter un autocommutateur ou
pour grer une salle des marchs. La grande complexit de ces logiciels plus
prcisment de ces systmes logiciels provient dune part de la complexit
intrinsque lie au domaine des applications et dautre part de la complexit des
environnements dexcution, souvent htrognes et distribus. Leur
maintenance volutive devient de plus en plus difficile car chaque modification
rend le logiciel plus confus. Les informaticiens subissent alors le poids du pass,
souvent jusqu un point de rupture quil est essentiel danticiper. La triste ralit
est que lentropie des logiciels est limage de lentropie de lunivers : elle ne
cesse de crotre. De ce point de vue, un processus de dveloppement doit limiter
le dsordre logiciel.
La dernire catgorie de logiciels englobe les systmes vitaux, cest--dire ceux
dont dpend la vie dtres humains. Ces systmes se rencontrent dans les
domaines du transport de larmement et de la mdecine. Les contraintes
dexploitation de ces logiciels nont absolument rien voir avec les catgories
prcdentes. Un dysfonctionnement ne se chiffre plus en argent, mais en vies
humaines.
La complexit des logiciels

Les informaticiens, de manire gnrale, ont un grave dfaut. Ils ne savent pas
faire simple. Dun autre ct, faire simple est extrmement difficile.
Faire simple, cest par exemple apprendre encapsuler la complexit ; cest aussi
lutter contre le plaisir que procure le maniement des arcanes dun langage de
programmation. Faire simple, cest galement apprendre faire semblant que cest
simple, cest crer lillusion de la simplicit.
Linformaticien doit apprendre imiter la nature qui, dans ses constructions les
plus lmentaires comme les plus complexes, cherche toujours lquilibre stable,
la consommation dnergie minimale, loin du caprice ou du superflu.
Trop souvent, llaboration des logiciels reste une activit parcellaire et
disperse. Si linformaticien construisait des meubles, il commencerait par planter
des glands, dbiterait les arbres en planches, creuserait le sol la recherche de
minerai de fer, fabriquerait une forge pour faire ses clous et finirait par assembler
le tout pour obtenir un meuble. Ce mode de fabrication engendre une large
dispersion des efforts et requiert la matrise dune trop grande palette de
comptences. Durant les sicles passs, nos anctres ont appris spcialiser les
activits humaines et cest ainsi que certains spcialistes savent comment faire
pousser les arbres alors que dautres connaissent les secrets de fabrication des
clous. Lavantage immdiat de cette approche est que les autres personnes
peuvent se concentrer sur leur propre domaine de connaissance, par exemple la
fabrication des meubles. Un mode de dveloppement qui repose sur les paules
de quelques programmeurs hroques, de gourous et autres magiciens du logiciel,
ne constitue pas une pratique industrielle prenne et reproductible.
La formalisation du processus de dveloppement procde de cette constatation.
Les activits mises en uvre lors de llaboration du logiciel doivent tre dcrites,
expliques, motives : la connaissance et le savoir-faire informatique peuvent
alors se propager autrement que de bouche de druide oreille de druide21. Un
processus dcrit lenchanement des activits de lquipe de dveloppement ; il
dirige les tches de chaque individu ainsi que celles du groupe. Le processus
dfinit des points de mesures et des critres pour contrler et mesurer les
produits et les activits du projet.
Malheureusement, la formalisation du processus de dveloppement ne sapplique
que partiellement au domaine informatique. Contrairement lbnisterie,
linformatique est un domaine de connaissance trs jeune et pauvre en savoirfaire transmissibles. De plus, le niveau de formalisation du savoir-faire
informatique est trs faible. Avant de vouloir propager lexprience, il faut
dabord savoir la dcrire, la reprsenter, la modliser.
Cela revient galement dire que linformatique est un mtier qui sapprend
comme les autres mtiers : il nest pas possible de simproviser informaticien. Une
entreprise qui recherche un spcialiste de linformatique doit donc rechercher un
ingnieur informaticien plutt quun spcialiste de la chimie ou du textile.
Origines de la complexit des logiciels

Il ne suffit pas de jeter la pierre aux informaticiens : de plus en plus, la
problmatique qui leur est soumise est complexe de par la nature mme du
21
Gosciny, Uderzo1961, Astrix le Gaulois, Dargaud.
domaine des applications. Avec la meilleure volont du monde, cette complexit

ne peut tre rduite par linformaticien. En revanche, elle peut tre canalise,
confine dans des espaces clos faiblement coupls. Par une segmentation
judicieuse de lespace des tats, la caractrisation du comportement des systmes
discrets que sont les programmes est facilite.
De la mme manire, la complexit lie lenvironnement informatique, cest--dire
aux mthodes, aux langages, aux systmes dexploitation, etc, peut et doit tre
minimise le plus possible : il faut viter les solutions moins onreuses mais plus
complexes.
En amont de ces problmes de complexit, il faut insister sur linfinie flexibilit du
logiciel qui est la fois son plus grand avantage et son plus grand dfaut. Il est
extrmement facile dcrire une ligne de programme ; il est plus difficile de la
mettre au point. Il est tout aussi facile de modifier une ligne dans un programme ;
il est infiniment plus difficile de garantir que le programme continuera de
fonctionner correctement.
Consquence de la complexit
Du fait de la complexit lie llaboration des logiciels, il y a fort peu de chances
quun logiciel soit exempt de dfauts. Au contraire, le risque de dficience grave
est lev.
Les dfauts logiciels, les bogues, sont comme les couacs en musique22. Les
meilleurs musiciens ne sont pas l'abri dun couac ; ce quils font est difficile et
assurer une qualit constante, sur une longue dure, lest aussi. Linformaticien
est confront au mme problme, quelles que soient ses comptences ; il nest
pas l'abri dun couac. Les logiciels sont crits par des humains, les humains
sont faillibles, les logiciels aussi.
La mise au point des logiciels est lente et chaotique, et le cot de maintenance est
disproportionn. Les techniques de test et de validation permettent de dgager
des chemins dexcution scuriss : suivis la lettre, ils permettent de garantir un
niveau de confiance raisonnable dans le logiciel.
Tous les dfauts nont pas les mmes consquences. Les dfauts danalyse se
traduisent par des logiciels qui ne satisfont pas leurs utilisateurs. Les dfauts de
conception gnrent des logiciels lourds manier, trop lents ou peu efficaces. Les
dfauts de ralisation induisent des comportements non prvus. Tout dfaut est
indsirable ; ceux introduits dans les activits en amont restent cependant les
plus difficiles corriger.
22
Adda J.-L., communication prive.
La crise de logiciel est le fruit de notre incapacit matriser les dfauts du

logiciel. Le rsultat de cette crise est le cot astronomique des applications
complexes.
La porte de lapproche objet

Le dveloppement dune application peut tre divis en plusieurs grandes
parties : elles senchanent de manire squentielle au sein dun cycle de vie en
cascade ou elles se distribuent sur les diffrentes itrations dun cycle de vie
itratif.
De manire gnrale, quelle que soit la manire de procder, linairement ou
itrativement, selon une approche structure ou objet, le dveloppement dune
application rpond quatre questions :
Application = Quoi + Dans quel domaine + Comment + Avec quelles comptences
Ces questions correspondent diffrents points de vue et concernent diffrents

intervenants. Elles peuvent tre tudies selon des techniques varies, mais
doivent dans tous les cas tre considrs pour dvelopper une application :
Quoi faire ? La rponse est exprime par lutilisateur qui dcrit ce quil attend
du systme, comment il entend interagir avec lui et quels sont les diffrents
intervenants. Il sagit dune description fonctionnelle qui ne rentre pas dans
les dtails de la ralisation : le quoi faire est purement descriptif.
Dans quel domaine ? La rponse doit dcrire le domaine (lenvironnement)

dans lequel l'application va exister et prciser quels sont les lments
pertinents dans ce domaine pour lapplication. Ltude du domaine est le fruit
dune analyse, totalement dconnecte de toute considration de ralisation.
Le domaine est analys par un analyste et doit pouvoir tre compris par un
utilisateur.
Comment ? Il faut le dterminer lors de la conception. Le comment est le fruit

de lexprience et du savoir-faire du concepteur. La conception est lart de
rendre possible les dsirs de lutilisateur exprims dans le quoi faire en
considrant le domaine de lapplication et en tenant compte des contraintes
de ralisation.
Avec quelles comptences ? Il faut dterminer tout ce qui est ncessaire la

fabrication de lapplication. Ce point repose sur des comptences techniques
pour le dveloppement des classes, des objets et des mcanismes, sur des
comptences danimation pour lencadrement des quipes et sur des
comptences dorganisation pour assurer la logistique gnrale.
Lapproche objet rpond ces questions, selon trois regards diffrents : lanalyse
objet, la conception objet et la programmation objet.
Figure 315 : Lapproche objet porte trois regards diffrents sur les systmes.
Lanalyse objet
Lanalyse remonte de la consquence vers le principe : elle essaie de comprendre,
dexpliquer et de reprsenter la nature profonde du systme quelle observe.
Lanalyse ne se proccupe pas de solutions mais de questions ; elle identifie le
quoi faire et lenvironnement dun systme, sans dcrire le comment qui est le
propre de la conception.
Lanalyse commence par la dtermination du quoi faire, cest--dire des besoins
de lutilisateur. Bien souvent, lutilisateur nest pas capable dexprimer clairement
ses attentes, de sorte que le cahier des charges nest quune reprsentation
approximative de ses besoins rels. La prsence dun imposant cahier des
charges nest pas toujours de bon augure. Sa qualit dpend trs fortement de
la technique employe pour son laboration. Trop souvent, les cahiers des
charges sont touffus, confus, contiennent des points contradictoires et ne
refltent pas les vrais besoins des utilisateurs. Lexprience montre que la
technique des cas dutilisation (use cases) se prte bien la dtermination des
besoins de lutilisateur.
Lanalyse se poursuit par la modlisation du domaine de lapplication, cest--dire
par lidentification des objets et des classes qui appartiennent fondamentalement
lenvironnement de lapplication, et par la reprsentation des interactions entre
ces objets. Lanalyse rend compte de la structure statique au moyen des relations
entre les classes et des interactions entre les objets au moyen des messages. Il
nexiste pas dordre prfrentiel dans llaboration des diffrents types de
diagrammes : ils sont souvent construits simultanment. Parmi les nombreux
diagrammes dfinis par UML, ceux qui montrent des lments de la vue logique
peuvent tre utiliss en analyse, en particulier :
les cas dutilisation,
les spcifications de classes et d'objets,
les diagrammes de collaboration,
les diagrammes de squence,
les diagrammes de classes,
les diagrammes dtats-transitions.
Cette liste nest pas limitative et chaque projet est libre dutiliser dautres
techniques pour parfaire lanalyse de son problme. En particulier, les approches
cognitives et systmiques apportent souvent un clairage intressant et
complmentaire de la modlisation objet.
Lassise sur les lments du monde rel facilite le dpart de la dmarche car elle
concentre la pense sur des lments concrets. Elle doit imprativement tre
poursuivie par une dmarche dabstraction qui vise faire oublier les
contingences du monde rel et dterminer les concepts fondateurs qui sont
leurs origines. Si la rflexion se focalise trop sur lexistant, les risques de
reproduire une solution au lieu didentifier le problme pos sont grands (voir
plus loin le paragraphe sur la place de linformatique ou le choc des cultures).
Lanalyse est lantithse de la conformit. Lanalyse est souvent surprenante car
elle demande de changer de point de vue, doublier ce qui est connu, ce qui
simpose de prime abord, afin de trouver lessentiel, la nature cache des choses.
Le propre de lanalyse est de trouver une description laquelle personne navait
pens jusqualors, mais qui une fois dtermine simpose au point dtre
vidente.
Pour prendre une image, analyser cest regarder un point, un cercle, une ellipse,
une droite, deux droites scantes, une hyperbole et une parabole et reconnatre
que toutes ces formes peuvent tre obtenues par lintersection dun plan et dun
cne. Dans ce cas, le principe gnrateur peut tre exprim par une quation de la
forme ax2 + by2 + 2cx + 2dy + e = 0. Cette reprsentation est
conome car elle dcrit lessentiel. Lanalyse va lessentiel et recherche un
modle gnrique plus abstrait.
La consquence immdiate dune analyse bien mene est toujours une grande
conomie dans la ralisation qui sensuit, en vertu de la dichotomie (essence,
manifestation) sous-tendu par lapproche objet. Lidentification du principe
gnrateur permet de raliser en une seule fois ce qui se manifeste gnralement
sous plusieurs formes, puis de linstancier pour obtenir les diffrentes
manifestations dsires, voire souvent dautres manifestations non encore
prsentes dans le domaine.
Paralllement lanalyse de lenvironnement, se droule parfois une analyse de
lexistant et des contraintes de ralisation. Lobjet de cette analyse est de
comprendre parfaitement les caractristiques et les contraintes de
lenvironnement de ralisation afin de pouvoir prendre des dcisions motives et
rflchies lors de la conception. Cette analyse est le seul moyen de prendre en

compte de manire raliste les choix de ralisation qui peuvent tre imposs un
projet, avant mme la conception. Cette situation est malheureusement trop
courante en informatique. Les informaticiens doivent rsoudre un problme
partir dun fragment de solution !
Au passage la conception, il faut prendre garde ne pas perdre la vue
danalyse. La perte de cette vue est la consquence de lenrichissement des
modles durant la conception. Comme il a t dit plus haut, la conception apporte
des informations complmentaires qui viennent enrichir les descriptions
effectues en analyse. La tentation est forte de partir des diagrammes obtenus en
analyse et de rajouter linformation de conception dans ces diagrammes.
Lanalyse se fond alors progressivement dans la conception et les diagrammes ne
montrent plus les objets du domaine mais le comment. La situation est souvent
autrement complexe car les modles subissent des transformations qui sont plus
que de simples enrichissements ; un filtrage ne suffit pas pour retrouver la vue
danalyse.
Il nexiste pas de solution simple au problme de la transformation des modles,
en particulier de la transformation bidirectionnelle ; lorsque les claircissements
de la conception peuvent entraner des modifications de lanalyse par effet
rtroactif. UML dfinit le concept de trace entre lments de modlisation, y
compris dun modle lautre, de sorte quil est possible denregistrer lhistoire
de ces lments.
La conception objet
Comme lanalyse et la conception, la conception et la ralisation se chevauchent
en partie. Il est rare de savoir comment tout faire : pour cette raison il faut essayer
des techniques alternatives, comparer les rsultats puis choisir en faisant des
compromis. La conception et la ralisation se compltent. La conception a besoin
dexprimenter, la ralisation a besoin de principes directeurs.
Afin de maintenir le plus longtemps possible les bnfices de l'abstraction, la
conception est gnralement subdivise en deux tapes : une tape logique
indpendante de lenvironnement de ralisation et une tape physique qui se
proccupe de lordonnancement des ressources et des particularits des langages
de programmation ou de lenvironnement dexcution.
La conception est souvent considre, tort, comme un simple enrichissement
des rsultats obtenus durant lanalyse. Il sagit l dune vision fortement
rductrice qui ignore tout simplement que la conception est le temps de la mise en
uvre du savoir-faire. Ce savoir-faire peut tre interne au projet ou acquis
lextrieur sous la forme doutils, de composants rutilisables ou plus largement
de cadres de dveloppement. Lmergence des patterns (les patterns et les
frameworks sont dcrits plus loin) marque une avance dans la formalisation du
savoir-faire objet, indpendamment des langages de programmation et de leurs

subtils arcanes.
La conception dbute par la dtermination de larchitecture du logiciel, cest-dire par llaboration des structures statiques et dynamiques qui serviront de
charpente pour lensemble du dveloppement. Larchitecture dfinit la forme
gnrale de lapplication ; de sa qualit dpendent le dveloppement et
lvolution du logiciel. Larchitecture est la consquence de dcisions
stratgiques arrtes lors de la conception et de dcisions tactiques prises en
cours de ralisation.
Se donner une stratgie informatique, cest considrer le logiciel comme un
lment dterminant du dveloppement de lentreprise ; cest aussi chercher
sassurer une avance technologique par des choix darchitecture qui dpassent le
cadre des besoins immdiats, lis une application particulire.
Se donner une stratgie informatique, cest par exemple choisir :
linternationalisation, autrement dit, concevoir le logiciel de telle manire que

le dialogue avec lutilisateur puisse tre men dans toutes les langues ;
la rutilisation qui nest pas le fruit du hasard, mais le rsultat dune

adhsion forte de toute une organisation, depuis la dfinition de la ligne de
produits jusquau dveloppement de ces produits ;
lunicit de langage pour lensemble des dveloppements (Ada dans le cas

du ministre de la dfense amricain) ;
lindpendance par rapport aux dispositifs daffichage, autrement dit, le

dcouplage entre linformation afficher et la manire de lafficher ;
la portabilit des sources, voire des excutables, qui rduit notablement les
cots de dveloppement et surtout de maintenance dans le cas dun
dveloppement multicibles.
la gnralisation des mcanismes de communication entre objets qui permet

de rendre transparente la localisation des objets et ainsi de faciliter la
distribution des applications et de leurs composants.
La conception est le domaine du compromis. Il nexiste pas de solution toute

blanche ou toute noire : la vrit est toujours quelque part dans le gris. Les
dcisions tactiques couvrent toutes les activits qui guideront la recherche de
cette vrit dans leffort de dveloppement au jour le jour. Elles contiennent par
exemple les lments suivants :
la gnralisation d'abstractions et de mcanismes pour les tches

ancillaires, autrement dit, tous les composants largement rutilisables dans
les programmes, comme les dates, les chanes de caractres, les structures de
donnes de base, les algorithmes de tri, etc. ;
le traitement des erreurs qui peut tre effectu par des exceptions ou par des
statuts exprims sous la forme de valeurs entires. Lexception ne peut tre
ignore, mais son traitement obscurcit le code normal. Le statut derreur est
simple mettre en uvre mais il peut tre ignor : le traitement de lerreur nest
alors pas garanti ;
la gestion de la mmoire dynamique qui peut tre effectue par le

programmeur ou automatise par lenvironnement dexcution ;
la communication entre processus qui peut reposer sur des liaisons point-point, multi-points ou par diffusion. Elle peut tre assure par des mcanismes
ad hoc ou inscrite dans un schma gnral dintgration dapplication comme
Corba ou ActiveX ;
le choix des modes de communication qui inclut la forme et la nature des

messages et les diffrents modes de synchronisation : synchrone, semisynchrone, drobante, minute, asynchrone, etc ;
la prsentation des messages utilisateur afin de rendre toutes les interactions

avec lutilisateur le plus homognes possible ;
les langages de programmation qui sont compils ou interprts et

prsentent des points forts et des limites. Les langages compils permettent
dcrire des programmes plus fiables, les langages interprts apportent plus
de souplesse lors du dveloppement. Dans certains cas, il peut tre
intressant de mlanger diffrents langages au sein de la mme application ;
le choix des structures de donnes et des algorithmes qui sont encapsuls

dans les objets afin de dcoupler la spcification de la ralisation des classes ;
loptimisation du rseau de relations qui reflte les besoins de

communication de lutilisateur. Le concepteur peut tre amen modifier ce
rseau pour diverses raisons : optimiser la vitesse des accs, prendre en
compte des contraintes particulires de ralisation, comme labsence de lien
bidirectionnel dans les langages de programmation de troisime gnration ;
la mutation de certaines relations de gnralisation parce que lhritage

multiple nest pas disponible dans le langage de programmation utilis ou
encore parce que la forme de gnralisation recherche doit tre dynamique
alors que lhritage est statique ;
la mise en uvre de composants rutilisables dans le cadre de deux ralits ;

la programmation avec la rutilisation et la programmation pour la rutilisation.
La premire forme de rutilisation consiste incorporer un composant existant
et ainsi acclrer un dveloppement en cours. La deuxime forme
sapparente plus un investissement : le cot est immdiat et les bnfices ne
sont perus que plus tard.
Leffort dvelopp en conception est plus ou moins important selon la nature de

lapplication et la richesse de lenvironnement de ralisation. Il est de plus en plus
possible deffectuer un transfert de complexit des applications vers les

environnements, grce une factorisation des lments et des mcanismes
communs. Cest le cas dans les familles dapplications bien cibles dans un
domaine donn, comme les logiciels clients qui interagissent avec des serveurs de
bases de donnes. Inversement, plus une application est technique, plus elle
interagit avec des matriels particuliers et plus leffort de conception est
important.
Les outils RAD dveloppement rapide dapplications proposent une voie bien
trace. Tout comme avec les frameworks, il faut suivre les rgles du jeu fixes
lavance : au bnfice de la simplicit mais au dtriment de loriginalit. Toutes les
applications finissent par se ressembler, ce qui est bien et mal la fois. Le travers
des outils RAD est dencourager faire vite et salement quick and dirty
plutt que vite et bien.
Curieusement, le RAD est un mlange de gnie logiciel dans sa conception et
dhorreur informatique dans son utilisation. Ceci est la consquence dune vision
court terme des utilisateurs pour qui seul laspect rapidit compte bien souvent.
Comme le RAD nencourage pas particulirement la modularit et les abstractions
en couches, trs rapidement cest le cas de le dire le code dinterface
utilisateur et le code de lapplication se retrouvent intimement mlangs. Le
logiciel construit de cette manire est difficile maintenir et quasiment impossible
rutiliser pour une autre application.
Le propre de la conception est de rechercher lquilibre entre vitesse de
ralisation et possibilit de rutilisation, ouverture et solution cl en main, vision
court terme (la tactique) et vision long terme (la stratgie).
La programmation objet
La programmation objet est le dernier maillon de la chane objet, aprs lanalyse et
la conception. La programmation dans un langage objet est la manire la plus
commode de traduire une conception objet en un programme excutable par une
machine. Il est galement possible dutiliser un langage non objet, mais ceci
impose une charge de travail supplmentaire au programmeur qui doit simuler les
constructions objet.
Paralllement aux vrais langages objet, comme Smalltalk ou Java, il est possible de
trouver des langages ou des environnements teinture objet, par exemple Visual
Basic de Microsoft ou encore Powerbuilder de Powersoft ; dune certaine manire
ils permettent de faire de lobjet en douceur, sans sen rendre compte23.
Les langages de programmation objet sont en majorit des langages
algorithmiques et structurs. Ils offrent au moins les concepts de classes,
23
Coydon B. 1995, Visual Basic, Dveloppement dapplications professionnelles

sous Windows. Eyrolles, Paris.
dobjets, dhritage, de liaison dynamique et dencapsulation. Bertrand Meyer

insiste tout particulirement sur la gestion automatique24 de la mmoire. Eiffel,
Smalltalk et Java sont pourvus dun systme de ramasse-miettes qui affranchit le
programmeur du difficile, voire insurmontable, problme de libration de la
mmoire dynamique. La principale qualit des langages objet est de rduire le
dcalage entre la manire de penser du programmeur et le langage fruste compris
par lordinateur. Il existe toutefois de grandes variations syntaxiques entre les
diffrents langages objet selon quils sont une extension conservatrice comme
C++ ou une innovation totale comme Smalltalk.
Le choix dun langage de programmation objet est souvent dict par la culture
informatique de lentreprise. Jusqu prsent, linformatique technique penchait
plutt pour C++ alors que le monde de la gestion manifestait un intrt croissant
pour Smalltalk ou les solutions semi-objet voques prcdemment. Lanne 96 a
t marque par le dferlement du langage Java dvelopp par Sun : il suscite un
intrt trs large de la part de lensemble de la communaut informatique.
Il existe de nombreux langages de programmation objet dont les principaux sont
dcrits ici dans leurs grandes lignes :
Ada est un langage de programmation de haut niveau conu pour rduire les
cots de dveloppement exorbitants auxquels le ministre de la dfense
amricain devait faire face dans les annes 70. Ada a t normalis une
premire fois en 1983 par lANSI. Aprs une dcennie dutilisation, le langage
Ada a t amlior par lajout de constructions objet et sa deuxime mouture,
standardise en 1995, en fait un langage objet part entire. Ada 83 est le
langage du gnie logiciel ; Ada 95 est le langage du gnie logiciel objet.
C++ est un langage objet hybride conu par Bjarne Stroustrup dans les
annes 80 : cest une extension du langage C. C++ corrige le C en rajoutant le
typage fort, les classes, la surcharge et la liaison dynamique. Sa syntaxe reste
touffue comme celle du C et rend C++ difficile mettre en uvre.
Eiffel est un langage objet volontairement simple, la syntaxe trs propre. Il a

t conu par Bertrand Meyer dans les annes 80. Eiffel se distingue des
autres langages objet par la place quil accorde la notion de programmation
par contrat ; cest ainsi le seul langage qui prenne en compte le principe de
substitution dans sa syntaxe.
Java est le dernier-n des langages objet. Il sinspire de C++ pour la syntaxe et
de Smalltalk pour la machine virtuelle, tout en restant comme Eiffel
volontairement simple. Initialement conu pour la programmation des
24
Meyer B. 1988, Object-Oriented Software Construction, Prentice Hall, New York,

NY.
assistants lectroniques (personal digital assistant), le langage Java a t

propuls sur le devant de la scne par sa forte complmentarit avec Internet.
Smalltalk est le langage objet par excellence : en Smalltalk, tout est objet, y
compris les classes elles-mmes. Smalltalk a t conu dans les annes 70 au
PARC (le centre de recherche de Xerox Palo Alto). Depuis 1980, Smalltalk est
accompagn dun environnement de dveloppement sophistiqu et dune
grande collection de classes prdfinies. Du fait de sa souplesse demploi et
de sa simplicit, Smalltalk connat actuellement un regain dintrt pour la
cration de systmes dinformation.
Le tableau suivant rsume les caractristiques des principaux langages objet. Le

cas de Smalltalk est particulier car les caractristiques du langage peuvent tre
tendues en intervenant au niveau des mtaclasses.
Ada 95
C++
Eiffel
Java
Smalltalk
Paquetage
Oui
Non
Non
Oui
Non
Hritage
Simple
Multiple
Multiple
Simple
Simple
Gnricit
Oui
Oui
Oui
Non
Non
Typage
Fort
Fort
Fort
Fort
Non typ
Liaison
Dynamique
Dynamique
Dynamique
Dynamique
Dynamique
Paralllisme
Oui
Non
Non
Oui
Non
Ramasse-miettes
Non
Non
Oui
Oui
Oui
Assertions
Non
Non
Oui
Non
Non
Persistance
Non
Non
Non
Non
Non
Figure 316 : Tableau rcapitulatif des grandes caractristiques des principaux langages
objet.
La transition vers lobjet

La transition dune organisation vers la technologie objet demande un temps non
ngligeable.
Pour des dveloppeurs confirms, il faut compter en moyenne :
1 mois pour matriser les constructions dun langage objet,
6 9 mois pour acqurir un mode de pense objet,
1 mois pour matriser une bibliothque de classes,
6 9 mois pour dominer un framework.
Il faut savoir nanmoins quune petite minorit de rfractaires ne parviendront

jamais sauter le pas (entre 10 et 15 % des dveloppeurs). Aucun critre simple
ne permet a priori de les identifier.
Pour faciliter la transition, il est fortement conseill :
de faire appel des comptences externes,
de lancer un projet pilote,
de mettre en place un plan de formation sous une forme qui combine thorie et
pratique,
davoir recours des spcialistes du transfert de technologie qui

accompagneront le projet,
de former tout le monde, les dveloppeurs mais aussi les groupes de test, les
quipes dassurance qualit et lencadrement.
La transition vers lobjet est coteuse. Il est sage de prvoir un surcot de 10

20 % pour le premier projet objet du fait de lapprentissage des diffrentes
techniques par lquipe de dveloppement et de lexprimentation de la gestion
du cycle itratif par lencadrement. Les bnfices de la transition ne seront
rcolts qu partir du deuxime ou troisime projet, qui devrait demander de 20
30 % de ressources en moins.
Vers une mthode de dveloppement

Un processus de dveloppement de logiciel a pour objectif la formalisation des
activits lies llaboration des systmes informatiques. La formalisation dun
processus de dveloppement vise doter les entreprises dun ensemble de
mcanismes qui, lorsquils sont appliqus systmatiquement, permettent
dobtenir de manire rptitive et fiable des systmes logiciels de qualit
constante. Par nature, la description du processus reste gnrale car il nest pas
possible de dfinir autoritairement un standard unique, adapt toutes les
personnes, tous les types dapplications et toutes les cultures. Il convient plutt
de parler de cadre configurable, ventuellement raffin de manire consensuelle
par la pratique et la mise en uvre de produits largement adopts par la
communaut des utilisateurs.
Une mthode de dveloppement comprend :
des lments de modlisation qui sont les briques conceptuelles de base,
une notation dont lobjectif est dassurer le rendu visuel des lments de
modlisation,
un processus qui dcrit les tapes suivre lors du dveloppement du

systme,
du savoir-faire, plus ou moins formalis.
Watts S. Humphrey a propos cinq niveaux de maturit25 des processus de

dveloppement de logiciel :
initial : le dveloppement nest pas formalis, lquipe ragit au jour le jour et

choisit des solutions au cas par cas de sorte que le succs dpend fortement
des personnes impliques dans le projet,
reproductible : lorganisation est capable dtablir des plans raisonnables en

termes de budget et de vrifier ltat davancement du projet par rapport ces
plans,
dfini : le processus de dveloppement est bien dfini, connu et compris par

tous les intervenants du projet,
encadr : les performances du processus de dveloppement sont mesurables

objectivement,
optimisant : les donnes de contrle des performances du processus

permettent lamlioration du processus.
A partir de ce modle, le SEI (Software Engineering Institute) de luniversit de

Carnegie Mellon dvelopp une procdure dvaluation des processus de
dveloppement connue sous labrviation CMM (Capability Maturity Model).
Le diagramme suivant reprsente les cinq niveaux de maturit des processus.
Figure 317 : Reprsentation des cinq niveaux de maturit des processus de dveloppement
selon Watts S. Humphrey.
La segmentation de la modlisation permet de grer la complexit en rduisant la

porte de ltude une partie, un sous-ensemble ou un point de vue. De cette
manire, lorsque le tout est trop complexe pour tre compris dun seul coup, la
comprhension globale peut se dgager par la perception parallle de plusieurs
25
Humphrey W. S. 1989, Managing the Software Process, Addison-Wesley.
vues disjointes, mais concourantes. Le choix des points de vue, cest--dire de ce

qui est modlis, influence fortement la manire dapprocher le problme, et donc
la forme des solutions qui retenues. Il nexiste pas de modle universel et les
niveaux de dtail, de prcision ou de fidlit peuvent varier. Les meilleurs modles
sont en prise directe sur la ralit.
UML est un langage pour la reprsentation des modles objet, mais le processus
dlaboration de ces modles nest pas dcrit par UML. Les auteurs dUML
insistent nanmoins sur les caractristiques suivantes, qui leur semblent
essentielles pour un processus de dveloppement :
pilot par les cas dutilisation : toutes les activits, de la spcification de ce

qui doit tre fait jusqu la maintenance, sont guides par les cas dutilisation.
centr sur larchitecture. Ds le dpart, le projet place la dtermination des

traits de larchitecture en ligne de mire. Larchitecture est conue pour
satisfaire les besoins exprims dans les cas dutilisation, mais aussi pour
prendre en compte les volutions et les contraintes de ralisation.
Larchitecture doit tre simple et se comprendre de manire intuitive ; elle est
conue avec et pour la rutilisation.
itratif et incrmental : lensemble du travail est divis en petites itrations,

dfinies partir du degr dimportance des cas dutilisation et de ltude des
risques. Le dveloppement procde par des itrations qui conduisent des
livraisons incrmentales du systme. Les itrations peuvent tre conduites en
parallle.
Le diagramme suivant reprsente la forme gnrale du processus de

dveloppement prconis par les auteurs dUML.
Architecture
Itratif et incrmental
Cas d'utilisation
<<Centr sur>>
<<Pilot par>>
<<Droulement>>
Processus Gnrique
Groupe A
Entreprise B
Figure 318 : Le processus de dveloppement prconis par les auteurs dUML est pilot par
les cas dutilisation, centr sur larchitecture et droul de manire itrative et incrmentale.
Les cas dutilisation

Les cas dutilisation (use cases) viennent en complment de lapproche objet et
forment la base du processus de dveloppement. Dans ce contexte, les cas
dutilisation doivent tre vus comme un fil rouge ; ce fil balise les diffrentes
activits du dveloppement de lexpression des besoins dun utilisateur vers la
ralisation informatique qui satisfait ces besoins.
Figure 319 : Les cas dutilisation balisent les diffrentes activits et tapes du processus.
Les besoins sont dabord segments par rapport aux diffrents types
dutilisateurs (les acteurs) et dcrits par des cas dutilisation exprims dans le
langage des acteurs. A ce stade, les cas dutilisation aident lutilisateur articuler
ses besoins : il dcrit les services quil attend du systme sous la forme
dinteractions entre lacteur et le systme. Lanalyse des besoins est
principalement exprime par un modle des cas dutilisation.
Le processus continue par une dmarche danalyse objet. Les objets qui
appartiennent fondamentalement au domaine de lapplication sont identifis, puis
dcrits de manire gnrale par leurs classes. Chaque cas dutilisation est ensuite
ralis par une collaboration entre les objets trouvs prcdemment. La
dcomposition nest pas fonctionnelle : la collaboration qui ralise un cas
dutilisation nest quun cas particulier des collaborations potentielles gnres
par la structure des classes.
Le passage de lanalyse la conception est marqu par lintroduction de
considrations de ralisation dans les modles. Lanalyse dcrit le quoi dun
systme alors que la conception sintresse au comment. Les cas dutilisation
continuent de baliser la conception puisquils spcifient ce que les mcanismes
doivent faire.
Les cas dutilisation dcrivent les tests fonctionnels.
Cas d'utilisation
Dcrit le domaine
Ralise
Vrifie
Analyse
Conception
Test
Figure 320 : Les cas dutilisation coordonnent et balisent les diffrents modles.
Pour autant, les cas dutilisation ne donnent pas la forme du systme. Dans une
approche objet, la forme (larchitecture) du logiciel ne reflte pas la forme des cas
dutilisation.
Architecture logicielle
Le dveloppement dun logiciel peut tre vu comme la traverse dun ocan en
bateau. Le jour de dpart est connu, le jour darrive lest moins, et en cours de
route, il faudra affronter des temptes et rparer des avaries. La conception de
larchitecture dun logiciel a pour objet de donner un effort de dveloppement
les moyens de parvenir bon port.
Larchitecture logicielle sintresse la forme globale dune application : cette
forme merge de la conception au-del des structures de donnes ou des
algorithmes 26. Larchitecture logicielle se proccupe dintgrit, duniformit, de
simplicit et desthtisme. Elle est presque contre-courant dune discipline (le
dveloppement de logiciel) que rien ne prdispose aux vertus voques plus
haut, du fait principalement de limmatrialit du logiciel et de labsence de
contraintes physiques.
La mise en place d'une architecture adapte est la cl de vote du succs dun
dveloppement. Il importe de la stabiliser le plus tt possible. Il nexiste pas
darchitecture universelle, adapte tous les types dapplications. En revanche, il
existe des architectures rutilisables, dans les limites dun domaine particulier.
26
Garland D., Shaw, M. 1993, An Introduction to Software Architecture.

Advances in Software Engineering and Knowledge Engineering, Vol. 1,
Singapore, World Scientific Publishing Co., pp. 1-39
Perry et Wolf27 dfinissent larchitecture des logiciels par la formule suivante :

Architecture logicielle = Elments + Formes +
Motivations
Dans le contexte de la dmarche objet, les lments sont les objets et les classes,
les formes sont des regroupements de classes et dobjets (les patterns), et les
motivations expliquent pourquoi tel ou tel regroupement est plus adapt quun
autre dans un contexte donn.
Larchitecture offre une vision globale de lapplication ; elle dcrit les choix
stratgiques qui dterminent les qualits du logiciel, comme la fiabilit,
ladaptabilit ou la garantie des performances, tout en mnageant des espaces
pour les dcisions tactiques prises en cours de dveloppement28.
Figure 321 : Larchitecture reflte les choix stratgiques gnraux et mnage des espaces
pour les dcisions tactiques ponctuelles.
Les bonnes architectures se caractrisent par :
la simplicit,
llgance,
lintelligibilit,
des niveaux dabstraction bien dfinis,
27
Perry D. E.and Wolf A. L. Oct. 1992, Foundations for the Study of Software
Architecture. ACM Software Eng. Notes, pp. 40-52.
28
Pour prendre une image gastronomique, le dveloppement consiste

transformer un morceau de gruyre en un morceau de comt, par remplissage des
trous !
une sparation claire entre linterface et limplmentation de chaque niveau.
La vision de larchitecte
Il nexiste pas une seule manire de considrer un systme. De multiples points de
vue sont requis. Par ailleurs, pour satisfaire les multiples intervenants chaque
type de diagramme ne donne quune image partielle dun systme.
Tous les projets objet couronns de succs se caractrisent par la prsence dune
forte vision de larchitecture. Cette vision peut tre dcrite partir de plusieurs
vues complmentaires, inspires de celles dcrites par Philippe Kruchten29, dans
son modle dit des 4 + 1 vues.
Figure 322 : Reprsentation du modle darchitecture de Philippe Kruchten.
Ce modle darchitecture est bien adapt la reprsentation des contraintes

varies que larchitecte doit prendre en considration.
La vue logique
La vue logique dcrit les aspects statiques et dynamiques dun systme en
termes de classes et dobjets et se concentre sur labstraction, lencapsulation et
luniformit. Le systme est dcompos dans un jeu d'abstractions-cls,
originellement issues du domaine du problme. Au-del de la satisfaction des
besoins fonctionnels de lutilisateur, la vue logique permet didentifier et de
gnraliser les lments et les mcanismes qui constituent les diffrentes parties
du systme.
La vue logique met en jeu les lments de modlisation suivants :
les objets,
les classes,
les collaborations,
les interactions,
29
Kruchten P. Nov. 95, The 4+1 View Model of Architecture. IEEE Software.
les catgories (paquetages strotyps).
La vue de ralisation
La vue de ralisation se proccupe de lorganisation des modules dans
lenvironnement de dveloppement. Elle montre lallocation des classes dans les
modules, et lallocation des modules dans les sous-systmes. Les sous-systmes
sont eux-mmes organiss en niveaux hirarchiques aux interfaces bien dfinies.
La vue de ralisation traite des lments de modlisation suivants :
les modules,
les sous-programmes,
les tches (en tant quunits de programme, comme en Ada),
les sous-systmes (paquetages strotyps).
La vue des processus

La vue des processus reprsente la dcomposition en flots dexcution
(processus, threads, tches...), la synchronisation entre flots et lallocation des
objets et des classes au sein des diffrents flots. La vue des processus se
proccupe galement de la disponibilit du systme, de la fiabilit des
applications et des performances.
La vue des processus prend toute son importance dans les environnements
multitches.
La vue des processus manipule les lments de modlisation suivants :
les tches, les threads, les processus,
les interactions.
La vue de dploiement
La vue de dploiement dcrit les diffrentes ressources matrielles et
limplantation du logiciel dans ces ressources.
La vue de dploiement traite les points suivants :
les temps de rponse et les performances du systme,
la bande passante des chemins de communication et les capacits,
les contraintes gographiques (disposition physique des processeurs),
les besoins en puissance de calcul distribue,
les surcharges et lquilibrage des charges dans un systme distribu,
la tolrance aux fautes et aux pannes.
La vue de dploiement prend toute son importance lorsque le systme est

distribu.
La vue de dploiement se concentre sur les lments de modlisation suivants :
les nuds,
les modules,
les programmes principaux.
La vue des cas dutilisation

Les cas dutilisation forment la colle qui unifie les quatre vues prcdentes. Les
cas dutilisation motivent et justifient les choix darchitecture. Ils permettent
didentifier les interfaces critiques, ils forcent les concepteurs se concentrer sur
les problmes concrets, ils dmontrent et valident les autres vues darchitecture.
La vue des cas dutilisation rend compte des lments de modlisation suivants :
les acteurs,
les cas dutilisation,
les classes,
les collaborations.
Organisation des modles

Les cinq vues dcrites plus haut, associes au concept de paquetage, permettent
la structuration hirarchique dun modle. Un modle dcrit par UML prend la
forme de larborescence reprsente dans le diagramme de classes suivant :
Modle
1
Vue
1..5
Paquetage
0..1
Possde
*
*
Rfrence
*
Elment
1..*
Elment de visualisation
< Montre
0..*
Figure 323 : Extrait du mtamodle. Organisation hirarchique des modles selon plusieurs
vues.
Les paquetages sont la fois des lments de modlisation et des lments de

structuration des modles. Larborescence des paquetages organise les modles,
comme les rpertoires organisent les systmes de fichiers.
Le diagramme dobjets suivant donne un exemple dorganisation dun modle,
structur selon les cinq vues darchitecture prsentes plus haut :
: Modle
Vue des cas d'utilisation : Paquetage
: Elment
Vue logique : Paquetage
: Elment
Vue de ralisation : Paquetage
: Elment
Vue des processus : Paquetage
: Elment
Vue de dploiement : Paquetage
: Elment
Figure 324 : Exemple de modle structur selon cinq vues darchitecture.
Documentation de larchitecture
Larchitecture est dcrite dans un document darchitecture qui comprend :
une description textuelle des traits de larchitecture (les vues) et les besoinscls du systme,
les compromis retenus et les alternatives explores,
une reprsentation de haut niveau de la vue logique (entre 5 et 50 classescls),
des scnarios spcifiques larchitecture,
la description des mcanismes-cls.
Articulation des diffrents diagrammes

Les lments de modlisation sont accessibles lutilisateur par lintermdiaire de
projections graphiques (les lments de visualisation) reprsentes dans les
neufs types de diagrammes suivants :
Diagramme
Composants
Dploiement
Classes
Cas d'utilisation
Squence
Etats-Transitions
Activit
Objets
Collaboration
Figure 325 : Reprsentation des neuf types de diagrammes dfinis par UML.
Ces diagrammes forment la base des vues darchitecture dcrites plus haut. Il
importe de bien conceptualiser les liens entre les diffrents lments de
modlisation et leurs reprsentations associes afin de documenter un systme
avec clart et efficacit.
Un modle est une construction smantique, organise sous la forme dun rseau.
Ce rseau peut se parcourir en suivant les rgles gnrales dcrites dans le
mtamodle dUML.
Les diffrents diagrammes peuvent tre vus comme des chemins graphiques
parcourant les modles. Les paragraphes suivants proposent un exemple de
cheminement, depuis lnonc des besoins jusquau dploiement dans le matriel.
Expression des besoins

Lexpression des besoins dune catgorie dutilisateur est dcrite sous une forme
fonctionnelle dans les cas dutilisation. Les cas dutilisation sont exprims en
langage naturel, dans les termes de lutilisateur.
Acteur
Cas d'utilisation
*
Besoin
Figure 326 : Les besoins des utilisateurs sont exprims, acteur par acteur, sous la forme de
cas dutilisation.
Transition vers lobjet

La transition vers lobjet est opre par lanalyste. Il ralise le comportement
dcrit dans le cas dutilisation au moyen dune collaboration entre des objets,
initialement issus du domaine de lapplication. Le contexte dune collaboration est
reprsent dans un diagramme dobjets.
Cas d'utilisation
<<Ralise>>
*
Objet
Contexte
*
Collaboration
0..*
Interaction
0..1
Figure 327 : La transition vers lobjet est opre en ralisant un cas dutilisation par une
collaboration entre objets du domaine.
Expression du comportement
Le comportement dune collaboration ou dune classe peut se reprsenter sous la
forme dune interaction ou dun automate. Les interactions sont visualises du
point de vue temporel, par des diagrammes de squence et du point de vue
spatial, par des diagrammes de collaboration. Les automates sont visualiss du
point de vue des tats et des transitions, par des diagrammes dtats-transitions
et du point de vue des activits, par des diagrammes dactivits.
0..1
Classe
0..1
Collaboration
0..*
Automate
0..1
Interaction
0..*
0..*
Diagramme
d'tats-transitions
Diagramme
d'activits
Diagramme
d'interaction
Diagramme
de squence
Diagramme
de collaboration
Figure 328 : UML propose 5 types de diagrammes pour la reprsentation du comportement.
Reprsentation de la structure
Chaque objet est instance dune classe. Les classes du domaine dcrivent de
manire gnrale les objets mtiers. Les objets sont reprsents dans les
diagrammes dobjets, dans les diagrammes de collaboration et dans les
diagrammes de squence. Les classes sont reprsentes dans les diagrammes de
classes.
Lien
Instance de >
Relation
Objet
*
Classe
*
Instance de >
Collaboration
*
*
Interaction
Diagramme de classe
0..*
0..1
Diagramme d'objets
1
*
Contexte
Diagramme d'interaction
*
Figure 329 : Chaque objet est instance dune classe.
Ralisation des objets et des classes

Le code qui ralise les classes, les objets et les interactions entre ces objets est
stock dans des composants qui constituent les briques de la structure physique
des systmes. Les composants regroupent les modules, les sous-programmes, les
tches (au sens des units de programmes Ada) et les programmes principaux.
Les modules contiennent le code qui correspond aux classes et aux objets, les
programmes principaux contiennent le code qui correspond aux points dentre
dans la ralisation des interactions. Un module peut contenir plusieurs classes et
plusieurs objets, mais par dfaut, il ny a quune seule classe par module ; le nom
de la classe est utilis pour construire le nom du module dans lespace de
dveloppement.
Un diagramme de composants montre les dpendances de compilation entre les
diffrents composants dune application.
Instance de >
Objet
Classe
1
*
*
Dpendance
Composant
1
Module
Sous-Programme
Tche
Programme principal
Figure 330 : Le code qui correspond aux objets et aux classes est stock dans des modules.
Dploiement du code excutable

Un programme principal est une sorte de composant qui contient un code
excutable correspondant une ou plusieurs interactions. Trs souvent, un
programme principal ne correspond qu une seule interaction. Un programme
principal est dploy sur des nuds, au sein de processus qui lexcutent.
Les diagrammes de dploiement montrent les diffrentes sortes de processeurs et
de dispositifs qui composent lenvironnement dexcution du systme ; ils
montrent aussi la configuration de composants, de processus et dobjets qui
sexcutent dans cet environnement. Si ncessaire, la migration des objets et des

processus est reprsente au moyen dune relation de dpendance strotype.
Interaction
1
Programme principal
*
Processus
*
Noeud
Figure 331 : Un programme principal est une sorte de composant qui contient un code
excutable correspondant une ou plusieurs interactions.
Organisation des modles et des vues

Les paquetages organisent les vues et les modles en encapsulant les autres
lments de modlisation dans une dcomposition hirarchique, analogue la
structuration dun systme de fichiers par des rpertoires :
dans la vue logique, les paquetages contiennent des objets, des classes,
dautres paquetages, et les diagrammes qui visualisent ces lments,
dans la vue de ralisation, les paquetages contiennent des composants et

dautres paquetages et les diagrammes correspondants.
Les paquetages peuvent tre spcialiss sous la forme de catgories et de soussystmes, pour distinguer respectivement les paquetages de la vue logique et les
paquetages de la vue de ralisation.
Paquetage
Catgorie
Sous-systme
Figure 332 : Exemple de spcialisation des paquetages pour distinguer les concepts
dorganisation de la vue logique, de ceux de la vue de ralisation.
En rgle gnrale, il y a correspondance directe entre une catgorie et un soussystme. Les hirarchies de catgories et de sous-systmes peuvent diffrer,
entre autres pour :
regrouper des objets qui ont une forte interaction,
raliser des fonctionnalits de bas niveau, non reprsentes en analyse,
rpartir le travail dans lquipe de dveloppement.
Granularit des lments de modlisation

Les lments de modlisation dUML suivent une dichotomie telle que pour un
type de concept donn, il existe toujours un lment de modlisation granularit
fine et un lment de modlisation granularit plus leve.
Le diagramme suivant illustre les correspondances entre les lments granularit
forte.
Catgorie
Processus
*
*
1
1..*
Sous-systme
Noeud
*
Figure 333 : Reprsentation des correspondances entre les lments granularit forte.
Les lments plus faible granularit sont galement en correspondance.

Classe
Thread
*
Module
Processeur
*
Figure 334 : Reprsentation des correspondances entre les lments granularit fine.
Vue par vue, les lments forte granularit sont des agrgats dlments
granularit plus fine. UML permet de construire des modles empreints de cette
dcomposition hirarchique, et favorise ainsi la navigation entre les diffrents
points de vue et entre les niveaux de dtails de ces points de vue.
Catgorie
Processus
1
Classe
*
Module
Processeur
*
*
1
Thread
*
1..*
*
*
Sous-systme
Noeud
*
Figure 335 : Correspondance entre les lments de modlisation au sein dune reprsentation
hirarchique matrialise par les agrgations.
Cette dichotomie entre lments peut tre reprsente sous la forme dun
empilement pyramidal des lments de modlisation dUML ; il montre que tous
les lments sont visibles simultanment en cas de besoin, mais que la vision
peut galement se limiter un niveau dabstraction donn.
Figure 336 : Reprsentation pyramidale des lments de modlisation dUML.
La figure prcdente fournit une vue du dessus de cet empilement. Les lments
de mme niveau hirarchique dans la pyramide sont en correspondance vue par
vue. La base de la pyramide regroupe les lments forte granularit, ltage
intermdiaire contient les lments fine granularit et le sommet est constitu
des cas dutilisation. Ces derniers se ralisent par des collaborations construites
partir des lments des niveaux infrieurs.
Grce ces correspondances entre lments de modlisation, UML facilite la
navigation entre les points de vue gnraux et les points de vue dtaills, comme
le dcrit Grady Booch, pour qui la forme gnrale influence les formes dtailles et
rciproquement. Il qualifie sa dmarche de Round Trip Gestalt30.
Rcapitulatif des lments et des vues

Le tableau suivant rsume lutilisation courante des lments dans les diffrents
diagrammes dans le but de reprsenter les diffrents points de vue. Cette
reprsentation nest pas limitative ; lutilisateur est libre de reprsenter les
lments quil trouve pertinents dans les diagrammes qui lui conviennent.
30
Booch G. 1994, Object-Oriented Analysis and Design, with Applications.

Benjamin Cummings.
Vue des cas

dutilisation
Diagramme de
cas
dutilisation
Vue de
ralisation
Vue des
processus
Vue de
dploiement
Acteurs
Cas
dutilisation
Diagramme de
classes
Diagramme
dobjets
Vue logique
Classes
Relations
Objets
Classes
Liens
Objets
Liens
Diagramme de
squence
Diagramme de
collaboration
Diagramme
dtatstransitions
Diagramme
dactivit
Acteurs
Acteurs
Objets
Objets
Objets
Messages
Messages
Messages
Acteurs
Acteurs
Objets
Objets
Objets
Liens
Liens
Liens
Messages
Message
Messages
Etats
Etats
Etats
Transitions
Transitions
Transitions
Activits
Activits
Activits
Transitions
Transitions
Transitions
Diagramme de
composants
Diagramme de
dploiement
Composants
Composants
Composants
Nuds
Liens
Figure 337 : Tableau rcapitulatif de lutilisation des lments dans les diffrents types de
diagrammes dans le but de reprsenter les diffrents points de vue.
Micro-architecture
Le terme anglais pattern, en franais forme, micro-architecture, ou schme,
dsigne des combinaisons rcurrentes dobjets et de classes. Elle se retrouvent
frquemment dans les conceptions objet et peuvent tre qualifies de savoir-faire
objet. Le principal intrt des patterns est de permettre la manipulation de
concepts darchitecture plus labors que les objets et classes. Ils augmentent la
puissance dexpression des langages de modlisation. Cette dmarche vite
galement de trop sattarder sur des objets lis aux particularits du domaine de
lapplication, et ainsi de rechercher des conceptions de plus haut niveau,
ventuellement moins performantes, mais plus flexibles et plus extensibles. Dans
une certaine mesure, un pattern est pour les objets, lquivalent du sousprogramme pour les instructions, ou encore des circuits intgrs pour les
transistors. Le pattern est lunit de rutilisation de conception objet.
Le concept de pattern 31 a t dcrit par Christopher Alexander32. Cet architecte
dsirait formaliser les grands traits de larchitecture afin de faciliter la construction
des btiments. Cette ide de formalisation des lments darchitecture, ou encore
des formes darchitecture (do le terme de pattern), peut tout fait tre
transpose dans le domaine du logiciel, afin de dfinir des formes logicielles
rutilisables dapplications en applications.
UML reprsente les patterns par les collaborations. Une collaboration regroupe
un contexte dobjets et une interaction entre ces objets. Une collaboration
convient donc pour la reprsentation des patterns de structure, comme des
patterns de comportement. Les collaborations sont reprsentes par des ellipses
pointilles, connectes aux objets qui y participent.
Le diagramme suivant reprsente un pattern de chane de responsabilit.
31
Alexander C., Ishikawa S., Silverstein M., Jacobson M., Fiskdahl-King I., Angel
S. 1977, A Pattern Language. Oxford University Press, New York.
32
Each pattern describes a problem which occurs over and over again in our
environment, and then describes the core of the solution to that problem, in
such a way that you can use this solution a million times over, without ever
doing it the same way twice. Christopher Alexander
Figure 338 : Reprsentation dun pattern chane de responsabilit par une

collaboration.
Il existe galement des patterns danalyse, construits partir dobjets mtiers, et

ddis spcifiquement des logiciels dploys dans un domaine donn.
Description des patterns
La description33 prcise des patterns est essentielle pour permettre leur mise en
uvre. Au minimum, un pattern est dcrit par :
un nom pour augmenter le niveau dabstraction du langage de modlisation,
un problme avec son contexte et des pr- et post-conditions,
une solution abstraite indpendante des langages de programmation,
des consquences en termes de flexibilit, dextensibilit et de portabilit.
Idiomes
Les patterns sont des constructions caractristiques totalement indpendantes
des langages de ralisation. Les patterns formalisent des choix darchitecture qui
peuvent tre mis en uvre de manire uniforme, quel que soit lenvironnement de
ralisation. Paralllement ces formes indpendantes, il existe des constructions
rcurrentes spcifiques un langage de programmation donn. Ces formes
particulires, appeles idiomes, regroupent des constructions syntaxiques
existantes. Les idiomes permettent de former de nouvelles constructions et ne
sont gnralement pas transposables tels quels dun langage lautre.
33
Gamma E., Helm R., Johnson R., Vlissides J. 1995, Elements of Reusable ObjectOriented Software. Addison-Wesley.
Les idiomes appartiennent au florilge de trucs et astuces qui accompagnent un

style de programmation, considr comme lgant dans un langage donn. Selon
la puissance dexpression des langages, une technique donne peut tre un
idiome dans un langage et une construction syntaxique dans un autre.
La copie dune chane de caractres en C++ peut se raliser de la manire
suivante :
While (*destination++ = *source++) ;
En Ada, les noms peuvent tre prfixs :

Standard.Mailbox.Open ;
En C++, beaucoup de techniques de programmation comme la gestion de la

mmoire, les entres-sorties ou linitialisation relvent des idiomes. Ces idiomes
sont dcrits dans des ouvrages 34 qui se prsentent comme des manuels de
programmation avance. A lusage, C++ se rvle tre un langage assez difficile
utiliser, du fait de la ncessit de matriser un grand nombre didiomes pour
programmer efficacement.
Macro-architecture
La reprsentation des grands systmes fait appel de nombreuses classes. Du
fait de la complexit des modles dont le contenu dpasse rapidement les
limites 35 de comprhension de l'tre humain il est impossible de distinguer les
traits de larchitecture dans les entrelacs de classes et de relations. Larchitecture
gnrale dune application ne peut pas se reprsenter partir dlments fine
granularit ; il faut introduire des concepts structurants plus larges pour faire
merger la macrostructure et pour faciliter la comprhension des modles.
Les patterns dcrivent de petites formes rcurrentes, utilisables au jour le jour
pour rsoudre des problmes ponctuels. Ces patterns nexpriment pas la forme
gnrale dune application. Cest pourquoi des reprsentations plus larges
regroupent les patterns au sein de frameworks, vritables infrastructures
rutilisables, ddies la ralisation dapplications cibles. Ces frameworks
34
Meyers S. 1991, Effective C++, 50 Specific Ways to Improve Your Programs

and Designs. Addison Wesley.
35
Miller G. March 1956, The Magical Number Seven, Plus or Minus Two: Some
Limits on Our Capacity for Processing Information. The Psychological Review
V. 63 (2).
peuvent tre reprsents au moyen des trois concepts structurants proposs par
UML : les cas dutilisation, les paquetages et les collaborations. Ces concepts
expriment respectivement, le comportement vu de lextrieur, la macrostructure
statique et les patterns.
La macro-architecture se reprsente au moyen de catgories (paquetages
strotyps pour insister sur leur fonction architecturale). Les catgories
encapsulent les classes et les objets coupls logiquement au sein dlments plus
larges. Ils permettent ainsi de construire des niveaux hirarchiques. Ils
segmentent une application en couches dabstraction croissante. Chaque niveau
possde des interfaces bien dfinies. Un niveau de rang donn ne dpend que
des niveaux de rang infrieur. La forme gnrale dune application se reprsente
par des diagrammes de catgories, en fait des diagrammes de classes qui ne
contiennent que des catgories. Les diffrentes catgories sont relies entre elles
par des relations de dpendances strotypes pour reprsenter les imports entre
catgories.
<<Catgorie>>
<<Import>
>
<<Catgorie>>
<<Import>>
<<Catgorie>>
Figure 339 : Exemple de reprsentation des catgories et des imports entre catgories.
Le diagramme de catgories suivant reprsente un exemple de macrostructure. Le

strotype <<Framework>> a t dfini afin de dsigner des ensembles de
classes stabilises, rutilisables dapplications en applications. Lapplication est
compose de quatre niveaux dabstraction. Le niveau le plus bas encapsule les
spcificits du systme dexploitation. Le deuxime niveau offre des services de
communication et de persistance. Le troisime niveau comprend un framework de
contrle-commande et deux catgories dobjets mtiers : les machines-outils et les
gammes dusinage. Le dernier niveau contient un framework dobjets graphiques
rutilisables et une catgorie IHM qui contient des objets miroirs des objets
mtiers. Les trois catgories de plus bas niveau pourraient trs certainement tre
transformes en un framework.
<<Framework>>
<<Catgorie>>
Wigdets
IHM
<<Miroir>>
<<Framework>>
<<Catgorie>>
<<Catgorie>>
Contrle
commande
Machine outil
Gamme
<<Catgorie>>
<<Catgorie>>
Com
Persistance
<<Catgorie>>
Systme
d'exploitation
Figure 340 : Exemple de diagramme de catgories pour la reprsentation de la structure

gnrale dune application.
La place du logiciel ou le choc des cultures

Selon la part de matriel spcifique construit par lentreprise, une distinction peut
tre opre entre larchitecte du systme et larchitecte du logiciel. Larchitecte du
systme est responsable pour lensemble du systme, le matriel, le logiciel et
lutilisation. Larchitecte du logiciel ne se consacre qu la partie logicielle.
Cette distinction est logique, mais peut se rvler malheureuse lorsque
larchitecte principal ne connat pas assez le logiciel. Un bon architecte doit
connatre la fois le domaine de lapplication et les diffrentes techniques
employes dans la ralisation, dont le logiciel.
Dans les quinze dernires annes, de nombreuses entreprises se sont trouves
confrontes une profonde mutation de leur activit du fait de lintroduction de
linformatique dans leurs produits. Souvent, le choix de larchitecte dpend plus
de sa connaissance du domaine que de sa connaissance de linformatique. Cette
situation est particulirement sensible dans les entreprises qui ont bti une
culture lectromcanique, puis mut vers llectronique ; elles peroivent souvent
linformatique comme un accessoire de plus et non comme le lien intgrateur
quelle devrait tre.
Les diagrammes suivants dcrivent la situation. A lorigine, la part de matriel

tait prdominante ; le mtier de lentreprise tait essentiellement exprim au
travers de ce matriel.
Figure 341 : A lorigine, le savoir-faire de lentreprise est exprim par du matriel.
Petit petit, des lments logiciels ont t rajouts pour contrler, commander ou
rguler. Ces premiers programmes ont dabord t dvelopps en assembleur ; ils
restent trs proches du matriel.
Cette topologie dapplication est la consquence dun manque de vision globale.
Elle se traduit par une absence totale dintgration entre les composants logiciels
et par une duplication de leffort, allant parfois jusqu' des redondances
matrielles. Dans le domaine de lautomobile, les systmes distincts dantipatinage et danti-blocage des roues illustrent bien ce phnomne.
Figure 342 : Des lments logiciels sont rajouts dans le systme, sans concertation.
Le choc culturel a lieu lorsque la tendance sinverse au profit du logiciel, parfois

par ncessit conomique. Il est licite de parler darchitecture logicielle partir du
moment o une dmarche raisonne, unificatrice et intgrante regroupe le logiciel
et le matriel au sein dun cadre cooprant.
Figure 343 : Le choc culturel correspond linversion du cadre intgrant.
Lorsque la mutation est opre totalement, le savoir-faire de lentreprise est

compltement transfr dans le logiciel. Le matriel spcifique nexiste plus, ou
alors est intgr dans larchitecture gnrale du logiciel. Cette mutation a dj t
vcue par des entreprises de CAO ou dimagerie mdicale.
Figure 344 : Aprs mutation, le savoir-faire de lentreprise est exprim dans du logiciel.
Linformatique est un catalyseur. Linformatique sest love dans les matriels,

tant et tant que linformatique a cess dtre secondaire pour devenir principale.
Ceci ne se fait pas toujours sans douleur du fait du profond choc culturel entran
par cette mutation des mtiers. Les personnes de lentreprise qui dtenaient
traditionnellement le savoir du mtier se sentent dpossdes ; elles ragissent,
inconsciemment, en freinant des deux pieds et en essayant de confiner
linformatique dans des tches accessoires. Ce problme est difficile grer car
souvent les personnes qui freinent le plus fort ont suffisamment de pouvoir de
dcision pour imposer leur vision.
Cette attitude conservatrice engendre un dsquilibre dans larchitecture au profit
du matriel : le logiciel est alors sous-employ. Un architecte qui ne possde pas
de vision logicielle conoit des systmes dans lesquels le logiciel est mal intgr
avec le matriel, au lieu de concevoir des systmes dans lesquels le matriel est
bien intgr dans le logiciel. Au-del des habitudes, le problme est li une
mauvaise analyse. Les solutions proposes ne sont pas assez innovantes et se
contentent souvent dinformatiser lexistant.
Cette situation nest pas rserve linformatique technique et se manifeste
galement dans le monde des systmes dinformation des entreprises. Les
processus en place dans lentreprise sont lquivalent des lments matriels
spcifiques dcrits prcdemment ; le savoir-faire de lentreprise est traduit dans
ces processus. Lapproche conservatrice attend et admet de linformatique

lautomatisation de certaines tches, mais seulement au sein de processus dj en
place.
Figure 345 : Informatisation limite dans le cadre dun processus en place dans lentreprise.
La rupture est consomme lorsque linformatisation dpasse le cadre dun

processus donn et recherche lintgration entre plusieurs processus, par
exemple pour changer de linformation. Dans les faits, cela se traduit
gnralement par la dtection dincohrences, de pertes de temps, de
mouvements inutiles. Le choc culturel rsultant est souvent plus intense que
dans le monde technique. Les consquences dune remise plat des processus
dune entreprise touchent plus directement les personnes et leur emploi.
Figure 346 : Intgration des processus dune entreprise dans un cadre informatique global.
Cycle de vie itratif et incrmental

Le cycle de vie itratif repose sur une ide trs simple : lorsquun systme est trop
complexe pour tre compris, conu ou ralis du premier coup, voire les trois la
fois, il vaut mieux le raliser en plusieurs fois par volutions. Dans la nature, les
systmes complexes qui fonctionnent sont toujours des volutions de systmes
plus simples 36.
La mise en uvre de cette ide nest pas aussi simple que cela dans le monde de
linformatique : le logiciel ne se prte pas spontanment lvolution. Au
36
Gall, J. 1986, Systematics : How Systems Really Work and How They Fail. 2nd
ed. Ann Arbor, MI : The General Systematics Press.
contraire, le logiciel se rvle souvent extrmement fragile en face dun

changement ou dune modification. Ceci est directement li la forme interne des
programmes et au couplage qui existe entre les diffrents constituants. Leffet
dune modification locale peut se propager dans lensemble de lapplication et,
la limite, le basculement dun seul bit suffit pour compltement faire scrouler
une application qui fonctionnait correctement auparavant.
Avant de parler de dveloppement par volution, il faut sattacher rendre les
logiciels plus stables et moins enclins leffondrement face lvolution. Le
gnie logiciel nous apprend que pour rendre un programme plus robuste, il faut
segmenter lespace des tats possibles, rduire le couplage au moyen de niveaux
dabstraction et sparer les spcifications des ralisations.
Lapproche objet est btie autour de concepts comme lencapsulation et la
modularit qui encouragent un style de programmation dfensif : par nature, les
programmes objet prsentent une rsistance plus grande face aux changements et
aux surprises. Lapproche objet, de ce point de vue, favorise le dveloppement de
programmes selon une dmarche itrative.
Il faut tre bien conscient que lapproche objet nest pas ncessaire pour mettre
en uvre un dveloppement itratif ; elle nentrane et ne requiert aucun
dveloppement itratif, mais simplement les facilite.
En rsum, lapproche objet nous fournit un cadre confortable pour dvelopper
par volution, de manire itrative.
Cycle de vie linaire

Lexpression cycle de vie linaire dsigne une dmarche de dveloppement de
logiciels, base sur une succession dtapes, depuis le cahier des charges jusqu
la ralisation.
Le modle en tunnel
Le modle de dveloppement en tunnel37 est en fait une manire image de
dsigner labsence de modle de dveloppement. Dans les projets qui suivent la
dmarche en tunnel, il est globalement impossible de savoir ce qui se passe. Le
dveloppement est en cours, les gens travaillent souvent beaucoup mais
aucune information fiable nest disponible, ni sur ltat davancement du logiciel,
ni sur la qualit des lments dj dvelopps. Ce genre de modle de
dveloppement nest adapt que pour les petits efforts, avec un nombre trs
limit de participants.
37
Pierre D., communication prive.
Figure 347 : Modle de dveloppement en tunnel, le processus de dveloppement nest pas

visible.
Le modle en cascade
Le cycle de vie en cascade38, dcrit par Royce ds 1970, a t largement employ
depuis, pour la description gnrale des activits lies au dveloppement de
logiciels.
Le cycle de vie en cascade prsente le dveloppement de logiciel comme une
suite de phases qui senchanent dans un droulement linaire, depuis lanalyse
des besoins jusqu' la livraison du produit au client. Chaque phase correspond
une activit.
Le dveloppement en cascade est rythm par la gnration de documents qui
servent de support tangible pour les revues de validation du passage dune
phase une autre.
Par rapport au modle en tunnel, le modle en cascade prsente lnorme
avantage de fournir des points de mesure concrets, sous la forme de documents ;
il augmente ainsi la visibilit sur ltat davancement du systme en cours de
dveloppement. Le diagramme suivants illustre le gain de visibilit apport par le
modle en cascade.
38
Royce, W. W. Aot 1970, Managing the development of large software

systems. Proceedings of IEEE WESCON.
Figure 348 : Le modle de dveloppement en cascade ouvre des points de visibilit sur le
processus de dveloppement.
Le cycle en cascade est souvent reprsent sous la forme dune lettre V pour faire
apparatre que le dveloppement des tests est effectu de manire synchrone
avec le dveloppement du logiciel. Cette approche permet de tester ce qui devait
tre fait et non ce qui a t fait. Le diagramme suivant montre un exemple de
modle en V, dans lequel les tests fonctionnels sont spcifis lors de lanalyse,
les tests dintgration lors de la conception et les tests unitaires pendant la phase
de codage.
Figure 349 : Exemple de modle de dveloppement en V. Les tests sont dvelopps

paralllement au logiciel.
Limites du modle en cascade

Le modle en cascade repose sur une squence de phases bien cernes. Le projet
produit des documents valus lors de revues censes valider le passage dune
phase une autre. Toutefois, la preuve effective du bon (ou mauvais)
fonctionnement du systme nest ralise que tardivement dans le cycle lors de
la phase dintgration lorsquil est possible dvaluer concrtement le logiciel.
Avant cette phase dintgration, seuls des documents ont t produits. Or, ce
nest pas parce quun document passe avec succs une tape de validation sur
papier que le logiciel quil dcrit donnera forcment des rsultats convaincants.
En fait, la dmarche en cascade ne donne des rsultats satisfaisants que lorsquil
est effectivement possible denchaner les phases sans trop de problmes. Il faut
que lensemble des besoins soit parfaitement connu et le problme compltement
compris par les analystes ; il faut aussi que la solution soit facile dterminer par
les concepteurs et le codage rduit idalement la gnration automatique de
code, partir des documents de conception.
Hlas, les projets ne se prsentent pas tous sous ces conditions idales. Force
est de constater que la part d'inconnu, et donc de risques, peut tre grande dans
certains dveloppements, notamment du fait :
de la mconnaissance des besoins par le client,
de lincomprhension des besoins par le fournisseur,
de linstabilit des besoins, qui dcoule des deux points prcdents,
des choix technologiques,
des mouvements de personnel...
Pour toutes ces raisons, des retours dinformation entre les phases sont
ncessaires pour incorporer des corrections en amont, en fonction des
dcouvertes ralises en aval. Ces retours entre phases perturbent la vision
linaire donne par le cycle de vie en cascade, comme le montre le diagramme
suivant :
Figure 350 : La part dinconnu qui caractrise les systmes complexes se traduit par des
retours dinformation entre phases pour incorporer des corrections.
En fait, les retours entre phases ne sont que le reflet de la ralit. Tant que ces
retours restent marginaux et limits entre phases adjacentes, le modle en cascade
conserve toute sa pertinence. Dans le cas contraire, le modle en cascade nest
plus vraiment adapt. Il devient alors de plus en plus artificiel de considrer le
dveloppement comme un enchanement linaire.
Lorsquun modle ne reprsente plus une ralit, il faut en changer et non essayer
de faire coller la ralit au modle 39.
Caractristiques du cycle de vie itratif

Le cycle de vie itratif est bas sur lvolution de prototypes excutables,
mesurables, et donc sur lvaluation dlments concrets. Il soppose ainsi au
cycle de vie en cascade qui repose sur llaboration de documents. Les livraisons
forcent lquipe donner des rsultats concrets rgulirement, ce qui permet
dviter le syndrome des 90 % finis, avec encore 90 % faire. Le droulement
rgulier des itrations facilite la prise en compte des problmes ; les changements
sont incorpors dans les itrations futures, plutt que de dranger et
dinterrompre leffort en cours.
Au cours du dveloppement, certains prototypes sont montrs aux utilisateurs et
aux clients. La dmonstration des prototypes prsente de nombreux avantages :
lutilisateur est plac devant des situations dutilisation concrtes qui lui
permettent de mieux structurer ses dsirs et de les communiquer lquipe de
dveloppement ;
lutilisateur devient partenaire du projet ; il prend sa part de responsabilit

dans le nouveau systme et, de fait, laccepte plus facilement ;
lquipe de dveloppement est plus fortement motive du fait de la proximit

de lobjectif ;
lintgration des diffrents composants du logiciel est ralise de manire

progressive, durant la construction, sans effet big bang lapproche de la
date de livraison ;
les progrs se mesurent par des programmes dmontrables, plutt que par des
documents ou des estimations comme dans le cycle de vie en cascade.
Lencadrement dispose ainsi dlments objectifs et peut valuer les progrs
et ltat davancement avec plus de fiabilit.
En revanche, le cycle de vie itratif demande plus dattention et dimplication de

lensemble des acteurs du projet. Il doit tre prsent et compris par tous : les
clients, les utilisateurs, les dveloppeurs, lencadrement, lassurance qualit, les
testeurs, les documentalistes. Tous doivent organiser leur travail en
consquence.
Une mini-cascade
Dans le cycle de vie itratif, chaque itration reproduit le cycle de vie en cascade,
une plus petite chelle. Les objectifs dune itration sont tablis en fonction de
39
Kuhn T. S. 1970, The Structure of Scientific Revolutions, 2nd edition. The

University of Chicago Press, Chicago.
lvaluation des itrations prcdentes. Les activits senchanent ensuite dans

une mini-cascade dont la porte est limite par les objectifs de litration.
Figure 351 : Le cycle de vie itratif repasse plusieurs fois par les phases du cycle de vie en
cascade.
Les phases traditionnelles sont couvertes graduellement, itration aprs itration.

La nature des activits menes au sein des phases ne varie pas fondamentalement
selon quil sagit dun dveloppement itratif ou dun dveloppement en cascade.
La diffrence se situe plus dans la distribution de ces activits par rapport aux
phases.
Chaque itration comprend les activits suivantes :
la planification de litration est labore en fonction des rsultats de ltude

de risques ;
lanalyse tudie les cas dutilisation et les scnarios raliser dans

litration ; elle met jour le modle danalyse pour prendre en compte les
nouvelles classes et associations dcouvertes pendant lanalyse de
litration ;
la conception se concentre sur les choix tactiques ncessaires pour raliser

les mcanismes allous litration. Au besoin, des retouches sont apportes
larchitecture et le modle de conception est mis jour. Les procdures de
test sont dfinies paralllement la conception des nouveaux mcanismes ;
le codage et les tests dont la charpente du code est gnre automatiquement

depuis le modle de conception. Le dtail des oprations est ensuite ralis
manuellement. L'intgration du nouveau code avec le code existant, issu des
itrations prcdentes, est ralise graduellement pendant la construction. Les
procdures de tests unitaires et dintgration sont appliques au prototype.
lvaluation de la livraison excutable : lexamen des rsultats des tests sert

de base pour lvaluation du prototype. Les rsultats sont valus par rapport
aux critres dfinis avant de lancer litration.
la prparation de la livraison : le prototype est gel et lensemble des

lments qui sont entrs dans son dveloppement est plac dans des
bibliothques contrles. Les diffrents documents de description et
dinstallation du prototype sont finaliss.
Dans le diagramme suivant, les activits internes se chevauchent pour montrer

quau sein dune itration, elles nont pas besoin de se terminer brutalement et
que la transition entre deux activits peut tre progressive. Le cycle itratif se
distingue ici du cycle en cascade qui effectue un amalgame entre phases et
activits.
Figure 352 : Exemple de transition progressive entre les activits dune itration.
Ides fausses sur le cycle de vie itratif

Le monde est plein de prjugs et dides fausses. Linformatique nchappe pas
cette tendance et, en particulier, le cycle de vie itratif draine dans son sillage
bon nombre de mythes, parmi lesquels :
Le cycle de vie itratif encourage la bidouille.
Le cycle de vie itratif encourage surtout la crativit en mnageant des espaces

de libert, sans rgles trop strictes.
Le cycle de vie itratif engendre des problmes.
Le cycle de vie itratif nengendre pas les problmes : il rvle prcocement des
problmes qui auraient t dtects tardivement avec le cycle en cascade. Le
cycle en cascade semble prvisible : les revues danalyse et de conception se
succdent dans les dlais prvus. Tout va bien jusqu' la phase dintgration o
mille turpitudes sont commises pour livrer quelque chose au client. Le cycle de
vie itratif commence mal et se termine bien, contrairement au cycle de vie en
cascade qui commence bien et se termine mal.
Le cycle de vie itratif et incrmental demande de recommencer n fois

jusqu' ce que le rsultat soit bon.
Le cycle de vie itratif ne demande pas de recommencer ternellement le mme

programme, mais denrichir un programme existant par lajout de nouvelles
fonctionnalits. La confusion vient du fait que certaines parties doivent tre
retouches, prcisment parce quelles comportaient des dfauts dtects par une
itration. Plus tt les problmes sont dtects dans le cycle de dveloppement,
moins ils sont coteux corriger.
Le cycle de vie itratif est une excuse pour ne pas planifier et grer un projet.
Au contraire, le cycle de vie itratif demande plus de planification et une attention

soutenue. La planification nest pas faite au dbut ; elle est rpartie sur
lensemble du dveloppement. Il est facile de faire des plans, il est plus difficile de
les corriger ou den changer.
Le cycle de vie itratif ne concerne que les dveloppeurs.
Il est vrai que les dveloppeurs se sentent laise avec le cycle itratif, mais ce
nest pas parce que les uns sont heureux que les autres en particulier
lencadrement doivent tre malheureux. En effet, le cycle de vie itratif leur
fournit plus de points de mesure que le cycle en cascade et ces mesures sont plus
fiables : elles sont connectes sur la ralit de lvaluation dun prototype, plutt
que sur la virtualit de la lecture dune documentation.
Le cycle de vie itratif encourage rajouter toujours de nouveaux besoins,

sans fin.
Voil une ide fausse dont il faut absolument se dfaire. Lanalyse itrative ne
consiste pas rajouter toujours et encore de nouveaux besoins ; elle permet de se
concentrer dabord sur les besoins majeurs et dincorporer plus tard les besoins
secondaires. Le cycle de vie itratif vite la paralysie par lanalyse.
Stabilit des besoins et cycles de vie

Le cycle de vie itratif est souvent dcri par des informaticiens qui ont souffert
de projets dans lesquels lexpression des besoins des utilisateurs ntait pas
stable. Ces informaticiens sont dautant plus virulents que le cycle de vie itratif
leur apparat comme une perptuelle invitation la surenchre. Ils lopposent par
l au cycle en cascade, dans lequel les phases ont thoriquement une limite bien
dfinie.
Cette crainte lgard du cycle de vie itratif nest pas fonde. Quelle que soit la
forme de cycle de vie, lexplosion des besoins est toujours la consquence dun
mauvais dpart. Il ny a pas tellement de nouveaux besoins, il y a surtout des

besoins sous-estims ou mal identifis.
Le diagramme suivant reprsente le phnomne dexplosion des besoins. Dune
part, les besoins ne sont pas stables, et dautre part, les utilisateurs en rajoutent
toujours de nouveaux.
Figure 353 : Reprsentation du phnomne dexplosion des besoins.
Pour rgler le problme de lexplosion des besoins, il faut imprativement aider (il
faudrait plutt dire forcer) les utilisateurs articuler leurs besoins dans un cadre
stable et structurant. Les cas dutilisation apportent une trs bonne technique
pour ce faire ; leur laboration oblige les utilisateurs imaginer comment ils
comptent utiliser le futur systme. Ceci reste difficile en labsence dlments
concrets critiquer, comme cest le cas avec le cycle en cascade qui, dans ses
premires phases, ne produit que des documents. Le cycle de vie itratif vient au
secours des utilisateurs en leur fournissant des prototypes valuer. Les
informaticiens peuvent de leur ct exprimenter leurs choix de ralisation en
vraie grandeur.
Ds le dbut du dveloppement, un cycle itratif produit des prototypes
documents qui peuvent tre valus objectivement. Il soppose au cycle en
cascade qui ne fournit que des documents. Dans le premier cas, le logiciel est mis
en avant ; dans le second cas, ce sont les sous-produits. A qualit dencadrement
gale, un cycle itratif produit des rsultats plus stables quun cycle linaire.
Le cycle en cascade ne secoue pas assez les utilisateurs ; les documents quil
produit ne procurent quune illusion de progrs ; rien ne dit que leur contenu
satisfait rellement les besoins. Les revues de conception se passent bien, le
projet suit le plan de dveloppement jusqu' la phase dintgration. L, plus rien
ne marche : de nombreuses rparations sont alors effectues dans la prcipitation,
sans recul suffisant, et cela se traduit par des retards et un produit fragile et
difficile maintenir.
Le diagramme suivant reprsente la courbe de connaissance des besoins dans
une approche itrative. Tous les besoins ne sont pas ncessairement connus ds
le dbut ; la connaissance des besoins peut progresser avec les itrations.
Figure 354 : Exemple de progression dans la connaissance des besoins dans le cadre dune
dmarche itrative.
Ladoption de lapproche itrative ne fait pas disparatre tous les problmes par
magie. Lapproche itrative est seulement un outil pour mieux grer les problmes.
There is no silver bullet40
La documentation
Les prototypes sont les principaux produits tangibles issus du cycle de vie
itratif, de sorte quil nest pas ncessaire de fournir des documents pour servir
de support aux revues de validation de fin de phase, comme dans le cycle en
cascade.
Il est nanmoins possible de construire une documentation conventionnelle
lorsque celle-ci est exige par contrat. Cette documentation est constitue de
documents danalyse et de conception par exemple dans le format normalis DoD
2167a.
40
Brooks, F. P. April 1987, No silver bullet, essence and accidents of software

engineering. IEEE Computer.
La documentation nest pas construite en une seule passe, mais graduellement,

lors de chaque itration. A la fin du dveloppement, les documents obtenus de
manire itrative ne se distinguent pas dans leur forme de ceux obtenus de
manire conventionnelle. En revanche, ils restituent une image fidle de ltat final
du projet avec lequel ils ont volu de manire synchrone.
Le diagramme suivant montre que la documentation obtenue graduellement lors
dun dveloppement itratif peut trs bien tre prsente comme issue dun
dveloppement conventionnel. Selon les lecteurs, laspect itratif du
dveloppement gagne tre occult une fois le projet termin.
Figure 355 : La documentation gnre par un dveloppement itratif est semblable dans sa
forme la documentation traditionnelle, mais reflte plus fidlement ltat final du projet.
Variantes du cycle itratif

Il existe plusieurs variantes du cycle itratif selon la taille du projet, la complexit
du domaine et les choix darchitecture.
Dans sa variante la plus simple, la forme du cycle de vie itratif correspond la
lettre b. La forme en b a t identifie par Birrel et Ould 41, qui rservaient litration
uniquement la phase de maintenance.
La forme en b est bien adapte pour des applications de taille modeste ou pour
des applications parfaitement dfinies, ralises dans le cadre dune architecture
prouve qui ne crera pas de surprises.
41
Birrel N. D. et. Ould M. A. 1985, A Practical Handbook for Software

Development. Cambridge University Press, Cambridge, U. K.
Les cycles y sont rapides et lintgration continue, de sorte que le principal

avantage de cette forme itrative, par rapport un cycle en cascade, est de
supprimer leffet big bang dune phase dintgration localise en fin de cycle.
Le diagramme suivant reprsente lenchanement des activits au sein dun cycle
de vie itratif en b. Litration est centre sur la construction.
Figure 356 : Cycle itratif en b. Cette forme de cycle itratif est bien adapte pour les projets
modestes ou bien dfinis.
Le cycle en b concentre les itrations sur la construction. Lorsque tous les

besoins ne sont pas connus ds le dpart, ou pour prendre en compte des
retouches darchitecture, il est frquent de rajouter des boucles de rattrapage sur
ltude dopportunit ou sur llaboration. Le flot principal de litration reste
concentr sur la construction par incrments, les flots secondaires ayant pour
vocation daffiner lanalyse ou larchitecture plutt que de les remettre en cause.
Le diagramme suivant montre comment le cycle en b a tendance souvrir lorsque
des retouches de conception ou danalyse doivent tre apportes suite aux
enseignements recueillis lors de la construction.
Figure 357 : Cycle itratif en b avec quelques retouches sur les activits en amont de la
construction. Litration reste principalement concentre sur la construction.
Le cycle en b est tout fait adapt pour les dveloppements bien circonscrits.
Une grande part d'incertitude sur les besoins est plus grande, une architecture
partiellement dtermine ou un projet men par plusieurs quipes en parallle,

rendent prpondrantes les branches secondaires : la forme du cycle se
rapproche dune lettre en O. Le cycle en O drive du cycle en spirale de Boehm42.
Il a t dcrit par Philippe Kruchten43 et sinspire dune lettre ouverte de Mike
Devlin 44.
Le diagramme suivant reprsente la forme dun cycle de vie en O. Litration
comprend lanalyse et la conception.
Figure 358 : Cycle de vie itratif en O. Cette forme de cycle itratif est bien adapte pour les
grands projets.
Quelle que soit la forme du cycle de vie itratif retenue, il convient de conduire
lanalyse aussi loin que possible, sans tre paralys par la recherche de lanalyse
parfaite. Le cycle itratif, avec son exigence de livraisons rgulires de
programmes excutables, encourage les projets dcoller et produire des
rsultats concrets.
Evaluation des itrations

Les critres dvaluation dune itration doivent tre dfinis avant de commencer
litration. Chaque itration est dcrite par un plan dtaill, lui-mme inclus dans
un plan de dveloppement gnral. Une itration est marque par des tapes
intermdiaires, comme des sances de relecture critique du code. Elles permettent
42
Boehm B. W. May 1988, A Spiral Model of Software Development and

Enhancement. IEEE Computer.
43
Kruchten P. December 1991, Un processus de dveloppement de logiciel

itratif et centr sur larchitecture. Proceedings of the 4th International
Conference on Software Engineering, Toulouse, EC2, Paris.
44
Mike Devlin est co-fondateur et prsident du conseil dadministration de

Rational Software Corporation.
de mesurer les progrs et dentretenir le moral de lquipe qui se concentre sur

des objectifs court terme.
Le diagramme suivant reprsente une itration dun petit projet, dlimite par deux
revues : la premire, pour lancer formellement litration aprs avoir vrifi
lallocation des ressources et la deuxime, pour valider litration et autoriser la
livraison du prototype correspondant.
Figure 359 : Exemple ditration dlimite par deux revues.
Le nombre d'tapes dpend de la longueur de litration. Pour de petites itrations

entre un et trois mois il faut compter environ deux tapes :
la revue de dpart qui fige les objectifs de litration, les critres dvaluation
et la liste des scnarios raliser,
la revue dvaluation qui valide les rsultats de litration par rapport aux
critres dfinis avant de drouler litration.
Pour des itrations plus longues, il faut prvoir plus de revues intermdiaires pour
lapprobation des plans de tests, la mise en place de lassurance qualit, etc.
Les rsultats de litration sont valus par rapport aux critres dvaluation
dfinis lors de la planification de litration. Ils sont fonction des performances,
des capacits et des mesures de qualit. Il faut galement prendre en compte les
ventuels changements externes, comme lapparition de nouveaux besoins ou la
dcouverte des plans de la concurrence, et dterminer sil faut reprendre certaines
parties du systme et les assigner aux itrations restantes.
Figure 360 : Principaux produits et activits de lvaluation dune itration.
Lvaluation est une tape essentielle pour bnficier pleinement de lapproche

itrative. Il faut garder prsent lesprit quil vaut parfois mieux rviser les critres
plutt que modifier le systme. Une itration peut rvler quun besoin particulier
nest pas aussi important que prvu, quil est trop difficile raliser ou trop cher
satisfaire. Dans ce cas, une analyse comparative entre le cot et le bnfice doit
tre mene.
La planification des itrations

Il ny a pas de rponse toute faite. Pour un projet de 18 mois environ, il y aura
entre trois et six itrations. Les itrations ont toutes peu prs la mme dure.
Le diagramme suivant reprsente des exemples dallocation de leffort dans un
dveloppement itratif :
La courbe B correspond une premire itration trop ambitieuse. Le projet B

rencontre les dsagrments du cycle en cascade : lintgration choue, le
dveloppement entre dans une priode dinstabilit et finit par dpasser les
dlais, sans atteindre ses objectifs ou sans respecter ses impratifs de qualit.
La courbe A correspond a un projet qui a consacr les deux premires

itrations la mise en place dune architecture stable, au prix de petites
retouches, et qui connat une volution itrative sans surprises. Le lger
dpassement dachvement reprsente lvolution des besoins qui ont t
pris en compte.
Figure 361 : Illustration de limpact de la planification des itrations sur le droulement du

projet.
La premire itration est la plus difficile conduire car elle demande la mise en
place de lensemble de lenvironnement de dveloppement et de lquipe. Le
projet rencontre gnralement de nombreux problmes avec les outils,
lintgration entre les outils, les relations au sein de lquipe.
Les quipes qui appliquent une approche itrative sont gnralement trop
optimistes. Il faut rester modeste et ne pas attendre trop de la premire itration,
faute de quoi les dlais vont tre dpasss, le nombre ditrations ventuellement
rduit et les bnfices de lapproche itrative limits.
Lquipe perd gnralement pas mal de temps travailler avec le nouveau
compilateur, mettre en place la gestion de versions et de configurations, les
tests de non-rgression et le million dautres choses qui doivent tre rgles lors
de la premire itration. Pour la deuxime itration, tout rentre dans lordre,
chacun sait comment procder avec les outils et lquipe peut se concentrer sur
les fonctionnalits.
Pilotage des projets objet

Pourquoi parler de pilotage des projets objet ? Les projets objet demandent-ils
une forme particulire dencadrement, et inversement, nest-il pas possible de
piloter les projets objet comme les projets classiques ?
En fait oui et non. Ladoption des technologies objet nimplique pas
obligatoirement de revoir les procdures de dveloppement en place. Nanmoins,
il faut tre conscient que le seul moyen de rellement bnficier de lapproche
objet consiste tablir une solution totalement objet.
Cette volution des pratiques de lentreprise exige une adhsion totale des
diffrents intervenants.
Il nexiste pas une forme de processus de dveloppement adapte tous les

projets, tous les domaines dapplication et toutes les cultures dentreprise. Le
processus de dveloppement dcrit dans ce chapitre est dfini de manire
gnrale. Il appartient chaque projet de ladapter en fonction de ses contraintes
propres.
Processus abstrait
Processus du projet A
Processus du projet B
Figure 362 : Il appartient chaque projet dadapter le processus abstrait dcrit de manire
gnrale dans ce paragraphe.
Le processus de dveloppement dun logiciel peut tre observ selon deux points
de vue complmentaires :
la vue de lencadrement qui se proccupe des aspects financiers, stratgiques,

commerciaux et humains,
la vue technique qui se concentre sur lingnierie, le contrle de la qualit et la

mthode de modlisation.
Figure 363 :Points de vue ports sur le processus de dveloppement.
La vue de lencadrement
La vue de lencadrement reprsente le dveloppement du logiciel comme un
enchanement de quatre phases :
ltude dopportunit qui comprend ltude du march, la spcification du

produit final et la dfinition de la porte du projet ;
llaboration qui correspond la spcification des particularits du produit,

la planification des activits, la dtermination des ressources, la
conception et la validation de larchitecture du logiciel ;
la construction qui regroupe la ralisation du produit, ladaptation de la

vision, de larchitecture et des plans, jusqu la livraison du produit ;
la transition qui rassemble la fabrication grande chelle, la formation, le

dploiement dans la communaut des utilisateurs, le support technique et la
maintenance.
Un cycle de dveloppement correspond une passe au travers des quatre phases

et donne une nouvelle gnration du logiciel.
Figure 364 : Dans la vue de lencadrement, le dveloppement dune gnration du logiciel

correspond une passe au travers de quatre phases.
Les progrs sont mesurs en termes davancement dans les phases. Certains
logiciels demandent plusieurs cycles pour prendre en compte des amliorations,
des demandes de nouvelles fonctionnalits, etc. La phase de transition dune
gnration donne recouvre alors souvent la phase dtude dopportunit de la
gnration suivante. Dans le cas de grands projets, les cycles peuvent tre mens
en parallle et plusieurs sous-systmes sont dvelopps indpendamment.
Figure 365 : Dans le cas de grands projets, des dveloppements de sous-systmes peuvent tre
mens en parallle.
La vue technique
La vue technique se concentre sur la mise uvre et lordonnancement de toutes
les activits techniques qui conduisent la livraison dune gnration du logiciel.
Le cycle de dveloppement est peru comme une suite ditrations par lesquelles
le logiciel volue par incrments. Chaque itration dbouche sur la livraison dun
programme excutable. Le contenu dune itration doit tre utile pour le
dveloppement ou pour lutilisateur. Il est dtermin en choisissant un sousensemble des fonctionnalits de lapplication au sein des cas dutilisation.
Certaines livraisons sont purement internes, dautres servent dmontrer ltat
davancement, certaines enfin sont places chez lutilisateur. Ditration en
itration, le programme grandit en fonctionnalit et en qualit, jusqu' ce quune
itration particulire donne la premire gnration du logiciel.
Les activits traditionnelles ne sont pas effectues en squence comme dans un
cycle de vie en cascade ; elles sont distribues saupoudres sur les
diffrentes itrations. Chaque itration comprend des activits de planification,
danalyse, de conception, dimplmentation, de test et dintgration, dont le
nombre varie en fonction de la position de litration dans le cycle.
Le programme excutable qui rsulte dune itration est appel prototype. Un
prototype est une tape concrte de la construction dun logiciel. Il fait la preuve
tangible mesurable des progrs raliss. Un prototype est un sous-ensemble
de lapplication, utile pour la formulation des besoins ou la validation des choix

technologiques. Les prototypes senrichissent chaque itration.
Le premier prototype a souvent pour seul objectif deffectuer la preuve dun
concept dapplication. Il est dvelopp le plus rapidement possible, sans tenir
compte des critres de qualit habituels. Ce genre de prototype, le plus souvent
jetable, est appel maquette.
Les avant-dernires itrations produisent les versions bta, gnralement places
en test chez une slection dutilisateurs bienveillants.
La version livre lutilisateur est un prototype comme les autres, issu de la
chane des prototypes ; elle peut tre vue comme le dernier prototype de la
gnration courante et le premier prototype de la prochaine gnration du
systme.
Figure 366 : Reprsentation de la chane des prototypes.
Intgration des deux points de vue

Les deux points de vue sont synchroniss la fin de chaque phase, sur le rsultat
tangible dune itration.
Ltude dopportunit peut faire appel un prototype pour dterminer la viabilit
dun projet ou sa faisabilit technique. Lvaluation de la maquette excutable,
livre par lquipe de dveloppement, participe la dcision de poursuite ou non
du projet, donne la fin de ltude dopportunit.
La phase dlaboration a pour objectif essentiel de dfinir une architecture qui

permette le dveloppement et lvolution de lapplication. Il est difficile de trouver
une bonne architecture du premier coup, do lintrt deffectuer un certain
nombre de prototypes darchitecture. Llaboration se termine par la dfinition
dune base darchitecture, valide par un prototype darchitecture.
La phase de construction progresse au rythme des prototypes de dveloppement,
dont lobjectif premier est de mesurer les progrs et de garantir la stabilisation de
la conception. La phase de construction se termine par la livraison de versions
prliminaires, les versions bta, qui sont places chez des utilisateurs en vue
dtre testes en vraie grandeur, dans lenvironnement de dploiement.
La phase de transition dbute par linstallation des versions bta sur site. Elle
progresse au rythme des livraisons de versions qui viennent corriger les dfauts
dtects par les utilisateurs. Selon les organisations, la phase de transition
sarrte lorsque le logiciel est arriv sa version de production, ou alors lorsque
la prochaine gnration est livre aux utilisateurs.
Il appartient chaque projet de dterminer le nombre ditrations quil y a dans
chaque phase ; le diagramme suivant donne un exemple typique.
Figure 367 : Les deux points de vue sont synchroniss en fin de phase. La fin dune phase est
marque par la validation dun prototype.
Gestion du risque dans un dveloppement itratif

Toute activit humaine comporte sa part de risques. Le dveloppement de
logiciels nchappe pas cette rgle. Les projets informatiques doivent grer les
grer afin de minimiser leurs consquences.
Lanalyse des risques consiste valuer le projet, la technologie et les
ressources, dans le but de dterminer et de comprendre la nature et lorigine des
risques. Chaque risque est dcrit brivement et les relations entre les risques sont
soulignes. Lvaluation des risques dtermine dans quelle mesure les
consquences dun risque sont acceptables.
Les risques doivent faire lobjet dune description crite, pas ncessairement
dans un formalisme trs pouss. Tous les membres du projet doivent en prendre
connaissance. Les risques doivent tres quantifis, sinon il est impossible de
savoir si les risques ont t limins ou non. Il ne faut jamais laisser traner des
expressions floues dans la documentation, comme : le systme devra tre rapide,
la capacit de la mmoire sera suffisante, etc.
Il existe quatre grandes catgories de risques :
les risques commerciaux : la concurrence peut-elle capturer le march avant

que le produit ne soit prt ? Vaut-il mieux sortir une livraison minimale pour
occuper le terrain ?
les risques financiers : lentreprise dispose-t-elle de capacits financires

suffisantes pour mener le projet son terme ?
les risques techniques : la base technologique est-elle solide et prouve ?
les risques de dveloppement : lquipe est-elle suffisamment exprimente et

matrise-t-elle les technologies mises en uvre ?
Mais avant tout, il faut bien comprendre que le plus grand risque consiste ne
pas savoir o sont les risques. Il faut aussi se mfier des quipes plthoriques et
prendre garde aux chefs de projet qui mesurent leur prestige au nombre de
dveloppeurs sous leur responsabilit. Il ne sert rien davoir beaucoup de
dveloppeurs : il faut avoir les bons et savoir les faire travailler en quipe. La
gestion des risques regroupe toutes les activits requises pour construire un plan
de rduction des risques et pour conduire ce plan terme.
Le plan de rduction des risques dcrit, pour chaque risque identifi :
limportance par rapport au client,
limportance par rapport au dveloppement,
laction entreprise et ses implications conomiques,
le moyen de vrifier que le risque a t supprim ou rduit, et dans quelle

mesure,
les scnarios affects par le risque,
lallocation un prototype.
La rduction du risque pilote les itrations dans le cycle de vie itratif. Chaque
itration a pour objectif dliminer une part du risque global associ au
dveloppement dune application. Le diagramme suivant illustre le mcanisme de
rduction du risque par les itrations. Chaque itration est construite comme un
petit projet, avec pour objectif la rduction dune partie des risques identifis lors
la dfinition du projet.
Figure 368 : Chaque itration est construite comme un petit projet, ddi llimination
dune partie des risques identifis lors de la dfinition du projet.
En suivant lapproche en cascade, la rduction des risques est insignifiante

jusqu' ce que la phase dintgration commence. Les plus grands risques
techniques sont lis larchitecture : performances (vitesse, capacit, prcision),
intgrit des interfaces du systme, qualit du systme (adaptabilit, portabilit).
Ces lments ne peuvent pas tre valus avant qu'une quantit significative de
code ait t dveloppe et intgre. Le diagramme suivant reprsente lallure de la
courbe de dcroissance du risque dans un dveloppement en cascade. Le risque
reste lev pendant la majeure partie du cycle de vie.
Figure 369 : Courbe de dcroissance du risque dans un dveloppement en cascade.
Lapproche itrative identifie et traite les risques plus rapidement dans le cycle de
vie, de sorte que le risque peut tre rduit de manire significative ds la phase
dlaboration. Ditration en itration, les prototypes excutables valident les
choix du projet de manire concrte et mesurable, et le niveau de confiance dans
lapplication augmente. Le diagramme suivant montre la dcroissance plus rapide
du risque dans un dveloppement itratif. La principale diffrence avec le
diagramme prcdent provient de laxe des abscisses, gradu par les multiples
itrations ; elles se concentrent toutes sur la rduction dune part du risque
global.
Figure 370 : Courbe de dcroissance du risque dans un dveloppement itratif.
Chaque itration est base sur la construction dun nombre rduit de scnarios
qui sattaquent dabord aux risques les plus importants et dterminent les classes
et les catgories construire dans litration. Les catgories forment un espace de
travail bien adapt aux dveloppeurs.
Les testeurs utilisent les mmes scnarios pour construire le plan de test et les
procdures de test de litration. A la fin de litration, lvaluation dtermine les
risques qui ont t limins ou rduits. Le plan des prototypes est rvis en
consquence.
Le diagramme suivant montre un exemple de rpartition des risques entre deux
prototypes conscutifs. Il illustre leffet dune itration en terme de rduction de
risque.
Itration
N vers N+1
Prototype N
Prototype N+1
Figure 371 : Une itration a pour objectif la rduction du risque associ une partie de
lapplication. La partition des fonctionnalits de lapplication est ralise selon les cas
dutilisation.
Chaque prototype explore une partie de lapplication dans le but de rduire une
part des risques. Selon la nature des risques tudier, les prototypes senfoncent
plus ou moins profondment dans larchitecture.
Le diagramme suivant reprsente diffrentes sortes de prototypes :
le prototype dIHM, limit linterface utilisateur, est souvent une maquette

construite dans le but daider lutilisateur articuler lexpression de ses
besoins ;
le prototype middleware (une couche logicielle intermdiaire) teste et valide

une couche de logiciel rutilisable, probablement achete lextrieur ;
le prototype technologique vrifie, par exemple, la qualit des encapsulations

du matriel, ou des particularits des systmes dexploitation ;
le prototype fonctionnel traverse toute larchitecture ; il garantit la pertinence

de lensemble des choix stratgiques.
Figure 372 : Exemples de prototypes. Chaque prototype explore une partie de lapplication.
Les prototypes sont enchans une fois que larchitecture a t valide. Chacun
de ces prototypes correspond un ou plusieurs cas dutilisation. A chaque
itration la couverture des besoins augmente.
Le diagramme suivant montre comment quatre prototypes ont t dploys pour
dvelopper une application. Les deux premiers prototypes ont d tre retouchs,
pour corriger larchitecture ou pour prendre en compte de nouveaux besoins.
Figure 373 : Reprsentation de la couverture des besoins, prototype par prototype.
Le dveloppement itratif ne consiste pas recommencer ternellement le mme

travail. Bien quil soit normal de refaire certaines parties 45, la tendance gnrale
est de conserver le rsultat des itrations prcdentes. Le premier prototype est
jetable : do la limite suprieure place 100 % de retouche. Si le systme
reprend du code existant, la quantit de retouches doit tre plus faible. Une fois
45
Brooks, F. P. 1975, The Mythical Man-Month. Addison-Wesley, New York.
que larchitecture est tablie et stabilise, les retouches restent faibles et bien
localises. La somme des retouches des itrations suivantes doit rester infrieure
25 %. Les pourcentages, indiqus dans le graphique suivant, se rapportent
lensemble du systme et pas seulement litration la plus rcente.
Figure 374 : Exemple de lvolution des retouches avec le droulement des prototypes. Une
fois larchitecture valide et stabilise, la somme des retouches reste infrieure 25 % du
total.
Gestion du risque phase par phase

Chaque phase du dveloppement apporte sa contribution la rduction des
risques, avec chaque fois un clairage diffrent :
ltude dopportunit essaie de dlimiter les risques du projet, en

construisant un prototype pour valider les concepts ;
llaboration commence par rduire les risques dincomprhension entre les

utilisateurs et les dveloppeurs : elle dveloppe une vision partage de la
porte du projet et explore des scnarios avec les utilisateurs et les experts du
domaine. Dans un deuxime temps, llaboration valide les choix
darchitecture. Larchitecture est raffine par les itrations suivantes, au
besoin ;
la construction est le sige de la fabrication incrmentale de lapplication.

Lintgration progressive des divers composants supprime les risques de
discordance rencontrs dans les phases ddies spcifiquement
lintgration, en fin de dveloppement en cascade ;
la transition : les risques de prise en main du logiciel sont rduits par le

dploiement graduel de lapplication en phase de transition, et cela dautant
plus lorsque les utilisateurs ont t impliqus ds les phases prcdentes ;
le post-dploiement : la maintenance, corrective ou volutive, est effectue

dans le mme cadre de dveloppement que la construction, par itration et
fabrication de nouveaux prototypes. La maintenance est une volution
normale du produit, similaire la construction. Les risques de dgradation de
larchitecture et de la conception sen trouvent fortement rduits.
Exemples de risques
Tous les projets rencontrent des risques dont le nombre varie selon la taille, la
complexit, le degr de nouveaut du projet et les qualifications de lquipe de
dveloppement.
Certains risques sont frquents, du fait de la navet des participants, des
relations fausses entre client et fournisseur, de linstabilit des besoins, etc.
Les grandes causes dchec des projets sont souvent lies :
dans le cas de trs grands projets, la situation gopolitique bien plus quaux
aspects techniques,
labsence dune relle vision de larchitecture, de sorte que le logiciel nest

pas intgrable,
aux mauvaises relations au sein de lquipe de dveloppement,
labsence de motivation, du fait dchances trop lointaines ou mal dfinies,
au manque de visibilit sur le projet, la fois des dveloppeurs qui ne

peroivent pas limage globale, et de lencadrement qui, sans informations
prcises, pilote dans le brouillard,
un manque de personnel qualifi, suffisamment form aux diverses

technologies mises en uvre,
un excs de personnes dans le projet, principalement dans les grandes

organisations, o le prestige du chef de projet se mesure au nombre de
dveloppeurs placs sous ses ordres,
au manque dimplication de lutilisateur dans le processus de dveloppement,
au manque de soutien de toute lorganisation, provoqu par le manque de

conviction dun groupe donn, comme lassurance qualit ou lencadrement
intermdiaire,
la sous-estimation du budget de la formation et du tutorat, ncessaires

tout projet qui aborde de nouvelles technologies,
la sous-estimation des dlais, ce qui cause souvent la suppression

ditrations intermdiaires, et par suite, le retour aux travers du cycle en
cascade,
la sous-estimation de lampleur du projet, manifeste entre autres par

linstabilit des besoins,
la technologie slectionne, quelquefois par simple effet de mode,
la dpendance par rapport dautres dveloppements, effectus en parallle.
Le tableau suivant rsume les dix principaux risques rcurrents et les actions
entreprendre pour les rduire.
Risque
Impact
Rsolution
Intgration trop complexe
Qualit
Centrage sur larchitecture
Absence de convergence
Cot
Middleware
Dlais
Dveloppement itratif
Qualit
Dveloppement itratif
Cot
Objectifs proches
Dlais
Planification des besoins
Cot
Investissement dans des outils

intgrs
Dmotivation
Environnement de dveloppement
inadapt
Utilisateurs dfavorables
Dlais
Cot
Implication prcoce des utilisateurs
Dlais
Dmonstration de prototypes
Cot
Centrage sur larchitecture
Dlais
Achat de comptences externes
Activits manuelles trop lourdes
Cot
Automatisation par des outils intgrs
Inadquation des composants

rutilisables achets
Dlais
Prototypes
Performances insuffisantes
Qualit
Indpendance par rapport au matriel
Excs de bureaucratie
Dlais
Centrage sur les prototypes, pas sur

la documentation
Fonctions inadaptes
Qualit
Prototypes
Technologie trop complexe
Figure 375 : Rsum des dix principaux risques rcurrents et des actions entreprendre pour
les rduire.
Chaque organisation ou projet devrait dfinir une liste de critres pour dterminer
quelles fonctionnalits doivent tre dveloppes dans une itration donne. Le
tableau suivant dcrit des exemples de critres suffisamment gnraux pour tre
appliqus tous les projets.
Critre
Description
Intrt
Degr de ncessit de llment pour les utilisateurs
Cot de fabrication
Estimation de la difficult de dveloppement de llment par les

dveloppeurs
Nouveaut
Llment est-il totalement inconnu ?
Interfaces ncessaires
De quoi llment a-t-il besoin ?
Politique
Comment sera perue la prsence ou labsence de llment ?
Technologie
Les dveloppeurs matrisent-ils les technologies ncessaires ?
Planification
Llment conditionne-t-il la livraison de prototypes ?
Tremplin
Llment facilite-t-il le dveloppement dautres lments ?
Figure 376 : Exemples de critres dapprciation des risques pour la dtermination des
itrations.
Constitution de lquipe de dveloppement

Il existe quelques rares informaticiens virtuoses, mais quelles que soient les
qualits des individus, il arrive un moment o lampleur de la tche accomplir est
telle que leffort individuel ne suffit plus. Il convient alors de travailler de concert,
de coordonner les efforts et de rechercher la performance collective partir des
capacits moyennes de chacun.
Le choix des personnes qui constituent une quipe de dveloppement dtermine
fortement le droulement du projet. Au-del des aspects techniques, le succs
dun projet dpend en grande partie des facteurs humains. Un bon processus de
dveloppement permet prcisment de retirer la quintessence dune quipe de
dveloppement, de manire reproductible et contrle. Les membres dune quipe
efficace doivent dune part tre complmentaires, et dautre part tre bien
conscients de leur rle dans le processus de dveloppement. Il appartient au chef
de projet de mettre sur pied cette quipe de personnes, puis dentretenir le moral
des troupes pendant lensemble du dveloppement.
De manire gnrale, un processus de dveloppement de logiciel peut se
dcomposer en trois sous-processus :
le dveloppement informatique proprement dit,
la logistique qui pourvoit aux besoins du dveloppement informatique,
linterface avec le reste du monde qui isole le dveloppement des

perturbations externes.
Ivar Jacobson a montr comment les processus des entreprises peuvent se

modliser avec des cas dutilisation46. La figure suivante utilise ce formalisme
pour illustrer les trois sous-processus du dveloppement.
Dveloppement
Informatique
Logistique
Interface
Figure 377 : Exemples de reprsentation des sous-processus du dveloppement dans un

diagramme de cas dutilisation.
Lquipe de dveloppement est organise par rapport aux cas dutilisation dcrits
prcdemment. Les diffrents intervenants sont reprsents par des acteurs qui
interagissent avec les trois cas dutilisation identifis.
Le dveloppement informatique
Le dveloppement informatique est conduit par les trois acteurs suivants :
larchitecte dfinit la forme gnrale du logiciel. Il est galement responsable

de la dfinition et de lordonnancement des itrations ;
les abstractionistes (de langlais abstractionist) identifient les objets et les

mcanismes qui permettront de satisfaire les besoins de lutilisateur ;
les dveloppeurs matrisent les technologies et ralisent les abstractions

identifies par les abstractionistes.
46
Jacobson I., Ericson M., Jacobson A. 1994, The Object Advantage, Business
Process Reengineering with Object Technology. Addison Wesley.
Architecte
Informatique
Abstractionniste
Dveloppeur
Figure 378 : Reprsentation des acteurs du dveloppement informatique proprement dit.
La logistique
La logistique interagit avec les acteurs suivants :
le chef de projet compose lquipe, gre le budget et les personnes, et

coordonne les diverses activits ;
lanalyste est un expert du domaine, charg de comprendre les besoins des

utilisateurs ;
lintgrateur assemble les lments produits par les dveloppeurs, et ce

durant le dveloppement dans le cas dun projet objet ;
le qualiticien value tous les lments produits par le dveloppement et

dirige les tests du systme ;
le documentaliste rdige la documentation destination de lutilisateur ;
ladministrateur-systme gre et entretient le parc matriel utilis par le

projet ;
Loutilleur construit et adapte les outils logiciels qui forment lenvironnement

de dveloppement ;
le bibliothcaire assure larchivage et la prservation de tous les artefacts du

dveloppement et de leurs rgles de production.
Chef de projet
Analyste
Intgrateur
Logistique
Bibliothcaire
Qualiticien
Documentaliste
Administrateur
-systme
Outilleur
Figure 379 : Reprsentation des acteurs de la logistique.
Linterface
Linterface interagit avec les acteurs suivants :
le chef de projet assure linterface entre lquipe de dveloppement et le reste

du monde ;
le chef de produit supervise une ligne de produits ; il coordonne les activits

de marketing, de formation et de support technique ;
le financier contrle lallocation du budget et sa bonne utilisation ;
lutilisateur/client participe des revues de prototypes ;
le support technique rsout ou contourne les problmes rencontrs par les

utilisateurs.
Utilisateurclient
Chef de
produit
Interface
Client
Chef de projet
Support
technique
Financier
Figure 380 : Reprsentation des acteurs de linterface.
Les rles dcrits prcdemment peuvent tre jous par la mme personne. Dans
les petites organisations, il est frquent que le chef de projet remplisse galement
les rles darchitecte et danalyste. De mme, les dveloppeurs et les
abstractionistes sont souvent confondus.
Description dtaille des phases

Ce paragraphe dtaille les diffrentes phases du cycle de dveloppement selon le
point de vue gnral adopt par lencadrement. Les phases apportent une vision
structure dans le temps, bien adapte la gestion des aspects contractuels et
financiers.
Ltude dopportunit
Ltude dopportunit nest gnralement pas mene par les informaticiens, mais
par des spcialistes de ltude des marchs et de lanalyse de la concurrence. Ils
essaient de dterminer si la construction dun nouveau systme ou une
amlioration majeure dun systme existant est conomiquement justifie et
prsente un intrt pour lentreprise.
La premire opration consiste se doter dune vision gnrale du produit afin de
mieux le caractriser et de dgager des lments dapprciation. Cette vision peut
se rsumer par la formule suivante47 :
Vision = Quoi + Pour qui +
Combien
Les diffrentes composantes se dfinissent ainsi :
Quoi exprime les grandes lignes du produit ;
Pour qui dtermine la population cible ;
Combien estime le prix que les acheteurs du produit seront disposs payer.
La vision gnrale du projet est exprime dans un cahier des charges prliminaire,
dans un cahier des non-objectifs qui prcise ce que le projet nest pas, et dans un
argumentaire financier qui donne les premiers lments conomiques, par exemple
en termes destimation du retour sur investissement.
Ces diffrents lments peuvent tre difficiles apprcier en labsence dlments
de mesures tangibles. Cest pourquoi ltude dopportunit se base souvent sur
une analyse prliminaire du domaine (10 20 % des classes). Lorsque les
47
Morel E., communication prive.
incertitudes sur la faisabilit dun projet sont leves, il est frquent de conduire
un prototype conceptuel. Son but premier est de dgager des lments concrets
pour valuer les risques lis aux fonctionnalits attendues, aux performances
requises, la taille ou la complexit du sujet, ou encore ladoption de
nouvelles technologies. A partir de l, le concept du produit est valid ou non.
Ce genre de prototype ne respecte pas les rgles habituelles de dveloppement. Il
recherche avant tout un rsultat rapide, sans insister sur la fiabilit ou la rapidit
dexcution. Cest avant tout une maquette jetable dont le code ne rentre pas
dans lapplication finale. Elle gagne tre ralise dans un environnement de
prototypage rapide, comme Smalltalk. Certaines applications sont dveloppes
intgralement partir du premier prototype. Pour ce faire, des outils de
dveloppement rapide dapplication (RAD) sont utiliss. Cette approche
fonctionne pour des projets modestes, mais ne se prte gure des systmes
plus consquents.
A ce stade, lquipe est constitue dun petit nombre de personnes qui entourent
larchitecte du systme ou larchitecte du logiciel. Elles continueront de participer
au dveloppement du projet.
Par la suite, une fois que la vision du produit est dfinie et que les risques
inhrents au projet ont t identifis dans leurs grandes lignes, ltude
dopportunit essaie destimer le cot du projet et le retour sur investissement.
Lestimation des cots et le retour sur investissement
La dtermination du retour sur investissement est assez difficile effectuer dans
le cas de linformatique, en raison essentiellement de limmatrialit des logiciels
et du manque dlments objectifs pour apprcier a priori leur cot.
Il faut rechercher un quilibre entre la fiabilit de lestimation des cots et le dlai
ncessaire pour produire cette estimation. Lestimation fausse immdiate ou le
cot exact connu la fin du dveloppement ntant pas acceptables, il est
judicieux de dcomposer lestimation en plusieurs tapes, afin de laffiner
progressivement.
La figure suivante reprsente, qualitativement, la prcision de lestimation du cot
dun dveloppement logiciel.
Figure 381 : Evolution de la prcision de lestimation du cot dun projet.
Du fait du faible niveau de visibilit sur les besoins rels et sur la nature des
risques durant ltude dopportunit, il est fort peu raliste dessayer destimer
prcisment les ressources ncessaires au projet.
Nanmoins, cette estimation est frquemment demande par le client. Il faut alors
expliquer celui-ci que la seule manire davoir une bonne ide du cot, cest de
financer une premire tranche jusqu la fin de la phase dlaboration. A la lumire
de linformation rcolte, il pourra dcider de poursuivre ou non leffort de
dveloppement, avant daborder la monte en charge de la phase de construction.
Lapproche objet seule ne permet pas dvaluer le cot final plus rapidement que
les approches traditionnelles. En revanche, associe une dmarche itrative, elle
permet de garantir une dtermination plus prcise de ce cot partir de la phase
dlaboration.
Pour un petit projet, ltude dopportunit est souvent rduite un cahier des
charges. Pour un projet moyen, dune anne environ, ltude dopportunit
fabrication du prototype incluse prend approximativement un mois. Pour un
gros projet, le prototype devient un petit projet part entire, souvent dnomm
dmonstrateur, et passe lui-mme par les diffrentes phases nonces plus haut.
La phase dlaboration
La phase dlaboration commence par lanalyse des besoins et par la modlisation
du domaine. Elle a pour objectif de dfinir les choix darchitecture, dexplorer et de
rduire les risques du projet, et finalement de dfinir un plan complet qui quantifie
les moyens mettre en uvre pour mener bien le dveloppement.
La phase dlaboration est conduite par une quipe restreinte, emmene par
larchitecte logiciel. Elle est constitue dun petit groupe de dveloppeurs et d'un
ou deux experts du domaine ou dutilisateurs. Il est souvent judicieux dadjoindre
un reprsentant de lquipe de test et dassurance qualit, un outilleur
(responsable de la mise en place de lenvironnement de dveloppement) et un

documentaliste (responsable de la rdaction de la documentation).
Activits conduites en phase dlaboration
Lanalyse des besoins est base principalement sur ltude des cas dutilisation,
sans pour autant exclure toutes les autres techniques qui pourraient aider les
utilisateurs articuler puis formuler leurs dsirs.
Les cas dutilisation sont exprims dans la terminologie des utilisateurs, sous une
forme textuelle, loin de tout formalisme informatique. La transition vers une
reprsentation plus informatique est effectue par les analystes. Ils transforment
les cas dutilisation en collaborations entre objets du domaine de lapplication.
Une collaboration reste comprhensible par les utilisateurs. Il faut pralablement
leur expliquer que les objets reprsentent une entit du monde rel, autrement dit
de leur monde, et que ces objets collaborent pour construire les fonctions
reprsentes par les cas dutilisation.
Figure 382 : Exemple de ralisation dun cas dutilisation par une collaboration entre trois
objets.
Au fur et mesure de ltude dtaille des cas dutilisation, le modle du domaine

est mis jour pour prendre en compte les nouvelles classes identifies dans les
collaborations qui servent de support aux diffrentes interactions. Une deuxime
passe danalyse, aprs lanalyse du domaine, recherche des abstractions et des
scnarios plus gnraux. Elle dgage des classes abstraites qui serviront de
spcifications pour lcriture de mcanismes gnriques.
La phase dlaboration donne naissance aux produits suivants :
la description du comportement du systme, exprime sous la forme de cas

dutilisation, le contexte du systme, les acteurs, les scnarios et un modle
des classes du domaine (80 % des classes) ;
une architecture excutable, un document de description de larchitecture et

une rvision de la vision du projet et de la description du risque ;
un plan de dveloppement complet pour lensemble du projet ;
un plan dtaill des itrations, les critres dvaluation et le cahier des charges
de chaque itration et les rsultats de lassurance qualit ;
ventuellement un manuel utilisateur prliminaire.
Pour les projets de taille moyenne, il y a typiquement :
quelques dizaines de cas dutilisation ;
une centaine de scnarios principaux ;
quelques centaines de scnarios secondaires ;
entre 50 et 100 classes dans le domaine.
Conseils pratiques sur llaboration

Nimporte quelle application devrait pouvoir rcuprer suffisamment de
composants rutilisables pour raliser de 10 30 % de son implmentation. Les
frameworks et les solutions cls en main permettent denvisager un taux de
rutilisation de lordre de 60 % pour un mme type dapplication et un mme
domaine.
La dure de la phase dlaboration est donc trs variable. Elle dpend beaucoup
des types dapplication et des choix dinfrastructure. Pour un projet dun an, cette
phase dure entre deux et quatre mois.
Dans tous les cas, il faut imprativement viter la paralysie par lanalyse, cest-dire de perdre trop de temps rechercher une analyse parfaite. Il vaut mieux se
jeter leau (cest--dire passer la conception de larchitecture) lorsquenviron
80 % des scnarios principaux ont t examins.
Lors de ltude des scnarios, il ne faut pas non plus aller trop loin dans les
dtails au risque de senfoncer trop tt dans la conception et par suite de
manquer dabstraction dans les solutions mises en uvre.
La phase de construction
Cette phase a pour objectif de dvelopper un produit logiciel prt pour la
transition dans la communaut des utilisateurs. Dans les cycles itratifs en b, la
phase de construction correspond la mise en uvre effective des itrations.
Certaines itrations sont purement internes, dautres sont galement visibles
lextrieur du projet. Chaque itration produit la livraison dun prototype
excutable.
Un prototype force la fin dune itration et oblige lquipe de dveloppement
fournir un rsultat concret, mesurable. Un prototype est stable et autosuffisant ;
cest une version excutable du systme, conduite comme un petit projet et

accompagne de tous les produits ncessaires pour son exploitation.
La ralisation dune itration regroupe les activits suivantes :
identification des scnarios complter ou reprendre dans litration, en

fonction de ltude des risques et des rsultats de litration prcdente ;
assignation de tches prcises lquipe de dveloppement pour arriver au

bout de litration ;
dfinition des critres dvaluation de chaque itration, des points de contrle

et des dlais ;
rdaction de la documentation pour lutilisateur et de la documentation de

dploiement (notes de livraison, notes dinstallation).
Le flot de livraisons se caractrise par :
une augmentation rgulire des fonctionnalits, mesure par le nombre de

nouveaux scnarios pris en compte par chaque itration ;
une plus grande profondeur, mesure par le degr de ralisation du modle du

domaine et des mcanismes ;
une plus grande stabilit, mesure par la rduction dans les changements
apports aux modles ;
lajustement continu du plan du projet ;
lvaluation de chaque itration, avec les rsultats des tests et de lassurance

qualit.
Avec la monte en charge de la construction, lquipe est au complet. Dans les

grands projets, plusieurs incrments peuvent tre dvelopps en parallle. En
rgle gnrale, 80 % de lquipe travaille au dveloppement dune livraison, alors
que les 20 % restant explorent les nouveaux risques et prparent la mise en
chantier des livraisons suivantes.
Pour un projet modeste, cette phase dure entre 2 et 3 mois ; pour un projet
typique, elle dure entre 6 et 9 mois en moyenne. La dure totale des projets objet
est aujourdhui dune anne, avec une petite quipe de 5 ou 6 dveloppeurs.
Dans le cas de trs gros projets, chaque sous-systme se comporte comme un
projet et possde alors ses propres itrations, au sein dun cycle de vie itratif
en O.
La gestion du changement
Dans un cycle de vie itratif, les artefacts de dveloppement mrissent avec les
itrations. Le projet est donc confront un important problme de gestion de
cohrence, du fait des nombreuses versions de chaque lment. Cette gestion de
la cohrence peut tre assure avec succs et un cot raisonnable uniquement
si des outils de gestion de versions et de configurations sont totalement intgrs

dans le processus de dveloppement.
Dans les projets modestes, la gestion des changements concerne principalement
le code et la documentation. Dans les projets plus ambitieux, il faut se proccuper
de la gestion du changement dans lensemble de lenvironnement de
dveloppement, depuis les versions des logiciels, comme les compilateurs ou les
systmes dexploitation, jusquau matriel lui-mme. Dans les cas extrmes, par
exemple pour certains projets militaires ou aronautiques, lensemble de
lenvironnement de dveloppement (logiciel et matriel) est conserv, sans
aucune modification, pendant toute la dure de vie du systme !
Les principaux types de changements apports au logiciel sont les suivants :
lajout de classe ou de collaboration avec une classe ;
le changement de limplmentation des oprations dune classe ;
le changement de la reprsentation dune classe ;
la rorganisation de la structure de classes ;
le changement de linterface dune classe.
Les trois premiers types de changements sont frquents dans la phase de

construction. Dans les dernires itrations, les deux derniers types indiquent que
la conception nest pas stable.
Avec le temps, les changements doivent tre de plus en plus localiss (du fait de
lencapsulation). Les changements darchitecture sont les plus coteux en terme
de retouches.
Conseils pratiques sur la construction
Chaque livraison donne aux dveloppeurs une satisfaction lie la notion de
travail accompli. Les livraisons constituent des sous-objectifs relativement faciles
atteindre, dans un dlai raisonnable par rapport la dure totale du projet. De ce
fait, le moral de lquipe reste au beau fixe, mme si la dmarche par prototypes
oblige sattaquer aux problmes ds le dpart.
Chaque livraison fournit galement lencadrement un point de contrle objectif
sur ltat davancement du projet. Chaque prototype est un pas en avant vers la
satisfaction des besoins.
Enfin, chaque livraison redonne confiance aux utilisateurs qui reoivent par
lexamen du prototype un retour tangible, dont ils peuvent directement transposer
les bnfices dans leur travail quotidien. Ceci suppose de ne pas jeter une
livraison en pture aux utilisateurs, sans avoir au pralable dfini avec eux la
porte du prototype. Il faut imprativement que les utilisateurs comprennent
quun prototype est une tape, pas un systme complet, sinon les frustrations
peuvent tre grandes.
En cas durgence, il vaut mieux reporter des fonctionnalits que manquer un
rendez-vous avec les utilisateurs. Tout prototype dmontrable, mme incomplet,
augmente le niveau de confiance des utilisateurs, et par suite du client. Il faut
toutefois prendre garde leffet congre qui se caractrise par une accumulation
de fonctionnalits non satisfaites, toujours remises la prochaine livraison. Il faut
essayer de tenir le plan des livraisons car la tendance naturelle est de repousser
les livraisons en raison du retard pris par rapport la ralisation des
fonctionnalits. En repoussant la fin des itrations, et par suite la livraison des
prototypes, le danger est grand de revenir au modle en cascade et de perdre les
avantages de la dmarche itrative.
Les catgories permettent dallouer les responsabilits dans lquipe. Les petits
changements sont pris en compte lintrieur dune classe ou dune catgorie.
Les grands changements demandent la coordination entre les responsables de
chaque catgorie et une remonte de la dcision au niveau de larchitecte. Il est
normal de devoir jeter du code en phase de construction. En revanche, au-del de
25 % de changements cumuls dans les livraisons de construction, larchitecture
doit tre considre comme instable. Linstabilit de larchitecture est
gnralement le signe dune phase dlaboration qui na pas donn une place
suffisante lexprimentation.
La phase de transition
La phase de transition consiste transfrer le logiciel dans la communaut de ses
utilisateurs. Cette phase est dune complexit variable selon le type
dapplication ; elle comprend la fabrication, lexpdition, linstallation, la
formation, le support technique et la maintenance. Lquipe de dveloppement se
rduit un petit groupe de dveloppeurs et testeurs, assists temps partiel par
larchitecte, garant de la cohrence de lensemble, et par un documentaliste
responsable de la mise jour de la documentation. Le relais est pass au
personnel du support technique, ainsi quaux formateurs et aux commerciaux.
En phase de transition, le dveloppement initial est presque termin ; tous les
artefacts ont atteint suffisamment de maturit pour tre distribus largement vers
deux catgories de destinataires : les utilisateurs et les responsables du projet.
Les principaux produits destination des utilisateurs comprennent :
des programmes excutables, les versions bta puis dfinitives ;
les manuels pour lutilisateur ;
la documentation de dploiement et dinstallation.
Les principaux produits destination des responsables du projet regroupent :
les modles rviss ;
les critres dvaluation de chaque itration ;
la description des livraisons ;
les rsultats de lassurance qualit ;
les rsultats de lanalyse post-mortem des performances du projet.
La dure de la phase de transition est trs variable selon le critre de fin de phase.
Si la fin est indique par le client au cours dun processus de recette, la transition
dure au maximum un mois pour un projet dune anne. En revanche, si la fin du
projet correspond la fin de la vie du projet, la transition peut tre beaucoup plus
longue.
Conseils pratiques sur la transition
La difficult de cette phase est inversement proportionnelle la qualit du produit
et au degr de prparation des utilisateurs. Tous les produits ncessitent une
formation. Il ne faut pas ngliger la phase dinstallation du produit ; une
installation difficile peut dcourager les utilisateurs et rduire leur confiance dans
le produit.
Pour un systme de remplacement, beaucoup d'efforts sont ncessaires pour
mettre en place le nouveau systme en parallle avec le systme existant.
Dans certaines organisations, lquipe de maintenance et lquipe de
dveloppement sont nettement dissocies. Cette situation nest pas optimale car
elle engendre une rupture trop nette dans le cycle de dveloppement. Elle induit
surtout un moment de flottement dans le partage des responsabilits, entre les
dveloppeurs initiaux et les dveloppeurs de maintenance. Il est plus judicieux
dassurer un recouvrement entre les deux quipes, en incluant des personnes du
support technique et de la maintenance ds le dbut du projet et en assignant
temps partiel quelques dveloppeurs initiaux dans lquipe de maintenance.
Cycles de dveloppement post-dploiement

Pour la plupart des produits logiciels, le dploiement marque le dbut dune
priode de maintenance et damlioration. Cette priode se caractrise par la
rptition du cycle de dveloppement, de ltude dopportunit jusqu' la
transition. Limportance relative de chacune de ces activits peut changer. Ainsi,
dans un simple cycle de maintenance, il ny a pas normalement dimpact sur
larchitecture, tant que les modifications restent bien encapsules.
Chaque itration dmarre en tablissant une liste de priorits de rparation et en
dsignant les quipes de dveloppement. Elle se termine par la livraison dune
version du systme qui corrige les dfauts identifis prcdemment. La transition
inclut la mise jour de la documentation destination des utilisateurs et la
description des dfauts corrigs.
Conseils pratiques sur le post-dploiement

Il faut imprativement corriger les dfauts afin de satisfaire les attentes lgitimes
des utilisateurs. Il faut essayer en plus de satisfaire leurs nouveaux besoins,
ventuellement au moyen de nouvelles technologies : un logiciel qui nvolue
plus devient sans intrt. Pour ce faire, il faut se focaliser sur la conservation de
lintgrit de larchitecture sinon lentropie prend le dessus : petit petit, le cot
des changements augmente, la conception se complique et la maintenance
devient de plus en plus difficile.
Dans tous les cas, quelles que soient les mesures prises, les rsolutions affiches
et la bonne volont des quipes de dveloppement et de maintenance, il arrivera
un temps ou le logiciel devra tre jet et remplac par un autre. Les logiciels
portent en eux les raisons de leur mort, et leur esprance de vie...
Rpartition des activits par rapport aux phases

Limportance de chaque activit de dveloppement varie dune phase une autre.
Il ny a pas de correspondance directe entre les phases de la vue de
lencadrement et les phases classiques dun cycle en cascade. Au contraire, les
activits comme lanalyse et la conception sont tales sur plusieurs phases de la
vue de lencadrement. Les activits se distribuent sur les cycles et leur dbut et
fin ne correspondent pas aux limites des phases de la vue de lencadrement.
En fait, le point important est la densit dactivit ralise dans chaque phase de
la vue de lencadrement.
Figure 383 : Rpartition typique des activits au sein des phases de la vue de lencadrement.
La figure prcdente montre que :
la planification est effectue tout au long des phases ;
lanalyse est concentre principalement dans la phase dlaboration, bien

quune part danalyse puisse dj tre conduite en phase dtude
dopportunit et que lanalyse soit affine en phase de construction ;
la principale partie de larchitecture est dtermine dans la phase

dlaboration ;
la ralisation (qui comprend galement les tests unitaires) commence en phase

dlaboration (pour les lments darchitecture) et culmine en phase de
construction ;
la maintenance dbute ds que la premire version du logiciel a t dfinie,

gnralement en phase dlaboration ;
les tests et les mesures de qualit se rpartissent sur toutes les phases et
concernent tous les prototypes ;
la gestion des changements (versions et configurations) enregistre lhistoire

de tout le projet.
Il ny pas de phase dintgration proprement dite : lintgration est continue, le

logiciel est intgr par construction.
Effort relatif par activit
Le diagramme suivant illustre une situation typique, reprsentative dun projet
objet moyen (dune anne environ, avec une petite quipe denviron cinq
personnes). Il dcrit une rpartition typique de leffort par rapport aux activits.
Dans le but de rpartir leffort selon les diffrentes activits, les postulats
suivants sont tablis :
la planification inclut les activits de pilotage de projet, les plans de

dveloppement, la mesure des progrs et le contrle des ressources du
projet ;
lanalyse comprend le dveloppement des modles objet, des modles

utilisateurs, la spcification de la vision du projet et la description des critres
dvaluation ;
larchitecture inclut la ralisation des fondements du logiciel, la conception

gnrale de toute lapplication et la construction des mcanismes communs ;
limplmentation regroupe toutes les activits de conception dtaille, le

codage et les tests unitaires ;
la maintenance comprend les changements apports au logiciel, une fois plac

sous gestion de versions et de configurations ;
les tests et lvaluation comprennent les activits ncessaires pour dmontrer

que le logiciel atteint les objectifs fixs et mesurs par les critres ;
la gestion du changement mmorise les tats conscutifs de tous les artefacts

de dveloppement.
Figure 384 : Rpartition typique de leffort par rapport aux activits.
Effort relatif par phase

Leffort est rparti diffremment selon les phases et cette rpartition peut varier
considrablement avec les caractristiques du projet. Le diagramme suivant
montre une situation typique, reprsentative dun projet de taille moyenne. La fin
de la phase de transition est marque par la disponibilit gnrale du produit.
Figure 385 : Rpartition typique de leffort par rapport aux phases.
Pour un cycle de maintenance, les phases dtudes dopportunit et dlaboration

sont considrablement rduites. Lemploi doutils de gnration de code ou de
construction dapplication peut fortement rduire la phase de construction ; dans
certains cas elle peut tre plus courte que les phases dtude dopportunit et
dlaboration mises bout bout.
Points de recouvrement des phases et points de dcision
La fin de chaque phase est marque par une dcision planifie qui correspond
de grandes dcisions dans la conduite des affaires de lentreprise. Pendant la
phase dtude dopportunit, la viabilit conomique et la faisabilit technique du
produit sont tablies. A la fin de ltude dopportunit, la dcision dallouer ou
non des ressources pour llaboration doit tre prise. A la fin de llaboration, un
point de dcision similaire est atteint. En fonction du travail darchitecture dj
ralis et en fonction de lvaluation des risques subsistants, il faut allouer ou
non les ressources pour terminer le produit.
La construction sachve lorsque le produit est suffisamment mr pour que des
utilisateurs puissent sen servir de manire fiable.
La transition se termine soit lorsque le produit est remplac par une nouvelle
gnration, soit lorsque le produit arrive en fin de vie et nest plus utilis.
Paralllement au droulement des phases, la fin de chaque itration apporte un
clairage sur les progrs techniques et la maturit du projet. Lvaluation des
itrations dtermine ltendue des progrs et, dans la foule, entrane les
rvaluations du cot global, de la planification et du contenu du projet.
Le tableau suivant rsume les objectifs et les points de dcisions rapports aux
itrations de la vue technique et aux phases de la vue de lencadrement.
Itration
Phase
Objectif
Itration prliminaire
Etude dopportunit
Comprendre le
problme
Point de dcision
Allouer les
ressources pour
llaboration
Itration
darchitecture
Elaboration
Comprendre la
solution
Itration
darchitecture
Elaboration
Comprendre la
solution
Allouer les
ressources pour la
construction
Itration de
dveloppement
Construction
Raliser la solution
Itration de
dveloppement
Construction
Raliser la solution
Itration de
dveloppement
Construction
Raliser la solution
Livrer le produit
Itration de transition
Transition
Transmettre la
solution
Itration de transition
Transition
Transmettre la
solution
Recette par le client
Figure 386 : Tableau rcapitulatif des objectifs et des points de dcisions rapports aux
itrations et aux phases.
Le tableau suivant rcapitule les tapes, les points de mesure et les rsultats de
chaque phase.
Phase
Etape
Mesure
Rsultat
Etude
dopportunit
Plan marketing
Compltude dun
prototype
Lancement effectif du
projet
Prototype excutable
Risque
Elaboration
Modle des cas

dutilisation
Stabilit
80 % des scnarios
Simplicit
80 % du modle du
domaine
Compltude des
livraisons
Produit complet
Modle du domaine
Architecture
Construction
Prototypes
Plan de dploiement
Taux de dfauts
Documentation
complte
Densit de dfauts
Qualit satisfaisante
Stabilit
Transition
Versions bta
Satisfaction des
utilisateurs
Version dfinitive
Taux de dfauts
Densit de dfauts
Stabilit
Figure 387 : Tableau rcapitulatif des tapes, des points de mesure des rsultats de chaque
phase.
5
Etude de cas :
application de contrle
daccs un btiment
Ce chapitre prsente lutilisation dUML pour la modlisation objet dun systme
de contrle des accs un btiment.
Ltude de cas dcrite dans ce paragraphe est inspire dune application
dploye lESSAIM (Ecole Suprieure des Sciences Appliques pour
lIngnieur Mulhouse).
Le modle de cet exemple ralis avec loutil Rational Rose est disponible sur
le CD-ROM qui accompagne louvrage.
Le processus
Ltude de cas dbute directement par lanalyse des besoins. Les besoins du
systme sont dtermins partir de linformation recueillie durant linterview du
superviseur du futur systme. Ces besoins sont exprims sous la forme de cas
dutilisation, dans un langage trs proche des utilisateurs.
Ltude des cas dutilisation demande de choisir le niveau de granularit des
informations reprsentes dans les interactions ; ce qui pose souvent le problme
du petit rocher ou du gros caillou. Dans lexemple suivant, les cas dutilisation
sont dlibrment considrs comme des lments forte granularit.
Chaque cas dutilisation regroupe plusieurs scnarios dcrits dabord de manire

gnrale, du point de vue de lacteur, puis reprsents de manire plus
informatique afin de permettre une valuation des cots de ralisation de
lapplication.
La structure statique exprime par les relations entre les classes des objets qui
participent aux collaborations est reprsente dans des bauches de
diagrammes de classes, puis finalise dans un diagramme de classes qui
reprsente les abstractions cls du domaine et leurs relations.
Lanalyse de lexistant tudie les caractristiques des lecteurs de badges mis en
uvre et permet de dgager une stratgie pour la ralisation des cas dutilisation.
Lexemple se termine par la description de larchitecture logicielle et matrielle de
lapplication.
Analyse des besoins

Les espaces protger se rpartissent sur 4 niveaux au sein dun btiment dune
surface totale denviron 5 000 m2. Le btiment est divis en cinq zones : deux ailes
de recherche, une aile de travaux pratiques, une aile pour ladministration et un
corps central qui abrite les salles de cours et les deux amphithtres.
Le site accueille environ 500 personnes tous les jours, en majorit des tudiants,
mais aussi des enseignants, des chercheurs, du personnel administratif et
technique, ainsi que de nombreux visiteurs.
Suite la disparition dobjets divers, il a t dcid de restreindre les accs
certaines salles au moyen de portes fermeture automatique. Louverture de
chacune de ces portes est commande par un lecteur de badges plac proximit.
Les badges qui permettent louverture des portes ne sont dlivrs quaux
personnes qui doivent accder aux locaux protgs dans lexercice de leurs
activits. Les droits daccs sont allous entre les groupes de personnes et les
groupes de portes, de sorte quune personne ou une porte doit toujours tre au
moins dans un groupe (le sien).
Un groupe de portes peut contenir des portes disperses dans tout le btiment.
Du point de vue du contrle daccs, seule la notion de groupe de portes est
importante : les chemins et les dplacements ne sont pas contrls. Une porte
donne ne peut appartenir qu un seul groupe de portes.
Une mme personne peut appartenir plusieurs groupes, de sorte que ses droits
daccs correspondent lunion des droits daccs de chacun des groupes qui la
contiennent.
5 Etude de cas 291
La dfinition des droits daccs est effectue en dcrivant pour chaque groupe de
personnes les diffrents groupes de portes qui sont accessibles et sous quelles
contraintes horaires. Les droits daccs sont dcrits dans un calendrier annuel qui
dcrit la situation semaine par semaine. Etant donn la faible variation des droits
dans le temps, un calendrier peut tre initialis au moyen de semaines types qui
dcrivent une configuration de droits donne. Le superviseur peut crer autant de
semaines types quil le dsire. Les changements apports une semaine type
sont automatiquement propags dans tous les calendriers qui utilisent cette
semaine type. Les changements apports directement dans un calendrier, par
exemple pour prendre en compte un jour fri, ne sont pas affects lors de la
modification dune semaine type.
La figure suivante reprsente une semaine type. Les parties en gris
correspondent aux plages horaires pendant lesquelles laccs nest pas autoris.
Lundi
00
01
01
02
...
...
06
07
07
08
08
09
...
...
21
22
22
23
23
24
Mardi
Mercredi
Jeudi
Vendredi
Samedi
Dimanche
Figure 388 : Exemple de semaine type.
Le systme de contrle daccs doit fonctionner de la manire la plus autonome

possible. Un superviseur est responsable de la configuration initiale et de la mise
jour des diffrentes informations de dfinition des groupes de personnes et de
portes. Un gardien dispose dun cran de contrle et est inform des tentatives
de passage infructueuses. Les alarmes sont transmises en temps lgrement
diffr : la mise jour de linformation sur lcran de contrle est effectue toutes
les minutes.
Linterface utilisateur doit aider lutilisateur formuler des requtes correctes. Les
valeurs de paramtres doivent systmatiquement tre lues dans des listes qui
dfinissent le domaine des valeurs correctes.
Description des cas dutilisation

Les cas dutilisation sont dcrits de manire textuelle, agrmente de quelques
diagrammes dinteraction. A ce stade de la modlisation, les interactions
reprsentent les principaux vnements qui se produisent dans le domaine de
lapplication. Plus tard, lors de la conception, ces vnements sont traduits en
messages qui dclenchent des oprations.
Dtermination des cas dutilisation

Lanalyse dbute par la recherche des acteurs (catgories dutilisateurs) du
systme de gestion des accs. Un acteur reprsente un rle jou par une
personne ou par une chose qui interagit avec le systme. Il nest pas toujours
facile de dterminer la limite du systme. Par dfinition, les acteurs sont
lextrieur du systme.
Les acteurs se recrutent parmi les utilisateurs du systme et aussi parmi les
responsables de sa configuration et de sa maintenance. Ils se rpartissent dans
les catgories suivantes :
superviseur,
gardien,
porteur de badge.
Voici leur reprsentation graphique :
Superviseur
Porteur de
badge
Gardien
Figure 389 : Reprsentation des catgories dutilisateurs.
Les acteurs interagissent avec le systme. Ltude des cas dutilisation a pour
objectif de dterminer ce que chaque acteur attend du systme. La dtermination
des besoins est base sur la reprsentation de linteraction entre lacteur et le
systme. Cette approche prsente lavantage de forcer lutilisateur dfinir
prcisment ce quil attend du systme.
5 Etude de cas 293
Un cas dutilisation est une abstraction dune partie du comportement du

systme. Le cas dutilisation est instanci chaque utilisation du systme par une
instance dun acteur.
Aprs interview des utilisateurs, il ressort que les catgories de besoins
fonctionnels des acteurs se dcomposent de la manire suivante :
Acteur
Cas dutilisation
Superviseur
Configuration du systme
Gardien
Exploitation du systme
Utilisateur
Validation dune demande daccs
Figure 390 : Rcapitulatif des cas dutilisation du systme de contrle daccs.
Le diagramme suivant reprsente les cas dutilisation du systme de contrle

daccs.
Superviseur
Configuration
Identification
Contrle d'accs
Porteur de badge
Surveillance
Gardien
Figure 391 : Diagramme des cas dutilisation du systme de contrle daccs.
Configuration
La configuration est dclenche par le superviseur.
Superviseur
Configuration
Figure 392 : Dclenchement de la configuration par le superviseur.
Identification
Le superviseur se connecte au systme et donne son mot de passe.
Le systme vrifie lidentit du superviseur et autorise la connexion.
: Systme
: Superviseur
Login (mot de passe)
Vrification
Autorisatio
Figure 393 : Identification du superviseur.
5 Etude de cas 295
Modification des portes

Le superviseur demande la liste des portes ou des groupes de portes.
Le systme affiche la liste des portes ou des groupes de portes.
Le superviseur choisit une porte ou un groupe de portes.
Le systme affiche les informations suivantes :
ltat (activ / dsactiv),
la dure de la temporisation douverture,
la confidentialit (un seul dedans, les autres dehors).
Le superviseur modifie les informations prcdentes.
Le systme enregistre les informations.
: Systme
: Superviseur
Modification d'une porte
Liste des portes
Choix d'une porte
Informations de la porte
Modification des informations

Information de la porte
Sauvegarde des informations
Figure 394 : Modification des portes.
Modification dune personne

Le superviseur demande la liste des personnes.
Le systme affiche toutes les personnes dj recenses.
Le superviseur choisit une personne.
le nom de la personne,
le prnom de la personne,
le numro de tlphone de la personne,
le numro de son badge,
la liste des groupes auxquels appartient la personne.
: Systme
: Superviseur
Modification d'une personne
Liste des personnes
Choix d'une personne
Informations de la personne
Figure 395 : Modification des personnes.
5 Etude de cas 297
Modification des groupes de personnes

Le superviseur demande la liste des groupes de personnes.
Le systme affiche tous les groupes de personnes dj recenss.
Le superviseur choisit un groupe de personnes.
le nom du groupe,
la liste des membres du groupe,
la liste des accs possibles pour le groupe.
: Systme
: Superviseur
Modification d'un groupe de personnes
Liste des groupes
Choix d'un groupe
Informations du groupe
Figure 396 : Modification des groupes de personnes.
Modification des groupes de portes

Le superviseur demande la liste des groupes de portes.
Le systme affiche tous les groupes de portes dj recenss.
Le superviseur choisit un groupe de portes.
le nom du groupe,
la liste des portes contenues par le groupe,
la liste des accs allous des groupes de personnes.
: Systme
: Superviseur
Modification d'un groupe de portes

Liste des groupes
Choix d'un groupe
Figure 397 : Modification des groupes de portes.
5 Etude de cas 299
Recherche dune personne en fonction dun badge

Le superviseur donne le numro didentification du badge.
Le systme retrouve la personne qui le badge a t allou.
le nom de la personne,
le prnom de la personne,
le numro de tlphone de la personne,
le numro de son badge,
la liste des groupes auxquels appartient la personne.
: Systme
: Superviseur
Recherche d'une personne (badge)
Figure 398 : Recherche dune personne en fonction dun badge.
Recherche des portes franchissables par une personne donne

Le systme affiche la liste des portes franchissables.
Le superviseur choisit une porte.
la dure de la temporisation douverture,
la confidentialit (un seul dedans, les autres dehors),
laccs allou la personne.
: Systme
: Superviseur
Recherche portes franchissables (personne)
Liste de portes
Choix d'une porte
Informations sur la porte
Figure 399 : Recherche des portes franchissables par une personne donne.
Recherche des groupes qui contiennent une personne donne

Le systme affiche la liste des groupes qui contiennent la personne.
: Systme
: Superviseur
Recherche des groupes d'une personne
Liste des personnes
Choix d'une personne
Liste de groupes
Figure 400 : Recherche des groupes qui contiennent une personne donne.
5 Etude de cas 301
Recherche des personnes qui appartiennent un groupe donn

Le systme affiche tous les groupes dj recenss.
Le superviseur choisit un groupe.
Le systme affiche la liste des personnes contenues par le groupe.
: Superviseur
: Systme
Recherche des membres d'un groupe

Liste des groupes
Choix d'un groupe
Liste des membres
Figure 401 : Recherche des personnes qui appartiennent un groupe donn.
Modification des accs dun groupe de personnes un groupe de

portes
Le systme affiche tous les groupes dj recenss.
Le superviseur choisit un groupe.
le nom du groupe,
la liste des personnes appartenant au groupe,
la liste des accs aux groupes de portes.
Le superviseur choisit un accs.

un calendrier ouvert par dfaut sur la semaine courante,
dans le calendrier, les plages horaires autorises.
: Superviseur
: Systme
Modification des accs

Liste des groupes de personnes
Choix d'un groupe de personnes
Informations du groupe de personnes
Choix d'un accs un groupe de portes
Informations sur l'accs
Figure 402 : Modification des accs dun groupe de personnes un groupe de portes.
5 Etude de cas 303
Modification dune semaine type

Le superviseur demande la liste des semaines types.
Le systme affiche toutes les semaines types dj recenses.
Le superviseur choisit une semaine type.
le nom de la semaine,
une description textuelle de la semaine,
les jours de la semaine dcoups en tranches horaires,
heure par heure la validit ou non de laccs.
: Systme
: Superviseur
Modification semaine type

Liste des semaines types
Choix d'une semaine type
Informations sur la semaine type
Informations sur la semaine type
Figure 403 : Modification dune semaine type.
Recherche des droits daccs dune personne pour une porte

donne
Le superviseur demande la liste des personnes et des portes.
Le systme affiche toutes les personnes et portes dj recenses.
Le superviseur choisit une personne et une porte
un calendrier ouvert par dfaut sur la semaine courante,
dans le calendrier, les plages horaires autorises.
: Systme
: Superviseur
Recherche accs une porte (UnePersonne)

Liste des portes
Choix porte
Liste des personnes
Choix personne
Figure 404 : Recherche des droits daccs dune personne pour une porte donne.
Surveillance
La surveillance est dclenche par le gardien.
5 Etude de cas 305
Surveillance
Gardien
Figure 405 : Dclenchement de la surveillance par le gardien.
Identification
Le gardien se connecte au systme et donne son mot de passe.
Le systme vrifie lidentit du gardien et autorise la connexion.
: Systme
: Gardien
Login (mot de passe)
Vrification
Autorisation
Figure 406 : Identification du gardien.
Rapport des vnements

Le gardien spcifie les dates de dbut et de fin de la priode dsire.
Tant que le gardien a envie
Le systme affiche les vnements dans lordre chronologique.
Le gardien slectionne des filtres daffichage.
: Systme
: Gardien
Rapport vnements (Priode)
Loop
Evnements
End loop
Figure 407 : Rapport des vnements.
5 Etude de cas 307
Purge des vnements

Le gardien spcifie les dates de dbut et de fin de la priode purger.
Le systme dtruit les vnements qui correspondent la priode.
: Systme
: Gardien
Purge (Priode)
Destruction des vnements
Figure 408 : Purge des vnements.
Rapport des alarmes

Le gardien spcifie le dlai de rafrachissement (1..60 minutes).
Jusqu' ce que le gardien interrompe la dtection
Le systme affiche rgulirement les nouvelles alarmes.
: Systme
: Superviseur
Rapport alarmes (Priode)
Liste des alarmes
Loop
Delay Priode
End loop
Figure 409 : Rapport des alarmes.
Ouverture manuelle des portes

Le gardien demande la liste des portes.
Le systme affiche la liste des portes.
Le gardien choisit une porte.
la valeur de la confidentialit (une personne est-elle dans la salle ?),
les dix derniers vnements.
Le gardien force louverture de la porte.
Le systme enregistre lvnement.
: Systme
: Gardien

Liste des portes
Choix d'une porte
Informations sur la porte
Ouverture de la porte
Enregistrement de l'vnement
Figure 410 : Ouverture manuelle des portes.
5 Etude de cas 309
Incendie
Le gardien dclenche lalarme incendie.
Le systme ouvre toutes les portes.
: Systme
: Gardien
Incendie
Ouverture de toutes les portes
Figure 411 :Alarme incendie.
Contrle daccs
Le contrle daccs est dclench par le porteur de badge.
Contrle d'accs
Porteur de badge
Figure 412 : Dclenchement du contrle daccs par le porteur de badge.
Autorisation de passage
La personne prsente son badge.
Le systme dtermine si laccs est autoris.
Si laccs est autoris
Le systme commande louverture de la porte.
: Systme
: Porteur de
badge
Prsente son badge
Vrifie les droits d'accs

If Droits corrects
Ouvre la porte
End if
Figure 413 : Autorisation de passage.
Tableau rcapitulatif des cas dutilisation et des scnarios

principaux
Cas dutilisation
Scnarios principaux
Configuration
Identification
Configuration
Configuration
Modification des personnes
Configuration
Configuration
Configuration
5 Etude de cas 311
Cas dutilisation
Scnarios principaux
Configuration
Configuration
Configuration
Configuration

portes
Configuration
Configuration
Affichage des droits daccs dune personne pour une porte donne
Surveillance
Identification
Surveillance
Surveillance
Purge des vnements
Surveillance
Dtection des alarmes
Surveillance
Surveillance
Incendie
Contrle
daccs
Contrles de cohrence
Les contraintes suivantes doivent tre prise en compte par le systme :
chaque lecteur de badges est identifi par une adresse unique,
un lecteur de badges ne peut tre associ qu une seule porte,
une porte doit toujours tre au moins dans son propre groupe,
une personne doit toujours tre au moins dans son propre groupe,
un badge ne peut tre allou qu une seule personne,
les plages horaires dfinies dans une journe ne doivent pas se chevaucher.
Description des collaborations

Les fonctionnalits dcrites par les cas dutilisation sont ralises par des
collaborations dobjets du domaine.
Figure 414 : Ralisation dun cas dutilisation par une collaboration entre objets du
domaine.
La ralisation des collaborations fait intervenir des objets supplmentaires qui

nappartiennent pas au domaine de lapplication mais qui sont ncessaires son
fonctionnement. Ces objets effectuent gnralement linterface entre le systme et
lutilisateur, ou entre le systme et un autre systme. La reprsentation de ces
objets permet dvaluer le cot de lapplication ; il est par exemple frquent de
compter une journe de travail pour la ralisation dun cran et des mcanismes
associs.
La nature particulire des classes de ces objets peut tre signifie au moyen des
strotypes suivants :
<<contrleur>> pour le pilotage et lordonnancement,
<<dispositif>> pour la manipulation du matriel,
<<interface>> pour la traduction dinformation la frontire entre deux

systmes,
<<substitut>> pour la manipulation dobjets externes au systme,
<<vue>> pour la reprsentation des objets du domaine.
Trs souvent, il existe trois lments du modle qui correspondent au mme

lment du monde physique. Cette distinction est en particulier opre dans le
cas des personnes, par lintermdiaire :
des acteurs qui reprsentent les utilisateurs dun systme, vu de lextrieur,
des objets, instances de classes issues de lanalyse du domaine (galement

appels objets mtiers) qui encapsulent les informations dcrivant chaque
utilisateur,
5 Etude de cas 313
des objets dinterface qui permettent de manipuler, lire et modifier les

informations contenues par les objets de la catgorie prcdente.
Le diagramme suivant reprsente cette trilogie de classes dobjets. Lutilisateur

est montr sous la forme dun acteur afin de reprsenter une personne (un
humain) qui interagit avec le systme. Les informations sur cette personne sont
stockes par un substitut et visualises par un objet dune classe dinterface (dit
objet miroir) dont le nom est prfix par la lettre I. Un mme objet dinterface peut
visualiser successivement les caractristiques de diffrentes personnes.
Utilisateur
Systme
<<Vue>>
I_Personne
<<Substitut>>
Personne
Figure 415 : Diffrentes catgories de classes dobjets.
Dans un systme dinformation, les informations qui font foi sont celles
contenues dans le systme. Dans un systme automatis, la vrit est toujours
lextrieur du systme. Dans les deux cas, il importe de bien synchroniser ltat de
la trilogie dobjets.
Les acteurs ninterviennent plus directement dans les collaborations.
Linteraction avec les utilisateurs est exprime sous la forme de messages
envoys et reus par les objets dinterface. Le niveau de granularit de ces objets
est variable, mais en rgle gnrale les mcanismes reprsents en termes dobjets
collaborants vitent daller trop loin dans les dtails de la ralisation de linterface
utilisateur. Il y a deux raisons cela : dune part, faciliter la lecture des
diagrammes, et dautre part, favoriser la rutilisation des objets mtiers.
Linterface est toujours trs dpendante de chaque application. En revanche, les
objets mtiers peuvent souvent tre rutiliss par dautres applications.
Configuration
Identification du superviseur
Dans un premier temps, lacteur peut tre conserv pour reprsenter de manire
compacte linterface utilisateur.
2: LireMotDePasse
1: LireNom
: Login
: Superviseur
3: Vrifier (MotDePasse)
Superviseur : Personne
Figure 416 : Reprsentation dune collaboration entre des objets du domaine et un acteur.
De manire alternative, il est galement possible de crer une classe

LimiteDuSystme et de lemployer en lieu et place de lacteur.
: LimiteDuSystme
2: LireMotDePasse
1: LireNom
: Login
3: Vrifier (MotDePasse)
Figure 417 : Reprsentation globale de linterface utilisateur au moyen dun objet de classe
LimiteDuSystme.
Par la suite, les grandes lignes de linterface utilisateur peuvent tre dcrites au
moyen de classes qui reprsentent les diffrentes fentres. Dans ce cas, le but
nest pas de dcrire de manire prcise les classes graphiques de linterface, mais
plutt de capturer la forme gnrale des interactions et ainsi de quantifier la
charge de travail pour le dveloppement de linterface. La fabrication de
linterface proprement dite est du ressort doutils spcialiss dans la construction
et la gnration automatique des interfaces graphiques.
Par convention, chaque objet du domaine est visualis par un objet dinterface de
mme nom, prfix par la lettre F. Dans le diagramme suivant, lobjet de classe
Login est accessible par lintermdiaire dun objet graphique F_Login.
5 Etude de cas 315
4: Cacher ( )
2: Lire (Nom, MotDePasse)
1: Afficher ( )
: F_Login
: Login
: F_Configuration
5: Afficher ( )
3: Correct ? ( MotDePasse)
Figure 418 : Ralisation de la connexion au systme par une collaboration entre objets.
Le diagramme de collaboration ci-dessus montre des objets instances de quatre

classes diffrentes, divises en deux classes dobjets du domaine et en deux
classes dinterface utilisateur.
Un diagramme de classes prliminaire, compatible avec la collaboration
prcdente, est reprsent ci-dessous. Etant donn ltat peu avanc de la
modlisation, les informations de multiplicit ne sont pas toutes dtermines ce
stade.
F_Login
Login
1
1
F_Configuration
Personne
Figure 419 : Ebauche du diagramme de classes.
Le comportement des objets de la classe Login peut tre dcrit de manire

gnrale par lautomate suivant. Lautomate montre, entre autres, que le systme
ne prcise pas lorigine prcise du rejet dune connexion.
Login
Lecture nom
entry: Invite nom
Nom lu
Lecture mot de passe
entry: Invite mot de passe
Nom ou
mot de
passe
incorrect
Mot de passe lu
Vrification
Nom et mot de passe OK

Connexion
Figure 420 : Description gnrale du comportement des objets de la classe Login.
Les classes dinterface utilisateur drivent toutes les deux dune classe
Fentre qui dfinit les oprations Afficher() et Cacher().
Fentre
Afficher( )
Cacher( )
F_Login
F_Configuration
Figure 421 : Hirarchie des classes dinterface utilisateur.

Le superviseur peut modifier les portes de manire individuelle ou par groupe de
portes. Les deux scnarios suivants correspondent respectivement ces deux
options.
5 Etude de cas 317
1: Modifier les informations

: Superviseur
: Porte
Figure 422 : Modification des informations des portes par le superviseur.
Scnario pour une seule porte

Le diagramme de collaboration suivant reprsente la modification des
informations dune porte.
4: Afficher (Porte slectionne)
: F_Configuration
: F_Porte
1: Afficher ( )
2: Slection ( )
3: Cacher ( )
5: Image ( )
6: Valeur ( )
: Porte
: L_Portes
Figure 423 : Modification des informations dune porte.
Les oprations Image() et Valeur() symbolisent la lecture et lcriture de

ltat de lobjet Porte partir de linterface utilisateur. Lopration Image()
permet un objet dinterface dextraire les informations contenues par un objet du
domaine afin de les montrer aux utilisateurs. Inversement, lopration Valeur()
permet un objet dinterface de transfrer des informations en provenance dun
utilisateur vers un objet du domaine.
Ces oprations sont hrites de la classe abstraite ObjetDuDomaine.
ObjetDuDomaine
Image ()
Valeur ()
Porte
Figure 424 : La classe abstraite ObjetDuDomaine spcifie les oprations Image() et

Valeur() qui permettent la communication avec linterface.
La figure suivante reprsente le diagramme de classes prliminaire qui correspond

au diagramme de collaboration prcdent.
F_Configuration
F_Porte
L_Portes
Porte
Les classes dont le nom est prfix par une lettre L reprsentent des classes
dinterface utilisateur spcialises dans la reprsentation de listes dlments. Ces
classes possdent une opration Slection() qui permet de rcuprer
llment slectionn par lutilisateur dans la liste. Les classes de visualisation de
listes sont galement des fentres, comme le montre le diagramme de classe
suivant :
Fentre
Afficher( )
Cacher( )
Liste
Slection( )
L_Portes
L_Personnes
Figure 426 : Hirarchie des classes de visualisation de listes.
Scnario pour un groupe de portes

Lopration de modification des portes peut galement tre ralise de manire
globale pour un ensemble de portes regroupes dans un groupe de portes.
5 Etude de cas 319

: F_Configuration
: F_GroupeDePortes
1: Afficher ( )
2: Slection ( )
3: Cacher ( )
5: Image ( )
6: Valeur ( )
: GroupeDePortes
: L_GroupeDePortes
Figure 427 : Modification dun groupe de portes.
Le diagramme de classes prcdent est enrichi pour prendre en compte la

manipulation des groupes de portes.
L_Portes
F_Configuration
F_Porte
F_GroupeDePortes
Porte
GroupeDePortes
Modification des personnes

: Superviseur
: Personne
Figure 429 : Modification des informations dune personne.
Diagramme de collaboration
4: Afficher (Personne slectionne)
: F_Configuration
: F_Personne
1: Afficher ( )
2: Slection ( )
3: Cacher ( )
5: Image ( )
6: Valeur ( )
: Personne
: L_Personnes
Figure 430 : Diagramme de collaboration. Modification des informations dune personne.
Ebauche du diagramme de classes

F_Configuration
F_Personne
L_Personnes
Personne

: Superviseur
: Groupe de personnes
: Personne
Figure 432 : Modification des groupes de personnes.
5 Etude de cas 321
4: Afficher (Groupe slectionn)
: F_Configuration
: F_GroupeDePersonnes
1: Afficher ( )
2: Slection ( )
3: Cacher ( )
5: Image ( )
6: Valeur ( )
: GroupeDePersonnes
: L_GroupeDePersonnes
Figure 433 : Diagramme de collaboration.

F_Configuration
F_GroupeDePersonnes
L_Personnes
GroupeDePersonnes

1: Modification des informations
: Superviseur
: Groupe de portes
: Porte
Figure 435 : Modification des groupes de portes.
: F_Configuration
: F_GroupeDePortes
1: Afficher ( )
2: Slection ( )
3: Cacher ( )
5: Image ( )
6: Valeur ( )
: GroupeDePortes
: L_GroupeDePortes

F_Configuration
F_GroupeDePortes
L_Portes
GroupeDePortes

1: Personne ? (Badge)
: Superviseur
2: Lire les informations

: Personne
Figure 438 : Recherche dune personne en fonction dun badge.
5 Etude de cas 323
: Personne
: F_Configuration
2: Existe ? (Badge)
1: Afficher ( )
: GroupeDePersonnes
: F_RecherchePersonne
: Personne
3: Afficher ( )
: F_Personne
4: Image ( )
5: Valeur ( )

F_Configuration
F_RecherchePersonne
GroupeDePersonnes
F_Personne
Personne

1: Choisir une personne
: Personne
2: Choisir un groupe de portes

: Groupe de portes
: Superviseur
: Porte
Figure 441 : Recherche des portes franchissables par une personne donne.
8: Afficher ( )
: F_Configuration
9: Image ( )
10: Valeur ( )
4: ListePortes
3: Cacher ( )
2: Slection ( )
1: Afficher ( )
: L_Personnes
: F_Porte
5: Afficher ( )
6: Slection ( )
7: Cacher ( )
: Porte
: L_Portes
: Personne
: Porte
: GroupeDePortes
5 Etude de cas 325

F_Configuration
F_Porte
Porte
L_Personnes
L_Portes
*
1
GroupeDePortes
Personne
: Personne
: Superviseur
Figure 444 : Recherche des groupes qui contiennent une personne donne.
4: GroupeDePersonnes ( )
: F_Configuration
: Personne
Personne slectionne
1: Afficher ( )
2: Slection ( )
3: Cacher ( )
5: Afficher ( )
: L_Personnes
: GroupeDePersonnes

F_Configuration
Personne
*
GroupeDePersonnes
*
L_Personnes
L_GroupeDePersonnes
5 Etude de cas 327
1: Choisir un groupe
: Superviseur
: Personne
Figure 447 : Recherche des personnes qui appartiennent un groupe donn.
4: Afficher ( )
: F_Configuration
: L_Personnes
1: Afficher ( )
2: Slection ( ) Groupe slectionn
3: Cacher ( )
: GroupeDePersonnes

F_Configuration
L_Personnes
L_GroupeDePersonnes
GroupeDePersonnes
*

portes
1: Choisir un groupe
: Personne
: Superviseur
: Accs
: Calendrier
: Groupe de portes
Figure 450 : Modification des accs dun groupe de personnes un groupe de portes.
5 Etude de cas 329
4: Afficher ( )
5: Accs ( )
: F_GroupeDePersonnes
: F_Configuration
1: Afficher ( )
2: Slection ( )
3: Cacher ( )
Rsultat 2
6: Afficher ( )
: GroupeDePersonnes
9: Afficher ( ) : F_Accs
: F_Calendrier
7: Image ( )
8: Valeur ( )
: Accs
10: Image ( )
11: Valeur ( )
: GroupeDePersonnes
: GroupeDePortes
: Calendrier

F_Configuration
L_GroupeDePersonnes
F_GroupeDePersonnes
F_Accs
F_Calendrier
*
GroupeDePersonnes
Accs
GroupeDePortes
Calendrier
: Semaine type
: Superviseur
Figure 453 : Modification dune semaine type.
4: Afficher ( )
: F_Configuration
3: Cacher ( )
2: Slection ( )
1: Afficher ( )
: L_SemaineType
: F_SemaineType
5: Image ( )
6: Valeur ( )
: Semaine type

F_Configuration
F_SemaineType
L_SemaineType
Semaine type
5 Etude de cas 331
Recherche des droits daccs dune personne pour une porte

donne
: Porte
1: Choisir une porte
: Calendrier
: Superviseur
: Personne
Figure 456 : Recherche des droits daccs dune personne pour une porte donne.
Les liens annots par un numro entre parenthses ont t crs par lopration
dclenche par le message de rang correspondant au numro.
: F_Configuration
3: Cacher ( )
2: Slection ( )
1: Afficher ( )
: L_Portes
4: Afficher ( )
5: Slection ( )
6: Cacher ( )
7: Afficher ( )
(2)
: F_Calendrier
: L_Personnes
(3)
8: Image ( )
9: Valeur ( )
: Porte
: Calendrier
: Personne
: GroupeDePortes
: Accs
: GroupeDePersonnes

F_Configuration
L_Portes
F_Calendrier
L_Personnes
Porte
Calendrier
Personne
*
*
1
GroupeDePortes
*
Accs
GroupeDePersonnes
5 Etude de cas 333
Surveillance
Identification du gardien
2: Login (nom, mot de passe)
: Gardien
Portier
1: Existe ? (nom, mot de passe)
: Utilisateur
Figure 459 : Identification du gardien.
: F_Login
3: Cacher ( )
2: Lire (Nom, MotDePasse)
1: Afficher ( )
: Login
: F_Configuration
4: Afficher ( )
5: Correct ? ( MotDePasse)
Gardien : Personne

F_Login
Login
1
1
F_Configuration
Personne

: Evnement
: Gardien
Figure 462 : Rapport des vnements.
: F_Surveillance
1: Afficher ( )
: L_Evnements
: Evnement
5 Etude de cas 335
F_Surveillance
L_Evnements
Evnement
Purge des vnements
1: Dtruire (priode)
: Evnement
: Gardien
Figure 465 : Purge des vnements.
Diagramme de squence
Linteraction est reprsente ici au moyen dun diagramme de squence qui est
plus expressif quun diagramme de collaboration pour la reprsentation des
structures de contrle.
: F_Surveillance
: F_Purge
: Itrateur
Valeur ( ) :
Evnement
Afficher ( )
Initialiser (Priode )
Fini ( )
Tant que pas
Valeur ( )
Dtruire ( )
Suivant ( )
fin
Figure 466 : Diagramme de squence.
F_Surveillance
F_Purge
Itrateur
Evnement
Rapport des alarmes
* [1 minute] :Lire les information
Alarme : Evnement
: Gardien
Figure 468 : Rapport des alarmes.
5 Etude de cas 337
: F_Configuration
: F_Alarme
1: Afficher ( )
: L_Evnements
2: Image ( )
: Anomalie
F_Configuration
F_Alarme
L_Evnements
Anomalie

Toutes les portes
1: Choisir une porte
: Porte
: Gardien
2: Ouvre la porte
: Porte
Figure 471 : Ouverture manuelle des portes.
4: Afficher ( )
: F_Surveillance
3: Cacher ( )
2: Slection ( )
1: Afficher ( )
: L_Portes
: F_Porte
5: Image ( )
6: Ouvrir ( )
: Porte
5 Etude de cas 339
F_Surveillance
F_Porte
L_Portes
Porte
Incendie
* : Ouvrir les portes
: Porte
: Gardien
Figure 474 : Incendie.
Diagramme de squence
: F_Surveillance
: Porte
Pour toute les portes

Ouvrir ( )
fin
Figure 475 : Diagramme de squence.

F_Surveillance
*
Porte
Contrle daccs
1: Ouvrir (Badge)
Portier
2: Personne ? (Badge)
: Personne
: Porteur de
badge
: Badge
Figure 477 : Autorisation de passage.
5 Etude de cas 341
: Lecteur de badge
4: Vrifier appartenance la liste d'accs

: Badge
1: AccsValide (Badge)
: Porte
: Personne
2: Badge (Badge)
3: ListeAccs ( )
: GroupeDePortes
: Accs
: GroupeDePersonnes
Lecteur de badge
Badge
Porte
Personne
GroupeDePortes
Accs
GroupeDePersonnes
Analyse
Analyse du domaine
Les cas dutilisation segmentent lespace des besoins selon le point de vue dun
acteur la fois. La description donne par les cas dutilisation est purement
fonctionnelle et il convient de prendre garde ne pas embrayer vers une
dcomposition fonctionnelle plutt que vers une dcomposition objet. Les cas
dutilisation doivent tre vus comme des classes de comportement.
UML ralise les cas dutilisation au moyen de collaborations entre objets issus du
domaine de lapplication. Chaque collaboration regroupe un contexte dobjet et
une interaction entre ces objets. Le contexte des objets est exprim de manire
particulire dans les diagrammes de collaboration et de manire gnrale dans les
diagrammes de classes. Ces diagrammes de classes ont t bauchs dans le
paragraphe prcdent.
Le diagramme de classes suivant est obtenu automatiquement (grce loutil
Rose) partir de ces diffrentes bauches.
Lecteur de badges
Adresse
Anti-retour
Site
Temporisation
1
Type d'vnements
Veille
Porte
Numro de porte
1 Numro de salle
*
0..4000
GroupeDePortes
Nom
Badge
Validit
Numro de site
Numro de badge
*
Accs
1
Personne
Prnom
Nom
GroupeDePersonnes
Nom
Figure 480 : Diagramme de classes obtenu par synthse automatique des diffrentes
bauches.
5 Etude de cas 343
Lexamen du diagramme prcdent fait apparatre deux associations redondantes

(entre les classes Personne, Porte et GroupeDePortes) qui peuvent tre
drives dautres associations. Le diagramme suivant fait tat des ajustements
qui ont t apports au modle du domaine.
Lecteur de badges
Adresse
Anti-retour
Site
Temporisation
1
Type d'vnements
Veille
1
Porte
Numro de porte
1 Numro de salle
*
1
0..4000
Badge
Validit
Numro de site
Numro de badge
GroupeDePortes
Nom
*
Accs
Calendrier
*
1
Personne
Prnom
Nom
GroupeDePersonnes
Nom
*
Semaine type
Figure 481 : Diagramme des classes du domaine.
La classe Accs a t transforme en association car elle ne contenait pas

dinformations particulires. Le dtail des droits est exprim dans la classeassociation Calendrier. La relation de composition reprsente les semaines
type qui ont t modifies localement dans un calendrier donn.
Analyse de lexistant
LEssaim dispose dj dun certain nombre de lecteurs de badges et dsire les
rutiliser dans le nouveau systme de contrle daccs. Ces lecteurs de badges
peuvent fonctionner de manire totalement autonome ; ils sont programmables
sur place au moyen de badges particuliers ou distance via une liaison srie.
Tous les lecteurs sont esclaves du systme de contrle : un lecteur nest jamais
lorigine dune interaction.
Caractristiques des lecteurs de badges

Chaque lecteur de badges possde les caractristiques suivantes :
la mmorisation de 4 000 cartes, avec la possibilit dinvalider certaines cartes,
la mmorisation des 100 derniers vnements (un filtre permet denregistrer

uniquement les anomalies),
une adresse sur le rseau (il peut y avoir jusqu' 64 lecteurs connects au
rseau),
une horloge logicielle,
8 plages horaires,
une temporisation de gche,
une fonction anti-retour optionnelle (entre tte principale et tte auxiliaire),
une entre tout-ou-rien connecte au choix un bouton-poussoir, un contact

de porte ou une boucle de dtection,
un tat qui prcise si le lecteur est actif ou en veille.
Horloge
1
Plage horaire
8
Lecteur de badges
Adresse
Anti-retour
1
1 Site
Temporisation
Type d'vnements
1 Veille
1
ToutOuRien
1
Evnement
0..100
1
0..4000
Badge
Figure 482 : Reprsentation des caractristiques des lecteurs de badges.
Mise lheure
Chaque lecteur contient une horloge logicielle. En cas de coupure de courant, le
lecteur enregistre un vnement spcial lors de sa remise sous tension et ne gre
plus les plages horaires. Lhorloge doit alors tre remise lheure par le systme
de contrle pour que le lecteur fonctionne nouveau avec les plages horaires. La
diffrence entre lheure de lhorloge et lheure relle donne la dure de la coupure.
5 Etude de cas 345
Horloge
Jour
Heure
Minute
Figure 483 : Horloge logicielle contenue par les lecteurs de badges.
Gestion des badges

Le lecteur peut mmoriser jusqu' 4000 numros de badge. Ces numros de badge
peuvent tre manipuls par groupes de numros croissants. Le lecteur propose
les oprations suivantes :
validation d'un badge,
validation d'un groupe de badges,
invalidation d'un badge,
invalidation d'un groupe de badges.
Plages horaires
Une plage horaire est associe chaque badge ou groupe de badges. Un lecteur
contient la description de 8 plages horaires. Une plage horaire permet de
restreindre les accs en fonction du jour et de l'heure de prsentation du badge.
Les 7 premires plages sont configurables par le superviseur, la dernire plage est
le passe tout temps. Chaque plage horaire comporte 3 sous-plages qui ne doivent
pas se recouvrir.
Les plages se prsentent de la manire suivante :
Sous-plage
LU
MA
ME
JE
VE
SA
DI
00:00-00:00
00:00-00:00
00:00-00:00
Figure 484 : Plage horaire.
Le diagramme de classes correspondant prend la forme suivante :
SousPlage
PlageHoraire
Dbut
3 Fin
Jour
1
Droit
Figure 485 : Reprsentation des plages horaires.
Evnements
Les vnements sont mmoriss suivant les critres de paramtrage (tous les
vnements ou seulement les anomalies). Chaque lecteur peut enregistrer au
maximum 100 vnements entre 2 interrogations provenant du systme matre.
Aprs interrogation les vnements sont effacs. La mmoire du lecteur est
organise sous la forme dun tampon circulaire. Les plus vieux vnements sont
effacs en cas de dbordement de la mmoire.
Chaque vnement contient les informations suivantes :
la date,
le numro de badge,
la tte concerne (principale ou auxiliaire).
Evnement
Date
Numro de carte
Tte
Figure 486 : Description des vnements.
Le lecteur enregistre les vnements suivants :
carte accepte,
coupure secteur,
carte refuse lecteur en veille,
carte refuse hors plage,
5 Etude de cas 347
carte refuse mauvais code site,
carte refuse carte non programme,
carte refuse dfaut anti-retour,
carte refuse mauvaise plage horaire.
Ces types dvnements sont reprsents dans le diagramme suivant :
Evnement
Anomalie
Coupure secteur
Anti-retour
Hors plage
Carte refuse
Lecteur en veille
Normal
Carte accepte
Mauvais site
Non programme
Figure 487 : Hirarchie des types dvnements.
Types de messages
La communication entre les lecteurs de badges et le systme matre est effectue
par des messages issus des trois grandes catgories suivantes :
les messages simples qui contiennent un entte mais pas de donnes,
les messages qui contiennent des donnes de longueur fixe,
les messages qui contiennent des donnes de longueur variable.
Ces types de messages sont reprsents dans le diagramme suivant :
Message
Simple
Fixe
Variable
Figure 488 : Diffrentes catgories de messages.
Messages simples
Les messages simples regroupent des messages de synchronisation, des
requtes de rapport et des commandes.
Message
Simple
Synchronisation
Requte
Commande simple
Figure 489 : Reprsentation des types de messages simples.
Messages reus par le lecteur :
acquittement,
non acquittement,
requte vnements,
requte rglage paramtres,
requte cartes valides,
requte cartes invalides,
requte horloge,
requte code site,
commande mise en veille,
5 Etude de cas 349
commande sortie du mode veille,
commande ouverture porte.
Synchronisation
Acquittement
Non acquittement
Figure 490 : Reprsentation des types de messages de synchronisation.
Requte
Req_Evnements
Req_CartesValides
Req_Paramtres
Req_Horloge
Req_CartesInvalides
Req_CodeSite
Figure 491 : Reprsentation des types de requtes simples.
Commande simple
Cmd_MiseEnVeille
Cmd_FinVeille
Cmd_OuverturePorte
Figure 492 : Reprsentation des types de commandes simples.
Messages de longueur fixe
Message
Longueur fixe
Commande fixe
Rapport fixe
Figure 493 : Reprsentation des types de messages de longueur fixe.
Messages reus par le lecteur :
commande rglage paramtres,
commande validation d'une carte,
commande validation d'un groupe de cartes,
commande invalidation d'une carte,
commande invalidation d'un groupe de cartes,
commande mise l'heure,
commande transmission d'une plage horaire,
commande envoi du code site.
5 Etude de cas 351
Commande fixe
Cmd_Paramtres
Cmd_ValidationCarte
Cmd_ValidationGroupe
Cmd_InvalidationCarte
Cmd_InvalidationGroupe
Cmd_Horloge
Cmd_PlageHoraire
Cmd_CodeSite
Figure 494 : Reprsentation des types de commandes fixes.
Messages envoys par le lecteur :
rapport rglage paramtres,
rapport horloge,
rapport d'une plage horaire du lecteur spcifi,
rapport code site.
Rapport fixe
Rpt_Paramtres
Rpt_Horloge
Rpt_PlageHoraire
Rpt_CodeSite
Figure 495 : Reprsentation des types de rapports fixes.
Messages de longueur variable
Message
Longueur variable
Rapport variable
Figure 496 : Reprsentation du type messages de longueur variable.
Messages envoys par le lecteur :
rapport vnement,
rapport cartes valides,
rapport cartes invalides.
5 Etude de cas 353
Rapport variable
Rpt_Evnements
Rpt_CartesValides
Rpt_CartesInvalides
Figure 497 : Reprsentation des types de rapports de longueur variable.
Structure des trames

Les messages sont encapsuls par des trames qui contiennent des informations
dadressage et de vrification de la transmission.
Chaque trame prend la forme suivante :
Dbut
Adresse
Check-sum
Donnes
Fin
1 octet
1 octet
2 octets
0..n octets
2 octets
01H
00H .. 3FH
F1H F2H
Figure 498 : Forme gnrale des trames de transmission.
La classe des trames offre les oprations Image() et Valeur() pour le

transfert des trames. Lopration Image() transforme un objet trame en une
suite doctets susceptible dtre transmise via la liaison srie qui relie les lecteurs
de badges et les PC. Inversement, lopration Valeur() reconstruit un objet
trame partir dune suite doctets en provenance dun des lecteurs de badges.
Trame
Dbut : Byte : = 01H
Adresse : Byte
Somme1 : Byte
Somme2 : Byte
Fin1 : Byte : = F1H
Fin2 : Byte : = F2H
Donne
* Valeur : Byte
{Ordonne}
Image( )
Valeur( )
Figure 499 : Reprsentation de la classe des trames.
Le comportement de lopration Valeur() est dcrit par lautomate suivant :

Octet lu
Attente trame
Prfixe lu
Attente longueur
Longueur lue
Octet lu[ Cpt < Longueur ]
Suffixe lu[ Cpt = Longueur ]
Figure 500 : Reprsentation du comportement de lopration Valeur().
Architecture
Architecture logicielle
Ces lecteurs de badges peuvent tre reprsents par un acteur. Dans le
diagramme suivant, le lecteur de badges est reprsent par une classe strotype
pour insister sur le fait quil sagit dune classe de dispositifs matriels et non de
personnes.
Superviseur
Lecteur de badge
<<Acteur>>
Porteur de
badge
Gardien
Figure 501 : Reprsentation des acteurs.
5 Etude de cas 355
Le matriel utilis permet de dporter le cas dutilisation du contrle daccs vers

les lecteurs de badges. Selon le point de vue retenu, le lecteur de badges se
comporte comme un acteur pour le systme de contrle daccs dans son
ensemble ou comme un systme indpendant avec lequel interagit le porteur de
badge.
Lecteur de badges
Contrle d'accs
Porteur de badge
Figure 502 : Le cas dutilisation du contrle des accs est dport vers les lecteurs de badges.
Du point de vue global, les lecteurs de badges apparaissent comme un acteur au

mme titre que le superviseur et le gardien. Le systme est constitu de deux
sous-systme distincts. Dune part le logiciel spcifique dvelopper (pour
excution sur les PC) et dautre part le systme cl en main, livr avec les lecteurs
de badges.
Lecteur de badges
Superviseur
<<Acteur>>
Configuration
Identification
Contrle d'accs
Porteur de badge
Surveillance
Gardien
Figure 503 : Reprsentation dfinitive des cas dutilisation.
La structure de la vue logique prend la forme suivante. Les objets mtiers sont
regroups dans un paquetage Domaine. Les composants miroirs de ces objets
du domaine sont contenus dans le paquetage IHM. La couche la plus basse
comprend une catgorie Persistance qui encapsule une base de donne, un

paquetage Machine virtuelle qui isole lapplication des particularits du
matriel et un paquetage Lecteur physique contenant des classes qui
permettent la manipulation des lecteurs de badges et qui encapsulent toute la
complexit de la communication.
IHM
Domaine
Utilitaires
global
Persistance
Lecteur
physique
Machine
virtuelle
Figure 504 : Structure de la vue logique.
Architecture matrielle
Le systme est constitu dlments logiciels et matriels, interchangeables dans
une large mesure.
Les lecteurs de badges sont interconnects au moyen dun rseau spcifique,
indpendant de lIntranet. Le poste de travail du superviseur et la station de
contrle du gardien sont galement connects ce rseau ddi au contrle
daccs. Il peut y avoir jusqu' 64 lecteurs de badges connects au rseau.
5 Etude de cas 357
PC
superviseur
PC
gardien
{1}
{1}
1
<<RS422>>
1
Prcdent
Lecteur de
badges
<<RS422>>
1
{64}
1
Suivant
<<RS422>>
Figure 505 : Architecture matrielle.
Ralisation
Cette tude de cas a pour objectif de prsenter la modlisation objet avec UML,
de sorte que la ralisation nest pas dcrite ici en dtail. Les grandes tapes de la
ralisation comprennent :
la gnration automatique du schma de la base de donnes partir des

classes du domaine dsignes comme persistantes,
la gnration des crans par un constructeur dinterfaces graphiques,
la ralisation manuelle des interactions partir des diagrammes de

collaboration.
Annexes
A1
Les lments standard
Les strotypes, les tiquettes et les contraintes sont les mcanismes mis la
disposition de l'utilisateur pour l'extension d'UML.
Strotypes prdfinis
Les strotypes prdfinis par UML sont prsents par ordre alphabtique dans
le tableau suivant. Les trois colonnes contiennent respectivement le nom du
strotype, llment de modlisation auquel il sapplique et la description
dtaille de sa smantique.
Nom
Sujet
Smantique
acteur
type
abstraction externe au systme en cours de

modlisation
ami
dpendance
extension de la visibilit d'un paquetage au contenu

d'un autre paquetage
appel
dpendance
opration qui appelle une autre opration
application
composant
composant qui reprsente un programme excutable
besoin
note
note qui exprime un besoin ou une obligation
bibliothque
composant
composant qui reprsente une bibliothque statique

ou dynamique
contrainte
note
transforme une note en contrainte
copie
dpendance
copie profonde d'une instance dans une autre
Nom
Sujet
Smantique
drive
dpendance
la source est drive de la cible
devient
dpendance
transformation des caractristiques d'une mme

instance
document
composant
composant qui reprsente un document
numration
type primitif
ensemble d'identificateurs qui forment le domaine de

valeur d'un type
envoi
dpendance
relation de dpendance entre une opration et un

signal envoy par l'opration
tend
gnralisation
le cas d'utilisation source tend le comportement du

cas d'utilisation cible
faade
paquetage
paquetage qui ne fait que rfrencer des lments
fichier
composant
composant qui reprsente un fichier source
flot
classe active
classe active qui reprsente un flot de contrle lger

(thread)
import
dpendance
rend la partie publique d'un paquetage visible un

autre paquetage
instance
dpendance
relation entre une instance et son type
interface
type
vue d'un type
liaison
dpendance
relation de dpendance entre un type instanci ou

une collaboration et un type modle ou une
collaboration modle
collaboration
mtaclasse
dpendance
type
relation de dpendance entre un type et sa

mtaclasse
page
composant
composant qui reprsente une page web
powertype
dpendance
relation de dpendance entre une gnralisation et un

type dont les instances sont les sous-types qui
participent la gnralisation
type
processus
classe active
classe active qui reprsente un flot de contrle lourd
raffinement
dpendance
la source drive de la cible et ajoute de l'information
rle
dpendance
dpendance entre un type et un rle d'association
signal
classe
classe qui reprsente un vnement
souche
paquetage
paquetage entirement transfr
sous-classe
gnralisation
le sous-type hrite de la structure et du comportement

du super-type, sans tre un type du super-type
sous-type
gnralisation
le sous-type hrite de la structure et du comportement
A1 Les lments standard 363
Nom
Sujet
Smantique
du super-type, et devient un type du super-type
table
composant
composant qui reprsente une table de base de

donnes
trace
dpendance
relation de dpendance entre lments de modles

diffrents
utilise
dpendance
le cas dutilisation source utilise le comportement du

cas dutilisation cible
utilitaire
type
type non instanciable qui regroupe des oprations et

des attributs
Etiquettes prdfinies
Les tiquettes prdfinies par UML sont prsentes par ordre alphabtique dans
le tableau suivant. Les quatre colonnes contiennent respectivement le nom de
ltiquette, le domaine de dfinition de sa valeur, llment de modlisation auquel
elle sapplique et la description dtaille de sa smantique.
Nom
Valeur
Sujet
Smantique
documentation
chane
lment
commentaire, description ou
explication
invariant
non interprt
type
prdicat qui doit tre toujours vrai

pour toutes les instances du type
localisation
composant
lment de
assignation de la ralisation d'un

lment de modlisation dans un
composant
modlisation
nud
composant
assignation d'un composant sur

un nud
numration
type
permanence de l'tat
{transitoire,
persistant}
instance
post-condition
non interprt
opration
prdicat qui doit tre vrai aprs

l'invocation d'une opration
pr-condition
non interprt
opration
prdicat qui doit tre vrai avant

l'invocation d'une opration
responsabilit
chane
type
obligation lie un type
smantique
non interprt
type
spcification de la smantique
persistance
attribut
opration
smantique
spatiale
non interprt
smantique
temporelle
non interprt
type
opration
type
opration
spcification de la complexit
spatiale
spcification de la complexit
temporelle
A1 Les lments standard 365
Contraintes prdfinies
Les contraintes prdfinies par UML sont prsentes par ordre alphabtique dans
le tableau suivant. Les trois colonnes contiennent respectivement le nom de la
contrainte, llment de modlisation auquel elle sapplique et la description
dtaille de sa smantique.
Nom
Sujet
association
rle de lien
l'instance correspondante est visible par une

association
chevauchement
gnralisation
les instances peuvent avoir plusieurs types parmi

les sous-types
complte
gnralisation
tous les sous-types ont t spcifis
diffusion
message
l'ordre d'invocation des messages n'est pas

spcifi
disjointe
gnralisation
les instances n'ont qu'un seul type parmi les

sous-types
global
rle de lien
l'instance correspondante est visible, car place

dans une porte globale
implicite
association
l'association n'est pas manifeste, mais

conceptuelle
incomplte
gnralisation
tous les sous-types n'ont pas t spcifis
local
rle de lien
l'instance correspondante est visible, car elle est

une variable locale d'une opration
ordonne
rle d'association
la collection, reprsente par l'association, est

ordonne
ou
association
associations mutuellement exclusives
paramtre
rle de lien
l'instance correspondante est visible, car elle est

paramtre d'une opration
self
rle de lien
l'instance correspondante est visible car elle

participe la distribution du message
vote
collection de
messages
la valeur de retour est choisie par vote majoritaire

parmi les valeurs retournes par la collection de
messages
inclusif
exclusif
Smantique
A2
Guide de transition de
Booch et OMT vers UML
Ce guide a pour objectif de faciliter la transition des utilisateurs des notations de
Booch93 ou OMT-2 vers la notation UML.
Les notations de Booch, OMT et UML fournissent trois vues diffrentes de
concepts objet trs proches. En fait, les notations de Booch et OMT pourraient
tre utilises pour reprsenter une grande partie des lments de modlisation
dfinis dans le mtamodle dUML.
Graphiquement, UML est plus proche dOMT que de Booch, car les icnes en
forme de nuage ont t abandonnes au profit de rectangles plus faciles
dessiner. Au-del des aspects graphiques, UML peut tre considre comme un
sur-ensemble des deux autres notations.
Figure 506 : UML est un sur-ensemble de Booch et OMT.
Les tableaux qui suivent illustrent les diffrences de notations concernant les
principaux concepts objet.
Les mcanismes de base

Contraintes
Dans les trois notations, les contraintes se reprsentent par des expressions entre
accolades.
Booch
OMT
UML
Texte entre accolades
{Ceci est une contrainte}
Notes
En Booch et en UML, les notes se reprsentent par des rectangles, avec un coin
repli. En OMT, les notes se reprsentent comme les contraintes.
En Booch le coin bas-gauche est repli, alors quen UML, le coin haut-droit est
repli.
Booch
OMT
UML
Ceci est
une note
texte entre accolades
Ceci est
une note
{Ceci est une note}
Catgories
En Booch et en OMT, les catgories font partie des lments de modlisation. En
UML, les catgories se ralisent par strotypage des paquetages.
Booch
OMT
Catgorie
Catgorie
UML
<<Catgorie>>
Paquetage
Sous-systmes
En Booch et en OMT, les sous-systmes font partie des lments de
modlisation. En UML, les sous-systmes se ralisent par strotypage des
paquetages.
A2 Guide de transition de Booch et OMT vers UML 369
Booch
OMT
Sous-systme
Sous-systme
UML
<<Sous-systme>>
Paquetage
Les objets
En Booch, les objets se reprsentent par des nuages. En OMT, comme en UML,
les objets se reprsentent par des rectangles. En UML, le nom des objets est
soulign.
Booch
OMT
UML
Nom :
Classe
Nom : Classe
Nom : Classe
Les liens
Dans les trois notations, les liens se reprsentent par une ligne continue, trace
entre les objets.
Booch
:A
OMT
:B
:A
UML
:B
:A
:B
Spcification de ralisation
Booch et UML permettent de prciser la construction retenue pour la ralisation
dun lien, au moyen dun petit carr plac sur le rle. Le symbole plac dans le
carr indique la nature du lien. Un carr noir indique une ralisation par valeur, un
carr blanc indique une ralisation par rfrence.
OMT ne propose pas dattribut graphique particulier, en dehors des contraintes.
Booch
OMT
UML
A association
F membre (field)
F membre (field)
G global
G global
L local
L local
P paramtre
P paramtre
S self
Les messages
Dans les trois notations, les messages se reprsentent au moyen de flches
places proximit des liens.
La forme de synchronisation de lenvoi de message est symbolise par une forme
de flche particulire.
Booch
OMT
UML
Strotypage pour les

autres formes de
synchronisation
Ordre denvoi
Lordre denvoi est reprsent dans les trois notations par une expression place
en tte du message.
Booch
Notation dcimale
OMT
Notation dcimale pointe
UML
Notation dcimale pointe
modifie
caractre flot
chiffre tape dans un
flot
* itration
Flots de donnes
Booch et UML permettent de reprsenter les flots de donnes paralllement aux
flots de contrle (les messages), au moyen de petits cercles accols une flche
dirige dans le sens du flot de donnes. Cette notation est optionnelle, car
redondante avec la reprsentation des paramtres des messages.
Booch
OMT
UML
Par les paramtres des

messages
Les classes
En Booch, les classes se reprsentent par des nuages pointills. En OMT, comme
en UML, les classes se reprsentent par des rectangles.
Classe simple
Booch
Une
classe
OMT
UML
Une classe
Une classe
Attributs et oprations
Dans les trois notations, les attributs et les oprations sont reprsents au sein
de licne de la classe. Certains attributs et certaines oprations peuvent tre
masqus pour ne pas surcharger les diagrammes.
OMT et UML proposent des compartiments pour distinguer les attributs des
oprations.
Booch
OMT
UML
Une classe
Une classe
Attribut
Opration( )
Une classe
Attribut
Attribut
Opration( )
Opration( )
Visibilit
Les trois notations proposent les niveaux public, protg et priv, avec la mme
smantique que celle du langage C++. Booch possde en plus un niveau
implmentation.
Booch
OMT
UML
rien non spcifi

rien public
+ public
+ public
| protg
# protg
# protg
|| priv
- priv
- priv
$ classe
soulign classe
||| implmentation
Mtaclasse classe
A
A
Attribut public
| Attribut protg
|| Attribut priv
Opration publique( )
| Opration protge( )
|| Opration prive( )
+Attribut public
#Attribut protg
-Attribut priv
+Attribut public
#Attribut protg
-Attribut priv
#Opration protge( )
-Opration prive( )
#Opration protge( )
-Opration prive( )
Classe abstraite
En Booch, les classes abstraites sont dsignes par un petit triangle qui contient
la lettre A. En OMT, une classe abstraite possde une multiplicit de valeur nulle.
En UML, le nom des classes abstraites figure en italique.
Booch
OMT
UML
Classe
abstraite
Classe abstraite
0
Classe abstraite
Classe utilitaire
En Booch et en UML, une classe utilitaire se reprsente comme une classe simple,
avec en plus une bordure grise. OMT ne propose pas dattribut graphique
particulier, en dehors des contraintes.
Booch
OMT
UML
Classe
utilitaire
Classe utilitaire
{utilitaire}
Classe utilitaire
<<Utilitaire>>
Classe utilitaire
Classe paramtrable
Booch et UML proposent une notation spciale, drive de la reprsentation des
classes simples, avec en plus un petit rectangle pointill qui contient les
paramtres formels. OMT suffixe le nom des classes paramtrables par les
paramtres formels.
Booch
Param
Classe
paramtrable
OMT
Classe paramtrable
<Param>
UML
Param
Classe paramtrable
Classe paramtre
Linstanciation dune classe paramtrable donne une classe paramtre. Booch
propose une icne spciale, avec un rectangle en trait continu ; le paramtre
effectif peut tre reprsent au moyen dune relation dutilisation. OMT et UML
reprsentent les classes paramtres au moyen dune classe simple en suffixant le
nom de la classe par les valeurs des paramtres effectifs.
Booch
Classe
paramtre
OMT
UML
Classe paramtre
<Paramtre effectif>
Classe paramtre
<Paramtre effectif>
Mtaclasse
Booch reprsente une mtaclasse au moyen dune classe grise. OMT ne
possde pas dattribut graphique particulier, en dehors des contraintes. UML
strotype une classe simple pour obtenir une mtaclasse.
Booch
Mtaclasse
OMT
UML
Mtaclasse
<<Mtaclasse>>
{Mtaclasse}
Mtaclasse
Les relations
Association
Dans les trois notations, les associations se reprsentent par une ligne continue,
trace entre les classes qui participent lassociation.
Booch
A
OMT
B
UML
Rle
Dans les trois notations, les noms de rles sont placs prs des extrmits des
relations.
Booch
A
Rle
OMT
B
UML
Rle
Rle
Multiplicit
Booch et UML sont identiques, part pour la valeur illimite qui se reprsente par
N en Booch et * en UML. OMT propose une reprsentation graphique base de
cercles. Il faut faire attention ne pas confondre ces cercles avec ceux des
relation has et use de Booch, car il ny aucun rapport entre les deux
reprsentations.
Booch
OMT
1 par dfaut
0..N
0..1
N
UML
0..1
1
0..1
*
3..5
3..5, 7, 15
3..5, 7, 15
1+
3..N
3..*
Restriction
La restriction dune association se reprsente en Booch au moyen dune
condition entre crochets. En OMT et en UML, une restriction se reprsente au
moyen dun compartiment rectangulaire.
La cl se reprsente du ct source en OMT et UML, et du ct destination en
Booch.
Booch
OMT
B
UML
B
Cl
Cl
[Cl]
Classe-association
Dans les trois notations, une classe-association se reprsente au moyen dune
classe relie une association.
Booch
OMT
B
UML
B
C
C
C
Agrgation
Il ny a pas dquivalence stricte entre Booch dune part, et OMT et UML dautre
part.
Du point de vue des agrgations, Booch est plus proche de la conception, OMT
est plus proche de lanalyse, et UML couvre la fois lanalyse et la conception.
Le tableau suivant reprsente les deux situations les plus courantes : lagrgation
par rfrence et lagrgation par valeur (la composition en UML). Il faut noter que
dans le cas dOMT, la vue graphique ne distingue pas la forme dagrgation.
Booch
OMT
UML
Dpendance
Booch reprsente la dpendance au moyen dune association dcore dun petit
cercle, plac du ct client. OMT reprsente la dpendance au moyen dune
flche en pointill, tte pleine. UML reprsente la dpendance au moyen dune
flche en pointill, tte ouverte. En OMT et en UML, la flche dsigne le
fournisseur.
Booch
OMT
UML
Hritage
Dans les trois notations, lhritage se reprsente au moyen dune flche qui
pointe de la sous-classe vers la super-classe.
Booch
A
OMT
UML
Instanciation de Mtaclasse
Booch emploie une flche grise pour reprsenter la relation ente une classe et sa
mtaclasse. OMT ne prvoit pas de notation particulire, en dehors des
contraintes. UML strotype une relation de dpendance.
Booch
OMT
UML
<<Mtaclasse>>
Mta A
Mta A
Mta A
{mtaclasse}
<<Mtaclasse>>
Instanciation de gnrique
Booch propose une flche pointille pour reprsenter la relation entre les classes
paramtres et les classes paramtrables. OMT emploie une relation de
dpendance. UML strotype une relation de dpendance.
Booch
OMT
UML
<<Liaison>>
<>
<>
Construction drive
Les associations et les attributs drivs sont prfixs par le caractre / en OMT
comme en UML. Cette notion nexiste pas en Booch.
Booch
OMT
UML
A3
Gnration de code C++
Les exemples de code qui suivent ont t gnrs automatiquement par loutil
Rational Rose 4.0, partir de modles UML. Ces exemples nillustrent pas
lensemble des capacits de gnration de code de Rose, mais dcrivent les
grandes lignes des correspondances entre UML et le langage C++.
Classe
Classe vide
Le gnrateur de code a t configur pour gnrer un constructeur, un
constructeur par copie, un destructeur, un oprateur daffectation et deux
oprateurs dgalit.
Ces oprations ne sont pas reprsentes dans les paragraphes suivants, afin de
ne pas surcharger les exemples.
#ifndef A_h
#define A_h 1
class A
{
public:
//## Constructors (generated)
A();
A(const A &right);
//## Destructor (generated)
~A();
//## Assignment Operation (generated)
const A & operator=(const A &right);
//## Equality Operations (generated)
int operator==(const A &right) const;
int operator!=(const A &right) const;
};
#endif
Classe avec attributs et oprations
A
A1 : String
A2 : String
Op1( )
Op2( )
class A
{
public:
...
//## Other Operations (specified)
void Op1();
void Op2();
const String get_A1() const;
void set_A1(const String value);
const String get_A2() const;
void set_A2(const String value);
private:
String A1;
String A2;
};
inline const String A::get_A1() const
{
return A1;
}
inline void A::set_A1(const String value)
{
A1 = value;
}
inline const String A::get_A2() const
{
A3 Gnration de code C++ 383
return A2;
}
inline void A::set_A2(const String value)
{
A2 = value;
}
Classe paramtrable
Att
template <argtype Att>

class D
{
public:
D();
D(const D<Att> &right);
~D();
const D<Att> & operator=(const D<Att>
&right);
int operator==(const D<Att> &right) const;
int operator!=(const D<Att> &right) const;
...
};
Classe utilitaire
Toutes les oprations dune classe utilitaire sont prfixes par le mot-cl
static.
F
Op1( )
Op2( )
class F
{
public:
static void Op1();
static void Op2();
};
Association
Association 1 vers 1
Le gnrateur de code ralise lassociation par des pointeurs placs dans les
parties prives des classes qui participent lassociation.
A
Ra
1
...
class A
{
...
Rb
...
class B
{
...
const B * get_Rb() const;

void set_Rb(B *const value);
const A * get_Ra() const;

void set_Ra(A *const value);
private:
B *Rb;
};
private:
A *Ra;
};
inline const B * A::get_Rb() const

{
return Rb;
}
inline const A * B::get_Ra() const

{
return Ra;
}
inline void A::set_Rb(B *const

value)
{
Rb = value;
}
inline void B::set_Ra(A *const

value)
{
Ra = value;
}
Association N vers 1
A
Ra
0..*
Rb
parties prives des classes qui participent lassociation. La multiplicit 0..*
est ralise par un ensemble de taille non contrainte.
...
class B
{
...
const UnboundedSetByReference<A> get_Ra() const;
void set_Ra(const UnboundedSetByReference<A> value);
private:
UnboundedSetByReference<A> Ra;
};
inline const UnboundedSetByReference<A> B::get_Ra() const
{
return Ra;
}
inline void B::set_Ra(const UnboundedSetByReference<A> value)
{
Ra = value;
}
Association N vers 1 avec une contrainte

parties prives des classes qui participent lassociation. Du fait de la contrainte
{Ordered}, la multiplicit 0..* est ralise par une liste de taille non
contrainte.
Ra
0..*
{Ordered}
Rb
...
class B
{
...
const UnboundedListByReference<A> get_Ra() const;
void set_Ra(const UnboundedListByReference<A> value);
private:
UnboundedListByReference<A> Ra;
};
Classe-association
B
1
class A; class B;
class C
{
...
const B * get_the_B() const;
void set_the_B(B *const value);
const A * get_the_A() const;
void set_the_A(A *const
value);
private:
A *the_A;
B *the_B;
};
#include "C.h"
class A
{
...
const C * get_the_C() const;
void set_the_C(C *const value);
#include "C.h"
class B
{
...
const C * get_the_C() const;
void set_the_C(C *const value);
private:
C *the_C;
};
private:
C *the_C;
};
Classe-association N vers N
B
0..*
0..*
#include "C.h"
class B
{
...
const UnboundedSetByReference<C> get_the_C() const;
void set_the_C(const UnboundedSetByReference<C> value);
private:
UnboundedSetByReference<C> the_C;
};
Agrgation
Agrgation 1 vers 1
A
Ra
1
B
1
#include "B.h"
class A
{
...
#include "A.h"
class B
{
...
private:
B *the_B;
};
private:
A *Ra;
};
Agrgation navigabilit restreinte
Ra
1
class A
{
...
private:
};
B
1
#include "A.h"
class B
{
...
private:
A *Ra;
};
Agrgation par valeur
Ra
1
B
1
#include "B.h"
class A
{
...
#include "A.h"
class B
{
...
const A get_Ra() const;
void set_Ra(const A value);
private:
B *the_B;
};
private:
A Ra;
};
Agrgation par valeur 1 vers N
Ra
0..*
#include "A.h"
class B
B
1
{
...
const UnboundedSetByValue<A> get_Ra() const;
void set_Ra(const UnboundedSetByValue<A> value);
private:
UnboundedSetByValue<A> Ra;
};
Hritage
Hritage simple
#include "A.h"
class B : public A
{
...
};
Hritage multiple
A1
A2
#include "A1.h"
#include "A2.h"
class B : public A2, public A1
{
...
};
A4
Gnration de code Java
grandes lignes des correspondances entre UML et le langage Java.
Classe
Classe vide
Le gnrateur de code a t configur pour gnrer un constructeur et un
destructeur. Ces oprations ne sont pas reprsentes dans les paragraphes
suivants, afin de ne pas surcharger les exemples.
A
public final class A {

public A() {
super();
...
}
protected void finalize() throws Throwable {
super.finalize();
...
}
...
}

public final class A {
A
A1 : String
A2 : String
private String m_A1;

private String m_A2;
Op1( )
Op2( )
public void Op1() {

...
}
public void Op2() {
...
}
Classe abstraite
public abstract class A {
...
}
Interface
public interface I_A {
...
}
<<Interface>>
I_A
Association
A
Ra
1
public class A {
Rb
public class B {
public B m_Rb;
}
public A m_Ra;
}
A4 Gnration de code Java 393
Ra
Rb
-Ra
*
Rb
public class B {
public class B {
public Vector m_Ra = new

Vector();
private Vector m_Ra = new

Vector();
Lorsque la multiplicit est limite lassociation est ralise par un tableau.
-Ra
Rb
public class B {
private A[] m_Ra = new A[5];

}
Agrgation
Agrgation 1 vers 1
Ra
1
public class A {
B
1
public class B {
public B m_B;
}
public A m_Ra;
}
Ra
1
public class A {
...
}
B
1
public class B {
public A m_Ra;
}
Hritage
Hritage simple
public class B extends A {

...
}
Hritage entre interfaces

<<Interface>>
I_A
<<Interface>>
I_C
public interface I_C extends I_A {

...
}
<<Interface>>
I_B
<<Interface>>
I_A
<<Interface>>
I_C
public interface I_C extends I_A, I_B

{
...
}
A4 Gnration de code Java 395
Ralisation dune interface par une classe abstraite

<<Interface>>
I_A
public abstract class A implements

I_A {
...
}
Ralisation dune interface par une classe

<<Interface>>
I_A
public class A implements I_A {

...
}
Ralisation de plusieurs interfaces par une classe

<<Interface>>
I_B
<<Interface>>
I_A
public class A implements I_A, I_B {

...
}
A5
Gnration de code IDL
grandes lignes des correspondances entre UML et le langage IDL.
Classe
Classe vide
Une classe est traduite en interface IDL.
A
interface A {
...
};

A
A1 : String
A2 : String
Op1( )
Op2( )
interface A {
attribute String Att1;
attribute String Att2;
void Op1();
void Op2();
};
Association
Ra
interface A {
Rb
interface B {
attribute B Rb;
attribute A Ra;
};
};
Ra
Rb
interface B {
attribute sequence<A> Ra;

};
-Ra
Rb
interface B {
attribute sequence<A,5> Ra;

};
Agrgation
Agrgation 1 vers 1
A
Ra
1
B
1
A6 Gnration de code IDL 399
interface A {
interface B {
attribute B the_B;
attribute A Ra;
};
};
Ra
1
interface A {
B
1
interface B {
};
attribute A Ra;
};
Hritage
Hritage simple
interface B : A {
};
Hritage multiple
A1
A2
interface B : A1, A2 {
};
A6
Gnration de code
Visual Basic
grandes lignes des correspondances entre UML et le langage Visual Basic.
Classe
Classe vide
Option Base 0
Private Sub Class_Initialize()
End Sub
Private Sub Class_Terminate()
End Sub

A
Option Base 0
A1 : String
A2 : String
Public A1 As String
Op1( )
Op2( )
Public A2 As String
End Sub
End Sub
Public Sub Op1()
On Error GoTo Op1Err
...
Exit Sub
Op1Err:
Call RaiseError(MyUnhandledError, "A:Op1
Method")
End Sub
Public Property Get Op2() As Boolean
On Error GoTo Op2Err
...
Exit Property
Op2Err:
Call RaiseError(MyUnhandledError, "A:Op2
Property")
End Property
Classe utilitaire
F
Op1( )
Op2( )
Option Base 0
End Sub
End Sub
A6 Gnration de code Visual Basic 403
Public Sub Op1()

End Sub
Public Property Get Op2() As Boolean
End Property
Association
Ra
Rb
Option Base 0
Option Base 0
Public Rb As B
Public Ra As A

End Sub

End Sub

End Sub

End Sub
A
Ra
*
Rb
Option Base 0
Option Base 0
Public Rb As B
Public Ra As Collection

End Sub

End Sub

End Sub

End Sub
Hritage
Hritage simple
A
Op1()
Option Base 0
Implements A
Op2()
'local superclass object (generated)

Private mAObject As New A
End Sub
End Sub
Public Sub Op2()
End Sub
Private Sub A_Op1()
mAObject.Op1
End Sub
A7
Gnration de code SQL
grandes lignes des correspondances entre UML et le langage SQL ANSI.
Pour une discussion dtaille sur la gnration de code SQL partir dun
diagramme de classes et les diffrentes stratgies possibles, voir le chapitre 17 du
livre Object-Oriented Modeling and Design48.
Classe
Classe vide
A
CREATE TABLE T_A (

A_Id NUMBER (5),
PRIMARY KEY (A_Id)
)
48
Rumbaugh J., Blaha M., Premerlani W., Eddy F., Lorensen W. 1991, ObjectOriented Modeling and Design. Prentice Hall.

Le gnrateur construit la structure statique, les oprations sont ignores.
A
A1 : String
A2 : String
Op1( )
Op2( )
CREATE TABLE T_A (

A_Id NUMBER (5),
Att1 VARCHAR (),
Att2 VARCHAR (),
PRIMARY KEY (A_Id)
)
Association
Ra
Rb
CREATE TABLE T_B (

B_Id NUMBER (5),
PRIMARY KEY (B_Id)
)
CREATE TABLE T_A (
A_Id NUMBER (5),
B_Id NUMBER (5) REFERENCES T_B (B_Id),
PRIMARY KEY (A_Id)
)
A
Ra
*
CREATE TABLE T_B (

B_Id NUMBER (5),
Rb
1
A7 Gnration de code SQL 407
PRIMARY KEY (B_Id)

)
CREATE TABLE T_A (
B_Id NUMBER (5) REFERENCES T_B (B_Id),
A_Id NUMBER (5),
PRIMARY KEY(A_Id)
)
Classe-association N vers N
A
B
0..*
0..*
C
CREATE TABLE T_A (
A_Id NUMBER (5),
PRIMARY KEY (A_Id)
)
CREATE TABLE T_B(
B_Id NUMBER (5),
PRIMARY KEY (B_Id)
)
CREATE TABLE T_C (
A_Id NUMBER (5) REFERENCES T_A (A_Id) ON DELETE CASCADE,
B_Id NUMBER (5) REFERENCES T_B (B_Id) ON DELETE CASCADE,
PRIMARY KEY(A_Id, B_Id)
)
Hritage
Dans les exemples suivants chaque classe est ralise par une table. Lidentit
dun objet est prserve dans la hirarchie de classes par lemploi dun identifiant
partag.
Hritage simple
A
B
CREATE TABLE T_A(
A_Id NUMBER(5),
PRIMARY KEY(A_Id)
)
CREATE TABLE T_B(
A_Id NUMBER (5) REFERENCES T_A (A_Id),
PRIMARY KEY(A_Id))
)
Hritage multiple
A1
A2
CREATE TABLE T_A1(

A1_Id NUMBER(5),
PRIMARY KEY(A1_Id))
CREATE TABLE T_A2(
A2_Id NUMBER(5),
PRIMARY KEY(A2_Id)
)
CREATE TABLE T_B(
A1_Id NUMBER (5) REFERENCES T_A1 (A1_Id),
A2_Id NUMBER (5) REFERENCES T_A2 (A2_Id),
PRIMARY KEY(A1_Id ,A2_Id)
)
Glossaire
Abstraction
Facult des humains de se concentrer sur lessentiel et doublier

les dtails. Parfois employ comme synonyme de classe.
Abstraite
Se dit dune classe qui ne peut pas tre instancie directement.
Acteur
1) Classe de personnes ou de systmes qui interagissent avec un

systme.
2) Objet toujours lorigine dune interaction.
Action
Opration excute instantanment lors dune transition dun

tat vers un autre tat. Une action ne peut pas tre interrompue.
Activit
Opration excute au sein dun tat. Une activit est

interruptible.
Agent
Objet qui peut tre origine et destination dune interaction.
Agrgation
Forme dassociation non symtrique qui exprime un couplage

fort et une relation de subordination.
Algorithme
Enchanement des actions ncessaires une tche.
Analyse
Dtermination du quoi et du quoi faire dune application.
Analyse des besoins
Dtermination des besoins des utilisateurs.
Analyse du domaine
Partie de lanalyse qui se concentre sur lenvironnement de

lapplication.
Anctre
Synonyme de super-classe.
Application
Systme logiciel labor dans un but prcis.
Architecte
Spcialiste de larchitecture.
Architecture
1) Art de construire ; en informatique, art de construire les

logiciels.
2) Structure dun logiciel.
Artefact
Elment dinformation, produit ou consomm par une des

activits lors du dveloppement dun logiciel.
Association
Relation entre classes qui dcrit un ensemble de liens.
Association drive
Association dduite dautres associations.
Asynchrone
Forme de communication non bloquante et sans accus de

rception.
Attribut
Information contenue par un objet.
Attribut de lien
Attribut appartenant un lien entre objets, plutt quaux objets

eux-mmes.
Attribut driv
Attribut dduit dautres attributs.
Automate
Forme de reprsentation abstraite du comportement.
Big bang
Se dit de la technique dintgration lorsquelle est concentre en

fin de dveloppement.
Cardinalit
Nombre dlments dans une collection.
Cas dutilisation
Technique dlaboration des besoins fonctionnels, selon le point

de vue dune catgorie dutilisateurs.
Catgorie
Sorte de paquetage de la vue logique ; une catgorie encapsule

des classes.
Classe
Description abstraite dun ensemble dobjets ; ralisation dun

type.
Classe abstraite
Classe qui ne sinstancie pas directement et qui sert uniquement

de spcification.
Classe active
Classe dont les objets sont actifs.
Classe concrte
Par opposition aux classes abstraites, classe qui sinstancie

pour donner des objets.
Classe de base
Classe racine dune hirarchie de classes.
Classe paramtrable
Classe modle pour la construction de classes.
Classe paramtre
Classe rsultant
paramtrable.
Classe racine
Classe racine dune hirarchie de classes.
Classe utilitaire
Classe dgrade, rduite au concept de module.
Classe-association
Association promue au rang de classe.
Classification
Action dordonner dans le but de comprendre.
Classification
dynamique
Forme de classification par laquelle un objet peut changer de

type ou de rle.
Classification
Forme de classification par laquelle un objet ne peut pas
de
la
paramtrisation
dune
classe
Glossaire 411
statique
changer de type ou de rle.
Cl
Tuple des attributs qui ralisent la restriction dune association.
Cl naturelle
Cl primaire issue du domaine de lapplication.
Cl primaire
Information dsignant un objet de manire bijective.
Client
Objet lorigine dune requte.
Collaboration
1) Se dit dune interaction entre objets ralise dans le but de

satisfaire un besoin de lutilisateur.
2) Elment structurant dUML pour la description du contexte
dune interaction.
Collection
Terme gnrique dsignant tous les regroupements dobjets sans

prciser la nature du regroupement.
Composant
Elment physique constitutif dune application, reprsent

principalement dans la vue de ralisation.
Composition
1) Forme dorganisation complmentaire de la classification.

2) Agrgation par valeur.
Conception
Dtermination du comment dune application.
Condition
Expression boolenne qui valide ou non une transition dans un

automate dtats finis.
Constructeur
Opration de classe qui construit des objets.
Construction
Phase de la vue de lencadrement dans laquelle le logiciel est

ralis et amen un tat de maturit suffisant pour tre livr
ses utilisateurs.
Conteneur
Structure de donnes qui contient des objets.
Contexte
Ensemble dlments de modlisation qui sert de support une

interaction.
Contrainte
Expression qui prcise le rle ou la porte d'un ou plusieurs

lments de modlisation.
Contrat
Engagement entre classes rdig selon les termes de la

spcification du fournisseur.
Contrle
Synonyme de flot de contrle.
Couche
Segmentation horizontale des modles.
Couplage
Dpendance entre lments de modlisation.
CRC
Abrviation de Class Responsibilities Collaborators.
Cycle
Passage complet par les quatre phases de la vue de

lencadrement.
Cycle de vie
Etapes du dveloppement et ordonnancement de ces tapes.
Dcomposition
Sparation en lments plus petits dans le but de rduire la

complexit.
Dlgation
Mcanisme de communication entre objets qui permet un

objet fournisseur de faire raliser des tches par un objet soustraitant, sans le dire lobjet client.
Dpendance
Relation dobsolescence entre deux lments de modlisation.
Dploiement
Phase de la vue de lencadrement qui comprend la transition de

lapplication dans son environnement final.
Destructeur
Opration de classe qui dtruit des objets.
Diagramme
Reprsentation graphique dlments de modlisation.
Discret
Contraire de continu.
Discriminant
Synonyme de critre.
Documentation
Description textuelle des modles.
Domaine
Synonyme de champ dapplication.
Elaboration
Phase de la vue de lencadrement dans laquelle larchitecture est

dfinie.
Elment
Brique de base dun modle.
Elment de
modlisation
Reprsentation dune abstraction issue du domaine du

problme.
Elment de
visualisation
Projection graphique
modlisation.
Encapsulation
Occultation des informations contenues par un objet.
Entit
Terme emprunt aux mthodes de modlisation par les

donnes ; il est employ comme synonyme dobjet du domaine.
Enumration
Liste de valeurs nommes ; domaine de dfinition dun type.
Erreur
Occurrence anormale.
Espace de nom
Partie de modle dans laquelle un nom peut tre dfini : au sein

dun espace de nom, un nom ne possde quune seule
signification.
Espace des tats
Ensemble des tats possibles.
Etat
Condition instantane dans laquelle se trouve un objet, un

systme.
Etend
Relation dextension entre cas dutilisation.
Etude dopportunit
Phase de la vue de lencadrement dans laquelle la vision du

produit est dfinie.
Evnement
Occurrence qui engendre un changement dtat.
Exception
Condition exceptionnelle qui correspond une anomalie lors de

lexcution.
Export
Partie visible dun paquetage.
dune
collection
dlments
de
Glossaire 413
Expression
Chane dont linterprtation donne une valeur dun type donn.
Extension
Forme de programmation qui facilite la prise en compte de

nouveaux besoins.
Factorisation
Identification puis extraction de similitudes entre classes.
Flot dexcution
Description de la rpartition de lactivit entre les objets.
Flot de contrle
Synonyme de flot dexcution.
Flot de donnes
Description des donnes qui transitent dun objet vers un autre

objet.
Fonction
Expression dun besoin en termes impratifs, sous la forme de

tches accomplir.
Framework
Macro-architecture gnrique.
Garde
Condition boolenne qui valide une transition dans un automate.
Gnralisation
Point de vue ascendant port sur une classification ; nom donn

par UML la relation de classification utilise pour construire
des hirarchies de classes ; souvent synonyme dhritage, bien
que plus abstrait.
Gnralisation
multiple
Forme de gnralisation dans laquelle une classe drive de

plusieurs anctres. Souvent synonyme dhritage multiple, bien
que plus abstrait.
Gnration
Dernire version excutable produite par un cycle de

dveloppement.
Gnrique
Solution gnrale ; se dit aussi de composants modles.
Gestion de versions
Enregistrement de lhistoire dun lment.
Gestion de
configurations
Etablissement de relations entre les constituants dun systme

dans le but de maintenir la cohrence.
Hritage
Relation entre classes qui permet le partage de proprits

dfinies dans une classe ; principale technique de ralisation de
la gnralisation.
Hritage dinterface
Hritage de linterface dun lment plus gnral sans sa

ralisation.
Hritage de (pour la)

ralisation
Hritage de linterface et de la ralisation dun lment plus

gnral.
Hritage multiple
Relation entre classes qui permet le partage de proprits

dfinies dans plusieurs classes.
Hirarchie
Arborescence de classes ordonnes par une relation de

gnralisation.
Identit
Caractristique fondamentale dun objet qui le distingue de tous

les autres objets.
Idiome
Construction lgante, propre un langage donn.
Import
Relation de dpendance entre paquetages qui rend visible les
exports dun paquetage au sein dun autre paquetage.
Instance
Synonyme dobjet ; un objet est instance dune classe.
Intgration
Qualit de linterdpendance entre lments de modlisation.
Interaction
Description dun comportement dans le contexte dune

collaboration.
Interface
Partie visible dune classe, dun groupe dobjets ; parfois

synonyme de spcification.
Interruption
Droutement du flot dexcution normal, conscutif la

dtection d'une condition matrielle.
Invariant
1) Expression boolenne dont le changement de valeur dclenche

une exception.
2) Critre pour la dtection des objets ; un objet est un invariant
du domaine.
Invocation
Mcanisme par lequel un message dclenche une opration.
Itrateur
Objet ou mcanisme qui permet de visiter tous les lments

dune collection, sans en dvoiler la structure interne.
Itration
1) Action de traverser une collection dobjets.

2) Squence dactivits de la vue technique qui aboutit la
livraison dun prototype excutable.
Liaison dynamique
Association entre un nom dobjet et une classe ralise

lexcution.
Liaison statique
Association entre un nom dobjet et une classe ralise la

compilation.
Lien
Connexion smantique entre un tuple dobjets par laquelle un

objet peut communiquer avec un autre objet.
Ligne de vie
Reprsentation de lexistence dun objet dans un diagramme de

squence.
Livraison
Rsultat excutable dune itration ; parfois synonyme de

prototype.
Maintenance
Phase du cycle de vie du logiciel qui suit le dploiement ; la

maintenance regroupe des activits de correction de dfauts et
de prise en compte des demandes dvolution.
Mcanisme
Synonyme de collaboration entre objets.
Membre
Terminologie C++ pour dsigner un attribut ou une opration

contenue par une classe.
Message
Elment de communication entre objets qui dclenche une

activit dans lobjet destinataire ; la rception dun message
correspond un vnement.
Mtaclasse
Classe dune classe ; elle contient les donnes et les oprations

qui concernent la classe plutt que les instances de la classe.
Glossaire 415
Mtamodle
Modle qui dcrit des lments de modlisation.
Mtamodlisation
Modlisation rcursive des lments de modlisation partir

deux-mmes.
Mthode
1) Souvent synonyme dopration ; quelquefois utilis pour

distinguer la spcification de lopration des multiples
ralisations les mthodes implantes dans les sous-classes.
2) Ensemble de dmarches raisonnes pour parvenir un but.
Mthode dinstance
Opration qui concerne les objets.
Mthode de classe
Opration qui concerne la classe plus que les objets.
Mode
Caractrise les paramtres selon la direction du flot de donnes :

en entre, en entre et en sortie, en sortie.
Modle
Construction descriptive partir des lments de modlisation.
Modlisation
Synonyme danalyse ; par extension, laboration des modles, y

compris de conception.
Modificateur
Opration qui modifie ltat interne dun objet.
Modularit
Qualit dun environnement de ralisation qui permet la

partition.
Module
Espace lexical dans lequel dautres constructions peuvent tre

dclares.
Monomorphisme
Concept de la thorie des types, selon lequel un nom ne peut

rfrencer que des objets de la mme classe.
Multiplicit
Dsigne le nombre dobjets qui peuvent participer une

relation.
Navigabilit
Qualit dune relation qui permet le passage dune classe vers

une autre classe.
Niveau de maturit
Description de la qualit dun processus de dveloppement.
Nud
Dispositif matriel susceptible dexcuter un programme.
Non interprt
Reprsentation dun type non spcifi par UML, sous la forme

dune chane.
Notation
Ensemble des signes et symboles qui composent un langage.

Dans le cas dUML, ensemble des reprsentations graphiques
et textuelles qui constituent les diagrammes.
Note
Information textuelle qui peut tre associe tout lment ou

combinaison dlments de modlisation ; la note appartient la
vue, elle ne vhicule aucune smantique.
Objet
Entit atomique constitue dun tat, dun comportement et

dune identit.
Objet actif
Objet qui possde son propre flot de contrle ; instance dune

classe active.
Occultation
Synonyme dencapsulation.
dinformation
Opration
Elment de comportement des objets, dfini de manire globale

dans la classe.
Opration abstraite
Opration dfinie dans une classe, mais dont la ralisation est

reporte dans une sous-classe.
Paquetage
Elment dorganisation des modles.
Partie prive
Partie de la spcification dune classe qui regroupe des

proprits invisibles de lextrieur.
Partie protge

proprits invisibles de lextrieur, sauf des sous-classes.
Partie publique

proprits visibles de lextrieur.
Partition
Segmentation verticale des modles ; par extension, sousensemble dun modle.
Pattern
Micro-architecture ; lment de conception (ou danalyse)

rcurrent.
Persistance
Qualit dun objet transcender le temps ou lespace.
Phase
Ensemble des activits entre deux points de contrle dun

processus de dveloppement.
Polymorphisme
Concept de la thorie des types, selon lequel un nom peut

rfrencer des objets instances de plusieurs classes regroupes
dans une hirarchie de gnralisation.
Post-condition
Condition boolenne qui doit tre vraie aprs lexcution dune

opration.
Pr-condition
Condition boolenne qui doit tre vraie avant lexcution dune

opration.
Processus
1) Flot dexcution lourd.

2) Suite dtapes, plus ou moins ordonnes, ddies la
satisfaction dun objectif.
Projection
Relation entre un ensemble et un sous-ensemble.
Proprit
Caractristique dune classe.
Prototype
Rsultat dune itration ; version partielle dun systme.
Pseudo-tat
Dsigne des tats particuliers comme ltat initial, ltat final,

lhistorique.
Rcursivit
Application dune rgle ses propres rsultats pour gnrer une

squence infinie de rsultats.
Rflexive
Se dit dune relation dont les rles concernent la mme classe.
Rification
Action de chosifier un concept, une fonction.
Responsabilit
Obligation dune classe ; partie de sa raison dtre.
Glossaire 417
Restriction
Se dit dune relation dont la porte a t rduite par une

contrainte ou une cl.
Rtro-ingnierie
Reconstruction des artefacts des activits en amont, partir des

artefacts des activits en aval.
Rutilisation
Usage poursuivi ou rpt dun artefact du dveloppement.
Revue
Rvision formelle dune documentation, dun modle.
Risque
Elment susceptible de perturber le bon droulement du

dveloppement.
Rle
Extrmit dune relation ; par extension, manire dont les

instances dune classe voient les instances dune autre classe au
travers dune relation.
Scnario
Interaction simple entre objets.
Schme
Traduction franaise de pattern.
SEI
Software Engineering Institute.
Slecteur
1) Opration qui renseigne sur ltat interne dun objet, sans le

modifier.
2) Dans une expression de navigation, association qui
partitionne un ensemble dobjet partir de la valeur dune cl.
Serveur
Objet qui nest jamais lorigine dune interaction.
Signal
Evnement nomm qui peut tre dclench explicitement.
Signature
Identifiant non ambigu dune opration, construit partir du

nom de lopration et de ses paramtres.
Sous-classe
Classe spcialise, relie une autre classe plus gnrale par une
relation de gnralisation.
Sous-tat
Etat englob par un super-tat.
Sous-systme
Sorte de paquetage de la vue de ralisation ; un sous-systme

contient des lments de ralisation ; il est le pendant de la
catgorie dfinie dans la vue logique.
Spcialisation
Point de vue descendant port sur une classification.
Spcification
Description exhaustive dun lment de modlisation.
Strotype
Extension de la smantique dun lment du mtamodle.
Structure
Relations statiques entre lments de modlisation.
Structure
Dcrit une technique de dcomposition, base sur la notion de

modules et la description des flots de donnes entre ces
modules.
Super-classe
Classe gnrale relie une autre classe plus spcialise par une
relation de gnralisation.
Super-tat
Etat contenant des sous-tats.
Surcharge
Emploi dun mme nom pour dsigner diffrentes

constructions ; la surcharge est rsolue statiquement par les
compilateurs en fonction du contexte et de la signature des
oprations.
Synchrone
Forme de communication bloquante, avec accus de rception

implicite.
Synchronisation
Expression de la forme de communication entre deux objets.
Temps rel
Caractristique dun logiciel dont le temps de rponse est

compatible avec la dynamique du systme.
Test
Ensemble des mesures et des activits qui visent garantir le

fonctionnement satisfaisant du logiciel.
Topologie
Dcrit la rpartition des modules, ainsi que des donnes et des

oprations dans ces modules, au sein dune application.
Transition
1) Connexion entre deux tats dun automate, dclenche par

loccurrence dun vnement.
2) Phase de la vue de lencadrement dans laquelle le logiciel est
transfr ses utilisateurs.
Transition
automatique
Transition dclenche ds que lactivit en cours dans ltat

sachve.
Typage
Manire dont les langages de programmation supportent la

notion de type.
Type
Description dun ensemble dinstances qui partagent des

oprations, des attributs abstraits, des relations et des
contraintes.
Type de donne
abstrait
Description dune donne en termes opratoires.
Type primitif
Type de base prdfini par UML.
Use case
Voir cas dutilisation.
Variable dinstance
Attribut dobjet.
Variable de classe
Attribut qui concerne la classe plus que les objets.
Visibilit
Niveau dencapsulation des attributs et des oprations dans les

classes.
Vision
Dfinition dun produit et de sa porte.
Vue
Manire de regarder des lments de

ventuellement issus de modles diffrents.
modlisation,
Bibliographie
Pour en savoir plus

Bibliographie
C. A LEXANDER, S. ISHIKAWA, M. SILVERSTEIN, M. JACOBSON, I. FISKDAHL-KING,
S. A NGEL, A Pattern Language, Oxford University Press, 1977.
N.D. BIRREL, M.A. OULD, A Practical Handbook for Software Development,
Cambridge University Press, 1985.
G. BOOCH, Object-Oriented Analysis and Design with Applications, 2e dition,
Addison-Wesley, 1994.
BOOCH, Object Solutions, Addison-Wesley, 1996. [Traduction franaise : Des
solutions objets : grer les projets orients objets, ITP France, 1997].
M. BOUZEGHOUB, G. GARDARIN, P. VALDURIEZ, Les objets, Eyrolles, 1997.
F.P. BROOKS, The Mythical Man-Month, 2e dition, Addison-Wesley, 1995.
F. BUSCHMANN et al., Pattern-Oriented Software Architecture: A System of Patterns,
Wiley, 1996.
P. COAD, E. YOURDON, Object Oriented Analysis, Yourdon Press, Prentice Hall, 1991
W.E. DEMING, Quality, Productivity, and Competitive Position, Massachusetts

Institute of Technology, 1982.
DESFRAY, Modlisation par objets, Masson, 1996.
D. EMBLEY, B. D. KURTZ, S.N. W OODFIELD, Object-Oriented Systems Analysis : A
Model-Driven Approach, Prentice Hall, 1992.
E. GAMMA, R. HELM, R. JOHNSON, J. VLISSIDES, Design Patterns: Elements of
Reusable Object-Oriented Software, Addison-Wesley, 1995. [Traduction franaise :
Design patterns : catalogue de modles de conception rutilisables, ITP France,
1996].
I. GRAHAM, Object Oriented Methods, 2e dition, Addison-Wesley, 1994.
W.S. HUMPHREY, Managing the Software Process, Addison-Wesley, 1989.
I. JACOBSON, M. CHRISTERSON, P. JONSSON, G. OVERGAARD, Object-Oriented
Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1992.
I. JACOBSON, M. ERICSON, A. JACOBSON, The Object Advantage: Business Process
Reengineering with Object Technology, Addison Wesley, 1994.
I. JACOBSON, M. GRISS P. JONSSON, Software Reuse: Architecture, Process and
Organisation for Business Success, Addison-Wesley, 1997.
J. M ARTIN, J.J. ODELL, Object-Oriented Methods: Pragmatic Considerations,
Prentice Hall, 1996.
B. M EYER, Object-Oriented Software Construction, Prentice Hall, 1988. [Traduction
franaise : Conception et programmation par objets, InterEdition, 1990].
RUMBAUGH et al., Object Oriented Modeling and Design, Prentice Hall, 1991.
[Traduction franaise : OMT Tome 1 : Modlisation et conception orientes objet,
Masson, 1996].
S. SHLAER, S. J. M ELLOR, Object Oriented Systems Analysis : Modeling the World in
Data, Prentice Hall, 1988.
Adresses utiles sur Internet

Spcifications dUML 1.0 (Rational Software)
Document en anglais aux formats HTML ou PDF compos de six sections :
UML Summary : introduction UML.
UML Notation Guide : description de la notation unifie avec exemples dillustration.
Bibliographie 421
UML Semantics : description du mtamodle qui est la base de la smantique

dUML.
UML Glossary : glossaire de la terminologie UML.
UML Process-Specific Extensions : extensions spcifiques pour la reprsentation
des processus de dveloppement.
http://www.rational.com/uml/
Rational Rose
Outil de modlisation supportant les notations Booch93, OMT-2 et UML.
http://www.rational.com/pst/products/rosefamily.html
Site web de lESSAIM

(Ecole suprieure des sciences appliques pour lingnieur Mulhouse)
Informations gnrales sur UML (site de lauteur).
http://www.essaim.univ-mulhouse.fr
Index
A
abstraction 219
dmarche d 36, 206
hirarchie d 49
niveau d 61, 71, 218, 235
acteur
candidats 127
cas d'utilisation 124
comportement 26
action 168
dclenchement 146, 181
activit 168
diagramme d' 182
priode d' 155
agent 26
agrgation 46, 109
automate 161
composite 141
composition 110
Agrgation
d'tats 173
analyse
des besoins 216, 276
des risques 261
mthode d' 5
objet 205
approche
cognitive 206
fonctionnelle 7, 25
objet 15
structure 136, 204
systmique 206
approches 206
architecture 208, 237
conception 217
macro-~ 234
micro-~ 231
vision de l' 219
Architecture 217, 219
association 44, 99
couplage fort 46
rflexive 107, 139
ternaire 101, 140
asynchrone
communication 166
envoi de message 31, 153
attribut 20, 37, 94
driv 96
automate 161
mmoire 175
agrgation 173
vnement 165
garde 167
Index 425
gnralisation 171
souche 173
transition 164
B
big bang
effet 244
Booch
Grady 9
mthode de 9, 12
C
cas dutilisation 124, 152, 162, 182,
192, 216, 224
diagramme de 126
transition vers l'objet 224
changement de paradigme 7
classe 36
abstraite 57, 118
active 120
contrat de 40
diagramme de 94
paramtrable 98
spcification de 40, 53
utilitaire 99
classification 49
difficult de 59
dynamique 63, 115
multiple 63
proprits des 69
mtamodle 149
ralisation des cas d'utilisation
136, 216, 276
ralisation des patterns 232
reprsentation du comportement
224
collection 40, 71
multiplicit 104
paramtrable 98
complexit
crise du logiciel 200
cycle itratif 250
des besoins 125
des logiciels 201
gestion de la 17, 36, 49, 140, 193,
214
risque 267
transfert de la 210
composant
agrgation 46
diagramme de 187
hritage 64
intgration des 244, 266
mtamodle 120
rutilisable 98, 207, 277
stockage du code 226
topologie des 237
composants
diagramme de 187
cl
naturelle 23
restriction d'association 108
valeur de 142
composition
agrgation 110
automate 173
gnralisation et 114
hritage et 64
collaboration 136
contexte dune 136
diagramme de 33, 142
conception 207
architecture 217
cycle de vie 245, 257, 282
objet 207
pattern 231
retouche de 251
condition
activit 183
automate 164
boucle 159
branchement 147
garde 167, 174
congre
effet 280
constructeur
d'interfaces 135
d'outils 87
message 28, 104, 381
conteneur 89
contexte
de collaboration 136, 149, 224, 232
de diagramme 44, 84, 94
diagramme d'objet 137
interaction 33, 142
contrainte 88
association 100, 106
d'architecture 219
de dveloppement 200
de gnralisation 50, 116
de ralisation 23, 209
d'objet 144
hritage 64, 115
mcanisme commun 86
multiplicit 104
principe de substitution 69, 75
temporelle 152, 158
contrat
de classe 40
de maintenance 201
programmation par 211

contrle
activit 182
automate 179
de la qualit 256
flot de 26, 35
mode de 157
objet actif 145
tche 189
couche
architecture 235
prototype 264
couplage
agrgation 46
association 103
cycle de vie 240
dlgation 67
encapsulation 41
gnralisation 62
hritage 115
polymorphisme 71
covariance 60
et dlgation 68
cycle de vie
couverture du 9
des objets 19
diagramme de squence 152
en cascade 241
Cycle de vie
itratif et incrmental 239
D
dcomposition
automate 171
couplage 103
Index 427
covariante 59
en sous-systmes 192
flot d'excution 220
fonctionnelle 16
gnralisation 116
objet 16
paquetage 90, 227
processus de 16
dcouplage
polymorphisme 71
dlgation 67
agent 27
dpendance
automate 174
composant 188
de compilation 226
import 91, 235
obsolescence 92
relation de 88, 123
dploiement
diagramme de 194
graduel 267
post- 267, 281
vue de 220
Dploiement
du code excutable 226
destructeur
message 28, 381
diagramme
dtats-transitions 161
dobjets 137
d'activits 182
de cas d'utilisation 126
de classes 94
de collaboration 142
de composants 187
de dploiement 194
de squence 151
discriminant
gnralisation 116
documentation 249
cas d'utilisation 128, 135, 152
cycle de vie 247
de l'architecture 223
sous-systme 193
domaine 204
classe du 225
complexit du 201, 250
de dfinition 20, 40, 123
du problme 17
vnement 165
expert du 125, 266
gnralisation 51
modlisation du 205, 216, 275
objet du 36, 94, 136
E
effet
big bang 244, 251
congre 280
laboration
cycle de vie 257, 260
phase d' 275
encapsulation 41
couplage 43
niveau d' 42
paquetage 92
sous-systme 193
envoi de message
asynchrone 31, 153
synchrone 30, 153
erreur
traitement d' 93, 209

espace de noms 91
espace des tats
segmentation de l' 174, 203, 240
tats-transitions
diagramme d' 161
exception
de classification 59
traitement d'erreur 209
extension
d'UML 86, 361
par spcialisation 50, 118
relation d' 130
F
factorisation
des proprits 56
simplification par 174, 210
flot
dexcution 30, 120, 146, 153, 155,
184, 220
de contrle 28, 152, 183, 371
de donnes 28, 152, 371
formation 257, 267, 272, 280
plan de 213
framework 234
G
garde 167, 183
gnralisation 50, 114, 122
automate 161
d'tat 171
gnration 257, 285
de code C++ 381
de code IDL 397
de code Java 391

de code SQL 405
de code Visual Basic 401
gnrique
cadre mthodologique 199
classe 98
collaboration, pattern 149
description d'association 105
instanciation de 378
logiciel 57
mcanisme 276
modle 206
nom 20, 94, 179
notation 83
spcification 187
gestion
de versions et de configurations
193, 255, 279, 283
du risque 261
H
hritage 64
valuation de l' 69
multiple 65
pour la construction 64
pour raliser la classification 115
reprsentation graphique 377
simulation de l 67
hirarchie
de catgories et de sous-systmes
227
de classes 49
de paquetages 90
historique
automate mmoire 175
I
identit 20, 23
Index 429
de collaboration 149
idiome 233
instance 36
de relation 44
ensemble des 53
intgration
avec les environnements de
dveloppement 193
dmarche d' 17
phase d' 242
schma d' 209
test d' 242
interaction 150
description des 70
diagramme d' 32
entre objets 22
reprsentation des 142, 151
structuration des cas d'utilisation
125
interface 41, 67, 97
de paquetage 92
d'un projet 272
type 97
interruption 28, 153, 176
itrateur 28, 72
itration
clause d' 147
cycle de vie 204, 215, 244
envoi de message 144
valuation d'une 252
J
Jacobson Ivar 9
L
liaison
dynamique 27, 77, 176, 211

polymorphisme dopration 71
statique 75
lien 22, 44, 49
de communication 196
diteur de 190
instance d'association 94
instance d'association ternaire 101
polymorphe 77
ligne de vie 151
diagramme d'activit 185
livraison 244
incrmentale 215
M
maintenance 43, 71, 126, 201, 208, 250
cycle de 285
dploiement 281
point de maintenance 60
post-dploiement 267
maquette 135, 259, 274
mcanisme 57
abstrait 71, 118
commun 86
de base 368
de communication 29
de dlgation 27, 67
de partition 90
excution d'un 182
gnrique 276
membre
de classe 92
d'un projet 261
d'une quipe 269
fonction 29
message 27
catgorie de 28
de cration 154
de destruction 154
dclenchement d'oprations 71, 77
envoi de 142
flot de 128
mode de communication 209
paramtres de 148
rcursif 157
rflexif 154
synchronisation des 29, 146
mtaclasse
reprsentation 374
strotype 95
mtamodle 12, 119, 149, 180
spcialisation du 86
mthode
de dveloppement 213
l'unification des 10
ralisation des oprations 119, 182
mode
de contrle 157
de synchronisation 209
modle 86
CMM (Capability Maturity Model)
214
complexit des 234
de classes 98
des 4 + 1 vues 219
en cascade 241
en tunnel 240
en V 242
enrichissement des 207
organisation des 221
partition des 90
transformation des 207

modlisation 13
fonctionnelle 7, 13
objet 7, 11, 13, 19, 49
modificateur
message 28
modularit 43, 210, 240
module 41, 187
classe utilitaire 95
organisation des 220
multiplicit 45, 89, 103
rduction de la 112
N
navigation
expression de 88, 111
nud 120, 194
reprsentation 194
strotypes de 194
nommage
des associations 101
des rles 45, 107
note 88
d'installation 278
mcanisme commun 86
reprsentation 19, 368
O
Objectory 12
objet 18
acteur 26
actif 145
agent 26
anonyme 20
approche 15
Index 431
caractristiques fondamentales
dun 20
diagramme d' 137
persistant 24
serveur 26
OMT 9, 12
OOSE 12
opration 21, 37, 94
abstraite 118
action 169
automate 168
compartiment de classe 95
de classe 97
dclenchement des 77
dclenchement manuel 75
gnralisation 50
hritage 64
point d'excution 170
propagation des 47, 70
visibilit des 96
optimisation 209
P
paquetage 86, 90, 123, 149
Ada 187
arborescence de 222
gnralisation 114
import 91
interface 92
organisation des vues 227
strotyp en catgorie 220, 235
partie
prive 42, 193
protge 42
publique 42, 193
partition
des besoins 125
des modles 90
d'un ensemble dobjets 56, 112,
122
en sous-systmes 9
pattern 150, 207, 231
persistance 24, 235
polymorphisme 70, 80
ad hoc 80
d'opration 71
thorie des types 70
projection 14, 86, 223
proprit 95
caractristique d'un ensemble 53
classification 69
de navigation 114
drive 96
des objets d'une classe 40
tiquette 88
modlisation des 17
prototype 244, 258
maquette 274
R
rcursive
structure 107, 137
rflexive
association 107, 139
transition 168
rification
dune association 105
dune fonction 39
d'un flot d'excution 120
d'une interaction 39
responsabilit
allocation des 280
chane de 232
restriction
d'une association 108, 142
reprsentation 376
rutilisation 51, 208, 215
pattern 232
taux de 277
revue 241, 246
risque
gestion du 261
rle
association 102
association n-aire 101
attributs de 121
d'une classe 45
nommage des 102
Rumbaugh James 9
S
scnario 128, 245, 263
automate 162
schme 150, 231
SEI (Software Engineering Institute)
214
slecteur
expression de navigation 111
message 28
opration 42
squence
diagramme de 151
serveur
comportement 26
de bases de donnes 210
objet 26
ordinateur 195
X 195
signature 80
souche 173
spcialisation 50
critre de 62
dimension de 60
spcification
d'un composant 187
d'un lment 86
d'un vnement 166
d'une classe 40, 53
gnrique 187
pure 99
strotype 87, 123
association ternaire 101
de classe 95, 138
de dpendance 188
de nud 194
de paquetage 87, 90, 235
de processus 189
de support de communication 195
de transition 186
de type 97
d'tat 182
d'objet 138
prdfini 361
structure
approche 136, 204
technique 200
surcharge
des oprations 80, 211
polymorphisme ad hoc 80
synchronisation
barre de 184
Index 433
de flots de contrle 183

des messages 146
forme de 29
mode de 209
T
tche 189, 220, 226
dichotomie (type, classe) 88

dichotomie (type, instance) 88
d'utilisateurs 216
gnralisation 114, 118
interface 97
polymorphisme 70
primitif 88
temps rel 152
topologie
d'application 237
use case 124
transition 158
automate 164
automatique 169
cycle de vie 257
dentre 170
de Booch et OMT vers UML 367
de sortie 169
diagramme d'tats-transitions 161
interne 172
phase de 280
vers l'objet 212
variable
de classe 97
Transition 224
typage
influence du 80
type 40, 119, 123
de donne abstrait 40, 99
des attributs 138
visibilit 84
niveau de 42, 96
rgles de 42
vision
anthropomorphique 19
d'architecture 219
d'un produit 273
vue
d'architecture 219
de dploiement 220
de ralisation 220
des cas d'utilisation 221
des processus 220
logique 219
Contenu du CD-Rom
Tous les efforts ont t faits pour tester avec soin le CD-Rom et les programmes quil
contient. Nanmoins, les Editions EYROLLES ne pourront tre tenues pour
responsables des prjudices ou dommages de quelque nature que ce soit pouvant
rsulter de lutilisation de ces programmes.

22 - Copie PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

22 - Copie PDF

Uploaded by

Copyright:

Available Formats

Modlisation objet

pam, avril 1997

Table des matires

REDDE CAESARI QUAE SUNT CAESARIS

TABLE DES MATIRES

A QUI SADRESSE CE LIVRE

Les mthodes danalyse et de conception......................................................................5

Pourquoi lapproche objet ?.......................................................................................... 15

II Modlisation objet avec UML

Les diagrammes dUML ................................................................................................ 84

Table des matires III

Similitudes avec les diagrammes de classes.......................................................141

IV Modlisation objet avec UML

La transition vers lobjet........................................................................................212

LES LMENTS STANDARD

Table des matires V

Contraintes prdfinies ..............................................................................................365

Les mcanismes de base.............................................................................................368

VI Modlisation objet avec UML

Table des matires VII

Pour en savoir plus ......................................................................................................419

A qui sadresse ce livre

2 Modlisation objet avec UML

le premier chapitre met en avant le besoin de mthodes et dcrit la gense de

le deuxime chapitre prsente les concepts de base de la technologie objet,

le troisime chapitre dcrit les concepts dUML, en utilisant la notation comme

le quatrime chapitre introduit les bases de lencadrement des projets objet,

le cinquime chapitre prsente une tude de cas : la modlisation objet avec

un guide de transition de Booch et OMT vers UML,

la gnration de code C++,

la gnration de code Java,

la gnration de code IDL,

la gnration de code Visual Basic,

la gnration de code SQL.

Plusieurs lectures de l'ouvrage sont possibles, selon les connaissances et les

Le lecteur qui possde dj une bonne connaissance d'une mthode de

Les architectes du logiciel, aprs avoir tudi la notation UML dans le

Les chefs de projets trouveront galement dans le quatrime chapitre les

A qui sadresse ce livre 3

l'architecture, itratif et incrmental. Il leur sera aussi profitable de parcourir les

ni un trait de programmation objet ; il ne dcrit aucun langage de

ni une apologie dUML ; mais plutt un ouvrage de modlisation objet, qui

Les mthodes danalyse et de conception

6 Modlisation objet avec UML

Des mthodes fonctionnelles aux mthodes objet

8 Modlisation objet avec UML

Figure 2 : La combinaison dune approche fonctionnelle pour lanalyse et dune approche

Durant la dernire dcennie, des applications objet depuis lanalyse des

La prolifration des mthodes objet

qui ne lest pas du tout1. Le travers de cette effervescence mthodologique est

Rapprochement de Booch et OMT

Amghar Y. & al. 25-27 octobre 1995, Domaines et utilisation de la technologie

Harel, D. 1987. Statecharts : A Visual Formalism for Complex Systems. Science

10 Modlisation objet avec UML

Classes singletons et objets composites

Description des oprations, numrotation des messages

Frameworks, patterns et notes

Cas dutilisation (use cases)

Classification dynamique, clairage sur les vnements

Cycle de vie des objets

Lunification des mthodes

tablir un couplage explicite entre les concepts et les artefacts excutables,

prendre en compte les facteurs dchelle inhrents aux systmes complexes et