Transformation du composant fragmenté en un composant composite

Une fois que le composant à adapter est fragmenté, le composant initial doit être recomposé (voir Figure 3.10) afin de préserver les invariants que nous avons fixés pour garantir le résultat de l’adaptation. Cette étape peut être décomposée en deux sous-étapes qui sont :

• l’assemblage des nouvelles entités

L’étape de décomposition produit des composants déconnectés les uns des autres et fournissant chacun un sous-ensemble des services du composant initial. Cependant, ces services ne sont pas indépendants. En fait, ils peuvent être liés par des dépendances comportementales ou bien par des dépendances dues au partage de ressources. Les dépendances comportementales font références aux appels de méthodes. En fait, certaines méthodes peuvent faire appel à d’autres méthodes qui initialement étaient définies dans l’espace de nom du composant mais suite à la fragmentation ne le sont plus : elles sont maintenant définies dans d’autres composants. Ainsi, pour garantir la cohérence de l’assemblage, il est nécessaire de garantir que toutes les méthodes définies dans l’implémentation d’un composant puissent accéder aux méthodes qu’elles utilisent.

Par ailleurs, nous avons vu que les ressources logicielles peuvent être dupliquées dans plusieurs implémentations associées à des composants générés : ce sont des ressources partagées. Ainsi, pour assurer la cohérence de l’assemblage des composants générés, il est indispensable de garantir la cohérence des états des ressources partagées. Pour cela, il est nécessaire d’introduire dans les composants partageant des ressources, des mécanismes de notification et de synchronisation ; • l’intégration du résultat de l’adaptation structurelle

Le résultat de la sous-étape précédente fournit un assemblage de composants dont le compor- tement est identique à celui du composant initial. Cependant, les propriétés d’interopérabilité et de transparence ne sont pas respectées. Ainsi, l’objectif de cette dernière étape est d’intégrer ces propriétés à l’assemblage. Le résultat de l’adaptation est encapsulé dans un composant dont la structure externe est identique à celle du composant initial.

3.2.3.1 Assemblage des composants générés

Comme nous l’avons mentionné précédemment, l’assemblage des nouvelles entités générées au cours de la fragmentation du composant initial a pour objectif de garantir l’intégrité et la cohérence du résultat de la transformation. La réalisation de cette tâche passe par :

• le maintien de l’intégrité fonctionnelle des composants créés

Certains composants créés lors de l’étape de décomposition de notre processus de restructuration peuvent ne pas définir, dans leurs espaces de noms, certaines entités structurelles (par exemple, les méthodes) dont ils ont besoin pour l’exécution de leurs services. Ces entités sont en fait définies dans l’implémentation d’autres sous-composants générés lors de la fragmentation. Donc, pour garantir l’intégrité structurelle et fonctionnelle des composants créés, il est nécessaire de leurs

Figure 3.10 – Phase de recomposition du composant adapté

introduire des mécanismes leurs permettant d’accéder aux entités structurelles dont ils ont besoins pour fonctionner.

En fait, avant la fragmentation, une méthode pouvait invoquer une autre méthode de manière clas- sique (i.e. appel de méthodes standard dans l’orienté objet par envoi de message). Cependant, après transformation, la méthode invoquée peut être devenue un service fourni par un autre composant généré. De ce fait, le maintien de l’intégrité passe par la transformation d’appels de méthodes en appels de services fournis par d’autres composants qui ont été générés. De plus, il est nécessaire d’introduire dans les composants concernés, de nouvelles interfaces leurs permettant d’accéder à ces services qui se trouvent fournis par d’autres composants. Nous appelons ces interfaces, des in- terfaces de communication. Leur mise en œuvre est décrite lors de la présentation de notre modèle de composants support de l’adaptation structurelle (voir Section 3.3) ;

• le maintien de la cohérence entre les différents composants créés

Les nouveaux composants issus de l’étape de décomposition de notre processus de restructura- tion peuvent partager des ressources logicielles. Comme nous l’avons défini précédemment, une ressource possède un état qui peut être mis à jour et dont la persistance est supérieure à celle de la méthode dans laquelle elle est utilisée. De ce fait, l’état de chacune des ressources logicielles partagées doit rester cohérent pour maintenir la cohérence de l’assemblage de composants générés. Étant donné que nous avons choisi une stratégie de duplication des ressources partagées, leur gestion nécessite l’introduction de mécanismes permettant d’assurer la cohérence des états des différentes copies locales de ces ressources. Ces mécanismes de gestion de partage se chargent de deux tâches :

1. la communication des états de ressources entre les composants

La première tâche consiste à gérer les échanges entre les différents composants définissant au moins une ressource partagée afin de pouvoir préserver la cohérence de leur état. Cette tâche est accomplie au travers des interfaces de notification dont nous détaillerons la mise en œuvre lors de la présentation de notre modèle de composants support de l’adaptation struc- turelle (voir Section 3.3) ;

2. la synchronisation des accès aux ressources par les composants.

La deuxième tâche concerne l’interdiction de l’accès multiple et simultané à une ressource. Cette tâche est réalisée au travers des interfaces de synchronisation dont nous détaillerons la mise en œuvre lors de la présentation de notre modèle de composants support de l’adaptation structurelle (voir Section 3.3).

3.2.3.2 Intégration du composant composite

Afin que le résultat du processus de transformation respecte les propriétés de transparence et d’en- capsulation, l’assemblage obtenu précédemment est encapsulé dans un composant composite dont la structure externe et le comportement sont identiques à celui du composant avant sa transformation. De plus, nous introduisons dans le composite, des mécanismes permettant de configurer certaines propriétés liées à la composition.

Définition Un composant composite est un composant logiciel ayant des liens de composition avec

d’autres composants logiciels, dénommés ses sous-composants (ou composants internes), qui dé- crivent chacun une de ses parties. Ces composants peuvent être à leur tour des composants- composites (i.e. un sous-composant peut être composé d’autres composants) ou des composants simples. Ainsi, un composite est avant tout un composant. Il est lié à ses sous-composants par la relation de composition.

En fait, les composants composites permettent de représenter des composants complexes par la com- position de parties représentées par des composants ayant des liens structurels (i.e. services composés d’autres services), fonctionnels (i.e. services nécessitant l’utilisation d’autres services) ou plus générale- ment sémantiques (i.e. regrouper un ensemble de services suivant un même thème) entre eux. Les sous- composants peuvent être assemblés afin de remplir les services du composite. Le composant composite dispose de ses propres ports et interfaces. Les services fournis par un composant composite peuvent être délégués à un de ses sous-composants ou bien ils peuvent être propres au composite.

L’encapsulation de l’assemblage obtenu précédemment passe par la génération d’une membrane qui va permettre de masquer la structure interne du composant résultat de l’adaptation et la mise en œuvre de mécanismes permettant d’assurer les communications entre cette membrane et les sous-composants

concernés1. Ces deux tâches sont étroitement liées au modèle de composants utilisé. Dans le cadre du

modèle de composants Fractal, l’encapsulation passe uniquement par une modification de la description de l’architecture de l’application contenant le composant adapté : définition du composite (désignation, interfaces fournies et requises définies, etc.) et par la mise en place de liaisons d’exportation entre le composite et ses sous-composants.

Exemple de l’agenda-partagé

Le composant Agenda-partagé encapsule les composants générés (GestionnaireDeReunion, Gestionnai-

reDAbsence, etc.) (lignes 5-25). Il définit les mêmes interfaces fournies et requises que le composant

initial (lignes 6-8) qui sont liées aux interfaces fournies par les sous-composants correspondants (lignes 22-24). Ainsi, la nouvelle description de l’architecture du composant composite obtenu après adaptation du composant Agenda-partagé est la suivante :

1_{La mise en œuvre de ces mécanismes est réalisée au travers des interfaces de communication entre le composite et ses}

sous-composants, que nous détaillerons lors de la présentation de notre modèle de composants structurellement adaptés (voir Section 3.3)

1 <? xml v e r s i o n = " 1 . 0 " e n c o d i n g = " ISO−8859−1 " ?>

2 < !DOCTYPE d e f i n i t i o n PUBLIC "−// o b j e c t w e b . o r g / / DTD F r a c t a l ADL 2 . 0 / / EN"

3 " c l a s s p a t h : / / o r g / o b j e c t w e b / f r a c t a l / a d l / xml / s t a n d a r d . d t d " > 4 5 < d e f i n i t i o n name= " A g e n d a P a r t a g é " > 6 < i n t e r f a c e name= " I t _ r e u n i o n " r o l e = " s e r v e r " s i g n a t u r e = " R e u n i o n " / > 7 < i n t e r f a c e name= " I t _ a b s e n c e " r o l e = " s e r v e r " s i g n a t u r e = " A bs ence " / > 8 . . . 9 < i n t e r f a c e name= " I t _ M a i l _ s e n d e r " r o l e = " c l i e n t " s i g n a t u r e = " M a i l _ s e n d e r " / > 10 < com ponent name= " G e s t i o n n a i r e D e R e u n i o n " >

11 < i n t e r f a c e name= " I t _ r e u n i o n " r o l e = " s e r v e r " s i g n a t u r e = " R e u n i o n " / > 12 < i n t e r f a c e name= " I t _ a b s e n c e " r o l e = " c l i e n t " s i g n a t u r e = " A bs ence " / > 13 < i n t e r f a c e name= " I t _ M a i l _ s e n d e r " r o l e = " c l i e n t " s i g n a t u r e = " M a i l _ s e n d e r " / > 14 . . . 15 < / com ponent > 16

17 < com ponent name= " G e s t i o n n a i r e D A b s e n c e " >

18 < i n t e r f a c e name= " I t _ a b s e n c e " r o l e = " s e r v e r " s i g n a t u r e = " A bs ence " / > 19 . . . 20 < / com ponent > 21 22 < b i n d i n g c l i e n t = " G e s t i o n n a i r e D e R e u n i o n . I t _ a b s e n c e " s e r v e r = " G e s t i o n n a i r e D A b s e n c e . I t _ a b s e n c e " / > 23 . . . 24 < b i n d i n g c l i e n t = " t h i s . I t _ r e u n i o n " s e r v e r = " G e s t i o n n a i r e D e R e u n i o n . I t _ r e u n i o n " / > 25 < b i n d i n g c l i e n t = " t h i s . I t _ a b s e n c e " s e r v e r = " G e s t i o n n a i r e D A b s e n c e . I t _ a b s e n c e " / > 26 . . . 27 < b i n d i n g c l i e n t = " G e s t i o n n a i r e D e R e u n i o n . I t _ M a i l _ s e n d e r " s e r v e r = " t h i s . I t _ M a i l _ s e n d e r " / > 28 . . . 29 < / d e f i n i t i o n >

Nous pouvons noter que dans le cadre du modèle de composants Fractal et de son implémentation Julia, aucune modification au niveau implémentatoire n’est nécessaire pour la mise en œuvre des inter- faces de communication entre un composite et ses sous-composants.

L’encapsulation permet ainsi de masquer les services issus de l’adaptation (i.e. filtrage de l’accès aux services). En fait, le composant fournit les mêmes services fonctionnels que ceux disponibles avant son adaptation. Par ailleurs, il peut intégrer de nouveaux services non fonctionnels destinés à manipuler ses sous-composants. Ces services permettent, par exemple le paramétrage d’un déploiement distribué de ce nouveau composant composite ou bien la possibilité de réaliser une nouvelle adaptation. La figure 3.11 présente le composant composite associé au composant Agenda-partagé.