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é)
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
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 »
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)
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
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
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
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 …