3012 Mise en oeuvre des Design Patterns sur une étude de cas Pascal Roques Consultant senior et formateur
Introduction
Présentations Programme
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 De l'analyse des besoins à la conception en Java
UML par la pratique
Cours et exercices Java et C# - 2ème édition
UML - Modéliser un site e-commerce Les Cahiers du Programmeur
Notre 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 DP GoF : State, Singleton, Template Method De l’analyse à la conception Application à l’étude de cas
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 » • 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 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) • 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) • 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
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
Les Design Patterns GoF
source : Design Patterns – Elements of Reusable Object-Oriented Software
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 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 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 public void void m1(){ m1(){ ifif << test test 11 >> methodA() methodA() else else ifif << test test 22 >> methodB() methodB() }}
public public void void m2(){ m2(){ ifif << test test 11 >> methodC() methodC() else else ifif << test test 22 >> methodD() methodD() }}
• Solution : délégation + polymorphisme •
Classe abstraite (ou interface) « Etat »
public public void void m3(){ m3(){ ifif << test test 11 >> methodE() methodE() else else ifif << test test 22 >> methodF() methodF() }}
Le DP State (2/2)
Analyse de l’étude de cas
Présentation Analyse des besoins Modèle du domaine
L’étude de cas (1/2) • Le jeu du Démineur …
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) • Diagramme de cas d’utilisation Paramétrer le jeu <
> [Paramétrage]
Joueur
Jouer au démineur Extension points Paramétrage Help <> [Help] Consulter l'aide en ligne
Itération 1 : avec paramétrage par défaut, et non prise en compte du marquage « ? »
Analyse des besoins (2/2) • Diagramme de séquence « système » Demineur Joueur initialiser()
decouvrirCase(Point) marquerCase(Point)
etc.
decouvrirCase(Point) gagné !! entrerNomHighScores(n)
Modèle du domaine (1/2) • Diagramme de classes du domaine
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©
Conception DP State DP Singleton DP Template Method
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
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.
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) • Diagramme de classes de conception •
premier jet pour l’itération 1
Classes de conception • Ajout des types non-primitifs (optionnel)
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() decouvrirCase(Point) marquerCase(Point)
etc.
decouvrirCase(Point) gagné !! entrerNomHighScores(n)
• La complexité se
trouve dans les deux opérations : • •
decouvrirCase(Point) marquerCase(Point)
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)
:Plateau
les:Case
1.1.1: c:=get(Point)
1.1.2: marquer()
1.1.2.1: ?? c:Case
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) • Diagramme de classes de conception « avant » •
Ajout des méthodes dans Plateau et Case
Application du DP State (2/4)
Application du DP State (3/4) • Diagramme de classes de conception « après »« !
Application du DP State (4/4) • Le code Java correspondant « après »« !
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)Î
:EtatDecouverte
:EtatCouverteNonMarquee
2: majCompteur(-1)Î
<>
:Partie
1: setEtatCourant(EtatDrapeau) Ð
c : Case
marquer(c: Case)Î :EtatDrapeau
2: majCompteur(1)Î
1: setEtatCourant(EtatCouverteNonMarquee)Ð
c : Case
<>
:Partie
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) • Appliquons le DP Singleton à la classe Partie
Application du DP Singleton • Le modèle et le code Java correspondant « après »« !
Classes de conception • Le modèle
complété de l’itération 1 pourrait alors ressembler à:
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…
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) • Diagramme de classes de conception « après »« !
Conclusion
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 !
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]
