Design Patterns (2003)

2 702 vues

Publié le

Mise en oeuvre des Design Patterns sur une étude de cas

Publié dans : Technologie
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
2 702
Sur SlideShare
0
Issues des intégrations
0
Intégrations
3
Actions
Partages
0
Téléchargements
98
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Design Patterns (2003)

  1. 1. 3012 Mise en oeuvre des DesignPatterns sur une étude de cas Pascal Roques Consultant senior et formateur
  2. 2. Introduction Présentations Programme
  3. 3. Présentations• Intervenant : Pascal Roques • Consultant senior chez • Responsable des formations autour de l’analyse et de la conception objet avec UML • Auteur de 3 ouvrages sur UML parus chez Eyrolles : UML en action - 2e édition UML par la pratique UML - Modéliser un site De lanalyse des besoins Cours et exercices Java et C# à la conception en Java e-commerce - 2ème édition Les Cahiers du Programmeur
  4. 4. Notre programme• 1. Introduction• 2. Les Design Patterns• 3. Analyse de l’étude de cas (Together®)• 4. Application des Design Patterns (Together®)• 5. Conclusion
  5. 5. Les Design Patterns Introduction aux DPGoF : State, Singleton, Template Method De l’analyse à la conception Application à l’étude de cas
  6. 6. Introduction aux « patterns »• Le succès d’une conception passe par l’attribution réussie des bonnes responsabilités aux bonnes classes• Problème : les décisions qui vont conduire à des systèmes extensibles et maintenables ne sont pas forcément évidentes• Solution : il y a des principes fondamentaux et éprouvés appelés « patterns » que tout concepteur expérimenté applique
  7. 7. Introduction aux « patterns »• Les « patterns » sont : • Des paires nommées (problème + solution) • Des conseils issus de la pratique d’experts • Une technique essentielle dans le monde de la conception orientée objet !• Les concepteurs aguerris conçoivent par le biais d’un « langage de patterns » • « Dans cette conception, j’ai associé les patterns State (État) et Singleton pour faciliter l’ajout de nouveaux états… Vaudrait-il mieux que j’utilise le Flyweight ? »
  8. 8. Ressources sur les patterns• Exemples de patterns et de ressources : • Patterns GRASP • Neuf patterns d’attribution des responsabilités fondamentales • UML et les Design Patterns (Larman, 2001, CampusPress). • Les patterns « Gang of Four » (GoF) • 23 patterns courants dans des situations spécifiques • Le plus connu des ensembles de patterns orientés objets • Design Patterns (Gamma, et. al. 1995, AW). • Les patterns en Java • 50 patterns courants avec leur traduction en Java • Patterns in Java (Grand, 2003, Wiley). • …
  9. 9. Modèle de description (1/3) • Nom du pattern • Le nom du pattern véhicule succinctement l’essence du pattern • Il est essentiel de trouver un nom clair et facile à mémoriser ! • Intention • Formule brève répondant aux questions suivantes : • Que fait le design pattern ? • Quels en sont le raisonnement et l’intention ? • Quel problème spécifique de conception traite-t-il ? • Également appelé • Autres noms connus du pattern, s’il en existe (alias) • Motivation • Scénario illustrant un problème de conception ainsi que la façon dont les structures de classes et d’objets du pattern résolvent le problèmesource : Design Patterns – Elements of Reusable Object-Oriented Software
  10. 10. Modèle de description (2/3) • Applicabilité • Quelles sont les situations dans lesquelles le design pattern peut être appliqué ? Quels sont les exemples de mauvaises conceptions que le pattern permet de traiter ? • Structure • Généralement, représentation graphique des classes du pattern créée à l’aide d’UML • Participants • Classes et/ou objets prenant part au design pattern avec leurs responsabilités respectives • Collaborations • Façon dont les participants collaborent afin d’assumer leurs responsabilités • Patterns connexes • Quels sont les design patterns liés de près à celui-ci ? Avec quels autres patterns celui-ci doit-il être utilisé ?source : Design Patterns – Elements of Reusable Object-Oriented Software
  11. 11. Modèle de description (3/3) • Conséquences • De quelle façon le pattern accomplit-il ses objectifs ? • Quels sont les compromis et les résultats liés à l’utilisation du pattern ? • Implémentation • Quels sont les pièges, les conseils ou les techniques dont il faut avoir connaissance lors de la mise en œuvre du pattern ? • Y a-t-il des questions spécifiques au langage ? • Exemple de code • Fragments de code illustrant la façon dont on pourrait mettre en œuvre le pattern avec un langage orienté objets • Usages connus • Exemples d’utilisation du pattern sur des systèmes réelssource : Design Patterns – Elements of Reusable Object-Oriented Software
  12. 12. Les Design Patterns GoFsource : Design Patterns – Elements of Reusable Object-Oriented Software
  13. 13. Le DP Singleton (1/2)• Problème : comment garantir la présence d’une seule instance d’une classe et fournir un point d’accès global à cette instance ?• Solution : sauvegarder l’objet singleton dans une variable statique et implémenter une méthode de classe retournant ce singleton • Notez que cela fournit un accès global sans les défauts des variables globales • Le constructeur est déclaré privé (ou mieux : protégé)
  14. 14. Le DP Singleton (2/2)
  15. 15. Le DP Template Method (1/2)• Le pattern Template Method (TMP) est au cœur de la conception d’algorithmes génériques• Problème : comment concevoir des algorithmes variables et non variables ?• Solution : définissez le squelette d’un algorithme dans une méthode de super-classe, en confiant certaines étapes à des sous-classes
  16. 16. Le DP Template Method (2/2)
  17. 17. Le DP State (1/2) • Problème : le comportement d’un objet dépend de son état • l’objet doit changer de comportement à l’exécution • Il est nécessaire que la réponse d’une instance varie en fonction de son état public void m1(){ public void m1(){ public void m2(){ public void m2(){ public void m3(){ public void m3(){ if < test 1 > if < test 1 > if < test 1 > if < test 1 > if < test 1 > if < test 1 > methodA() methodA() methodC() methodC() methodE() methodE() else if < test 2 > else if < test 2 > else if < test 2 > else if < test 2 > else if < test 2 > else if < test 2 > methodB() methodB() methodD() methodD() methodF() methodF() } } } } } }• Solution : délégation + polymorphisme • Classe abstraite (ou interface) « Etat »
  18. 18. Le DP State (2/2)
  19. 19. Analyse de l’étude de cas Présentation Analyse des besoins Modèle du domaine
  20. 20. L’étude de cas (1/2)• Le jeu du Démineur …
  21. 21. L’étude de cas (2/2)• L’objectif de cette étude de cas est de concevoir un jeu de démineur comme celui qui est livré avec Windows© • Nous souhaitons utiliser un processus itératif et incrémental• La démarche classique de modélisation que nous allons appliquer est la suivante : • Analyse des besoins • Diagramme de cas d’utilisation • Diagramme de séquence système • Modèle du domaine • Diagramme de classes • Diagramme d’états • Modèle de conception objet • Diagramme de classes • Diagrammes d’interactions
  22. 22. Analyse des besoins (1/2)• Diagramme de cas d’utilisation Paramétrer le jeu <<extend>> [Paramétrage] Jouer au démineur Joueur Extension points Itération 1 : avec paramétrage par défaut, Paramétrage et non prise en compte du marquage « ? » Help <<extend>> [Help] Consulter laide en ligne
  23. 23. Analyse des besoins (2/2)• Diagramme de séquence « système » Demineur Joueur initialiser() decouvrirCase(Point) marquerCase(Point) etc. decouvrirCase(Point) gagné !! entrerNomHighScores(n)
  24. 24. Modèle du domaine (1/2)• Diagramme de classes du domaine
  25. 25. Modèle du domaine (2/2)• Diagramme d’états : la classe Case • Complexité itérative ! Itération 1 Itération ultérieure…
  26. 26. Application des Design Patterns avec Together© Conception DP State DP Singleton DP Template Method
  27. 27. Architecture logique• Le modèle du domaine va nous servir de base pour la couche « domaine » de notre architecture logique en conception objet • Modèle simplifié en 3 couches
  28. 28. De l’analyse à la conception (1/3)• Dans le diagramme de classes, nous allons maintenant indiquer : • Les méthodes • La navigabilité des associations • Les dépendances entre classes • Les types des attributs et des méthodes (retour, paramètres)• Together permet d’ajouter facilement les constructeurs, accesseurs, etc.
  29. 29. De l’analyse à la conception (2/3)• Le modèle du domaine fournit des classes candidates pour le diagramme de classes de conception • Le concepteur peut être amené à fusionner certains concepts ou au contraire à introduire de nouvelles classes de conception État ??
  30. 30. De l’analyse à la conception (3/3)• Diagramme de classes de conception • premier jet pour l’itération 1
  31. 31. Classes de conception• Ajout des types non-primitifs (optionnel)
  32. 32. Conception de la dynamique (1/3)• Pour chaque « opération système » complexe, nous allons réaliser un diagramme d’interaction (collaboration ou séquence) Démineur • La complexité se Joueur initialiser() trouve dans les deux opérations : decouvrirCase(Point) marquerCase(Point) • decouvrirCase(Point) etc. • marquerCase(Point) decouvrirCase(Point) gagné !! entrerNomHighScores(n)
  33. 33. Conception de la dynamique (2/3)• Commençons par « marquerCase » : • Le joueur clique sur un point du plateau, il faut déjà traiter l’événement graphique en trouvant la case concernée… 1: marquerCase(Point) :Partie 1.1: marquerCase(Point) les:Case :Plateau 1.1.1: c:=get(Point) 1.1.2: marquer() 1.1.2.1: ?? c:Case
  34. 34. Conception de la dynamique (3/3)• Continuons « marquerCase » : • Si elle est toujours couverte, une case peut être marquée en respectant les règles indiquées par le diagramme d’états • Le traitement à effectuer dépend donc entièrement de l’état de la case pointée…• Nous allons utiliser le Design pattern du State • !Avantage : évolutivité facilitée (pour la prise en compte ultérieure du marquage « ? »)
  35. 35. Application du DP State (1/4)• Diagramme de classes de conception « avant » • Ajout des méthodes dans Plateau et Case
  36. 36. Application du DP State (2/4)
  37. 37. Application du DP State (3/4)• Diagramme de classes de conception « après »« !
  38. 38. Application du DP State (4/4)• Le code Java correspondant « après »« !
  39. 39. Suite de la dynamique (1/2)• Continuons « marquerCase » : • En fonction de son état, la case effectue des traitements différents marquer(c : Case) :EtatDecouverte marquer(c : Case) 2: majCompteur(-1) <<singleton>> :EtatCouverteNonMarquee :Partie 1: setEtatCourant(EtatDrapeau) c : Case marquer(c: Case) 2: majCompteur(1) <<singleton>> :EtatDrapeau :Partie 1: setEtatCourant(EtatCouverteNonMarquee) c : Case
  40. 40. Suite de la dynamique (1/2)• Quelles sont les améliorations du modèle que l’étude de la dynamique nous inspire ?• Les états doivent recevoir en paramètre la case elle-même pour pouvoir ensuite invoquer la méthode setEtatCourant() • marquer() marquer(c : Case) • Idem pour decouvrir(c : Case)• De nombreuses classes vont avoir besoin d’un accès à la classe Partie : tous les états, etc.• Cette classe Partie doit avoir une seule instance à la fois ! • L’utilisation du DP Singleton est naturelle …
  41. 41. Suite de la dynamique (2/2)• Appliquons le DP Singleton à la classe Partie
  42. 42. Application du DP Singleton• Le modèle et le code Java correspondant « après »« !
  43. 43. Classes de conception • Le modèle complété de l’itération 1 pourrait alors ressembler à:
  44. 44. Développement itératif• Le DP State facilite l’introduction itérative d’un nouvel état de marquage de la case Itération 1 Itération ultérieure…
  45. 45. Nouvelle application du State (1/2)• Together permet facilement d’ajouter un nouvel état concret • Grâce au paramètre “create pattern links” qui reconnaît les participants au DP
  46. 46. Nouvelle application du State (2/2)• Diagramme de classes de conception « après »« !
  47. 47. Conclusion
  48. 48. Pas de « pattern-alisme » excessif !• Une bonne conception n’implique pas d’utiliser tous les patterns de la terre ! • Utilisez les bons patterns au bon endroit et justifiez votre solution ! • Il est rare de réaliser une bonne conception dès la première tentative • L’activité de refactoring aide à rectifier les erreurs • Développez de façon itérative• Évitez le syndrome du « silver bullet » ! • Utilisation obsessionnelle d’un pattern ou d’une technologie auxquels vous êtes habitué • Méfiez-vous de ceux qui disent avoir un pattern préféré !
  49. 49. Utilisez Together ! Together permet d’appliquer plus facilement des patterns sur vos modèles UML … Il permet également de se créer ses propres patterns ! Mais ceci est une autre histoire …
  50. 50. Questions?
  51. 51. Merci !N’oubliez pas de remplir le formulaire d’évaluation Vous pouvez me contacter à … pascal.roques@valtech.fr

×