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