[PDF] GRASP : conception objet et responsabilités Première approche des

View - Download GRASP : conception objet et responsabilités Première approche des

Previous PDF

Next PDF

GRASP : conception objet et

responsabilitŽs extrait de UML2 et les Design Patterns, Craig Larman design patterns 1

Mireille Blay-Fornarino, UniversitŽ Nice Sophia Antipolis, DŽpartement Info IUT, Septembre 2014

mercredi 10 septembre 14

Bibliographie

Craig Larman, UML2 et les Design Patterns

Glenn D. Blank CSE432, Lehigh University

Sylvain Cherrier, Design Patterns

Laurent Henocque, Design Patterns

2 mercredi 10 septembre 14

Design patterns ?

En gŽnie Logiciel, un patron de conception (design pattern en anglais) est paradigme objet. Les patrons de conception dŽcrivent des solutions des logiciels (source WikipŽdia) ÒA pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.Ó

Christopher Alexander, professor of architecture

3 mercredi 10 septembre 14

Conception dirigŽe par les

responsabilitŽs

MŽtaphore

communautŽ dÕobjets responsables qui collaborent (cf. humains) :

Anthropomorphism.

penser lÕorganisation des composants (logiciels ou autres) en termes de responsabilitŽs par rapport ˆ des r™les, au sein de collaborations.

ResponsabilitŽ

abstraction de comportement (contrat, obligation par rapport ˆ un r™le) une responsabilitŽ nÕest pas une mŽthode; les mŽthodes sÕacquittent des responsabilitŽs.

Anthropomorphism: Object-oriented

programming works like human organizations.

Each object will communicate with another one

by sending messages. So the software objects work by just sending those messages.

Ron McFadyen, 2004

4 mercredi 10 septembre 14

Conception dirigŽe par les

responsabilitŽs Les responsabilitŽs de Faire dÕun objet peuvent tre : faire quelque chose (un calcul, crŽer un autre objet), dŽclencher une action sur un autre objet, contr™ler et coordonner les activitŽs d'un autre objet Les responsabilitŽs de savoir dÕun objet peuvent tre : conna"tre les valeurs de ses propres attributs (donnŽes privŽes encapsulŽes), connaitre les objets qui lui sont rattachŽs, conna"tre les ŽlŽments quÕil peut calculer ou dŽriver. 5 mercredi 10 septembre 14

GRASP : General Responsability

Assignment Software Patterns

Une approche mŽthodique de la COO

Patterns gŽnŽraux dÕaffectation des responsabilitŽs pour aider ˆ la conception orientŽe-objet raisonner objet de faon mŽthodique, rationnelle, explicable

Patterns fondamentaux, simples, basiques...

Utiles pour lÕanalyse et la conception

RŽfŽrence : Larman 2004

6 mercredi 10 septembre 14

GRASP : Un principe gŽnŽral

Toujours chercher ˆ rŽduire le dŽcalage des reprŽsentations entre la faon de penser le domaine (humaine)

Ç un Žchiquier a des cases È

les objets logiciels correspondants un objet Echiquier contient des objets Case vs. un objet Echiquier contient 4 objets 16 Cases vs. un objet TYR43 contient des EE25 7 mercredi 10 septembre 14

Des Patterns GRASP

Information Expert

Creator

Low Coupling

Controller

High Cohesion

Polymorphisme

Fabrication Pure

8 mercredi 10 septembre 14

Expert en Information (GRASP)

Quel est le principe gŽnŽral dÕaffectation des responsabilitŽs aux objets ?

Solution

Affecter la responsabilitŽ ˆ lÕexpert en information i.e. la classe qui responsabilitŽ 9 mercredi 10 septembre 14

Expert (GRASP) : Exemple

Monopoly : qui conna"t un objet Case Žtant donnŽ une clŽ ? Qui est responsable de retrouver une case ˆ partir de son nom ? Sylvain Cherrier, Design Patterns???c= getCase(nom) 10 mercredi 10 septembre 14

Expert (GRASP) : Exemple

Monopoly : qui conna"t un objet Case Žtant donnŽ une clŽ ? Qui est responsable de retrouver une case ˆ partir de son nom ?

Sylvain Cherrier, Design Patterns

11 mercredi 10 septembre 14

Expert (GRASP) : Exemple

dÕexemplaires disponibles ? 12 mercredi 10 septembre 14

Expert (GRASP) : Exemple

Commencer avec la question

De quelle information a-t-on besoin pour dŽterminer le nombre dÕexemplaires disponibles ? DisponibilitŽ de toutes les instances dÕexemplaires Puis

Qui en est responsable ?

Sylvain Cherrier, Design Patterns

13

Livre est lÕExpert pour cette information

mercredi 10 septembre 14

Expert (GRASP) : Exemple

Sylvain Cherrier, Design Patterns

14 Qui est responsable de connaitre le nombre de livres en rayon? mercredi 10 septembre 14

Expert (GRASP) : Exemple

Sylvain Cherrier, Design Patterns

15 mercredi 10 septembre 14

Expert (GRASP) : Discussion

Le plus utilisŽ de tous les patterns dÕattribution de responsabilitŽ

Un principe de base en OO

LÕaccomplissement dÕune responsabilitŽ nŽcessite souvent que lÕinformation nŽcessaire soit rŽpartie entre diffŽrents objets.

Sylvain Cherrier, Design Patterns

16 mercredi 10 septembre 14

Expert (GRASP) : Discussions

Facilite lÕencapsulation et la cohŽsion

les objets utilisent leur propre information pour mener ˆ bien leurs t‰ches Le comportement est distribuŽ ˆ travers diffŽrentes classes qui ont lÕinformation nŽcessaire comprendre et ˆ maintenir

Autres noms

Mettre les responsabilitŽs avec les donnŽes

Qui sait, fait

Faire soi-mme

Sylvain Cherrier, Design Patterns

17 mercredi 10 septembre 14

CrŽateur (GRASP)

Qui doit avoir la responsabilitŽ de crŽer une nouvelle instance dÕune classe donnŽe ?

Solution

18 Affecter ˆ la classe B la responsabilitŽ de crŽer une instance de la classe A si une - ou plusieurs - des conditions est vraie :

B enregistre des objets A

B utilise Žtroitement des objets A

B a les donnŽes dÕinitialisation qui seront transmises aux objets A lors de leur crŽation Ç B est un Expert en ce qui concerne la crŽation de AÈ mercredi 10 septembre 14

CrŽateur (GRASP) : exemple

Monopoly : qui doit tre responsable de la crŽation des cases du jeu?

Intuitivement ?

19 mercredi 10 septembre 14

CrŽateur (GRASP) : exemple

Monopoly : qui doit tre responsable de la crŽation des cases du jeu? On conforte notre intuition par un diagramme de sŽquence. 20 mercredi 10 septembre 14

CrŽateur (GRASP) : exemple

Monopoly : qui doit tre responsable de la crŽation de la case du jeu? 21
mercredi 10 septembre 14

CrŽateur (GRASP) : exemple

Sylvain Cherrier, Design Patterns

BasePret contient des Prts : elle doit les crŽer. 22
mercredi 10 septembre 14

CrŽateur (GRASP) : discussion

Guide pour attribuer une responsabilitŽ pour la crŽation dÕobjet FinalitŽ : trouver un crŽateur pour qui il est nŽcessaire dՐtre connectŽ aux objets crŽŽs favorise le Faible couplage Moins de dŽpendances de maintenance, plus dÕopportunitŽs de rŽutilisation

Pattern liŽs

Faible couplage

Composite

Fabricant

Sylvain Cherrier, Design Patterns

23
mercredi 10 septembre 14

CrŽateur (GRASP) : contre-

indication

Creation may require signiÞcant complexity:

recycling instances for performance reasons conditionally creating instances from a family of similar classes In these instances, other patterns are availableÉ WeÕll learn about Factory and other patterns laterÉ

Glenn D. Blank CSE432, Lehigh University

24
mercredi 10 septembre 14

Faible couplage (GRASP)

Comment minimiser les dŽpendances, rŽduire lÕimpact des changements, et augmenter la rŽutilisation ?

Solution

Affecter une responsabilitŽ de sorte que le couplage reste faible. Appliquer ce principe pour Žvaluer les solution possibles.

Couplage

Mesure du degrŽ auquel un ŽlŽment est liŽ ˆ un autre 25
mercredi 10 septembre 14

Couplage

Exemples classiques de couplages de TypeX vers TypeY dans un langage OO

TypeX a une mŽthode qui rŽfŽrence TypeY

TypeX est une sous-classe directe ou indirecte de TypeY TypeY est une interface et TypeX lÕimplŽmente 26

Sylvain Cherrier, Design Patterns

mercredi 10 septembre 14

Couplage

faible ? 27

Sylvain Cherrier, Design Patterns

mercredi 10 septembre 14

Couplage faible : Exemple

Exemplaire dans le Prt (...). Quelle classe en sera responsable ? 28

Sylvain Cherrier, Design Patterns

mercredi 10 septembre 14 Avoir un couplage faible signiÞe une faible dŽpendance aux autres classes Un changement dans une classe force ˆ changer toutes ou la plupart des classes liŽes Les classes prises isolŽment sont difÞciles ˆ comprendre RŽutilisation difÞcile : lÕemploi dÕune classe nŽcessite celui des classes dont elle dŽpend

BŽnŽÞces du couplage faible

Exactement lÕinverse

29

Sylvain Cherrier, Design Patterns

mercredi 10 septembre 14

Couplage faible : discussion

Pas de mesure absolue de Çquand un couplage est trop fortÈ stables

Java.util par exemple

30

Sylvain Cherrier, Design Patterns

mercredi 10 septembre 14

Couplage faible : discussion

Cas extrme de faible couplage

des objets incohŽrents, complexes, qui font tout le travail des objets isolŽs, non couplŽs, qui servent ˆ stocker les donnŽes peu ou pas de communication entre objets une mauvaise conception qui va ˆ lÕencontre des principes OO (collaboration dÕobjets) Bref 31

Sylvain Cherrier, Design Patterns

mercredi 10 septembre 14

Contr™leur (GRASP)

Quel est le premier objet au delˆ de lÕIHM qui reoit et coordonne

Solution

32

Sylvain Cherrier, Design Patterns

Choisir ou Inventer un objet dans la couche

application pour gŽrer le Çcontr™leÈ mercredi 10 septembre 14

Contr™leur (GRASP)

Quel est le premier objet au delˆ de lÕIHM qui reoit et coordonne (contr™le)

Solution

Affecter cette responsabilitŽ ˆ une classe qui correspond ˆ lÕun des cas suivants logiciel sÕexŽcute (eq. ˆ des variantes dÕun contr™leur Faade) produit 33

Sylvain Cherrier, Design Patterns

contr™leur : objet n'appartenant pas ˆ lÕIHM ayant la responsabilitŽ de recevoir ou de gŽrer un ŽvŽnement mercredi 10 septembre 14

Contr™leur : exemple

34
mercredi 10 septembre 14

Contr™leur : exemple (suite)

scŽnario? Quelle(s) classes connectent la couche ÇPrŽsentationÈ ˆ la couche chargŽe de la logique applicative ? 35
mercredi 10 septembre 14

Contr™leur Facade

exemples : ProductController, etc.

A utiliser quand

contr™leur alternatif 36

Sylvain Cherrier, Design Patterns

mercredi 10 septembre 14

Contr™leur Cas dÕutilisation

Utiliser le mme contr™leur pour tous les ŽvŽnements dÕun cas dÕutilisation Un contr™leur diffŽrent pour chaque cas dÕutilisation contr™leur artiÞciel (ÇHandlerÈ), pas un objet du domaine

A utiliser quand

trop chargŽ) rŽpartit la gestion entre des classes distinctes et faciles ˆ gŽrer permet de conna"tre et dÕanalyser lՎtat du scŽnario en cours

Sylvain Cherrier, Design Patterns

37
mercredi 10 septembre 14

Contr™leur trop chargŽ (mauvais)

Pas de focus, prend en charge de nombreux domaines de responsabilitŽ

le contr™leur effectue la majoritŽ des t‰ches nŽcessaires pour rŽpondre aux ŽvŽnements

un contr™leur doit dŽlŽguer ˆ dÕautres objets les t‰ches ˆ effectuer ces informations doivent tre distribuŽes dans les autres objets ou doivent tre des duplications dÕinformations trouvŽes dans dÕautres objets

Solution

ajouter des contr™leurs concevoir des contr™leurs dont la prioritŽ est de dŽlŽguer 38

Sylvain Cherrier, Design Patterns

mercredi 10 septembre 14

Remarque : couche prŽsentation

Les objets dÕinterfaces graphique (fentres, applets) et la couche de cÕest la responsabilitŽ de la couche domaine 39

Sylvain Cherrier, Design Patterns

mercredi 10 septembre 14

Contr™leur : Avantages

Meilleur potentiel de rŽutilisation

moyen de sŽparer les connaissances du domaine de la couche prŽsentation/IHM

Capture lՎtat dÕun Cas dÕUtilisation

ordre 40

Sylvain Cherrier, Design Patterns

mercredi 10 septembre 14

Forte CohŽsion (GRASP)

CohŽsion

La cohŽsion (la cohŽsion fonctionnelle) est une mesure de lՎtroitesse des liens et de la spŽcialisation des responsabilitŽs dÕun ŽlŽment (dÕune classe) Une classe qui a des responsabilitŽs Žtroitement liŽes et nÕeffectue pas un travail gigantesque est fortement cohŽsive 41

Sylvain Cherrier, Design Patterns

mercredi 10 septembre 14

Forte CohŽsion (GRASP)

Comment parvenir ˆ maintenir la complexitŽ gŽrable ? Comment sÕassurer que les objets restent comprŽhensibles et faciles ˆ gŽrer? quÕils contribuent au faible couplage ?

Solution

Attribuer une responsabilitŽ de telle sorte que la cohŽsion reste forte. Appliquer ce principe pour Žvaluer les solutions possibles. 42

Sylvain Cherrier, Design Patterns

mercredi 10 septembre 14

Forte CohŽsion (suite)

Les classes ayant une faible cohŽsion effectuent des t‰ches sans liens entre elles ou effectuent trop de t‰ches

DifÞciles ˆ comprendre

DifÞciles ˆ rŽutiliser

DifÞciles ˆ maintenir

Fragiles, constamment affectŽes par le changement 43

Sylvain Cherrier, Design Patterns

mercredi 10 septembre 14

Forte CohŽsion : Exemple

GestionPret est partiellement responsable de la mise en place de lÕISBN GestionPret sera responsable de beaucoup dÕautres fonctions 44

Sylvain Cherrier, Design Patterns

mercredi 10 septembre 14

Forte CohŽsion : Exemple

DŽlŽgation des responsabilitŽs et coordination des t‰ches 45
mercredi 10 septembre 14

Forte CohŽsion : discussion

Comme le couplage faible, un pattern dՎvaluation ˆ garder en tte pendant toute la conception [Booch] : Il existe une cohŽsion fonctionnelle quand les ŽlŽments dÕun composant (eg. Les classes) travaillent toutes ensemble pour fournir un comportement bien dŽlimitŽ È 46

Sylvain Cherrier, Design Patterns

mercredi 10 septembre 14

Forte CohŽsion

Une classe de forte cohŽsion a un petit nombre de mŽthodes, avec des fonctionnalitŽs hautement liŽes entre elles, et ne fait pas trop de travail

Un test

DŽcrire une classe avec une seule phrase.

ensemble de modules cohŽsifs et peu couplŽs 47

Sylvain Cherrier, Design Patterns

mercredi 10 septembre 14

Forte CohŽsion : discussion

BŽnŽÞces de la forte cohŽsion

Augmentation de la clartŽ et de la comprŽhension de la conception

Maintenance et amŽliorations simpliގes

SigniÞe en gŽnŽral couplage faible

Meilleur potentiel de rŽutilisation

48

Sylvain Cherrier, Design Patterns

mercredi 10 septembre 14

Polymorphisme (GRASP)

Comment gŽrer des alternatives dŽpendantes des types ? Comment crŽer des composants logiciels Ç enÞchables È ?

Solution

Quand des fonctions ou des comportements connexes varient en fonction du type (classe), affectez les responsabilitŽs - en utilisant des opŽrations polymorphes - aux types pour lesquels le comportement varie ne pas utiliser de test sur le type dÕun objet ou une logique conditionnelle (if/ then/else) pour apporter des alternatives basŽes sur le type 49

Sylvain Cherrier, Design Patterns

mercredi 10 septembre 14

Polymorphisme (GRASP)

Polymorphisme

donner le mme nom ˆ des ÇservicesÈ dans diffŽrents objets 50

Sylvain Cherrier, Design Patterns

mercredi 10 septembre 14

Polymorphisme : exemple

disponible ? 51

Sylvain Cherrier, Design Patterns

mercredi 10 septembre 14

Polymorphisme : exemple

Monopoly : En fonction de la case sur laquelle atterrit le joueur le comportement est diffŽrent : Sur la case dŽpart, le joueur reoit 200 $, Sur la case imp™t, le joueur paie 10% de son cash, sur la case AllezEnPrison, le joueur va sur la case Prison. 52
mercredi 10 septembre 14

Polymorphisme : exemple

Monopoly : En fonction de la case sur laquelle atterrit le joueur le comportement est diffŽrent : Sur la case dŽpart, le joueur reoit 200 $, Sur la case imp™t, le joueur paie 10% de son cash, sur la case AllezEnPrison, le joueur va sur la case Prison. 53
mercredi 10 septembre 14

Polymorphisme : exemple

Monopoly : En fonction de la case sur laquelle atterrit le joueur le comportement est diffŽrent : Sur la case dŽpart, le joueur reoit 200 $, Sur la case imp™t, le joueur paie 10% de son cash, sur la case AllezEnPrison, le joueur va sur la case Prison. 54
mercredi 10 septembre 14

Polymorphisme : exemple

Monopoly : En fonction de la case sur laquelle atterrit le joueur le comportement est diffŽrent : Sur la case dŽpart, le joueur reoit 200 $, Sur la case imp™t, le joueur paie 10% de son cash, sur la case AllezEnPrison, le joueur va sur la case Prison. 55
mercredi 10 septembre 14

Polymorphisme

Implique en gŽnŽral lÕutilisation de classes abstraites et dÕinterfaces

Avantages

Les points dÕextension requis par les nouvelles variantes sont faciles ˆ ajouter On peut introduire de nouvelles implŽmentations sans affecter les clients 56

Sylvain Cherrier, Design Patterns

mercredi 10 septembre 14

Fabrication pure (GRASP)

Que faire quand les concepts du monde rŽel (objets du domaine) ne sont pas utilisables en respectant le Faible couplage et la Forte cohŽsion ?

Solution

Affecter un ensemble fortement cohŽsif ˆ une classe artiÞcielle ou dequotesdbs_dbs23.pdfusesText_29

[PDF] Architecture logicielle MVC - LIG Membres

[PDF] 1 Architecture traditionnelle et réhabilitation au Maroc - RehabiMed

[PDF] Le matériel : architecture des ordinateurs - Limuniv-mrsfr

[PDF] Architecture matériel et logiciel 2

[PDF] Architectures Logicielles et Matérielles - Verimag

[PDF] Vers une architecture n-tiers

[PDF] Les réseaux Peer-to-Peer

[PDF] L 'architecture postale - La Poste

[PDF] Partie 1 : Architecture et communications Client/Serveur - Univ Lyon 1

[PDF] Architecture Traditionnelle Méditerranéenne Méthode RehabiMed

[PDF] La fabrication de l architecture en Tunisie indépendante : une

[PDF] l 'architecture traditionnelle en tunisie : l 'habitat rural - RehabiMed

[PDF] Etude d une architecture IP intégrant un lien satellite - OATAO

[PDF] Les règles de classement et d 'archivage des documents d 'entreprise

[PDF] LES RECHERCHES CONCERNANT L ALGERIE - Archives nationales