Architecture - IGM

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

Documents

Architecture - IGM