Cadre logiciel pour l’adaptation des architectures

Télécharger le fichier pdf d’un mémoire de fin d’études

Description des Architectures

Approches ADL

Les premiers travaux r´ealis´es pour d´ecrire les architectures logicielles ont fait naˆıtre les langages de description d’architecture. En accord avec la notion d’architecture logicielle, l’id´ee est de fournir une structure de haut niveau de l’application plutˆot que l’implantation dans un code source sp´ecifique, Vestal (1993). Il faut pr´eciser qu’il n’existe pas une d´efinition unique des ADL, mais en g´en´eral on accepte qu’un ADL fournit un mod`ele explicite de composants, de connecteurs et de leur configuration. Optionnellement, un ADL pourrait fournir des outils pour la g´en´eration de code source bas´es sur les architectures et pour la gestion de l’´evolution des applications.
Depuis le d´ebut des ann´ees 90 bon nombre d’ADLs ont vu le jour. Parmi les plus repr´esentatifs correspondant `a une premi`ere g´en´eration nous trouvons notamment : Darwin Magee et al. (1995); Magee et Kramer (1996), Rapide Luckham et al. (1995),,Wright Allen (1997); Allen et Garlan (1997). Alors que l’on peut consid´erer comme partie d’une deuxi`eme g´en´eration aux ADLs : xADL Dashofy et al. (2001) et -ADL Oquendo (2004). Chacun propose une architecture `a sa mani`ere, les uns privil´egiant les ´el´ements architecturaux et leur assemblage structurel et les autres s’orientant vers la configuration de l’architecture et la dynamique du syst`eme.
Face `a une telle vari´et´e et au manque de consensus Medvidovic et Taylor (2000) ont fait une classification. Nous reprenons leurs d´efinitions et les caract´eristiques par la suite de la section.
Le composant
Le composant est une unit´e de calcul ou de stockage. Il peut ˆetre simple ou composite, et sa fonctionnalit´e peut aller de la simple proc´edure `a une application compl`ete.
Le composant est consid´er´e comme un couple sp´ecification-code : la sp´ecification donne les interfaces, les propri´et´es du composant ; le code correspond `a la mise en oeuvre de la sp´ecification par le composant.
Les caract´eristiques globales d’un composant sont les suivantes :
– L’interface d’un composant est la description de l’ensemble des services offerts et requis par le composant sous la forme de signature de m´ethodes, de type d’objets envoy´es et retourn´es, d’exceptions et de contexte d’ex´ecution. L’interface est un moyen d’expression des liens du composant ainsi que ses contraintes avec l’ext´erieur.
– Le type d’un composant est un concept repr´esentant l’implantation des fonctionnalit´es fournies par le composant. Il s’apparente `a la notion de classe que l’on trouve dans le mod`ele orient´e objet. Ainsi, un type de composant permet la r´eutilisation d’instances de mˆeme fonctionnalit´e soit dans une mˆeme architecture, soit dans des architectures diff´erentes. En fournissant un moyen de d´ecrire, de mani`er explicite, les propri´et´es communes `a un ensemble d’instances d’un mˆeme composant, la notion de type de composant introduit un classificateur qui favorise la compr´ehension d’une architecture et de sa conception.
– La s´emantique du composant est exprim´ee en partie par son interface. Cependant, l’interface, telle qu’elle est d´ecrite ci-dessus, ne permet pas de pr´eciser compl`etement le comportement du composant. La s´emantique doit ˆetre enrichie par un mod`ele plus complet et plus abstrait permettant de sp´ecifier les aspects dynamiques ainsi que les contraintes li´ees `a l’architecture. Ce mod`ele doit garantir une projection coh´erente de la sp´ecification abstraite de l’architecture vers la description de son implantation avec diff´erents niveaux de raffinements. La s´emantique d’un composant s’apparente `a la notion de type dans le mod`ele orient´e objet.
– Les contraintes d´efinissent les limites d’utilisation des composants. Une contrainte est une propri´et´e devant ˆetre v´erifi´ee pour un syst`eme ou pour une de ces parties.
Si celle-ci est viol´ee, le syst`eme est consid´er´e comme incoh´erent. Elle permet ainsi de d´ecrire de mani`ere explicite les d´ependances des parties internes d’un composant comme la sp´ecification de la synchronisation entre composants d’une mˆeme application.
– L’´evolution d’un composant doit ˆetre simple et s’effectuer par le biais de techniques comme le sous typage ou le raffinement. Un ADL doit favoriser la modification, de ses propri´et´es (interface, comportement, implantation) sans perturber son int´egration dans les applications d´ej`a existantes.
– Les propri´et´es non fonctionnelles doivent ˆetre exprim´ees `a part, permettant ainsi une s´eparation dans la sp´ecification du composant des aspects fonctionnels (aspects m´etiers de l’application) et des aspects non fonctionnels ou techniques (aspects transactionnels, de cryptographie, de qualit´e de service). Cette s´eparation permet la simulation du comportement d’un composant `a l’ex´ecution d`es la phase de conception, et de la v´erification de la validit´e de l’architecture logicielle par rapport `a l’architecture mat´erielle et l’environnement d’ex´ecution.
Le connecteur
Le connecteur mod´elise un ensemble d’interactions entre composants. Cette interaction peut aller du simple appel de proc´edure distante aux protocoles de communication.
Tout comme le composant, le connecteur est un couple sp´ecification-code : la sp´ecification d´ecrit les rˆoles des participants `a une interaction ; le code correspond `a l’implantation du connecteur. Cependant, la diff´erence avec le composant est que le connecteur ne correspond pas `a une unique, mais ´eventuellement `a plusieurs unit´es de programmation.
Six caract´eristiques importantes sont `a prendre en compte pour sp´ecifier de mani`ere exhaustive un connecteur. Ces caract´eristiques sont les suivantes :
– L’interface d’un connecteur d´efinit les points d’interactions entre connecteurs et composants. L’interface ne d´ecrit pas des services fonctionnels comme ceux du composant mais s’attache `a d´efinir des m´ecanismes de connexion entre composants.
Certains ADLs nomment ces points d’interactions comme ´etant des rˆoles.
– Le type d’un connecteur correspond `a sa d´efinition abstraite qui reprend les m´ecanismes de communication entre composants ou les m´ecanismes de d´ecision de coordination et de m´ediation. Il permet la description d’interactions simples ou complexes de mani`ere g´en´erique et offre ainsi des possibilit´es de r´eutilisation de protocoles. Par exemple, la sp´ecification d’un connecteur de type RPC qui relie deux composants d´efinit les r`egles du protocole RPC.
– La s´emantique des connecteurs est d´efinie par un mod`ele de haut niveau sp´ecifiant le comportement du connecteur. A l’oppos´e de la s´emantique du composant, qui doit exprimer les fonctionnalit´es d´eduites des buts ou des besoins de l’application, la s´emantique du connecteur doit sp´ecifier le protocole d’interaction. De plus, le protocole d’interaction doit pouvoir ˆetre mod´elis´e et raffin´e lors du passage d’un niveau de description abstraite `a un niveau d’implantation.
– Les contraintes permettent de d´efinir les limites d’utilisation d’un connecteur, c’est-`a-dire les limites d’utilisation du protocole de communication associ´e. Une contrainte est une propri´et´e devant ˆetre v´erifi´ee pour un syst`eme ou pour une de ses parties. Si celle-ci est viol´ee, le syst`eme est consid´er´e comme un syst`eme incoh´erent. Par exemple, le nombre maximum de composants interconnect´es `a travers le connecteur correspond `a une contrainte.
– La maintenance des propri´et´es (interface, comportement) d’un connecteur doit lui permettre d’´evoluer sans perturber son utilisation et son int´egration dans les applications existantes. Il s’agit de maximiser la r´eutilisation par modification ou raffinement des connecteurs existants. Un ADL donnant la possibilit´e de d´efinir un connecteur doit donc permettre de le faire ´evoluer de mani`ere simple et ind´ependante en utilisant le sous typage ou des techniques de raffinement.
– Les propri´et´es non fonctionnelles d’un connecteur concernent tout ce qui ne d´ecoule pas directement de la s´emantique du connecteur. Elles sp´ecifient des besoins qui viennent s’ajouter `a ceux d´ej`a existants et qui favorisent une implantation correcte du connecteur. La sp´ecification de ces propri´et´es est importante puisqu’elle permet de simuler le comportement `a l’ex´ecution, l’analyse, la d´efinition de contraintes et la s´election des connecteurs.

La configuration de l’architecture

La configuration de l’architecture d´efinit les propri´et´es topologiques de l’application : les connections entre composants et connecteurs, mais aussi, selon les ADL, les propri´et´es de concurrence, de r´epartition, de s´ecurit´e, etc. La topologie peut ˆetre dynamique, auquel cas la configuration d´ecrit la topologie ainsi que son ´evolution.
Neuf caract´eristiques sont pr´ecis´ees pour ´evaluer la configuration d’un ADL. Ces caract´eristiques sont les suivantes :
– Un formalisme commun. Une configuration doit permettre de fournir une syntaxe simple et une s´emantique permettant de (a) faciliter la communication entre les diff´erents partenaires d’un projet (concepteurs, d´eveloppeurs, testeurs, architectes),
(b) rendre compr´ehensible la structure d’une application `a partir de la configuration sans entrer dans le d´etail de chaque composant et de chaque connecteur,
(c) sp´ecifier la dynamique d’un syst`eme, c’est-`a-dire l’´evolution de celui-ci au cours de son ex´ecution.
– La composition. La d´efinition de la configuration d’une application doit permettre la mod´elisation et la repr´esentation de la composition `a diff´erents niveaux de d´etail. La notion de configuration sp´ecifie une application par composition hi´erarchique. Ainsi un composant peut ˆetre compos´e de composants, chaque composant ´etant sp´ecifi´e lui-mˆeme de la mˆeme mani`ere, jusqu’au composant dit primitif, c’est-`a-dire non d´ecomposable. L’int´erˆet de ce concept est qu’il permet la sp´ecification de l’application par une approche descendante par raffinement, allant du niveau le plus g´en´eral form´e par les composants et les connecteurs principaux, d´efinis eux mˆemes par des groupes de composants et de connecteurs, jusqu’aux d´etails de chaque composant et de chaque connecteur primitifs.
– Le raffinement et la tra¸cabilit´e. La configuration est ´egalement un moyen de permettre le raffinement de l’application d’un niveau abstrait de description g´en´eral vers un niveau de description de plus en plus d´etaill´e, et, ceci, `a chaque ´etape du processus de d´eveloppement (conception, implantation, d´eploiement). Ainsi il est possible, par la d´efinition de la configuration, de garder une trace de ce qui a ´et´e fait en amont, et de cr´eer des liens entre les diff´erents niveaux de description de l’application. Cette caract´eristique permet le rapprochement entre les mod`eles de haut niveau et le code.
– L’h´et´erog´en´eit´e. La configuration d’un ADL doit permettre le d´eveloppement de grands syst`emes avec des ´el´ements pr´eexistants de caract´eristiques diff´erentes.
L’ADL doit ˆetre capable de sp´ecifier une application ind´ependamment du langage de programmation, du syst`eme d’exploitation et du langage de mod´elisation.
– Le passage `a l’´echelle. Les ADLs se doivent de proposer une mod´elisation de syst`emes qui peuvent grossir en taille. Il s’agit de pr´evoir le nombre d’instances et leur placement dans un environnement ainsi que la dynamique de l’application.
– L’´evolution de la configuration. La configuration doit ˆetre capable d’´evoluer pour prendre de nouvelles fonctionnalit´es impliquant une modification ou une ´evolution de l’application. Elle doit permettre de faire ´evoluer l’architecture d’une application de mani`ere incr´ementale, c’est-`a-dire par ajout ou retrait de nouvelles classes de composants et des connecteurs.
– L’aspect dynamique de l’application. La configuration d’une application doit permettre la modification `a l’ex´ecution de syst`emes demandant des temps d’ex´ecution longs ou pouvant difficilement ˆetre stopp´es. Elle doit sp´ecifier le comportement dynamique de l’application, c’est-`a-dire les changements de l’application qui peuvent arriver pendant son ex´ecution comme la cr´eation, ou la suppression d’instances de composants.
– Les contraintes. Les contraintes li´ees `a la configuration viennent en compl´ement des contraintes d´efinies pour chaque composant et chaque connecteur. Elles d´ecrivent les d´ependances entre les composants et les connecteurs et concernent des caract ´eristiques li´ees `a l’assemblage de composants que l’on qualifie de contraintes inter composants. La sp´ecification de ces contraintes permet de d´efinir des contraintes dites globales, s’appliquant `a tous les ´el´ements de l’application.
– Les propri´et´es non-fonctionnelles. Certaines propri´et´es non fonctionnelles ne concernant ni les connecteurs ni les composants doivent ˆetre exprim´ees au niveau de la configuration. Ces contraintes sont li´ees `a l’environnement d’ex´ecution. Un ADL doit donc ˆetre capable de sp´ecifier ces contraintes au niveau de la configuration.
L’Adl Darwin
Le langage Darwin, Magee et al. (1995); Magee et Kramer (1996), est consid´er´e comme un langage de description d’architecture, bien que celui-ci soit souvent appel´e langage de configuration. Un langage de configuration favorise la description de la configuration d’une application, c’est-`a-dire la description des interactions entre composants.
La particularit´e de ce langage est qu’un composant est une entit´e instanciable. La description d’un composant au niveau du langage permet de cr´eer de multiples instances d’un composant lors de l’ex´ecution. Ainsi, ce type de langage se centre sur la description de la configuration et sur l’expression du comportement d’une application plutˆot que sur la description structurelle de l’architecture d’un syst`eme comme le font de nombreux ADLs. La particularit´e de Darwin est donc de permettre la sp´ecification d’une partie de la dynamique de l’application en terme de sch´ema de cr´eation de composants logiciels avant, apr`es ou en cours d’ex´ecution.
Le concept principal de Darwin est le composant. Un composant est d´ecrit par une interface qui contient les services fournis et requis. Ces services s’apparentent plus aux entr´ees et sorties de flots de communication qu’`a la notion de fonction. Deux types de composants existent :
– les primitifs int`egrent du code logiciel, leur granularit´e est ´etablie au niveau d’un processus,
– les composites sont des interconnexions de composants, ils repr´esentent des unit´es de configuration.
La s´emantique associ´ee `a un composant est celle du processus. Ainsi, une instance de composant correspond `a un processus cr´e´e. Il est possible d’associer au composant un ensemble de param`etres typ´es d’initialisation et d’utiliser les valeurs de ceux-ci `a l’int´erieur de la configuration du composite de fa¸con `a d´ecrire la configuration de mani`ere dynamique. Par exemple, Darwin permet de fixer le nombre d’instances d’un composant lors de son initialisation. Les services requis ou fournis (ang. require et provide) correspondent `a des types d’objets de communication que le composant utilise pour respectivement communiquer avec un autre composant ou recevoir une communication d’un autre composant. Ainsi, les services n’ont pas de connotation fonctionnelle.
Ils d´ecrivent les types d’objets de communication utilis´es ou autoris´es `a appeler une fonction du composant. Ces types d’objets sont d´efinis par le support d’ex´ecution r´eparti appel´e Regis, Magee et al. (1994) et sont limit´es. Ainsi, `a l’ex´ecution, un composant Darwin est un processus qui communique avec d’autres composants grˆace `a des objets de communication cr´e´es et g´er´es par le syst`eme d’ex´ecution Regis. Parmi les types d’objet, le port est le plus courant : il s’agit d’un objet envoyant des requˆetes de mani`ere synchrone ou asynchrone entre composants r´epartis ou non.

Table des matières

1 Introduction 
1.1 Objectifs et contributions
1.2 Plan du m´emoire
I Etat de l’art 
2 Architectures logicielles
2.1 Introduction
2.1.1 Historique
2.1.2 D´efinition
2.2 Description des Architectures
2.2.1 Approches ADL
2.2.2 Style d’architecture
2.3 Les architectures dynamiques
2.3.1 Architectures dynamiques selon les ADL
2.3.2 UML en tant que langage pour la description des architectures
2.4 Architectures orient´ees service
2.4.1 Structure de SOA
2.4.2 Services Web
2.5 Conclusion
3 Adaptabilit´e des architectures logicielles
3.1 Introduction
3.2 Reconfiguration des architectures
3.2.1 Une approche comportementale de mod´elisation SOA
3.2.2 Approches bas´ees sur les graphes
3.3 Mod´elisation de syst`emes « self-healing »
3.3.1 Un mod`ele d’adaptation pour les architectures
3.3.2 Une approche architecturale pour le logiciel auto-adaptatif
3.3.3 Une approche pour le d´eveloppement de composants « self-healing »
3.3.4 Une approche architecturale pour la cr´eation de syst`emes « selfhealing»
3.3.5 Une architecture pour les services Web autonomes
3.3.6 Une infrastructure d’ex´ecution pour les syst`emes « self-healing »
3.3.7 Une plate-forme pour le « self-healing » dans les services Web
3.4 Conclusion
II Contributions 
4 Cadre logiciel pour l’adaptation des architectures
4.1 Introduction
4.2 Positionnement par rapport aux approches de reconfiguration
4.3 Description architecturale
4.3.1 M´etamod`ele UML pour la description des architectures
4.3.2 Interactions entre services
4.3.3 Sch´ema XML pour la description architecturale
4.4 D´efinition de r`egles de base
4.4.1 Sch´ema XML pour les r`egles de base
4.5 D´efinition de r`egles de reconfiguration
4.5.1 Outils pour la transformation des graphes
4.6 Conclusion
5 Sc´enarios applicatifs
5.1 Introduction
5.2 La revue coop´erative
5.2.1 Acteurs et Workflow
5.2.2 Description des phases
5.2.3 Description architecturale
5.2.4 Application des r`egles de reconfiguration
5.2.5 Mise en oeuvre du syst`eme de gestion de conf´erences
5.3 L’exemple « Foodshopping »
5.3.1 Acteurs et workflow
5.3.2 Description architecturale
5.3.3 Application des r`egles de reconfiguration
5.4 Conclusion
6 Vers une infrastructure de gestion de la QdS
6.1 Introduction
6.2 Les ontologies et leur sp´ecification
6.2.1 Langages pour la repr´esentation des ontologies
6.3 La qualit´e de service
6.3.1 La QdS dans la revue coop´erative
6.4 Mod´elisation de la QdS par les ontologies
6.4.1 D´efinition de la structure de l’ontologie
6.4.2 D´efinition des propri´et´es de l’ontologie
6.4.3 D´efinition des individus
6.4.4 D´efinition et application des r`egles
6.5 Reconfiguration au niveau classe de service
6.5.1 Cas 1. Interaction simple
6.5.2 Cas 2. Interactions multiples
6.6 Architecture de gestion de la QdS
6.6.1 Mod´elisation de l’architecture de gestion de la QdS
6.6.2 Validation de l’architecture de gestion de la QdS
6.7 Conclusion
7 Conclusion
7.1 Bilan des contributions
7.2 Travaux en cours et perspectives
Bibliographie 
A Sch´emas XML
B Diagrammes UML
C Publications de l’auteur
C.1 Conf´erences internationales avec actes et comit´e de lecture
C.2 Manifestations d’audience nationale
C.3 D´elivrables du projet WS-DIAMOND
C.4 Rapports de recherche

Télécharger le rapport complet