Office de la Formation Professionnelle et de la Promotion du Travail

Mthode RUP Phase de conception

DIRECTION RECHERCHE ET INGENIERIE DE FORMATION

SECTEUR NTIC
 Mthode RUP phase de conception

Sommaire

1. La conception ................................................................................... 2
1.1. dixime tape : le diagramme dtat ............................................... 2
1.2. onzime tape : Expliciter les contrats dopration par des diagrammes
de squence boite blanche ........................................................................ 4
1.3. douzime tape : le diagramme de collaboration ................................ 7
1.4. treizime tape : le diagramme de classe de conception ................... 33
1.5. quatorzime tape : le codage ....................................................... 39
2. Le processus unifi .......................................................................... 42
2.1. Notion de lot ( ou de cycle ) .......................................................... 42
2.2. Notion de phases ......................................................................... 42
2.3. Notion ditration ......................................................................... 44
3. conclusion ...................................................................................... 45

Document Millsime Page

OFPPT @ [Link] novembre 17 1 - 47
Mthode RUP Phase de conception

1. La conception
1.1. dixime tape : le diagramme dtat

Le diagramme d'tat est la frontire de l'analyse ( par la comprhension

des cycles de vie de certains objets ) et de la conception ( par les mthodes
qu'il permet de dfinir dans les classes tudies ).

"Le diagramme se ralise pour les classes d'objets ayant un comportement

significativement complexe. Toutes les classes d'un systme n'ont pas besoin
d'avoir un diagramme d'tat." ( James RUMBAUGH )

Si, dans l'analyse de notre systme, des classes paraissent complexes, par
exemple si elles sont souvent sollicites dans les diagrammes de squence
bote blanche, il est bon de faire un diagramme d'tat de ces classes: cela
permet d'avoir une vue orthogonale de la classe par rapport ses liens avec
les autres classes. Ainsi, nous regardons le comportement des objets d'une
classe, et leur volution interne au fil des vnements. Cela nous donne le
cycle de vie des objets d'une classe.

Ainsi, ayant peru le fonctionnement des objets d'une classe, il est plus facile
de vrifier que les objets des autres classes respectent bien ce comportement.
Cela amliore notre perception du problme.
Cela implique que les diagrammes d'tat doivent tre confronts aux
diagrammes d'interaction afin de vrifier la cohrence de ces diagrammes.

Les diagrammes d'tat permettront galement de complter les diagrammes

de classes de conception en particulier en mettant en vidence des mthodes
publiques ( correspondant aux actions du diagramme d'tat ) et des mthodes
prives ( correspondant aux activits du diagramme d'tat ).

Quelques rappels:

Un tat reprsente un objet dans une situation o:

Il a une raction dtermine par rapport un vnement.
Il excute une activit.
Il satisfait une condition.

Un tat a une dure finie.

Un objet peut avoir une activit dans un tat. Par exemple quand la caisse
est en attente d'un client, elle peut faire dfiler un message de bienvenue sur
l'cran client.
Un objet peut avoir des actions qui seront dclenches sur des vnements.
Par exemple sur l'vnement fin de vente, la caisse va afficher le total payer.

Une action est une opration atomique qui ne peut tre interrompue.
Elle est considre comme instantane.
Document Millsime Page
OFPPT @ [Link] novembre 17 2 - 47
 Mthode RUP Phase de conception
Elle est gnralement associe une transition.

Une activit est une opration qui dure et qui peut tre interrompue.
Elle est associe un tat.
Elle peut tre continue et interrompue par un vnement.
Elle peut tre finie et dclencher une transition.

nouvel article

arrive article / cration vente

dmarrer caisse

attente traitem ent un article

do afficher en boucle bonjour
abandon / dtruire vente entry: afficher prix + description
entre quantit/afficher quantit
et sous total

ticket rem is / historiser vente abandon / dtruire vente

fin vente / afficher total
arrter caisse

im pression en cours
attente paiement
entry : lancer
im pression somm e saisie / afficher monnaie

Etat de la caisse concernant le use case effectuer un achat

Document Millsime Page

OFPPT @ [Link] novembre 17 3 - 47
Mthode RUP Phase de conception
1.2. onzime tape : Expliciter les contrats dopration
par des diagrammes de squence boite blanche

Pour matrialiser la ralisation concrte du contrat dopration sur les objets

qui sont impliqus dans celui-ci, on peut rdiger les diagrammes de squence.
Toutefois, si le contrat est simple, par exemple une cration dobjet, et que
la lecture de la forme textuelle du contrat dopration suffit expliciter le
comment faire , il est inutile dalourdir ltude par ces diagrammes
supplmentaires.
titre dexemple, montrons la ralisation effective des contrats dopration
de la neuvime tape.

Voici le diagramme de squence bote blanche (on regarde ici l'intrieur du

systme) de l'opration modifierprix. Cela correspond au contrat de
l'opration.

: catalogue article
: Manager

modifier(cecode, nouveauprix)
modifier( prix )

Diagramme de squence bote blanche de

l'opration modifier le prix d'un article au catalogue
dans le use case grer le catalogue.

Diagramme de squence bote blanche de enregistrer un article.

Document Millsime Page

OFPPT @ [Link] novembre 17 4 - 47
 Mthode RUP Phase de conception

: caisse v : vente ldv : ligne de art : article : catalogue

vente
: Caissier

enregistrer un article ( cecode )

create ( date, time )

art = selectionner( cecode )

create(art,1)

maj ligne vente(ldv)

si nouvelle
vente
afficher(description,prix)

la quantit
vaut 1

On notera que sur cette reprsentation nous ne voyons pas bien les
associations qui ont t cres. Par contre nous voyons mieux les objets qui
cooprent pour arriver au rsultat. Ces deux reprsentations du contrat sont
assez complmentaires, et mriteraient d'tre prsentes toutes les deux.

Diagramme de squence bote blanche de l'opration dnombrer les articles

identiques.

: caisse v : vente ldv : ligne de

: Caissier : article
vente

dnombrer(q)
ldv = slectionner dernier ldv()

modifquantit(q)
p = getprix()

afficher([Link]*p)

Document Millsime Page

OFPPT @ [Link] novembre 17 5 - 47
Mthode RUP Phase de conception

Diagramme de squence bote blanche de l'opration finir vente.

: caisse : vente
: Caissier

finir vente()
set termin(true)

T = calculer Total()

setTotal(T)

afficher Total

cela ncessite de
parcourir toutes les
lignes de vente

Diagramme de squence bote blanche de l'opration payer la vente.

: caisse : vente p : Paiement t : ticket

: Caissier

payer (s)
payer(s)
create([Link])

afficher([Link])

create()

im prim er()

Document Millsime Page

OFPPT @ [Link] novembre 17 6 - 47
Mthode RUP Phase de conception

Ces schmas sont moins prcis que le contrat d'opration sous forme
textuelle. Nous n'y retrouvons pas les associations. Les schmas de
diagramme de squence bote blanche utiliss pour dcrire un contrat
d'opration ( bien que souvent utiliss ) vont introduire des choix de
conception ( qui dclenche les oprations? ). Si ces choix ne sont pas faits le
diagramme induit une erreur d'interprtation. Nous prfrerons donc faire ces
choix de conception dans le diagramme de collaboration, et garder le contrat
d'opration sous forme textuelle.

1.3. douzime tape : le diagramme de collaboration

Le diagramme de collaboration va nous montrer comment les objets

interagissent entre eux pour rendre le service demand par le contrat
d'opration. Nous allons d'abord observer la syntaxe, et la forme que prend
ce diagramme d'opration. Les objets doivent demander des services
d'autres objets. Il leur faut donc connatre ces objets pour pouvoir leur
adresser des messages. Nous allons donc regarder la visibilit des objets (
c'est dire comment un objet peut connatre d'autres objets ). Enfin quand
une ligne du contrat d'opration est ralise il faut se poser la question de
savoir quel objet agit pour raliser cette ligne ( qui cre tel objet, qui reoit
l'vnement initial). En un mot il est ncessaire de dfinir les responsabilits
des objets. L'exprience et le savoir faire des professionnels nous ont permis
de dfinir des rgles, des modles de pense, qui nous permettrons de nous
guider pour dfinir les responsabilits des objets. Ce sont les GRASP patterns
que nous verrons enfin, avant de traiter notre caisse.

1.3.1. Syntaxe du diagramme de collaboration

Nous allons prendre un exemple de diagramme de collaboration pour

introduire toutes les notions vhicules dans ce diagramme. Rappelons nous
que ce diagramme, dans le contexte de la conception, nous montre comment
les objets cooprent entre eux pour raliser les oprations dfinies par les
contrats d'opration.

Document Millsime Page

OFPPT @ [Link] novembre 17 7 - 47
Mthode RUP Phase de conception

Modifierprix(code,prix) 1 :Modifierprix(code,prix)
:caisse :catalogue

1.1 :art := chercher(code) : article

1.2 : setprix(prix)

art : article

: article

Les objets

Ici nous reprsentons la coopration des objets pour rendre le service

demand. Il sagit donc bien dobjets. Ces objets apparaissent sous trois
formes :

Les objets anonymes ( :caisse, :catalogue). A comprendre la caisse courante,

ou le catalogue courant
Les objets nomms ( art :article ). A comprendre que cest bien le type darticle
qui correspond au code cherch.
Les multiobjets ( :article ). A comprendre comme la collection des types
darticle associe au catalogue.

Objet
anonyme

Modifierprix(code,prix) 1 :Modifierprix(code,prix)
:caisse :catalogue

1.1 :art := chercher(code) : article

Objet
nomm 1.2 : setprix(prix) Multi
objet

art : article

: article

Document Millsime Page

OFPPT @ [Link] novembre 17 8 - 47
 Mthode RUP Phase de conception

La syntaxe des messages

Message
initial issu
du Caisse envoie
diagramme un message
de squence Dabord le
catalogue
catalogue
cherche
larticle

Modifierprix(code,prix) 1 :modifierprix(code,prix)
:caisse :catalogue

Puis il modifie
le prix de
larticle trouv

1.1 :art := chercher(code) : article

1.2 : setprix(prix)

art : article

: article

Le message initial est non numrot par convention. Ce message est un des
vnements issu du diagramme de squence bote noire, dont nous avons fait
un contrat dopration.

Les oprations effectues en rponse ce message seront numrotes de 1

n (notons quen gnral n nest pas trs lev, si la conception est bien faite )

Les oprations effectues en raction un message numro x seront

numrotes de x.1 x.n. Et ainsi de suite pour les oprations effectues en
raction un message numro x.y ( x.y.1 x.y.n).

Un message a la forme suivante :

Type de
message retour du
Valeur message
de
retour

1.1 :art := chercher(code) : article

numro
affectatio Paramtre(s
n ) du
message
Document Millsime Page
OFPPT @ [Link] novembre 17 9 - 47
Mthode RUP Phase de conception

Un lien entre deux objets est directionnel. La flche indique le receveur du

message. Ce lien implique que lobjet qui envoie le message connaisse celui qui
le reoit. Un objet ne peut en effet envoyer un message qu un objet quil
connat ( rappelez-vous que lon envoie un message un objet en lui parlant :
moncatalogue , modifie le prix de larticle de code moncode monprix.).
Chaque flche implique une visibilit oriente entre les objets.

:catalogue
connat art et
le multiobjet

Modifierprix(code,prix) 1 :Modifierprix(code,prix)
:caisse :catalogue

:caisse
connat
lobjet :catal
ogue 1.1 :art := chercher(code) :article

1.2 : setprix(prix)

art : article

:article

Les types de messages

Nous avons vu la forme gnrale des messages. Il peut y avoir quelques formes
particulires de messages, que nous allons lister maintenant.

Les messages conditionnels simples :

Message
habituel, ici
simplifi

1.1[x>y] :message()
1
:A :B
: numro condition
m
s
g Document Millsime Page
OFPPT @ [Link] novembre 17 10 - 47
(
)
 Mthode RUP Phase de conception

Le message nest envoy :B que si la condition x>y est remplie lors du

droulement du code de msg() dans la classe A.

Les messages conditionnels exclusifs ( ou si sinon) :

1.1a[x>y] :messageb()
1
:A :B
: condition
Numro
m avec une
s letrre
g
(
)
1.1b[ not x>y] :messagec()

:C

Mme numro
avec une autre
lettre Condition
contraire

Si la condition x>y est vrifie, un message est envoy lobjet :B, sinon un
message est envoy lobjet :C

Les messages dinstanciation

Ce sont les messages de cration dobjet. Ce sont des messages create, avec
ou sans paramtres, qui creront de nouvelles instances dobjets.

:catalogue Nouvelarticle
1 :Ajouter(desc,prix,code,qt) 1.1 :Create(desc,prix,code,qt)
:Type article

Ici le message create cre un nouvel article en linitialisant. Les vrifications

dusage seraient bien sr effectuer (le code de larticle nexiste til pas dj
au catalogue ?).

Document Millsime Page

OFPPT @ [Link] novembre 17 11 - 47
Mthode RUP Phase de conception
Les messages itratifs
Ici itration
* aprs le de 1 10
numro
indique une
itration

1.1*[i :=1..10] :message()

1
:A :B
:
m
s
Le message sera envoy dix fois lobjet :B. De manire gnrale ltoile
g
place aprs le numro dsigne une itration. Nous trouverons soit une
(
numration de litration, comme ici, une condition de continuation galement
)
(1.1*[not condition] :message() ). Nous trouverons ultrieurement une
itration sur tous les lments.

Les messages itratifs groups

Ce sont des messages itratifs, o plusieurs messages sont envoys dans

litration.

1.1*[i :=1..10] :messageb(

1 )
:A :B
:
Itration
m sur i de 1
s 10
g
(
)
1.2*[ i :=1..10] :messagec()

:C
Itration
sur le
mme i
toujours de
1 10

Ici nous envoyons successivement un message :B, puis un message :C, le

tout 10 fois. Il ny a quune seule boucle.

Document Millsime Page

OFPPT @ [Link] novembre 17 12 - 47
 Mthode RUP Phase de conception
Les messages itratifs distincts

Ce sont des messages itratifs, o plusieurs itrations se suivent. Ici les boucles
sont distinctes.

1.1*[i :=1..10] :messageb()

1
:A :B
:
Itration
m sur i de 1
s 10
g
(
)
1.2*[ j :=1..10] :messagec()

:C
Itration
sur j
diffrent de
i

Ici nous envoyons successivement dix messages :B, puis dix messages :C.
Il y a deux boucles distinctes.

Les messages vers this

Ici un objet senvoie un message lui-mme.

1 :Create()

Produit frais

1.1 :defDatePremption(today)

La dfinition de la date de premption du produit est faite par lui-mme. Il sait

combien de temps il peut se conserver dans des conditions de tempratures
normales. Donc il senvoie le message lui-mme.

Les messages vers un multiobjet

1 :art :=quelart(code) : article :catalogue 1.1 :art :=trouver(code) :article : article

Le message trouver n'est pas envoy l'objet :Type art mais au multi objet,
qui se traduira en programmation par une collection ( tableau, vecteur,
hashtable, etc ).
Document Millsime Page
OFPPT @ [Link] novembre 17 13 - 47
Mthode RUP Phase de conception

Les multiobjets acceptent de manire gnrale un certain nombre de

messages:

Trouver : rcupre un lment d'un multiobjet partir d'une cl.

Ajouter : ajoute un lment au multiobjet.
Supprimer : supprime un lment du multiobjet.
Taille : donne le nombre d'lments du multiobjet.
Suivant : permet de passer l'lment suivant du multiobjet.
Contient : permet de savoir si un lment est prsent dans le
multiobjet partir d'une cl.

Itration sur les lments d'un multiobjet

1: lister()
Pour chaque article du catalogue, nous voulons la
description de l'intitul de l'article.
:catalogue

Cette toile
montre que l'on
s'adresse aux
lments de la
1.1*: s := getDescr() : String * collection

Cette toile
montre une
: article itration sur
tous les
lments

Il nous reste ici imprimer la description obtenue. Pour cela il faut envoyer un
message une classe.

Envoi d'un message une classe ( appel d'une mthode statique )

1: lister()

1.2*: imprimer(s)
:catalogue Systeme

1.1*: s := getDescr() : String *

Ici nous avons une classe. La
mthode imprimer est donc
une mthode statique (lie
une classe).

: article

Document Millsime Page

OFPPT @ [Link] novembre 17 14 - 47
Mthode RUP Phase de conception

1.3.2. Visibilit des objets

Pour pouvoir s'changer des messages, les objets doivent se connatre.

:caisse :vente

Ce lien veut dire

que la caisse
connat la vente.

La classe caisse doit connatre la classe vente pour pouvoir lui parler:" vente ,
oh ma vente! Ajoute-toi un article de ce code.".

La visibilit entre les objets n'est pas automatique. Il y a quatre manires

diffrentes pour un objet d'en connatre un autre.

La visibilit de type attribut.

La visibilit de type paramtre
La visibilit de type locale
La visibilit de type globale

Nous allons regarder chacun de ces diffrents types de visibilit.

La visibilit de type attribut.

1: desc := getdesc(code):String
:caisse :catalogue

La caisse doit connatre de manire permanente le catalogue. Elle a donc un

attribut qui rfrence le catalogue. Le lien montre cet attribut, car c'est la seule
manire ici de connatre la classe catalogue.

La visibilit de type paramtre

Supposons que le diagramme de squence bote noire mette en vidence un

message de type vrifier avec en paramtre une description d'article.
Supposons galement que ce soit la caisse qui traite ce message. Nous
obtenons le diagramme de collaboration suivant:

Que
Val := Vrifier(art:article): entier
celui-l
Document
Celui-ci c'est le mme Millsime Page
OFPPT @ [Link] novembre 17 15 - 47
Mthode RUP Phase de conception

:caisse art :article

1: p := getPrix(): entier

Ici la caisse ne connat l'article art que temporairement. Le passage de

paramtre lui fait connatre l'article art qui la caisse va envoyer un message.

La visibilit de type locale

Setprix(code,prix)

1:art:= getart(code): article

:caisse :catalogue

Rcuprons
une rfrence
sur un objet

2: setprix(prix)
art:article Pour pouvoir
lui envoyer
un message

Ici caisse va chercher une rfrence sur un article, pour pouvoir envoyer un
message cet article. Ici aussi, la connaissance de l'objet est temporaire, mais
elle se fait par une variable locale.

La visibilit de type globale

C'est l'utilisation par un objet d'une rfrence globale un objet connu de tous.
Cela peut aussi tre le cas de variables globales dans le cas de certains
langages. Nous comprenons bien que ce type de visibilit sera utilis dans de
rares cas, o un objet est omniprsent pour tous les autres objets, et sera
considr comme le contexte de vie de ces objets.

Le problme est que certaines, rares, classes ayant une instance unique doivent
tre connues de nombreux objets. Il est alors conseill d'utiliser le GOF Pattern
"Singleton".

Supposons qu'une classe ncessite d'en connatre une autre ayant une instance
unique (Par exemple, le magasin, si lon avait une classe magasin), et que les
autres techniques de visibilit soient notoirement malcommodes voici ce que
vous pouvez faire:

La classe magasin aura une donne membre statique instance.

A la cration ( constructeur ) du magasin la donne membre sera
initialise this ( l'instance nouvellement cre du magasin ).
La classe magasin aura une fonction statique getInstance qui
retournera l'instance du magasin. Ainsi n'importe quelle classe
Document Millsime Page
OFPPT @ [Link] novembre 17 16 - 47
Mthode RUP Phase de conception
pourra connatre l'objet magasin existant ( car la mthode tant
statique, elle est envoye la classe elle mme ). Ainsi l'autre classe
pourra envoyer sa requte l'objet magasin.

Document Millsime Page

OFPPT @ [Link] novembre 17 17 - 47
Mthode RUP Phase de conception
Voici un diagramme de collaboration qui illustre cet exemple.

1: m =getInstance()
:X Magasin

2: xxx()

Ceci est Ceci est

m:Magasin l'instanc une
e unique classe

1.3.3. GRASP patterns

Quand un vnement est envoy au systme informatique, rien n'indique quelle

classe prend en charge l'vnement et le traite en droulant les oprations
associes.

Systeme
informatique

vnement
A qui est
envoy ce
message ?

De mme pour chaque opration permettant de mettre en uvre le contrat

d'opration, il faudra dterminer qui cre tel objet, qui envoie tel message tel
autre objet.

Document Millsime Page

OFPPT @ [Link] novembre 17 18 - 47
Mthode RUP Phase de conception
Contrat d'opration: une ligne de vente a t cre.

Systme
informatique

:caisse :vente

Qui cre
la ligne de
vente ?
C
C
r
r
e
e
a
:magasin L:lignevente a
t
t
e
C e
?
r ?
e
a
t
La rponse ces questions va influencer normment
e la conception de notre
application. C'est ici que l'on va dfinir concrtement
? la responsabilit des
objets, leur rle. C'est aussi ici que l'on va mettre en place la structure du
logiciel par couches ( entre autre en implmentant les passerelles tanches
entre les couches ).

Les qualits du logiciel qui lui permettront de vivre, d'tre corrig, d'voluer,
de grandir dpendront compltement des choix que l'on va effectuer ici.

Les spcialistes de la conception objet, aprs avoir vcu quelques annes de

dveloppement anarchique, puis aprs avoir test l'apport de quelques rgles
de construction, ont fini par dfinir un certain nombre de rgles pour aider le
concepteur dans cette phase capitale et difficile. Ces rgles sont issues de
l'exprience d'une communaut de dveloppeurs. Ce sont des conseils, ou des
rgles qui permettent de dfinir les responsabilits des objets. Ce sont les
modles d'assignation des responsabilits ou GRASP Patterns ( General
Responsability Assignement Software Patterns ).
To grasp ( en anglais ) veut dire: saisir, comprendre, intgrer. Il est
fondamental d'intgrer ces modles avant de faire de la conception objet, pour
obtenir des diagrammes de classe de conception, et des diagrammes de
collaboration de qualit.

Il y a neuf grands principes pour attribuer les responsabilits aux objets, et

modliser les interactions entre les objets. Cela permet de rpondre aux
questions:
Quelles mthodes dans quelles classes?
Comment interagissent les objets pour remplir leur contrat?

Document Millsime Page

OFPPT @ [Link] novembre 17 19 - 47
Mthode RUP Phase de conception
De mauvaises rponses conduisent raliser des programmes fragiles, faible
rutilisation et maintenance leve.

Quand, dans le diagramme de collaboration, un objet envoie un message un

autre objet, cela signifie que l'objet recevant le message a la responsabilit de
faire ce qui est demand.

da := getdescart(code) :catalogue Le catalogue la

responsabilit de
rechercher une
description
d'article

Un message implique une responsabilit.

Les patterns sont l pour nous aider lors de la conception. C'est un couple
problme solution issu de la pratique des experts.
Nous allons voir les neuf GRASP patterns. Il y a d'autres patterns qui existent
( par exemple GOF ( Gang Of Four ) patterns ) ceux-l sont plus ddis des
solutions des problmes particuliers ( par exemple le modle de traitement
des vnements ( GOF patterns ) qui a inspir le modle java de traitement
des vnements ).
Les GRASP patterns sont des modles gnraux de conception, et doivent tre
considrs par le concepteur objet comme la base de son travail de conception.
Nous allons tudier chacun de ces patterns.

3.1) Faible couplage

Le couplage entre les classes se mesure : c'est la quantit de classes qu'une

classe doit connatre, auxquelles elle est connecte, ou dont elle dpend.
Plus il y a de couplage, moins les classes s'adaptent aux volutions. Il faut
donc garder en permanence l'esprit que des liens entre les classes ne seront
rajouts que si nous ne pouvons les viter.
Un couplage faible mne des systmes volutifs et maintenables. Il existe
forcment un couplage pour permettre aux objets de communiquer.

3.2) Forte cohsion

Des classes de faible cohsion font des choses diverses ( classes poubelles
o sont ranges les diffrentes mthodes que l'on ne sait pas classer ), ou tout
simplement font trop de choses.
Ces classes faible cohsion sont difficiles comprendre, rutiliser,
maintenir. Elles sont galement fragiles car soumises aux moindres variations,
elles sont donc instables.
Le programmeur doit toujours avoir ce principe de forte cohsion en tte. Il
ralisera alors des classes qui ont un rle clairement tabli, avec un contour
simple et clair.

3.3) Expert

Document Millsime Page

OFPPT @ [Link] novembre 17 20 - 47
Mthode RUP Phase de conception
Ici nous allons tablir qui rend un service. Le principe est que la
responsabilit revient l'expert, celui qui sait car il dtient l'information.

Quelle classe fournira le service getdescription ( code ) qui retourne la

description d'un article dont nous avons le code?

Desc := getdescription( code ) : descriptionarticle

:vente :catalogue

C'est
l'expert

C'est le catalogue qui possde les descriptions d'article, c'est lui l'expert.
C'est donc lui qui nous fournira le service getdescription.

Ce principe conduit placer les services avec les attributs. Nous pouvons
aussi garder en tte le principe: "celui qui sait, fait".

3.4) Crateur

Quand une instance de classe doit tre cre, il faut se poser la question: "
Quelle classe doit crer cet objet?".

Une classe A cre peut crer une instance de la classe B si:

A contient B.
A est un agrgat de B.
A enregistre B.
A utilise souvent B.

Alors A est la classe cratrice de B. Il arrive souvent que deux classes soient
de bons candidats pour crer une instance. Alors il faut valuer le meilleur
candidat. Cela va dans le sens du faible couplage.
Ici c'est le catalogue qui cre les descriptions d'articles.

3.5) Contrleur

En dbut de ce document, il tait voqu l'indpendance entre les

diffrentes couches logicielles. Regardons ici l'interface entre la couche
prsentation et la couche mtier.

Document Millsime Page

OFPPT @ [Link] novembre 17 21 - 47
Mthode RUP Phase de conception

Interface utilisateur Systme informatique

Objets de l'interface utilisateur objets du sytme

informatique
( Frame )

Ici nous voyons de fortes dpendances entre les objets du Systme

informatique et les objets de l'interface. Si l'interface doit tre modifie, il y a
de fortes chances qu'il faille galement modifier les objets du systme
informatique.

Notons sur cet exemple un autre problme: les classes du systme

informatique, ici, connaissent les classes de l'interface utilisateur. Or, ces
classes sont lies un usage particulier ( une application ) alors que les classes
mtier sont transverses toutes les applications. Elles ne peuvent donc pas
connatre les interfaces utilisateur. Ce sont les interfaces utilisateurs qui vont
chercher les informations des objets mtier, et non les objets mtier qui
affichent les informations.

Les objets de l'interface utilisateur vont solliciter un objet d'interface, plutt

que de solliciter les objets mtier eux-mmes. Cet objet s'appelle un contrleur.

Il peut y avoir quatre sortes de contrleurs:

Quelque chose qui reprsente entirement le systme ( caisse ).
Quelque chose qui reprsente l'organisation ou le mtier dans son
ensemble ( magasin ).
Quelque chose du monde rel qui est actif dans le processus: rle d'une
personne impliqu dans le processus (caissier).
Handler artificiel pour traiter tous les vnements d'un use case. (
AchatHandler )

Document Millsime Page

OFPPT @ [Link] novembre 17 22 - 47
Mthode RUP Phase de conception
Regardons notre schma des changes entre les couches UI et mtier.

Interface utilisateur Systme informatique

Objets de l'interface utilisateur objets du systme

informatique
( Frame )

Le problme est maintenant de savoir comment nous allons choisir notre

meilleur contrleur ( il peut y en avoir plusieurs ).

L'vnement entrerunarticle arrive donc sur une des quatre classes: Caisse,
Magasin, Caissier ou AchatHandler.

L'exprience montre que la troisime proposition, appele contrleur de rle,

est utiliser avec parcimonie, car elle conduit souvent construire un objet
trop complexe qui ne dlgue pas.

Les deux premires solutions, que l'on appelle contrleurs de faade sont bien
utilises quand il y a peu d'vnements systme. La quatrime proposition (
contrleur de use case ) est utiliser quand il y a beaucoup d'vnements
grer dans le systme. Il y aura alors autant de contrleurs que de use cases.
Cela permet de mieux matriser chaque use case, tout en ne compliquant pas
notre modle objet.

Nous avons peu d'vnements grer. Nous prendrons donc la solution 1 ou

2. Le choix entre ces deux propositions va se faire en appliquant les patterns
prcdemment tablis.

3.6) Polymorphisme

Quand vous travaillez avec des objets dont les comportements varient lorsque
les objets voluent, ces comportements doivent tre dfinis dans les classes
des objets, et les classes doivent tre hirarchises pour marquer cette
volution.
Document Millsime Page
OFPPT @ [Link] novembre 17 23 - 47
Mthode RUP Phase de conception
Les comportements seront dfinis par des fonctions polymorphes, c'est dire
ayant mme forme ( mme signature ou interface ), mais avec des
comportements mutants.

Ainsi lorsque l'on sollicite un objet de cette hirarchie, il n'est pas besoin de
savoir quelle est la nature exacte de l'objet, il suffit de lui envoyer le message
adquat ( le message polymorphe ), et lui ragira avec son savoir faire propre.

Cela permet de faire voluer plus facilement les logiciels. Un objet mutant (
avec un comportement polymorphe ) est immdiatement pris en compte par
les logiciels utilisant l'objet initial. Un programme ne teste donc pas un objet
pour connatre sa nature et savoir comment l'utiliser: il lui envoie un message
et l'objet sait se comporter. Cela va dans le sens de l'radication de l'instruction
switch ( de JAVA ou de C++).

3.7) Pure fabrication

L'utilisation des diffrents grasp patterns nous conduit quelque fois des
impasses. Par exemple la sauvegarde d'un objet en base de donnes devrait
tre fait par l'objet lui-mme ( expert ) mais alors l'objet est li ( coupl )
son environnement, et doit faire appel un certain nombre d'outils de base de
donnes, il devient donc peu cohrent.
La solution prconise, dans un tel cas, est de crer de toute pice un objet
qui traite la sauvegarde en base de donnes. Notre objet reste alors cohrent,
rutilisable, et un nouvel objet, dit de pure fabrication, s'occupe de la
sauvegarde en base de donnes.
Cette solution n'est employer que dans des cas bien particuliers, car elle
conduit raliser des objets bibliothque de fonctions.

3.8) Indirection

L'indirection est le fait de dcoupler deux objets, ou un objet et un service.

La pure fabrication est un exemple d'indirection, mais aussi l'interfaage avec
un composant physique. Un objet ne s'adresse pas directement un modem,
mais un objet qui dialogue avec le modem.

3.9) Ne parle pas aux inconnus

Pour viter le couplage, chaque objet n'a le droit de parler qu' ses proches.
Ainsi, nous limitons les interactions entre les diffrents objets.
Quels sont les objets auxquels un objet le droit de parler?
Lui-mme.
Un objet paramtre de la mthode appele.
Un objet attribut de l'objet lui-mme.
Un objet lment d'une collection attribut de l'objet lui-mme.
Un objet cr par la mthode.

Les autres objets sont considrs comme des inconnus auxquels, nous le
savons depuis la plus tendre enfance, il ne faut pas parler.

Document Millsime Page

OFPPT @ [Link] novembre 17 24 - 47
 Mthode RUP Phase de conception
Prenons un exemple:
L'objet caisse connat la vente en cours ( c'est un attribut de la caisse ). Cette
vente connat le paiement ( c'est un attribut de la vente ).
Nous voulons raliser une mthode de la caisse qui nous donne la valeur de la
vente en cours. Voici une premire solution:

1:P:=paiement():Paiement
Total = totalvente():float :Caisse :Vente

2:Total := totalvente():float
Caisse et p:Paiement
paiement
sont coupls

Cette solution implique que l'objet caisse dialogue avec l'objet paiement. Hors
a priori il ne connat pas cet objet paiement. Pour limiter le couplage entre les
objets, il est prfrable d'utiliser la solution suivante:

Total = totalvente():float 1:Total:=totalvente():float

:Caisse :Vente

Vente et 1.1:Total := totalvente():float

paiement se
connaissait
dj.
Pas de couplage
supplmentaire
:Paiement

Ici, la caisse ne sait pas comment la vente rcupre le total. Des modifications
de la structure des objets vente et paiement ainsi que de leurs relations ne
changent rien pour la caisse.

3.10) Typologie et regroupement des design Pattern.

mesure que le nombre de design patterns augmente, il devient judicieux

de dfinir des classifications pour pouvoir les organiser, restreindre les
recherches un sous-ensemble et effectuer des comparaisons.
Voici comment les patterns sont regroups en catgories. Cette classification
na rien dofficielle et nest pas normalise par un organisme. Cest un simple
moyen pour connatre la nature du pattern et quoi il sert. Notons bien que
Document Millsime Page
OFPPT @ [Link] novembre 17 25 - 47
Mthode RUP Phase de conception
tous les auteurs ne sont pas daccord sur le classement des pattern dans les
diffrentes catgories. Classiquement, on distingue trois grandes catgories :

Les Patterns Crateurs

Ils concernent linstanciation des objets et fournissent tous un moyen de

dcoupler un client des objets quil a besoin dinstancier. On y trouve :

Singleton ;
Monteur ;
Prototype ;
Fabrique abstraite ;
Fabrication.

Les Patterns Comportementaux

Tout pattern qui est un Pattern Comportemental est en rapport avec les
interactions des classes et des objets ainsi que la distribution des
responsabilits. On y trouve :

Commande ;
Itrateur ;
Mdiateur ;
Patron de mthode ;
Visiteur ;
Chane de responsabilit ;
Observateur ;
tat ;
Interprte ;
Mmento ;
Stratgie.

Les Patterns Structurels

Il permettent de composer des classes ou des objets pour former des structures
plus vastes. On y trouve :

Dcorateur ;
Proxy ;
Faade ;
Composite ;
Poids mouche ;
Pont ;
Adaptateur.

3.11) Un pattern important MVC (Modle-Vue-Contrleur)

Le pattern MVC est un pattern compos de plusieurs pattern qui concourent

la ralisation dun ensemble plus vaste utilis dans beaucoup de domaines
(composant graphiques Swing, application web, framework, IDE).
Document Millsime Page
OFPPT @ [Link] novembre 17 26 - 47
Mthode RUP Phase de conception
Le principe du pattern MVC est le suivant :
Le modle est responsable des donnes, il utilise le pattern Observateur pour
pouvoir tenir les observateurs jour tout en restant dcoupl deux ;
Le contrleur est la stratgie pour la vue. Le vue peut utiliser diffrentes
implmentations du contrleur pour avoir des comportements diffrents ;
La vue utilise le pattern Composite pour implmenter linterface utilisateur.
Celle-ci est gnralement constitue de composants imbriqus comme des
fentres, des cadres et des boutons ;
Ces patterns collaborent pour dcoupler les trois acteurs du modle MVC, ce
qui prserve la clart et la souplesse de la conception ;
On peut utiliser le pattern Adaptateur pour adapter un nouveau modle une
vue et un contrleur existant ;
Le Model 2 (MVC 2) est une adaptation de MVC aux applications Web ;
Dans le Model 2, le contrleur est implment sous forme de servlet et la vue
sous la forme de JSP et de code HTML.

1.3.4. Diagramme de collaboration du magasin

Nous allons maintenant construire le diagramme de collaboration pour chacun

des contrats d'opration que nous avions dtaills, en tenant compte des
modles de conception.

Nous allons faire autant de diagrammes de collaboration que nous avons fait
de contrats d'oprations. Pour chaque contrat d'opration nous allons prendre
l'vnement du systme comme message d'attaque de notre diagramme de
collaboration, puis nous allons crer les interactions entre les objets qui, partir
de l, permettent de remplir le service demand. Nous serons vigilant bien
respecter les modles de conception. Il n'est pas un message qui se construise
au hasard. Chaque message envoy d'un objet un autre se justifie par un
pattern de conception ( au moins ) .

Document Millsime Page

OFPPT @ [Link] novembre 17 27 - 47
 Mthode RUP Phase de conception
4.1) Diagramme de collaboration de Enregistrer un article

Enregistrer
article(code) 2: [1er article] crer(date)
3: ajouter(art)
:Caisse :Vente

3.1:ldv := crer(art)

1 art := chercherarticle(code) 3.2: ajouter(ldv)

:Catalogue ldv:lignedevente

:lignedevente

3.1.1: p:=getprix()
3.1.2: desc := getdesc()
1.1 art := chercher(code)

art: article

: Article

4.2) Diagramme de collaboration de dnombrer les articles

identiques
Dnombrer
1: dnombrer(quantit)
( quantit)
:Caisse :Vente

1.2:misejour(quantit)

1.1: ldv :=dernierldv()

Ldv:lignedevente
1.2.2: total ligne := p*quantit
Liste:lignede
vente

1.2.1: p:=getprix()

art: article

Document Millsime Page

OFPPT @ [Link] novembre 17 28 - 47
 Mthode RUP Phase de conception

4.3) Diagramme de collaboration de Finir la vente

Finirvente() 1: Finirvente()
:Caisse :Vente

1.1: termin := vrai

1.3: Total := somme

1.2*: somme := somme+getsstotal() *

Liste:lignede
vente

4.4) Diagramme de collaboration de Payer la vente

Payervente(s) 1:Payersomme(s)
:Caisse v:Vente

1.2:afficher(s-total)
:Afficheur

1.3: crer(v) 1.1: crer(total)

1.4: imprimer()

:Paiement

Le ticket
:ticket
doit
connatre
la vente
pour
imprimer

Document Millsime Page

OFPPT @ [Link] novembre 17 29 - 47
Mthode RUP Phase de conception

Les classes ticket et vente sont troitement couples. Nous pouvons nous poser
la question de savoir si cette classe ticket a un intrt. Il serait bon de faire
l'impression par la vente ( l'expert ), mais en s'appuyant sur une indirection
(imprimante) comme pour l'affichage. Enfin une analyse de tous les uses cases
mettrait en vidence le besoin d'archiver les ventes, pour pouvoir faire les
statistiques. Nous allons donc proposer une solution plus avance de ce
diagramme de collaboration.
On a ici rajout les notions dhistorisation des ventes (qui dcoule dautres use-
case), ce qui nous permet de faire apparatre la classe magasin (singleton).
Cette classe sera fusionne avec la classe catalogue.
En ce qui concerne laffichage, on a choisi dutiliser un afficheur reli
directement la caisse. Il aurait pu tre judicieux de lier lafficheur la ligne
de vente (pour laffichage des descriptions, prix, quantit et sous-total associs
la ligne de vente) et la vente (pour laffichage du total et de la monnaie
rendre).. Dans ce cas, on aurait pu aussi utiliser le pattern singleton pour
modliser cet afficheur (un objet unique, accessible depuis partout).

Document Millsime Page

OFPPT @ [Link] novembre 17 30 - 47
 Mthode RUP Phase de conception
:Afficheur :imprimante

1.2.1:afficher(s-total) 1.8.1: imprimer(line)

1.7*:line := desc+prix+quantit+sstotal

Payervente(s) 1:Payersomme(s)
:Caisse v:Vente

2:historiser(v) 1.2:afficher(s-total)
1.8*: imprimer(line)

1.1: crer(total)

:Magasin

:Paiement

1.3*: desc := getdesc() *

2.1: ajouter(v) 1.4*:prix := getprix() *
1.5*:quantit := getquantit() *
1.6*: sstotal :=getsstotal() *

Ventes:vente

Liste:lignede
vente

1.3.1:desc:=getdesc()
1.4.1:prix:=getprix()

Art: article

Tous les dtails sur l'impression du ticket n'y sont pas ( entte, total, somme
rendue ), mais ce schma donne une bonne vue des relations entre les objets.
Document Millsime Page
OFPPT @ [Link] novembre 17 31 - 47
Mthode RUP Phase de conception

Document Millsime Page

OFPPT @ [Link] novembre 17 32 - 47
Mthode RUP Phase de conception
1.4. treizime tape : le diagramme de classe de
conception

Nous allons enfin construire le diagramme de classes de conception. C'est le

diagramme qui nous montre les classes qui seront dveloppes. C'est donc
l'aboutissement de ce travail d'analyse.
Pour l'ensemble des uses cases qui composent notre cycle de dveloppement,
nous allons raliser le diagramme de classes de conception. Nous allons partir
des diagrammes de collaboration, qui nous donnent les classes dvelopper,
leurs relations ainsi que les attributs par rfrence. Nous complterons ce
diagramme par les attributs venant du diagramme de classe d'analyse.

Nous allons partir uniquement du use case effectuer un achat, donc des quatre
diagrammes de collaboration du chapitre prcdent. Etape par tape, nous
allons construire le diagramme de classe de conception.

1) Premire tape

Nous allons rfrencer toutes les classes rencontres dans les diagrammes de
collaboration. Nous allons les dessiner dans un diagramme de classes. Nous
allons y ajouter les attributs venant du diagramme de classe d'analyse, et les
mthodes venant du diagramme de collaboration.
Nous ne rfrenons que les classes participant nos diagrammes de
collaboration. Les collections ne sont pas rfrences en tant que telles, cela
n'apporte pas de plus value.
Les messages vers les collections n'ont pas lieu d'tre, les collections
supportant ces messages par dfaut.
Les messages de cration par dfaut ne sont pas rfrencs, s'il n'existe pas
de constructeur par initialisation ( car alors ils existent forcment ).
Les slecteurs et les modifieurs n'ont pas de raison de figurer dans ce schma
pour ne pas le surcharger. En effet dans la majorit des cas, ces messages
existent et sont dvelopps la construction de la classe.

Document Millsime Page

OFPPT @ [Link] novembre 17 33 - 47
 Mthode RUP Phase de conception
Caisse Vente

Date : date
Payervente(s:float) Termin : boolen
enregistrerarticle(code : Codebarre) Total : float
dnombrer(quantit : entier) payersomme(s:float)
finirvente() Vente(date:Date)
afficher(total:float) ajouter(art: article)
imprimer(line:text) dnombrerquantit(q:entier)
finirvente()

Magasin Lignevente

Nom : text Quantit : entier Paiement

Adresse : Adresse Sstotal : float
Total : float
historiser(v:vente) getdesc():Text
chercherarticle(code:Codebarre): article getprix():Float Paiement(total:float)
Lignevente(art :article)

Descriptionarticle

Description : text Afficheur Imprimante

Prix : rel
Code : codebarre
afficher(stt:float) imprimer(line:text)

2) Deuxime tape

Il faut maintenant ajouter les associations ncessaires pour montrer la visibilit

par attribut des objets. Cette visibilit par attribut va permettre de construire
les attributs qui rfrencent les objets que l'on doit connatre. Cette association
porte une flche de navigation qui nous permet de connatre l'objet qui doit
connatre l'autre.
Prenons trois exemples :

1) issu du diagramme de collaboration de payervente:

1:payersomme(s)
:Caisse V:Vente

Ici la caisse doit connatre en permanence la vente en cours: nous aurons une
association de type attribut.

Caisse Vente

1 t 1
r .
a
venteencours .
i 0
Document t Millsime Page
OFPPT @ [Link] e novembre 17 34 - 47
Mthode RUP Phase de conception

Cela indique que la classe Caisse a un attribut qui rfrence l'objet vente en
cours. Le nom de rle venteencours donnera, pour une gnration automatique
de code, le nom de l'attribut qui rfrence la vente en cours.

2) issu du diagramme de collaboration de enregistrerarticle :

Ajouter(art)
:Caisse
:Ventes

Ici la caisse a une visibilit de type variable locale sur l article ( cela serait
le mme traitement si il avait une visibilit de type paramtre comme pour la
Vente ). Nous ajouterons des dpendances de type relation entre les deux
classes.

Caisse article

Flche
avec des
pointills

Cette association montre que le code des mthodes de Caisse doit manipuler
la classe article. Il sera donc ncessaire, la gnration de code, d'inclure un
accs la classe article dans la classe Caisse ( import java, ou include c++ ).

3) issu du diagramme de collaboration de payervente :

1:art:=chercherarticle(code)
:Caisse :Catalogue

Ici le magasin est une instance unique pour l'application. Un certain nombre
de classes doivent connatre le magasin. Nous pouvons rsoudre le problme
comme au 1. Mais, si nous ne voulons pas multiplier les rfrences au
magasin, nous pouvons appliquer le pattern Singleton ( Singleton pour instance
unique ).
Cela revient effectivement travailler avec une instance globale, mais fait
proprement, dans des cas rares, et rpertoris. Nous retrouverons la notation
de relation entre les classes, ici pour un accs une variable globale.

Caisse Magasin

$boutic:Magasin

$getInstance()
Document Millsime Page
OFPPT @ [Link] novembre 17 35 - 47
Mthode RUP Phase de conception

Comment est trait le pattern Singleton?

La classe Magasin possde une instance de classe ( statique ) d'un objet d'elle-
mme, et une fonction de classe ( statique). Le code de la fonction est le
suivant:

(exemple en java)
public static Magasin getInstance()
{
if (boutic == null)
{
boutic = new Magasin();
}
return boutic;
}

Ainsi nous aurons une instance unique du Magasin. Cette instance peut tre
appele partout en utilisant le formalisme suivant:

(exemple en java)
Magasin monbazar = [Link]();

Voici maintenant le diagramme de classe de conception de notre exercice:

Document Millsime Page

OFPPT @ [Link] novembre 17 36 - 47
 Mthode RUP Phase de conception
Afficheur Imprimante

affichet(stt:float) imprimer(line:text)

1 1

possde
possde

0
Vente
.
1 . : date
Date
1
1
ralise
Termin : boolen
1 : float
Total
Caisse
payersomme(s:float)
1 Venteencours 1 Vente(date:Date,c:Caisse)
Se fait sur ajouter(art:article)
Payervente(s:float)
dnombrerquantit(q:entier
enregistrerarticle(code :
)
Codebarre)
Historique * finirvente()
dnombrer(quantit : entier)
finirvente() 1 1
afficher(total:float) effectue
imprimer(line:text)

enregistre
0
.
Paiement .
1
Total : float
1 contient
Paiement(total:floa
Magasin t)

Nom : text
Adresse : Adresse
$boutic:Magasin

historiser(v:vente)
chercherarticle(code:Codebarre): article
$getInstance():Magasin
1
.
Lignevente
1 .
Quantit : entier *
Sstotal : float
rfrence
rfrence
*
getdesc():Text
getprix():Float
Lignevente(art :article)
*
1
catalogu
article
e
Description : text
Prix : rel
Code : codebarre

Document Millsime Page

OFPPT @ [Link] novembre 17 37 - 47
Mthode RUP Phase de conception
Notes sur le diagramme de conception:

Quand la vente en cours est cre, il faut lui associer la caisse sur
laquelle s'effectue la vente. Nous avons fait le choix que la vente ne
connaisse que la caisse, plutt que de connatre chacun de ses lments
( afficheur, imprimante, )
La caisse joue un double rle: celui d'interface pour le use case effectuer
un achat, et l'indirection vers les composants physiques de la caisse. Si
la caisse devient trop complexe, il vaut mieux couper la classe en deux,
d'un cot l'interface du use case, et de l'autre ct l'interface vers les
composants de la caisse elle-mme. Nous ne l'avons pas fait dans le
cadre de cet exercice.
Quand entre deux classes, il existe dj une association
( ), il n'est pas utile d'y rajouter une relation
( ). Cela n'apporte rien, sinon du bruit.
Ici, nous n'avons pas rajout les indicateurs de visibilit ( public +, priv
-,), tant bien entendu que les mthodes sont publiques, et les
attributs sont privs. Les fonctions d'accs aux attributs sont sous-
entendues.
Les noms de rle mis sur certaines associations donnent le nom de
l'attribut dans la classe concerne. Les associations sont
unidirectionnelles et donne le sens de la visibilit. Le diagramme nous
montre que la classe Caisse a un attribut qui s'appelle venteencours qui
rfrence la vente en cours. De mme la classe Magasin a un attribut qui
s'appelle catalogue et qui est une collection darticles ( c'est la cardinalit
qui nous montre que dans ce cas c'est une collection ).

Les trois relations prsentes sont des trois types possibles ( global, paramtre
et local )

Document Millsime Page

OFPPT @ [Link] novembre 17 38 - 47
Mthode RUP Phase de conception
1.5. quatorzime tape : le codage

A partir des diagrammes de collaboration et du diagramme de classe de

conception, on en dduit simplement des lments de codage associs. En
voici quelques exemples :

class Caisse
{
private Catalogue cat ;
private Vente v ;
public void enregistrerarticle(int code)
{
Article art=[Link](code) ;
if (v==null)
{
v=new Vente() ;
}
[Link](art) ;
}
public void finvente()
{
[Link]() ;
}
.
}

class Catalogue
{
private Hashtable articles=new Hashtable() ; ;

public Article chercherarticle(int code)

{
return [Link] (code) ;
}
.
}

class Vente
{
private boolean ventetermine = false ;
private Vector lignes = new Vector() ;
public void ajouter(Article art)
{
[Link](new Ldv(art)) ;
}
public void finvente()
{
ventetermine= true ;
}
public float total()
Document Millsime Page
OFPPT @ [Link] novembre 17 39 - 47
Mthode RUP Phase de conception
{
float total=0 ;
Enumeration e=[Link]() ;
while ([Link]())
{
total+=((Ldv)[Link]()).soustotal();
}
return total;
}

.
}

class Ldv
{
private int qte ;
private Article art ;
.
public Ldv(Article a)
{
[Link]=a ;
}
public void soustotal()
{
return qte*[Link]() ;
}
public denombrer(int newqte)
{
setqte(newqte) ;
}
.
}

class Article
{
private int code=0 ;
private float prix=0 ;
private String desc= ;
public Article(int code, float prix, String desc)
{
[Link]=code ;
[Link]=prix;
[Link]=desc;
}
public int getcode()
{
return code;
}
public int getprix()
{
return prix;
Document Millsime Page
OFPPT @ [Link] novembre 17 40 - 47
Mthode RUP Phase de conception
}
public int getdesc()
{
return desc;
}

.
}

Document Millsime Page

OFPPT @ [Link] novembre 17 41 - 47
Mthode RUP Phase de conception
2. Le processus unifi
Le processus unifi est la dmarche danalyse et de conception qui sappuie sur
le langage UML pour sa modlisation. Ce que nous avons vu jusqu prsent,
cest une dmarche linaire pour partir dun besoin utilisateur jusqu sa
ralisation. Ceci nest pas reprsentatif de la ralit des dveloppements. Un
dveloppement dun projet informatique va tre incrmental et itratif. Cela
permet dviter leffet tunnel des projets classiques ( le client perd de vue son
logiciel entre le cahier des charges et la livraison ). Ici le projet est dvelopp
en concertation avec le client, le dialogue doit tre permanent, les livraisons se
font rgulirement, permettant dintervenir au plus tt si il y a un cart entre
le besoin du client et le logiciel ralis.

Nous allons donc mettre en 3 dimensions le processus que nous avons tudi.

2.1. Notion de lot ( ou de cycle )

Un lot, ou un cycle de dveloppement, permet de livrer au client une version

de logiciel. Il est important de faire des livraisons rgulires du logiciel, pour
que le client garde le contrle du logiciel que nous lui dveloppons.
Typiquement un cycle peut durer trois semaines deux mois. Les exceptions
viendront des gros logiciels, o une nouvelle version sort tous les ans.

Comment sy prendre pour dcouper un logiciel en lot ? Nous allons lister

lensemble des uses cases, en les valuant suivant deux critres : leur
importance pour le client, et le risque technique de ralisation, en notant par
exemple de un cinq chacun des critres.
Nous comprenons bien quil vaut mieux raliser dabord un module de
facturation quun module daide en ligne pour un commerant. Il est aussi
important de raliser dabord les exigences fort risque technique, afin de
vrifier la faisabilit technique, et la validit de la solution.

Nous classerons les uses cases par leur pondration ( risque + importance ).
Puis nous donnerons une logique ce classement. Cela peut nous amener
ne vrifier quune faisabilit pour un use case particulier, ou traiter une partie
des exigences dun use case dans un premier lot, et les autres dans un lot
suivant.
Ce dcoupage sera valid par le client, et nous donnera les diffrentes livraisons
qui seront faites au client.

2.2. Notion de phases

Un lot est compos de plusieurs phases. Il y a 4 phases dans le

dveloppement dun lot :
Inception ou cration

Document Millsime Page

OFPPT @ [Link] novembre 17 42 - 47
Mthode RUP Phase de conception
Elaboration
Construction
Transition

Nous allons voir en quoi consiste chaque phase, puis nous verrons que chaque
phase est constitue dune ou plusieurs itrations.

Inception : Cette phase sert prouver la faisabilit.

Effort : 5% du temps total.

Objectif :
apprhender le contexte du dveloppement.
Connatre, dans les grandes lignes, les services rendus aux utilisateurs
principaux.
Mettre en vidence les risques, et vrifier quils sont matriss.
Choisir une architecture.
Planifier la phase suivante
Estimer assez prcisment les cots, dlais, ressources ncessaires.
Documents produits :
Principaux cas dutilisation
Descriptions de haut niveau de ces uses cases

Elaboration : Cette phase sert construire larchitecture de base, et

dfinir la plupart des exigences.

Effort : 20% du temps total.

Objectif :
Recueillir les exigences.
Mettre en uvre les exigences haut risque.
Faire une description dtaille des uses cases.
Crer larchitecture du logiciel.
Dfinir les niveaux de qualit requis pour le systme ( fiabilit, temps de
rponse, )
Planifier et budgter le dveloppement
Documents produits :
Uses cases dtaills
Diagrammes de squences bote noire.
Diagramme de classes danalyse.
Diagramme de classe de conception, diagrammes de collaboration, et
contrats doprations sur quelques classes qui permettent de rendre le risque
matrisable.

Construction : Cette phase sert btir le systme.

Effort : 65% du temps total.

Objectif :
Etendre lanalyse et la conception lensemble des classes non critiques du
systme.
Coder ces classes.
Document Millsime Page
OFPPT @ [Link] novembre 17 43 - 47
Mthode RUP Phase de conception
Tester les classes unitairement.
Prparer les tests du systme.
Documents produits :
Modle du domaine.
Diagramme de classe de conception, diagrammes de collaboration, et
contrats doprations sur quelques classes qui permettent de rendre le risque
matrisable.
Code.
Tests et procdures de test du systme.
Surveiller les risques dtects en phases amont.

Transition : Cette phase sert tester et dployer le produit chez le ou

les utilisateurs.

Effort : 10% du temps total.

Objectif :
faire les bta tests.
convertir les donnes antrieures.
former les utilisateurs.
finalisation des manuels utilisateurs.
corriger les derniers bugs.
Documents produits :
Diagrammes de composants.
Diagramme de dploiement.

2.3. Notion ditration

Chacune des phases dcrites, peut tre effectue en plusieurs itrations. Par
exemple dans la phase de conception, les itrations peuvent tre trs brves
( de lordre de la demi journe, jusqu deux jours ), et consiste
implmenter une classe par exemple.
Dans la phase dlaboration, une itration pourra par exemple traiter dun
risque particulier.

Document Millsime Page

OFPPT @ [Link] novembre 17 44 - 47
Mthode RUP Phase de conception
3. conclusion
Nous avons vu quune mthode ( de type Unified Process ) qui sappuie sur UML,
permettait davoir une dmarche danalyse et de conception qui nous amne de
manire continue du problme du client, vers le systme quil dsire.

Cette mthode est incrmentale et itrative. Le client voit se construire son

logiciel petit petit, peut donc se lapproprier, se former, et mieux adapter le
logiciel par rapport son besoin. Cette mthode permet au client de participer
llaboration du logiciel, et permet aux dveloppeurs de prendre en compte les
remarques du client sans avoir remettre en cause tout ce qui a dj t ralis.

Elle permet galement de se construire des bibliothques dobjets mtiers, qui

permettront de rduire les cots des prochains logiciels raliser. Les
informaticiens vont enfin pouvoir capitaliser leurs comptences au sein de
bibliothques dobjets.

Document Millsime Page

OFPPT @ [Link] novembre 17 45 - 47
Mthode RUP Phase de conception

Pour approfondir le sujet.

Proposition de rfrences utiles permettant dapprofondir le thme abord

o UML2 et les Design Patterns - Auteur Craig Larman (ditions Pearson)

o Tte la premire Design patterns auteurs Eric et lisabeth Freeman (OReilly)
o Le pattern MVC - Ralisation sur un cas simple

Sources de rfrence

Document Millsime Page

OFPPT @ [Link] novembre 17 46 - 47