Methode de Conception Orientee Objet - 2012

Mthodes de Conception Orients Objet (MCOO)
Verlain FOUNDIKOU Page 1

SOMMAIRE

Sommaire .......................................................................................................................................... 1
INTRODUCTION .................................................................................................................................. 3
I. Particularits dUML ..................................................................................................................... 4
I.1 UML est une norme ............................................................................................................................. 5
I.2 UML est un langage de modlisation objet......................................................................................... 5
I.3 UML est un support de communication .............................................................................................. 6
I.4 UML est un cadre mthodologique pour une analyse objet ............................................................... 6
II. Le contexte dapparition dUML .................................................................................................... 8
II.1 Approche fonctionnelle et approche objet ......................................................................................... 8
II.1.1 Lapproche fonctionnelle ......................................................................................................... 8
II.1.2 Lapproche objet.................................................................................................................... 10
II.2 La gense dUML ............................................................................................................................... 13
II.2.1 Historique des mthodes danalyse ...................................................................................... 13
II.2.2 Cadre dutilisation dUML ...................................................................................................... 14
II.2.3 Points forts dUML ................................................................................................................. 15
II.2.4 Points faibles dUML .............................................................................................................. 15
III. Dmarche gnrale de modlisation avec UML ........................................................................... 16
III.1 Quest ce quun modle ? ................................................................................................................. 16
III.1.1 Dfinition dun modle .......................................................................................................... 16
III.1.2 Caractristiques fondamentales des modles ...................................................................... 16
III.2 Comment modliser avec UML ? ...................................................................................................... 16
III.2.1 Proposition dune dmarche ................................................................................................. 16
III.2.2 Les vues ................................................................................................................................. 17
III.3 Les niveaux dabstraction .................................................................................................................. 18
III.4 Lutilisation des diagrammes ............................................................................................................. 19
III.4.1 Dfinition dun diagramme ................................................................................................... 19
III.4.2 Caractristiques des diagrammes UML ................................................................................. 20
IV. Les Diffrents types de diagrammes ............................................................................................ 20
IV.1 Vues statique du systme ................................................................................................................. 20
IV.1.1 Diagrammes de cas d'utilisation ............................................................................................ 21
IV.1.2 Diagrammes de classes.......................................................................................................... 27
IV.1.3 Diagrammes d'objets ............................................................................................................. 35
IV.1.4 Diagrammes de composants ................................................................................................. 35
IV.1.5 Diagrammes de dploiement ................................................................................................ 35
IV.1.6 Diagrammes des paquetages ................................................................................................ 36
IV.1.7 Diagramme de structure composite...................................................................................... 36
IV.2 Vues dynamiques du systme : ......................................................................................................... 36
IV.2.1 Diagrammes de collaboration ou diagrammes de communication en UML 2 ..................... 36
IV.2.2 Diagrammes de squence ..................................................................................................... 38
IV.2.3 Diagrammes d'tats-transitions ............................................................................................ 43
IV.2.4 Diagrammes d'activits ......................................................................................................... 45
IV.2.5 Diagramme global dinteraction ............................................................................................ 45
IV.2.6 Diagramme de temps ............................................................................................................ 46
IV.3 Modlisation et association des diagrammes / outils de modlisation ........................................... 46
IV.3.1 Modlisation et association des diagrammes ....................................................................... 46
IV.3.2 Les outils de modlisation ..................................................................................................... 47
IV.3.3 Quelques langages de programmation orients objet ......................................................... 48

V. Etude Dune methode de modelisation sappuyant sur uml: Le processus unifi (up) ................... 49
V.1 Le processus unifi est pilot par les cas dutilisation ...................................................................... 49
V.1.1 Prsentation gnrale ........................................................................................................... 49
V.1.2 Stratgie des cas dutilisation ................................................................................................ 49
V.2 Le processus unifi est centr sur larchitecture .............................................................................. 50
V.2.1 Liens entre cas dutilisation et architecture .......................................................................... 51
V.2.2 Marche suivre ..................................................................................................................... 51
V.2.3 Le processus unifi est itratif et incrmental ...................................................................... 51
V.2.4 Le cycle de vie du processus unifi ........................................................................................ 52
V.2.5 Conclusion : un processus intgr ......................................................................................... 54
VI. Elments de comparaisons entre MERISE et UML ........................................................................ 54
VI.1 Les principes ...................................................................................................................................... 54
VI.1.1 Lapproche systmique ......................................................................................................... 55
VI.1.2 Les cycles de construction du systme dinformation .......................................................... 55
VI.1.3 Lapproche fonctionnelle ....................................................................................................... 56
VI.1.4 La sparation donnes-traitements ...................................................................................... 56
VI.1.5 Lapproche qui part du gnral vers le particulier ................................................................ 56
VI.2 La modlisation mtier ...................................................................................................................... 56
VI.2.1 Le domaine ............................................................................................................................ 56
VI.2.2 Lacteur .................................................................................................................................. 57
VI.2.3 Les flux ................................................................................................................................... 57
VI.2.4 Les modles conceptuels et organisationnels ....................................................................... 57
VI.3 La dmarche ...................................................................................................................................... 60
VI.3.1 Les modles utiliss ............................................................................................................... 60
VI.3.2 Les tapes du processus dlaboration du systme dinformation ................................. 61
CONCLUSION GENERALE ................................................................................................................... 62


INTRODUCTION

Pour faire face la complexit croissante des systmes dinformation, de nouvelles
mthodes et outils ont t cres. La principale avance des dernires annes rside dans la
programmation oriente objet (P.O.O.).
Face ce nouveau mode de programmation, les mthodes de modlisation classique(telle MERISE)
ont rapidement montr certaines limites et ont d sadapter (cf.MERISE/2).
De trs nombreuses mthodes ont galement vu le jour comme Booch, OMT
Dans ce contexte et devant le foisonnement de nouvelles mthodes de conception oriente
objet , lObject Management Group (OMG) a eu comme objectif de dfinir une notation standard
utilisable dans les dveloppements informatiques bass sur lobjet. Cest ainsi quest apparu UML
(Unified Modified Language langage de modlisation objet unifi ), qui est issu de la fusion
des mthodes Booch, OMT (Object ModellingTechnique) et OOSE (Object Oriented Software
Engineering). Cest donc un langage standard de modlisation des systmes dinformation.
Issu du terrain et fruit d'un travail d'experts reconnus, UML est le rsultat d'un large consensus. De
trs nombreux acteurs industriels de renom ont adopt UML et participent son dveloppement.
En l'espace d'une poigne d'annes seulement, UML est devenu un standard incontournable de
part ses atouts majeurs car tant un langage visuel pour comprendre le systme, communiquer et
travailler plusieurs, aider spcifier, concevoir et dvelopper un systme dinformation avec
diffrents modles et diffrentes vues.
Ceci nous amne nous questionner sur :
- les apports rels dUML dans la modlisation
- la place des mthodes dites traditionnelles telle que MERISE.
UML est en effet apparu trs tardivement, car lapproche objet se pratique depuis de trs
nombreuses annes dj, mais sest impos du fait quil couvre toutes les phases du cycle de vie de
dveloppement dun systme et se veut indpendant des langages dimplmentation et des
domaines dapplication.


I. PARTICULARITES DUML
Il ya donc dj longtemps que l'approche objet est devenue une ralit. Les concepts de base de
l'approche objet sont stables et largement prouvs. De nos jours, programmer "objet", c'est
bnficier d'une panoplie d'outils et de langages performants. L'approche objet est une
solution technologique incontournable. Ce n'est plus une mode, mais un rflexe quasi-
automatique ds lors qu'on cherche concevoir des logiciels complexes qui doivent "rsister" des
volutions incessantes.
Toutefois, lapproche objet nest pas une panace :
- elle est moins intuitive que l'approche fonctionnelle.
Malgr les apparences, il est plus naturel pour l'esprit humain de dcomposer un problme
informatique sous forme d'une hirarchie de fonctions atomiques et de donnes, qu'en terme
d'objets et d'interaction entre ces objets.
Or, rien dans les concepts de base de l'approche objet ne dicte comment modliser la structure objet
d'un systme de manire pertinente. Quels moyens doit-on alors utiliser pour mener une analyse qui
respecte les concepts objet ? Sans un cadre mthodologique appropri, la drive fonctionnelle de la
conception est invitable...

- l'application des concepts objet ncessite une trs grande rigueur.
Le vocabulaire prcis est un facteur d'chec important dans la mise en uvre d'une approche objet
(risques d'ambiguts et d'incomprhensions). Beaucoup de dveloppeurs (mme expriments)
ne pensent souvent objet qu' travers un langage de programmation.
Or, les langages orients objet ne sont que des outils qui proposent une manire particulire
d'implmenter certains concepts objet. Ils ne valident en rien l'utilisation de ces moyens techniques
pour concevoir un systme conforme la philosophie objet.
Connatre C++ ou Java n'est donc pas une fin en soi, il faut aussi savoir se servir de ces langages
bon escient. La question est donc de savoir "qui va nous guider dans l'utilisation des concepts
objet, si ce ne sont pas les langages orients objet ?".
Enfin, comment comparer deux solutions de dcoupe objet d'un systme si l'on ne dispose pas
d'un moyen de reprsentation adquat ? Il est trs simple de dcrire le rsultat d'une analyse
fonctionnelle, mais qu'en est-il d'une dcoupe objet ?
Pour remdier ces inconvnients majeurs de l'approche objet, il faut donc :
1) un langage (pour s'exprimer clairement l'aide des concepts objets)
Le langage doit permettre de reprsenter des concepts abstraits (graphiquement par
exemple), limiter les ambiguts (parler un langage commun, au vocabulaire prcis,
indpendant des langages orients objet), faciliter l'analyse (simplifier la comparaison et
l'valuation de solutions).
2) une dmarche d'analyse et de conception objet
Une dmarche danalyse et de conception objet est ncessaire afin de ne pas effectuer une analyse
fonctionnelle et se contenter d'une implmentation objet, mais penser objet ds le dpart, dfinir
les vues qui permettent de dcrire tous les aspects d'un systme avec des concepts objets.
Il faut donc disposer d'un outil qui donne une dimension mthodologique l'approche objet
et qui permette de mieux matriser sa richesse.
La prise de conscience de l'importance d'une mthode spcifiquement objet
("comment structurer un systme sans centrer l'analyse uniquement sur les donnes ou
uniquement sur les traitements, mais sur les deux"), ne date pas d'hier. Plus de 50 mthodes objet
sont apparues durant le milieu des annes 90 (Booch, Classe-Relation, Fusion, HOOD, OMT,
OOA, OOD, OOM, OOSE...). Aucune ne s'est rellement impose.
L'absence de consensus sur une mthode d'analyse objet a longtemps frein l'essor des
technologies objet. Ce n'est que rcemment que les grands acteurs du monde informatique
ont pris conscience de ce problme. L'unification et la normalisation des mthodes objet
dominantes (OMT, Booch et OOSE) ne datent que de 1995. UML est le fruit de cette fusion.

UML, ainsi que les mthodes dont il est issu, s'accordent sur un point : une analyse objet passe par
une modlisation objet.

UML permet donc de modliser une application selon une vision objet.
Lapprhension dUML est complexe car UML est la fois :
- une norme,
- un langage de modlisation objet,
- un support de communication,
- un cadre mthodologique.
I.1 UML est une norme
Fin 1997, UML est devenu une norme OMG (Object Management Group).
L'OMG est un organisme but non lucratif, cr en 1989 l'initiative de grandes socits (HP,
Sun, Unisys, American Airlines, Philips...). Aujourd'hui, l'OMG fdre plus de 850 acteurs du
monde informatique. Son rle est de promouvoir des standards qui garantissent
l'interoprabilit entre applications orientes objet, dveloppes sur des rseaux htrognes.
L'OMG propose notamment l'architecture CORBA (Common Object Request Broker Architecture), un
modle standard pour la construction d'applications objets distribus (rpartis sur un rseau).
CORBA fait partie d'une vision globale de la construction d'applications rparties, appele OMA
(Object Management Architecture) et dfinie par l'OMG. Sans rentrer dans les dtails, on peut
rsumer cette vision par la volont de favoriser l'essor industriel des technologies objet, en offrant
un ensemble de solutions technologiques non propritaires, qui suppriment les clivages
techniques.
UML a t adopt (normalis) par l'OMG et intgr l'OMA, car il participe cette vision et parce
qu'il rpond la "philosophie" OMG.

I.2 UML est un langage de modlisation objet.
Pour penser et concevoir objet, il faut savoir "prendre de la hauteur", jongler avec des concepts
abstraits, indpendants des langages d'implmentation et des contraintes purement techniques.
Les langages de programmation ne sont pas un support d'analyse adquat pour "concevoir
objet". Ils ne permettent pas de dcrire des solutions en terme de concepts abstraits et constituent
un cadre trop rigide pour mener une analyse itrative.
Pour conduire une analyse objet cohrente, il ne faut pas directement penser en terme
de pointeurs, d'attributs et de tableaux, mais en terme d'association, de proprits et de
cardinalits... Utiliser le langage de programmation comme support de conception ne revient
bien souvent qu' juxtaposer de manire fonctionnelle un ensemble de mcanismes
d'implmentation, pour rsoudre un problme qui ncessite en ralit une modlisation objet.
Lapproche objet ncessite une analyse rflchie, qui passe par diffrentes phases
exploratoires.
Bien que raisonner en termes d'objets semble naturel, l'approche fonctionnelle reste la plus intuitive
pour nos esprits cartsiens... Voil pourquoi il ne faut pas se contenter d'une implmentation objet,
mais se discipliner "penser objet" au cours d'une phase d'analyse pralable.
Toutes les drives fonctionnelles de code objet ont pour origine le non respect des concepts de
base de l'approche objet (encapsulation...) ou une utilisation dtourne de ces concepts (hritage
sans classification...). Ces drives ne sont pas dues de mauvaises techniques de
programmation ; la racine du mal est bien plus profonde : programmer en C++ ou en Java
n'implique pas forcment concevoir objet...
Les difficults de mise en uvre d'une approche "rellement objet" ont engendr bien souvent
des dceptions, ce qui a longtemps constitu un obstacle important l'essor des technologies

objet. Beaucoup ont cd au leurre des langages de programmation orients objet et oubli
que le code n'est qu'un "moyen". Le respect des concepts fondamentaux de l'approche objet
prime sur la manire dont on les implmente. Ne penser qu' travers un langage de programmation
objet dtourne de l'essentiel.
Pour sortir les technologies objet de cette impasse, l'OMG propose UML.
UML comble une lacune importante des technologies objet. Il permet
d'exprimer et d'laborer des modles objet, indpendamment de tout langage de
programmation. Il a t pens pour servir de support une analyse base sur les concepts objet.
UML est un langage formel, dfini par un mtamodle.
Le mtamodle d'UML dcrit de manire trs prcise tous les lments de modlisation (les
concepts vhiculs et manipuls par le langage) et la smantique de ces lments (leur dfinition et
le sens de leur utilisation).
En d'autres termes : UML normalise les concepts objet.
Un mtamodle permet de limiter les ambiguts et encourage la construction d'outils. Il
permet aussi de classer les diffrents concepts du langage (selon leur niveau d'abstraction ou
leur domaine d'application) et expose ainsi clairement sa structure. Enfin, on peut noter que le
mtamodle d'UML est lui-mme dcrit par un mta-mtamodle de manire standardise, l'aide
de MOF (Meta Object Facility : norme OMG de description des mtamodles).
Vritable cl de vote de l'OMA, UML est donc un outil indispensable pour tous ceux qui ont
compris que programmer objet, c'est d'abord concevoir objet. UML n'est pas l'origine des
concepts objets, mais il en constitue une tape majeure, car il unifie les diffrentes approches
et en donne une dfinition plus formelle.
I.3 UML est un support de communication
UML est avant tout un support de communication performant, qui facilite la reprsentation
et la comprhension de solutions objet.
Sa notation graphique permet d'exprimer visuellement une solution objet, ce qui facilite la
comparaison et l'valuation de solutions.
L'aspect formel de sa notation limite les ambiguts et les incomprhensions.
Son indpendance par rapport aux langages de programmation, aux domaines d'application et
aux processus, en font un langage universel.

La notation graphique d'UML n'est que le support du langage. La vritable force d'UML, c'est
qu'il repose sur un mtamodle. En d'autres termes : la puissance et l'intrt d'UML, c'est qu'il
normalise la smantique des concepts qu'il vhicule !
Qu'une association d'hritage entre deux classes soit reprsente par une flche termine par
un triangle ou un cercle, n'a que peu d'importance par rapport au sens que cela donne votre
modle. La notation graphique est essentiellement guide par des considrations esthtiques,
mme si elle a t pense dans ses moindres dtails.
Par contre, utiliser une relation d'hritage, reflte l'intention de donner votre modle un sens
particulier. Un "bon" langage de modlisation doit permettre n'importe qui de dchiffrer cette
intention de manire non quivoque. Il est donc primordial de s'accorder sur la smantique des
lments de modlisation, bien avant de s'intresser la manire de les reprsenter.
Le mtamodle UML apporte une solution ce problme fondamental.
UML est donc bien plus qu'un simple outil qui permet de "dessiner" des reprsentations
mentales... Il permet de parler un langage commun, normalis mais accessible, car visuel.
I.4 UML est un cadre mthodologique pour une analyse objet
Une autre caractristique importante d'UML, est qu'il cadre l'analyse. UML permet de
reprsenter un systme selon diffrentes vues complmentaires : les diagrammes. Un

diagramme UML est une reprsentation graphique, qui s'intresse un aspect prcis du
modle ; c'est une perspective du modle.
Chaque type de diagramme UML possde une structure (les types des lments de modlisation
qui le composent sont prdfinis) et vhicule une smantique prcise (il offre toujours la mme vue
d'un systme).
Combins, les diffrents types de diagrammes UML offrent une vue complte des aspects
statiques et dynamiques d'un systme. Les diagrammes permettent donc d'inspecter
un modle selon diffrentes perspectives et guident l'utilisation des lments de modlisation
(les concepts objet), car ils possdent une structure.
Une caractristique importante des diagrammes UML, est qu'ils supportent l'abstraction. Cela
permet de mieux contrler la complexit dans l'expression et l'laboration des solutions objet.
UML opte en effet pour l'laboration des modles, plutt que pour une approche qui impose une
barrire stricte entre analyse et conception. Les modles d'analyse et de conception ne
diffrent que par leur niveau de dtail, il n'y a pas de diffrence dans les concepts utiliss.
UML n'introduit pas d'lments de modlisation propres une activit (analyse, conception...) ;
le langage reste le mme tous les niveaux d'abstraction.
Cette approche simplificatrice facilite le passage entre les niveaux d'abstraction.
L'laboration encourage une approche non linaire, les "retours en arrire" entre niveaux
d'abstraction diffrents sont facilits et la traabilit entre modles de niveaux diffrents est assure
par l'unicit du langage.
UML favorise donc le prototypage, et c'est l une de ses forces. En effet, modliser une application
n'est pas une activit linaire. Il s'agit d'une tche trs complexe, qui ncessite une approche
itrative, car il est plus efficace de construire et valider par tapes, ce qui est difficile cerner et
matriser.

UML permet donc non seulement de reprsenter et de manipuler les concepts objet, il sous-entend
une dmarche d'analyse qui permet de concevoir une solution objet de manire itrative, grce aux
diagrammes, qui supportent l'abstraction.

UML N'EST PAS UNE METHODE
UML est un langage qui permet de reprsenter des modles, mais il ne dfinit pas le processus
d'laboration des modles. Qualifier UML de "mthode objet" n'est donc pas tout fait
appropri.
Une mthode propose aussi un processus, qui rgit notamment l'enchanement des activits de
production d'une entreprise. Or UML n'a pas t pens pour rgir les activits de l'entreprise.
Les auteurs d'UML sont tout fait conscients de l'importance du processus, mais ce sujet a t
intentionnellement exclu des travaux de l'OMG. Comment prendre en compte toutes les
organisations et cultures d'entreprises ? Un processus est adapt (donc trs li) au domaine d'activit
de l'entreprise ; mme s'il constitue un cadre gnral, il faut l'adapter au contexte de l'entreprise.
Bref, amliorer un processus est une discipline part entire, c'est un objectif qui dpasse trs
largement le cadre de l'OMA.
Cependant, mme si pour l'OMG, l'acceptabilit industrielle de la modlisation objet passe d'abord
par la disponibilit d'un langage d'analyse objet performant et standard, les auteurs d'UML
prconisent d'utiliser une dmarche :
- guide par les besoins des utilisateurs du systme,
- centre sur l'architecture logicielle,
- itrative et incrmentale.
D'aprs les auteurs d'UML, un processus de dveloppement qui possde ces qualits fondamentales
"devrait" favoriser la russite d'un projet.
Une source frquente de malentendus sur UML a pour origine la facult d'UML de modliser un
processus, pour le documenter et l'optimiser par exemple. En fin de compte, qu'est-ce qu'un

processus ? Un ensemble d'activits coordonnes et rgules, en partie ordonnes, dont le but
est de crer un produit (matriel ou intellectuel). UML permet tout fait de modliser les activits
(c'est--dire la dynamique) d'un processus, de dcrire le rle des acteurs du processus, la structure
des lments manipuls et produits, etc.
Une extension d'UML ("UML extension for business modeling") propose d'ailleurs
un certain nombre de strotypes standards (extensions du mtamodle) pour mieux dcrire
les processus.
Le RUP ("Rational Unified Process"), processus de dveloppement "cl en main", propos par
Rational Software, est lui aussi modlis (document) avec UML. Il offre un cadre mthodologique
gnrique qui repose sur UML et la suite d'outils Rational.
II. LE CONTEXTE DAPPARITION DUML
II.1 Approche fonctionnelle et approche objet
II.1.1 Lapproche fonctionnelle
LA DECOUPE FONCTIONNELLE D'UN PROBLEME INFORMATIQUE : UNE APPROCHE
INTUITIVE

La dcoupe fonctionnelle dun problme (sur laquelle reposent les langages de
programmation structure) consiste dcouper le problme en blocs indpendants. En ce sens, elle
prsente un caractre intuitif fort.
LA REUTILISABILITE DU CODE
Le dcoupage dun problme en blocs indpendants (fonctions et procdures) va permettre aux
programmeurs de rutiliser les fonctions dj dveloppes ( condition quelles soient suffisamment
gnriques). La productivit se trouve donc accrue.

LE REVERS DE LA MEDAILLE : MAINTENANCE COMPLEXE EN CAS D'EVOLUTION
Le dcoupage en blocs fonctionnels n'a malheureusement pas que des avantages. Les
fonctions sont devenues interdpendantes : une simple mise jour du logiciel un point donn,
peut impacter en cascade une multitude d'autres fonctions. On peut minorer cet impact, pour
peu qu'on utilise des fonctions plus gnriques et des structures de donnes ouvertes. Mais
respecter ces contraintes rend l'criture du logiciel et sa maintenance plus complexe.
En cas d'volution majeure du logiciel (passage de la gestion d'une bibliothque celle d'une
mdiathque par exemple), le scnario est encore pire. Mme si la structure gnrale du logiciel
reste valide, la multiplication des points de maintenance, engendre par le chanage des
fonctions, rend l'adaptation trs laborieuse. Le logiciel doit tre retouch dans sa globalit :
- on a de nouvelles donnes grer (ex : DVD)
- les traitements voluent : laffichage sera diffrent selon le type (livre, CD,
DVD )

PROBLEMES GENERES PAR LA SEPARATION DES DONNEES ET DES TRAITEMENTS :
Examinons le problme de l'volution de code fonctionnel plus en dtail...
Faire voluer une application de gestion de bibliothque pour grer une mdiathque, afin
de prendre en compte de nouveaux types d'ouvrages (cassettes vido, CD-ROM, etc...),
ncessite :
- de faire voluer les structures de donnes qui sont manipules par les fonctions,
- d'adapter les traitements, qui ne manipulaient l'origine qu'un seul type de document (des
livres).

Il faudra donc modifier toutes les portions de code qui utilisent la base documentaire, pour grer les
donnes et les actions propres aux diffrents types de documents.

Il faudra par exemple modifier la fonction qui ralise l'dition des "lettres de rappel" (une lettre de
rappel est une mise en demeure, qu'on envoie automatiquement aux personnes qui tardent rendre
un ouvrage emprunt). Si l'on dsire que le dlai avant rappel varie selon le type de document
emprunt, il faut prvoir une rgle de calcul pour chaque type de document.

En fait, c'est la quasi-totalit de l'application qui devra tre adapte, pour grer les nouvelles
donnes et raliser les traitements correspondants. Et cela, chaque fois qu'on dcidera de grer
un nouveau type de document !

1ERE AMELIORATION : RASSEMBLER LES VALEURS QUI CARACTERISENT UN TYPE, DANS
LE TYPE
Une solution relativement lgante la multiplication des branches conditionnelles et des
redondances dans le code (consquence logique d'une trop grande ouverture des donnes), consiste
tout simplement centraliser dans les structures de donnes, les valeurs qui leurs sont propres.
Par exemple, le dlai avant rappel peut tre dfini pour chaque type de document. Cela
permet donc de crer une fonction plus gnrique qui sapplique tous les types de
documents.

2EME AMELIORATION : CENTRALISER LES TRAITEMENTS ASSOCIES A UN TYPE, AUPRES DU
TYPE
Pourquoi ne pas aussi rassembler dans une mme unit physique les types de donnes et tous
les traitements associs ?

Que se passerait-il par exemple si l'on centralisait dans un mme fichier, la structure de donnes qui
dcrit les documents et la fonction de calcul du dlai avant rappel ? Cela nous permettrait de
retrouver immdiatement la partie de code qui est charge de calculer le dlai avant rappel d'un
document, puisqu'elle se trouve au plus prs de la structure de donnes concerne.

Ainsi, si notre mdiathque devait grer un nouveau type d'ouvrage, il suffirait de modifier une seule
fonction (qu'on sait retrouver instantanment), pour assurer la prise en compte de ce nouveau type
de document dans le calcul du dlai avant rappel. Plus besoin de fouiller partout dans le code...
Ecrit en ces termes, le logiciel serait plus facile maintenir et bien plus lisible. Le stockage et le calcul
du dlai avant rappel des documents, serait dsormais assur par une seule et unique unit
physique (quelques lignes de code, rapidement identifiables).

Pour accder la caractristique "dlai avant rappel" d'un document, il suffit de rcuprer la valeur
correspondante parmi les champs qui dcrivent le document. Pour assurer la prise en compte d'un
nouveau type de document dans le calcul du dlai avant rappel, il suffit de modifier une seule
fonction, situe au mme endroit que la structure de donnes qui dcrit les documents.

Document
Code document
Nom document
Type document
Calculer date rappel


Centraliser les donnes d'un type et les traitements associs, dans une mme unit physique,
permet de limiter les points de maintenance dans le code et facilite l'accs l'information en
cas d'volution du logiciel.

II.1.2 Lapproche objet
LE CONCEPT DOBJET
Les modifications qui ont t apportes au logiciel de gestion de mdiathque, nous ont
amen transformer ce qui tait l'origine une structure de donnes, manipule par des
fonctions, en une entit autonome, qui regroupe un ensemble de proprits cohrentes et de
traitements associs. Une telle entit s'appelle... un objet et constitue le concept fondateur de
l'approche du mme nom.
Un objet est une entit aux frontires prcises qui possde une identit (un nom).
Un ensemble d'attributs caractrise l'tat de l'objet.
Un ensemble d'oprations (mthodes) en dfinissent le comportement.
Un objet est une instance de classe (une occurrence d'un type abstrait).
Une classe est un type de donnes abstrait, caractris par des proprits (attributs et
mthodes) communes des objets et permettant de crer des objets possdant ces
proprits.

Document
+ code document: int
+ nom document: String
+ T + type document: String
+ Calculer date rappel () : Date

Classe : regroupement dobjets

MERISE_UML_document
C1
De Merise vers UML
Support de cours
Objet : instance dune classe

LES AUTRES CONCEPTS IMPORTANTS DE L'APPROCHE OBJET.
lencapsulation
Lencapsulation consiste masquer les dtails d'implmentation d'un objet, en dfinissant une
interface.
L'interface est la vue externe d'un objet, elle dfinit les services accessibles (offerts) aux
utilisateurs de l'objet.
L'encapsulation facilite l'volution d'une application car elle stabilise l'utilisation des
objets : on peut modifier l'implmentation des attributs d'un objet sans modifier son interface.
L'encapsulation garantit l'intgrit des donnes, car elle permet d'interdire l'accs direct aux
attributs des objets.
lhritage
L'hritage est un mcanisme de transmission des proprits d'une classe (ses attributs et
mthodes) vers une sous-classe.
Une classe peut tre spcialise en d'autres classes, afin d'y ajouter des caractristiques
spcifiques ou d'en adapter certaines.

Plusieurs classes peuvent tre gnralises en une classe qui les factorise, afin de regrouper les
caractristiques communes d'un ensemble de classes.
La spcialisation et la gnralisation permettent de construire des hirarchies de classes.
L'hritage peut tre simple ou multiple.
L'hritage vite la duplication et encourage la rutilisation.

Le polymorphisme
Le polymorphisme reprsente la facult d'une mme opration de s'excuter diffremment
suivant le contexte de la classe o elle se trouve.
Ainsi, une opration dfinie dans une superclasse peut s'excuter de faon diffrente selon la sous-
classe o elle est hrite.
Ex : excution d'une opration de calcul des salaires dans 2 sous-classes spcialises : une pour les
cadres, l'autre pour les non-cadres.

Le polymorphisme augmente la gnricit du code.


lagrgation
Il s'agit d'une relation entre deux classes, spcifiant que les objets d'une classe sont des
composants de l'autre classe.
Une relation d'agrgation permet donc de dfinir des objets composs d'autres objets.
L'agrgation permet d'assembler des objets de base, afin de construire des objets plus
complexes.

HISTORIQUE DE LAPPROCHE OBJET
Les concepts objet sont stables et prouvs (issus du terrain) :
- Simula, 1er langage de programmation implmenter le concept de type abstrait ( l'aide de
classes), date de 1967 !
- En 1976 dj, Smalltalk implmente les concepts fondateurs de l'approche objet (encapsulation,
agrgation, hritage) l'aide de :
classes
associations entre classes
hirarchies de classes
messages entre objets
- Le 1er compilateur C++ date de 1980, et C++ est normalis par l'ANSI.
- De nombreux langages orients objets acadmiques ont tays les concepts objets : Eiffel,
Objective C, Loops

Les concepts objet sont anciens, mais ils n'ont jamais t autant d'actualit :
- L'approche fonctionnelle n'est pas adapte au dveloppement d'applications qui voluent sans
cesse et dont la complexit croit continuellement.
- L'approche objet a t invente pour faciliter l'volution d'applications complexes.

De nos jours, les outils orients objet sont fiables et performants
- Les compilateurs C++ produisent un code robuste et optimis.
- De trs nombreux outils facilitent le dveloppement d'applications C++ :
bibliothques (STL, USL, Rogue Wave, MFC...)
environnements de dveloppement intgrs (Developper Studio, Sniff+...)
outils de qualimtrie et de tests (Cantata++, Insure++, Logiscope...)
bases de donnes orientes objet (O2, ObjectStore, Versant...)

INCONVENIENTS DE LAPPROCHE OBJET
L'approche objet est moins intuitive que l'approche fonctionnelle.
L'application des concepts objets ncessite une grande rigueur : le vocabulaire est prcis (risques
d'ambiguts, d'incomprhensions).

SOLUTIONS POUR REMEDIER AUX INCONVENIENTS DE LAPPROCHE OBJET
Il faut bnficier dun langage pour exprimer les concepts objet qu'on utilise, afin de
pouvoir :
- reprsenter des concepts abstraits (graphiquement par exemple).
- limiter les ambiguts (parler un langage commun).
- faciliter l'analyse (simplifier la comparaison et l'valuation de solutions).

Il faut galement une dmarche d'analyse et de conception objet, pour :
- ne pas effectuer une analyse fonctionnelle et se contenter d'une implmentation objet, mais
penser objet ds le dpart.
- dfinir les vues qui permettent de couvrir tous les aspects d'un systme, avec des concepts
objets.
II.2 La gense dUML
II.2.1 Historique des mthodes danalyse
LES PREMIERES METHODES D'ANALYSE (ANNEES 70)
Dcoupe cartsienne (fonctionnelle et hirarchique) d'un systme.
L'APPROCHE SYSTEMIQUE (ANNEES 80)
Modlisation des donnes + modlisation des traitements (Merise ...).
L'EMERGENCE DES METHODES OBJET (1990-1995)
Prise de conscience de l'importance d'une mthode spcifiquement objet :
- comment structurer un systme sans centrer l'analyse uniquement sur les donnes ou
uniquement sur les traitements (mais sur les deux) ?
- Plus de 50 mthodes objet sont apparues durant cette priode (Booch, Classe-
Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE...)!
- Aucune mthode ne s'est rellement impose.
LES PREMIERS CONSENSUS (1995)
- OMT (James Rumbaugh) : vues statiques, dynamiques et fonctionnelles d'un systme
o issue du centre de R&D de General Electric.
o Notation graphique riche et lisible.
- OOD (Grady Booch) : vues logiques et physiques du systme

o Dfinie pour le DOD, afin de rationaliser de dveloppement d'applications ADA, puis
C++.
o Ne couvre pas la phase d'analyse dans ses 1res versions (prconise SADT).
o Introduit le concept de package (lment d'organisation des modles).
- OOSE (Ivar Jacobson) : couvre tout le cycle de dveloppement
o Issue d'un centre de dveloppement d'Ericsson, en Sude.
o La mthodologie repose sur l'analyse des besoins des utilisateurs.

L'UNIFICATION ET LA NORMALISATION DES METHODES (1995-1997)
En octobre 1994, G. Booch (pre fondateur de la mthode Booch) et J. Rumbaugh
(principal auteur de la mthode OMT) ont dcid de travailler ensemble pour unifier leurs mthodes
au sein de la socit Rational Software. Un an aprs, I . Jacobson (auteur de la mthode OOSE et
des cas dutilisation) a rejoint Rational Software pour travailler sur lunification. Unified
Modified Language (UML) est n.
Les travaux sur ce langage ont continu avec son adoption par de grands acteurs industriels comme
HP, Microsoft, Oracle ou Unisys. Ce travail a abouti en 1997 UML 1.0. Le langage a t
soumis par Rational Software et ses partenaires lOMG comme rponse un appel doffres sur la
standardisation des langages de modlisation.
Lappel doffres de lOMG a recueilli un avis favorable, puisque 6 rponses concurrentes sont
parvenues lOMG. IBM et Object Time (mthode ROOM pour les systmes temps rel ractifs)
ont dcid de rejoindre lquipe UML ; leur proposition tait en fait une extension dUML 1.0.
Certains autres auteurs qui ont rpondu lappel doffres ont abandonn leur proposition pour
rejoindre leur tour UML. En novembre 1997, UML a t adopt par lOMG.
UML est donc le rsultat dun large consensus et tient compte des dernires avances en matire
de modlisation et de dveloppement logiciel.
L'OMG RTF (nombreux acteurs industriels) centralise et normalise les volutions d'UML au niveau
international et de nombreux groupes d'utilisateurs UML favorisent le partage des expriences.
II.2.2 Cadre dutilisation dUML
UML N'EST PAS UNE METHODE OU UN PROCESSUS
Si l'on parle de mthode objet pour UML, c'est par abus de langage.
Ce constat vaut aussi pour OMT ou d'autres techniques / langages de modlisation.
Une mthode propose aussi un processus, qui rgit notamment l'enchanement des activits de
production d'une entreprise. Or, UML a t pens pour permettre de modliser les activits de
l'entreprise, pas pour les rgir.
Des mthodes orientes objet les plus connues, seules les mthodes OOSE et BOOCH incluent
cet aspect processus de manire explicite et formelle. Ces 2 auteurs se sont dailleurs
toujours dmarqus des autres sur ce point.
Par leur nature, les processus doivent tre adapts aux organisations, leurs domaines
dactivit, leur culture
De ce fait, ni la normalisation ni la standardisation dun processus de dveloppement
logiciel ne peut faire lobjet dun consensus international suffisant pour aboutir un standard
acceptable et utilisable.

UML EST UN LANGAGE DE MODELISATION
UML est un langage de modlisation au sens de la thorie des langages. Il contient de ce
fait les lments constitutifs de tout langage, savoir : des concepts, une syntaxe et une
smantique.
De plus, UML a choisi une notation supplmentaire : il sagit dune forme visuelle fonde sur des
diagrammes. Si lunification dune notation est secondaire par rapports aux lments
constituant le langage, elle reste cependant primordiale pour la communication et la comprhension.
UML DECRIT UN META MODELE

UML est fond sur un mtamodle, qui dfinit :
- les lments de modlisation (les concepts manipuls par le langage),
- la smantique de ces lments (leur dfinition et le sens de leur utilisation).

Un mtamodle est une description trs formelle de tous les concepts d'un langage. Il limite
les ambiguts et encourage la construction d'outils.
Le mtamodle d'UML permet de classer les concepts du langage (selon leur niveau
d'abstraction ou domaine d'application) et expose sa structure.
Le mtamodle UML est lui-mme dcrit par un mta-mtamodle (OMG-MOF).
UML propose aussi une notation, qui permet de reprsenter graphiquement les lments de
modlisation du mtamodle.
Cette notation graphique est le support du langage UML.

UML offre :
- diffrentes vues (perspectives) complmentaires d'un systme, qui guident l'utilisation des
concepts objets
- plusieurs niveaux d'abstraction, qui permettent de mieux contrler la complexit dans l'expression
des solutions objets.
UML EST UN SUPPORT DE COMMUNICATION
Sa notation graphique permet d'exprimer visuellement une solution objet.
L'aspect formel de sa notation limite les ambiguts et les incomprhensions.
Son aspect visuel facilite la comparaison et l'valuation de solutions.
Son indpendance (par rapport aux langages d'implmentation, domaine d'application,
processus...) en font un langage universel.

II.2.3 Points forts dUML
UML est un langage formel et normalis
Il permet ainsi :
- un gain de prcision
- un gage de stabilit
- l'utilisation d'outils

UML EST UN SUPPORT DE COMMUNICATION PERFORMANT
Il cadre l'analyse et facilite la comprhension de reprsentations abstraites complexes. Son
caractre polyvalent et sa souplesse en font un langage universel.

II.2.4 Points faibles dUML
La mise en pratique d'UML ncessite un apprentissage et passe par une priode d'adaptation.
Mme si l'Espranto est une utopie, la ncessit de s'accorder sur des modes d'expression
communs est vitale en informatique. UML n 'est pas l'origine des concepts objets, mais
en constitue une tape majeure, car il unifie les diffrentes approches et en donne une
dfinition plus formelle.
Le processus (non couvert par UML) est une autre cl de la russite d'un projet.
L'intgration d'UML dans un processus n'est pas triviale et amliorer un processus est un tche
complexe et longue.

III. DEMARCHE GENERALE DE MODELISATION AVEC UML
III.1 Quest ce quun modle ?
III.1.1 Dfinition dun modle
Un modle est une abstraction de la ralit.
L'abstraction est un des piliers de l'approche objet : il s'agit d'un processus qui consiste
identifier les caractristiques intressantes d'une entit, en vue d'une utilisation prcise.
L'abstraction dsigne aussi le rsultat de ce processus, c'est--dire l'ensemble des
caractristiques essentielles d'une entit, retenues par un observateur.
Un modle est une vue subjective mais pertinente de la ralit. Un modle dfinit une frontire
entre la ralit et la perspective de l'observateur. Ce n'est pas "la ralit", mais une vue trs
subjective de la ralit.
Bien qu'un modle ne reprsente pas une ralit absolue, un modle reflte des aspects
importants de la ralit, il en donne donc une vue juste et pertinente.

III.1.2 Caractristiques fondamentales des modles
Le caractre abstrait d'un modle doit notamment permettre :
o de faciliter la comprhension du systme tudi : un modle rduit la complexit du
systme tudi.
o de simuler le systme tudi : un modle reprsente le systme tudi et reproduit ses
comportements.
III.2 Comment modliser avec UML ?
III.2.1 Proposition dune dmarche

UML est un langage qui permet de reprsenter des modles, mais il ne dfinit pas le
processus d'laboration des modles : UML nest donc pas une mthode de modlisation.

Cependant, dans le cadre de la modlisation d'une application informatique, les auteurs d'UML
prconisent d'utiliser une dmarche :
- itrative et incrmentale,
- guide par les besoins des utilisateurs du systme,
- centre sur l'architecture logicielle.

D'aprs les auteurs d'UML, un processus de dveloppement qui possde ces qualits devrait
favoriser la russite d'un projet.

UNE DEMARCHE ITERATIVE ET INCREMENTALE
Pour modliser (comprendre et reprsenter) un systme complexe, il vaut mieux s'y
prendre en plusieurs fois, en affinant son analyse par tapes.

Cette dmarche doit aussi s'appliquer au cycle de dveloppement dans son ensemble, en
favorisant le prototypage.

Le but est de mieux matriser la part d'inconnu et d'incertitudes qui caractrisent les systmes
complexes.

UNE DEMARCHE PILOTEE PAR LES BESOINS DES UTILISATEURS

Avec UML, ce sont les utilisateurs qui guident la dfinition des modles :
Le primtre du systme modliser est dfini par les besoins des utilisateurs (les utilisateurs
dfinissent ce que doit tre le systme). Le but du systme modliser est de rpondre aux besoins
de ses utilisateurs (les utilisateurs sont les clients du systme).

Les besoins des utilisateurs servent aussi de fil rouge, tout au long du cycle de
dveloppement (itratif et incrmental) :
- chaque itration de la phase d'analyse, on clarifie, affine et valide les besoins des utilisateurs.
- chaque itration de la phase de conception et de ralisation, on veille la prise en compte des
besoins des utilisateurs.
- chaque itration de la phase de test, on vrifie que les besoins des utilisateurs sont satisfaits.

UNE DEMARCHE CENTREE SUR L'ARCHITECTURE
Une architecture adapte est la cl de vote du succs d'un dveloppement.
Elle dcrit des choix stratgiques qui dterminent en grande partie les qualits du logiciel
(adaptabilit, performances, fiabilit...).

Ph. Kruchten propose diffrentes perspectives, indpendantes et complmentaires, qui
permettent de dfinir un modle d'architecture (publication IEEE, 1995). Ph. Kruchten dfend lide
que larchitecture logicielle doit tre une discipline part entire. Il propose que plusieurs
perspectives concourent lexpression de larchitecture dun systme et il explique quil est
ncessaire de garantir la sparation et lindpendance de ces diffrentes perspectives. Lvolution
de lune des perspectives ne doit pas avoir dimpact (sinon limit) sur les autres.

III.2.2 Les vues
LA VUE LOGIQUE
Cette vue concerne lintgrit de conception .
Cette vue de haut niveau se concentre sur l'abstraction et l'encapsulation, elle modlise les lments
et mcanismes principaux du systme.
Elle identifie les lments du domaine, ainsi que les relations et interactions entre ces
lments notions de classes et de relations :
- les lments du domaine sont lis au(x) mtier(s) de l'entreprise,
- ils sont indispensables la mission du systme,
- ils gagnent tre rutiliss (ils reprsentent un savoir-faire).

Cette vue organise aussi (selon des critres purement logiques), les lments du domaine en
"catgories" :
- pour rpartir les tches dans les quipes,
- regrouper ce qui peut tre gnrique,
- isoler ce qui est propre une version donne, etc...

LA VUE DES COMPOSANTS
Cette vue concerne lintgrit de gestion .
Elle exprime la perspective physique de lorganisation du code en termes de modules, de
composants et surtout des concepts du langage ou de lenvironnement dimplmentation.
Dans cette perspective, larchitecte est surtout concern par les aspects de gestion du code, dordre
de compilation, de rutilisation, dintgration et dautres contraintes de dveloppement pur.
Pour reprsenter cette perspective, UML fournit des concepts adapts tels que les modules, les
composants, les relations de dpendance, linterface

Cette vue de bas niveau (aussi appele vue de ralisation ), montre ainsi :

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

LA VUE DES PROCESSUS
Cette vue concerne lintgrit dexcution .
Cette vue est trs importante dans les environnements multitches ; elle exprime la
perspective sur les activits concurrentes et parallles. Elle montre ainsi :
- la dcomposition du systme en terme de processus (tches).
- les interactions entre les processus (leur communication).
- la synchronisation et la communication des activits parallles (threads).
LA VUE DE DEPLOIEMENT
Cette vue concerne lintgrit de performance . Elle exprime la rpartition du systme travers
un rseau de calculateurs et de nuds logiques de traitements . Cette vue est
particulirement utile pour dcrire la distribution dun systme rparti.
Elle montre :
- la disposition et nature physique des matriels, ainsi que leurs performances.
- l'implantation des modules principaux sur les nuds du rseau.
- les exigences en terme de performances (temps de rponse, tolrance aux fautes et pannes...).

LA VUE DES CAS DUTILISATION
Cette vue est particulire en ce sens quelle guide toutes les autres.
Cette vue permet :
- de trouver le bon modle
Les cas dutilisation permettent de guider la modlisation. Lutilisation des scnarios et des cas
dutilisation savre plus rigoureuse et plus systmatique que les entretiens et lanalyse des
documents pour dcouvrir les abstractions du domaine.
- dexpliquer et de justifier ses choix
Il est en effet ncessaire dexpliquer le systme, de justifier les choix qui ont guid sa
conception et son fonctionnement pour pouvoir le construire, le maintenir et le tester. Pour cela
UML offre des concepts adapts tels que les scnarios et les cas dutilisation.
III.3 Les niveaux dabstraction
UNE NON-DEMARCATION ENTRE CONCEPTION ET ANALYSE
UML opte pour l'laboration des modles, plutt que pour une approche qui impose une barrire
stricte entre analyse et conception :
- les modles d'analyse et de conception ne diffrent que par leur niveau de dtail, il n'y a pas de
diffrence dans les concepts utiliss.
- UML n'introduit pas d'lments de modlisation propres une activit (analyse, conception...) ; le
langage reste le mme tous les niveaux d'abstraction.
Cette approche simplificatrice facilite le passage entre les niveaux d'abstraction :
- l'laboration encourage une approche non linaire (les "retours en arrire" entre niveaux
d'abstraction diffrents sont facilits).
- la traabilit entre modles de niveaux diffrents est assure par l'unicit du langage.

LES NIVEAUX DABSTRACTION

Conceptualisation
L'entre de l'analyse ce niveau est le dossier d'expression des besoins client. A ce niveau
d'abstraction, on doit capturer les besoins principaux des utilisateurs.
Il ne faut pas chercher l'exhaustivit, mais clarifier, filtrer et organiser les besoins.
Le but de la conceptualisation est :
- de dfinir le contour du systme modliser (de spcifier le "quoi"),
- de capturer les fonctionnalits principales du systme, afin d'en fournir une meilleur
comprhension (le modle produit sert d'interface entre les acteurs du projet),
- de fournir une base la planification du projet.

Analyse du domaine
L'entre de l'analyse ce niveau, est le modle des besoins clients (les "cas d'utilisation"
UML).
Il s'agit de modliser les lments et mcanismes principaux du systme.
On identifie les lments du domaine, ainsi que les relations et interactions entre ces
lments :
- les lments du domaine sont lis au(x) mtier(s) de l'entreprise,
- ils sont indispensables la mission du systme,
- ils gagnent tre rutiliss (ils reprsentent un savoir-faire).

A ce stade, on organise aussi (selon des critres purement logiques), les lments du domaine
en "catgories", pour rpartir les tches dans les quipes, regrouper ce qui peut tre gnrique,
etc...
Analyse applicative
A ce niveau, on modlise les aspects informatiques du systme, sans pour autant rentrer dans
les dtails d'implmentation.
Les interfaces des lments de modlisation sont dfinis (cf. encapsulation). Les relations entre les
lments des modles sont dfinies.
Les lments de modlisation utiliss peuvent tre propres une version du systme.
Conception
On y modlise tous les rouages d'implmentation et on dtaille tous les lments de
modlisation issus des niveaux suprieurs.
Les modles sont optimiss, car destins tre implments.

III.4 Lutilisation des diagrammes
UML permet de dfinir et de visualiser un modle, l'aide de diagrammes.
III.4.1 Dfinition dun diagramme
Un diagramme UML est une reprsentation graphique, qui s'intresse un aspect prcis du
modle. C'est une perspective du modle, pas "le modle".
Chaque type de diagramme UML possde une structure (les types des lments de
modlisation qui le composent sont prdfinis).
Un type de diagramme UML vhicule une smantique prcise (un type de diagramme offre toujours
la mme vue d'un systme).
Combins, les diffrents types de diagrammes UML offrent une vue complte des aspects statiques
et dynamiques d'un systme.
Par extension et abus de langage, un diagramme UML est aussi un modle (un diagramme modlise
un aspect du modle global).

III.4.2 Caractristiques des diagrammes UML
Les diagrammes UML supportent l'abstraction. Leur niveau de dtail caractrise le niveau
d'abstraction du modle.
La structure des diagrammes UML et la notation graphique des lments de modlisation est
normalise (document "UML notation guide").

Rappel : la smantique des lments de modlisation et de leur utilisation est dfinie par le
mtamodle UML (document "UML semantics").
IV. LES DIFFERENTS TYPES DE DIAGRAMMES

UML 1.3 propose 9 diagrammes tandis quUML 2 en propose 13.
Il existe 2 types de vues du systme qui comportent chacune leurs propres diagrammes :

- les vues statiques :
diagrammes de cas d'utilisation
diagrammes d'objets
diagrammes de classes
diagrammes de composants
diagrammes de dploiement
Diagramme des paquetages
Diagramme de structure composite (UML2)

- les vues dynamiques :
diagrammes de collaboration
diagrammes de squence / Diagramme de communication (UML2)
diagrammes d'tats-transitions
diagrammes d'activits
Diagramme global d'interaction (UML2)
Diagramme de temps (UML2)
IV.1 Vues statique du systme
Le but de la conceptualisation est de comprendre et structurer les besoins du client. : Il ne faut pas
chercher l'exhaustivit, mais clarifier, filtrer et organiser les besoins.

Une fois identifis et structurs, ces besoins :
- dfinissent le contour du systme modliser (ils prcisent le but atteindre),
- permettent d'identifier les fonctionnalits principales (critiques) du systme.

Le modle conceptuel doit permettre une meilleure comprhension du systme.
Le modle conceptuel doit servir d'interface entre tous les acteurs du projet.

Les besoins des clients sont des lments de traabilit dans un processus intgrant UML.
Le modle conceptuel joue un rle central, il est capital de bien le dfinir.


IV.1.1 Diagrammes de cas d'utilisation

DEFINITION DU CAS D'UTILISATION (USE CASE)
Les use cases permettent de structurer les besoins des utilisateurs et les objectifs
correspondants d'un systme. Ils centrent l'expression des exigences du systme sur ses
utilisateurs : ils partent du principe que les objectifs du systme sont tous motivs.

La dtermination et la comprhension des besoins sont souvent difficiles car les intervenants
sont noys sous de trop grandes quantits dinformations : il faut clarifier et organiser les besoins
des clients (les modliser). Pour cela, les cas dutilisation identifient les utilisateurs du systme
(acteurs) et leurs interactions avec le systme. Ils permettent de classer les acteurs et structurer les
objectifs du systme.

Une fois identifis et structurs, ces besoins :
- dfinissent le contour du systme modliser (ils prcisent le but atteindre),
- permettent d'identifier les fonctionnalits principales (critiques) du systme.
Les use cases ne doivent donc en aucun cas dcrire des solutions d'implmentation.
Leur but est justement d'viter de tomber dans la drive d'une approche fonctionnelle, o l'on liste
une litanie de fonctions que le systme doit raliser.

ELEMENTS DE MODELISATION DES CAS D'UTILISATION
Lacteur :
La premire tape de modlisation consiste dfinir le primtre du systme, dfinir le
contour de lorganisation et le modliser. Toute entit qui est en dehors de cette organisation et
qui interagit avec elle est appel acteur selon UML.
Un acteur est un type strotyp reprsentant une abstraction qui rside juste en dehors du
systme modliser.
Un acteur reprsente un rle jou par une personne ou une chose qui interagit avec le systme (la
mme personne physique peut donc tre reprsente par plusieurs acteurs en fonction des rles
quelle joue).

Pour identifier les acteurs, il faut donc se concentrer sur les rles jous par les entits extrieures au
primtre.
Dans UML, il ny a pas de notion dacteur interne et externe. Par dfinition, un acteur est externe au
primtre de ltude, quil appartienne ou pas la socit.
Enfin, un acteur nest pas ncessairement une personne physique : il peut tre un service, une
socit, un systme informatique
Il existe 4 catgories dacteurs :
- les acteurs principaux : les personnes qui utilisent les fonctions principales du systme
- les acteurs secondaires : les personnes qui effectuent des tches administratives ou de
maintenance.
- le matriel externe : les dispositifs matriels incontournables qui font partie du domaine de
lapplication et qui doivent tre utiliss.
- les autres systmes : les systmes avec lesquels le systme doit interagir.

Formalisme :


Nom acteur

Le cas dutilisation
Le cas dutilisation (ou use case) correspond un objectif du systme, motiv par un besoin
dun ou plusieurs acteurs.
L'ensemble des use cases dcrit les objectifs (le but) du systme.

Formalisme :

La relation
Elle exprime linteraction existant entre un acteur et un cas dutilisation.

Formalisme :

Prospect

Il existe 3 types de relations entre cas dutilisation :
- la relation de gnralisation
- la relation dextension
- la relation dinclusion

La relation de gnralisation
Dans une relation de gnralisation entre 2 cas dutilisation, le cas dutilisation enfant est une
spcialisation du cas dutilisation parent.

Formalisme et exemple :

Nom du use case

Retirer argent


NB : un acteur peut galement participer des relations de gnralisation avec dautres
acteurs. Les acteurs enfant seront alors capables de communiquer avec les mmes cas
dutilisation que les acteurs parents .

Formalisme exemple :

La relation dinclusion
Elle indique que le cas dutilisation source contient aussi le comportement dcrit dans le cas
dutilisation destination. Linclusion a un caractre obligatoire, la source spcifiant quel endroit
le cas dutilisation cible doit tre inclus. Cette relation permet ainsi de dcomposer des
comportements et de dfinir des comportements partageables entre plusieurs cas dutilisation.

Cas
dutilisation
parent
Virement par
internet
Cas
dutilisation
Enfant
Virement
bancaire
Obtenir
informations
compte
Retirer
argent
Prospect
Client agence

Formalisme :

Pour raliser lobjectif virement , on utilise obligatoirement identification .

La relation dextension
Elle indique que le cas dutilisation source ajoute son comportement au cas dutilisation
destination. Lextension peut tre soumise condition. Le comportement ajout est insr au niveau
dun point dextension dfini dans le cas dutilisation destination. Cette relation permet de modliser
les variantes de comportement dun cas dutilisation (selon les interactions des acteurs et
lenvironnement du systme).

Formalisme :

Exemple :
<<extend>> Cas d'uti li sati on source
Cas d'uti li sati on desti nation
<<include>>

Virement

Identification

Paquetage
Un paquetage (package) est un groupement dlment de modlisation. Un paquetage peut contenir
aussi bien des paquetages embots que des lments de modlisation ordinaires.
Le systme entier peut tre pens comme un unique paquetage de haut niveau comprenant
lensemble. Tous les lments de modlisation dUML, y compris les diagrammes, peuvent tre
organiss en paquetage.
Les uses cases peuvent tre organiss en paquetages (packages).

Les scnarios
Un cas dutilisation est une abstraction de plusieurs chemins dexcution. Une instance de cas
dutilisation est appele : scnario .
Chaque fois quune instance dun acteur dclenche un cas dutilisation, un scnario est cr (le cas
dutilisation est instanci). Ce scnario suivra un chemin particulier dans le cas dutilisation.
<<extend>>
Reti rer argent
Veri fi er sol de

Un scnario ne contient pas de branche du type Si condition alors car pendant
lexcution, la condition est soit vraie, soit fausse, mais elle aura une valeur.
Aprs la description des cas dutilisation, il est ncessaire de slectionner un ensemble de scnarios
qui vont servir piloter litration en cours de dveloppement.
Le choix et le nombre de scnarios retenir est une tape difficile raliser : lexhaustivit est
difficile, voire impossible atteindre. Le nombre dinstances pour un cas dutilisation peut tre trs
important, voire infini.
Les scnarios peuvent tre classs en :
- scnarios principaux : il correspond linstance principal du cas dutilisation.
Cest souvent le chemin normal dexcution du cas dutilisation qui nimplique pas
derreurs.
- Scnarios secondaires : il peut tre un cas alternatif (un choix), un cas exceptionnel ou une
erreur.
Les scnarios sont utiles pour :
- analyser et concevoir le systme
- justifier les choix effectus (ils serviront la documentation des cas dutilisation)
- tester : les scnarios constituent le meilleur moyen de spcifier les tests.

ELABORATION DES CAS D'UTILISATION
Un cas dutilisation doit tre avant tout simple, intelligible et dcrit de manire claire et
concise. Le nombre dacteurs qui interagissent avec le cas dutilisation est souvent limit.
Il y a souvent un acteur pas cas dutilisation.

Lors de llaboration dun cas dutilisation, il faut se demander :
- quelles sont les tches de lacteur ?
- quelles informations lacteur doit-il crer, sauvegarder, modifier ou lire ?
- lacteur devra-t-il informer le systme des changements externes ?
- le systme devra-t-il informer lacteur des conditions internes ?
- quelles sont les conditions de dmarrage et darrt du cas dutilisation ?
Les cas dutilisation peuvent tre prsents travers de vues multiples : un acteur avec tous ses cas
dutilisation, un cas dutilisation avec tous ses acteurs

Un cas dutilisation est une abstraction : il dcrit de manire abstraite une famille de
scnarios. Il ne faut donc pas raliser trop de cas dutilisation car cela constituerait un
manque dabstraction. Dans nimporte quels systme, il y a relativement peu de cas
dutilisation mais beaucoup de scnarios. Un grand nombre de cas dutilisation signifie par
consquent que lessence du systme nest pas comprise.

UTILISATION DES CAS D'UTILISATION
La porte des cas dutilisation dpasse largement la dfinition des besoins du systme. Les
cas dutilisation interviennent tout au long du cycle de vie du projet, depuis le cahier des charges
jusquaux tests.

Intervenant Utilisateur Analyste Architecte Programmeur Testeur
Rle des cas
dutilisation
Exprimer Comprendre Concevoir raliser vrifier

Schma de matrialisation de lutilisation des cas dutilisation :

IV.1.2 Diagrammes de classes
DEFINITION DU DIAGRAMME DE CLASSES

Le diagramme de classes exprime la structure statique du systme en termes de classes et de
relations entre ces classes.
Lintrt du diagramme de classe est de modliser les entits du systme dinformation.
Le diagramme de classe permet de reprsenter lensemble des informations finalises qui sont
gres par le domaine. Ces informations sont structures, cest--dire quelles ont regroupes
dans des classes. Le diagramme met en vidence dventuelles relations entre ces classes.
Le diagramme de classes comporte 6 concepts :
- classe
- attribut
- identifiant
- relation
- opration
- gnralisation / spcialisation

LES NOTIONS UTILISEES PAR LE DIAGRAMME DE CLASSES
La notion de classe

Dfinition : une classe est une description abstraite (condense) dun ensemble dobjets du domaine
de lapplication : elle dfinit leur structure, leur comportement et leurs relations.
Reprsentation : les classes sont reprsentes par des rectangles compartiments :
- le 1
er
compartiment reprsente le nom de la classe
- le 2
me
compartiment reprsente les attributs de la classe
- le 3
me
compartiment reprsente les oprations de la classe

Formalisme :


Les compartiments dune classe peuvent tre supprims (en totalit ou en partie) 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.

Le rectangle qui symbolise une classe peut contenir un strotype et des proprits.
UML dfinit les strotypes de classe suivants :
- classe implmentation : il sagit de limplmentation dune classe dans un langage de
programmation
- numration : il sagit dune classe qui dfinit un ensemble didentificateurs formant le
domaine de la valeur.
- mtaclasse : il sagit de la classe dune classe, comme en Smalltalk
- powertype : une classe est un mtatype : ses instances sont toutes des sous-types dun type
donn
- processus : il sagit dune classe active qui reprsente un flot de contrles lourd
- thread : il sagit dune classe active qui reprsente un flot de contrles lger
- type : il sagit dune classe qui dfinit un domaine dobjets et les oprations applicables ces
objets.
- utilitaire : il sagit dune classe rduite au concept de module et qui ne peut tre instancie.
La notion dattribut
Dfinition : Une classe correspond un concept global dinformation et se compose dun ensemble
dinformations lmentaires, appeles attributs de classe.
Un attribut reprsente la modlisation dune information lmentaire reprsente par son nom et
son format.
Par commodit de gestion, on choisit parfois de conserver dans un attribut le rsultat dun calcul
effectu partir dautres classes : on parle alors dattribut driv. Pour reprer un attribut driv :
on place un / devant son nom.

Visibilit et porte des attributs :
UML dfinit 3 niveaux de visibilit pour les attributs :
1- public (+) : llment est visible pour tous les clients de la classe
2- protg (#) : llment est visible pour les sous-classes de la classe
3- priv (-) : llment nest visible que par les objets de la classe dans laquelle il est dclar.
La notion didentifiant
Lidentifiant est un attribut particulier, qui permet de reprer de faon unique chaque objet, instance
de la classe.
La notion dopration
Dfinition : lopration reprsente un lment de comportement des objets, dfini de manire
globale dans la classe.
Une opration est une fonctionnalit assure par une classe. La description des oprations peut
prciser les paramtres dentre et de sortie ainsi que les actions lmentaires excuter.
Visibilit et porte des oprations :
Comme pour les attributs, on retrouve 3 niveaux de visibilit pour les oprations :
NOM CLASSE
-
-
-
Attri but_1
Attri but_2
Attri but_3
: i nt
: i nt
: i nt
+
+
Operati on_1 ()
Operati on_2 ()
...
: voi d
: voi d

1- public (+) : lopration est visible pour tous les clients de la classe
2- protg (#) : lopration est visible pour les sous-classes de la classe
3- priv (-) : lopration nest visible que par les objets de la classe dans laquelle elle est dclare.
La notion de relation
Sil existe des liens entre objets, cela se traduit ncessairement par des relations qui existent
entre leurs classes respectives.
Les liens entre les objets doivent tre considrs comme des instances de relations entre classes.
Il existe plusieurs types de relations entre classes :
- lassociation
- la gnralisation/spcialisation
- la dpendance

Lassociation
Lassociation est la relation la plus courante et la plus riche du point de vue smantique.
Une association est une relation statique n-aire (le plus souvent : elle est binaire) : cest--dire quelle
relie plusieurs classes entre elles.
Lassociation existe entre les classes et non entre les instances : elle est introduite pour
montrer une structure et non pour montrer des changes de donnes.
Une association n-aire possde n rles qui sont les points terminaux de lassociation ou
terminaisons.
Chaque classe qui participe lassociation joue un rle. Les rles sont dfinis par 2
proprits :
- la multiplicit : elle dfinit le nombre dinstances de lassociation pour une instance de la
classe. La multiplicit est dfinie par un nombre entier ou un intervalle de valeurs. La
multiplicit est note sur le rle (elle est note lenvers de la notation MERISE).

1 Un et un seul
0..1 Zro ou un
N ou * N (entier naturel)
M..N De M N (entiers
naturels)
0..* De zros plusieurs
1..* De 1 plusieurs

Les valeurs de multiplicit expriment les contraintes lies au domaine de lapplication. Il est donc
important de dterminer les valeurs de multiplicit optimales pour trouver le bon quilibre entre
complexit et efficacit. La surestimation des valeurs de multiplicit entrane un surcot de
taille de stockage et en vitesse dexcution (requte avec plus de jointures).

- la navigabilit
La navigabilit na rien voir avec le sens de lecture de lassociation. Une navigabilit place
sur une terminaison cible indique si ce rle est accessible partir de la source.
Par dfaut les associations sont navigables dans les 2 sens. Dans certains cas, une seule
direction de navigation est utile : lextrmit dassociation vers laquelle la navigation est possible
porte alors une flche.

- Les classes-association
Les attributs dune classe dpendent fonctionnellement de lidentifiant de la classe. Parfois, un
attribut dpend fonctionnellement de 2 identifiants, appartenant 2 classes diffrentes.

Par exemple, lattribut quantit commande dpend fonctionnellement du numro de
commande et du code produit. On va donc placer lattribut quantit commande dans
lassociation comporter .
Dans ce cas, lassociation est dite porteuse dattributs .
Une association porteuse dattributs est appele classe-association.

- Lagrgation
Dans UML, lagrgation nest pas un type de relation mais une variante de lassociation.
Une agrgation reprsente une association non symtrique dans laquelle une des extrmits joue un
rle prdominant par rapport lautre extrmit.
Lagrgation ne peut concerner quun seul rle dune association.
Lagrgation se reprsente toujours avec un petit losange du ct de lagrgat.
Le choix dune association de type agrgation traduit la volont de renforcer la dpendance entre
classes. Cest donc un type dassociation qui exprime un couplage plus fort entre les classes.
Lagrgation permet de modliser des relations de type matre et esclaves.
Lagrgation permet de modliser une contrainte dintgrit et de dsigner lagrgat comme
contrainte.
A travers une telle contrainte, il est possible de reprsenter par exemple :
- la propagation des valeurs dattributs dune classe vers une autre classe
- une action sur une classe qui implique une action sur une autre classe
- une subordination des objets dune classe une autre classe


Lexemple ci-dessus montre que lon veut grer une classification de vhicules. Chaque vhicule
est classifi selon son type. En consquence, il sera possible de prendre connaissance pour un
vhicule de lensemble des caractristiques du type de vhicule auquel il est associ.

NB : un agrgat peut tre multiple. Dans lexemple ci-dessous, un vhicule peut appartenir
plusieurs types.

Cas particulier des associations rflexives :
Commande
- no commande : int
Produit
- code produi t : int
classe_associati on
- quantit commande : int
1..1
0..*
Type Vehi cul e
1..*
0..*
Type Vehi cul e

On peut avoir des cas dagrgation rflexive ds que lon modlise des relations hirarchiques
ou des liens de parent par exemple.

- La composition
La composition est un cas particulier de lagrgation dans laquelle la vie des composants est lie
celle des agrgats. Elle fait souvent rfrence une contenance physique. Dans la composition
lagrgat ne peut tre multiple.
La composition implique, en plus de lagrgation, une concidence des dures de vie des
composants : la destruction de lagrgat (ou conteneur) implique automatiquement la
destruction de tous les composants lis.


La gnralisation / spcialisation

LE PRINCIPE DE GENERALISATION / SPECIALISATION
Le principe de gnralisation / spcialisation permet didentifier parmi les objets dune
classe (gnrique) des sous-ensembles dobjets (des classes spcialises) ayant des dfinitions
spcifiques. La classe plus spcifique (appele aussi classe fille, classe drive,
classe spcialise, classe descendante ) est cohrente avec la classe plus gnrale (appele
aussi classe mre, classe gnrale ), cest--dire quelle contient par hritage tous les attributs, les
membres, les relations de la classe gnrale, et peut contenir dautres.

Les relations de gnralisation peuvent tre dcouvertes de 2 manires :
- la gnralisation : il sagit de prendre des classes existantes dj mises en
vidences) et de crer de nouvelles classes qui regroupent leurs parties communes ; il faut aller
du plus spcifique au plus gnral.
Parent
Enfant
2
*
PERSONNE
1..*
1..1
1..*
1..1
VEHICULE
CHASSIS
MOTEUR

- La spcialisation : il sagit de slectionner des classes existantes (dj identifies) et den
driver des nouvelles classes plus spcialises, en spcifiant simplement les diffrences.
Ces 2 dmarches, mme si elles sont fondamentalement diffrentes, mnent au mme
rsultat, savoir la constitution dune hirarchie de classes relies par des relations de
gnralisation.

La relation de gnralisation est trs puissante car elle permet de construire simplement de
nouvelles classes partir de classes existantes. Cependant, elle est trs contraignante dans
le sens o elle dfinit une relation trs forte entre les classes. Ainsi, lvolution dune classe
de base entrane une volution de toutes les classes qui en drivent. Cet effet boule de neige peut
avoir des consquences aussi bien positives (quand cest leffet recherch) que ngatives.

La dpendance
Les relations de dpendance sont utilises lorsquil existe une relation smantique entre
plusieurs lments qui nest pas de nature structurelle. Une relation de dpendance dfinit une
relation unidirectionnelle entre un lment source et un lment cible.
Une dpendance est une relation entre deux lments de modlisation dans laquelle toute
modification effectue sur un lment de modlisation (l'lment influent) affecte l'autre
lment (lment dpendant).

UML dfinit 4 types de relation de dpendance. Pour chaque type de dpendance, un mot cl ou
strotype entre guillemets peut tre ajout la relation de dpendance pour prciser sa nature.
Les 4 types de relation sont :
- abstraction
Il sagit dune relation de dpendance entre lments qui reprsentent un mme concept
diffrents niveaux dabstraction ou selon des points de vue distincts.

Les mots-cls sont :
drive
Reprsente un lment dfini ou calcul partir dun autre. Par exemple, un attribut ou un rle peut
driver dautres attributs ou rles.
raffine
Reprsente une relation de dpendance entre des lments smantiques diffrents (analyse
et conception par exemple).
ralise
Reprsente une relation de dpendance entre une spcification (cible) et llment qui
implmente cette spcification (source)
trace

Reprsente lhistorique des constructions prsentes dans les diffrents modles.

- Liaison
Les paramtres formels dune classe ou collaboration paramtrables doivent tre lis des valeurs.
Cette dpendance cre une liaison entre la classe ou collaboration paramtrable (la cible) et la classe
ou collaboration paramtre (source).
lie
- Permission
Un lment (source) a le droit daccder un espace de nommage (cible)
ami
Reprsente un lment source (paquetage, classe, opration ) qui a accs llment
destination (paquetage, classe, opration ) quelle que soit la spcification de visibilit de ce dernier.
- Utilisation
Un lment (source) requiert la prsence dun autre lment (cible) pour son bon
fonctionnement ou son implmentation.
utilise
appelle
Reprsente une relation de dpendance entre une opration qui invoque une opration dune
autre classe. Cette relation est reprsente en connectant les oprations ou les classes qui possdent
ces oprations.
cre
Reprsente le classificateur source qui cre une instance du classificateur cible
instancie
Reprsente une relation de dpendance entre classificateurs due la cration dune instance
du classificateur cible par une opration du classificateur source.

Formalisme :

Linterface
Une interface dfinit le comportement visible dune classe. Ce comportement est dfini par une
liste doprations ayant une visibilit public . Aucun attribut ou association nest dfini pour
une interface.
Une interface est en fait une classe particulire (avec le strotype interface ).
UML reprsente les interfaces :
- soit au moyen de petits cercles relis par un trait llment qui fournit les services dcrits
par linterface
- soit au moyen de classes avec le mot cl interface . Cette notation permet
<<deri ve>>
CLASSE A
CLASSE B

de faire figurer dans le compartiment des oprations la liste des services de linterface.

Les relations possibles sur une interface sont :
- la fourniture
Cette relation spcifie quune classe donne fournit linterface ses clients : cest--dire que la
classe possde cette interface.
Une classe peut fournir plusieurs interfaces ses clients et chaque interface dfinit un des services
de la classe. Cette technique permet de rduire la visibilit dune classe.
En effet, une classe qui expose ses oprations publiques les expose toutes les autres classes
du modle. Le concept dinterface permet une classe de dfinir plusieurs profils
en permettant chaque classe de nutiliser que le profil qui lintresse. Une classe peut ainsi
tre vue avec plusieurs perspectives diffrentes en fonction de la classe qui lutilise, ce qui
augmente la rutilisabilit.
- lutilisation
Cette relation concerne toute classe client qui souhaite accder la classe interface de
manire accder ses oprations. Cest une relation dutilisation standard.
- la ralisation
Cette relation nest utilise que pour les interfaces.
Une ralisation est une relation entre une classe et une interface. Elle montre que la classe ralise les
oprations offertes par l'interface.

Exemple :

Lexemple ci-dessus illustre la modlisation de 2 interfaces crdit et assurance dune classe banque.
Une relation de ralisation indique que la classe banque ralise linterface assurance.

Elaboration dun diagramme de classes
Gnralits
Un diagramme de classes est une collection d'lments de modlisation statiques (classes,
paquetages...), qui montre la structure d'un modle.
Un diagramme de classes fait abstraction des aspects dynamiques et temporels.
Pour un modle complexe, plusieurs diagrammes de classes complmentaires doivent tre
construits.
On peut par exemple se focaliser sur :
- les classes qui participent un cas d'utilisation (cf. collaboration),
- les classes associes dans la ralisation d'un scnario prcis,
- les classes qui composent un paquetage,
<<utilise>>
<<utilise>>
<<utilise>>
Entreprise
Client
<<interface>>
Assurance
Banque
Credit

- la structure hirarchique d'un ensemble de classes.

Pour reprsenter un contexte prcis, un diagramme de classes peut tre instanci en
diagrammes d'objets.

Rgles dlaboration
Les rgles de normalisation des modles entit-relation, issues de lalgbre relationnelle, peuvent
tre utilement appliques un modle de classes UML, mme si UML ne contient aucune
prconisation sur ces rgles.
Ces rgles aident conduire les travaux de modlisation en vitant le plus possible la
redondance de linformation, tout en restant fidle aux rgles de gestion.
IV.1.3 Diagrammes d'objets
Le diagramme dobjets permet de mettre en vidence des liens entre les objets. Les objets, instances
de classes, sont relis par des liens, instances dassociations.
A lexception de la multiplicit, qui est explicitement indique, le diagramme dobjets utilise les
mmes concepts que le diagramme de classes. Ils sont essentiellement utiliss pour comprendre
ou illustrer des parties complexes dun diagramme de classes.
IV.1.4 Diagrammes de composants
Les diagrammes de composants dcrivent les composants et leurs dpendances dans
lenvironnement de ralisation.
En gnral, ils ne sont utiliss que pour des systmes complexes.

Un composant est une vue physique qui reprsente une partie implmentable dun systme.
Un composant peut tre du code, un script, un fichier de commandes, un fichier de
donnes, une table Il peut raliser un ensemble dinterfaces qui dfinissent alors le
comportement offert dautres composants.

Formalisme :

UML dfinit 5 strotypes aux composants :
- document : un document quelconque
- excutable : un programme qui peut sexcuter
- fichier : un document contenant un code source ou des donnes
- bibliothque : une bibliothque statique ou dynamique
- table : une table de base de donnes relationnelle

Pour montrer les instances des composants, un diagramme de dploiement peut tre utilis.

IV.1.5 Diagrammes de dploiement
Les diagrammes de dploiement montrent la disposition physique des diffrents matriels
appels nuds(ordinateurs, priphriques, rseaux, systmes de stockage...) qui entrent dans la

composition dun systme et la rpartition des instances de composants, processus et objets qui
vivent sur ces matriels.
Les diagrammes de dploiement sont donc trs utiles pour modliser larchitecture physique
dun systme.

Exemple de diagramme de dploiement pour une application web

IV.1.6 Diagrammes des paquetages
Un paquetage tant un conteneur logique permettant de regrouper et d'organiser les lments
dans le modle UML, le Diagramme de paquetage sert reprsenter les dpendances entre
paquetages, cest--dire les dpendances entre ensembles de dfinitions.
IV.1.7 Diagramme de structure composite
Permet de dcrire sous forme de bote blanche les relations entre composants d'une classe.
IV.2 Vues dynamiques du systme :
Les cas dutilisation sont centrs sur les besoins des utilisateurs. Ils aident construire le bon
systme. Les cas dutilisation ne fournissent pas pour autant la bonne manire de faire le
systme, ni la forme de larchitecture logicielle : ils disent ce quun systme doit faire, non
comment il doit le faire.
La vue des cas dutilisation est une description fonctionnelle des besoins, structure par
rapport des acteurs. Le passage lapproche objet seffectue en associant une collaboration
chaque cas dutilisation.
Une collaboration dcrit les 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.
IV.2.1 Diagrammes de collaboration ou diagrammes de communication en UML 2
OBJECTIFS DU DIAGRAMME DE COLLABORATION
Le diagramme de collaboration permet de mettre en vidence les interactions entre les
diffrents objets du systme.
Dans le cadre de lanalyse, il sera utilis

- pour prciser le contexte dans lequel chaque objet volue
- pour mettre en vidence les dpendances entre les diffrents objets impliqus dans
lexcution dun processus ou dun cas dutilisation.
Un diagramme de collaboration fait apparatre les interactions entre des objets et les
messages quils changent.
LES INTERACTIONS
Une interaction dfinit la communication entre les objets sous la forme dun ensemble
partiellement ordonn de messages.
Lobjet metteur envoie un message lobjet rcepteur. Les objets reprsents dans les
diagrammes de collaboration ne sont pas ncessairement des instances dentits. Certains messages
peuvent avoir pour origine des acteurs que lon pourra reprsenter.

Formalisme : linteraction se reprsente par une flche avec un texte dcrivant le message.
Exemple dinteraction entre objets :

Exemple dinteraction entre un objet et un acteur ;

LES MESSAGES
Les messages sont le seul moyen de communication entre les objets. Ils sont dcrits
essentiellement par lobjet metteur et lobjet rcepteur. Leur description peut tre
complte par un nom, une squence, des arguments, un rsultat attendu, une
synchronisation, une condition dmission.
La squence permet de prciser lordre dmission des messages.


Le message 1 peut avoir comme arguments lintitul du produit souhait, la quantit et la catgorie
du client.


Certains messages peuvent solliciter un rsultat. Ce cas peut tre modlis de 2 faons :
- un message de demande et un message de rponse
- indiquer sur le premier message le rsultat attendu (lorsque le message en retour est attendu
immdiatement).

DIAGRAMME DE COMMUNICATION
Il est utilis depuis UML 2 pour la reprsentation simplifie d'un diagramme de squence se
concentrant sur les changes de messages entre les objets.
Exemple :

IV.2.2 Diagrammes de squence
Le diagramme de squence est une variante du diagramme de collaboration.
Par opposition aux diagrammes de collaboration, les diagrammes de squence possdent
intrinsquement une dimension temporelle mais ne reprsente pas explicitement les liens entre
les objets.

Ils privilgient ainsi la reprsentation temporelle la reprsentation spatiale et sont plus aptes
modliser les aspects dynamiques du systme.
En revanche, ils ne rendent pas compte du contexte des objets de manire explicite, comme les
diagrammes de collaboration.

Le diagramme de squence permet de visualiser les messages par une lecture de haut en bas. Laxe
vertical reprsente le temps, laxe horizontal les objets qui collaborent. Une ligne verticale en
pointill est attache chaque objet et reprsente sa dure de vie.

Les messages sont reprsents comme dans le diagramme de collaboration. (NB : un message
de retour sera reprsent avec des traits en pointills)

Exemple :

LES INTERACTIONS
Linteraction se traduit par lenvoi dun message entre objets. Le diagramme de squence insiste sur
la chronologie des objets en utilisant la ligne de vie des objets.

LES ACTIVATIONS
Les diagrammes de squence permettent 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.

Formalisme : les priodes dactivit se reprsentent par des bandes rectangulaires places sur la
ligne de vie des objets.


LES CATEGORIES DE MESSAGE
Les diagrammes de squence distinguent 3 catgories denvois de message :
- flot de contrle plat
Cette catgorie denvois est utilise pour indiquer la progression vers la prochaine tape dune
squence.
Formalisme : une flche simple symbolise de tels messages.

Alternativement, une demi-flche peut tre utilise pour reprsenter explicitement des
messages asynchrones pour des systmes concurrents (la flche pleine correspond alors un
message avec attente de prise en compte).

- appel de procdure (ou flot de contrle embot)
Dans un contrle embot, la squence embote doit se terminer pour que la squence
englobante reprenne le contrle.
Un objet poursuit donc son excution une fois le comportement initi par le message
termin.

Formalisme : Des flches extrmits pleines symbolisent de tels messages.


Lobjet 1 rcupre le contrle quand lobjet 2 a fini sa tche.

- Retour de procdure
Le retour de procdure est implicite la fin dune activation. Nanmoins, en cas denvois de
messages asynchrones, il savre utile pour montrer la fin de lexcution dune sous-procdure et
le renvoi ventuel de paramtres.

LES MESSAGES REFLEXIFS
Un objet peut senvoyer un message.
Formalisme : Cette situation se reprsente par une flche qui revient en boucle sur la ligne de vie de
lobjet.


LES CONTRAINTES TEMPORELLES
Une 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.
Des annotations temporelles concernent les messages peuvent galement tre ajoutes.
Exemple :

LA LIGNE DE VIE
La ligne de vie des objets est reprsente par une ligne verticale en traits pointills, place sous le
symbole de lobjet concern. Cette ligne de vie prcise lexistence de lobjet concern durant
un certain laps de temps.
En gnral, une ligne de vie est reprsente sur toute la hauteur du diagramme de squence.
Par contre, elle peut dbuter et sinterrompre lintrieur du diagramme.

Formalisme : la cration 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 croix (X), soit la hauteur du message qui cause la destruction, soit aprs le dernier
message envoy par un objet qui se suicide.


Pour reprsenter la collaboration entre les objets, on dispose donc dans UML de 2 diagrammes
(collaboration et squence). On peut utiliser lun ou lautre, voire les 2.
On peut ainsi dcrire lensemble des interactions avec des messages complets (nom, squence,
rsultat attendu, synchronisation et condition dmission) sur un diagramme de collaboration et
complter cette description par des diagrammes de squence ne visualisant que les noms des
messages.

IV.2.3 Diagrammes d'tats-transitions
Ils ont pour rle de reprsenter les traitements (oprations) qui vont grer le domaine tudi.
Ils dfinissent l'enchanement des tats de classe et font donc apparatre l'ordonnancement des
travaux.
Le diagramme d'tats-transition est associ une classe pour laquelle on gre diffrents
tats : il permet de reprsenter tous les tats possibles ainsi que les vnements qui
provoquent les changements d'tat.
Caractristiques et rgles de construction
Etat
Un tat correspond une situation durable dans laquelle se trouvent les objets d'une classe.
On lui associe les rgles de gestion et les activits particulires.
Etat : objets d'une classe
+ rgles de gestion
+ changements d'tats
La reprsentation symbolique des tats d'une classe d'objets est la suivante (rectangle aux bords
arrondis) :

Exemple pour une commande :
Etat "en prparation"
Etat "en cours"
Evnements et transitions
Un objet passe d'un tat un autre suite un vnement, certains vnements pouvant ne pas
provoquer de changement d'tat.
Une transition est une relation entre 2 tats. Elle est oriente ce qui signifie que l'tat 2 est possible
si certains vnements sont vrifis.
Sa reprsentation symbolique est une flche sur laquelle est annot l'vnement qui concourt
au changement d'tat.

Exemple : Une commande passera dans l'tat "En attente" ds lors qu'elle aura t expdie
Expdition


Les traitements
Les oprations de description des classes sont dcrites dans le diagramme d'tats-transitions
sous forme d'actions et d'activits.
Une action est une opration lmentaire et instantane. Elle peut tre associe
l'vnement lui-mme ou l'entre dans l'tat ou la sortie de l'tat
Une activit est une opration qui dure et qui est donc associe un tat. Elle peut tre
squentielle ou cyclique :
- La fin d'une activit squentielle correspond la sortie de ltat : une transition
automatique est gnre.
- une activit cyclique ne se termine que par une transition de sortie identifie.

Exemple de formalisme sur une commande "en prparation" :

La hirarchie des tats
Pour faciliter la comprhension de traitements complexes, il est possible de crer des
supertats qui contiendront des actions et activits communes d'autres tats (sous-tats).
Les tats prdfinis
Deux tats sont prdfinis :
- l'tat initial d'un objet : il est obligatoire et unique
- l'tat final : selon les vnements, il peut exister plusieurs tats finaux
Leurs symbolismes sont les suivants :


IV.2.4 Diagrammes d'activits
Le diagramme d'activit est attach une catgorie de classe et dcrit le droulement des activits
de cette catgorie. Le droulement s'appelle "flot de contrle". Il indique la part prise par chaque
objet dans l'excution d'un travail. Il sera enrichi par les conditions de squencement.
Il pourra comporter des synchronisations pour reprsenter les droulements parallles.
La notion de couloir d'activit va dcrire les responsabilits en rpartissant les activits entre
les diffrents acteurs oprationnels.

LE DEROULEMENT SEQUENTIEL DES ACTIVITES
Le diagramme d'tats-transitions vu prcdemment prsente dj un squencement des
activits d'une classe.

Le diagramme d'activits va modifier cette reprsentation pour n'en conserver que le
squencement. La notion d'tat disparat. On obtient ce graphe :

Comme dans le diagramme d'tats-transitions, la transaction peut tre complte par une
condition de garde.

LA SYNCHRONISATION
Les flots de contrle parallles sont spars ou runis par des barres de synchronisation.
Les activits 2 et 3 seront simultanes.

LES COULOIRS D'ACTIVITES
Le diagramme d'activits fait intervenir les acteurs de chaque activit. Chaque activit sera place
dans une colonne (couloir) qui correspond l'acteur.
IV.2.5 Diagramme global dinteraction
Permet de dcrire les enchanements possibles entre les scnarios pralablement identifis
sous forme de diagrammes de squences (variante du diagramme d'activit).

IV.2.6 Diagramme de temps
Permet de dcrire les variations d'une donne au cours du temps.

IV.3 Modlisation et association des diagrammes / outils de modlisation
IV.3.1 Modlisation et association des diagrammes
UML tant un langage de modlisation, nimpose pas une mthode de travail. Pour la
ralisation dun projet, lutilisation de tous les diagrammes nest pas obligatoire. Leur utilisation varie
en fonction des exigences et des fonctionnalits du systme tudi.
Le tableau ci-dessous rsume lutilisation de quelques diagrammes pour la ralisation de chaque
phase dun projet.

Besoins des utilisateurs : spcifier le systme en
dfinissant les acteurs, les cas dutilisation et les
associations quivalentes)

Diagramme de cas dutilisation
Interactions entre objets : Modliser les objets
communicants en identifiant et en nommant les instances
(objets physiques puis abstraits), on spcifie les liens entre
les objets et les messages transitant par ces liens.)

Diagramme de squence
Diagramme de collaboration

Structure statique : Modliser la structure de lapplication
Diagramme de classes
Diagramme objet
Diagramme de packages
Dynamique des objets : Modliser le comportement des
objets et les traitements.
Diagramme tats -transition
Diagramme dactivits

Ralisation et dploiement : Modliser limplantation de
lapplication
Diagramme de composants
Diagramme de dploiement

RECAPITULATIF DE LA CHAINE COMPLETE DE LA DEMARCHE DE MODELISATION JUSQUAU CODE


Cependant des mthodes pour accompagner la modlisation avec UML ont t cres (RUP, UP, 2TUP
les mthodes argiles, OMT). Il est nanmoins conseill dutiliser une mthode de modlisation
existante car avant tout, une bonne dmarche permet de :
Bien comprendre les demandes et exigences des utilisateurs finaux
Bien communiquer avec le client
Tenir compte des changements du cahier des charges
Empcher la dcouverte tardive de dfauts srieux dans le projet dans le projet
Traiter au plus tt tous les points critiques du projet
Bien matriser la complexit
Favoriser la rutilisation
Dfinir une architecture robuste
Faciliter le travail en quipe.

IV.3.2 Les outils de modlisation
Voici une liste non exhaustive des logiciels de modlisation des diagrammes en UML.
Logiciels libres :
Neptune outil permettant de vrifier les modles UML1.x via des rgles OCL ;
ATL solution open source pour faire des transformations de modles vers ou depuis UML (entre
autres); ATL est un langage de type QVT ;
Dia, logiciel de diagrammes pour GNOME ;
Umbrello UML Modeller un modeleur UML sous GPL.
ArgoUml un modeleur UML sous Licence BSD ;
Gaphor un modeleur UML sous GPL ;
BOUML, un modeleur UML sous GPL pour Windows, Linux, MacOS X et Solaris ;
Eclipse GMT-UMLX ;
Eclipse UML2, Mta modle UML2, sans interface graphique ;
Netbeans [1], logiciel open source de Sun ;
Papyrus un modeleur UML2 open source pour la plateforme Eclipse Licence EPL ;
PauWare moteur d'excution Java des State Machine Diagrams et Sequence Diagrams d'UML 2 ;
Staruml, logiciel libre ;
Acceleo, gnrateur de code source partir de modles UML ;
AndroMDA, atelier de gnration de code partir de modles tels UML sous licence BSD ; des
gnrateurs diverses comme J2EE ou .NET sont disponibles ;
Topcased atelier open source en cours de dveloppement bas sur la platerforme eclipse qui
propose un diteur UML2.
Delphia Object Modeler (version personnelle), Outil de modlisation et de prototypage.
Diagrammes de classe et d'tat. Langage objet intgr. Gnrateur de Java ;
Violet UML modeleur UML, autonome ou plugin pour clipse

Logiciels propritaires
Enterprise Architect, un outil de modlisation UML ;
Jude [2], en Java ;
MagicDraw, un diteur de diagrammes UML ;
Objecteering d'Objecteering Software ;
Omondo EclipseUML, un plugin UML pour Eclipse;
Poseidon (version commerciale), bas sur ArgoUml (logiciel libre);
PowerAMC/PowerDesigner [3], de Sybase (un outil de modlisation complet intgrant l'UML en
plus des classiques MCD, MPD ...) ;
Rhapsody de Telelogic pour une modlisation PSM (Platform Specific Model) complte de
systmes ou de logiciels embarqus ;
Rational Software Architect / Rational Software Modeler (et toujours Rose/XDE), de IBM Software
Rational ;
SDE for Eclipse, un plugin UML pour Eclipse ;
Telelogic TAU de Telelogic pour la modlisation PIM (Platform Independant Model) de systmes
ou de logiciels, pour la modlisation d'architectures SOA ou l'implmentation d'applications pour
architecture SOA ;
Together, de Borland ;
Visual Paradigm for UML, de Visual Paradigm Internation Ltd.;
Delphia Object Modeler (version commerciale), Outil de modlisation et de prototypage.
Diagrammes de classe et d'tat. Langage objet intgr. Gnrateur de Java ;

IV.3.3 Quelques langages de programmation orients objet
Ada
C++ (voir aussi la catgorie C++)
C#
Delphi (=Pascal orient objet)
Java
Kylix
Objective-C
Objective Caml (ocaml)
Perl
PHP (Depuis la version 4)
Python
SmallTalk (totalement objet)
Ruby
Etc.

V. ETUDE DUNE METHODE DE MODELISATION SAPPUYANT SUR
UML: LE PROCESSUS UNIFIE (UP)
Le processus unifi (Unified process en anglais) est un processus de dveloppement logiciel : il
regroupe les activits mener pour transformer les besoins dun utilisateur en systme logiciel.

Caractristiques essentielles du processus unifi :
- Le processus unifi est base de composants,
- Le processus unifi utilise le langage UML (ensemble d'outils et de diagramme),
- Le processus unifi est pilot par les cas dutilisation,
- Centr sur larchitecture,
- Itratif et incrmental.
V.1 Le processus unifi est pilot par les cas dutilisation
V.1.1 Prsentation gnrale
Lobjectif principal dun systme logiciel est de rendre service ses utilisateurs ; il faut par
consquent bien comprendre les dsirs et les besoins des futurs utilisateurs. Le processus de
dveloppement sera donc centr sur l'utilisateur. Le terme utilisateur ne dsigne pas seulement les
utilisateurs humains mais galement les autres systmes. Lutilisateur
reprsente donc une personne ou une chose dialoguant avec le systme en cours de
dveloppement.
Ce type dinteraction est appel cas dutilisation.
Les cas dutilisation font apparatre les besoins fonctionnels et leur ensemble constitue le modle
des cas dutilisation qui dcrit les fonctionnalits compltes du systme.

Nous ne sommes pas dans une approche de type fonctionnelle mais une approche pilote par des
cas d'utilisation.
V.1.2 Stratgie des cas dutilisation
Les cas dutilisation ne sont pas un simple outil de spcification des besoins du systme. Ils vont
compltement guider le processus de dveloppement travers lutilisation de modles bass sur
lutilisation du langage UML.


A partir du modle des cas dutilisation, les dveloppeurs crent une srie de modles
de conception et dimplmentation ralisant les cas dutilisation.

Chacun des modles successifs est ensuite rvis pour en contrler la conformit par rapport
au modle des cas dutilisation.

Enfin, les testeurs testent limplmentation pour sassurer que les composants du modle
dimplmentation mettent correctement en uvre les cas dutilisation.

Les cas dutilisation garantissent la cohrence du processus de dveloppement du systme.
Sil est vrai que les cas dutilisation guident le processus de dveloppement, ils ne
sont pas slectionns de faon isole, mais doivent absolument tre dvelopps avec
larchitecture du systme.
V.2 Le processus unifi est centr sur larchitecture
Ds le dmarrage du processus, on aura une vue sur l'architecture mettre en place.
Larchitecture dun systme logiciel peut tre dcrite comme les diffrentes vues du systme
qui doit tre construit. Larchitecture logicielle quivaut aux aspects statiques et dynamiques les
plus significatifs du systme. Larchitecture merge des besoins de lentreprise, tels quils sont
exprims par les utilisateurs et autres intervenants et tels quils sont reflts par les cas dutilisation.
Elle subit galement linfluence dautres facteurs :
- la plate-forme sur laquelle devra sexcuter le systme ;
- les briques de bases rutilisables disponibles pour le dveloppement ;
- les considrations de dploiement, les systmes existants et les besoins non
fonctionnels (performance, fiabilit..)


V.2.1 Liens entre cas dutilisation et architecture
Tout produit est la fois forme et fonction. Les cas dutilisation doivent une fois raliss, trouver
leur place dans larchitecture. Larchitecture doit prvoir la ralisation de tous les cas dutilisation.
Larchitecture et les cas dutilisation doivent voluer de faon concomitante.

V.2.2 Marche suivre
Larchitecte cre une bauche grossire de larchitecture, en partant de laspect qui nest
pas propre aux cas dutilisation (plate forme..). Bien que cette partie de larchitecture soit
indpendante des cas dutilisation. Larchitecte doit avoir une comprhension globale de
ceux ci avant den esquisser larchitecture.

Il travaille ensuite, sur un sous ensemble des cas dutilisation identifis, ceux qui
reprsentent les fonctions essentielles du systme en cours de dveloppement.

Larchitecture se dvoile peu peu, au rythme de la spcification et de la
maturation des cas dutilisation, qui favorisent, leur tour, le dveloppement dun nombre
croissant de cas dutilisation.
Ce processus se poursuit jusqu ce que larchitecture soit juge stable.
V.2.3 Le processus unifi est itratif et incrmental
Le dveloppement dun produit logiciel destin la commercialisation est une vaste entreprise
qui peut stendre sur plusieurs mois. On ne va pas tout dvelopper dun coup.
On peut dcouper le travail en plusieurs parties qui sont autant de mini projets. Chacun
dentre eux reprsentant une itration qui donne lieu un incrment.
Une itration dsigne la succession des tapes de lenchanement dactivits, tandis quun
incrment correspond une avance dans les diffrents stades de dveloppement.

Le choix de ce qui doit tre implment au cours dune itration repose sur deux facteurs :
Une itration prend en compte un certain nombre de cas dutilisation qui ensemble, amliorent
lutilisabilit du produit un certain stade de dveloppement.
Litration traite en priorit les risques majeurs.

Un incrment constitue souvent un additif.

A chaque itration, les dveloppeurs identifient et spcifient les cas dutilisations
pertinents, crent une conception en se laissant guider par larchitecture choisie,
implmentent cette conception sous forme de composants et vrifie que ceux ci sont
conformes aux cas dutilisation. Ds quune itration rpond aux objectifs fixs le
dveloppement passe litration suivante.
Pour rentabiliser le dveloppement il faut slectionner les itrations ncessaires pour atteindre
les objectifs du projet. Ces itrations devront se succder dans un ordre logique.
Un projet russi suivra un droulement direct, tabli ds le dbut par les dveloppeurs et dont ils
ne sloigneront que de faon trs marginale. Llimination des problmes imprvus fait partie
des objectifs de rduction des risques.

Avantages dun processus itratif contrl

Permet de limiter les cots, en termes de risques, aux strictes dpenses lies une
itration.


Permet de limiter les risques de retard de mise sur le march du produit dvelopp
(identification des problmes ds les premiers stades de dveloppement et non en phase de test
comme avec lapproche classique ).

Permet dacclrer le rythme de dveloppement grce des objectifs clairs et court terme.

Permet de prendre en compte le fait que les besoins des utilisateurs et les exigences
correspondantes ne peuvent tre intgralement dfinis lavance et se dgagent peu peu des
itrations successives

Larchitecture fournit la structure qui servira de cadre au travail effectu au cours des
itrations, tandis que les cas dutilisation dfinissent les objectifs et orientent le travail de chaque
itration. Il ne faut donc pas msestimer lun des trois concepts.
V.2.4 Le cycle de vie du processus unifi
Le processus unifi rpte un certain nombre de fois une srie de cycles.
Tout cycle se conclut par la livraison dune version du produit aux clients et sarticule en 4
phases : cration, laboration, construction et transition, chacune dentre elles se subdivisant
son tour en itrations.

Chaque cycle se traduit par une nouvelle version du systme. Ce produit se compose dun corps de
code source rparti sur plusieurs composants pouvant tre compils et excuts et saccompagne de
manuels et de produits associs. Pour mener efficacement le cycle, les dveloppeurs ont besoin
de construire toutes les reprsentations du produit logiciel :

Tous ces modles sont lis. Ensemble, ils reprsentent le systme comme un tout. Les
lments de chacun des modles prsentent des dpendances de traabilit ; ce qui facilite la
comprhension et les modifications ultrieures.


Prsentation du cycle de vie de UP (Unified process)

Phase Description et Enchanement dactivits

Phase de cration
Traduit une ide en vision de produit fini et
prsente une tude de rentabilit pour ce
produit
- Que va faire le systme pour les utilisateurs ?
- A quoi peut ressembler larchitecture dun tel
systme ?
- Quels sont lorganisation et les cots du
dveloppement de ce produit ?
On fait apparatre les principaux cas
dutilisation.
Larchitecture est provisoire, identification des
risques majeurs et planification de la phase
dlaboration.

Phase dlaboration
Permet de prciser la plupart des cas
dutilisation et de concevoir larchitecture du
systme. Larchitecture doit tre exprime
sous forme de vue de chacun des modles.
Emergence dune architecture de rfrence.
A lissue de cette phase, le chef de projet doit
tre en mesure de prvoir les activits et
destimer les ressources ncessaires
lachvement du projet.

Moment o lon construit le produit.
Larchitecture de rfrence se mtamorphose
en produit complet, elle est maintenant stable.

Phase de construction
Le produit contient tous les cas dutilisation
que les chefs de projet, en accord avec les
utilisateurs ont dcid de mettre au point pour
cette version.
Celle ci doit encore avoir des anomalies qui
peuvent tre en partie rsolue lors de la phase
de transition.

Phase de transition
Le produit est en version bta. Un groupe
dutilisateurs essaye le produit et dtecte les
anomalies et dfauts. Ce phase suppose des
activits comme la fabrication, la formation
des utilisateurs clients, la mise en uvre dun
service dassistance et la correction des
anomalies constates.(o le report de leur
correction la version suivante)

V.2.5 Conclusion : un processus intgr
Le processus unifi est bas sur des composants. Il utilise UML et est bas sur les cas
dutilisation, larchitecture et le dveloppement incrmental. Pour mettre en pratique ces ides il
faut recourir un processus multi-facettes prenant en considration les cycles, les phases, les
enchanements dactivits, la rduction des risques, le contrle qualit, la gestion de projet et la
gestion de configuration. Le processus unifi a mis en place un cadre gnral (framework) intgrant
chacune de ces facettes.
VI. ELEMENTS DE COMPARAISONS ENTRE MERISE ET UML

Il ne sagit pas ici dlire une mthode ou un langage numro 1 (UML nest pas le
remplaant de MERISE) mais dessayer de comprendre quels sont les apports de ces 2
dmarches et en quoi elles peuvent tres complmentaires.
Il conviendra ensuite au lecteur dadapter leur utilisation (qui peut tre combine) en fonction
du problme explorer.

Reprenons pour cela les principaux points cl de MERISE que nous comparerons un par un ceux
dUML :
- les principes
- la modlisation du mtier
- la dmarche
VI.1 Les principes
MERISE repose sur 5 principes fondamentaux :
- lapproche systmique
- les cycles de construction du systme dinformation
- lapproche fonctionnelle
- la sparation donnes-traitements
- approche qui part du gnral vers le particulier


VI.1.1 Lapproche systmique
MERISE trouve ses fondements dans la thorie systmique qui dcoupe lentreprise en 3 sous-
systmes :
- le systme de dcision
- le systme dinformation
- le systme oprant

Tout systme tudi ne doit pas ltre de faon tenir compte du systme complet dans lequel il
volue.

Dans UML, lapproche par les cas dutilisation constitue de ce fait une approche systmique.
Le systme tudi est considr comme une bote noire qui ragit des sollicitations
extrieurs qui sont formalises par des flches et dont lorigine est lacteur.
Les cas dutilisation traduisent ainsi la structure du systme modliser. La structure interne du
systme (compose dobjets) est modlise par les diagrammes de collaboration.

VI.1.2 Les cycles de construction du systme dinformation

MERISE est une dmarche qui repose sur 3 cycles :
- le cycle de vie
- le cycle dabstraction
- le cycle de dcision

LE CYCLE DE VIE
Dans la mthode Merise on distingue diffrentes priodes qui vont de la conception du
systme d'information sa maintenance. On se situe dans une situation dynamique en
considrant que le systme d'information va natre, grandir, tre entretenu puis va disparatre
et tre remplac par un autre.

UML ne dfinit pas de cycle de vie. Le cycle de dveloppement sous-jacent est itratif et incrmental,
guid par les cas dutilisation et centr sur larchitecture.

LE CYCLE DABSTRACTION
Dans MERISE, ce cycle permet disoler un niveau spcifique, les lments significatifs contribuant
la description du systme dinformation. Les niveaux conceptuel, logique ou organisationnel,
physique ou oprationnel se situent dans ce cycle.

UML offre plusieurs diagrammes pour modliser le systme aux diffrents niveaux
dabstraction (diagramme de squences, de classes ). Mais la diffrence de MERISE, il ny a pas
de diagramme spcifique par niveau dabstraction. Le formalisme UML est le mme tout au long
du processus de fabrication.
UML laisse le soin de prsenter les diagrammes cohrents qui contiennent des objets de mme
niveau de proccupation.

LE CYCLE DE DECISION
Il concerne les diffrentes dcisions et choix qui sont effectus tout au long du cycle de
vie, et permettent de faire valider petit petit le systme que l'on est en train de construire.
Ces dcisions marquent la fin d'une tape et le dbut d'une autre, ce sont des passages
obligs avant de poursuivre l'tude du projet. Ces tapes de validation sont fondamentales dans
MERISE et permettent l'appropriation du systme d'information par lensemble de la communaut.

UML, tout comme MERISE, se soucie dassocier troitement les utilisateurs dans les tches
danalyse et de conception (notamment au niveau des cas dutilisation).
VI.1.3 Lapproche fonctionnelle
MERISE propose une approche descendante o le systme rel est dcompos en activits, elles-
mmes dclines en fonctions.
Les fonctions sont composes de rgles de gestion, elles-mmes regroupes en oprations.
Ces rgles de gestion au niveau conceptuel gnrent des modules dcomposs en module
plus simple et ainsi de suite jusqu obtenir des modules lmentaires. Ceci correspond bien
aux langages de programmation structure mais la rutilisation des modules prsente des difficults.
En effet, les modules sont difficilement extensibles et exploitables pour de nouveaux systmes.

A ce niveau, UML se dmarque fortement de MERISE en proposant une architecture qui rend le
systme le plus indpendant possible des besoins, o les classes donnent naissance des
composants rutilisables dans diffrents contextes de besoins.
Le degr de rutilisabilit est donc plus fort dans UML mais ncessite un plus haut niveau
dabstraction.
VI.1.4 La sparation donnes-traitements
Tout au long de sa dmarche, la mthode MERISE est caractrise par les approches
conjointes et parallles des donnes et des traitements, approches qui se traduisent par des
modles spcifiques. Les modles de donnes rendent compte de laspect statique du systme
alors que les modles de traitement rendent compte des aspects dynamiques.

UML, tout comme MERISE, traite des donnes et des traitements. Mais au lieu de les sparer,
elle les associe.
Elle repose en effet sur une vritable approche objet qui intgre donnes et traitements.
VI.1.5 Lapproche qui part du gnral vers le particulier
MERISE reposant sur une dmarche fonctionnelle : elle applique une mthode de
type descendante : la vision globale du systme doit tre affine par intgrations successives
des diffrentes orientations retenues.

UML permet aussi bien une approche descendante quune approche ascendante.
Les diffrents diagrammes fournissent les supports pour matrialiser une dmarche progressive,
allant du global vers le dtaill.
Lavantage dUML rside dans le fait que le concept dobjet peut tre dclin sur tout le cycle
dabstraction, ce qui facilite une analyse ascendante.
VI.2 La modlisation mtier
Pour dcrire le mtier de lentreprise, MERISE sappuie sur les concepts de :
- domaine
- acteur
- flux
- modles conceptuels et organisationnels.
VI.2.1 Le domaine
Une des premires tapes dans MERISE consiste dlimiter le domaine de ltude.
Le domaine regroupe lensemble des processus contenus dans le systme tudier. Il est trs
important car il sert fixer les limites du cadre de ltude.

On retrouve dans UML la mme importance dfinir le domaine dtude. De la dfinition
fiable et stable du domaine dtude dpend en effet le choix des cas dutilisation, des
acteurs
VI.2.2 Lacteur
Dans MERISE, le concept dacteur apparat trs tt dans la conception du systme dinformation (ex:
modle de flux).
MERISE distingue 2 types dacteurs : des acteurs internes et externes. Les acteurs externes sont des
acteurs qui nappartiennent pas au domaine dfini. Lacteur externe nappartenant pas au champ
dtude, seules ses principales caractristiques sont dcrites.

Pour UML, le concept dacteur signifie de fait acteur externe.

La diffrence avec MERISE rside dans le fait que les acteurs sont analyss du point de
vue du rle quils jouent vis--vis du systme (la mme personne peut jouer plusieurs rles).
VI.2.3 Les flux
La modlisation des flux tient une place importante dans MERISE et se retrouve tout au
long du processus de modlisation des traitements : du diagramme de flux trs gnral
visant dcrire le domaine au modle organisationnel des traitements (MOT) qui dcrit les processus
en dtails.
MERISE adopte ici aussi une approche descendante qui part du gnral vers le particulier.

Dans UML, le diagramme des cas dutilisation est une reprsentation externe qui montre
les liens de haut niveau sans reprsenter le dtail des changes. Au niveau interne, les
diagrammes de squence et les diagrammes dactivits permettent de reprsenter les flux.
La diffrence essentielle dans la modlisation des flux entre MERISE et UML provient de
la faon daborder les processus : on les dcoupe par fonctions dans MERISE et on les aborde
par les rles jous par les acteurs dans UML.
VI.2.4 Les modles conceptuels et organisationnels
Les modles conceptuels
Le modle conceptuel des donnes
Dans MERISE, le MCD est la reprsentation de l'ensemble des donnes mmorisables du domaine
sans tenir compte des aspects techniques de stockage ni se rfrer aux conditions d'utilisation par tel
ou tel traitement.
Pour laborer un MCD, MERISE sappuie sur les concepts suivants :
- proprit
- entit
- association
Le concept de proprit
La proprit est la modlisation de l'information lmentaire. C'est un ensemble de
donnes ayant la mme structure et reprsentant des informations analogues. La modlisation
des proprits doit viter les synonymes et les polysmes.

Il ny a pas de diffrence ce niveau entre MERISE et UML. Les attributs des objets sont comparables
aux proprits des entits.
UML possde simplement un formalisme spcifique pour les informations calcules (cf.
attribut driv) alors quelles sont fortement dconseilles dans MERISE et quelles
ninterviennent que dans le MPD (modle physique des donnes) aprs dgradation.
Le concept dentit

L'entit est un groupe de proprits permettant de modliser un ensemble d'objets de mme
nature.

Dans UML, la notion dentit correspond la composante statique de la notion de classe dans le
diagramme des classes.
La notion de classe est toutefois plus large que la notion dentit : elle contient en effet des
mthodes et des oprations ; les instances communiquent grce des messages. Autant de notions
inconnues dans MERISE.
De plus, les classes ne sont pas utilises uniquement pour modliser les objets mtier, elles servent
aussi modliser les objets techniques.

Le diagramme des classes dUML est donc plus riche que le MCD de MERISE : on peut transformer un
MCD en diagramme de classes mais linverse nest pas possible.
Ceci reflte la diffrence fondamentale entre UML et MERISE : UML intgre lobjet et associe
donc au sein du mme concept des aspects statiques et dynamiques.
Cette diffrence se traduit par la modlisation des oprations dans les classes mais
galement par la porte de la modlisation : linverse de MERISE, les objets ne se limitent
pas la modlisation du processus mtier.
Les classes dUML respecteront par consquent les mmes rgles de normalisation que dans
MERISE mais sont cres dans une optique diffrente des entits.

Quant au formalisme, il ny a pas de diffrence notoire entre MERISE et UML.

NB : la porte des attributs (public, protg, ou priv) apparaissent dans MERISE 2 au niveau
du modle organisationnel des donnes.
Le concept dassociation
Une association modlise un ensemble de liens de mme nature entre deux ou plusieurs
occurrences d'entits.

On ne note pas de diffrence flagrantes entre MERISE et UML ce niveau. Les diffrences se
situent essentiellement au niveau du formalisme des cardinalits par
exemple (sens de lecture invers par exemple ), ou de la description de lassociation
(description des 2 rles en UML).

Les associations de MERISE qui contiennent des proprits se traduisent en UML par des
classes-associations.

Quant au concept de gnralisation / spcialisation et la notion dhritage qui en dcoule,
on le retrouve galement dans MERISE 2, tout comme la modlisation des contraintes
(partition, exclusion, totalit...)

Il faut noter quUML exprime certaines notions (comme lagrgation ou la composition) avec un
symbolisme particulier qui nest pas prsent dans MERISE.

LA NORMALISATION DU MODELE
La normalisation est un ensemble de rgles introduites lorigine dans le modle relationnel.
Elles ont pour objectif de garantir la cohrence de la base de donnes lors des diffrentes
manipulations (insertion, mise jour, suppression).
Transposes au modle conceptuel des donnes, elles permettent de rapprocher le formalisme
entit-association de MERISE, du modle relationnel.
MERISE propose ainsi des rgles de validation :
- pertinence

- identification
- vrification
- unicit
- homognit
Ensuite, le modle doit respecter au moins les 3 premires formes normales.
Cette normalisation a fait la force de MERISE pour modliser les donnes.

A la diffrence de MERISE, UML ne se proccupe pas de normalisation. Rien nempche toutefois
dappliquer les rgles de normalisation prconises dans MERISE au diagramme de clases.
Le modle conceptuel des traitements
Dans MERISE, le modle conceptuel des traitements (MCT) a pour objectif de reprsenter les
activits exerces par le domaine. Il exprime ce que fait le domaine et non, o, comment,
quand et par qui, ces activits sont ralises (cette modlisation est ralise au niveau
organisationnel). A ce stade, on fait abstraction de lorganisation du domaine.

Le MCT repose sur plusieurs concepts
- les vnements
- les oprations
- la synchronisation
Les vnements
MERISE distingue deux types dvnement :
- des vnements dclencheurs provoquant une opration
- des vnements rsultats produits par une opration suite une rgle dmission

Dans UML, les concepts de flux assez similaires. Seul le mode de reprsentation diffre
(cf. diagramme de squences).
Les oprations
Une opration dcrit le comportement du domaine et de son systme dinformation face un ou
plusieurs vnements. Une opration est dclenche par la survenance dun vnement, ou de
plusieurs vnements synchroniss. Elle comprend lensemble des activits que le domaine peut
effectuer partir des informations fournies par lvnement, et de celles dj connues dans la
mmoire du systme dinformation.

Dans UML, les oprations sont reprsentes dans des diagrammes dactivits. Les activits sont
hirarchiques et donc se dcrivent elles-mmes par des activits.
La synchronisation
La synchronisation est une condition pralable au dmarrage dune opration. Elle se traduit
par une opration logique.

Dans UML, les synchronisations peuvent apparatre dans les diagrammes dactivits et dtats
transition.
Les modles organisationnels
Le modle organisationnel des traitements
Le MCT permet de dcrire les fonctions sans rfrence aux ressources pour en assurer le
fonctionnement.
Le modle organisationnel des traitements dcrit la manire dont ces fonctions sont
matriellement assures.

Dans UML, les aspects dynamiques de lorganisation sont tudis par les diagrammes de squence
et les diagrammes dactivits. Le diagramme dactivits permet de visualiser le
squencement des tches en les attribuant aux travailleurs dinterface et de contrle. Les
changes et les contrles apparaissent de faon claire.

Ainsi, lenchanement des tches dans le MOT trouve son quivalent dans le diagramme
dactivits.
Le diagramme de squences apporte par contre une dimension supplmentaire par apport au MOT
en faisant apparatre les objets entits.
Toutefois, on retrouve galement ce lien dans MERISE 2 au travers du MOTA (Modle
organisationnel des traitements analytique).
Le modle organisationnel des donnes
Le MOD utilise le mme formalisme et les mmes concepts que le MCD.
Les caractristiques de chaque donne sont enrichies par des notions de confidentialit, de scurit,
de besoin dhistorique. On distingue les donnes prives, protges et partages.

On retrouve ces notions dans UML, notamment au niveau du diagramme de classes.
VI.3 La dmarche
Deux points seront abords pour comparer les dmarches utilises dans MERISE et UML :
- les modles
- les tapes du processus dlaboration du systme dinformation
VI.3.1 Les modles utiliss
MERISE utilise diffrents types de modle en fonction du niveau dabstraction et de la
nature de lobjet tudi (donnes ou traitements) et se fonde avant tout sur une analyse
fonctionnelle descendante

UML propose une approche en 2 temps :
- la couche mtier se rapproche des niveaux conceptuel et organisationnel
- la couche ressource de rapproche des niveaux logique et physique

Les diagrammes de la couche mtier sont complts dans la couche ressource sans
changement de formalisme.

Il existe des quivalences entre les modles MERISE et les modles UML.
Le diagramme de cas dutilisation ne montre que les acteurs, les cas dutilisation et leur relation : il
ne matrialise pas les flux et les changes. Il ne faut donc pas le confondre avec le diagramme des
flux.
Le diagramme de classes et le diagramme dobjets sont proches des MCD et MOD. Les diffrences
fondamentales rsident dans lintgration des mthodes dans les classes et les objets.
De plus, le diagramme des classes ne se limite pas aux seules entits mtier comme le
MCD et contient galement des paquetages et des interfaces.
Le diagramme de collaboration na pas dquivalence
Le diagramme dtats-transitions na pas dquivalence dans MERISE. Il sapparente au
CVO (cycle de vie des entits et objets) dans MERISE 2.
Le diagramme dactivits prsente des similitudes avec le diagramme des flux et se
rapproche du MCT et MOT (MCTA et MOTA dans MERISE 2) pour fournir une vue globale de
lorganisation.
Le diagramme de composants montre la mise en uvre physique des modles logiques avec
lenvironnement de dveloppement. Elle tient compte des problmatiques de programmation,
compilation, rutilisation
Le diagramme de dploiement est spcifique UML.


Il nest cependant pas trs intressant dtablir des liens de correspondance entre les modles
de MERISE et dUML car les 2 modles ne sont pas raliss avec les mmes objectifs et
nutilisent pas toujours les mmes concepts.
VI.3.2 Les tapes du processus dlaboration du systme dinformation
MERISE identifie 3 grandes tapes dans le processus dlaboration dun systme dinformation :
la conception, la ralisation et la maintenance, quon peut dtailler ainsi :

- Conception
Schma directeur
Etude pralable
Etude dtaille
- Ralisation
Etude technique
Production logicielle
Mise en uvre
- Maintenance
Mise en service - Maintenance

A la diffrence de MERISE, UML ne propose pas de cycle prcis : les organisations sont libres de
choisir le cycle qui leur convient.

UML fonctionne sur un principe ditrations qui ne soppose pas aux phases dfinies dans MERISE.
MERISE dcoupe plus au travers de ses phases lanalyse mtier et larchitecture logicielle. Dans UML,
larchitecture logicielle a une place prpondrante et est intgre trs en amont dans
llaboration du systme dinformation.

Dans UML, lavancement du projet est mesur par le nombre de cas dutilisation, de classes...
rellement implantes et non par la documentation produite.
Les itrations servent en outre rpartir lintgration et les tests tout au long du processus
dlaboration du systme dinformation.
Conclusion
En rsum, on retiendra que :
- les niveaux dabstraction ne sont pas nettement distingus dans UML
- il ny a pas de diffrence de formalisme en fonction des niveaux dabstraction dans UML
- UML intgre lobjet et a t conu pour et autour de lobjet.
- UML est plus proche du langage de programmation que MERISE


CONCLUSION GENERALE
UML est un langage de modlisation visuelle prsentant des modles bass sur un nombre
dtermin de diagrammes en fonction de la vue et qui sont progressivement enrichis.
Comme UML n'impose pas de mthode de travail particulire, il peut tre intgr n'importe quel
processus de dveloppement logiciel de manire transparente. UML est une sorte de bote outils,
qui permet d'amliorer progressivement les mthodes de travail, tout en prservant les modes de
fonctionnement et reste incontournable si lentreprise veut utiliser les techniques objets.
Intgrer UML par tapes dans un processus, de manire pragmatique, est tout fait ncessaire. La
facult d'UML de se fonder dans le processus courant, tout en vhiculant une dmarche
mthodologique, facilite son intgration et limite de nombreux risques (rejet des utilisateurs,
cots...).
Intgrer UML dans un processus ne signifie donc pas rvolutionner ses mthodes de travail, mais cela
devrait tre loccasion de se remettre en question.

Methode de Conception Orientee Objet - 2012

Uploaded by

Document Information

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

Methode de Conception Orientee Objet - 2012

Uploaded by

Copyright:

Available Formats

Mthodes de Conception Orients Objet (MCOO)

Verlain FOUNDIKOU Page 1

You might also like