Patron de conception GRASP

Patron de conception GRASP

Patron de conception GRASPRapport de gnie logiciel II

Propos par M .

Table des matiresI.Introduction:3II.Dfinition :3III.Les patrons de conception GRASP:4III.1Expert en information:4i.Exemple Bibliothque :4ii.Avantage:5III.2Crateur:5i.Exemple :6ii.Discussion:6III.3Faible couplage:7i.Couplage7ii.Problmes du couplage fort :7iii.Mise en uvre :8iv.Exemples :8v.Discussion :8III.4Forte cohsion:9i.Problmes des classes faible cohsion:9ii.Discussion :10III.5Contrleur:10ii.Mise en uvre :10iii.Contrleur et 'Faade' :11iv.Contrleur de cas dutilisation:11v.Contrleur trop charge (pas bon):12vi.Avantages:12III.6Polymorphisme:12i.Principe:13ii.Mise en uvre :13iv.Avantages du polymorphisme :14III.7Fabrication pure :14v.Mise en uvre15vi.Exemple :15vii.Discussion :16viii.Avantage:16III.8Indirection:16i.Mise en uvre:16ii.Exemple:17iii.Discussion:17III.9Protection des variations:18i.Avantage:18ii.Ne pas parler aux inconnus:18iii.Exemple:19IV.Conclusion:19

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:

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

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 ? 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 dpendExemples 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 responsabilitsComparer 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.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 comprhensibles ? 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 : idalementun contrleur est un objet qui ne fait rien reoit les vnements systme dlgue aux objets dont la responsabilit est de les traiteril se limite aux tches de contrle et de coordination Vrification de la squence des vnements systme Appel des mthodes ad hoc des autres objetsRgle dorLes 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...)

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:

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 ?

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

ConstatLenregistrement dobjets dans une BD est une tche gnrique utilisable par de nombreux objets (pas de rutilisation, beaucoup de duplication)Solution avec Fabrication pureCrer une classe artificielle Gestion ArchivageAvantagesGains pour Prt Forte cohsion et Faible couplageConception 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 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 cohsivesviii. Avantage: Supporte Faible couplage et Forte cohsion. Amliore la rutilisabilit. Patterns lies : Faible couplage, Forte cohsion, Adaptateur, Observateur, Visiteur .III.8 Indirection:ProblmeO 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) ?SolutionCrer 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 packagesi. 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

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 variationsGoF : 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). 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 prvisiblesAffecter 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 doprationsIntermdiaires.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.

2