You are on page 1of 11

Conception de Logiciel

avec les Design Patterns


et UML (Unified Modeling Language)
Pr. Jean-Marc Jzquel
IRISA - Univ. Rennes I

Campus de Beaulieu
F-35042 Rennes Cedex
Tel : +33 299 847 192 Fax : +33 299 842 532
e-mail : jezequel@irisa.fr
http://www.irisa.fr/prive/jezequel
1

Processus de dveloppement avec UML

 Approche itrative, incrmentale, dirige par les cas


dutilisation

?
Expression des besoins
Analyse
Elaboration d un modle idal
Conception
passage du modle idal au monde rel
Ralisation et Validation

1
Gnrateur de code built-in
class Compte {
private int solde;
private int plancher;
Compte public int getSolde(){
solde: Somme return solde;
plancher: Somme }
crditer (Somme)
dbiter (Somme)
public void crediter(int montant) {
}
Seulement un point de dpart,
car dans la vrai vie le code public void crediter(int montant) {
quon veut est plus complexe }
=> intgration de
proccupation non- }
fonctionnelles 3

La conception dans le processus de


dveloppement avec UML

2
Le rle du Designer
 Le designer est celui qui doit simplifier, donner une
personnalit forte et invisible ce qu il cre,
laguer, purer, dsencombrer, crer les produits
adapts (selon Jasper Morrison)

 There are two ways of constructing a software


design (C. A. R. Hoare):
One way is to make it so simple that there are obviously
no deficiencies
and the other way is to make it so complicated that there
are no obvious deficiencies.
The first way is far more difficult to achieve
5

Processus de dveloppement avec UML


 Inspir de OMT, Catalysis, Rapshody

 Conception Systmique (Architecture)


choix stratgiques de ralisation du systme
beaucoup dingnirie, peu dinformatique
patrons darchitecture

 Conception Objet (dtaille)


prparation de la projection vers langage programmation
aspects dynamiques, fonctionnels, relations...
patrons de conception dtaille (GoF)

3
Conception Systmique (Architecture)
 Organisation en sous-systmes
 Choix de limplantation du mode de contrle du
logiciel
 Conception de la concurrence
 Allocation des sous-systmes aux tches et
processeurs
 Choix des modes de stockages des donnes
 Gestion de laccs aux ressources globales
 Prvisions des conditions aux limites
 Choix des priorits pour les contraintes non-
fonctionnelles
7

Organisation et accs aux donnes


 Base de donnes : avantages
Prvues pour grer de grandes quantits de donnes
crash recovery, partage, distribution, intgrit
interface standardise (SQL)
 Base de donnes : inconvnients
surcot en performances
difficiles manipuler si traitements complexes
interface mdiocre avec les langages de programmation
 Modle d architecture 3 tiers

GUI CoreBusiness DBMS

4
Gnration du shma de base de
donnes
 Si BD relationelle
Class => Table
Associations, attributs => colonnes
Gestion des cls pour les associations
Gestion de lhritage
 Si BD moderne e.g. BigTable, NoSql
Idem tables de hachage contenant tous les objets
 Pour certaines applications, tout en mmoire avec
srialization la demande + journaling
Pas de BD!

Conception Objet (dtaille)


 Projection des aspects dynamiques
Exemples dimplantation de StateCharts
Cas le plus simple, Rification dvnements, Rification dtat,
Rification dtat et dvnement
 Conception des algorithmes
 Optimisations
 Ajustement de lhritage
 Conception des relations
cas simples
Rification dune relation
 Principes de conception objet
 Rvision de la hirarchie de classes 10

5
Projection des aspects dynamiques
 Prsence dune mthode par opration possible
dans chaque classe
diagramme de squences => mthodes et constructeurs
statecharts => m = f (state, event)
 Solution simple : pour chaque vnement e (signal,
condition, expiration de dlai) du diagramme dtat
Crer une mthode process_e (paramtres optionnels)
avec un traitement par cas selon ltat de lobjet
 Utilisation possible des design patterns
COMMAND : rification des vnements
STATE : rification des tats
ou les deux => double dispatch
11

Exemples dimplantation de
StateChart
book person
* borrow 0..1

borrowLink (book, person)


borrowUnlink(book,person) * reservation *

Reserve(p) Reserve(p)

Unavailable
Ordered [not reservations-> Borrow(p)
Borrowed
isEmpty] Deliver
[reservations->
size>1] delay
[reservations->isEmpty] Deliver [not reservations->
[reservations-> isEmpty] Return
size=1] delay Reserved [reservations->
Available
isEmpty] Return
Borrow(p)
12

6
if Ordered() or Unavailable() then
Cas le plus simple addReservation(this,p)
end
if Reserved() then
Coder ltat sur un type numr
if reservations.size = 1 then
boolen, entier state := available
Introduire mthode daccs end -- else stay in Reserved()
ltat (idem OCL) removeReservation(reservations.first)
Pour chaque vnement e : end -- else ignore
Crer une mthode : book
process_e (paramtres) # state : Integer
+Ordered() : Boolean
avec traitement par cas +Available() : Boolean
selon ltat de lobjet +Unavailable() : Boolean
+Reserved() : Boolean
Reserve(p)
Reserve(p) +Borrowed() : Boolean
Ordered Unavailable
Borrowed
+ProcessDeliver()
[not reservations->
isEmpty] Deliver
Borrow(p)

[reservations->
+ProcessBorrow(p:person)
size>1] delay
[reservations->isEmpty] Deliver
[not reservations->
isEmpty] Return
+ProcessReturn()
Available
[reservations->
size=1] delay Reserved
+ProcessReserve(p:person)
[reservations->
isEmpty] Return +ProcessTimeout()
Borrow(p)
13

Gestion des dlais sur les transitions


 Pattern SoftTimer
TimerManager SoftTimer Ringable
ringTime : Date
register (SoftTimer) isRinging : Boolean
remove (SoftTimer) 1 manage * make(Ringable) ProcessRing()
isTimerRinging() * 1
{ordered} set (Date)
processRing() reset()
ring()

Sur chaque transition entrante


myTimer.set(AwakingDate)
Book
Sur chaque transition sortante
Process_Ring()
myTimer.reset()
TimerManager : regarde priodiquement t.isRinging en
tte de sa file, et si oui appelle t.ring()
14

7
Rification dvnements
 Pattern command
une classe par vnement, possibilit dhritage
BookEvent
Execute(Book)
book
# state : Integer
+Ordered() : Boolean
Deliver Borrow +Available() : Boolean
+Unavailable() : Boolean
Execute(book) Execute(book)
+Reserved() : Boolean
+Borrowed() : Boolean
+ProcessEvent(ev : BookEvent)
{ ev.execute(this) }

15

Rification dtat
 Pattern state
une sous-classe par sous-tat
hirarchie dtats correspond la hirarchie de classes
priorit aux transitions les plus internes book
BookState +ProcessDeliver()
Deliver(Book) 1 State +ProcessBorrow(p:person)
Borrow(Book,p)... +ProcessReturn()
+ProcessReserve(p:person)
+ProcessTimeout()
Ordered Unavailable Available
Deliver(book)... Deliver(book)... Deliver(book)...

State.Deliver(this)
Borrowed Reserved
16
Deliver(book)... Deliver(book)...

8
Rification dtat et dvnement
 Patterns State et Command simultanment
ev.execute(this)
b.state.deliver(b)

BookState book
Deliver(Book) 1 State +ProcessEvent(BookEvent)
Borrow(Book,p)...

BookEvent
Ordered Unavailable Available
Execute(b:book)
Deliver(book)... Deliver(book)... Deliver(book)...

Deliver Borrow
Borrowed Reserved
Execute(b:book) Execute(b:book)
Deliver(book)... Deliver(book)...
17

Conception des associations


 Analyse des sens de traverse des relations

 A sens unique, selon la multiplicit :


vers 1 => attribut (rfrence)
vers n => Liste ou Map
 Bi-directionnels, selon la frquence :
un sens peu frquent => attribut (rfrence) + recherche
dans lautre sens
si mise jour peu frquentes => attributs dans les 2 sens,
mais structure complexe mettre jour
sinon, laide dun objet matrialisant cette relation
Exemple : relation tre-membre dun groupe de multicast
21

9
Reification dune association
Personne Reunion
* participe *

Personne Reunion

1 1
Participation
a * * contient

22

Principes de conception Object


 Single Responsibility Principle (SRP)
Une classe par concept, et un concept par classe
 Open/Closed Principle (OCP)
Ouvert aux extensions par hritage, mais stable vs client
 Liskov Substitution Principle (LSP)
a.k.a. Design by Contract : une sous-classe doit honorer
les contrats de ses super-classes
 Dependency Inversion Principle (DIP)
Le concret doit dpendre de labstrait (interfaces)
 Interface Segregation Principle (ISP)
Un programme ne doit pas dpendre de mthodes qu'il
n'utilise pas
23

10
Rvision de la hirarchie de classes
 Essayer de simplifier le modle
Einstein as simple as possible, but no simpler
St Exupry un bon design nest pas un design auquel
on ne peut rien ajouter, mais un design auquel on ne peut
rien enlever
 Revoir la dcoupe en paquetages
Classes groupes afin que les paquetages soient le plus
faiblement coupls possible (cibles des tests unitaires)
 Documenter toutes les dcisions de conception

24

11