LOG4430 : Architecture logicielle et conception avancée

Transcription

1 LOG4430 : Architecture logicielle et conception avancée Abdou Maiga Revision Département de génie informatique et de génie logiciel École Polytechnique de Montréal Guéhéneuc, 2009; Khomh, 2010; Maiga, 2010

2 Conception architecturale 1. Introduction 2. Modéliser l architecture avec UML 3. Éléments architecturaux 4. Styles architecturaux 1. Architecture pipeline 2. Architecture avec référentiel de données 3. Architecture MVC 4. Architecture multi-couches 5. Architecture n-niveaux 5. Développer un modèle architectural

3 1. Architecture logicielle Qu est-ce qu une architecture logicielle? L architecture d un logiciel est la structure des structures (modules) d un système Elle inclut Les composants logiciels Les propriétés externes visibles de ces composants Les relations entre ces composants Cf. [Bass, Clements, and Kazman (1998) ] Contrairement aux spécifications produites par l analyse fonctionnelle ne décrit pas ce que doit réaliser un système mais comment il doit être conçu pour à répondre aux spécifications. L analyse fonctionnelle décrit le «quoi faire» alors que l architecture décrit le «comment le faire»

4 Introduction Qu est que la description d une architecture logicielle? La définition de l architecture logicielle consiste à: Décrire l organisation générale d un système et sa décomposition en sous-systèmes ou composants Déterminer les interfaces entre les sous-systèmes Décrire les interactions et le flot de contrôle entre les sous- systèmes Décrire également les composants utilisés pour implanter les fonctionnalités des sous-systèmes Les propriétés de ces composants Leur contenu (e.g., classes, autres composants) Les machines ou dispositifs matériels sur lesquels ces modules seront déployés

5 Introduction Pourquoi développer une architecture logicielle? Pour permettre à tous de mieux comprendre le système Pour permettre aux développeurs de travailler sur des parties individuelles du système en isolation Pour préparer les extensions du système Pour faciliter la réutilisation et la réutilisabilité

6 Introduction Utilité d une architecture logicielle [Garlan 2000] Compréhension : facilite la compréhension des grands systèmes complexes en donnant une vue de haut-niveau de leur structure et de leurs contraintes. Les motivation des choix de conception sont ainsi mis en évidence Réutilisation : favorise l identification des éléments réutilisables, parties de conception, composants, caractéristiques, fonctions ou données communes Construction : fournit un plan de haut-niveau du développement et de l intégration des modules en mettant en évidence les composants, les interactions et les dépendances

7 Introduction Utilité d une architecture logicielle [Garlan 2000] Évolution : met en évidence les points où un système peut être modifié et étendu. La séparation composant/connecteur facilite une implémentation du type «plug-and-play» Analyse : offre une base pour l analyse plus approfondie de la conception du logiciel, analyse de la cohérence, test de conformité, analyse des dépendances Gestion : contribue à la gestion générale du projet en permettant aux différentes personnes impliquées de voir comment les différents morceaux du casse-tête seront agencés. L identification des dépendance entre composants permet d identifier où les délais peuvent survenir et leur impact sur la planification générale

8 2. Modéliser avec UML (1/5) Les vues (structurelles) d une architecture logicielle Vue logique. Description logique du système décomposé en sous-systèmes (modules + interface) UML : diagramme de paquetages Vue d implémentation. Description de l implémentation (physique) du système logiciel en termes de composants et de connecteurs UML : diagramme de composants Vue de déploiement. Description de l intégration et de la distribution de la partie logicielle sur la partie matérielle UML: diagramme combiné de composants et de déploiement

9 3. Éléments architecturaux (8/10) Exemple d un diagramme de composants

10 3. Éléments architecturaux (10/10) Choix d une architecture Dépend des exigences fonctionnelles et non fonctionnelles du logiciel Choix favorisant la stabilité : l ajout de nouveaux éléments sera facile et ne nécessitera en général que des ajustements mineurs à l architecture Influencé par certains «modèles connus» de décomposition en composants (styles architecturaux) et de mode d interactions (e.g., orienté objet)

11 4. Style architecturaux Un style architectural Est un patron décrivant une architecture logicielle permettant de résoudre un problème particulier Définit Un ensemble de composants et de connecteurs (et leur type) Les règles de configuration des composants et connecteurs (topologie) Une spécification du comportement du patron Des exemples de systèmes construits selon ce patron Constitue un modèle éprouvé et enrichi par l expérience de plusieurs développeurs Compréhensibilité, maintenance, évolution, réutilisation, performance, documentation, etc.

12 Architecture pipeline Convient bien aux systèmes de traitement et de transformation de données Composants = filtre ; Connecteur = canal Filtre Traite indépendamment et asynchrone Reçoit ses données d un ou plusieurs canaux d entrée, effectue la transformation/traitement des données et envoie les données de sortie produites sur un ou plusieurs canaux de sorties Fonctionnent en concurrence. Chacun traite les données au fur et mesure qu il les reçoit Canal Unidirectionnel au travers duquel circulent un flot de données (stream). Synchronisation et utilisation d un tampon parfois nécessaire pour assurer la bon fonctionnement entre filtre producteur et filtre consommateur Exemples : application de traitement de texte, de traitement de signaux. Compilateur (analyse lexicale, syntaxique, sémantique) Filtre canal de communication synchro

13 Architecture pipeline Système de traitement du son Encodeur pour sortie de microphone Filtrer l écho Filtrer le bruit Retirer les fréquences non vocales Égaliser les les intervalles dynamiques Encodeur de bruit ambiant Décompresser Recevoir Transmettre Compresser Encoder la sortie des haut-parleurs

14 Architecture pipeline Avantages Bon pour traitement en lot (batch) Très flexible Analyse facilitée : performance, synchronisation, goulot d étranglement, etc. Se prête bien à la décomposition fonctionnelle d un système Inconvénients Mauvais pour le traitement interactif D un point de vue conception Diviser pour régner : les filtres peuvent être conçus séparément Cohésion : les filtres sont un type de cohésion fonctionnelle Couplage : les filtres n ont qu une entrée et une sortie en général Abstraction : les filtres cachent généralement bien leurs détails internes Réutilisabilité : les filtres peuvent très souvent être réutilisés dans d autres contextes Réutilisation : il est souvent possible d utiliser des filtres déjà existants pour les insérer dans le pipeline

15 Architecture avec référentiel Architecture avec référentiel de données (shared data) Utilisée dans le cas où des données sont partagées et fréquemment échangées entre les composants Deux types de composants : référentiel de données et accesseur de données Les référentiels constituent le medium de communication entre les accesseurs Connecteur : relie un accesseur à un référentiel Rôle de communication, mais aussi possiblement de coordination, de conversion et de facilitation Référentiel1 Référentiel2 A A A A A

16 Architecture avec référentiel Variantes Style tableau noir : les référentiels sont des agents actifs. Lorsqu ils reçoivent une données, ils informent tous les accesseurs concernés Style référentiel : les référentiels sont passifs. Simple vocation de stockage. Les composants accède aux référentiels comme ils le désirent Exemples : application de bases de données, systèmes Web, systèmes centrés sur les données (e.g. système bancaire, système de facturation,etc.), environnement de programmation

17 Architecture avec référentiel Avantages Avantageux pour les applications impliquant des tâches complexes sur les données, nombreuses et changeant souvent. Une fois le référentiel bien défini, de nouveaux services peuvent facilement être ajoutés Inconvénients Le référentiel peut facilement constituer un goulot d étranglement, tant du point de vue de sa performance que du changement

18 Architecture Modèle-Vue-Contrôleur (MVC) Séparer la couche interface utilisateur des autres parties du système (car les interfaces utilisateurs sont beaucoup plus susceptibles de changer que la base de connaissances du système) Composé de trois types de composants Modèle : rassemble des données du domaine, des connaissances du système. Contient les classes dont les instances doivent être vues et manipulées Vue : utilisé pour présenter/afficher les données du modèle dans l interface utilisateur Contrôleur : contient les fonctionnalités nécessaires pour gérer et contrôler les interactions de l utilisateur avec la vue et le modèle

19 Architecture Modèle-Vue-Contrôleur () Vus par les acteurs View E.g. Génère le code html pour le browser créer et mettre à jour E.g. Interprète les transmissions http «post» du browser Reçoit les événements des acteurs Consulter l état (i.e. les données) notifier changements Contrôleur Modèle modifier Le sous-système gérant l information.

20 Architecture Modèle-Vue-Contrôleur Modèle : noyau de l application Enregistre les vues et les contrôleurs qui en dépendent Notifie les composants dépendants des modifications aux données Vue : interface (graphique) de l application Crée et initialise ses contrôleurs Affiche les informations destinées aux utilisateurs Implante les procédure de mise à jour nécessaires pour demeurer cohérente Consulte les données du modèle Contrôleur : partie de l application qui prend les décisions Accepte les événement correspondant aux entrées de l utilisateur Traduit un événements (1) en demande de service adressée au modèle ou bien (2) en demande d affichage adressée à la vue Implémente les procédures indirectes de mise à jour des vues si nécessaire

21 Architecture Modèle-Vue-Contrôleur () Avantages : approprié pour les systèmes interactifs, particulièrement ceux impliquant plusieurs vues du même modèle de données. Peut être utilisé pour faciliter la maintenance de la cohérence entre les données distribuées Inconvénient : goulot d étranglement possible D un point de vue conception Diviser pour régner : les composants peuvent être conçus indépendamment Cohésion : meilleure cohésion que si les couches vue et contrôle étaient dans l interface utilisateur. Couplage : le nombre de canaux de communication entre les 3 composants est minimal Réutilisabilité : la vue et le contrôle peuvent être conçus à partir de composants déjà existants Flexibilité : il est facile de changer l interface utilisateur Testabilité : il est possible de tester l application indépendamment de l interface

22 Architecture multi-couches Composants : chaque composant réalise un service Une couche offre un service (serveur) aux couches externes (client) Service créé indépendamment du logiciel ou spécifiquement Met à profit la notion d abstraction, les couches externes sont plus abstraites (haut niveau) que les couches internes Connecteurs : dépendent du protocole d interaction souhaité entre couches Système fermé : une couche n a accès qu aux couches adjacentes. Les connecteurs ne relient que les couches adjacentes Système ouvert : toutes les couches ont accès à toutes les autres. Les connecteurs peuvent relier deux couches quelconques Exemples : souvent utilisé pour les systèmes implémentant des protocoles de communication (TCP/IP)

23 Architecture multi-couches Système fermé Reference Model of Open Systems Interconnection (OSI model) Application Présentation Transformation des données (encryption,etc.) Session Identifier et authentifier une connexion Transport Transmission (point à point) fiable des données Transmission des routing packets Réseau Transmission des data frames sans erreurs Ligne de données Interface matérielle du réseau Physique

24 Architecture multi-couches D un point de vue conception Diviser pour régner : les couches peuvent être conçues séparément Cohésion : si elles sont bien conçues, les couches présenter une cohésion par couche Couplage : des couches inférieures bien conçues ne devraient rien savoir à propos des couches supérieures et les seules connexions autorisées entre couches se font via les API Abstraction : on n a pas à connaître les détails d implémentation des couches inférieures Réutilisabilité : les couches inférieures peuvent être conçues de façon à offrir des solutions génériques réutilisables Réutilisation : on peut souvent réutiliser des couches développées par d autres et qui proposent le service requis Flexibilité : il est facile d ajouter de nouveaux services construits sur les services de plus bas niveau Anticipation du changement : en isolant les composants dans des couches distinctes, le système devient résistant Portabilité : tous les services relatifs à la portabilité peuvent être isolés Testabilité : les couches peuvent être testées indépendamment Conception défensive : les API des couches constituent des endroits stratégiques pour insérer des assertions de vérification

25 Architecture n-niveaux Pour les systèmes distribués Comparable à une architecture par couches dont les couches seraient distribuées! N.b. L architecture multi-couche est généralement utilisée pour décrire la structure interne (non distribuée) d un composant qui peut luimême appartenir à une architecture (distribuée) n-partie Par abus de langage, la notion de tier a pris le sens de couche distribuée Composants : chaque niveaux est représenté par un composant qui joue le rôle de client et/ou de serveur Connecteurs : relient un client à un serveur. Connexion asymétrique. Doit supporter les communication distantes (e.g., requêtes RPC, HTTP, TCP/IP) Exemples Client-serveur, Trois niveaux, Quatre niveaux

26 Architecture n-niveaux Architecture 2-niveaux (client-serveur ou client lourd) Client requête de service Serveur Architecture 3-niveaux (client léger) Navigateur Web Architecture 4-niveaux requête de service Logique applicative requête de service de B.D. Serveurs de base de données Client Présentation (partie web) Logique Applicative (calculs, business) Bases de données

27 Architecture n-niveaux Architecture client-serveur Exemple typique : un système d informations utilisant une base de données centrale. (cas spécial de l architecture avec référentiel) Clients : reçoivent les données de l utilisateur, initient les transactions, etc. Serveur : exécute les transactions, assure l intégrité des données Architecture pair-à-pair = une généralisation de l architecture client-serveur Les composants peuvent tous à la fois être client et serveur Conception plus difficile: flot de contrôle plus complexe dû à la possibilité de deadlocks

28 Architecture n-niveaux Architecture client-serveur <<communication>> Échanger msg Client2 <<communication>> chercher adresse Client1 <<communication>> Échanger msg Client3 Serveur <<communication>> Échanger msg <<communication>> chercher adresse netscape:webbrowser diro:webserver iexplo:webbrowser lynx:webbrowser

29 Architecture n-niveaux Architecture 3-niveaux Organisation en trois couches Couche interface: Composé d objets interfaces (boundary objects) pour interagir avec l utilisateur (fenêtres, formulaires, pages Web, etc.) Couche logique applicative : Comporte tous les objets de contrôle et d entités nécessaire pour faire les traitements, la vérification des règles et les notifications requises par l application Couche de stockage : réalise le stockage, la récupération et la recherche des objets persistants Avantage sur l architecture client-serveur Permet le développement et la modification de différentes interfaces utilisateurs pour la même logique applicative

30 Architecture n-niveaux Architecture 3-parties Réseau Client X Serveur de B.D. Unix Base de données corporative Marché de données Client Windows Serveur Windows NT Logique applicative Serveur de B.D. Unix Dépôt de données

31 Architecture n-niveaux Architecture 3-niveaux Interface gestionnaire Gestion des dossiers À noter que la tendance veut que la partie cliente soit De plus en plus mince, i.e., le client ne fait qu afficher un contenu HTML La logique applicative est alors responsable de créer les pages Web à afficher par le client Il faut dissocier logique applicative et présentation des données Base de données clients

32 Architecture n-niveaux Architecture 4-niveaux Architecture dont la couche logique applicative est décomposée en Couche Présentation (JSP, servlets) Présentation du contenu statique: Contenu HTML ou XML affiché par le client Présentation du contenu dynamique : contenu organisé et créé dynamiquement par le serveur web (pour ensuite être affiché en HTML/XML par le client) Couche Logique applicative (calculs purs) : réalise le cœur des traitements de l application Avantage sur l architecture 3-niveaux Permet de supporter un grand nombre de formats de présentation différents (propres à chaque client), tout en réutilisant certains des objets de présentation entre les clients. Réduction des redondances Bien adaptée pour les applications Web devant supporter plusieurs types de clients

33 Architecture n-niveaux Java Server Pages - Partie cliente - Partie serveur Architecture 4-niveaux Clients Serveur Serveur de base de données Interface ATM <<build>> Présentation Serveur Interface Web Interface employé de la banque <<submit>> <<build>> <<build>> <<submit>> Gestion opérations bancaires <<submit>> Accès base de données comptes clients

34 Architecture n-niveaux D un point de vue conception Diviser pour régner : de façon évidente, client et serveur peuvent être développées séparément Cohésion : le serveur peut offrir des services cohésifs au client Couplage : un seul canal de communication existe souvent entre client et serveur Réutilisation : il est possible de trouver une bibliothèque de composants, interfaces, etc. pour construire les systèmes Toutefois, les systèmes clientserveur dépendent très souvent de nombreuses considérations liées intimement à l application Flexibilité : il est assez facile d ajouter de nouveaux clients et serveurs Portabilité : on peut développer de nouveaux clients pour de nouvelles plateformes sans devoir porter le serveur Testabilité : on peut tester le client et le serveur indépendamment Conception défensive : on peut introduire des opérations de vérification dans le code traitant les messages reçus de part et d autre

35 5. Développer un modèle architectural Commencer par faire une esquisse de l architecture En se basant sur les principaux requis des cas d utilisation ; décomposition en sous-systèmes Déterminer les principaux composants requis Sélectionner un style architectural Raffiner l architecture Identifier les principales interactions entre les composants et les interfaces requises Décider comment chaque donnée et chaque fonctionnalité sera distribuée parmi les différents composants Déterminer si on peut réutiliser un cadriciel existant (réutilisation) ou si on peut en construire un (réutilisabilité). Considérer chacun des cas d utilisation et ajuster l architecture pour qu il soit réalisable Détailler l architecture et la faire évoluer Décrire l architecture avec UML

36 5. Développer un modèle architectural Les composants et le principe de séparation des préoccupations La séparation des préoccupation est le principe qui assure l intégrité fonctionnelle d un composant Chaque composant réalise une, et seulement une fonction au sein du système, mais peut néanmoins exposer plusieurs méthodes. Typiquement, chaque composant est défini par une interface qui constitue son seul moyen d interagir avec les autres composants L utilisation d une interface pour communiquer avec les autres composants du système facilite la maintenance puisqu on peut alors en changer l implémentation sans affecter les autres composants (induit un couplage plus faible du composant avec le reste du système) Les classes d un composant devrait être vues comme un patron cohésif qui implémente la fonctionnalité du composant

37 2.Bibliothèques et le chargement de composants dynamiques

38 2.1. Introduction Aucun logiciel de grande taille n est développé depuis zéro aujourd hui Sauf dans le cas de développement en «salle blanche» Utilisation de «Bouts de code» Structures + fonctions / Classes + méthodes Bibliothèques

39 2.2. Bibliothèques et cadriciels «Bibliothèque [library] logicielle est un ensemble de fonctions utilitaires, regroupées et mises à disposition afin de pouvoir être utilisées sans avoir à les réécrire» [Wikipedia] Plutôt que de coder une procédure courante dans chaque programme en ayant besoin, on rassemble ces procédures dans des bibliothèques. Si un programme a une fonction à remplir et que celle-ci se trouve en bibliothèque, il l'utilisera directement. Les bibliothèques logicielles se distinguent des exécutables dans la mesure où elles ne représentent pas une application Exemples La bibliothèque de classes Java (!) La STL de C++ (!!)

40 2.2. Bibliothèques et cadriciels «Un cadriciel [framework] est un espace de travail modulaire. C'est un ensemble de bibliothèques, d'outils et de conventions permettant le développement de programmes.» [Wikipedia] Un framework fournit: un ensemble de fonctions facilitant la création de tout ou d'une partie d'un système logiciel un guide architectural en divisant le domaine visé en modules.

41 2.2. Bibliothèques et cadriciels Types d interconnexions Chainage des liens (linking) Duplication de processus (fork) Protocole de communication (IPC) Sous-classage Chargement dynamique

42 3. Cadres de référence et plugiciels

43 3.1. Introduction Aujourd hui (et demain), les programmes Sont de plus en plus complexes Doivent être livrés de plus en plus rapidement Doivent fonctionner avec un minimum d arrêt Les programmes nécessitent donc Une plateforme de programmation favorisant l indépendance des composants Un format de livraison «standardisé» Une plateforme d exécution permettant le remplacement à chaud Les programmes doivent donc être formés de composants réutilisables et interchangeables en cours d exécution

44 3.2. Definition: plugiciel «Un [plugiciel] est un programme qui interagit avec un logiciel principal, appelé programme hôte, pour lui apporter de nouvelles fonctionnalités» [Wikipedia] ils ne peuvent fonctionner seuls car ils sont uniquement destinés à apporter une fonctionnalité à un ou plusieurs logiciels ; ils sont mis au point par des personnes n'ayant pas nécessairement de relation avec les auteurs du logiciel principal.

45 3.2. Definition: plugiciel L ojectif derriere l implementation des plugiciels est de permettre: L ajout des fonctionnalités sans avoir à tout reprogrammer Permettre aux utilisateurs d'ajouter leurs propres fonctionnalités de manière indépendante Cette indépendance inclut la possibilité pour le logiciel Cette indépendance inclut la possibilité pour le logiciel principal d'évoluer tout en restant compatible avec les plugiciels existants ; cette condition est cependant loin d'être toujours remplie.

46 3.3. OSGi Considérons une classe java faisant partie d une application et implémentant une fonctionnalité. Cette classe doit donc faire partie des.jar de l application. En cas de bug dans cette classe, l application complète doit être arrêtée afin que celui-ci soit corrigé même s il n affecte qu une sousfonctionnalité très rarement utilisée. La technologie OSGi permet de développer les fonctionnalités de façon indépendantes et de les intégrées dans l application sous forme de services. Ces services peuvent être reliées dynamiquement à l application Un service particulier pouvant être arrêté et mis à jour sans que le reste de l application ne soit affecté.

47 3.3. OSGi OSGi (Open Service Gateway Initiative) a été fondé par Ericson, IBM, Oracle et Sun Modèle à composants complet et dynamique Complémente la machine virtuelle Java Réduit la complexité : encapsulation, interface de programmation Réutilisation : composants depuis l étagère Déploiement simplifié : gestion du cycle de vie Mises à jour dynamiques : voir ci-dessus Adaptation : les services peuvent aller et venir Transparence : composants indépendants [

48 3.3. OSGi La spécification de OSGi définit comment les bundles (composants) doivent être implémentés afin d être intégrés à la plateforme OSGi. Elle se structure de la manière suivante: Un ensemble de services qu un conteneur OSGi doit implémenter (Exple de conteneur: Equinox d Eclipse) Un contrat entre le conteneur et les application

49 3.3. OSGi Cycle de vie d un bundle OSGi

50 4.Composition et architectures par composants

51 4.1. Introduction Limitations des architecture à objets Complexité du chargement dynamique Ad hoc Solution partielle des cadre de références et autres plugiciels

52 4.1. Introduction Contexte : ingénierie du système/intergiciel (middleware) Maintenant des systèmes globaux intégrant des applications jusqu'ici indépendantes + développements nouveaux. Tenir compte applications patrimoniales (legacy) = developpées avant les standards ouverts actuels application patrimoniale ne peut être utilisée qu à travers une interface specifiée, et ne peut être modifiée. La plupart du temps, l'application doit être reprise telle quelle car le coût de sa réécriture serait prohibitif. Solution : Adopter une norme commune, non liée a un langage particulier, pour interconnecter différentes applications. La norme spécifie des interfaces et des protocoles d'échange pour la communication entre applications. Les protocoles sont realisees par une couche logicielle qui fonctionne comme un bus d'echanges entre applications: c est l intergiciel (middleware) Utiliser des wrapper (envellope) = couche logicielle qui fait le pont entre l'interface originelle de l'application et une nouvelle interface conforme à la norme choisie. [

53 4.1. Introduction Contexte : ingénierie du système/intergiciel (middleware) Intégration d'applications patrimoniales [

54 4.2. Introduction aux composants logiciels Composant vs objet plus haut niveau abstraction meilleure encapsulation, protection, autonomie programmation + systématique + vérifiable communications plus explicites port, interface, connecteur connectables schéma de connexion (ADL) : «plan» applicatif séparation «métier» - technique meilleure converture du cycle de vie conception, implémentation, packaging, déploiement, exécution

55 4.2. Introduction aux composants logiciels Définition composant 1ère apparition terme [McIlroy 68] 30 ans + tard : Sun EJB, OMG CCM, MS.NET/COM+, recensement [Szyperski 02] : 11 définitions +/- A component is a unit of composition with contractually specified interfaces and context dependencies only. A software component can be deployed independently and is subject to composition by third parties. [Szyperski 97]

56 4.3. Le modèle Fractal FT R&D, INRIA open source Historique fin 2000 : premières réflexions autour de Fractal 06/2002 1ère version stable API implémentation de référence (Julia) 1ère version de l ADL 01/2004 définition de l ADL v2 (ADL extensible) implémentation disponible 03/2004

57 4.3. Le modèle Fractal ingénierie des systèmes et du middleware suffisamment général pour être appliqué à tout autre domaine grain fin (wrt EJB ou CCM) proche d un modèle de classe léger (surcoût faible par rapport aux objets) indépendant des langages de programmation vision homogène des couches (OS, middleware, services, applications) Fractal everywhere dans le but de faciliter et d unifier conception, développement, déploiement, administration

58 4.3. Le modèle Fractal ouvert et adaptable les services extra-fonctionnels peuvent être personnalisés il n y a pas une seule forme de composants Fractal 2 usages possibles avec Fractal framework de composants pour construire des applications/systèmes on utilise la forme standard des composants Fractal framework de frameworks de composants on construit d autres formes de composants avec introspection minimale et aggregation simple (à la COM) avec contrôleurs de liaison et de cycle de vie (à la OSGi) avec hiérarchie à 2 niveaux et liaison (à la SCA) avec des liaisons multicast (à la CCA) avec des contrôleurs d attribut (à la MBean) avec des contrôleurs de persistance et de transaction (à la EJB) on développe des applications avec ces autres formes

59 En résumé 4.3. Le modèle Fractal

60 5.Patrons de conception

61 Patrons de conception = Outils pour développeurs

62 5.1 Origines Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such way that you can use this solution a million times over, without ever doing it the same way twice. Each pattern is a three part rule, which express a relation between a context, a problem, and a solution. Christopher Alexander [Alexander, 1977] The strict modeling of the real world leads to reflect today s realities but not necessarily tomorrow s. The abstractions that emerge during design are key to making a design flexible. Erich Gamma [Gamma et al., 1994]

63 5.1 Origines Systèmes de plus en plus complexes, le nombre de classes et d instances est de plus en plus élevé. Vers une plus grande réutilisation de classes: ensembles de classes collaboratrices. Qu est qu un bon design?

64 5.1 Origines Un patron de conception c est: Description d une solution classique à un problème récurent Décrit une partie de la solution Avec des relations avec le système et les autres parties... C est une technique d architecture logicielle

65 5.1 Origines Un patron de conception n est pas: Une brique Un pattern dépend de son environnement Une règle Un pattern ne peut pas s appliquer mécaniquement Une méthode Ne guide pas une prise de décision ; un pattern est la décision prise Nouveau Non, Lao-Tzu (-550) travaillait déjà sur les patterns...

66 5.2. Definition The description of communicating objects and classes customized to solve general design problem in a particular context. Each design pattern lets some aspect of system structure vary independently of other aspects, thereby making a system more robust to a particular kind of change. [Gamma et al., 1994]

67 5.2. Definition Avantages Un vocabulaire commun Permettent une plus grande reutilisabilité Capitalisation de l expérience Un niveau d abstraction plus élevé qui permet d élaborer des constructions logicielles de meilleure qualité Réduire la complexité Guide/catalogue de solutions

68 5.2. Definition Inconvénients Effort de synthèse ; reconnaître, abstraire Apprentissage, expérience Les patterns «se dissolvent» en étant utilisés Nombreux lesquels sont identiques? De niveaux différents des patterns s appuient sur d autres...

69

70 Catégories de patrons de conception Création Fabrique abstraite (Abstract Factory) Monteur (Builder) Fabrique (Factory Method) Prototype (Prototype) Singleton (Singleton) Structuraux Adaptateur (Adapter) Pont (Bridge) Objet composite (Composite) Décorateur (Decorator) Façade (Facade) Poids-mouche ou poids-plume (Flyweight) Proxy (Proxy) Comportementaux Chaîne de responsabilité (Chain of responsibility) Commande (Command) Interpréteur (Interpreter) Itérateur (Iterator) Médiateur (Mediator) Mémento (Memento) Observateur (Observer) État (State) Stratégie (Strategy) Patron de méthode (Template Method) Visiteur (Visitor)

71 Quand utiliser un patron de conception? Lorsque le problème est complexe? Plusieurs patrons de conception existent Granularité Requis, analyses, architecture Conception, implémentation (idioms) Refactoring, testing Les connaître tous...

72 Application des patrons de conception L application des patrons lors de la conception permet Trouver les bons objets Les patterns proposent des abstractions qui n'apparaissent pas "naturellement" en observant le monde réel Composite par exemple permet de traiter uniformément une structure d'objets hétérogènes Bien choisir la granularité des objets La taille des objets peut varier considérablement ; comment choisir ce qui doit être décomposé ou au contraire regroupé? Exple: Facade, Flyweight, Spécifier les interfaces des objets Qu est-ce qui fait partie d un objet ou non? Exple: Memento, Decorator

73 Application des patrons de conception L application des patrons lors de la conception permet Spécifier l'implantation des objets Différence type-classe Exple: Chain of Responsibility ; même interface, mais implantations différentes Mieux réutiliser Héritage vs composition; Préférez la composition à l'héritage Délégation; Une forme de composition...qui remplace l'héritage, Exple: Mediator, Visitor, Proxy

74 Comment utiliser les patrons de conception? De façon itérative et inductive Partir de solutions simple et progressivement factoriser le code pour évoluer vers les patrons de conception si nécessaire Choisir le bon patron dès la phase de conception