design patterns (2003)

3012Mise en oeuvre des Design

Patterns sur une étude de cas

Pascal RoquesConsultant senior et formateur

Introduction

PrésentationsProgramme

PrésentationsPré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 éditionDe l'analyse des besoins à la conception en Java

UML par la pratiqueCours et exercices Java et C#- 2ème édition

UML - Modéliser un site e-commerceLes Cahiers du Programmeur

Notre programmeNotre programme• 1. Introduction

• 2. Les Design Patterns

• 3. Analyse de l’étude de cas (Together®)

• 4. Application des Design Patterns (Together®)

• 5. Conclusion

Les Design Patterns

Introduction aux DPGoF : State, Singleton, Template Method

De l’analyse à la conceptionApplication à l’étude de cas

Introduction aux « patterns »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

Introduction aux « patterns »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 ? »

Ressources sur les patternsRessources 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).

• …

Modèle de description (1/3)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

Modèle de description (2/3)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 conceptionsque 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é ?


Modèle de description (3/3)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


Les Design Patterns GoFLes Design Patterns GoF


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

Le DP Singleton (2/2)Le DP Singleton (2/2)

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

Le DP Template Method (2/2)Le DP Template Method (2/2)

Le DP State (1/2)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(){if < test 1 >

methodA()else if < test 2 >

methodB()}


methodA()else if < test 2 >

methodB()}


methodC()else if < test 2 >

methodD()}


methodC()else if < test 2 >

methodD()}


methodE()else if < test 2 >

methodF()}


methodE()else if < test 2 >

methodF()}

• Solution : délégation + polymorphisme• Classe abstraite (ou interface) « Etat »

Le DP State (2/2)Le DP State (2/2)

Analyse de l’étude de cas

PrésentationAnalyse des besoinsModèle du domaine

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

L’étude de cas (2/2)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

Analyse des besoins (1/2)Analyse des besoins (1/2)• Diagramme de cas d’utilisation

Joueur

Consulter l'aide en ligne

Jouer au démineurExtension points

ParamétrageHelp

Paramétrer le jeu

<<extend>>

<<extend>>[Paramétrage]

[Help]

Itération 1 : avec paramétrage par défaut, et non prise en compte du marquage « ? »

Analyse des besoins (2/2)Analyse des besoins (2/2)• Diagramme de séquence « système »

Demineur

Joueur

initialiser()

entrerNomHighScores(n)

decouvrirCase(Point)

marquerCase(Point)


etc.

gagné !!

Modèle du domaine (1/2)Modèle du domaine (1/2)• Diagramme de classes du domaine

Modèle du domaine (2/2)Modèle du domaine (2/2)• Diagramme d’états : la classe Case

• Complexité itérative !

Itération 1

Itération ultérieure…

Application des Design Patterns avec Together©

ConceptionDP State

DP SingletonDP Template Method

Architecture logiqueArchitecture 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

De l’analyse à la conception (1/3)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 lesconstructeurs, accesseurs, etc.

De l’analyse à la conception (2/3)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 ??

De l’analyse à la conception (3/3)De l’analyse à la conception (3/3)• Diagramme de classes de conception

• premier jet pour l’itération 1

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

Conception de la dynamique (1/3)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

Joueur

initialiser()

entrerNomHighScores(n)


marquerCase(Point)


etc.

gagné !!

• La complexité se trouve dans les deux opérations :• decouvrirCase(Point)• marquerCase(Point)

Conception de la dynamique (2/3)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…

:Partie

:Plateaules:Case

c:Case

1: marquerCase(Point)

1.1.2: marquer()

1.1.1: c:=get(Point)

1.1: marquerCase(Point)

1.1.2.1: ??

Conception de la dynamique (3/3)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 « ? »)

Application du DP State (1/4)Application du DP State (1/4)• Diagramme de classes de conception « avant »

• Ajout des méthodes dans Plateau et Case

Application du DP State (2/4)Application du DP State (2/4)

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

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

Suite de la dynamique (1/2)Suite de la dynamique (1/2)• Continuons « marquerCase » :

• En fonction de son état, la case effectue des traitements différents

marquer(c : Case)

marquer(c : Case)

:EtatCouverteNonMarquee

c : Case

:EtatDecouverte

<<singleton>>:Partie

2: majCompteur(-1)

1: setEtatCourant(EtatDrapeau)

marquer(c: Case)

:EtatDrapeau

c : Case

<<singleton>>:Partie

2: majCompteur(1)

1:setEtatCourant(EtatCouverteNonMarquee)

Suite de la dynamique (1/2)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 …

Suite de la dynamique (2/2)Suite de la dynamique (2/2)• Appliquons le DP Singleton à la classe Partie

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

Classes de conceptionClasses de conception• Le modèle

complété de l’itération 1 pourrait alors ressembler à :

Développement itératifDé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…

Nouvelle application du State (1/2)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

Nouvelle application du State (2/2)Nouvelle application du State (2/2)• Diagramme de classes de conception « après »« !

Conclusion

Pas de « pattern-alisme » excessif !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é !

Utilisez Together !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 …

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 …

Questions?

Merci !

N’oubliez pas de remplir le formulaire d’évaluation

Vous pouvez me contacter à …[email protected]

design patterns (2003)

Technology