Journées Patterns Grenoble 3 et 4 avril 2003 Patterns pour le développement logiciel Langage et...
-
Upload
abelard-chabert -
Category
Documents
-
view
108 -
download
0
Transcript of Journées Patterns Grenoble 3 et 4 avril 2003 Patterns pour le développement logiciel Langage et...
Journées Patterns Grenoble 3 et 4 avril 2003
Patterns pour le développement logicielLangage et systèmes de patterns
Isabelle Borne
Université de Bretagne-Sud
Vannes
I.Borne - UBS 2
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
Patterns pour le développement logiciel
Analyse
Conception
Programmation
Architecture logicielle
Anti-patterns
I.Borne - UBS 4
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 5
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 6
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 7
Catalogue de Design Patterns
Creational Structural Behavioral
Factory Method Adapter (class)Interpreter
Template Methodclass
objectAbstract 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 8
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 9
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 10
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, Addison-Wesley 1998.
I.Borne - UBS 11
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, Addison-Wesley, 1997.
I.Borne - UBS 12
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 13
« 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 14
« 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 15
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 16
« 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.
Patterns architecturaux
Langage de pattern
Catalogues et systèmes de patterns
I.Borne - UBS 18
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 19
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 20
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 21
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
FiltrePipe
Source :sortie
Sink :entrée
I.Borne - UBS 22
Schéma de présentation des patterns d’architecture
nom exemple contexte problème solution structure (CRC cards) dynamique (scénarios)
implémentation exemple résolu variantes usage connus conséquences voir aussi crédits
I.Borne - UBS 23
Pipe & Filter :exemple
Analyse syntaxique
Analyse sémantique
Génération de code intermédiaire
Optimisation
Analyse lexicale
Source du programme
Flot de tokens
Arbre de syntaxe abstrait
Arbre de syntaxe abstrait augmenté
Programme en code intermédiaire
I.Borne - UBS 24
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 25
Class Pipe
Responsibility• Transfers Data.• Buffers Data.• Synchronizes active neighbours.
Collaborators
• Data Source• Data Sink• Filter
Class Filter
Responsibility• Gets input Data.• Performs a function on its input data.• Supplies output data.
Collaborators
• Pipe La structure
I.Borne - UBS 26
Class Data SourceResponsibility• Delivers input to processing pipeline
Collaborators
• Pipe
Class Data SinkResponsibility• Consumes output
Collaborators
• Pipe
I.Borne - UBS 27
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 28
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 29
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 30
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 31
Un langage de patterns pour la conception d ’interface utilisateur
Todd Coram et Jim Lee, PloP96 workshop.
http://www.maplefish.com/todd/papers/experiences/Experiences.html
Construire des interfaces qui se concentrent sur l’interaction de l’utilisateur
I.Borne - UBS 32
I.Borne - UBS 33
Meta-pattern : Interaction Style
I.Borne - UBS 34
Explorable Interface
I.Borne - UBS 35
Crossing Chasms: A pattern Language for Relational Databases and Smalltalk
Kyle Brown, Pattern Languages of Program Design 2, Addison-Wesley, 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 36
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 37
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 38
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 39
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 40
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 41
Langage de patterns, système de patterns, catalogue de patterns
Système de pattern
– ensemble cohésif
– relations regroupements
– sujet large
Catalogue
– structuration
– organisation
Langage de pattern
– collection structurée
– règles de combinaison
– style architectural
– sujet unique
– méga-pattern
I.Borne - UBS 42
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 43
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 44
AchitecturalPatterns
Design Patterns Idioms
From Mud toStructure
LayersPipe and FiltersBlackboard
DistributedSystems
BrokerPipes and FiltersMicrokernel
Interactive Systems MVCPAC
Adaptable Systems MicrokernelReflection
critères de classification : 1) catégories de pattern : patterns architecturaux, patterns de conception et idiomes 2) catégories de problème.
I.Borne - UBS 45
AchitecturalPatterns
Design Patterns Idioms
StructuralDecomposition
Whole-part
Organization ofWork
Master-Slave
Management Command ProcessorView Handler
Access Control Proxy
Communication Publisher-SubscriberForwarder-ReceiverClient-Dispatcher-Server
ResourceHandling
Counted Pointer
I.Borne - UBS 46
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.
Model-View-Controller
I.Borne - UBS 47
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 48
ContexteApplications 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 49
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 50
Le mécanisme de propagation des changements est décrit par le pattern Publisher-Subscriber appelé aussi le pattern Observer.
I.Borne - UBS 51
Structure
Class Model
Responsibility• Fournit les fonctionnalités de l’application• Enregistre les vues dépendantes et les contrôleurs• Avertit les composants dépendants des changements de données
Collaborators
• View• Controller
I.Borne - UBS 52
Class View
Responsibility• Crée et initialise son 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
Collaborators
• Controller• Model
I.Borne - UBS 53
Class Controller
Responsibility• Accepte les entrées de 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
Collaborators
• View• Model
I.Borne - UBS 54
Observer
update
Model
coreDatasetOfObservers
attach(Oberver)detach(Observer)notify
getDataservice
View
Controller
myModelmyController
initialize(Model)makeControlleractivatedisplayupdate
myModelmyView
initialize(Model,View)handleEventupdate
attachgetData
call update
attachcall service
create
manipulate display
I.Borne - UBS 55
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.