Analyse, Conception Sommaire

Objet
9Conception
¾Réutilisabilité
Design Patterns ¾Bibliothèque de classe vs. Framework
Introduction ¾Design Pattern
¾Historique
¾Catégories de Patterns
¾Bibliographie
O. Boissier, SMA/G2I/ENS Mines Saint-Etienne, Olivier.Boissier@emse.fr, Avril 2004
1 2

Conception Deux questions sur la

conception de modules
¾ Face à des problèmes complexes, rechercher la
modularité afin d’obtenir un ensemble de modules ¾ Cohésion : degré avec ¾ Couplage : force de
plus simples et plus facilement gérables. lequel les tâches l’interaction entre les
¾ Dans le monde des objets, la notion de ‘‘modules’’ réalisées par un seul modules dans le système
se décline en : module sont ¾ Comment est-ce que les
¾Classes
fonctionnellement reliées modules travaillent
¾ Quel est le liant d ’un ensemble ?
¾ abstractions des données et des services
module ? ¾ Qu’ont-ils besoins de
¾Méthodes connaître l ’’un sur l ’autre
¾ Implémentation des services ¾ Quel est son objectif ?
?
¾Packages / sous-systèmes ¾ Fait-il une ou plusieurs
choses ? ¾ Quand font-ils appel aux
¾ Groupement de classes dans une seule collection fonctionnalités de chacun ?
¾Processus physiques (client/serveur, …) ¾ Quel est sa fonction ?
3 4
 Cohésion et Couplage
9 Cohésion (relations logiques
entre items d ’un objet)
9 Etendue de la responsabilité d ’un
module (une seule/plusieurs)
9 Informelle (définie en terme
d ’objectif)
9 Une forte cohésion est une bonne
qualité
9 Couplage(force des relations
physiques entre items d ’un
objet)
9 Dépendance entre les modules
9 Peut-être définie formellement
9 Un couplage ‘‘lâche’’ est une
bonne qualité
Cohésion
‘‘bon’’ exemple
Class GameBoard {
public GamePiece[ ][ ] getState()
--
public Player isWinner()
--
public boolean isTie()
--
} void initArray(int[ ] iGradeArray) {
class BoardDisplay {
public void displayBoard (GameBoard gb)
- affichage du contenu du jeu. Espaces blanc affichés pour
chacune des références nulles.
} de l ’attribut length
Cohésion
‘‘mauvais’’ exemple
Class GameBoard {
public GamePiece[ ][ ] getState()
Couplage - Méthode copiant la grille dans un tableau temporaire, résultat
entre de l ’appel de la méthode.
public Player isWinner()
modules
- vérifie l’état du jeu pour savoir s ’il existe un gagnant, dont
la référence est retournée. Null est retourné si aucun gagnant.
public boolean isTie()
- retourne true si aucun déplacement ne peut être effectué,
false sinon.
public void display ()
- affichage du contenu du jeu. Espaces blanc affichés pour
chacune des références nulles.
Cohésion entre
modules GameBoard est responsable des règles du jeu et de l ’affichage.
5 } 6
Couplage
Exemple
void initArray(int[ ] iGradeArray, int nStudents) {
int i;
for (i=0; i < nStudents; i++) {
Couplage entre client
iGradeArray[i] = 0;
} et initArray par le
2nd paramètre
int i;
for (i=0; i < iGradeArray.length; i++) {
iGradeArray[i] = 0;
} Couplage faible
(et meilleure fiabilité)
au travers de l ’utilisation
7 8
 Couplage Couplage
Nœuds d’une classe Booklist Nœuds d’une classe Booklist
class BookNode { next class BookNode {

private String title; title private Book book;

private BookNode next; private BookNode next; book
title author

public BookNode (String public void setNext (BookNode public BookNode (String title, class Book
newTitle) { nextBook) { String author) {
title = newTitle; next = nextBook; book = new Book(title, author); private String title;
next = null; } next = null; private String author;
} }
public void print () { public Book(String title,
public BookNode getNext () { ...
System.out.println (title); String auth) {
return (next);
} ...
} }
}
Que se passe-t-il }//class BookNode
}//class Book
si nous ajoutons Author ? 9 10

Principes de conception (1) Exemple

Tri d’étudiants (1) : ‘‘mauvais’’
¾ Programmer une interface plus qu’une implémentation, class StudentRecord {
¾ Utiliser des classes abstraites (interfaces en Java) pour private Name lastName;
définir des interfaces communes à un ensemble de classes, private Name firstName;
private long ID;
¾ Déclarer les paramètres comme instances de la classe
abstraite plutôt que comme instances de classes public Name getLastName() {return lastName;}
particulières. … // etc
}
Ainsi : class SortedList {
¾ les classes clients ou les objets sont indépendants des Object[] sortedData = new Object[size];
classes des objets qu’ils utilisent aussi longtemps que les public void add(StudentRecord X) {
objets respectent l ’interface qu’ils attendent, // …
Name a = X.getLastName();
¾ les classes clients ou les objets sont indépendants des
Name b = sortedData[k].getLastName();
classes qui implémentent l ’interface.
if (a.lessThan(b)) … else … //do something
11 }…} 12
Exemple Exemple
Tri d’étudiants (2) : ‘‘solution 1’’ Tri d’étudiants (3) : ‘‘solution 2’’
class StudentRecord { Interface Comparable {
private Name lastName; public boolean lessThan(Object X);
private Name firstName;
public boolean greaterThan(Object X);
private long ID;
public boolean lessThan(Object X) { public boolean equal(Object X);
return lastName.lessThan(X.lastName);} }
… // etc
} class StudentRecord implements Comparable {
class SortedList { private Name lastName;
Object[] sortedData = new Object[size]; private Name firstName;
public void add(StudentRecord X) { private long ID;
// … public boolean lessThan(Object X) {
if (X.lessThan(sortedData[k])) … else … //do something return lastName.lessThan(((StudentRecord)X).lastName);}
… // etc
}…}
}

13 14

Exemple Principes de conception (2)

Tri d’étudiants (4) : ‘‘solution 2’’
¾ Préférer la composition d’objet à l’héritage de
class SortedList { classes
Object[] sortedData = new Object[size];
public void add(Comparable X) {
// …
Ainsi :
if (X.lessThan(sortedData[k])) … else … //do something ¾ le comportement peut changer en cours
} d ’exécution,
…
} ¾ les classes sont plus focalisées sur une tâche,
¾ réduction des dépendances d ’implémentation.

15 16
 Sommaire Réutilisation en Génie Logiciel
Expression
des besoins
Spécifications
• Conception Analyse
Informelles Patrons d’analyse
(abstraction du
Modèles de domaine
9Réutilisabilité monde réel) Modèle Composants métiers conceptuels
Descriptif &
¾Bibliothèque de classe vs. Framework Normatif
Conception Informatisable Patrons d’architecture
¾Design Pattern (solution
Patrons de conception
technique)
Modèle ERP, Frameworks
¾Historique Effectif
Informatisé
¾Catégories de Patterns Implantation
(solution
Patrons d’implantation
Composants métiers logiciels
opérationnelle) Bibliothèques de classes
¾Bibliographie Logiciel

17 18

Réutilisation en Génie Logiciel Bibliothèque de classe

Analyse Conception Implantation Documentation
«métier commun» «architecture» « idiome »
«métier spécifique» «conception»
- technique de
¾Ensemble de classes
- Le problème traité - identifier, nommer - comment
est issu d’une et abstraire des implanter dans un
langage particulier
dialogue, de
documentation,
¾le plus souvent abstraites
analyse de domaine thèmes récurrents
- Aide à la
de la conception certains traits
absents de ce
d’enseignement
, etc.
¾indépendantes (pas d ’interaction a priori entre
par objet.
construction de
modèles objets - Aide à la
langage elles) Collections Base de
descriptifs construction de
¾sans comportements Données
modèles objets
effectifs par défaut Réseaux
Math
Gestion des ressources Composite Simuler l’héritage Documenter un Application
Opérations Bancaires Observateur multiple en Java framework
Blackboard
IHM
Flux de contrôle
19 Architecture Bibliothèque de classes 20
 Framework = squelette Framework = squelette
d’application d’application (suite)
¾Ensemble de classes : ¾ Application framework : encapsultation d ’une
¾concrètes ou abstraites conçues pour être expertise applicable à une large variété de
utilisées ensemble, programmes,
Collections Math
¾en interaction, ¾ Domain framework : encapsulation d ’une
expertise dans un domaine de problèmes
¾fournissant des
Application
particulier
comportements par
défaut ¾ Support framework : services de niveau système
IHM
Base de (accès fichier, application répartie, …)
Réseaux Flux de Données
contrôle
21 22
Architecture de Framework

Framework = squelette
Sommaire
d’application (suite)
¾ Boîte blanche ou en verre : • Conception
¾ fondé sur l ’héritage, • Réutilisabilité
¾ conçu par la généralisation de classes de différentes
• Bibliothèque de classe vs. Framework
applications,
¾ utilisé par dérivation de classes 9Design Pattern
¾ Boîte noire : ¾Historique
¾ fondé sur la composition,
¾Catégories de Patterns
¾ utilisé par composition des composants entre eux.
¾Bibliographie
23 24
 Autres domaines : Architecture
C. Alexander : 253 patrons de conception architecturaux (64,77,79)
« Pattern #112 d’Alexander»
x Nom : Transition d’entrée
x Quoi : créer une transition du monde extérieur vers un univers intérieur, plus privé
x Pourquoi : L’entrée dans un bâtiment influence la façon dont on va se sentir à
l’intérieur
x Quand : systèmes d’accès et d’entrée pour les maisons, les cliniques, les magasins, etc.
x Comment : Créer un espace de transition entre la rue et la porte d’entrée. Marquer le
cheminement dans l’espace de transition par un changement de lumière, un changement
de direction, etc.
x Patterns en relation : vue Zen (#134), etc.
tiré de «Introduction aux patterns» Jean Bézivin
25
Définition
Un patron décrit à la fois un problème qui se produit très
fréquemment dans votre environnement et l’architecture de la
solution à ce problème de telle façon que vous puissiez
utiliser cette solution des milliers de fois sans jamais
l’adapter deux fois de la même manière.
C. Alexander
Décrire avec succès des types de solutions récurrentes
à des problèmes communs dans des types de situations
27
Autres domaines : l’hydraulique
Ken Asplund en 1973
« Le volume d’eau en aval » (Downstream Water Volume )
Problème : Quand on détourne une partie des eaux d’une rivière, le volume d’eau dans
le drainage décroît, ce qui conduit à un affaiblissement des contributions de la rivière.
Contraintes : Il ne faut pas que le détournement d’une partie de la rivière pénalise
l’irrigation des cultures en aval ; la population ne doit pas souffrir de cette baisse du débit
des eaux ; l’impact écologique doit être limité au minimum.
Solution : Il faut maintenir le niveau des eaux en aval en ramenant un maximum d’eau
détournée vers son lit d’origine ; en traitant les eaux usées afin de les réintroduire en
aval ; en économisant les eaux d’irrigation en évitant les systèmes de pulvérisation ou de
brumisation.
26
Design Pattern
xCoad [Coad92]
Une abstraction d’un doublet, triplet ou d’un ensemble de classes qui
peut être réutilisé encore et encore pour le développement d’applications
xAppleton [Appleton97]
Une règle tripartite exprimant une relation entre un certain contexte, un
certain problème qui apparaît répétitivement dans ce contexte et une certaine
configuration logicielle qui permet la résolution de ce problème.
xAarsten [Aarsten96]
Un groupe d’objets coopérants liés par des relations et des règles qui
expriment les liens entre un contexte, un problème de conception et sa
solution.
Les patrons sont des composants logiques décrits indépendamment d’un
langage donné (solution exprimée par des modèles semi-formels)
28
 Design Patterns /
Design Pattern (suite)
Frameworks
¾ Documentation d ’une expérience éprouvée de
conception ¾ Synergie entre ces deux concepts
¾ Identification et spécification d ’abstractions qui ¾ les design patterns décrivent à un niveau plus
sont au dessus du niveau des simples classes, abstrait des composants de frameworks,
instances
implémentés dans un langage particulier,
¾ Vocabulaire commun et aide à la compréhension
de principes de conception, ¾ les design patterns aident à la conception des
frameworks,
¾ Moyen de documentation de logiciels
¾ Aide à la construction de logiciels répondant à des ¾ la conception de frameworks aident à la
propriétés précises, de logiciels complexes et découverte de nouveaux design patterns.
hétérogènes
29 30

Présentation d’un pattern Sommaire

¾ Nom du pattern
¾ utilisé pour décrire le pattern, ses solutions et les conséquences en • Conception
un mot ou deux
¾ Problème • Réutilisabilité
¾ description des conditions d ’applications. Explication du problème
et de son contexte.
• Bibliothèque de classe vs. Framework
¾ Solution • Design Pattern
¾ description des éléments (objets, relations, responsabilités,
collaboration) permettant de concevoir la solution au problème ; 9Historique
utilisation de diagrammes de classes, de séquences, …
vision statique ET dynamique de la solution ¾Catégories de Patterns
¾ Conséquences
¾ description des résultats (effets induits) de l ’application du pattern ¾Bibliographie
sur le système (effets positifs ET négatifs)
31 32
 Historique Sommaire
OOPSLA 87
Beck et Cunnimghan

OOPSLA 91, OOPSLA 92

Design Patterns : Element of Reusable
Object-Oriented Software
• Conception
Gamma et al. (GoF) Gamma 95
• Réutilisabilité
PLoP 94
Montibello • Bibliothèque de classe vs. Framework
• Object Models: Strategies, Patterns and Applications
EuroPLoP 96
• Design Pattern
Coad 95
• Patterns Languages of Program Design
Coplien et Schmidt 95
Kloster
• Historique
Pattern-Oriented Software Architecture: A System of Patterns. ChiliPLoP 98
9Catégories de Patterns
Buschmann 96 Wickenburg
Analysis Patterns : Reusable Object Model ¾Bibliographie
Fowler 97

33 34

Catégories de Design
Catégories de Patterns
Patterns
¾ Architectural Patterns : ¾ Création
¾ schémas d ’organisation structurelle de logiciels (pipes, filters, ¾ description de la manière dont un objet ou un ensemble d ’objets
brokers, blackboard, MVC, …) peuvent être créés, initialisés, et configurés : isoler le code relatif à
¾ Design Patterns : la création, l ’initialisation afin de rendre l ’application indépendante
de ces aspects.
¾ caractéristiques clés d ’une structure de conception commune à
plusieurs applications, ¾ Structure
¾ de portée plus limitée que les architectural patterns ¾ description de la manière dont doivent être connectés des objets de
¾ Idioms ou coding patterns l ’application afin de rendre ces connections indépendantes des
évolutions futures de l ’application : découplage de l ’interface et de
¾ solution liée à un langage particulier l ’implémentation de classes et d ’objets
¾ Anti-patterns : ¾ Comportement
¾ mauvaise solution ou comment sortir d ’une mauvaise solution ¾ description de comportements d ’interaction entre objets : gestion
¾ Organizational patterns : des interactions dynamiques entre des classes et des objets.
¾ organisation de tout ce qui entoure le développement d ’un logiciel
(humains)
35 36
 Vue d’ensemble des Design
Portée des Design Patterns
Patterns
but
Création Structure Comportement
¾Portée Classes Portée Classe Factory method Adapter Interpreter

¾Focalisation sur les relations entre classes Template Method

Objet Abstract Factory Adapter Chain of responsibility
et leurs sous-classes Builder Bridge Command
¾Réutilisation par héritage Prototype Composite Iterator
Singleton Decorator Mediator
¾Portée Objets Facade Memento
¾Focalisation sur les relations entre les Flyweight Observer

objets Proxy State

Strategy
¾Réutilisation par composition Visitor
37 38

Design Patterns de création Design Patterns de structure

¾ Abstract Factory : interface pour la création de familles
d’objets sans spécifier les classe concrètes.
¾ Builder :séparation de la construction d’objets complexes
de leur représentation afin qu’un même processus de
construction puisse créer différentes représentations.
¾ Factory Method :définition d’une interface pour la création
d’objets associées dans une classe dérivée.
¾ Prototype :spécification des types d’objet à créer en
utilisant une instance prototype.
¾ Singleton : comment assurer l’unicité de l’instance d’une
classe.
¾ Adapter : traducteur adaptant l’interface d’une classe en
une autre interface convenant aux attentes des classes
clientes.
¾ Bridge :découplage de l’abstraction de l’implémentation
pour faire varier les deux indépendamment.
¾ Composite : structure pour la construction d’agrégations
récursives.
¾ Decorator : extension d’un objet de manière transparente.
¾ Facade : unification de plusieurs interfaces de sous-
systèmes.
¾ Flyweight : partage efficace de plusieurs objets.
¾ Proxy : approximation d’un objet par un autre.

39 40
 Design Patterns de
comportement (1)
¾ Chain of Responsibility :délégation des requêtes à des
responsables de services.
¾ Command: encapsulation de requêtes par des objets afin
de permettre à un objet de traiter plusieurs types de
requêtes.
¾ Interpreter : étant donné un langage, représentation de la
grammaire le définissant pour l’interpréter.
¾ Iterator : parcours séquentiel de collections.
¾ Mediator : coordination d’interactions entre des objets
associés.
¾ Memento : capture et restauration d ’états d’objets.
41
Causes de reconception (1)
¾ Création d’un objet par la spécification d ’une classe
explicite
¾ Abstract factory, Factory Method, Prototype
¾ Dépendances entre opérations spécifiques
¾ Chain of Responsibility, Command
¾ Dépendances par rapport aux plate-formes matérielles et
logicielles :
¾ Abstract factory, Bridge
¾ Dépendances par rapport aux représentations et
implémentation des objets :
¾ Abstract factory, Bridge, Memento, Proxy
43
Design Patterns de
comportement (2)
¾ Observer :mise à jour automatique des dépendants d’un
objet.
¾ State : permettre à un objet de modifier son comportement
lorsque son état interne change.
¾ Strategy : abstraction pour sélectionner un algorithme
parmi plusieurs.
¾ Template method :définition d’un squelette d’algorithme
dont certaines étapes sont fournies par une classe dérivée.
¾ Visitor :représentation d’opérations devant être appliquées
à des éléments d’une structure hétérogène d’objets.
42
Causes de reconception (2)
¾ Dépendances algorithmiques :
¾ Builder, Iterator, Strategy, Template Method, Visitor
¾ Couplage important :
¾ Abstract factory, Bridge, Chain of Responsibility, Command,
Facade, Mediator, Observer
¾ Accroissement des fonctionnalités par dérivation :
¾ Bridge, Chain of Responsibility, Composite, Decorator, Observer,
Strategy
¾ Impossibilité de modifier des classes facilement :
¾ Adapter, Decorator, Visitor
44
 Memento Anti Patterns

¾ Lorsque l ’on utilise les Design Patterns, se
souvenir que :
¾ ce ne sont que des suggestions,
¾ qu’ils pointent vers des solutions,
¾ qu’ils sont implémentés différemment selon les langages
de programmation,
¾ qu’ils sont rarement utilisés seuls mais plutôt combinés
avec d ’autres patterns,
¾ que les solutions ainsi conçues sont généralement plus
génériques et plus facilement réutilisables.
¾ 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.

45 46

Exemple de schéma pour les anti-

patterns
Pattern architecturaux
¾ « Background » ¾ Schémas d’organisation structurelle fondamentaux
¾ Forme générale pour les logiciels.
¾ Symptômes et conséquences
¾ Causes typiques ¾ Exemples : Pipes and Filters, Broker, MVC, Micro-
¾ Exception connue kernel
¾ Solution « réparée »
¾ Références :
¾ Variations
¾ F.Buschmann & al., Pattern-Oriented Software Architecture,
¾ Exemple Wiley 1996.
¾ Solutions apparentées ¾ R.Martin & al., Pattern Language of Program Design 3,
Addison-Wesley 1998.
¾ Applicabilité à d’autres points de vue ou échelles

47 48
Patterns d’analyse Exemples de patterns d’analyse
¾ Question de modélisation générale en regardant un ¾ « Accountability »
problème particulier dans un domaine.
¾ Le concept de comptabilité s’applique quand une
¾ Martin Fowler a proposé deux catégories de patterns personne ou une organisation est responsable
: d’une autre.
¾ « Analysis patterns » ¾ notion abstraite qui peut représenter plusieurs
¾ « Supporting patterns » problèmes spécifiques, comportant des structures,
des contrats, et du personnel.
¾ Référence : ¾ Party, organization hierarchies, organization
Martin Fowler, Analysis Patterns - Reusable Object Models, structure etc.
Addison-Wesley, 1997.

49 50

¾ « Observations and measurement » ¾ « Referring to Objects »

¾ Name, Identification scheme, object merge, object
¾ Des quantités peuvent être utilisées en tant equivalence
qu’attributs d’objets pour enregistrer de
l’information sur eux. ¾ « Planning »
¾ Ces patterns montrent comment cette approche ¾ Proposed and Implemented Action, Suspension,
échoue et suggère des approches plus Plan, Resource Allocation etc..
sophistiquées.
¾ « Trading
¾ Quantity, conversion ratio, compound units, ¾ Contract, Portfolio, Quote, Scenario
measurement, observation, protocol, dual time
record etc.

51 52
 Exemples de patterns support
¾ « Patterns for Type Model Design Templates »
¾ comment transformer un modèle de spécification
¾ « Layered Architecture for Information System » implicite en un modèle explicite et une
¾ Two-tier architecture, Three-tier architecture, implémentation.
Presentation and Application Logic, Database ¾ Implementing Associations, Object Creation,
interaction Implementing Constraints ….

¾ « Application Facades » ¾ « Association patterns »

¾ Interface simplifiée à un modèle compliqué. ¾ Associative Type, Keyed mapping, Historic
¾ Responsable du choix et de l’organisation de mapping.
l’information pour une présentation.

53 54

Sommaire Bibliographie
¾ Erich Gamma & al (1995) Design Patterns - Elements of Reusable
Object-Oriented Software, Addison-Wesley.
¾ ” Pattern Languages of Program Design ”, Coplien J.O., Schmidt D.C.,
• Conception Addison-Wesley, 1995.
¾ ” Pattern languages of program design 2 ”, Vlissides, et al, ISBN 0-
• Réutilisabilité 201-89527-7, Addison-Wesley
¾ ” Pattern-oriented software architecture, a system of patterns ”,
• Bibliothèque de classe vs. Framework Buschmann, et al, Wiley
• Design Pattern ¾ ” Advanced C++ Programming Styles and Idioms ”, Coplien J.O.,
Addison-Wesley, 1992.
• Historique ¾ S.R. Alpert, K.Brown, B.Woolf (1998) The Design Patterns Smalltalk
Companion, Addison-Wesley (Software patterns series).
• Catégories de Patterns ¾ J.W.Cooper (1998), The Design Patterns Java Companion,
http://www.patterndepot.com/put/8/JavaPatterns.htm.
9Bibliographie ¾ S.A. Stelting, O.Maasen (2002) Applied Java Patterns, Sun
Microsystems Press.
¾ Communications of ACM, October 1997, vol. 40 (10).
55 56
 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

57