Configuration du composant composite issu de la transformation structurelle

Comme nous l’avons évoqué précédemment, afin d’introduire de nouveaux points de variabilité, nous proposons de fournir à un acteur de l’adaptation des mécanismes lui permettant de configurer certaines propriétés du composite résultat de l’adaptation afin qu’il réponde à plus de besoins liés à son utilisation. Les propriétés que nous proposons de rendre configurables font références à la relation de composition entre le composite et ses sous-composants [23, 127]. Elles peuvent être configurées de manière à intro- duire des facilités d’adaptation ou à gérer la politique de sécurité mise en place par un acteur externe de l’adaptation. Les propriétés configurables sont les suivantes :

• la cardinalité et la cardinalité inverse

la cardinalité représente le nombre de sous-composants pouvant appartenir à un objet compo- site via un lien de composition. Si ce nombre est égal à 0, cela signifie que la composition de composants est impossible. Si ce nombre est supérieur à 1, cela implique que la composition de composants est possible.

La cardinalité inverse correspond au nombre de composites qui pourront se partager un même sous-composant via un lien de composition. Si ce nombre est strictement supérieur à 1, cela implique que le partage des sous-composants est possible. C’est-à-dire qu’un composant réfé- rencé par un lien de composition partagé pourra être référencé par un nombre quelconque de liens de composition partagé et donc pourra faire partie de plusieurs composites simultanément. Si ce nombre est égal à 1, cela signifie l’exclusivité de chaque sous-composant à son composite. Dans ce cas, un composant référencé par un lien de composition exclusif ne peut être référencé que par ce seul lien de composition et ne peut donc faire partie que d’un seul composite. Enfin, si ce nombre est égal à 0, cela signifie que la composition de composants est impossible ;

• le niveau de composition

cette propriété permet de spécifier le niveau de composition possible. Si ce nombre est égal à 0, cela signifie que la composition de composants est impossible.

La limitation du nombre de composition possible peut permettre de diminuer les risques de conflits liés à la propagation des valeurs des attributs et permet d’augmenter la compréhension de la struc- ture du composant ;

• le degré d’encapsulation des sous-composants

cette propriété fait référence à la visibilité et à l’accessibilité des sous-composants vis-à-vis des autres composants de l’application (i.e. autres que ceux générés au cours de la fragmentation du composant initial). Il existe quatre configurations possibles pour cette propriété :

1. un composant « boîtes blanches »

Tout d’abord, le composite peut être considéré comme une boîte blanche (voir Figure 3.12, cas A). Dans ce cas tous ses sous-composants sont visibles et accessibles directement par les

autres composants de l’application. Cette stratégie de composition implique une très faible encapsulation des sous-composants. Elle est généralement utilisée pour regrouper un en- semble de services fonctionnellement indépendants mais sémantiquement proches dans un même composant ;

2. un composant « boîte noire »

Dans le cas d’un composite boîte noire (voir Figure 3.12, cas B), ses sous-composants ne sont ni visibles ni accessibles par les autres composants de l’application. Tous les appels des services des sous-composants provenant d’un composant externe doivent passer par le composite pour accéder aux services fournis par les sous-composants. Les sous-composants sont donc totalement encapsulés dans le composant composite. Tout composant interagissant avec le composite ignore la manière dont il est constitué. Étant donné qu’il est obligatoire de passer par le composite, il est donc possible de mettre en place très facilement des outils de traitement des messages entrant et sortant provenant de l’extérieur du composant (i.e. autres composants de l’application) et ainsi faciliter la maintenance et l’adaptation de l’application. De plus, la sécurité est un atout majeur des boîtes noires car les composants internes sont inaccessibles directement et donc protégés ;

3. un composant « boîte grise »

Lorsqu’un composite est spécifié comme étant une boîte grise (voir Figure 3.12, cas C), sa structure interne est visible par les autres composants de l’application mais ses sous- composants ne sont pas accessibles directement. Seuls les services fournis par le composite sont utilisables. En termes d’accessibilité, un composant « boîte grise » offre les mêmes ca- ractéristiques qu’un composant « boîte noire » ;

4. un composant « boîte mixte »

Si le composite est considéré comme une boîte mixte (voir Figure 3.12, cas D), certains sous- composants sont accessibles directement par les autres composants de l’application mais pas tous.

Cette propriété d’encapsulation peut être utilisée pour masquer certains sous-composants ou ser- vices en fonction de la politique de sécurité établie. Par exemple, concernant le composant Agenda-

partagé, le sous-composant GestionnaireDAgenda contenant les agendas personnels, peut être

configuré, en utilisant cette propriété (i.e. avec la valeur « boîte mixte »), comme étant invisible et inaccessible pour les autres composants de l’application.

• l’accessibilité interne

la propriété d’accessibilité interne permet de spécifier comment un sous-composant accède à un autre sous-composant du composite. Cette propriété peut être configurée de la manière suivante : l’accès peut être effectué via le composant composite ou bien via une référence directe vers le sous-composant en question. Nous distinguons trois stratégies possibles :

1. un accès direct

La première stratégie consiste à autoriser un accès direct aux services d’un autre sous- composant du composite (voir Figure 3.13, cas A) ;

Figure 3.12 – Configuration du degré d’encapsulation des sous-composants du composite résultat de l’adaptation structurelle

2. un accès par les services du composite

La deuxième stratégie consiste à passer par le composite pour accéder à un service d’un autre sous-composant (voir Figure 3.13, cas B). Ainsi, les messages échangés entre les sous- composants doivent traverser la membrane du composite puis sont redirigés au travers d’un lien d’exportation vers le service invoqué (i.e. délégation d’un service du composite vers un service d’un sous-composant). Dans ce cas, l’encapsulation des sous-composants est faible car ces derniers sont capables de traverser la membrane pour aller se connecter à un port (ou une interface) fourni par le composite. Cette approche est donc peu compatible avec la stratégie boîte noire où l’encapsulation est forte (i.e. les messages échangés à l’intérieur du composite ne doivent pas transiter par l’extérieur de ce dernier) ;

3. un accès par l’implémentation non-fonctionnelle du composite (i.e. membrane du composite) La dernière solution réside dans l’utilisation de la membrane du composite comme connec- teur entre les sous-composants (voir Figure 3.13, cas C). Cette solution permet de traiter facilement les messages échangés entre les sous-composants (i.e. possibilité d’adaptation en redirigeant les messages échangés) où même faciliter certaines tâches comme la gestion de la concurrence et de la synchronisation relatives aux ressources partagées par plusieurs sous- composants. En fait, elle permet de centraliser les contrôleurs du composite au niveau de sa membrane.

Cette propriété peut être utilisée pour faciliter l’insertion de code d’adaptation fonctionnel. En effet, si l’envoi de message entre les sous-composants transite par le composite, il devient plus facile de contrôler ces messages et de les modifier, si besoin est. Cependant, une telle stratégie peut entraîner une dégradation des performances du composant si le nombre de messages échan-

Figure 3.13 – Configuration de la propriété d’accessibilité interne aux services des sous-composants du composite issu de l’adaptation structurelle

gés est trop important. De ce fait, une telle stratégie ne peut être envisagée que si l’application le permet. Ainsi, la configuration de cette propriété dépend fortement de l’application qui contient le composant adapté donc elle ne doit être réalisée que par un acteur extérieur de l’adaptation ; • le cycle de vie du composite et de ses sous-composants

la gestion du cycle de vie est relative aux différentes stratégies envisageables lors de l’instancia- tion, de l’arrêt (i.e. dépendances comportementales) ou de la suppression (i.e. dépendances exis- tentielles) du composite ou bien de l’un de ses sous-composants.

– Instanciation du composite résultat de l’adaptation

La propriété d’instanciation des composants fait référence à la stratégie d’instanciation du com- posite et de ses sous-composants adoptée lors du déploiement de l’application. L’approche choi- sie peut être descendante (i.e. d’abord le composite est instancié, ensuite les sous-composants), ascendante (i.e. d’abord les sous-composants ensuite le composite), mixte ou bien dynamique. La stratégie adoptée est étroitement liée au type de composant manipulé (boîte blanche, boîte grise, boîte noire ou mixte) :

1. une approche ascendante

L’instanciation ascendante d’un composant logiciel impose la création des instances de ses sous-composants avant celle du composite. Cette stratégie induit une certaine indé- pendance du composite vis-à-vis de ses sous-composants. L’instanciation ascendante est généralement utilisée pour assembler des composants existants et les encapsuler au sein d’un composite. Tant que le composite n’est pas instancié les sous-composants sont vi- sibles et accessibles directement ; ce qui posent des problèmes de sécurité si le composant composite n’est pas spécifié comme étant « boîte blanche » ;

2. une approche descendante

Lors d’une instanciation descendante, le composite est instancié avant ses sous-composants. Une telle approche induit une forte encapsulation des sous-composants dans le composite. Contrairement à l’instanciation ascendante, si les acteurs externes de l’adaptation le sou- haitent, à aucun moment il est possible d’accéder aux instances des sous-composants. Cette approche est donc à privilégier pour la création de composants « boîtes noires » ou de com- posants « boîtes grises » ;

3. une approche mixte

Une stratégie mixte entre l’instanciation ascendante et descendante peut être réalisée. Par exemple, si l’on prend le cas des composants mixtes où l’on à un ensemble de sous- composants visibles et accessibles ainsi qu’un ensemble de sous-composants cachés et in- accessibles, l’on peut instaurer une stratégie d’instanciation des sous-composants qui serait la suivante : tout d’abord, on instancie les composants visibles (i.e. ce qui permet d’utili- ser des composants déjà instanciés), ensuite le composite et pour finir les sous-composants restants (i.e. composants cachés). En fait cette stratégie consiste à instrumenter les sous- composants et le composite dans n’importe quel ordre ;

4. une approche par instanciation dynamique des sous-composants

Une stratégie d’instanciation dynamique des composants permet d’instancier un composant dès le premier appel à un de ses services. Tant qu’un composant n’est pas utilisé, il n’est pas instancié. Cette méthode peut se révéler judicieuse pour des applications destinées à être exécutées dans des environnements à faibles ressources. Plusieurs stratégies peuvent être établies en fonction du moment de création de l’instance du composite. Celle-ci peut être créée dès l’appel à n’importe quel service de l’un de ses sous-composants ou bien uni- quement lorsque l’un de ses services est appelé.

Le choix de la stratégie d’instanciation des composants dépend d’une part, de l’environnement de déploiement de l’application (par exemple, dans le cadre d’environnement à ressources limi- tées, il est préférable d’opter pour une instanciation dynamique) et d’autre part de la politique de sécurité mise en place par l’administrateur de l’application (par exemple, contrairement à l’instanciation ascendante, l’approche descendante permet de garantir l’encapsulation totale des sous-composants ; de ce fait, la sécurité en est renforcée).

– Gestion des dépendances existentielles

Les dépendances existentielles se traduisent par deux propriétés : d’une part, la dépendance des liens de composition (i.e. propriété permettant d’établir le processus à appliquer lors de la sup- pression du composite) et, d’autre part, la prédominance des liens de composition (i.e. propriété permettant de spécifier le processus à mettre en œuvre lorsqu’un sous-composant est supprimé). L’existence des composites est fortement liée à celle de ses composants et réciproquement.

1. Propriété de dominance existentielle des liens de composition

Cette propriété permet d’établir le processus à appliquer lors de la destruction du compo- site. Plusieurs stratégies sont possibles (voir Figure 3.14) :

(a) la destruction totale du composant

La première solution consiste à détruite tous les sous-composants du composite (voir Figure 3.14, cas 1). Dans ce cas, le composite est vu comme une unité indivisible. Si un de ses sous-composants est détruit, le composite n’a plus de sémantique et donc l’existence de ses autres sous-composants est mise en question. Cette stratégie à forte sémantique de la composition peut être couplée avec les propriétés de boîtes noires ou de boîtes grises où la préservation de la sécurité est mise en avant. Étant donné que les sous-composants n’étaient pas accessibles directement, leur destruction permet de conserver cette propriété ;

(b) la destruction de la membrane

La deuxième stratégie réside uniquement dans la destruction de la membrane du com- posite (voir Figure 3.14, cas 2). Dans ce cas, le composite n’existe plus mais les sous- composants deviennent des composants (i.e. pouvant être composite) accessibles di- rectement par les autres composants de l’application. Cette stratégie n’est envisageable que pour les composites boîtes blanches car ses sous-composants peuvent être acces- sibles directement ;

(c) la destruction partielle du composant

La dernière solution consiste à détruire une partie des sous-composants (voir Figure 3.14, cas 3). Les composants non détruits restent accessibles directement. Cette solu- tion peut être mise en œuvre pour les composites boîte blanche où les composants à conserver seront spécifiés parmi l’ensemble de tous les sous-composants mais égale- ment pour les composants boîtes grises où les composants à conserver seront spécifiés parmi l’ensemble des sous-composants accessibles de l’extérieur du composite (i.e. les composants inaccessibles seront automatiquement détruits).

2. Propriété de prédominance existentielle des liens de composition

La propriété de prédominance des liens de composition fait référence à la relation entre un sous-composant et son composite. Elle permet de spécifier le processus à mettre en œuvre lorsqu’un sous-composant est détruit. Les stratégies possibles diffèrent essentiellement par la conservation ou la destruction du composite (voir Figure 3.15).

Tout d’abord, le choix de destruction du composite présuppose une forte relation séman- tique entre les sous-composants. Ainsi, si un sous-composant est supprimé, le composite n’a plus de sens d’un point de vue sémantique (i.e. encapsulation forte). Cette stratégie peut avoir des répercutions sur la propriété de dépendance. En effet, la suppression d’un sous-composant peut donc entraîner la suppression de tous les autres sous-composants du composite (i.e. le composite sera totalement détruit).

Une autre stratégie consisterait à détruire uniquement le sous-composant concerné et à conserver le composite. Cependant, la destruction d’un sous-composant peut avoir des répercutions dans le reste du composite au niveau des services. Par exemple, si le sous- composant fait partie d’un assemblage permettant de fournir un service, ce dernier doit être supprimé des services fournis par le composite. De plus, si d’autres sous-composants uti- lisent un des services fournis par le composant supprimé ou bien sont utilisés exclusivement dans le cadre d’un service nécessitant le composant supprimé, il peut être envisageable de

Figure 3.14 – Configuration des propriétés de dominances existentielles du composite issu de l’adaptation structurelle

supprimer les services faisant appels au moins à un service du composant supprimé ou bien de supprimer les sous-composants nécessitant le composant supprimé et ce récursivement. Par ailleurs, si le composite est boîte blanche, il doit pouvoir être possible de conserver les composants internes déconnectés.

– Gestion des dépendances comportementales

Concernant les dépendances comportementales, le principe est le même que pour les dépen- dances existancielles à la différence qu’au lieu d’étudier les conséquences de la suppression du composite ou de l’un de ses sous-composants, sont spécifiées les répercussions de l’arrêt du composite ou de l’un de ses sous-composants.

• la propagation des services

un composite peut propager certains de ses services2vers un de ses sous-composants et vice-versa.

Cette propriété relative à la propagation des services peut être configurée de la manière suivante : tout d’abord, du composite vers ses sous-composants (i.e. un service du composite est partagé par ses sous-composants), ou bien d’un sous-composant vers son composite (i.e. un service d’un sous-composant est partagé avec son composite).

Cette propriété peut être utilisée notamment dans le cadre de composants « boîtes noires » afin d’autoriser l’accès à un service d’un sous-composant par l’intermédiaire du composant (i.e. ce service sera alors partagé entre le sous-composant et le composite). Également, dans le cadre de composants « boîtes blanches », la possibilité d’invoquer un service du composite en accédant directement à un sous-composant sera donnée à l’utilisateur (i.e. propagation du sous-composant vers le composite).

2

Figure 3.15 – Configuration des propriétés de prédominances existentielles du composite issu de l’adap- tation structurelle

3.2.4.2 Intégration de mécanismes de distribution dans le composite issu de la transformation