Un modèle d'assemblage de composants par Contrat et ...

Publié par

THÈSE DE DOCTORAT DU
CONSERVATOIRE NATIONAL DES ARTS ET MÉTIERS
- CNAM -
Spécialité :
INFORMATIQUE
Présentée par
LEGOND-AUBRY Fabrice
Sujet de la thèse
Un modèle d’assemblage de composants par Contrat
et Programmation Orientée Aspect
Soutenue le 11 juillet 2005, devant le jury composé de :
M. Florin Gérard Professeur au Conservatoire National des Arts et Métiers, CEDRIC Directeur
M. Seinturier Lionel Maître de conférence à l’Université Paris VI, LIP6 Encadrant
M. Estublier Jacky Directeur de recherche CNRS, IMAG LSR Rapporteur
M. Sadou Salah Maître de conférence HDR à l’Université de Bretagne Sud, Valoria Rapp
M. Gressier Eric Professeur au Conservatoire National des Arts et Métiers, CEDRIC Examinateur
M. Girault Claude à l’Université Paris VI, LIP6
M. Traverson Bruno EDF/GDF, Ingénieur Recherche à la division R& D Invité Un modèle d’assemblage de composants par Contrat
et Programmation Orientée Aspect
Résumé de la thèse
La taille croissante des applications et la multitude de leurs interconnexions rendent de plus en
plus difficile leur conception. Les composants offrent une couche d’abstraction qui améliore leurs
mises en interactions et isole le code pour améliorer la portabilité et l’inter-opérabilité. Cependant
les composants souffrent d’une grande complexité de déploiement et d’un manque d’outils pour la
description de leurs assemblages et de leurs dépendances.
Actuellement, il n’existe pas de solution industrielle standardisée pour permettre l’assemblage et
l’extension ...
Publié le : lundi 9 mai 2011
Lecture(s) : 275
Nombre de pages : 228
Voir plus Voir moins
THÈSE DE DOCTORAT DU CONSERVATOIRE NATIONAL DES ARTS ET MÉTIERS - CNAM - Spécialité : INFORMATIQUE Présentée par LEGOND-AUBRY Fabrice Sujet de la thèse Un modèle d’assemblage de composants par Contrat et Programmation Orientée Aspect Soutenue le 11 juillet 2005, devant le jury composé de : M. Florin Gérard Professeur au Conservatoire National des Arts et Métiers, CEDRIC Directeur M. Seinturier Lionel Maître de conférence à l’Université Paris VI, LIP6 Encadrant M. Estublier Jacky Directeur de recherche CNRS, IMAG LSR Rapporteur M. Sadou Salah Maître de conférence HDR à l’Université de Bretagne Sud, Valoria Rapp M. Gressier Eric Professeur au Conservatoire National des Arts et Métiers, CEDRIC Examinateur M. Girault Claude à l’Université Paris VI, LIP6 M. Traverson Bruno EDF/GDF, Ingénieur Recherche à la division R& D Invité Un modèle d’assemblage de composants par Contrat et Programmation Orientée Aspect Résumé de la thèse La taille croissante des applications et la multitude de leurs interconnexions rendent de plus en plus difficile leur conception. Les composants offrent une couche d’abstraction qui améliore leurs mises en interactions et isole le code pour améliorer la portabilité et l’inter-opérabilité. Cependant les composants souffrent d’une grande complexité de déploiement et d’un manque d’outils pour la description de leurs assemblages et de leurs dépendances. Actuellement, il n’existe pas de solution industrielle standardisée pour permettre l’assemblage et l’extension des composants. Il faut utiliser des outils spécifiques non compatibles ou des plates-formes à composants dédiées. Nous proposons une méthode pour faciliter l’assemblage et la réutilisation de ces entités trop souvent considérées comme de simples serveurs. Nous introduisons les notions de dépendance, de connecteur, de demi-contrats et de contrats entre composants qui nous permettent d’expliciter des règles d’assemblage utilisées ensuite pour garantir la correction du système formé. Nous projetons ensuite ces contrats sur des plates-formes composants existantes. La Programma- tion Orientée Aspect (POA) nous permet d’injecter le code dans les composants sans en modifier le code source et en conservant la compatibilité avec la multitude de plates-formes existantes. La POA nous permet aussi par extension d’implanter des services non fonctionnels au niveau métier des composants sur des plates-formes tel que EJB et CCM. Nous avons mis en œuvre cette approche avec l’étude d’un service de contrôle comportementale des composants. Ce service nous permet, au cours de l’exécution, de vérifier la conformité des composants avec leur spécification. Mots Clés : Contrats, Composition, Assemblage, Composants, Programmation Orientée Aspect (POA), EJB, CCM An aspect oriented, contract aware, component model Abstract Components are more and more widely used to create complex distributed systems. One finds them invariousapplicationslikedata-processingapplications,intensivecalculationapplications,information systemsapplications,oreveninembeddedsystems.Theirreusablestructuremadethemvaluedentities to create applications. However, the "design by component" is a new method for which the entities composition raises several difficulties. On the contrary to the object oriented programming which carries out a downward analysis of the problems, the components form reusable elements that the designers can assemble to create an application. The design by component remains however a new technology and the composition rules of these entities are not well defined. The interaction between components often requires the correct following of a strict protocol. The interactionbondsevolvebetweenthecomponentsduringtheexecution.Thus,itisgenerallyimpossible to validate these relations during the conception phase. So, we present a method to ease the assembly and the re-use of these entities too frequently consideredassimpleserverswhichlimitstheircapacityofcollectiveaction.Weintroduceadependency concept and a notion of contract between components which enable us to clarify rules of assembly and, then, use them to guarantee the correction of the formed system. We project these contracts on component platforms. Our proposed solution is based on the aspect oriented programming (AOP) which enables us to inject additional code in the components without modifying their source code. Thanks to this aspect oriented programming aware component platform, we can check, at runtime, the execution flow of a component based application. The AOP also enables us by extension to add non-functional services on the functional components code of multiple components platforms such as EJB or CCM. Keywords:Contracts,Composition,Assembly,Components,aspectorientedprogramming(AOP), delegation Table des matières I Introduction 1 1 Introduction 3 1.1 Thème de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Une implémentation utilisant des concepts de plus en plus abstraits . . . . . . . . . . . 4 1.3 De nouvelles abstractions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3.1 Les composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3.2 L’utilisation de la modélisation et des contrats . . . . . . . . . . . . . . . . . . 6 1.3.3 La séparation des préoccupations et la POA . . . . . . . . . . . . . . . . . . . . 8 1.4 Une solution globale et générique est-elle possible? . . . . . . . . . . . . . . . . . . . . 10 1.5 Objectifs et plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.5.1 Les objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.5.2 Notre solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.5.3 Le plan de thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 II État de l’art 15 2 Etat de l’art 17 2.1 Différents axes de recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.2 Les plates-formes à composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.2.1 La notion de composant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.2.2 Les composants "Enterprise Java Beans" (EJB) . . . . . . . . . . . . . . . . . . 21 2.2.2.1 Architecture générale du modèle EJB 2.0 . . . . . . . . . . . . . . . . 22 2.2.2.2 Les composants EJB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.2.2.3 Détails de l’architecture d’une plate-forme EJB . . . . . . . . . . . . . 24 2.2.2.4 Les différents types de composants EJB . . . . . . . . . . . . . . . . . 24 v vi 2.2.2.5 Déploiement et assemblage . . . . . . . . . . . . . . . . . . . . . . . . 26 2.2.2.6 Evaluation du modèle EJB . . . . . . . . . . . . . . . . . . . . . . . . 26 2.2.2.7 Ouvertures du modèle EJB 3.0 . . . . . . . . . . . . . . . . . . . . . . 28 2.2.3 Les composants "Corba Component Model" (CCM) . . . . . . . . . . . . . . . 30 2.2.3.1 Le middleware CORBA, support de CCM . . . . . . . . . . . . . . . . 30 2.2.3.2 Le modèle CCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.2.3.3 Le Composant CCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.2.3.4 L’interface home dans CCM . . . . . . . . . . . . . . . . . . . . . . . 36 2.2.3.5 Déploiement, assemblage et exécution . . . . . . . . . . . . . . . . . . 36 2.2.3.6 Evaluation du modèle CCM . . . . . . . . . . . . . . . . . . . . . . . 37 2.2.4 JavaPod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2.2.4.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2.2.4.2 La composition dans JavaPod . . . . . . . . . . . . . . . . . . . . . . 39 2.2.4.3 Evaluation de Javapod . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.2.5 Tableau résumé sur les composants . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.3 La Programmation Orientée Aspect (POA) . . . . . . . . . . . . . . . . . . . . . . . . 42 2.3.1 Principes de la POA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.3.2 AspectJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.3.2.1 Principes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.3.2.2 Définitions des aspects . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.3.2.3 Quelques subtilités concernant les pointcuts . . . . . . . . . . . . . . 47 2.3.2.4 Evaluation d’AspectJ . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.3.3 JAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.3.3.1 Principes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.3.3.2 Outils de transformations de code . . . . . . . . . . . . . . . . . . . . 49 2.3.3.3 Mécanismes internes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 2.3.3.4 Définition des aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 2.3.3.5 Evaluation de JAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 2.3.4 AspectWerkz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 2.3.4.1 Principes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 2.3.4.2 Définition des aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 2.3.4.3 Evaluation d’AspectWerkz . . . . . . . . . . . . . . . . . . . . . . . . 56 2.3.5 Tableau résumé sur la POA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 2.4 Outils de modélisation et d’assemblage . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 vii 2.4.1 Unified Modeling Language : Objectifs . . . . . . . . . . . . . . . . . . . . . . . 58 2.4.2 Une modélisation du monde objet : UML 1.x . . . . . . . . . . . . . . . . . . . 58 2.4.2.1 Les éléments d’UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 2.4.2.2 UML 1.x et les composants . . . . . . . . . . . . . . . . . . . . . . . . 61 2.4.3 Une modélisation du monde composant : UML 2.0 . . . . . . . . . . . . . . . . 61 2.4.3.1 Les entités "component" en UML 2.0 . . . . . . . . . . . . . . . . . . 63 2.4.3.2 La notion de "Ports" et de "Connecteur" en UML 2.0 . . . . . . . . . 63 2.4.4 Programmation par Contrats . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 2.4.4.1 Le langage Eiffel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 2.4.4.2 Conception Objet Par Contrat : IContract . . . . . . . . . . . . . . . 71 2.5 Conclusion : des outils complémentaires . . . . . . . . . . . . . . . . . . . . . . . . . . 72 III Modélisation 75 3 Améliorer les modèles de composants 77 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 3.2 Motivations et caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 3.2.1 Des services non fonctionnels non indépendants . . . . . . . . . . . . . . . . . . 79 3.2.2 Une solution globale imparfaite : les contrats . . . . . . . . . . . . . . . . . . . 79 3.2.3 Des solutions spécifiques adaptées mais non compatibles . . . . . . . . . . . . . 80 3.2.4 Un manque de maturité conceptuelle des composants . . . . . . . . . . . . . . . 80 3.3 Le projet ACCORD et notre participation . . . . . . . . . . . . . . . . . . . . . . . . . 80 3.4 Les éléments de base du modèle ACCORD . . . . . . . . . . . . . . . . . . . . . . . . . 81 3.4.1 Le modèle ACCORD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 3.4.2 Une application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 3.4.3 Les composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 3.4.3.1 Les composants co-localisés et atomiques . . . . . . . . . . . . . . . . 84 3.4.3.2 Les composants composites . . . . . . . . . . . . . . . . . . . . . . . . 84 3.4.4 Les interfaces et les opérations . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 3.4.5 Les ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 3.4.5.1 Hiérarchie, relation d’assemblage et relation de délégation . . . . . . . 87 3.4.6 La représentation UML des composants ACCORD . . . . . . . . . . . . . . . . 87 3.4.6.1 Méta-élément Opération . . . . . . . . . . . . . . . . . . . . . . . . . 87 3.4.6.2t Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 88 viii 3.4.6.3 Méta-élément Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 3.4.6.4 Composant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 3.4.7 Les interactions primitives du modèle abstrait : l’invocation d’opération . . . . 90 3.4.8 Isolation et visibilité dans notre modèle abstrait . . . . . . . . . . . . . . . . . 90 3.4.8.1 Isolation et hiérarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 3.4.8.2 Visibilité inter-composants . . . . . . . . . . . . . . . . . . . . . . . . 91 3.4.8.3 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 3.5 L’assemblage et la délégation dans le modèle ACCORD . . . . . . . . . . . . . . . . . 94 3.5.1 La délégation dans le modèle abstrait A . . . . . . . . . . . . . . . . . 94 3.5.1.1 Délégation pure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 3.5.1.2 en conformité . . . . . . . . . . . . . . . . . . . . . . . . . 95 3.5.1.3 Délégation en adaptation . . . . . . . . . . . . . . . . . . . . . . . . . 95 3.5.2 La délégation et l’assemblage dans UML . . . . . . . . . . . . . . . . . . . . . . 95 3.5.3 La notion de connecteur dans ACCORD . . . . . . . . . . . . . . . . . . . . . . 96 3.5.3.1 Le ACCORD : un coordinateur de composants . . . . . . 96 3.5.3.2 Le connecteur : c’est aussi un composant! . . . . . . . . . . . . . . . . 97 3.5.3.3 Une définition des connecteurs ACCORD . . . . . . . . . . . . . . . . 98 3.5.3.4 Un exemple des complexes . . . . . . . . . . . . . . . . . 98 3.5.4 Représentation UML des connecteurs ACCORD . . . . . . . . . . . . . . . . . 100 3.5.4.1 Connecteur complexe (ComplexConnector) . . . . . . . . . . . . . . . 100 3.5.4.2 Prise (Plug) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 4 La programmation par contrats pour les composants 103 4.1 De nouveaux concepts nécessaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 4.2 Un modèle de contrats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 4.2.1 Une nouvelle définition des contrats . . . . . . . . . . . . . . . . . . . . . . . . 105 4.2.2 Nature des contrats et des spécifications . . . . . . . . . . . . . . . . . . . . . . 106 4.3 Contrats d’interactions : une relation de compatibilité . . . . . . . . . . . . . . . . . . 108 4.3.1 Compatibilité et sous typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 4.3.2 d’opération . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 4.3.2.1 Compatibilité syntaxique . . . . . . . . . . . . . . . . . . . . . . . . . 109 4.3.2.2 sémantique des paramètres . . . . . . . . . . . . . . . . 109 4.3.2.3 Compatibilité sémantique et pragmatique entre les propriétés . . . . . 110 ix 4.3.3 Expression des propriétés figurant dans les demi-contrats . . . . . . . . . . . . 112 4.3.4 Compatibilité d’interface, de port, de composant . . . . . . . . . . . . . . . . . 113 4.3.5 Existence d’un contrat d’interaction . . . . . . . . . . . . . . . . . . . . . . . . 113 4.3.6 Un exemple de contrat d’in entre 2 composants . . . . . . . . . . . . . 114 4.3.7 La notion de délégation pour les contrats . . . . . . . . . . . . . . . . . . . . . 116 4.3.8 Dépendances contractuelles dues à la délégation . . . . . . . . . . . . . . . . . 117 4.3.9 Détermination du contrat de composant . . . . . . . . . . . . . . . . . . . . . . 118 4.4 Un exemple d’étude de compatibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 4.4.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 4.4.2 Relation entre le contrôleur et les autres composants . . . . . . . . . . . . . . . 121 4.4.3 Contrôleur-Stock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 4.4.4 Relation Contrôleur-Authentification . . . . . . . . . . . . . . . . . . . . . . . . 123 4.4.5 Contrôleur-Banque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 4.4.6 Dépendances internes du composant Contrôleur . . . . . . . . . . . . . . . . . . 124 4.4.7 Détermination des relations de compatibilité . . . . . . . . . . . . . . . . . . . 124 4.5 Les contrats dans la pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 4.5.1 Représentation UML des contrats et des spécifications . . . . . . . . . . . . . . 126 4.5.2 XML Schema des contrats et des spécifications . . . . . . . . . . . . . . . . . . 129 4.5.3 Vérification au niveau modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 4.6 Conclusion : de la nécessité de la vérification dynamique . . . . . . . . . . . . . . . . . 137 IV Réalisation 139 5 La POA pour les composants : POAC (1ère partie) 141 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 5.2 L’impact de la POA sur les composants . . . . . . . . . . . . . . . . . . . . . . . . . . 143 5.3 La POA, un outil générique pour les composants . . . . . . . . . . . . . . . . . . . . . 144 5.4 Événements applicatifs à capturer avec des points de coupe . . . . . . . . . . . . . . . 146 5.4.1 Etape 1 : Découverte des services de base . . . . . . . . . . . . . . . . . . . . . 149 5.4.2 Etape 2 : Obtention d’une instance par recherche ou création . . . . . . . . . . 150 5.4.3 Etape 3 : Invocation de service . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 5.4.4 Etape 4 : Fermeture de connexion avec le composant . . . . . . . . . . . . . . . 152 5.4.5 Etape 5 : F de avec le middleware . . . . . . . . . . . . . . 152 5.4.6 Hors phase : les interactions Composant-Middleware . . . . . . . . . . . . . . . 153 x 5.4.7 Les exceptions composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 5.5 Une Plate-forme de POA pour Composant : POAC . . . . . . . . . . . . . . . . . . . . 153 5.5.1 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . . 153 5.5.2 Implantation de la couche d’aspect abstraite pour une plate-forme EJB . . . . 155 5.5.2.1 Étape 1 : Découverte des services de base . . . . . . . . . . . . . . . . 156 5.5.2.2 Étape 2 : Obtention d’une instance par recherche ou creation . . . . . 156 5.5.2.3 Etape 3 : Invocation de service . . . . . . . . . . . . . . . . . . . . . . 156 5.5.2.4 Étape 4 : Fermeture de connexion avec le composant . . . . . . . . . . 159 5.5.2.5 Interception des callbacks et exceptions . . . . . . . . . . . . . . . . . 159 5.5.3 Implantation de la couche d’aspect abstraite pour une plate-forme CCM . . . . 159 5.5.3.1 Étape 1 : Découverte des services de base . . . . . . . . . . . . . . . . 159 5.5.3.2 Etape 2 : Obtention d’une instance par recherche ou creation . . . . . 160 5.5.3.3 Étape 3 : Invocation de service . . . . . . . . . . . . . . . . . . . . . . 162 5.5.3.4 Étape 4 : Fermeture de connexion avec le composant . . . . . . . . . . 162 5.5.3.5 Interception des callbacks et exceptions . . . . . . . . . . . . . . . . . 162 5.6 Un exemple d’aspect EJB pour l’équilibrage de charge . . . . . . . . . . . . . . . . . . 162 5.6.1 Aspect de distribution au niveau client . . . . . . . . . . . . . . . . . . . . . . . 163 5.6.2 Aspect de au niveau serveur . . . . . . . . . . . . . . . . . . . . . . 166 5.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 6 La plate-forme POAC : abstraction inter-plate-forme (2ème partie) 169 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 6.2 La couche abstraite POAC : nécessaire mais pas suffisante . . . . . . . . . . . . . . . . 170 6.2.1 De subtiles différences entre plates-formes . . . . . . . . . . . . . . . . . . . . . 170 6.2.2 Visibilité des aspects dans le paradigme composant . . . . . . . . . . . . . . . . 171 6.2.3 Extension de la définition des coupes au paradigme composant . . . . . . . . . 173 6.3 Un gestionnaire d’aspect pour composant . . . . . . . . . . . . . . . . . . . . . . . . . 174 6.3.1 Abstraction du contexte : Le gestionnaire d’aspect composant . . . . . . . . . . 174 6.3.2 Architecture générales du middleware de POA pour Composant . . . . . . . . . 175 6.3.3 La création du contexte (couche 2) . . . . . . . . . . . . . . . . . . . . . . . . . 176 6.3.4 Le gestionnaire d’aspect (couche 3) . . . . . . . . . . . . . . . . . . . . . . . . . 178 6.3.5 La structure d’un aspect de composant (couche 4) . . . . . . . . . . . . . . . . 178 6.3.6 Les expressions de coupes du gestionnaire . . . . . . . . . . . . . . . . . . . . . 179 6.4 Coût d’interceptions dynamiques des appels composants . . . . . . . . . . . . . . . . . 180
Soyez le premier à déposer un commentaire !

17/1000 caractères maximum.