Août 2009

Design patterns Un modèle de conception(design patterns) fournit un arrangement pour affiner les sous-systèmes ou les composants d'un système logiciel en relation entre eux. Il décrit une structure généralement se reproduisant des composants communiquant qui résout un problème de conception général dans un contexte particulier.

Framework Un Framework est un logiciel partiellement complet (sous-) le système qui est destiné pour être instancé. Il définit l'architecture pour une famille (de sous-) des systèmes et fournit les composantes de base pour les créer. Il définit aussi les endroits où les adaptations pour la fonctionnalité spécifique devraient être faites..

Un Design Pattern Nom Exposé du problème Contexte & contraintes Description de la solution proposée Exemple d’implémentation Confrontation avec d’autres Design Patterns

Principales classes de Design Patterns Patterns de création Création d’objets sans instanciation directe d’une classe Patterns de composition(structurel) Composition de groupes d’objets Patterns comportementaux Modélisation des communications inter-objets et du flot de données

Factory Method Objectif : obtenir des instances de classes implémentant des interfaces connues, mais en ignorant le type réel de la classe obtenue et permettre de limiter le nombre d'instance d'une classe à une ou quelques unes Exemple : une application read data (locale, distante) distance local

Singleton Objectif : s’assurer qu’une seule instance d’un type spécifique existe dans le système et fournir l’accès à cet objet Exemple : appilcation

Adapter Objectif : Le pattern Adaptateur permet de transformer une interface d'une classe en une autre conforme à celle attendue par le client. L'adaptateur permet à des classes de collaborer alors qu'elles n'auraient pas pu le faire du fait d'interfaces incompatibles. Exemple : chargement d’un appareil Cible

J2EE Patterns

Architecture J2EE Pattern Presentation Tier Patterns Buisness Tier Patterns Integration Tier Patterns Intranet BGI et Patterns

Architecture J2EE Pattern Systèmes faisant appels à des composants analogues Réunion de communauté d’architecte Description d’une architecture standard => un composant J2EE pattern

Architecture J2EE Pattern

Architecture J2EE Pattern

Presentation Tier Patterns

Intercepting Filter Contrôle de tous qui est paramètrage Authentification, Authorisations, Logs… Type d’échange de données ( cryptage, compression) Ensemble de filtres flexibles interçeptant les requètes et reponses

Front Controller Avoir un point d’accès centralisé pour le traitement des requètes Ne pas avoir à répéter le traîtement commun à plusieurs requètes => Un controleur frontal à l’ecoute de toutes les requètes

Application Controller Satisfaire les requêtes et retourner les vues appropriées => Un application Controller pour gérer ce traitement

Composite view Construire une vue à partir d’un ensemble de composants atomiques et modulaires ( headers, footers, tables …) => Une vue globale composées de sous-vues (Un contenu changeable)

Business Tier Patterns

Buisness Delegate Faire Communiquer la couche présentation avec la couche métier tout en minimisant le couplage entre les deux couches ( Prevenir les potentiels changements) Cacher les détails de la création, invocation et reconfiguration des services Translater les exceptions vers la couche applicative => Utiliser un Buisness Delegate pour encapsuler les services métiers

Service Locator Etablir un contexte pour la connexion à la couche métier Utiliser un JNDI API afin de localiser et consommer un composant métier (EJB,JMS) =>Faire appel à un service Locator afin de localiser et consommer un composant tout en rendant transparente l’implémentation de ce dernier

Session Façade Créer une couche au dessus des composants métiers. Le contact clients objets métiers sera contrôlé par cette couche => Session façade expose ses services au clients afin d’accéder aux objets métier

Buisness Objects, Transfert Objects & Transfer Objects Assembler Ayant pour ressources des objects Buisness, les Transferts Objects sont des unités de données qui transitent entre les différents couches. Ces objets peuvent se réunir en Transfer Objects assembler afin de minimiser le va et vient entre tiers.

Integration Tier Patterns

Data Acces Objects Rendre transparent l’accées au données à travers les couches. Uniformiser l’accès indépendamment de types de données. =>Utiliser les DAO pour tous les accès à l'entrepôt de persistance. Le Data Access Object gère la connexion avec la source de données dans le but d’obtenir et stocker des données.

IntranetBGI

Merci Pour Votre attention