Vous êtes sur la page 1sur 50

Licence GI 2012

FST SETTAT

CAISSE
SUPERMARCHE

Licence GI 2012

FST SETTAT

Etude de cas
Ralisation d'une caisse informatise.
Un commerant de produits touristiques ( souvenirs, livres rgionaux, ...) dsire informatiser
sa caisse. Chaque type de produit possde un code unique ( tiquette code barres ), et un
mme prix pour tous les produits de ce type. L'objectif est de faciliter la maintenance des prix
des articles.
Chaque type de produit est rfrenc dans un catalogue, avec son prix associ. Quand le prix
d'un produit doit tre modifi, le manager modifie son prix dans le catalogue, puis sur
l'tagre o il est rang.
Le caissier s'identifie pour dmarrer la caisse ( avec mot de passe ).
La caisse fera les fonctions habituelles d'une caisse : calcul du sous total, calcul du total,
possibilit de rentrer plusieurs articles ayant un mme code, retour d'une marchandise avec le
ticket de caisse. Le paiement se fera en monnaie seulement.
La caisse permet d'diter des rapports :
Le reu qui sera donn uniquement pour une vente effective. Il contient le nom du
magasin, un message de bienvenue, la date et l'heure. Puis pour chaque vente il donne le
code du produit, la description du produit, le prix unitaire, la quantit et le sous total.
Enfin nous y trouvons le total TTC.
Le rapport quotidien de l'ensemble des ventes ( date, heure, total ).
Le rapport quotidien dtaill: liste de l'ensemble dtaill des ventes de la journe.
La caisse s'excute sur un PC. Une douchette permettra de lire les codes barres. Les
informations peuvent tre rentres au clavier, ou la souris.

Licence GI 2012

FST SETTAT

1. Diagramme dacteurs

Regardons maintenant les acteurs qui gravitent autour de notre application.

Cais sier

Client

Manager

(from Us e Cas e View)

(from Us e Cas e View)

(from Us e Cas e View)

Salari

Adminis trateur

(from Us e Cas e View)

(from Us e Cas e View)

les acteurs de l'application

Licence GI 2012

FST SETTAT

premire tape : les exigences et les acteurs


Les exigences que nous allons dcouvrir sont les exigences fonctionnelles. A partir du
problme pos, c'est dire de tout ce qui est crit, plus tout ce qui ne l'est pas, nous allons
lister l'ensemble des fonctions qui pourront tre ralises par le logiciel. Ces exigences seront
numrotes pour pouvoir les tracer dans les intentions d'acteur puis dans les uses cases.

Rfrence
R1
R2
R3
R4
R5
R6
R7
R8
R9
R10
R11
R12
R13
R14
R15
R16

Fonction
Modifier le prix d'un produit
Calculer le total d'une vente
Rentrer une quantit par article
Calculer le sous total d'un produit
Retourner une marchandise
Payer l'achat
Editer un ticket de vente
Editer un rapport succinct
Editer un rapport dtaill
Se connecter la caisse
Se connecter en grant
Dfinir les droits des usagers
Entrer un produit au catalogue
Supprimer un produit du catalogue
Enregistrer un produit la caisse
Initialiser la caisse

Notons que les exigences ne sont pas classes ici.


2. Diagramme de contexte statique

Licence GI 2012

FST SETTAT

0..*
1

Client
(from Use Case View)

Cais sier

(from Use Case View)


est dans

est la caisse

0..1
0..1
m agas in
0..*
travaille dans
0..*

0..*

1..*

gre

adm inistre
1

1
Salari

Manager
(from Use Case View)

(from Use Case View)

adm inistrateur
(from Use Case View)

Diagram m e de contexte statique (capture initiale des besoins )

Licence GI 2012

FST SETTAT

deuxime tape : les intentions dacteurs

Rfrence
R1
R13
R14
R16
R5
R10
R11
R8
R9
R12
R7
R6
R2
R3
R15
R4

Fonction
Modifier le prix d'un produit
Entrer un produit au catalogue
Supprimer un produit du catalogue
Initialiser la caisse
Retourner une marchandise
Se connecter la caisse
Se connecter en grant
Editer un rapport succinct
Editer un rapport dtaill
Dfinir les droits des usagers
Editer un ticket de vente
Payer l'achat
Calculer le total d'une vente
Rentrer une quantit par article
Enregistrer un produit la caisse
Calculer le sous total d'un produit

Intention d'acteur
Grer le catalogue
Grer le catalogue
Grer le catalogue
Initialiser la caisse
Retourner un article
Se connecter
Se connecter
Editer un rapport
Editer un rapport
Dfinir les profils
Effectuer un achat
Effectuer un achat
Effectuer un achat
Effectuer un achat
Effectuer un achat
Effectuer un achat

Acteurs
Manager

Manager
Client, Caissier
Salari
Manager
Administrateur
Client, Caissier

Licence GI 2012

FST SETTAT

Licence GI 2012

FST SETTAT

troisime tape : le diagramme de use case

Diagramme de use case

Effectuer un achat

Client
Retourner un article

Les flches unidirectionnelles

Se connecter

les flches unidirectionnelles


indiquent un
un lien
lien principal,
principal, cest
indiquent
dire lacteur
principal
du usedu
case
c'est
dire l'acteur
principal
use case.

Caissier

Grer le catalogue

Salari

Manager

Initialiser la caisse

Editer un rapport

administrateur
Dfinir les profils

Licence GI 2012

FST SETTAT

quatrime tape : use case description de haut niveau


Il nous faut maintenant dfinir les uses cases. Cette description est une description de haut
niveau qui se fait avant l'analyse. Nous sommes toujours dans la dfinition du besoin.
Une description de haut niveau d'un use case est une description textuelle qui comprend les
chapitre suivants:

Nom du Use Case:


Acteur principal:
Acteurs secondaires:
Evnement dclencheur du Use Case:
Rle du Use Case:
Terminaison du Use Case:

Effectuer un achat
Client
Caissier
Un client arrive la caisse avec ses achats
Le caissier passe tous les articles, fait la note, et
encaisse le paiement.
Le client a pay et a ramass tous ses articles.

Licence GI 2012

FST SETTAT

L'analyse
Nom du Use Case:
Acteur principal:
Acteurs secondaires:

Effectuer un achat
Client
Caissier

Evnement dclencheur du Use Case:

Un client arrive la caisse avec ses achats

Rle du Use Case:

Le caissier passe tous les articles, fait la note, et


encaisse le paiement.

Terminaison du Use Case:

Le client a pay et a ramass tous ses articles.

Les rfrences croises des exigences:

R2, R3, R4, R6, R7, R15

Les pr conditions ncessaires au fonctionnement du use case: La caisse est allume et


initialise. Un caissier est connect la caisse.
Description complte du use case, avec les diffrents scnarios:
Ici il n'y a qu'un scnario possible. Nous verrons dans l'exemple suivant un use case avec
plusieurs scnarios pour mettre en vidence le diagramme d'activit.

Licence GI 2012

Actions des acteurs


Rponses du systme
1) Le client arrive la caisse avec les articles
qu'il dsire acheter.
2) Le caissier enregistre chaque article.
3) Le systme dtermine le prix de l'article,
les informations sur l'article et ajoute ces
informations la transaction en cours. Il
affiche ces informations sur l'cran du client
et du caissier.
4) Le caissier indique la fin de vente quand il 5) Le systme calcule et affiche le montant
n'y a plus d'article.
total de l'achat.
6) Le caissier annonce au client le montant
total.
7) Le client donne au caissier une somme
d'argent suprieure ou gale la somme
demande.
8) Le caissier enregistre la somme donne par 9) Le systme calcule la somme rendre au
le client.
client.
10) Le caissier encaisse la somme remise par 11) Le systme enregistre la vente effectue
le client et rend la monnaie au client.
12) Le systme dite le ticket de caisse
13) Le caissier donne le ticket de caisse au
client
14) le client s'en va avec les articles qu'il a
achets.
Variantes du scnario nominal ( celui qui se droule quand tout se passe bien ).
Paragraphe 2: il peut y avoir plusieurs articles d'un mme produit. Le caissier enregistre le
produit ainsi que le nombre d'articles.
Paragraphe 3: s'il y a plusieurs articles d'un mme produit le systme calcule le sous total.
Paragraphe 2: Le code produit peut tre invalide. Le systme affiche un message d'erreur.
Paragraphe 7: Le client n'a pas la somme d'argent suffisante. La vente est annule. Remarque:
Ceci est une exception qui termine anormalement le use case.
Paragraphe 8: Le caissier n'a pas la monnaie pour rendre au client. Il va faire la monnaie la
caisse principale. Remarque: ici nous avons fait apparatre un nouvel acteur: le caissier
principal ( ce sera probablement la mme personne que le manager mais un acteur diffrent ).
Paragraphe 12: le systme ne peut pas diter le ticket de caisse. Un message est affich au
caissier, et celui-ci change le rouleau de papier.
Paragraphe 14: remarquons que si le client repart sans ses articles, il est probable que le
caissier les lui mettra de cot. Cet vnement ne change rien notre systme futur. Ce genre
d'incident ne sera pas pris en considration.

FST SETTAT

Licence GI 2012

En terme de reprsentation nous pouvons prfrer mettre une colonne par acteur pour bien
voir les responsabilits des acteurs vis vis du systme. Ici cela donnerait:
Actions du client
Actions du caissier
1) Le client arrive la caisse 2) Le caissier enregistre
avec les articles qu'il dsire chaque article.
acheter.

Rponses du systme
3) Le systme dtermine le
prix de l'article,
les
informations sur l'article et
ajoute ces informations la
transaction en cours. Il affiche
ces informations sur l'cran
du client et du caissier.
4) Le caissier indique la fin de 5) Le systme calcule et
vente quand il n'y a plus affiche le montant total de
d'article.
l'achat.
6) Le caissier annonce au
client le montant total.
7) Le client donne au caissier 8) Le caissier enregistre la 9) Le systme calcule la
une
somme
d'argent somme donne par le client.
somme rendre au client.
suprieure ou gale la
somme demande.
10) Le caissier encaisse la 11) Le systme enregistre la
somme remise par le client et vente effectue
rend la monnaie au client.
12) Le systme dite le ticket
de caisse
13) Le caissier donne le ticket
de caisse au client
14) le client s'en va avec les
articles qu'il a achets.
Cette reprsentation met en vidence que le client n'a pas accs au systme informatique.
Contraintes d'IHM ( optionnel ): La dsignation de l'article et son prix ( ventuellement le
sous total si plusieurs occurrences du mme article ) sont affichs chaque article au caissier
et au client. Le total est affich galement aux deux.
Contraintes non fonctionnelles ( optionnel ): Le magasin reoit en moyenne 200 clients par
jour. Chaque client achte en moyenne 10 articles.

FST SETTAT

Licence GI 2012

FST SETTAT

Voici un exemple de diagramme d'activit reprsentant la runion de scnarios modlisant un


use case.
supprim er un
article

saisir le code

dtruire la rfrence

saisir et valider le prix

vrifier le code

modifier le prix
d'un article

saisir les infos du produit

vrifier le code

enregistrer le produit

ajouter un
article

ralisation d'un diagram me d'activit ( ici ce n'est pas la norm e UML car la version
de rose utilise ne supporte pas les diagram mes d'activit ). Ce schm a a t
construit partir d'un diagramm e d'tat.

Note :

Ceci reprsente un commentaire dans tout schma UML.


commentaire

Licence GI 2012

FST SETTAT

sixime tape : diagramme de squence bote noire

Systme inform atique


: magasin

: Salari

login ( nom , m otpasse )


Le login est accept si le
Lelelogin
login
est
accept
accept
sisilelesalari
salari
estest
connu,
et que
estsalari
connu
est
etp)asse
si
connu,
son mot
et son
de passe
son
mot de
est
correct.
estmot
correct
de passe est correct

message bienvenue

retour de la demande
de login OK

logout()

vnement

systme inform atique


: magasin

: Caissier
pour chaque
article

enregistrer un article ( code )


description et prix article

si code
rfrenc
dnom brer ( quantit )
si quantit > 1

sous total = prix * quantit

fin de vente ( )
plus d'article

prix total

payer ( somme )
monnaie
ticket

ici la rponse
est asynchrone

Licence GI 2012

FST SETTAT

septime tape : diagramme de classe danalyse


caissier
0..1

catalogue

utilise
1

0..1

caisse
se fait partir
1
Paiement

effectue
0..1

paye par

1
vente
gnre

1
contient

ticket
1

comprend

1..*
ligne de vente
0..*
est dcrite par
1

0..*
article

Licence GI 2012

FST SETTAT

Voici notre diagramme de classe enrichi des attributs d'analyse.


caissier
0..1

catalogue

utilise
1

0..1
caisse

se fait partir

1
Paiement
somme : rel

effectue
0..1

1
paye par

1
1

gnre
ticket

vente
date : Date
heure : Heure
1

contient
1
comprend
1..*
ligne de vente
quantit : entier

le prix ou la
somme devraient
se donner par
rapport une
monnaie...

0..*
est dcrite par
1

0..*
description article
description : text
prix : rel
code : codebarre

Licence GI 2012

FST SETTAT

neuvime tape : les contrats d'opration

Contrat d'opration type:

Nom:
Responsabilits:
Exigences:

Notes:
Pr conditions:
Post conditions:

Nom de l'opration avec ses paramtres.


Description du rle de l'opration.
Liste des exigences dont le use case tient compte dans cette
itration.
Remarques diverses.
Etat ncessaire du systme pour que l'opration se fasse.
Etat du systme lorsque l'opration s'est droule entirement.

Les Pr conditions dcrivent l'tat du systme, c'est--dire l'tat des objets du systme comme
dcrit dans le diagramme des classes d'analyse.
Nous jouons l'opration sur le systme, en aveugle, et jusqu' sa fin.
Notons les changements de l'tat du systme ( des objets et de leurs associations ) et nous
obtenons les post conditions. Ces post conditions sont dcrites sous la forme "has been", c'est-dire l'objet X a t modifi, son attribut Y a t mis vrai.
Les post conditions portent sur 6 clauses:
Les objets crs.
Les objets dtruits.
Les associations cres.
Les associations dtruites.
Les attributs modifis.
Les vnements d'affichage ( fonctionnels bien sr !!! ).
Prenons un exemple simple pour traiter ces contrats d'opration.
Modifier le prix d'un article au catalogue.

Nom:
Responsabilits:

Exigences:
Notes:

Pr conditions:
Post conditions:

modifier (cecode, nouveauprix).


modifier le prix d'un article de code donn, prsent dans le
catalogue.
R1, R13, R14 pour le use case grer le catalogue.
Si le code ne correspond pas a un article du catalogue, un
message d'erreur sera envoy au manager et l'opration s'arrte.
Il y a un article correspondant au code donn.
l'attribut prix de l'objet description article, dont le code est
cecode, a t chang par nouveauprix.

Nous allons faire les contrats d'opration des oprations du use case effectuer un achat. Pour
cela il faut partir du diagramme de squence bote noire du use case effectuer un achat et du
diagramme de classe d'analyse, et pour chaque flche dirige vers le systme, rdiger un
contrat dopration. Par exemple :
Enregistrer un article.

Licence GI 2012

Nom:
Responsabilits:

Exigences:
Notes:

Pr conditions:

Post conditions:

FST SETTAT

enregistrer un article (cecode).


enregistrer un article lors d'une vente, et l'ajoute la vente en
cours.
R15 pour le use case effectuer un achat.
Si l'article est le premier de la vente, il dbute la vente.
Si le code cecode n'est pas rfrenc dans le catalogue, un
message d'erreur est envoy au caissier.
Il y a un article correspondant au code donn.
Il y a un caissier la caisse.
Si c'est le premier article de la vente, il faut qu'un objet vente ait
t cr et associ la caisse.
Une ligne de vente ( ldv ) a t cre. Elle a t associe un
article correspondant au code cecode.
La ligne de vente ldv a t associe la vente.
Le prix et la description de l'article ont t affichs.
L'attribut quantit a t mis 1.

Dnombrer les articles identiques.

Nom:
Responsabilits:

Exigences:
Notes:
Pr conditions:

Post conditions:

dnombrer (quantit).
donne le nombre d'articles identiques l'article enregistr, et
calcule le sous total.
R3, R4 pour le use case effectuer un achat.
Il y a une ligne de vente ( ldv ) correspondant au dernier article
enregistr.
L'attribut quantit de ldv est affect.
Le sous total ( ldv.quantit*prix ) est affich.

Finir la vente.

Nom:
Responsabilits:
Exigences:
Notes:
Pr conditions:
Post conditions:

finir vente ( ).
finit une vente et calcule le prix total de la vente.
R2 pour le use case effectuer un achat.
Il existe une vente et au moins une ligne de vente.
La vente est marque termin. Notons ici que nous avons
besoin d'enregistrer le fait que la vente soit finie. Cela nous
amne dfinir un attribut boolen vente termine.
Le prix total de la vente est affich. Ici aussi nous allons
enregistrer le prix total de la vente dans l'objet vente. Cela nous
amne dfinir un attribut rel Total.

Payer la vente.

Nom:

payer la vente (somme).

Licence GI 2012

Responsabilits:
Exigences:
Notes:

Pr conditions:
Post conditions:

FST SETTAT

calcule la monnaie rendre et imprime le ticket de vente.


R7 pour le use case effectuer un achat.
Si la somme n'est pas suffisante un message est envoy au
caissier.
Il y a une vente v en cours marque termin.
Un objet de type Paiement p a t cr.
P a t associ la vente v.
V. total a t affect p.somme.
La monnaie rendre ( somme p.somme ) a t affiche.
Un ticket t a t cr.
La vente v a t associe au ticket t.
Le ticket de vente a t imprim.

Nous allons voir une autre manire de reprsenter ces contrats d'opration l'aide de
diagramme de squence bote blanche. Cette manire de reprsenter les contrats d'opration
est beaucoup plus utilise que la manire textuelle. Elle n'est pas forcment mieux d'ailleurs
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.

Licence GI 2012

FST SETTAT
: catalogue

: Manager

article

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.

Maintenant nous allons faire les diagrammes de squence bote blanche des oprations du use
case effectuer un achat.
Diagramme de squence bote blanche de enregistrer un article.
: caisse

v : vente

ldv : ligne de
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

art : article

: catalogue

Licence GI 2012

FST SETTAT

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.

: Caissier

: caisse

dnombrer(q)

v : vente

ldv : ligne de
vente

: article

ldv = slectionner dernier ldv()

modifquantit(q)
p = getprix()
afficher(ldv.quantit*p)

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

: caisse

: Caissier

: vente

finir vente()
set termin(true)
T = calculer Total()

setTotal(T)

Total Total
afficher
cela ncessite de
parcourir toutes les
lignes de vente

Licence GI 2012

FST SETTAT

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

: caisse

: Caissier

: vente

p : Paiement

t : ticket

payer (s)
payer(s)
create(v.Total)

s-v.Total
afficher(s-v.Total)
create()
im prim er()

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.

Licence GI 2012

FST SETTAT

La conception
dixime tape : le diagramme dtat

nouvel article
arrive article / cration vente
dmarrer caisse
attente

traitem ent un article

do afficher en boucle bonjour


abandon / dtruire vente

ticket rem is / historiser vente

entry: afficher prix + description


entre quantit/afficher quantit
et sous total

abandon / dtruire vente


fin vente / afficher total

arrter caisse
im pression en cours
entry : lancer
im pression

attente paiement
somm e saisie / afficher monnaie

Etat de la caisse concernant le use case effectuer un achat

Licence GI 2012

FST SETTAT

onzime tape : le diagramme de collaboration

Modifierprix(code,prix)

1 :Modifierprix(code,prix)

:caisse

:catalogue

1.1 :art := chercher(code) : article


1.2 : setprix(prix)

art : article
: article

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

Modifierprix(code,prix)

Objet
anonym
e
1 :Modifierprix(code,prix)

:caisse

:catalogue

1.1 :art := chercher(code) : article


Objet
nomm

Multi
objet

1.2 : setprix(prix)

art : article
: article

Licence GI 2012

FST SETTAT

b) la syntaxe des messages

Message
initial issu
du
diagramme
de squence

Modifierprix(code,prix)

Caisse envoie
un message
catalogue
Dabord le
catalogue
:catalogue
cherche
larticle

1 :modifierprix(code,prix)

:caisse

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 :
Valeur
de
retour

message
Type de
retour du
message

1.1 :art := chercher(code) : article

numro

affectatio
n

Paramtre(s
) du
message

Licence GI 2012

FST SETTAT

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

:caisse
connat
lobjet :catal
ogue

:catalogue

1.1 :art := chercher(code) :article


1.2 : setprix(prix)

art : article
:article

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

1 :msg()

Message
habituel, ici
simplifi

1.1[x>y] :message()

:A
numro

:B

conditio
n

Le message nest envoy :B que si la condition x>y est remplie lors du droulement du code
de msg() dans la classe A.

Licence GI 2012

FST SETTAT

Les messages conditionnels exclusifs ( ou si sinon)

1 :msg()

1.1a[x>y] :messageb()

:A

:B
conditio
n

Numro
avec une
letrre

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.

Licence GI 2012

FST SETTAT

1 :Ajouter(desc,prix,code,qt)

:catalogue

1.1 :Create(desc,prix,code,qt)

Nouvelarticle
: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 ?).

Les messages itratifs


Ici itration
de 1 10

* aprs le
numro
indique une
itration
1 :msg()

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

:A

:B

Le message sera envoy dix fois lobjet :B. De manire gnrale ltoile 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 :msg()

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

:A

:B
Itration
sur i de 1
10

1.2*[ i :=1..10] :messagec()


:C
Itration
sur le
mme i
toujours de

Ici nous envoyons successivement un message :B, puis un message :C, le tout 10 fois. Il
ny a quune seule boucle.

Les messages itratifs distincts

Licence GI 2012

FST SETTAT

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

1 :msg()

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

:A

:B
Itration
sur i de 1
10

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

Licence GI 2012

FST SETTAT

Les multiobjets acceptent de manire gnrale un certain nombre de messages:

Trouver :
Ajouter :
Supprimer :
Taille :
Suivant :
Contient :
d'une cl.

Itration sur les lments d'un multiobjet

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


ajoute un lment au multiobjet.
supprime un lment du multiobjet.
donne le nombre d'lments du multiobjet.
permet de passer l'lment suivant du multiobjet.
permet de savoir si un lment est prsent dans le multiobjet partir

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 *

Cette toile
montre une
itration sur
tous les

: article

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

:catalogue

1.2*: imprimer(s)

Systeme

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


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

Licence GI 2012

2)

FST SETTAT

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.

:caisse

1: desc := getdesc(code):String

: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:

Val := Vrifier(art:article): entier

:caisse

Celui-ci c'est le
mme
1: p := getPrix(): entier

Que
celui-l
art :article

Licence GI 2012

FST SETTAT

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)

:caisse

1:art:= getart(code): article

: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 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.
Voici un diagramme de collaboration qui illustre cet exemple.

Licence GI 2012

:X

FST SETTAT

1: m =getInstance()

Magasin

2: xxx()

3)

Ceci est
une classe

Ceci est
l'instanc
e unique

m:Magasin

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.
Contrat d'opration: une ligne de vente a t cre.

Systme informatique

:caisse

:vente

Qui cre
la ligne
de vente ?
Create ?

Create ?

:magasin

L:lignevente
Create ?

Licence GI 2012

FST SETTAT

La rponse ces questions va influencer normment 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?
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

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.

Licence GI 2012

FST SETTAT

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
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?

:vente

Desc := getdescription( code ) : descriptionarticle

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

Licence GI 2012

FST SETTAT

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.

Interface utilisateur

Objets de l'interface utilisateur


( Frame )

Systme informatique

objets du sytme informatique

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

Licence GI 2012

FST SETTAT

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 )

Regardons notre schma des changes entre les couches UI et mtier.


Interface utilisateur

Objets de l'interface utilisateur


( Frame )

Systme informatique

objets du systme informatique

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

Licence GI 2012

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.
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.
Prenons un exemple:

FST SETTAT

Licence GI 2012

FST SETTAT

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:

Total = totalvente():float

:Caisse

1:P:=paiement():Paiement

2:Total := totalvente():float

Caisse
et
paiemen
t sont

:Vente

p:Paiement

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

:Caisse

1:Total:=totalvente():float

Vente et
paiement se
connaissait dj.
Pas de couplage
supplmentaire

:Vente

1.1:Total := totalvente():float

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

Licence GI 2012

FST SETTAT

message qui se construise au hasard. Chaque message envoy d'un objet un autre se justifie
par un pattern de conception ( au moins ) .
4.1) Diagramme de collaboration de Enregistrer un article
Enregistrer
article(code)
:Caisse

2: [1er article] crer(date)


3: ajouter(art)

:Vente

3.1:ldv := crer(art)
1 art := chercherarticle(code)

:Catalogue

3.2: ajouter(ldv)

ldv:lignedevente
:lignedevente

1.1 art := chercher(code)

3.1.1: p:=getprix()
3.1.2: desc := getdesc()

art: article
: Article

4.2) Diagramme de collaboration de dnombrer les articles identiques


Dnombrer
( quantit)

1: dnombrer(quantit)
:Caisse

:Vente

1.2:misejour(quantit)
1.1: ldv :=dernierldv()

1.2.2: total ligne := p*quantit

Ldv:lignedev
ente

1.2.1: p:=getprix()

art: article

Liste:lignede
vente

Licence GI 2012

FST SETTAT

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

:Afficheur

v:Vente

1.2:afficher(s-total)

1.3: crer(v)
1.4: imprimer()

1.1: crer(total)

:Paiement
Le ticket
doit
connatre
la vente
pour
imprimer

:ticket

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.

Licence GI 2012

FST SETTAT

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

:imprimante

1.2.1:afficher(s-total)

1.8.1: imprimer(line)
1.7*:line := desc+prix+quantit+sstotal

Payervente(s)

2:historiser(v)

:Caisse

1:Payersomme(s)

v:Vente

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

1.1: crer(total)
:Magasin
:Paiement

1.3*: desc := getdesc() *


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

2.1: ajouter(v)

Ventes:vent
e
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.

Licence GI 2012

FST SETTAT

douzime 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.
Caisse

Vente

Payervente(s:float)
enregistrerarticle(code : Codebarre)
dnombrer(quantit : entier)
finirvente()
afficher(total:float)
imprimer(line:text)

Date : date
Termin : boolen
Total : float
payersomme(s:float)
Vente(date:Date)
ajouter(art: article)
dnombrerquantit(q:entier)
finirvente()

Magasin

Lignevente

Nom : text
Adresse : Adresse

Quantit : entier
Sstotal : float

historiser(v:vente)
chercherarticle(code:Codebarre): article

getdesc():Text
getprix():Float
Lignevente(art :article)

Paiement
Total : float
Paiement(total:float)

Descriptionarticle
Description : text
Prix : rel
Code : codebarre

Afficheur

Imprimante

afficher(stt:float)

imprimer(line:text)

Licence GI 2012

2)

FST SETTAT

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

traite

1..0
venteencours

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 :

:Caisse

Ajouter(art)
: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
pointill
s

Licence GI 2012

FST SETTAT

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

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 = Magasin.getInstance();
Voici maintenant le diagramme de classe de conception de notre exercice:

Afficheur

Imprimante

affichet(stt:float)

imprimer(line:text)

Licence GI 2012

FST SETTAT

1
possde

possde

0..1
1

ralise

Caisse

Venteencours 1

Se fait sur

Payervente(s:float)
enregistrerarticle(code : Codebarre)
dnombrer(quantit : entier)
finirvente()
afficher(total:float)
imprimer(line:text)

Historique *

Vente
Date : date
Termin : boolen
Total : float
payersomme(s:float)
Vente(date:Date,c:Caisse)
ajouter(art:article)
dnombrerquantit(q:entier)
finirvente()

effectue

enregistre

0..1
Paiement
Total : float

contient

Paiement(total:float)
Magasin
Nom : text
Adresse : Adresse
$boutic:Magasin
historiser(v:vente)
chercherarticle(code:Codebarre): article
$getInstance():Magasin

1..*
Lignevente

1
Quantit : entier
Sstotal : float

rfrence
rfrence
* catalogue
article
Description : text
Prix : rel
Code : codebarre

getdesc():Text
getprix():Float
Lignevente(art :article)

Licence GI 2012

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 )

FST SETTAT

Licence GI 2012

treizime 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=Cat.chercherarticle(code) ;
if (v==null)
{
v=new Vente() ;
}
v.ajouter(art) ;
}
public void finvente()
{
v.finvente() ;
}
.
}

class Catalogue
{
private Hashtable articles=new Hashtable() ; ;
public Article chercherarticle(int code)
{
return articles.get (code) ;
}
.
}
class Vente
{
private boolean ventetermine = false ;
private Vector lignes = new Vector() ;
public void ajouter(Article art)
{
lignes.addElement(new Ldv(art)) ;
}
public void finvente()
{
ventetermine= true ;
}

FST SETTAT

Licence GI 2012

public float total()


{
float total=0 ;
Enumeration e=lignes.elements() ;
while (e.hasmoreElements())
{
total+=((Ldv)e.nextElement()).soustotal();
}
return total;
}
.
}

class Ldv
{
private int qte ;
private Article art ;
.
public Ldv(Article a)
{
this.art=a ;
}
public void soustotal()
{
return qte*art.getprix() ;
}
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)
{
this.code=code ;
this.prix=prix;
this.desc=desc;
}
public int getcode()
{
return code;

FST SETTAT

Licence GI 2012

}
public int getprix()
{
return prix;
}
public int getdesc()
{
return desc;
}
.
}

FST SETTAT