Transcript Pattern Language Pattern Catalogs and Systems

Journées Patterns
Grenoble 3 et 4 avril 2003
Patterns pour le développement logiciel
Langage et systèmes de patterns
Isabelle Borne
Université de Bretagne-Sud
Vannes
Sites Web


http://st-www.cs.uiuc.edu/users/patterns/patterns.html
http://hillside.net/patterns/patterns.html

Portland Pattern Repository
• http://www.c2.com/ppr

Ward Cunnigham's WikiWiki Web
• http://www.c2.com/cgi/wiki?WelcomeVisitors
• http://www.c2.com/cgi/wiki?PatternIndex
I.Borne - UBS
2
Patterns pour le développement logiciel
Analyse
Architecture logicielle
Conception
Anti-patterns
Programmation
Idiomes ou patterns de codage

Les Idiomes sont des patterns de bas niveau spécifiques à
un langage de programmation.

Ils décrivent comment implémenter des aspects particuliers
des composants ou leurs relations, avec les caractéristiques
d’un langage donné.

Langages : C++, Smalltalk, Java
I.Borne - UBS
4
Patterns de conception (Design Patterns)

Abstraction, identification et façon de nommer les aspects
clé d’une structure de conception courante.

Échelle plus petite que les patterns d’architecture, mais
niveau plus élevé que les idiomes spécifiques d’un langage
de programmation.

Organisés en catalogue.
I.Borne - UBS
5
Références :
 Erich Gamma & al (1995) Design Patterns - Elements of
Reusable Object-Oriented Software, Addison-Wesley.

S.R. Alpert, K.Brown, B.Woolf (1998) The Design Patterns
Smalltalk Companion, Addison-Wesley (Software patterns
series).

J.W.Cooper (1998), The Design Patterns Java Companion,
http://www.patterndepot.com/put/8/JavaPatterns.htm.

S.A. Stelting, O.Maasen (2002) Applied Java Patterns, Sun
Microsystems Press.
I.Borne - UBS
6
Catalogue de Design Patterns
class
object
Creational
Structural
Factory Method
Adapter (class)
Behavioral
Interpreter
Template Method
Abstract Factory
Adapter (object)
Chain of Responsibility
Builder
Bridge
Command
Prototype
Composite
Iterator
Singleton
Decorator
Mediator
Facade
Memento
Flyweight
Observer
Proxy
State, Strategy, Visitor
I.Borne - UBS
7
Anti Patterns

Représentent une « leçon apprise »

Erreurs logicielles que les gens font fréquemment.
Deux catégories :
– mauvaise solution à un problème qui a produit une
mauvaise situation.
– comment sortir d’une mauvaise situation et comment
poursuivre à partir de là vers une bonne solution.


Référence : W.J. Brown & al (1998) Anti Patterns - Refactoring
Software, Architectures, and Projects in Crisis, Wiley.
I.Borne - UBS
8
Exemple de schéma pour les anti-patterns

« Background »

Forme générale

Symptômes et conséquences

Causes typiques

Exception connue

Solution « réparée »

Variations

Exemple

Solutions apparentées

Applicabilité à d’autres points de vue ou échelles
I.Borne - UBS
9
Pattern architecturaux

Schémas d’organisation structurelle fondamentaux pour les
logiciels.

Exemples : Pipes and Filters, Broker, MVC, Micro-kernel

Références :
– F.Buschmann & al., Pattern-Oriented Software Architecture, Wiley
1996.
– R.Martin & al., Pattern Language of Program Design 3, AddisonWesley 1998.
I.Borne - UBS
10
Patterns d’analyse

Question de modélisation générale en regardant un
problème particulier dans un domaine.

Martin Fowler a proposé deux catégories de patterns :
– « Analysis patterns »
– « Supporting patterns »

Référence :
Martin Fowler, Analysis Patterns - Reusable Object Models, AddisonWesley, 1997.
I.Borne - UBS
11
Exemples de patterns d’analyse

« Accountability »
– Le concept de comptabilité s’applique quand une
personne ou une organisation est responsable d’une
autre.
– notion abstraite qui peut représenter plusieurs problèmes
spécifiques, comportant des structures, des contrats, et
du personnel.
– Party, organization hierarchies, organization structure
etc.
I.Borne - UBS
12

« Observations and measurement »
– Des quantités peuvent être utilisées en tant qu’attributs
d’objets pour enregistrer de l’information sur eux.
– Ces patterns montrent comment cette approche échoue
et suggère des approches plus sophistiquées.
– Quantity, conversion ratio, compound units,
measurement, observation, protocol, dual time record
etc.
I.Borne - UBS
13

« Referring to Objects »
– Name, Identification scheme, object merge, object
equivalence

« Planning »
– Proposed and Implemented Action, Suspension, Plan,
Resource Allocation etc..

« Trading
– Contract, Portfolio, Quote, Scenario
I.Borne - UBS
14
Exemples de patterns support

« Layered Architecture for Information System »
– Two-tier architecture, Three-tier architecture,
Presentation and Application Logic, Database
interaction

« Application Facades »
– Interface simplifiée à un modèle compliqué.
– Responsable du choix et de l’organisation de
l’information pour une présentation.
I.Borne - UBS
15

« Patterns for Type Model Design Templates »
– comment transformer un modèle de spécification
implicite en un modèle explicite et une implémentation.
– Implementing Associations, Object Creation,
Implementing Constraints ….

« Association patterns »
– Associative Type, Keyed mapping, Historic mapping.
I.Borne - UBS
16
Patterns architecturaux
Langage de pattern
Catalogues et systèmes de patterns
Bibliographie

Software Architecture: Perspectives on an Emerging Discipline,
Prentice-Hall, 1996.

Architectural Styles, Design Patterns, and Objects, R.T.Monroe & al.,
IEEE Software, January 1997, pages 43-52.

Pattern-Oriented Software Architecture - A System of Patterns,
F.Buschmann & al., John Wiley, 1996.

Pattern-Oriented Software Architecture - Patterns for Concurrent and
Networked Objects, volume 2, D.Schmidt & al., John Wiley, 2000.
I.Borne - UBS
18
Architecture logicielle

Architecture logicielle
– Description des sous-systèmes et des composants d’un logiciel et
leurs relations.

Conception logicielle
– Activité effectuée par un développeur logiciel qui produit
l’architecture logicielle d’un système.

Style architectural
– Définit une famille de systèmes en termes de leur organisation
structurelle et sémantique.

Framework
– Logiciel partiellement complet qui a vocation d’être instancié.
I.Borne - UBS
19
Patterns architecturaux

Ils interviennent dans les plus haut niveaux du
développement logiciel.
Ils ont souvent été découverts dans de gros projets.

Ils correspondent à des styles architecturaux classiques :

–
–
–
–
Pipe and filter
Layered systems
Event_based systems
….
I.Borne - UBS
20
Un architecture classique : Pipe and Filter


Chaque composant possède un ensemble de données en entrée et un
ensemble de données en sortie.
Un composant lit un flot de données en entrée et produit un flot de
données en sortie.
Filtre
Pipe
Source :
sortie
I.Borne - UBS
Filtre
Sink :
entrée
21
Schéma de présentation
des patterns d’architecture







nom
exemple
contexte
problème
solution
structure (CRC cards)
dynamique (scénarios)
I.Borne - UBS







implémentation
exemple résolu
variantes
usage connus
conséquences
voir aussi
crédits
22
Pipe & Filter :exemple
Source du programme
Analyse lexicale
Flot de tokens
Analyse syntaxique
Arbre de syntaxe abstrait
Analyse sémantique
Arbre de syntaxe abstrait augmenté
Génération de code
intermédiaire
Programme en code intermédiaire
Optimisation
I.Borne - UBS
23
Pipe & Filter :problème, solution

Le problème : construire des systèmes pour transformer et
calculer des flots de données.

La solution : la tâche globale est naturellement
décomposée en plusieurs étapes de calcul séquentielles.
I.Borne - UBS
24
Class
Filter
 La structure
Collaborators
• Pipe
Responsibility
• Gets input Data.
• Performs a function
on its input data.
• Supplies output data.
Class
Pipe
Responsibility
• Transfers Data.
Collaborators
• Data Source
• Data Sink
• Filter
• Buffers Data.
• Synchronizes active
neighbours.
I.Borne - UBS
25
Class
Collaborators
Data Source
Responsibility • Pipe
• Delivers input to
processing pipeline
Class
Collaborators
Data Sink
Responsibility
• Consumes
• Pipe
output
I.Borne - UBS
26
Langages de Pattern : définitions

Collection structurée de patterns comprenant des règles
pour combiner les patterns dans un style architectural
(structure architecturale récurrente).

Pattern : solution récurrente à un problème donné dans un
contexte

Langage de patterns : ensemble de patterns qui, à tout
niveau d’échelle, collaborent pour résoudre un problème
complexe. Ce problème ne peut pas être résolu par un seul
pattern.
I.Borne - UBS
27
Langages de Pattern : définitions

Les langages de patterns décrivent des frameworks
logiciels ou des familles de systèmes reliés.

Un langage de pattern comprend des règles et des lignes de
conduite qui expliquent comment et quand appliquer ses
patterns.
I.Borne - UBS
28
Origines des langages de pattern


A pattern Language [Alexander 1977]
A Timeless Way of Building [Alexander 1979]
– Chaque pattern dépend à la fois du pattern plus petit qu’il contient
et des patterns plus larges qui le contiennent.
– La structure du langage est créée par le réseau de connexions entre
patterns.
– Un langage de pattern donne à chaque personne qui l’utilise le
pouvoir de créer une variété infinie de constructions nouvelles et
uniques.
I.Borne - UBS
29
Exemples de langages de patterns

Chaque communauté a son propre langage de patterns, qui
augmente et change avec l’expérience.

Un langage de patterns pour la conception d ’interface
utilisateur (Todd Coram et Jim Lee, PloP96 workshop).

Un langage de patterns pour l’écriture de pattern (Gerard
Meszaros, Jim Doble, Pattern Languages of Program
Design 3, Addison-Wesley, 1998).

Crossing Chasms: A pattern Language for Relational
Databases and Smalltalk (Kyle Brown, Pattern Languages of
Program Design 2, Addison-Wesley, 1996).
I.Borne - UBS
30
Un langage de patterns pour la conception
d ’interface utilisateur
Todd Coram et Jim Lee, PloP96 workshop.
http://www.maplefish.com/todd/papers/experiences/Experienc
es.html


Construire des interfaces qui se concentrent sur
l’interaction de l’utilisateur
I.Borne - UBS
31
I.Borne - UBS
32
Meta-pattern : Interaction Style
I.Borne - UBS
33
Explorable Interface
I.Borne - UBS
34
Crossing Chasms: A pattern Language for
Relational Databases and Smalltalk

Kyle Brown, Pattern Languages of Program Design 2, AddisonWesley, 1996, or in Technical Journal, http://www.ksccary.com

Interfacer des bases de données relationnelles et un langage à objets.

Le langage de pattern
– patterns architecturaux
– patterns statiques
– patterns dynamiques
– patterns client-serveur
I.Borne - UBS
35

Patterns architecturaux :
– Four-Layer Architecture (View, application model, domain model
and infrastructure layers)
– Table Design Time (when is the best time to develop your
relational database system ?)
View Layer
Appplication Model Layer
Domain Model Layer
Infrastructure Layer
I.Borne - UBS
36

Patterns statiques :
– Representing objects as tables
– Object Identifier
– Foreign Key reference
– Representing Collections

Patterns dynamiques
– Broker (séparation des parties spécifiques au domaine des parties
spécifiques aux bases de données)
– Object Metadata (réification du mapping)
– Query Object (génération de requêtes SQL)

Patterns Client-Serveur
– Client Synchronization
– Cache Management (améliorer les performances du client)
I.Borne - UBS
37
Catalogues de patterns

Un catalogue de patterns est une collection arbitraire de
patterns qui sont faiblement reliés.

Typiquement il subdivise les patterns en un petit nombre de
catégories et il peut inclure des références croisées entre les
patterns.

Erich Gamma a lancé la présentation sous forme de
catalogues des design patterns dans sa thèse de doctorat
(1992).
I.Borne - UBS
38

Exemples :
– C.Alexander : A pattern Language (1977) 253 patterns
– GoF (1995) 23 design patterns
– Buschmann & al (1996) : 25 patterns architecturaux et de
conception
– M.Fowler (1997) : patterns d ’analyse et patterns de support.

Un langage de pattern est une collection de patterns où
chaque pattern est construit par rapport aux autres et
représente une série de décisions.

Un catalogue de patterns est une collection arbitraire où les
patterns existent par eux-mêmes.
I.Borne - UBS
39
Les systèmes de patterns


Ensemble cohésif de patterns.
Les patterns contribuent à la construction et à l’évolution
d’architectures au complet.

Il est organisé entre groupes et sous-groupes de patterns reliés
à plusieurs niveaux de granularité.

Il décrit les relations entre les patterns et leurs regroupements,
et la façon dont ils peuvent être combinés et composés pour
résoudre des problèmes plus complexes.
I.Borne - UBS
40
Langage de patterns, système de
patterns, catalogue de patterns

Système de pattern
– ensemble cohésif
– relations
regroupements
– sujet large

Catalogue
– structuration
– organisation
I.Borne - UBS

Langage de pattern
– collection structurée
– règles de combinaison
– style architectural
– sujet unique
– méga-pattern
41
Les systèmes de patterns pour
l’architecture logicielle

Un système de pattern pour l ’architecture logicielle est :
– une collection de patterns pour l ’architecture logicielle,
– plus des lignes de conduite pour leur implémentation,
leur combinaison et leur utilisation pratique dans le
développement de logiciels.
I.Borne - UBS
42

Spécifications (Buschmann)
– Il doit comporter une base suffisante de patterns.
– Il doit décrire tous les patterns de façon uniforme.
– Il doit montrer les diverses relations entre les patterns.
– Il doit avoir une organisation de ses patterns.
– Il doit supporter la construction de logiciels.
– Il doit supporter sa propre évolution.
I.Borne - UBS
43
critères de classification :
1) catégories de pattern : patterns architecturaux, patterns de conception et idiomes
2) catégories de problème.
Achitectural
Patterns
Design Patterns
Idioms
From Mud to
Structure
Layers
Pipe and Filters
Blackboard
Distributed
Broker
Systems
Pipes and Filters
Microkernel
Interactive Systems MVC
PAC
Adaptable Systems Microkernel
Reflection
I.Borne - UBS
44
Achitectural Design Patterns
Patterns
Structural
Decomposition
Organization of
Work
Management
Access Control
Communication
Resource
Handling
I.Borne - UBS
Idioms
Whole-part
Master-Slave
Command Processor
View Handler
Proxy
Publisher-Subscriber
Forwarder-Receiver
Client-Dispatcher-Server
Counted Pointer
45
Model-View-Controller

Le pattern architectural « Model-View-Controller » divise une
application interactive en trois composants.

Le « modèle »contient les fonctionnalités de base et les données .

Les « vues » affichent les informations à l’utilisateur.

Les « contrôleurs » gèrent les entrées de l’utilisateur.

Un mécanisme de propagation des changements assure la cohérence
entre l’interface utilisateur (view + controller) et le modèle.
I.Borne - UBS
46
Exemple






Considérons un système d’information pour des élections politiques
avec une représentation proportionnelle.
On a un tableur pour entrer les données et plusieurs sortes de tableau et
de graphe représentent les résultats courants.
Les utilisateurs peuvent intervenir avec le système via une interface
graphique.
Tous les affichages d’information doivent immédiatement refléter les
changements des données du vote.
Il doit être possible d ’ajouter de nouveaux moyens de représentation,
par exemple l’affectation des sièges de parlementaires.
Le système doit aussi être portable sur d ’autres plates-formes ou
d ’autres standards d’affichage « look and feel ».
I.Borne - UBS
47
Contexte
Applications interactives avec une interface homme-machine flexible.
Problème

Quand vous étendez les fonctionnalités d ’une application, vous devez modifier
les menus pour accéder à ces nouvelles fonctions. Les clients peuvent vouloir
des adaptations spécifiques etc ...

Les forces qui influencent la solution :
– La même information est présentée différemment dans différentes fenêtres.
– L ’affichage et le comportement de l’application doivent refléter
immédiatement les manipulations de données.
– Les changements de l’interface utilisateur doivent être faciles, et même
possibles lors de l’exécution.
– Le support de différents standards de « look and feel » ou le portage de
l ’interface utilisateur ne doit pas affecter le code dans le noyau de base de
l ’application.
I.Borne - UBS
48
Solution
 MVC divise une application interactive en processus, sortie et entrée.
 Model
– Le composant modèle encapsule les données et les fonctionnalités du
noyau de base.

Views
– les composants vue affichent l’information à l ’utilisateur. Une vue obtient
les données du modèle.
– Chaque vue possède un composant contrôleur associé.

Controllers
– Les contrôleurs reçoivent les entrées, comme des événements qui
encodent les mouvements de la souris, l’activation des boutons de la
souris ou les entrées au clavier.
– Les événements sont traduits en des requêtes de service pour le modèle ou
la vue.
– L ’utilisateur interagit avec le système seulement via les contrôleurs.
I.Borne - UBS
49

Le mécanisme de propagation des changements est décrit par le
pattern Publisher-Subscriber appelé aussi le pattern Observer.
I.Borne - UBS
50
Structure
Class
Model
Responsibility
• Fournit les fonctionnalités
Collaborators
• View
• Controller
de l’application
• Enregistre les vues
dépendantes et les contrôleurs
• Avertit les composants
dépendants des changements
de données
I.Borne - UBS
51
Class
View
Responsibility
• Crée et initialise son
Collaborators
• Controller
• Model
contrôleur associé
• Affiche l’information
pour l’utilisateur
• Implémente les procédures
de mise à jour
• Recherche les données dans
le modèle
I.Borne - UBS
52
Class
Collaborators
Controller
• View
Responsibility
• Accepte les entrées de
• Model
l’utilisateur comme des
événements
• Traduit les événements en
requêtes de service pour le
modèle ou affiche les
requêtes pour la vue.
• Implémente les procédures
de mise à jour si nécessaire
I.Borne - UBS
53
Observer
update
call update
Model
coreData
setOfObservers
attach(Oberver)
detach(Observer)
notify
getData
service
I.Borne - UBS
attach
getData
View
myModel
myController
initialize(Model)
makeController
activate
display
update
create
Controller
manipulate
display myModel
myView
attach initialize(Model,View)
call service
handleEvent
update
54
Implémentation

étape 1: Séparer l’interaction homme-machine du noyau fonctionnel.

étape 2: Implémenter le mécanisme de propagation de changements.

étape 3: Concevoir et implémenter les vues.

étape 4: Concevoir et implémenter les contrôleurs.

étape 5: Concevoir et implémenter la relation vue-contrôleur.

étape 6: Implémenter l’initialisation du MVC.

Etape 7: Interaction dynamique des vues.

étape 8: contrôleurs enfichables (pluggable).

étape 9: Infrastructure pour les vues et les contrôleurs hiérarchiques.

étape 10: Découpler encore plus les dépendances du système.
I.Borne - UBS
55