La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Foutse Khomh © Guéhéneuc, 2009; Khomh, 2010 Département de génie informatique et de génie logiciel École Polytechnique de Montréal LOG4430 : Architecture.

Présentations similaires


Présentation au sujet: "Foutse Khomh © Guéhéneuc, 2009; Khomh, 2010 Département de génie informatique et de génie logiciel École Polytechnique de Montréal LOG4430 : Architecture."— Transcription de la présentation:

1 Foutse Khomh © Guéhéneuc, 2009; Khomh, 2010 Département de génie informatique et de génie logiciel École Polytechnique de Montréal LOG4430 : Architecture et conception avancée Patrons et concepts associés

2 2/84 Patrons de conception Introduction aux patrons de conception: Exemple du Visitor. Patrons de conception: Feeling, Seeing, and Touching. Reification

3 3/84 Exemple (1/5) Compilateur –Parser des fichiers pour construire lASTT –Iteration sur l AST Bind types Generate code …

4 4/84 Exemple (2/5) AST

5 5/84 Exemple (3/5) package compiler; import java.util.Set; public class Method { private Set statements; public void addStatement(final Statement aStatement) { this.statements.add(aStatement); } public void removeStatement(final Statement aStatement) { this.statements.remove(aStatement); } package compiler; public class Field { /* To be implemented. */ } package compiler; public class Statement { /* To be implemented. */ }

6 6/84 Exemple (4/5) package compiler; import java.util.Set; public class Class { private String name; private Set methods; private Set fields; public String getName() { return this.name; } public void addMethod(final Method aMethod) { this.methods.add(aMethod); } public void removeMethod(final Method aMethod) { this.methods.remove(aMethod); } public void addField(final Method aField) { this.fields.add(aField); } public void removeField(final Field aField) { this.fields.remove(aField); }

7 7/84 Exemple (5/5) package compiler; import java.util.Iterator; import java.util.Set; public class CompilationUnit { private Set classes; public void addClass(final Class aClass) { this.classes.add(aClass); } public void removeClass(final Class aClass) { this.classes.remove(aClass); } public Class getClass(final String aName) { final Iterator iterator = this.classes.iterator(); while (iterator.hasNext()) { final Class aClass = (Class) iterator.next(); if (aClass.getName().equals(aName)) { return aClass; } return null; }

8 8/84 Implémentation naïve (1/7) Comment générer du code pour –Microsoft Windows operating system –Intel Pentium processor Ajouter une méthode generateCode() dans chaque classes

9 9/84 Implémentation naïve (2/7) public class Method { … public String generateCode() { String generatedCode = ""; /* Do something at the beginning. */ final Iterator iterator = this.statements.iterator(); while (iterator.hasNext()) { final Statement aStatement = (Statement) iterator.next(); generatedCode += aStatement.generateCode(); } /* Do something at the end. */ return generatedCode; } public class Field { … public String generateCode() { String generatedCode = ""; /* Do something. */ return generatedCode; } public class Statement { … public String generateCode() { String generatedCode = ""; /* Do something. */ return generatedCode; }

10 10/84 Implémentation naïve (3/7) public class Class { … public String generateCode() { String generatedCode = ""; /* Do something at the beginning. */ final Iterator iteratorOnFields = this.fields.iterator(); while (iteratorOnFields.hasNext()) { final Field aField = (Field) iteratorOnFields.next(); generatedCode += aField.generateCode(); } final Iterator iteratorOnMethods = this.methods.iterator(); while (iteratorOnMethods.hasNext()) { final Method aMethod = (Method) iteratorOnMethods.next(); generatedCode += aMethod.generateCode(); } /* Do something at the end. */ return generatedCode; }

11 11/84 Implémentation naïve (4/7) public class CompilationUnit { … public String generateCode() { String generatedCode = ""; /* Do something at the beginning. */ final Iterator iterator = this.classes.iterator(); while (iterator.hasNext()) { final Class aClass = (Class) iterator.next(); generatedCode += aClass.generateCode(); } /* Do something at the end. */ return generatedCode; }

12 12/84 Implémentation naïve (5/7)

13 13/84 Implémentation naïve (6/7) Limitations de l implémentation naïve –Que se passe t-il en cas de génération de code pour Linux on PowerPC? Linux on Motorola 68060? OS/400 on AS/400? Explosion combinatoire de méthodes generateCodeForXXX() dans chaque classes

14 14/84 Implémentation naïve (7/7) Requis: –Decouple the data structure The AST –From algorithms on the data structure The generateCodeForXXX() method And others, including type binding! Le patron Visiteur vous permet de faire ça

15 15/84 Le Patron Visiteur (1/12) Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates. [Gamma et al.]

16 16/84 Le Patron Visiteur (2/12) Name : Visitor Intent : Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.

17 17/84 Le Patron Visiteur (3/12) Motivation : Consider a compiler that represents programs as abstract syntax trees. It will need to perform operations on abstract syntax trees for "static semantic" analyses like checking that all variables are defined. It will also need to generate code.

18 18/84 Le Patron Visiteur (4/12) Motivation (contd) : […] It will be confusing to have type-checking code mixed with pretty-printing code or flow analysis code. […] It would be better if each new operation could be added separately, and the node classes were independent of the operations that apply to them.

19 19/84 Le Patron Visiteur (5/12) Motivation (contd) : We can have both by packaging related operations from each class in a separate object, called a visitor, and passing it to elements of the abstract syntax tree as it's traversed.

20 20/84 Le Patron Visiteur (6/12) Motivation (contd) : When an element accepts the visitor, it sends a request to the visitor that encodes the element's class. It also includes the element as an argument. The visitor will then execute the operation for that elementthe operation that used to be in the class of the element.

21 21/84 Le Patron Visiteur (7/12) Utilisation : Ce patron est adapté lorsque –La structure dun objet contient plusieurs classes dobjets avec des interfaces différentes… –Plusieurs opérations distinctes et indépendantes doivent être effectuées sur les objets de la structure… –Les classes définissants la structure changent rarement mais de nouvelles opérations sont fréquemment définies sur la structure…

22 22/84 Le Patron Visiteur (8/12) Permet du double dispatch –Receive a call –Send a call back with parameter values class Client { void printAllEverywhere(Figure[] figures, Printer[] printers) { for (int i = 0; i < figures.length; i++) { final Figure figure = figures[i]; for (int j = 0; j < printers.length; j++) { Printer printer = printers[j]; figure.printOn(printer); } Adapted from

23 23/84 Le Patron Visiteur (9/12) Structure

24 24/84 Le Patron Visiteur (10/12) Participants –Visitor ( NodeVisitor ) Declares a Visit operation for each class… –ConcreteVisitor ( TypeCheckingVisitor ) Implements each Visit… –Element ( Node ) Defines an Accept operation… –ConcreteElement ( AssignmentNode ) Implements Accept … –ObjectStructure ( Program ) Can enumerate its elements May provide a high-level interface to allow the visitor to visit its elements May either be a composite (see Composite) or a collection

25 25/84 Le Patron Visiteur (11/12) Collaborations

26 26/84 Le Patron Visiteur (12/12) Consequences : … Implementation : … Sample code : … Known uses –… –PADL Related patterns : Composite and Interpreter

27 27/84 Meilleure implémentation (1/6) package compiler.visitor; import compiler.Class; import compiler.CompilationUnit; import compiler.Field; import compiler.Method; import compiler.Statement; public interface Visitor { void open(final Class aClass); void open(final CompilationUnit aCompilationUnit); void open(final Method aMethod); void close(final Class aClass); void close(final CompilationUnit aCompilationUnit); void close(final Method aMethod); void visit(final Field aField); void visit(final Statement aStatement); }

28 28/84 Meilleure implémentation (2/6) public class Method { … public void accept(final Visitor aVisitor) { aVisitor.open(this); final Iterator iterator = this.statements.iterator(); while (iterator.hasNext()) { final Statement aStatement = (Statement) iterator.next(); aStatement.accept(aVisitor); } aVisitor.close(this); } public class Field { … public void accept(final Visitor aVisitor) { aVisitor.visit(this); } public class Statement { … public void accept(final Visitor aVisitor) { aVisitor.visit(this); }

29 29/84 Meilleure implémentation (3/6) public class Class { … public void accept(final Visitor aVisitor) { aVisitor.open(this); final Iterator iteratorOnFields = this.fields.iterator(); while (iteratorOnFields.hasNext()) { final Field aField = (Field) iteratorOnFields.next(); aField.accept(aVisitor); } final Iterator iteratorOnMethods = this.methods.iterator(); while (iteratorOnMethods.hasNext()) { final Method aMethod = (Method) iteratorOnMethods.next(); aMethod.accept(aVisitor); } aVisitor.close(this); }

30 30/84 Meilleure implémentation (4/6) public class CompilationUnit { … public void accept(final Visitor aVisitor) { aVisitor.open(this); final Iterator iterator = this.classes.iterator(); while (iterator.hasNext()) { final Class aClass = (Class) iterator.next(); aClass.accept(aVisitor); } aVisitor.close(this); }

31 31/84 Meilleure implémentation (5/6)

32 32/84 Meilleure implémentation (6/6) Lutilisation du patron Visiteur vous permet de: –Decouple data structure and algorithms –Allow the addition of new algorithms without changing the data structure Much better, clearer implementation!

33 33/84 Résumé Le patron Visiteur est utile partout ou lon a: –A data (stable) structure –Algorithms (infinite) on that data structure Les patrons de conception proposent des bonnes solutions à des problèmes récurrents de conception!

34 34/84 Patrons de conception = Outils pour développeurs

35 35/84 Patrons de conception: Feeling, Seeing, and Touching. Feeling –Le patron de conception Factory Method Seeing –Origines –Définition –Structure Touching –Quand et comment utiliser les patrons de conception –Outils supportant les patrons de conception

36 36/84 Factory Method(1/3) Besoin: Un Cadriciel pour programmes supportant plusieurs types de documents Problème: Les programmes savent quand créer de nouveaux documents, mais pas le type de document a créer

37 37/84 Factory Method(2/3) Solution: Isoler linformation sur le type de document a créer et la reporter à lextérieur du Cadriciel

38 38/84 Factory Method(3/3) Abstraction? Impact sur la qualité?

39 39/84 Origines(1/5) Each 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 way that you can use this solution a million times over, without ever doing it the same way twice. Each pattern is a three part rule, which express a relation between a context, a problem, and a solution. Christopher Alexander [Alexander, 1977]

40 40/84 Origines(2/5) The strict modeling of the real world leads to reflect todays realities but not necessarily tomorrows. The abstractions that emerge during design are key to making a design flexible. Erich Gamma [Gamma et al., 1994]

41 41/84 Origines(3/5) Systèmes de plus en plus complexes, le nombre de classes et dinstances est de plus en plus élevé. Vers une plus grande réutilisation de classes: ensembles de classes collaboratrices. Quest quun bon design?

42 42/84 Origines(4/5) Un patron de conception cest: –Description d une solution classique à un problème récurent –Décrit une partie de la solution… –Avec des relations avec le système et les autres parties... –C est une technique d architecture logicielle

43 43/84 Origines(5/5) Un patron de conception nest pas: –Une brique Un pattern dépend de son environnement –Une règle Un pattern ne peut pas s appliquer mécaniquement –Une méthode Ne guide pas une prise de décision ; un pattern est la décision prise –Nouveau Non, Lao-Tzu (-550) travaillait déjà sur les patterns...

44 44/84 Definition(1/3) The description of communicating objects and classes customized to solve general design problem in a particular context. Each design pattern lets some aspect of system structure vary independently of other aspects, thereby making a system more robust to a particular kind of change. [Gamma et al., 1994]

45 45/84 Definition(2/3) Avantages –Un vocabulaire commun –Permettent une plus grande reutilisabilité –Capitalisation de l expérience –Un niveau d abstraction plus élevé qui permet d élaborer des constructions logicielles de meilleure qualité –Réduire la complexité –Guide/catalogue de solutions

46 46/84 Definition(3/3) Inconvénients –Effort de synthèse ; reconnaître, abstraire… –Apprentissage, expérience –Les patterns « se dissolvent » en étant utilisés –Nombreux… lesquels sont identiques ? De niveaux différents … des patterns s appuient sur d autres...

47 47/84 Structure (1/3) Nom : augmente le vocabulaire, réifie une idée de solution, permet de mieux communiquer. Problème : quand appliquer la forme, le contexte... Solution : les éléments de la solution, leurs relations, responsabilités, collaborations. Pas de manière précise, mais suggestives... Conséquences : résultats et compromis issus de l'application de la forme

48 48/84 Plus encore…(2/3) Problème + Conséquence = Contexte –Intention, applicabilité, conséquences Solution + Conséquence = Stratégies –Structure, participants, collaborations Compréhension –Motivation, patrons relies, utilisations connues Utilisation –implémentation et exemple de code

49 49/84

50 50/84 Quand utiliser un patron de conception? Lorsque le problème est complexe? –Plusieurs patrons de conception existent –Granularité Requis, analyses, architecture Conception, implémentation (idioms) Refactoring, testing … Les connaître tous...

51 51/84 Application des patrons de conception (1/5) Lapplication des patrons lors de la conception permet –Trouver les bons objets Les patterns proposent des abstractions qui n'apparaissent pas "naturellement" en observant le monde réel Composite par exemple permet de traiter uniformément une structure d'objets hétérogènes –Bien choisir la granularité des objets La taille des objets peut varier considérablement ; comment choisir ce qui doit être décomposé ou au contraire regroupé ? Exple: Facade, Flyweight,… –Spécifier les interfaces des objets Quest-ce qui fait partie dun objet ou non ? Exple: Memento, Decorator

52 52/84 Application des patrons de conception (2/5) Lapplication des patrons lors de la conception permet –Spécifier l'implantation des objets Différence type-classe… Exple: Chain of Responsibility ; même interface, mais implantations différentes –Mieux réutiliser Héritage vs composition; Préférez la composition à l'héritage Délégation; Une forme de composition...qui remplace l'héritage, Exple: Mediator, Visitor, Proxy

53 53/84 Application des patrons de conception (3/5) Quelques astuces pour une bonne conception –Création d'un objet en référençant sa classe explicitement...Lien à une implantation particulière...pour éviter utilisez AbstractFactory, FactoryMethod, Prototype –Dépendance d'une opération spécifique...pour rendre plus souple utilisez Chain Of Responsibility, Command –Dépendance d'une couche matérielle ou logicielle...AbstractFactory, Bridge

54 54/84 Application des patrons de conception (4/5) Quelques astuces pour une bonne conception –Dépendance d'une implantation...pour rendre plus souple utilisez AbstractFactory, Bridge, Memento, Proxy –Dépendance d'un algorithme particulier...Builder, Iterator, Strategy, TemplateMethod, Strategy –Couplage fort...relâcher les relations utilisez AbstractFactory, Bridge, Chain Of Responsibility, Command, Facade, Mediator,Observer

55 55/84 Application des patrons de conception (5/5) Quelques astuces pour une bonne conception –Etendre les fonctionnalités en sous-classant peut être couteux (tests, compréhension des superclasses, etc) utilisez aussi la délégation, la composition...Bridge, Chain Of Responsibility, Composite, Decorator, Observer, Strategy, Proxy –Impossibilité de modifier une classe...absence du source, trop de répercussions, voyez Adapter, Decorator, Visitor

56 56/84 Exemple: Adaptateur (Adapter) Exemple de situation : Jutilise une bibliothèque de traitement dimages (dont je ne peux pas modifier le code source). Pour fonctionner, elle attend un objet fournissant une interface daccès en lecture et en écriture à un tableau en deux dimensions contenant des triplets doctets. Jaimerais linterfacer avec une bibliothèque fournissant une abstraction sur des tableaux unidimensionnels stockés de manière persistante dans une base de données ou dans un système de fichiers. Problème : Comment concilier les services proposés par la bibliothèque dentrées/sorties et linterface attendue par la bibliothèque de traitement dimages. Solution : Utiliser un objet qui implémente linterface attendue en faisant appel aux services proposés par une instance de la bibliothèque dentrées/sorties. [Yann08 ]

57 57/84 Exemple: Adaptateur (Adapter)

58 58/84 Exemple: Adaptateur (Adapter)

59 59/84 Comment utiliser les patrons de conception? De façon itérative et inductive –Partir de solutions simple et progressivement factoriser le code pour évoluer vers les patrons de conception si nécessaire… Choisir le bon patron dès la phase de conception

60 60/84 Catégories de patrons de conception Création –Fabrique abstraite (Abstract Factory) –Monteur (Builder) –Fabrique (Factory Method) –Prototype (Prototype) –Singleton (Singleton) Structuraux –Adaptateur (Adapter) –Pont (Bridge) –Objet composite (Composite) –Décorateur (Decorator) –Façade (Facade) –Poids-mouche ou poids-plume (Flyweight) –Proxy (Proxy) Comportementaux –Chaîne de responsabilité (Chain of responsibility) –Commande (Command) –Interpréteur (Interpreter) –Itérateur (Iterator) –Médiateur (Mediator) –Mémento (Memento) –Observateur (Observer) –État (State) –Stratégie (Strategy) –Patron de méthode (Template Method) –Visiteur (Visitor)

61 61/84 Patrons de conception Reification

62 62/84 Meta ? Du Grec : après, passé, post- Aristote et lensemble de livres « La Métaphysique » –Traite de létant en tant quétant –Traite de ce qui vient après la physique (nature) –Nommé par Andronicos de Rhodes –Propose une continuité entre physique et métaphysique Aristote ( ριστοτέλης) *

63 63/84 Meta ? Principal problème de linformatique –Comment représenter les objets manipulées par les programmes ? –Objets = Données –Objets = Programmes (!)

64 64/84 Meta ? Langages de programmation à classes –Représentation des programmes –Réflexion et méta-niveaux Analyse et conception –Représentation des données –Modélisation et métamodèles

65 65/84 Langages de programmation Réflexion –« La capacité dune entité à sauto-représenter et plus généralement à se manipuler elle-même, de la même manière quelle représente et manipule son principal sujet » [Smi90] –« La réflexion est la capacité dun programme à manipulé en tant que données les entités qui représentent létat du programme pendant sa propre exécution. » [BGW93]

66 66/84 Langages de programmation Introspection et intercession –« Lintrospection est la capacité dun programme dobserver et donc de raisonner sur son propre état » [BGW93] –« Lintercession est la capacité dun programme de modifier son propre état dexécution, ou daltérer sa propre interprétation ou signification » [BGW93]

67 67/84 Langages de programmation Réification –Opération (mécanisme) qui fournit une auto- représentation dun programme réflexif –Résultat de lopération qui consiste à représenter des entités dun programme sous forme dobjets manipulable par le programme (Réifier […] Transformer en chose […] chosifier. [Le Petit Robert])

68 68/84 Analyse et conception Besoin dexprimer larchitecture dun programme pendant –Son analyse –Sa conception

69 69/84 Analyse et conception Besoin de langages pour décrire et représenter un programme pendant –Son analyse –Sa conception

70 70/84 Analyse et conception Besoin de langages pour décrire et représenter un programme –Aspects dynamiques –Aspects comportementaux –Aspects structuraux (détaillés, globaux) –Aspects organisationnels

71 71/84 Analyse et conception De nombreux langages –OMT (James Rumbaugh) –OOD (Grady Booch) –OOSE (Ivar Jacobson) –UML

72 72/84 Analyse et conception UML –Un standard de facto –Un langage de modélisation –Pas une méthode –Pas un processus

73 73/84 Analyse et conception UML métamodèle –Définit la sémantique du langage UML pour représenter des modèles UML –Décrit en lui-même (?) –Nest pas très formel, décrit surtout une syntaxe

74 74/84 Analyse et conception UML métamodèle –Aspects dynamiques Diagrammes de séquences, de collaborations –Aspects comportementaux Diagrammes détats, dactivités, dobjets –Aspects structuraux (détaillés, globaux) Diagrammes de classes –Aspects organisationnels Diagrammes de composants, de déploiement

75 75/84 Analyse et conception UML méta-métamodèle –Définit la sémantique du méta-modèle UML (et autres) pour représenter des méta-modèles –Décrit en lui-même (?) –Nest pas très formel, décrit surtout une syntaxe (Aussi appelé MOF pour Meta-Object Facility)

76 76/84 Analyse et conception UML méta-métamodèle

77 77/84 Analyse et conception UML méta-métamodèle

78 78/84 Analyse et conception UML méta-métamodèle

79 79/84 Autres modèles de représentation Conceptual Graphs (cf. index.htm) « Tom believes that Mary wants to marry a sailor »

80 80/84 Autres modèles de représentation sNets (cf. recherch/travaux/cahiers98/lemesle.html)

81 81/84 Outils supportant les patrons de conception GoF book –Lists, classifications, relationships –[Gamma et al., 1996] C ASE Tools –Fragments [Florijn et al., 1997] –PatternsBox and Ptidej [Albin et al., 2001] Navigation –Tutor [Motelet, 2000]

82 82/84 Bibliographie [Alexander, 1977] Christopher Alexander ; A Pattern Language ; New York Oxford University Press, [Gamma et al., 1994] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides ; Design Patterns – Elements of Reusable Object- Oriented Software ; Addison Wesley [Florijn et al., 1997] Gert Florijin, Marco Meijers, and Pieter van Winsen ; Tool Support for Object-Oriented Pattern ; Proceedings of ECOOP, [Albin et al., 2001] Hervé Albin-Amiot, Pierre Cointe, Yann-Gaël Guéhéneuc, and Narendra Jussien ; Instantiating and Detecting Design Patterns: Putting Bits and Pieces Together ; Proceedings of ASE, [Motelet, 2000] Olivier Motelet ; A Contextual Help System for Assisting Object-Oriented Software Designers in using Design Patterns ; EMOOSE Master Thesis, 2000

83 83/84 Bibliographie [BC89] J.-P. Briot and P. Cointe ; Programming with Explicit Metaclasses in Smalltalk ; In proceedings of OOPSLA, pages 419–431, 1989 [BGW93] D.G. Bobrow, R.G. Gabriel, and J.L. White ; Object-Oriented Programming – The CLOS perspective ; In Object-Oriented Programming, MIT Press, 1993 [BS99] M.N. Bouraqadi-Sâadani ; Un MOP Smalltalk pour létude de la composition et la compatibilité des métaclasses – Application à la programmation par aspects ; Thèse de doctorat, Université de Nantes, 1999 [KdRB91] G. Kickzalès, Jim des Rivières, and D.G. Bobrow ; The Art of the Metaobject Protocol ; MIT Press, 1991 [Kee89] S.E. Keene ; Object-Oriented Programming in Common Lisp: A Programmers Guide to CLOS ; Addison-Wesley, 1989 [Yann08 ] Yann Régis-Gianas; Programmation Objet : Concepts Avancés Cours 5 : Patrons (et Anti-patrons) de conception, PPS - Université Denis Diderot – Paris 7

84 84/84 Bibliographie [Mal97] J. Malenfant ; Abstraction,encapsulation et réflexion dans les langages à prototypes ; Thèse dhabilitation, Université de Nantes, 1997 [Mul95] P. Mulet ; Réflexion et langages à prototypes ; Thèse de doctorat, Université de Nantes, 1995 [Riv97] F. Rivard ; Evolution du comportement des objets dans les langages à classes réflexifs ; Thèse de doctorat, Université de Nantes, 1997 [Smi84] B. Smith ; Reflection and Semantics in Lisp ; In proceedings of POPL, pages 23–35, 1984 [Smi90] B. Smith ; What do You Mean, Meta? ; In ECOOP/OOPSLA workshop on Reflection and Metalevel Architectures in OO Programming, 1990 [Beugnard] Les design patterns, ENST Bretagne.


Télécharger ppt "Foutse Khomh © Guéhéneuc, 2009; Khomh, 2010 Département de génie informatique et de génie logiciel École Polytechnique de Montréal LOG4430 : Architecture."

Présentations similaires


Annonces Google