Introduction aux patrons D. Rieu Dept Informatique, IUT2 Grenoble Dominique.Rieu@iut2.upmf-grenoble.fr

Composants de différents niveaux Nerson 92 Expression des besoins Spécifications Informelles Analyse (abstraction du monde réel) Modèle Objet Descriptif & Normatif Conception (solution technique) Composants Modèle Objet Effectif Normalise Implantation (solution opérationnelle) Logiciel Département info/IUT2

Composants réutilisables le composant logiciel ne suffit plus toute une panoplie de modèles de composants réutilisables Dédié à un niveau d’abstraction Capitalisant savoir / savoir-faire Patron (Patterns) : un modèle consensuel ? Département info/IUT2

Patron ? Un patron constitue une base de savoir-faire pour résoudre un problème récurrent dans un domaine particulier. L’expression de ce savoir-faire : permet d’identifier le problème à résoudre propose une solution possible et correcte pour y répondre offre les moyens d’adapter cette solution Département info/IUT2

PATTERNité : l’architecture C. Alexander : 253 patrons de conception architecturaux (64,77,79) tiré de «Introduction aux patterns» Jean Bézivin Département info/IUT2

D’autres domaines : l’hydraulique. Ken Asplund en 1973 Département info/IUT2

Définition Décrire avec succès des types de solutions récurrentes 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 Département info/IUT2

Les patrons pour les SI Les patrons sont des composants logiques décrits indépendamment d’un langage donné (solution exprimée par des modèles semi-formels) Département info/IUT2

Historique OOPSLA 87 Beck et Cunnimghan Design Patterns : Element of Reusable Object-Oriented Software Gamma 95 Gamma et al. (GoF) OOPSLA 91, OOPSLA 92 PLoP 94 Montibello • Object Models: Strategies, Patterns and Applications Coad 95 Patterns Languages of Program Design Coplien et Schmidt 95 EuroPLoP 96 Kloster Pattern-Oriented Software Architecture: A System of Patterns. ChiliPLoP 98 Wickenburg Buschmann 96 Analysis Patterns : Reusable Object Model Fowler 97 Département info/IUT2

Patron « observateur » d ’E. Gamma Intention : définir une interdépendance entre objets dépendants de façon telle que, quand un objet change d’état, tous ceux qui en dépendent en soit informés et automatiquement mis à jour. Motivation : 20 40 60 Est = 20,4 Ouest = 30,6 Nord = 45,9 1 sujet 3 observateurs x = 55 y = 97 GoF, 1995 Département info/IUT2

Patron « observateur » Structure et Collaborations un-Observateur un-Sujet un-autre-Observateur Sujet 1: modifier_état 2: notifier Observateur 1,n état_sujet lire_etat () modifier_etat () notifier () lier (Observeur) délier (Observeur) Observateurs état-obs. mise_à_jour( ) 3: mise_à_jour 4: lire_état 4: mise_à_jour return état_sujet 5: lire_état pour tout o de Observateurs o.mise_à-jour () Département info/IUT2

Types de patrons / portée Gestion des ressources Opérations Bancaires Analyse «métier commun» «métier spécifique» - Le problème traité est issu d’une analyse de domaine - Aide à la construction de modèles objets descriptifs Composite Observateur Blackboard Conception «architecture» «conception» - identifier, nommer et abstraire des thèmes récurrents de la conception par objet. - Aide à la construction de modèles objets effectifs Simuler l’héritage multiple en Java Implantation « idiome » - comment implanter dans un langage particulier certains traits absents de ce langage Documenter un framework Documentation - technique de dialogue, de documentation, d’enseignement, etc. Département info/IUT2

Patrons de Gamma : introduction 23 modèles de conception du «Gang of Four» Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides ORIGINES pratique de Smalltalk & C++ conception et réalisation de frameworks (cadriciels) thèse d’Erich Gamma, Object-Oriented Software Development based on ET++ : Design Patterns, Class Library, Tools, Institut für Informatik, Zurich, 1991. des conférences OOPSLA 91, 92, … Design Patterns - Elements of Reusable Object Oriented Software, Addison-Wesley, 1995. (existence d’une version française) Département info/IUT2

Patrons de Gamma : formalisme 1- nom du patron et classification 2- intention : le problème à résoudre 3- alias : les patrons similaires dans d’autres langages de patrons 4- motivation : un scénario d’application du patron, les problèmes particuliers 5- indications d’utilisation : les situations dans lesquelles ce patron peut être utilisé 6- structure : une représentation graphique du patron utilisant la notation OMT 7- participants : les classes et/ou les objets participants et leurs responsabilités 8- collaborations : comment les participants collaborent 9- conséquences : décrit les résultats d’utilisation du patron 10- implantation : les astuces et les conseils d'implantation 11- exemples de code : fragments de code illustrant l’implantation du patron 12- utilisations remarquables : des exemples d’utilisations réelles de ce patron 13- modèles apparentés : d’autres patrons utilisés avec (ou par) celui-ci Département info/IUT2

Formalismes des patrons Narratif ou Structuré P. Coad E. Gamma Nom Nom Le patron Intention Alias Un exemple Motivation Indications Indications d’utilisation Diagramme Structure Participants Collaborations Conséquences Implantation Exemples de Code Il existe plusieurs formalismes pour documenter les patrons, les plus celebres etant celui de la bande des quatre et un formalisme non nomme mais frequemment utilise sur le Web. Certains sont tres simples mais parfois incomplets comme celui de Coad. La plupart sont trop complexes et on a parfois du mal a ne pas faire de redite. De partout on retrouve une ou plusieurs rubriques représentant : le nom, le problème, le contexte , la solution, des exemples. Solution plus ou moins détaillée Liens inter-patrons Cas réels d’utilisation (framework) Utilisations Modèles Apparentés Département info/IUT2 Patron LSR-IMAG

Classification Gof Fonction Portée Les 23 Patrons du Gof sont classifies suivant deux critères : la fonction (ce que fait le patron) et la portée (la classe ou l’objet). Les patrons de création établissent des abstractions du mecanisme d’instanciation. Les patrons structurels ont pour objectif la gestion des compositions de classes et d’objets. Les patrons comportementaux caractérisent les interactions entre objet et la distribution des responsabilité. Abstract Factory est aussi connu sous le terme de KIT. Permet de définir une interface permettant de créer des familles d ’objets sans instancier directement leurs classes. Adapter : transforme l ’interface d ’une classe en une autre souhaitee par les clients. Interpreter : permet de représenter la grammaire d ’un langage et son interpreteur. Département info/IUT2 Patron LSR-IMAG

Exemple : Factory Method Application docs CreateDocument NewDocument doc = self.CreateDocument docs.inserer(doc) doc.ouvrir Document On a par exemple un framework pour des applications pouvant présenter plusieurs documents aux utilisateurs. Les deux abstraction de ce framework sont les classes application et document, une application etant une agrégation de documents. La classe application doit pouvoir gérer ses documents et par exemple en creer un nouveau. La méthode createdocument de Application est virtuelle. La méthode new-document va consister a demander une création de document puis a lier ce document a son application et finalement a l’ouvrir Les clients doivent spécialiser ces deux classes pour réaliser des implantations spécifiques. Pour creer par exemple une application de dessin il s’agit de définir une classe Application-Dessin et une classe Documents-Dessin.La méthode virtuelle peut alors être concretisee. MyApplication MyDocument return new MyDocument() CreateDocument Département info/IUT2 Patron LSR-IMAG

Exemple : Factory Method Structure Creator FactoryMethod AnOpération ... product = self. FactoryMethod .... Product ConcreteCreator ConcreteProduct FactoryMethod return new ConcreteProduct() Participants Product : l’interface des objets créés par la «factory method» ConcreteProduct : réalise l’interface Creator : déclare la «factory method» et l’utilise pour manipuler des produits ConcreteCreator : surcharge ou réalise la «factory method» Département info/IUT2 Patron LSR-IMAG

Exemple : Composite Département info/IUT2 Patron LSR-IMAG

Exemple : Composite Figure Cercle FigureComposée Texte une-Figure uneFigureComposée une-Figure* uneFigureSimple un-Client colorer () tracer () ajouter(fig) supprimer(fig) accéder () composant 1: colorer () 2: colorer () 1,n 3:colorer () 4: tracer () 5: tracer () Cercle FigureComposée colorer () tracer () La solution consiste a définir une classe abstraite représentant à la fois les objets simples et les objets composites. La classe FIGRURE définit l’interface commune de toutes les figures (colorer, tracer mais aussi ajouter un composants...). Les opérations spécifiques sont implantées dans les classes modélisant les figures simples, les opérations de gestion du lien de composition sont implantées dans la classe modélisant des figures composées. Les opérations spécifiques, par exemple colorer sont directement exécutées s’il s’agit d’une figure simple ou par appel récursif aux composants s’il s’agit d’une figure composée. colorer () { } tracer () ajouter(fig) supprimer(fig) accéder () Texte colorer () tracer () pour tout c de composants c.colorer() Département info/IUT2 Patron LSR-IMAG

Exemple : Composite composant pour tout c de composants Client Opérationspécifique () Ajouter(Composant) Supprimer(Composant) Accéder() composant Composite Feuille Opérationspécifique () Opérationspécifique () Ajouter(Composant) Supprimer(Composant) Accéder() pour tout c de composants c.operationspécifique Département info/IUT2 Patron LSR-IMAG

Exemple : Composite Département info/IUT2 Patron LSR-IMAG

Typologie des patrons Patrons nature couverture Patrons Processus Produit Patrons Généraux Patrons de Domaine portée Patrons D’Analyse Patrons Conception Patrons D’Implantation Département info/IUT2

Nouvelle-Opération-Bancaire Nom : Nouvelle-Opération-Bancaire Problème : Permet de traiter uniformément les opérations bancaires (création compte, prêt, retrait, dépôt, etc.) pour faciliter la maintenance et l’évolution du système. Force : Uniformisation des traitements, Réutilisation dès l’expression des besoins. Département info/IUT2

Nouvelle-Opération-Bancaire Cas d’application : Cas général 2 cas spécifiques Accéder au compte Nouvelle Opération Contrôler le compte Retrait Vérifier la création du retrait Compte Bancaire Créer le retrait Client Acteur Prévenir le client Accéder au produit Accéder au client Contrôler le produit Nouveau Contrôler le client Vérifier la création de l’opération Compte Vérifier la création du compte Créer l’opération Agent Créer le compte Prévenir l’acteur bancaire Prévenir l’agent Département info/IUT2

Nouvelle-Opération-Bancaire Département info/IUT2

Nouvelle-Opération-Bancaire Département info/IUT2 LSR-IMAG

Nouvelle-Opération-Bancaire Solution Modèle Nouvelle Opération Bancaire Acteur Accéder au produit Contrôler le produit Vérifier la création de l’opération Créer l’opération Prévenir l’acteur Département info/IUT2

Nouvelle-Opération-Bancaire Solution Modèle Département info/IUT2

Nouvelle-Opération-Bancaire Solution Modèle  Agrégat-Produit  nouvelle-opération-produit() un-produit?(): Produit  Produit  ton-état? () réaliser-opération ():Opération-Bancaire vérifier-création-opération (): Bool lier-opération-bancaire (o:Opération-Bancaire) 0..* 1 1..* Opération-Bancaire créer-opération-bancaire(p:Produit,..) lier-produit(p:Produit) Patron « Nouvelle-Opération-Bancaire » Département info/IUT2

Réutilisation dès l’expression des besoins Dépot Compte Nouvelle Opération Bancaire acteur Supprimer Produit Retrait Compte client Nouveau Compte Supprimer Compte Agent Bancaire Supprimer Client Département info/IUT2

Ingénierie des systèmes Imitation Imiter un patron = dupliquer et adapter les solutions modèles Adapter un duplicata de patron = (renommer | redéfinir | ajouter | supprimer)* des propriétés Département info/IUT2

Exemple d ’Imitation patron «Nouvelle-Opération-Bancaire»    nouvelle-opération-produit() un-produit? (): Produit   patron «Nouvelle-Opération-Bancaire» 0..* 1..* Agrégat-Produit Produit Opération Bancaire ton-état? () réaliser-opération ():Opération-Bancaire vérifier-création-opération (): Bool lier-opération-bancaire (o:Opération-Bancaire) créer-opération-bancaire(p:Produit,..) lier-produit(p:Produit) 1 créer-retrait (c:Compte,…) : Retrait lier-compte (c : Compte) 1 modèle «Nouveau-Compte» modèle «Retrait-Compte» nouveau-compte () un-client? () : Client 0..* 1..* créer-compte (cl:Client,…) :Compte lier-client (cl : Client) verser () retrait-compte() un-compte?() : Compte Banque Compte Retrait Client Agence ton-état? () réaliser-compte ():Compte vérifier-création-compte (): Bool lier-compte (c:Compte) réaliser-retrait ():Retrait vérifier-création-retrait (): lier-retrait (o:Retrait) retirer () 2 imitations 1 patron Département info/IUT2

Intégration d’imitation Ingénierie des systèmes Intégration d’imitation Intégrer des imitations = (unir)* les rôles des classes Union consiste à : - remplacer deux classes par une seule regroupant les propriétés des classes initiales ou - appliquer un patron Rôle Exemple : classe Compte Département info/IUT2

Exemple d ’Intégration Banque Maintenance et Traçabilité ? Agence retrait-compte() nouveau-compte () un-compte?() : Compte un-client? () : Client 0..* 0..* Compte Client Retrait créer-compte (cl:Client,…) 1..* 1 lier-client (cl : Client) 1 ton-état? () verser () 1..* créer-retrait (c:Compte,…) réaliser-compte ():Compte ton-état? () lier-compte (c : Compte) vérifier-création-compte (): réaliser-retrait ():Retrait lier-compte (c:Compte) vérifier-création-retrait lier-retrait (o:Retrait) retirer () Département info/IUT2

Un système = une intégration d’imitations de patrons Compte Opération-Bancaire Produit Nouveau-Compte «Nouvelle-Opération-Bancaire» Retrait-Compte «Nouvelle-Opération-Bancaire» Opération-Bancaire Agrégat-Produit Produit Agrégat-Produit Agence Client Retrait Banque Département info/IUT2

Un système = une intégration d’imitations de patrons Figure FigureChangeListener Composant Sujet Collègue concret Observateur Médiateur Composite Observateur Médiateur concret FigureChangeEventMulticaster Observateur concret Feuille Composite concret Sujet concret AttributeFigure CompositeFigure AbstractFigure StandardDrawing Gestionnaire concret Gestionnaire concret RectangleFigure Gestionnaire concret Gestionnaire Client Chaîne de responsabilité Département info/IUT2

Ingénierie des systèmes La structure générale d’un modèle de SI peut-elle être construite exclusivement par imitation et intégration de patrons sans ajouts de classes ou de liaisons ? OUI si : - si on reste au même niveau d’abstraction (usage du patron Rôle, des patrons de Gamma, etc.) - le catalogue de Patrons est complet Département info/IUT2

Complétude des catalogues de patrons Très difficilement vérifiable Plus facile pour un catalogue mono-domaine (SI bancaire, produit…) L’ingénierie des patrons passe par une analyse de domaine Catalogue de patrons Ingénierie des Patrons SI Analyse du domaine Nouveau SI Cahier des charges utilisateurs existants plus le catalogue est complet, plus les patrons sont liés les uns aux autres plus le processus d’ingénierie des SI est spécifié. Département info/IUT2

Nouvelle approche d’ingénierie Deux processus complémentaires - d’ingénierie des SI à partir de patrons (BY reuse) langage de patrons + opérations de bases Imitation, Intégration d’imitations - d’ingénierie des patrons (FOR reuse) systèmes existants, analyse de domaine + relations inter-patrons Alternative, Extension/Raffinement, Utilisation Département info/IUT2 LSR-IMAG