Vous êtes sur la page 1sur 19

Patron de

conception
GRASP
Rapport de gnie logiciel II

Propos par M .

Patron de conception GRASP



1

Table des matires
I. Introduction : ...................................................................................................................................................... 3
II. Dfinition : ............................................................................................................................................................ 3
III. Les patrons de conception GRASP : ................................................................................................................. 3
III.1 Expert en information : ................................................................................................................................. 3
i. Exemple Bibliothque : .............................................................................................................................. 4
ii. Avantage : ..................................................................................................................................................... 5
III.2 Crateur : ...................................................................................................................................................... 5
i. Exemple : ...................................................................................................................................................... 6
ii. Discussion : .................................................................................................................................................. 6
III.3 Faible couplage : ......................................................................................................................................... 6
i. Couplage ...................................................................................................................................................... 7
ii. Problmes du couplage fort : ..................................................................................................................... 7
iii. Mise en uvre : ....................................................................................................................................... 7
iv. Exemples : ................................................................................................................................................... 7
v. Discussion : .................................................................................................................................................. 8
III.4 Forte cohsion : ............................................................................................................................................ 8
i. Problmes des classes faible cohsion : .................................................................................................. 9
ii. Discussion : .................................................................................................................................................. 9
III.5 Contrleur : ................................................................................................................................................... 9
ii. Mise en uvre : ......................................................................................................................................... 10
iii. Contrleur et 'Faade' : ....................................................................................................................... 10
iv. Contrleur de cas dutilisation : .............................................................................................................. 11
v. Contrleur trop charge (pas bon) : ......................................................................................................... 11
vi. Avantages : ................................................................................................................................................ 11
III.6 Polymorphisme : ....................................................................................................................................... 11
i. Principe : ................................................................................................................................................... 12
ii. Mise en uvre : ......................................................................................................................................... 12
iv. Avantages du polymorphisme : ............................................................................................................... 13
III.7 Fabrication pure : ..................................................................................................................................... 13
v. Mise en uvre ........................................................................................................................................... 14
vi. Exemple : ................................................................................................................................................... 14
Patron de conception GRASP



2
vii. Discussion : ............................................................................................................................................ 14
viii. Avantage : ............................................................................................................................................. 15
III.8 Indirection : ............................................................................................................................................... 15
i. Mise en uvre : ......................................................................................................................................... 15
ii. Exemple : ................................................................................................................................................... 15
iii. Discussion : ............................................................................................................................................ 16
III.9 Protection des variations :........................................................................................................................... 16
i. Avantage : ................................................................................................................................................. 17
ii. Ne pas parler aux inconnus : ................................................................................................................... 17
iii. Exemple : ............................................................................................................................................... 18
IV. Conclusion : .................................................................................................................................................... 18

















Patron de conception GRASP



3
I. Introduction :
Concept de gnie logiciel visant rsoudre des problmes rcurrents darchitecture et de conception
logiciel.
Ce n'est pas un algorithme, mais une structure gnrique qui permet de rsoudre le problme
rfrenc. Il est indpendant du langage de programmation, il est standardis, suffisamment pour
que tous puissent s'y rfrer. C'est l'exprience qui montre que la solution est valide. On parle parfois
de Best Practices...
S'y rfrer permet de gagner du temps...
Il y a deux familles de DP, les GRASP (DP de base) et les GoF (du Gang Of Four). A l'inverse, des
anti Patterns montrent ce qu'il ne faut pas faire.
II. Dfinition :

Les patterns GRASP sont des patrons crs par Craig Larman qui dcrivent des rgles affecter les
responsabilits aux classes d'un programme orient objet pendant la conception, en liaison avec la
mthode de conception BCE (Boundary Control Entity), en franais MVC (Modle Vue Contrleur).
GRASP est l'acronyme de General Responsability Assignment Software Patterns (schmas
gnraux d'affectation des responsabilits). To GRASP signifie saisir.
L'objectif poursuivi par les Design Pattern GRASP de Craig Larman est de programmer objet de
faon claire, mthodique, rationnelle et explicable.
Les responsabilits
Faire : faire quelque chose (un calcul, un autre objet), dclencher une action sur un autre objet,
contrler et commander les activits d'un autre objet.
Savoir : savoir les valeurs de ses propres attributs, connaitre les objets qui lui sont rattachs, savoir
comment obtenir des rsultats de ces objets.
III. Les patrons de conception GRASP :

Les patrons de conception GRASP sont les suivants :
III.1 Expert en information :

Patron de conception GRASP



4
Le principe de lexpert en information est d'assigner la responsabilit d'une requte la classe qui
dtient les informations ncessaires. Il s'agit de crer la mthode l o les donnes se trouvent. Il
s'agit d'appliquer le principe Celui qui sait le fait ou de mettre les services avec les attributs.
Problme : Quel est le principe gnral daffectation des responsabilits aux objets ?
Solution :
Affecter la responsabilit lexpert en information.
la classe qui possde les informations ncessaires pour sacquitter de la responsabilit.

i. Exemple Bibliothque :

Qui doit avoir la responsabilit de connaitre lidentifiant de labonn ? De connaitre le titre dun livre
? De connaitre la disponibilit dun exemplaire ?

Qui doit avoir la responsabilit de connaitre le nombre dexemplaires disponibles ?

Commencer avec la question : De quelle information a-t-on besoin pour dterminer le nombre
dexemplaires disponibles ? Disponibilit de toutes les instances dexemplaires.
Puis : Qui en est responsable ? Livre et lExpert pour cette information.

Tche complexe :
Patron de conception GRASP



5
Que faire quand laccomplissement dune responsabilit ncessite de linformation rpartie entre
diffrents objets ?
Solution :
dcomposer la tche
Dterminer des experts partiels
Leur attribuer les responsabilits correspondant aux sous-tches
Faire jouer la collaboration pour raliser la tche globale

ii. Avantage :

Conforme aux principes de base en OO : encapsulation et collaboration.
Dfinitions de classes lgres, faciles
comprendre, maintenir, rutiliser.
Comportement distribu entre les classes qui ont
linformation ncessaire.
Systmes robustes et maintenables.

III.2 Crateur :

Une classe Contrleur doit tre cr si elle rpond lun des cas
suivants :
La classe reprsente un contrleur de faade, cest dire linterface daccs lensemble dun systme (pas
graphique, mais de gestion).
La classe reprsente le scnario issu dun cas dutilisation. On le nomme en gnral Session , gestionnaire ou
coordonnateur . Elle est charge de traiter tous les vnements systmes contenus dans un scnario de cas
dutilisation.
Problme : Qui doit avoir la responsabilit de crer une nouvelle instance dune classe
donne ?

Solution : Affecter la classe B la responsabilit de crer une instance de la classe A si une -
ou plusieurs - de ces conditions est vraie :
B contient ou agrge des objets A.
B enregistre des objets A.
B utilise troitement des objets A.
B a les donnes dinitialisation qui seront transmises aux objets A lors de leur cration.
B est un Expert en ce qui concerne la cration de A.


Patron de conception GRASP



6


i. Exemple :
Bibliothque : qui doit tre responsable de la cration de Prt ?
Base Prt contient des Prt : elle doit les crer.




ii. Discussion :
Guide pour attribuer une responsabilit pour la cration dobjets (une tache trs commune en
OO).
Finalit : trouver un crateur pour qui il est ncessaire dtre connecte aux objets cres :
Favorise le Faible couplage (Moins de dpendances de maintenance, plus dopportunits de
rutilisation)
Pattern lies :
Faible couplage
Composite
Fabricant


III.3 Faible couplage :

Principe gnral : Les classes, trs gnriques et trs rutilisables par nature, doivent avoir un faible
couplage.
Problme :
Comment minimiser les dpendances ?
Comment rduire limpact des changements ?
Patron de conception GRASP



7
Comment amliorer la rutilisabilit ?

Solution :
Affecter les responsabilits des classes de sorte que le couplage reste faible.
Appliquer ce principe lors de lvaluation des solutions possibles.

i. Couplage

Mesure du degr auquel un lment est lie un autre, en a connaissance ou en dpend
Exemples classiques de couplage de TypeX vers TypeY dans un langage OO
TypeX a un attribut qui rfre TypeY.
TypeX a une mthode qui rfrence TypeY.
TypeX est une sous-classe directe ou indirecte de TypeY.
TypeY est une interface et TypeX limplmente.
ii. Problmes du couplage fort :

Un changement dans une classe force changer toutes ou la plupart des classes
lies
Les classes prises isolement sont difficiles comprendre
Rutilisation difficile : lemploi dune classe ncessite celui des classes dont
elle dpend.
Bnfices du couplage faible Exactement linverse.



iii. Mise en uvre :
Dterminer plusieurs possibilits pour laffectation des responsabilits
Comparer leurs niveaux de couplage en termes de :
Nombre de relations entre les classes
Nombre de paramtres circulant dans lappel des mthodes
Frquence des messages



iv. Exemples :
Pour lapplication de bibliothque, il faut mettre lISBN dun Exemplaire dans le Prt.
Patron de conception GRASP



8
Quelle classe en sera responsable ?

v. Discussion :
Un principe a gard en tte pour toutes les dcisions de conception.
Ne doit pas tre considre indpendamment dautres patterns comme Expert et Forte
cohsion(en gnral, Expert soutient Faible couplage).
Pas de mesure absolue de quand un couplage est trop fort.
Un fort couplage nest pas dramatique avec des lments trs stables exemple : java.util.
Cas extrme de faible couplage
Des objets incohrents, complexes, qui font tout le travail.
Des objets isolent, non couples, qui servent stocker les donnes.
Peu ou pas de communication entre objets.
III.4 Forte cohsion :

La forte cohsion favorise :
la comprhension de la classe,
la maintenance de la classe,
la rutilisation des classes ou modules.

Problme : maintenir une complexit grable
Comment sassurer que les objets restent
Patron de conception GRASP



9
o comprhensibles ?
o faciles grer ?
Comment sassurer au passage que les objets contribuent au faible couplage ?
Solution :
Attribuer les responsabilits de telle sorte que la cohsion reste forte.
Appliquer ce principe pour valuer les solutions possibles.


i. Problmes des classes faible cohsion :
Elles effectuent :
Trop de taches
des taches sans lien entre elles
Elles sont :
Difficiles comprendre.
Difficiles rutiliser.
Difficiles maintenir.
Fragiles, constamment affectes par le changement.

ii. Discussion :
Forte cohsion va en gnral de pair avec Faible couplage.
Est un pattern dvaluation garder en tte pendant toute la conception ; Permet lvaluation
lment par lment (contrairement Faible couplage).

III.5 Contrleur :

Problme :
Quel est le premier objet au-del de lIHM qui reoit et coordonne (contrle) une opration
systme (vnement majeur entrant dans le systme) ?
Solution :
Affecter cette responsabilit une classe qui reprsente
Soit le systme global, un sous-systme majeur ou un quipement sur lequel le logiciel
sexcute
->contrleur Faade ou variantes.
Soit un scnario de cas dutilisation dans lequel lvnement systme se produit -
>contrleur de CU ou contrleur de session.
i. Principes bien comprendre : idalement
Patron de conception GRASP



10
un contrleur est un objet qui ne fait rien
reoit les vnements systme
dlgue aux objets dont la responsabilit est de les traiter
il se limite aux tches de contrle et de coordination
Vrification de la squence des vnements systme
Appel des mthodes ad hoc des autres objets
Rgle dor
Les oprations systme des CU sont les messages initiaux qui parviennent au contrleur dans
les diagrammes dinteraction de la couche domaine.
ii. Mise en uvre :
Au cours de la dtermination du comportement du systme (besoins, CU, DSS), les
oprations systme sont dtermines et attribues une classe gnrale Systme.
lanalyse/conception, des classes contrleur sont mises en place pour prendre en charge
ces oprations.

iii. Contrleur et 'Faade' :

Parfois, si il y a beaucoup de cas d'utilisation, ou beaucoup d'actions coordonner, pour viter
de perdre le Pattern 'cohsion forte', on peut utiliser une classe Faade, qui utilisera des
Contrleurs qui greront ensuite des cas spcialiss.
Ainsi, sur une grosse application, si l'ensemble des actions possibles devenait trop important,
on pourrait imaginer une faade gnrale qui utiliserait les contrleurs 'GestionClients',
'GestionCommandes 'GestionProduits'.

Le Contrleur (ici, la version Faade, qui appelle d'autres sous contrleurs...)

Patron de conception GRASP



11
iv. Contrleur de cas dutilisation :

Un contrleur diffre pour chaque cas dutilisation
Commun tous les vnements dun cas dutilisation.
Permet de connaitre et danalyser la squence dvnements systme et ltat de chaque
scenario.
A utiliser quand
Les autres choix amnent un fort couplage ou une cohsion faible (contrleur trop
charge - bloated)
Il y a de nombreux vnements systme qui appartient plusieurs processus (Permet de
repartir la gestion entre des classes distinctes et faciles grer).

v. Contrleur trop charge (pas bon) :

Pas de focus, prend en charge de nombreux domaines de responsabilit :
Un seul contrleur reoit tous les vnements systme.
Le contrleur effectue la majorit des taches ncessaires pour rpondre aux vnements
systme. Un contrleur doit dlguer dautres objets les taches effectuer.
a beaucoup dattributs et gre des informations importantes du systme ou du domaine :
Ces informations doivent tre distribues dans les autres objets.
Ou doivent tre des duplications dinformations trouves dans dautres objets.

Solution :
Ajouter des contrleurs.
Concevoir des contrleurs dont la priorit est de dlguer.
vi. Avantages :
Meilleur potentiel de rutilisation
-Permet de raliser des composants dinterface enfichables
porte dentre des objets de la couche domaine
la rend indpendante des types dinterface (Web, client riche, simulateur de
test)
-Niveau dindirection matrialisant la sparation Modle-vue.
-Brique de base pour une conception modulaire.
Meilleure architecturation des CU.

Patterns lis : Indirection, Couches, Faade, Fabrication pure, Commande.
III.6 Polymorphisme :

Patron de conception GRASP



12
Le polymorphisme est une proprit de la programmation objet o une classe peut dfinir
un comportement par dfaut (une mthode de classe), voire ne dfinir que la signature de la
mthode (classe abstraite).
Ce comportement pouvant tre redfini par des sous-classes afin de le modifier pour
certains types d'objets.
Sans le polymorphisme, il serait ncessaire d'utiliser plusieurs tests (instructions if ou
switch en gnral) dans la mthode afin de dfinir diffrents comportement en fonction du
type d'objet. L'ajout d'un nouveau type oblige la modification de la mthode pour ajouter un
test et un nouveau comportement.

Problme :
Comment grer des alternatives dpendantes des types ?
Comment crer des composants logiciels. Enfichables. ?
Solution :
Affecter les responsabilits aux types (classes) pour lesquels le comportement varie
Utiliser des oprations polymorphes.
Polymorphisme
Donner le mme nom a des services dans diffrents objets.
Lier le client un super type commun.
i. Principe :
Tirer avantage de lapproche OO en sous-classant les oprations dans des types drives de lExpert en
information (Lopration ncessite la fois des informations et un comportement particuliers).
ii. Mise en uvre :
Utiliser des classes abstraites
Pour dfinir les autres comportements communs.
Sil ny a pas de contre-indication (hritage multiple).
Utiliser des interfaces
Pour spcifier les oprations polymorphes.
Utiliser les deux (CA implmentant des interfaces)
Fournit un point dvolution pour dventuels cas particuliers futurs.
iii. Exemple :

Bibliothque : qui doit tre responsable de savoir si un exemplaire est disponible ?

Patron de conception GRASP



13



Autre solution (mauvaise) :
Utiliser une logique conditionnelle (test sur le type dun objet) au niveau
du client
Ncessite de connatre toutes les variations de type
Augmente le couplage
iv. Avantages du polymorphisme :
volutivit.
Points dextension requis par les nouvelles variantes faciles ajouter (nouvelle sous-
classe).
Stabilit du client.
Introduire de nouvelles implmentations naffecte pas les clients.

Patterns lis : Protection des variations, Faible couplage
III.7 Fabrication pure :

Problme :
Que faire
Pour respecter le Faible couplage et la Forte cohsion ?
Quand aucun concept du monde rel (objet du domaine) noffre de solution
satisfaisante ?
Solution :
Affecter un ensemble fortement cohsif a une classe artificielle ou de comme dite, qui ne
reprsente pas un concept du domaine (Entit fabrique de toutes pices).


Exemple typique : quand utiliser lExpert en information
Lui attribuerait trop de responsabilits (contrarie Forte cohsion)
Le lierait a beaucoup dautres objets (contrarie Faible couplage)
Patron de conception GRASP



14
v. Mise en uvre
Dterminer les fonctionnalits annexes de lExpert en information
Les regrouper dans des objets
aux responsabilits limites (fortement cohsifs)
aussi gnriques que possible (rutilisables)
Nommer ces objets
Pour permettre didentifier leurs responsabilits fonctionnelles
En utilisant si possible la terminologie du domaine.
vi. Exemple :
Problme : les instances de Prt doivent tre enregistres dans une BD
Solution initiale (daprs Expert) :
Prt cette responsabilit
Cela ncessite
Un grand nombre doprations de BD
->Prt devient donc non cohsif.
De lier Prt une BD ->le couplage augmente
pour Prt.



Constat
Lenregistrement dobjets dans une BD est une tche gnrique
utilisable par de nombreux objets (pas de rutilisation, beaucoup
de duplication)
Solution avec Fabrication pure
Crer une classe artificielle Gestion Archivage
Avantages
Gains pour Prt
Forte cohsion et Faible couplage
Conception de Gestion Archivage propre
relativement cohsif, gnrique et rutilisable


vii. Discussion :

Choix des objets pour la conception
Dcomposition reprsentationnelle (objets du domaine)
Conforme au principe de base de lOO : rduire le dcalage des reprsentations
entre le rel et le modle
Patron de conception GRASP



15
Dcomposition comportementale (Fabrication pure)
Sorte dobjet centr-fonction qui rend des services transverses dans un projet
(POA)
Rgle dor : Concevoir des objets Fabrication pure en pensant leur rutilisabilit, Est
assurer quils ont des responsabilits limites et cohsives
viii. Avantage :
Supporte Faible couplage et Forte cohsion.
Amliore la rutilisabilit.

Patterns lies : Faible couplage, Forte cohsion, Adaptateur, Observateur, Visiteur .
III.8 Indirection :
Problme
O affecter une responsabilit pour viter le couplage entre deux entits (ou plus)
de faon diminuer le couplage (objets dans deux couches diffrentes)
de faon favoriser la rutilisabilit (utilisation dune API externe) ?
Solution
Crer un objet qui sert dintermdiaire entre dautres composants ou services
lintermdiaire cre une indirection entre les composants.
lintermdiaire vite de les coupler directement.
Utilit
Raliser des adaptateurs, faades, etc. (pattern Protection des variations) qui sinterfacent
avec des systmes extrieurs Exemples : proxys, DAO, ORB
Raliser des inversions de dpendances entre packages
i. Mise en uvre :

Utilisation dobjets du domaine
Cration dobjets
Classes : cf. Fabrication pure.
Interfaces : cf. Fabrication pure + Polymorphies.
ii. Exemple :
Bibliothque : accs un systme de stockage propritaire


Patron de conception GRASP



16















iii. Discussion :

Remarques
Beaucoup de Fabrications pures sont cres pour des raisons dindirection
Objectif principal de lindirection : faible couplage.
Adage (et contre adage)
En informatique, on peut rsoudre la plupart des problmes en ajoutant un niveau
dindirection. (David Wheeler)
En informatique, on peut rsoudre la plupart des problmes de performance en
supprimant un niveau dindirection.
Patterns lies :
GRASP : Fabrication pure, Faible couplage, Protection des variations
GoF : Adaptateur, Facade, Observateur

III.9 Protection des variations :
Le but du patron de conception Protection est d'assigner les responsabilits afin que des
variations dans des classes (instabilit) ne produisent aucun effet indsirable sur le reste du
systme. Ce patron de conception est utilis en prvision d'volutions de l'application
logicielle, afin d'viter que de nouvelles fonctionnalits ne viennent perturber l'existant.
Pour mettre en uvre la protection contre les variations, on peut :
Crer des mthodes pour accder aux attributs d'une classe,
Crer une interface pour grer de nouvelles classes en dfinissant les mthodes qui
pourront tre appeles,
Crer des classes intermdiaires (voir le patron de conception indirection).
Patron de conception GRASP



17
Il faut veiller ne pas trop anticiper les changements possibles afin d'viter de complexifier
la structure de l'application en crant trop de classes intermdiaires ou d'interfaces.
Problme :
Comment concevoir des objets, sous-systmes, systmes pour que les variations ou
linstabilit de certains lments naient pas dimpact indsirable sur dautres lments ?
Solution :
Identifier les points de variation ou dinstabilit prvisibles
Affecter les responsabilits pour crer une interface (au sens large) stable autour deux
(indirection).
i. Avantage :
Masquage de linformation.
Diminution du couplage.
Diminution de limpact ou du cot du changement.
ii. Ne pas parler aux inconnus :

Cas particulier de Protection des variations
-Protection contre les variations lies aux volutions de structure des objets
Problme
Si un client utilise un service ou obtient de linformation dun objet indirect (inconnu)
via un objet direct (familier du client), comment le faire sans couplage ?
Cas general a eviter : a.getB().getC().getD().methodeDeD();
Solution :
Eviter de connaitre la structure dautres objets indirectement
Affecter la responsabilit de collaborer avec un objet indirect a un objet que le client
connait directement pour que le client nait pas besoin de connaitre ce dernier.
Objectif : viter le couplage entre le client et la connaissance dobjets indirects et les
connexions entre objets
objets direct : familiers du client.
objets indirects : inconnus.
Contrainte induite : depuis une mthode, nenvoyer des messages quaux objets
suivants
lobjet this (self)
un paramtre de la mthode courante
un attribut de this
un lment dune collection qui est un attribut de this
un objet cr lintrieur de la mthode
Implication : ajout doprations dans les objets directs pour servir doprations
Intermdiaires.
Patron de conception GRASP



18
iii. Exemple :
Comment implmenter disponible() dans GestionPret ?


IV. Conclusion :
Dune certaine manire, tous les autres patterns sont des applications, des spcialisations, des
utilisations conjointes des 9 patterns GRASP, qui sont les plus gnraux.