Journ

1
Journées Patterns Grenoble 3 et 4 avril
2003Patterns pour le développement
logicielLangage et systèmes de patterns

• Isabelle Borne
• Université de Bretagne-Sud
• Vannes

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

3
Patterns pour le développement logiciel
Analyse Conception Programmation
Architecture logicielle Anti-patterns
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 dun langage donné.
• Langages C, Smalltalk, Java

5
Patterns de conception (Design Patterns)

• Abstraction, identification et façon de nommer
  les aspects clé dune structure de conception
  courante.
• Échelle plus petite que les patterns
  darchitecture, mais niveau plus élevé que les
  idiomes spécifiques dun langage de
  programmation.
• Organisés en catalogue.

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/JavaP
  atterns.htm.
• S.A. Stelting, O.Maasen (2002) Applied Java
  Patterns, Sun Microsystems Press.

7
Catalogue de Design Patterns
Creational Structural Behavioral
Interpreter Template Method
Factory Method
Adapter (class)
class
Abstract Factory Adapter (object)
Chain of Responsibility Builder Bridge
Command Prototype Composite
Iterator Singleton Decorator
Mediator Facade Memento
Flyweight Observer Proxy
State, Strategy, Visitor
object
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 dune 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.

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é à dautres points de vue ou échelles

10
Pattern architecturaux

• Schémas dorganisation 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.

11
Patterns danalyse

• 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.

12
Exemples de patterns danalyse

•  Accountability 
• Le concept de comptabilité sapplique quand une
  personne ou une organisation est responsable
  dune 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.

13

•  Observations and measurement 
• Des quantités peuvent être utilisées en tant
  quattributs dobjets pour enregistrer de
  linformation 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.

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

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 lorganisation de
  linformation pour une présentation.

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.

17
Patterns architecturaux Langage de pattern
Catalogues et systèmes de patterns
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.

19
Architecture logicielle

• Architecture logicielle
• Description des sous-systèmes et des composants
  dun logiciel et leurs relations.
• Conception logicielle
• Activité effectuée par un développeur logiciel
  qui produit larchitecture logicielle dun
  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é.

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
• .

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
Filtre
Pipe


Source sortie
Sink entrée
22
Schéma de présentation des patterns
darchitecture

• 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

23
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
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.

25

• Class
• Filter
• Responsibility
• Gets input Data.
• Performs a function
• on its input data.
• Supplies output data.

• Collaborators
• Pipe

• La structure

• Class
• Pipe
• Responsibility
• Transfers Data.
• Buffers Data.
• Synchronizes active neighbours.

• Collaborators
• Data Source
• Data Sink
• Filter

26

• Class
• Data Source
• Responsibility
• Delivers input to processing pipeline

• Collaborators
• Pipe

• Class
• Data Sink
• Responsibility
• Consumes output

• Collaborators
• Pipe

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.

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.

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 quil 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
  lutilise le pouvoir de créer une variété infinie
  de constructions nouvelles et uniques.

30
Exemples de langages de patterns

• Chaque communauté a son propre langage de
  patterns, qui augmente et change avec
  lexpé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).

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/E
  xperiences.html
• Construire des interfaces qui se concentrent sur
  linteraction de lutilisateur

32
(No Transcript)
33
Meta-pattern Interaction Style
34
Explorable Interface
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

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
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)

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).

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.

40
Les systèmes de patterns

• Ensemble cohésif de patterns.
• Les patterns contribuent à la construction et à
  lévolution darchitectures 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.

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

42
Les systèmes de patterns pour larchitecture
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.

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.

44
critères de classification 1) catégories de
pattern patterns architecturaux, patterns de
conception et idiomes 2) catégories de problème.
45
(No Transcript)
46
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 à
  lutilisateur.
• Les  contrôleurs  gèrent les entrées de
  lutilisateur.
• Un mécanisme de propagation des changements
  assure la cohérence entre linterface utilisateur
  (view controller) et le modèle.

47
Exemple

• Considérons un système dinformation 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 dinformation 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
  laffectation des sièges de parlementaires.
• Le système doit aussi être portable sur d autres
  plates-formes ou d autres standards daffichage
   look and feel .

48

• 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 lapplication
  doivent refléter immédiatement les manipulations
  de données.
• Les changements de linterface utilisateur
  doivent être faciles, et même possibles lors de
  lexé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.

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 linformation à
  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, lactivation 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.

50

• Le mécanisme de propagation des changements est
  décrit par le pattern Publisher-Subscriber
  appelé aussi le pattern Observer.

51
Structure

• Class
• Model
• Responsibility
• Fournit les fonctionnalités
• de lapplication
• Enregistre les vues
• dépendantes et les contrôleurs
• Avertit les composants
• dépendants des changements
• de données

• Collaborators
• View
• Controller

52

• Class
• View
• Responsibility
• Crée et initialise son
• contrôleur associé
• Affiche linformation
• pour lutilisateur
• Implémente les procédures
• de mise à jour
• Recherche les données dans
• le modèle

• Collaborators
• Controller
• Model

53

• Class
• Controller
• Responsibility
• Accepte les entrées de
• lutilisateur 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

54
Observer
update
call update
Model
coreData setOfObservers attach(Oberver) detach(Obs
erver) notify getData service
View
attach getData
myModel myController
initialize(Model) makeController activate display
update
create
Controller
manipulate display
myModel myView
attach call service
initialize(Model,View) handleEvent update
55
Implémentation

• étape 1 Séparer linteraction 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 linitialisation 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.