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

1. 3012
Mise en oeuvre des Design
Patterns sur une étude de cas
Pascal Roques
Consultant senior et formateur

2. Introduction
Présentations
Programme

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 l'analyse des besoins Cours et exercices Java et C#
à la conception en Java
e-commerce
- 2ème édition
Les Cahiers du Programmeur

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. Les Design Patterns
Introduction aux DP
GoF : State, Singleton, Template Method
De l’analyse à la conception
Application à l’étude de cas

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. 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. 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. 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ème
source : Design Patterns – Elements of Reusable Object-Oriented Software

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. 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éels
source : Design Patterns – Elements of Reusable Object-Oriented Software

12. Les Design Patterns GoF
source : Design Patterns – Elements of Reusable Object-Oriented Software

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. Le DP Singleton (2/2)

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. Le DP Template Method (2/2)

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. Le DP State (2/2)

19. Analyse de l’étude de cas
Présentation
Analyse des besoins
Modèle du domaine

20. L’étude de cas (1/2)
• Le jeu du Démineur …

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. 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 l'aide en ligne

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. Modèle du domaine (1/2)
• Diagramme de classes du domaine

25. Modèle du domaine (2/2)
• Diagramme d’états : la classe Case
• Complexité itérative !
Itération 1
Itération ultérieure…

26. Application des Design Patterns
avec Together©
Conception
DP State
DP Singleton
DP Template Method

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. 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. 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. De l’analyse à la conception (3/3)
• Diagramme de classes de conception
• premier jet pour l’itération 1

31. Classes de conception
• Ajout des types non-primitifs (optionnel)

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. 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. 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. Application du DP State (1/4)
• Diagramme de classes de conception « avant »
• Ajout des méthodes dans Plateau et Case

36. Application du DP State (2/4)

37. Application du DP State (3/4)
• Diagramme de classes de conception « après »« !

38. Application du DP State (4/4)
• Le code Java correspondant « après »« !

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. 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. Suite de la dynamique (2/2)
• Appliquons le DP Singleton à la classe Partie

42. Application du DP Singleton
• Le modèle et le code Java correspondant « après »« !

43. Classes de conception
• Le modèle
complété
de
l’itération 1
pourrait
alors
ressembler
à:

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. 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. Nouvelle application du State (2/2)
• Diagramme de classes de conception « après »« !

47. Conclusion

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. 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. Questions?

51. Merci !
N’oubliez pas de remplir le formulaire d’évaluation
Vous pouvez me contacter à …
pascal.roques@valtech.fr