C HAPITRE 2 Adaptation structurelle
2.5 Démarche et approche de problématique
2.5.1 Les différents problèmes traités dans le cadre de l’adaptation structurelle
Notre objectif dans cette thèse est de traiter différents problèmes liés à l’adaptation structurelle (voir Figure 2.3) de manière à proposer une approche complète permettant d’adapter la structure d’un compo- sant logiciel existant. Les différents problèmes traités sont les suivants :
• l’adaptation structurelle par la ré-ingénierie de composants existants et son application pour l’in-
troduction de la propriété de distribution
Dans un premier temps, notre objectif va être de définir une approche d’adaptation structurelle per- mettant à partir du code source d’un composant existant d’obtenir un composant dont la structure est conforme à de nouveaux besoins liés à son utilisation. Pour cela, nous proposons un modèle de composants structurellement adaptés définissant les interfaces permettant à un composant adapté de garantir son intégrité et sa cohérence et un processus de ré-ingénierie dont l’objectif est de transformer tout composant existant en un composant conforme à notre modèle de composants structurellement adaptés. L’approche est semi-automatique : elle nécessite une spécification ma- nuelle de la structure du composant adaptée au nouveau contexte. Le processus de transformation est quant à lui entièrement automatique.
Cette approche d’adaptation structurelle peut être utilisée pour intégrer à un composant des méca- nismes de distribution. Pour cela, nous devons proposer un modèle de composants structurellement adaptés distribués et un processus permettant d’obtenir un composant conforme à ce modèle à par- tir d’un composant issu de notre processus d’adaptation structurelle statique. Ces propositions doivent être présentées comme des extensions du modèle de composants structurellement adaptés et du processus de transformation structurelle ;
• l’adaptation structurelle dynamique de composants logiciels
L’adaptation structurelle par la transformation statique ne permet pas de répondre à tous les be- soins relatifs à l’adaptation de la structure. En effet, il doit être possible d’adapter la structure d’un composant logiciel sans arrêter l’application qui le contient ; et ce afin de répondre à des besoins intervenant lors de l’exécution du composant. Ainsi, nous devons proposer une approche permettant de réaliser l’adaptation structurelle de manière dynamique. Cette proposition passe par la définition d’un modèle de composants structurellement et dynamiquement adaptables et d’un processus de ré-ingénierie permettant de rendre un composant existant conforme à ce modèle ; • l’adaptation structurelle automatique de composants logiciels
Par ailleurs, dans certains environnements tels que dans les environnements ubiquitaires, le contexte d’exécution d’une application change en permanence. De plus, le besoin en adaptation structurelle est très présent comme nous avons pu le constater dans le chapitre précédent. De ce fait, il ne peut être envisageable de fournir une approche d’adaptation semi-automatique. Ainsi, notre objectif va être de proposer une approche réalisant de manière automatique tout un processus d’adaptation ; y compris le déclenchement de l’adaptation et la spécification d’une structure pour le composant, qui soit adaptée à une nouvelle situation. Cette proposition passe par la définition d’un modèle de composants structurellement auto-adaptatifs et d’un processus de ré-ingénierie permettant de rendre un composant existant conforme à ce modèle ;
• l’adaptation structurelle d’architectures logicielles
L’adaptation structurelle d’un composant logiciel peut avoir des impacts sur les autres composants d’une architecture logicielle. De ce fait, nous devons proposer une approche permettant de réaliser l’adaptation structurelle au niveau d’architectures logicielles afin de tenir compte des adaptations de chaque composant qu’elle contient. Pour cela, il est nécessaire de proposer une stratégie de co- ordination de l’adaptation structurelle au niveau macro (i.e. au niveau de l’architecture logicielle).
Figure 2.3 – Présentation des différents problèmes à traiter dans le cadre de l’adaptation structurelle
2.5.2 Contraintes et limitations du cadre de l’étude
L’étude de notre approche d’adaptation structurelle nous a imposé certains choix ou hypothèses de travail que nous exposons dans cette section.
Choix réalisés pour la mise en œuvre de notre approche Avant de développer notre approche d’adap- tation structurelle, nous avons du faire un certain nombre de choix nous permettant de mieux cerner notre apport. Ces choix sont les suivants :
• adaptation de la structure interne de composants logiciels
Dans nos travaux, nous avons choisi de nous focaliser sur l’adaptation de la structure interne d’un composant logiciel pour répondre à des besoins tels que le déploiement ou le chargement flexible de services. Une telle stratégie peut nécessiter la fragmentation du composant (ou des en- tités structurelles qui le composent) à adapter et sa reconstitution de manière à garantir le résultat de l’adaptation. Or, comme nous l’avons vu précédemment, un composant est constitué de partie architecturale et d’une partie implémentatoire. De ce fait, l’adaptation structurelle va nécessiter l’étude de problèmes relatifs au partitionnement et à la parallélisation de code tels que la gestion de ressources partagées, etc. ;
• adaptation au niveau des interfaces de composant
de base qui ne peuvent pas être fragmentées. Ainsi, la restructuration d’un composant est réa- lisée par le regroupement des interfaces fournies par le composant adapté au sein de nouveaux composants considérés comme des sous-composants du composant adapté.
Nous avons choisi d’opérer à ce niveau de granularité car il nous assure une flexibilité suffisante dans la majorité des cas où la restructuration d’un composant est nécessaire. Cependant, il peut être envisagé des extensions à notre approche permettant de manipuler des entités structurelles de plus bas niveaux telles que les points d’entrées d’une interface, les méthodes, etc. comme des briques de base à la restructuration d’un composant.
Hypothèses de travail Les choix que nous avons pris nous imposent de fixer des hypothèses sur le composant à adapter et sur le modèle de composants utilisés afin de mettre en œuvre notre approche d’adaptation structurelle. Ces hypothèses sont les suivantes :
• indépendance du comportement et de la structure
Nous supposons également que l’implémentation du composant que l’on souhaite adapter est in- dépendante vis-à-vis de sa structure. Ainsi, les services métiers du composant à adapter ne doivent pas faire appel à des données relatives à sa structure. Par exemple, les informations relatives aux nombres d’interfaces requises par d’autres composants de l’application liés aux interfaces fournies par le composant à adapter ne doivent pas être utilisées par les services métiers de ce dernier. Il en va de même en ce qui concerne le nombre de sous-composants contenus dans le composant ou le nombre de composants partagés ;
• disponibilité du code source des composants pour nos processus de ré-ingénierie
La mise en œuvre de nos processus de ré-ingénierie permettant de réaliser l’adaptation structurelle de composants existants ou bien d’introduire des mécanismes d’auto-adaptation dynamique dans des composants existants nécessite la disponibilité du code source du composant à adapter. Cette hypothèse n’est pas en contradiction avec le principe des COTS du fait du fort développement des logiciels « open-source ». De plus, différentes stratégies peuvent être envisagées pour permettre la réalisation d’un processus d’adaptation structurelle sans que l’utilisateur puisse accéder au code source de l’application ;
• implémentation orientée objet, sans objet actif et sans accès à des entités logicielles ou matérielles
externes à l’application
Dans le cadre de notre étude, nous avons supposé que les composants sur lesquels nous agissons sont implémentés dans un langage orienté objet et qu’ils ne contiennent pas d’objets actifs tels que les threads. Cette dernière hypothèse, couramment émise dans les travaux de transformation de code (tels que le partitionnement, etc.), nous permet d’éviter certains problèmes liés à la paral- lélisation de code qui ne font pas l’objet de cette thèse. Pour plus de détails sur le traitement de
threads dans le cadre de partitionnement de code, nous invitons le lecteur à consulter [116].
Par ailleurs, nous supposons que les services du composant à adapter n’utilisent pas des entités logicielles (fichiers, base de données, etc.) ou matérielles externes (périphérique spécifique, etc.) à l’application. En effet, la prise en compte de ces entités ne peut être effective que si ces entités sont dotées de caractéristiques spécifiques. Notamment, elles doivent pouvoir être accédées à distance ; ce qui peut parfois se révéler impossible ou très complexe à mettre en œuvre. De plus, elle peut nécessiter un traitement spécifique qui, dans la majorité des cas, ne peut pas être automatisé. Étant
donné que nous avons pour objectif de proposer une approche entièrement automatique, nous ne pouvons pas prendre en considération l’accès à ces entités.
2.5.3 Notre modèle de composants restructurables
Pour mettre en œuvre notre approche, nous avons défini un modèle générique de référence auxquels les composants que nous proposons d’adapter devront être conformes. Puis, nous avons choisi un modèle de composants existant dans la littérature qui soit conforme à notre modèle générique afin d’illustrer notre approche.
2.5.3.1 Modèle générique de référence
Le modèle de composants à adapter est un modèle hiérarchique (i.e. modèle permettant de concevoir des composants de type composite). Cette propriété nous permet notamment de garantir la transparence de l’adaptation. En effet, les composants issus de la fragmentation du composant à adapter pourront être encapsulés dans un composant composite dont la structure externe sera identique à celle du composant initial. Dans le cas où le modèle de composants utilisé n’est pas hiérarchique, notre approche peut être utilisée pour fragmenter un composant existant en plusieurs composants. L’assemblage obtenu pourra remplacer le composant existant. Cependant, dans ce cas, nous ne pouvons plus parler de processus d’adaptation car certaines propriétés du composant ne sont plus préservées (transparence de l’adaptation, encapsulation des sous-composants générés, etc.).
Pour illustrer notre approche, nous considérons des composants logiciels conformes à la spécification générique décrite dans la figure 2.4. Concernant le niveau architectural, les composants peuvent être de type composite ou primitif. Chaque composant définit un ensemble d’interfaces qui peuvent être fournies ou requises. Une interface peut contenir un ou plusieurs services. Pour modéliser le niveau implémen- tatoire, nous avons utilisé le modèle objet. Comme nous pouvons le remarquer les deux niveaux sont étroitement liés : un composant primitif est implémenté par une hiérarchie de classes, une interface de composant est associé à une interface objet et un service correspond à une méthode de la classe d’implé- mentation du composant. Ainsi, la restructuration d’un composant doit être réalisée sur les deux niveaux (architectural et implémentatoire). En fait, toute mise à jour de la structure sur l’un des deux niveaux doit impérativement être répercutée sur l’autre niveau.
2.5.3.2 Modèle applicatif
Le modèle de composants, proposé dans la littérature, le plus proche de la spécification présentée dans la figure 2.4 est le modèle de composants Fractal [39] et son implémentation Java appelé Julia [38]. La seule différence réside dans l’association d’un composant primitif à une seule classe d’implémenta- tion. Le niveau architectural d’un composant Fractal est, quant à lui, décrit au travers d’un langage de description d’architecture appelé FractalADL [38] et dont la DTD est fournie dans la figure 5.3. De plus, Fractal présente les caractéristiques idéales pour mettre en œuvre une adaptation dynamique à savoir qu’il intègre dans son modèle les propriétés d’introspection et d’intercession comme nous avons pu le constater précédemment. De ce fait, pour illustrer notre approche, nous avons utilisé ce modèle de com- posants. Pour plus de détails sur le choix du modèle de composants Fractal et de son implémentation Julia, consulter le chapitre 5.
Figure 2.4 – Modèle de composants logiciels de référence