Architecture logiciel L'art de l'architecture logiciel est
difficile. Cette architecture ne
peut pas se reposer sur des lois physique pour étayer les choix
structuraux.
Pour simplifier le travail de l'architecte nous allons introduire
des règles de constructions qui permettrons d'évaluer l'opportunité
d'une modification du logiciel.
Pour pouvoir décrire notre logiciel nous allons le décrire selon
différents niveau de granularité.
Différentes Vues du Logiciel Les différentes vues sont
– Le niveau système – Le niveau conceptuel – Le niveau classe/objet
– Le niveau code
La vue système
La vue système s'apparente a la vue d'un Urbaniste, notre activité
peut être soit d'intégrer un nouveau bâtiment, une nouvelle
ensemble ou de créer une ville nouvelle.
Pour le logiciel, nous devons soit ajouter un nouveau composant,
soit un nouveau sous-système, soit concevoir l'ensemble du système
d'information.
Pour faire une description de l'architecture au niveau système. UML
nous propose plusieurs type de diagrammes, qui peuvent permettre de
faire cette description.
Soit un diagramme d'interaction (chaque système = un objet), soit
un diagramme de use case (système = acteur). Mais un diagramme
boite peut faire l'affaire.
Vue systémique
Interface d'accès
Vue Conceptuelle
Dans cette vue du logiciel ce que nous cherchons à décrire est la
structure en classes et l'organisation de ces classes.
Pour cella on utilise une vue en paquetages et une description par
paterns (patrons de conception).
La vue en paquetage permet de séparer différentes problèmatiques
métier en général on utilise un des concepts important du Modèle
conceptuel. Chacun des concepts important peut être associé a un
paquetage (bien sur pas tous).
On peut identifier les grand éléments du système qui deviennent
aussi des paquetage (les boites de la vue système).
Vue conceptuelle
Pour construire la vue conceptuelle il nous faut des briques, ces
briques sont les patrons de conception.
G.o.F
Gang of Four
Patrons de conception La conception orienté objet est une activité
difficile il faut trouver les bons objets les factoriser en classes
de la bonne granularité, définir des interfaces et des hiérarchies
de classes et surtout établir des relations entre tout cela.
Ecrire des éléments modifiables est difficile, des éléments
réutilisable est encore plus difficile.
Une conception flexible et réutilisable est rarement obtenue du
premier jet.
Mais avec l'expérience on tend a produire de la bonne conception,
comment capitaliser cette expérience, c'est l'objectif des patrons
de conception (Design Paterns du livre éponyme) .
C'est quoi un <patron> ?
Ce titre est un patron en effet il permet de produire tout un tas
de question intéressantes et simule d'une phrase le comportement
d'un enfant d'éléphant.
Pour beaucoup d'activité nous utilisons des patrons : « j'ai
le même jardin que jean mais moi j'ai mis des Delphiniums »
« l'omelette aux girolles c'est une omelette dans laquelle tu
jette à mis cuisson des girolles
Les patrons : un mode de stockage de l'expérience
Un patron décrit une situation classique et une réponse classique a
cette situation.
Le patron peut s'utiliser tel quel ou être adapté ou combiné avec
d'autre pour répondre aux besoins.
Les patrons décrit ici sont ceux fournis par Gamma et All qui sont
devenu une référence pour l'ensemble de la communauté des
développeurs objet.
La démarche d'apprentissage des patrons de conception: 1) accepter
leur utilité 2) lire et relire les patrons (www) 3) Les
intérioriser pour les utiliser
Un conseil
Lisez tout ce que vous trouverez sur les Design Patterns
WikiPaterns http://www-igm.univ-mlv.fr/~dr/COURS/GL2005/
par des portes, fermée par des murs.
Le joueur commence dans la salle « start »
Il se déplace en utilisant une des commandes Nord, Sud, Est,
Ouest
Quand il entre dans une salle non visitée un événement de jeu a
lieux (accès a un texte) il peut demander la lecture du texte d'une
salle déjà visité.
L'objectif du joueur et de reconstruire le texte dans le bon
ordre
Salle
Porte
Mur
Construire l'ensemble des types Réaliser un labyrinthe avec deux
salles puis
faite passer votre joueur d'une salle a l'autre (texte : j'ai
faim).
Question qui construit quoi ?
Les Patrons de Conception
Trois familles : Patrons de création/construction
liés au problème de choisir la classe responsable des création et a
l'encapsulation des classes effectives
Patrons structurels liés au problèmes d'organisation des objets
dans un
logiciel
Les Patrons de création
Copain f =new Fred(); // facile la création Mais avez vous toujours
besoin de fred est il toujours disponible ? Factory (Usine): une
classe responsable du type d'instance effectivement crée. Abstract
Factory: une classe qui permet de créer une famille d'instances de
classes liées. Builder : Quand cela devient compliquer de
construire une instance demander un spécialiste. Prototype: Quand
copier est une bonne idée Singleton : Il y a des objets qui ne
supporte pas d'être à deux dans le même marigot.
Factory Usine Patrons de Création
Factory Usine Patrons de Création
Une classe ne peut prévoir la classes des instances qu'elle doit
créer
Une classe veut que ces sous classes spécifient les objets a
créer
Une classes utilise de la délégation et vous voulez identifier une
classe responsable du choix de la classe déléguée.
Souvent une méthode usine qui retourne l'instance.
Factory Usine Patrons de Création
Structure
Abstract Factory Patrons de Création
Les choses ce compliques nous travaillons avec plusieurs ensemble
de classes ou d'objets interdépendants et nous ne connaissons (ou
ne voulons connaître) leur classes effectives. C'est typiquement
une situation de portage. L'interface des base de données JDBC
utile ce patron. Une fois le driver de la base spécifié plus aucune
référence au type de la base n'est utile ! Toutes les classes de
communication avec la base sont construites par l'usine
abstraite.
Un autre nom est Kit de construction :)
Abstract Factory Patrons de Création
Abstract Factory Patrons de Création
eclipse
Prototype Patrons de Création
Tient ! ce qui est vraiment différent c'est les valeurs
d'initialisation de nos instances. Et de nouveau il n'est pas
possible pour le client de connaître les bonnes valeurs
d'initialisation. Confions ce travail a une usine mais une usine
qui utilise des prototypes pour construire de nouvelles
instances.
Prototype Patrons de Création
L'exemple type du prototype est l'objet graphique.
J'ai un certain nombre d'objets correctement initialisés il me
suffit d'en faire des copies.
Prototype Patrons de Création
Singleton Patrons de Création
Je ne tient pas a avoir plusieurs instances de cette classe ! Mais
j'aimerais bien en hériter comme c'est une classe abstraite !
J'en fait un Singleton.
Pour cela j'impose l'utilisation d'une méthode usine qui va gérer
l'unicité.
JDBC (encore lui) utilise cette technique pour le driver de la
base.
C'est avantageux par rapport a des méthode de class comme Math
permet d'avoir une sous classe
Singleton Patrons de Création
Reduction de l'espace de nom global. Control d'accès a l'unique
instance. Possiblite de sous classe Peut être étendu a doubleton
etc (gestion du nombre de thread par exemple)
Attention en sous-classant a construire une instance de la sous-
classe
Builder (s.a.r.l.) Patrons de Création
Vous ne savez pas construire nous oui ! Nous vous proposons notre
aide grâce a nos Builder !
Vous voulez construire des objets complexes mais normés, la
répétition étant fastidieuse vous confiez à un objet constructeur
la compétence de construction. Vous ne perdez pas le pouvoir
décisionnel de ce qui doit être construit.
[remarque le méta-patron de délégation de responsabilité, ici de
construire de bonne instances]
Builder (s.a.r.l.) Patrons de Création
Builder (s.a.r.l.) Patrons de Création
Les Patrons Structurels
Nous nous préoccupons ici de savoir comment composer proprement des
classes et des objets pour former de grandes structures. Deux
patrons classiques des langages objet sont l 'héritage et
l'héritage multiple, qui permettent d'une part de construire une
interface et d'autre part une implémentation. Et de construire des
classes qui ont les propriétés de plusieurs classes. AdapterAdapter
(Adaptateur) permet d'adapter l'interface d'une classes aux
exigence d'interface d'une autre, permettant de voire une multitude
de classes comme un seul concept. Un bon exemple d'adaptation est
la construction d'itérateurs sur plusieurs type de containeurs
(list,vecteur, etc).
Les Patrons Structurels
CompositeComposite (Composite :) est le parfait exemple de patron
structurel, il donne une technique simple applicable dans de
nombreuse situations et qui a un excellent effet sur la structure
et la réutilisation du code.
L'essence des patrons structurels est d'organiser la structure
compositionnelle des objets d'une façon standard et
efficasse.
Les Patrons Structurels
Decorator Decorator changer sans modifier
Facade Facade Les interfaces de paquetage ne sont pas toujours très
claires
Flyweight Flyweight Parfois un objet cella coûte cher.
Proxy Proxy Peut tu gérer l'accès à cet objet pour moi,
Merci.
AdapterAdapter Patrons Structurels
Quand l'interface d'une classe n'est pas conforme a nos souhaits
plutôt que de la ré-écrire (ce qui n'est pas toujours possible si
elle appartient a une librairie par exemple), nous allons créer une
classe d'adaptation qui transforme les appels sur l'interface
voulue en appels sur l'interface existante.
L'exemple qui suit est typique, c'est une classe qui transforme un
objet textuel en objet graphique grâce à un adapteur.
AdapterAdapter Patrons Structurels
AdapterAdapter Patrons StructurelsClasse
AdapterAdapter Patrons StructurelsObjet
AdapterAdapter Patrons StructurelsObjet
Un adapter bi-directionel, supposons que l'on veut faire
fonctionner ensemble un logiciel de calcul qui définie la notion de
variable d'état, et un logiciel d'édition graphique qui définie
aussi ces variables contraintes. Hors les deux parties doivent
echanger des informations par le biais de ces variables il faut
donc créer une variable qui est un adapter des deux autres :
VariableEtatContrainte.
Une solution technique l'héritage multiple.
AdapterAdapter Patrons Structurels
BridgeBridge Patrons Structurels
BridgeBridge Patrons Structurels
Une Abstract Factory peut construire et configurer un Pont
particulier.
L'adapter est utilisé pour rendre des classes non reliées
compatible, a l'inverse du Pont qui est prévu des la conception du
système pour offrir une plus grande indépendance sur les
implémentations.
On peut regarder l'interface des fichiers sous unix comme un Pont,
en effet on utilise une interface commune pour touts les accès
fichiers, l'implémentation varie en fonction des type effectifs des
fichiers manipulés, et l'on peut changer l'implémentation sans
changer les code clients. Encore l'occasion d'utiliser du
Polymorphisme.
CompositeComposite Patrons Structurels
CompositeComposite Patrons Structurels
Le Composite est un des patrons les plus utilisés, car il propose
une vision des structures arborescentes.
Très puissant dans sont effet structurel, il y a bcp de choix
d'implémentations sur lequels il est necessaire de travailler : 1°
variation sur le container utilisé (list,vect, etc) ou sur un
stockage des liens dans les feuilles. 2° l'importance de l'ordre
des fils (pensez a utiliser un iterator) 3° références parent 4°
Qui détruit les composants ? 5° un Cache 6° stockage des composants
? Il faut être généreux avec l'interface car l'on cherche a cacher
la distinction entre feuille et noeud. Mais cette distinction est
nécessaire si l'on ne veut pas risquer des opérations de Noeud sur
les feuilles.
CompositeComposite Patrons Structurels
DecoratorDecorator Patrons Structurels
Attacher des responsabilités dynamiquement a un Objet. Les
décorateurs sont une aternative a l'héritage pour étendre les
fonctionnalités.
Emballage
FlyweightFlyweight Patrons Structurels
Le problème que nous avons a traiter est l'existence d'un nombre
considérable d'objets éventuellement très complexes mais qui
partages beaucoup de caractéristiques.
FlyweightFlyweight Patrons Structurels
Si l'on regarde simplement comme chaque caractère du document peut
être remplacé par une image ou autre il nous faut la structure
suivante :
FlyweightFlyweight Patrons Structurels
L'idée est d'utiliser pour tout les caractères le partage
d'instance (comme les strings en java) ce qui nous donne le schéma
suivant (en utilisant une factory pour les caractères qui utilise
la réserve : pool).
FlyweightFlyweight Patrons Structurels
Les information d'état des caractères sont rajoutées par une autre
structure
ProxyProxy Patrons Structurels
Un objet est loin ou grand ou coûteux ou tout a la fois. Pour
éviter de soit de le manipuler a distance ou de le charger en
entier, on installe un proxy qui réalisera l'opération d'accès pour
le client de façon économique.
ProxyProxy Patrons Structurels
Utilisation de proxy:
proxy de chargement, quand on a effectivement besoin de l'objet il
est chargé
proxy d'objet distribués le proxy s'occupe de la
synchronisation
proxy d'authentification sécurité
proxy virtuel création au dernier moment des objets
proxy lazy le proxy limite les parties qui sont effectivement
chargés.
Proxy cache (évident non ?)
proxy de persistance
Les Patrons Comportementaux
Les patrons comportementaux sont liés aux responsabilités des
objets dans les algorithmes. La plus part des patrons
comportementaux explicite un concept algorithmique récurent et
expose quelle structure d'objet permet de matérialiser cette
responsabilité qui a une forte variabilité.
Le maître mot est algorithme, les patrons comportementaux
permettent, soit de réaliser du polymorphisme sur l'algorithme
comme template méthode, ou stratégie. Soit d'identifier une étape
de l'algorithme et de la matérialiser comme un objet ou un
comportement ce qui permet de l'extraire des contraintes de
l'algorithme (ou de l'écriture de l'algorithme).
Les Patrons Comportementaux
Command Command Encapsuler des requêtes
Interpreter Interpreter Comment construire une grammaire qui
interprète
Iterator Iterator Visiter des agrégations sans les connaitres
Mediator Mediator Faire communiquer des objets pour un même
objectif
Memento Memento Garder l'encapsulation en stockant l'état d'un
objet a l'extérieur.
Observer Observer prévenir les observateur de changement
d'état.
Les Patrons Comportementaux
State State Permet a un objet de changer de comportement quand sont
état change.
Startegy Startegy Encapsuler un algorithme
Template Methode Template Methode Construire le squelette d'un
algorithme en délégant la réalisation d'opération
élémentaires.
Visitor Visitor Permet de définir de nouvelles opérations sans
changer les classes des éléments sur lesquelles elle opère.
Chaine deChaine de reponsabilitéreponsabilité
Patrons Comportementaux
L'idée de ce patron et d'éviter de coupler trop fortement le
demandeur et le receveur d'une requête de façon a permettre
plusieurs répondeur de satisfaire a cette requête.
Les exemples les plus classiques sont la gestion arborescente de
l'aide, la gestion des événements de souris sur une interface
graphique, la gestion des exceptions des langages de
programmation.
Les receveur potentiels sont chaînés par un lien de délégation a
qui ils transmettent la requête quand ils ne peuvent la
traiter.
Un patron associé plus complexe est la bureaucratie, ou l'on
introduit des niveau avec des délégations dans les deux sens entre
les objets de niveau différents.
Utilisé avec composite ou le parent est responsable de répondre aux
requête que l'élément ne peut réaliser.
Patrons Comportementaux
Chaine deChaine de reponsabilitéreponsabilité
Chaine deChaine de reponsabilitéreponsabilité
Les class Loader en Java forme une chaine de responsabilité.
CommandCommand Patrons
Comportementaux
Ce patron vous propose d'encapsuler une requête de l'utilisateur
dans un objet de type command de façon a pouvoir maîtriser la
répétition, l'annulation, l'archivage, l'enchaînement de commandes.
L'élément de variation est l'action executer (et annuler).
IteratorIterator Patrons
Comportementaux
Ce patron vous propose d'encapsuler le calcul de l'élément suivant
dans une séquence et la classe concrète du container qui stock la
séquence. C'est un des concepts fondamentaux de la STL.
IteratorIterator Patrons
Comportementaux
Il est habituel d'avoir la même interface pour tout les itérateurs
de façon a abstraire le container. En général une factory méthode
du container est utilisé pour créer l'instance adaptée
d'iterateur.
Ce patron est le plus utilisé des patrons comportementaux.
MediatorMediator Patrons
Comportementaux
Le patron Mediator nous propose une structure qui permet
d'encapsuler les protocoles de communication entre objets.
Occasions d'utilisation: Un ensemble d'objets communique d'une
façon bien définie mais complexe. Les interdépendances résultantes
sont non structurées et difficiles a comprendre.
La réutilisation d'un objet est difficile car il fait référence et
communique avec beaucoup d'autres objets.
Un comportement distribué sur plusieurs classes doit être adaptable
sans pour autant avoir a sous classé de nombreuse classes.
MediatorMediator Patrons
Comportementaux
Dans ce panel de nombreux objets manipule une police de caractère.
Les interactions sont complexes en effet le poids et l'inclinaison
sont dépendant du type de police. L'affiche de la police est
dépendant de toutes les autres widgets. Pour simplifier la
communication, un objet médiateur sera responsable de gérer les
mises à jours des widgets.
MediatorMediator Patrons
Comportementaux
On a un client qui communique avec le Mediator qui lui vas gérer
les communication de et vers les collègues qui travail ensemble.
Ainsi les collègues ne communique que par le biais du médiateur.
Leur mise à jour est faite par le médiateur.
MementoMemento Patrons
Comportementaux
Comment conserver l'état d'un objet indépendamment de celui ci,
ceci sans violer le principe d'encapsulation de cet objet, afin de
pouvoir régénérerez cet état par la suite. L'état conservé par le
memento peut avoir une structure d'information différente de
l'objet original. En java les systèmes de persistance/introspection
simplifient l'écriture des Memento.
ObserverObserver Patrons
Comportementaux
Le patron Observer nous propose une structure qui permet de rendre
indépendantes plusieurs vues d'une même structure
d'information.
ObserverObserver Patrons
Comportementaux
Un objet Sujet vas contenir l'information et être associé a
plusieurs Observer, le sujet doit signaler aux observer les
modifications de son état qui ont un impact sur les observer.
StateState Patrons
Comportementaux
Un objet change de comportement en fonction de son état sans que le
client n'ai a changer.
Les comportement invariants sont dans TCPConnection
Les comportement dépendants de l'état sont définis dans l'état
correspondant
StateState Patrons
Comportementaux