Supposons que, lors de la premi`ere ´etape de conception architecturale, une sp´ecification de contraintes, formalisant les d´ecisions architecturales prises, a ´et´e d´efinie. Cette sp´ecification est
nomm´ee SC1 dans la Figure 7.1. Lors de la deuxi`eme ´etape, de nouvelles contraintes peuvent apparaˆıtre. Ces contraintes sont nomm´ees SCS2. Dans cette ´etape, SC1 doit ´egalement pou- voir ˆetre ´evalu´ee. La vue dont on dispose de SC1 dans l’´etape 2 est nomm´ee ici SC1’. La sp´ecification de contraintes de l’´etape de conception de composants (´etape 2) est donc l’union de SC1’ et SCS2. De mˆeme, pour l’´etape 3, SC3 est ´egal `a l’union de SCS3 (les contraintes sp´ecifiques `a l’´etape 3) et de SC2’ (les contraintes SC2 vues dans l’´etape 3).
Afin que les d´ecisions architecturales puissent ˆetre pr´eserv´ees deux besoins ´emergent : 1. les contraintes SCS2 et SCS3 doivent pouvoir ˆetre exprim´ees. Plus g´en´eralement, les
contraintes architecturales doivent pouvoir ˆetre exprim´ees `a toutes les ´etapes du cycle de vie ;
2. les contraintes SC1 et SC2 doivent pouvoir ˆetre ´evalu´ees facilement dans les ´etapes 2 et 3 respectivement. Plus g´en´eralement, les contraintes architecturales exprim´ees dans les ´etapes en amont `a une ´etape donn´ee doivent pouvoir ˆetre facilement ´evalu´ees dans cette ´etape-ci.
7.3 Expression des contraintes `a divers niveaux
Afin de satisfaire le premier besoin ´enonc´e ci-dessus, une famille de langages de contraintes (ACL) a ´et´e propos´ee. Chaque profil ACL peut ˆetre utilis´e pour formaliser les d´ecisions `a une ´etape donn´ee du processus de d´eveloppement. Dans l’exemple pr´ec´edent, les contraintes SC1 peuvent ˆetre d´ecrites `a l’aide du profil ACL pour Acme. Ce dernier est compos´e du m´eta- mod`ele Acme et de CCL. Dans la deuxi`eme ´etape, les contraintes SCS2 peuvent ˆetre ex- prim´ees `a l’aide du profil ACL pour UML 2 (CCL + m´eta-mod`ele de composants UML 2). Les contraintes SCS3 de la derni`ere ´etape peuvent ˆetre exprim´ees `a l’aide du profil ACL pour CCM. Ceci est illustr´e dans la Figure 7.2.
ACL profil ACL profil
Etape d’implementation de composants : Representation CCM Etape de conception de composants : Representation UML 2
Authenticateur CtlAcces Archiveur EmetteurServeur
CtlAcces Archiveur Emetteur Serveur Authenticateur
Authenticateur CtlAcces Archiveur EmetteurServeur
SystemeControlAcces SystemeControlAcces SystemeControlAcces SC1 dans le profil ACL pour Acme SCS3 dans le SC2 SC3 SC1 SCS2 dans leSC1’ [ + SC2’ [ + pour UML 2 ] pour CCM ]
Etape de conception architecturale : Representation Acme
FIG. 7.2 – Expression des contraintes `a divers niveaux
je vous pr´esente la mani`ere avec laquelle ces diff´erents profils ACL sont ´evalu´es. La m´ethode d’´evaluation qui va ˆetre introduite dans les sous-sections suivantes va ˆetre utilis´ee pour r´epondre au deuxi`eme besoin.
7.3.1 Probl´ematique de l’´evaluation des contraintes
Comme ´enonc´e ci-dessus, ACL n’est pas un simple langage mais une collection de lan- gages. Chaque ´el´ement de cette collection (profil ACL) d´efinit en fait un langage. La difficult´e est de fournir autant d’´evaluateurs diff´erents qu’il y a de profils (actuellement 5). Il est plus judicieux, de par les ressemblances que pr´esentaient les m´eta-mod`eles de chacun des profils, de d´efinir : un m´eta-mod`ele fac¸ade auquel on associe un unique ´evaluateur et autant de traduc- teurs d’un profil vers ce langage interm´ediaire. Ce m´eta-mod`ele fac¸ade forme avec le langage CCL, le profil standard ArchMM. Avec ce mode de fonctionnement, pour ´evaluer un contrat sur un composant, on traduit le descripteur d’origine de ce composant dans un mod`ele conforme `a ArchMM. Ce mod`ele est une instance d’ArchMM g´en´er´ee par transformation depuis le descrip- teur d’architecture du composant. Les d´ecisions architecturales sont ´egalement traduites dans le profil ArchMM. Elles sont ensuite ´evalu´ees sur le mod`ele ArchMM g´en´er´e pr´ec´edemment.
Toute la difficult´e ´etait de trouver un m´eta-mod`ele fac¸ade suffisamment riche et abstrait pour fournir un espace de traduction sans perte depuis chacun des 5 profils. J’ai donc bˆati ArchMM sur une ´etude comparative de deux types de m´eta-mod`eles. Le premier concerne les langages de description d’architecture et le second, les technologies de composants. Une ´etude sur les ADL Acme, Koala [156], xADL [31], et d’autres, a ´et´e men´ee1. Pour la deuxi`eme
cat´egorie de m´eta-mod`eles j’ai compar´e les technologies de composants : EJB (Enterprise JavaBeans) de Sun Microsystems [145] et CCM (CORBA Component Model) de l’OMG [119]. J’ai jug´e int´eressant d’´etendre mon ´etude sur le mod`ele de composants hi´erarchique Fractal du consortium ObjectWeb et sur la partie du m´eta-mod`ele UML concern´ee par les composants.
Dans une premi`ere ´etape, il m’a fallu ´elaborer un m´eta-mod`ele pour chaque niveau (concep- tion ou impl´ementation). Cette tˆache ´etait relativement simple d`es lors que des standards dans les deux niveaux ont ´emerg´e. Je veux dire, par standard, une norme de fait, comme CCM dans les technologies de composants et Acme (par son extension XML, ADML) pour les ADL.
Le m´eta-mod`ele est pr´esent´e dans la prochaine section. Je pr´esenterai, dans les sous-sections suivantes, les abstractions architecturales repr´esent´ees dans les ADL, UML 2 et les technolo- gies de composants.
7.3.2 Abstractions architecturales dans les ADL
Les abstractions architecturales introduites par les ADL ont ´et´e pr´esent´ees dans le chapitre pr´ec´edent dans la section 6.5.2.2. La plupart des ADL permettent la description des types et des instances de composants et de connecteurs. Leur description peut contenir des descriptions d’interfaces, de ports ou de rˆoles. Une configuration ou une topologie d’une application consiste en un ensemble de liens (de type 1-1, N-1, 1-N, N-M) entre les ´el´ements pr´ec´edents. Il est ´egalement possible de hi´erarchiser la description et donc de d´efinir des composants ou des connecteurs composites. Ceci est r´ealis´e `a l’aide de liens hi´erarchique entre composants ou 1Je me suis bas´e ´egalement sur un autre ´etat de l’art ´etabli il y a quelques ann´ees par Medvidovic et Taylor [102].
connecteurs et leurs sous-´el´ements. Un exemple de m´eta-mod`ele MOF d’un ADL a ´et´e fourni dans le pr´ec´edent chapitre. Il concerne xAcme, un ADL g´en´erique et englobant les abstractions architecturales communes aux autres ADL.
7.3.3 Abstractions architecturales dans UML 2
UML fournit une notation unifi´ee pour la mod´elisation et un standard support´e par plusieurs outils du g´enie logiciel. Dans sa sp´ecification 2.0 [122] (adopt´ee par l’OMG), il fournit les ´el´ements n´ecessaires pour d´ecrire `a la fois des architectures abstraites et des impl´ementations `a base de composants2. Un composant est consid´er´e comme un ´el´ement de mod´elisation `a
part enti`ere (tout comme une classe) et non pas comme une entit´e d´eployable et existante `a l’ex´ecution. Cependant, UML est un langage de mod´elisation `a objectif g´en´eral. Par cons´equent, il existe une multitude de concepts pr´esents dans son m´eta-mod`ele qui rendent ce dernier re- lativement complexe. L’objectif vis´e (comme ´enonc´e pr´ec´edemment) est de pouvoir d´efinir le contrat d’´evolution le plus facilement et rapidement possible. Pour ce faire, le m´eta-mod`ele doit comporter des abstractions simples et connues par le d´eveloppeur.