Fonctionnement d’ACE

Supposons une contrainte d´efinie lors de l’´etape de conception avec le profil pour xAcme. Pour que cette contrainte soit ´evalu´ee lors de l’impl´ementation (dans ce cas, sur une description

<<artifact>> <<artifact>> Fractal Metamodel UML 2 <<artifact>> Metamodel <<artifact>> <<artifact>> archMM.xmi <<uses>> <<generates>> Constraint Editor <<generates>>

<<uses>> <<uses>> <<uses>> <<uses>> CCM

<<artifact>>

MetamodelxArch Metamodel

<<artifact>> SpecificationConstraint Intermediate SpecificationConstraint TransformerConstraint ACE <<conformsTo>>

FIG. 8.6 – Un prototype pour l’´edition et l’´evaluation des contraintes -Partie 2-

en Fractal), les ´etapes suivantes sont effectu´ees :

1. transformation de la contrainte sp´ecifi´ee dans le profil ACL pour xAcme vers le profil standard ;

2. transformation de la description architecturale en Fractal dans le mod`ele interm´ediaire ; 3. ´evaluation de la contrainte transform´ee sur le mod`ele interm´ediaire.

Sur la Figure 8.7, on retrouve une capture d’´ecran de l’outil ACE. Dans cette interface, on retrouve de simples zones de textes pour le chargement et ´eventuellement l’´edition de contraintes (zone en haut `a droite) et les descriptions d’architecture (zone en haut `a gauche). En bas de la figure, on retrouve les r´esultats d’´evaluation des contraintes architecturales sur les descriptions d’architecture.

Durant une activit´e d’´evolution, une nouvelle version d’une architecture peut ˆetre intro- duite. Les contraintes sont ´evalu´ees sur cette nouvelle description transform´ee dans le mod`ele interm´ediaire. Dans ce cas, toutes les contraintes (mˆeme celles impliquant les deux versions) sont ´evalu´ees. Si l’´evaluation retourne la valeur vraie, la nouvelle architecture introduite est valid´ee ; sinon, le d´eveloppeur en est averti.

Selon ce sch´ema de conception, l’outil ACE peut ˆetre facilement ´etendu pour supporter d’autres ADL ou des technologies de composants (comme CCM ou UML 2, voir les boˆıtes avec pointill´es dans les Figure 8.5 et 8.6). Il ´evalue toujours les contraintes sur la description

FIG. 8.7 – Capture d’´ecran de l’outil ACE

interm´ediaire. Pour chaque nouvel ADL ou technologie de composants, il suffit de d´efinir un m´eta-mod`ele (sous la forme XMI et XML Schema), ainsi que des projections (XSLT) entre ce m´eta-mod`ele et ArchMM, `a la fois pour les descriptions d’architecture et les contraintes. Dans un avenir proche, je pense proposer un moyen pour d´ecrire les projections entre un m´eta- mod`ele et ArchMM de mani`ere unique. Ensuite, ces projections seront exploiter pour trans- former, `a la fois, les descriptions d’architecture et les contraintes. L’introduction d’un nouveau m´eta-mod`ele et de projections permet de g´en´erer un nouveau profil ACL. Seuls les transfor- mateurs de contraintes et de descriptions doivent ˆetre ´etendus pour prendre en compte ses nouveaux formats. Les changements `a faire sont donc minimes.

8.4 En r´esum´e

Dans ce chapitre, des outils pour impl´ementer le travail ont ´et´e pr´esent´es. L’outil ACE impl´emente l’approche pr´esent´ee dans le chapitre 7. Il contribue `a la r´esolution de la probl´emati- que de pr´eservation des d´ecisions architecturales tout au long du processus de d´eveloppement d’un logiciel `a base de composants. En effet, ACE permet d’´evaluer des contraintes, formalisant

ces d´ecisions ´ecrites dans diff´erents profils ACL. Il transforme ces contraintes en un profil stan- dard ´evalu´e par cet outil. Il transforme ´egalement les descriptions d’architecture ou les configu- rations de composants vers une repr´esentation interm´ediaire. C’est sur cette repr´esentation que les contraintes ´ecrites dans le profil ACL standard sont ´evalu´ees. Dans sa version actuelle, ACE permet d’´evaluer des d´ecisions architecturales prises, au niveau conception, sur des descrip- tions architecturales xAcme. Il permet ´egalement d’interpr´eter des d´ecisions prises, au niveau impl´ementation, sur des descriptions de composants Fractal.

AURES, l’autre outil pr´esent´e dans ce chapitre, exploite les fonctionnalit´es d’ACE pour l’´evaluation des d´ecisions architecturales ´ecrites dans diff´erents profils ACL. Il permet d’´editer les contrats d’´evolution, qui contiennent la description des d´ecisions architecturales. De plus, les contrats contiennent les liens de ces d´ecisions avec les propri´et´es non-fonctionnelles (attri- buts qualit´e) qu’elles garantissent. Ces contrats sont interpr´et´es par AURES lors de l’´evolution d’une description d’architecture ou d’une configuration de composants. Cette interpr´etation de contrats permet de notifier au d´eveloppeur qu’un changement architectural affecte potentielle- ment les d´ecisions architecturales ´evalu´ees dans le contrat. En suivant les liens d´efinis dans ces contrats, l’outil notifie ´egalement l’alt´eration probable des propri´et´es non-fonctionnelles cor- respondantes. Le d´eveloppeur a le choix entre modifier la description architecturale, le contrat, ou laisser ces modifications telles qu’elles. L’outil garantit le respect des r`egles de l’algo- rithme d’assistance. AURES impl´emente l’approche pr´esent´ee dans le chapitre 6 et r´epond donc `a la probl´ematique de pr´eservation des d´ecisions architecturales et des propri´et´es non- fonctionnelles lors de l’´evolution.

d’exprimer de mani`ere formelle les d´ecisions de conception prises par les d´eveloppeurs au niveau architectural. Ils permettent ´egalement d’expliciter les raisons derri`ere ces d´ecisions. Cet aspect couvre les propri´et´es non-fonctionnelles (et plus particuli`erement) les attributs qualit´e requis par les documents de sp´ecification.

Les contrats d’´evolution servent, bien plus qu’une simple documentation. Lors de l’´evolution, ces contrats sont utilis´es afin de notifier les d´eveloppeurs des cons´equences d’un changement sur les d´ecisions architecturales et sur les propri´et´es non-fonctionnelles correspondantes. Ceci permet de mieux contrˆoler l’´evolution et guider le d´eveloppeur, lors d’une ´evolution, vers une version de l’architecture qui ne d´erive pas de mani`ere importante des besoins non-fonctionnels initiaux. Cette assistance vise `a minimiser le coˆut de maintenance `a travers la r´eduction des tests de non-r´egression effectu´es sur l’aspect non-fonctionnel.

Les d´ecisions architecturales dans ces contrats sont formalis´ees sous la forme de contraintes. Ces contraintes sont exploit´ees pour tracer les d´ecisions architecturales tout au long du proces- sus de d´eveloppement (avant l’´evolution). Cette trac¸abilit´e est garantie grˆace `a un langage four- nissant plusieurs profils, et une m´ethode de transformation de contraintes. L’approche pr´esent´ee est extensible. Elle permet de prendre en compte de nouveaux ADL ou technologies de com- posants avec un effort minimal.

Ces diff´erentes approches ont ´et´e impl´ement´ees `a travers un environnement (AURES) et un outil (ACE). Ces prototypes sont assez simples d’usage et peuvent ˆetre facilement ´etendus.

sants. Cette partie est structur´ee comme suit. Dans le premier chapitre, les apports de cette th`ese en terme de concepts, puis en terme de langages et de techniques, seront pr´esent´es. Chaque point sera d´etaill´e en se basant sur les diff´erentes parties du travail pr´esent´e dans ce m´emoire. Ensuite, ces apports seront r´epartis sur les diff´erentes publications et communications ´etablies pendant la th`ese. Dans le second chapitre, les am´eliorations possibles de ce travail seront intro- duites. Ces am´eliorations n´ecessitent un travail important et requ´erant un temps suppl´ementaire que le temps imparti `a cette th`ese n’a pas permis. Enfin, un chapitre ´epilogue clˆoturera ce m´emoire.

Apports de la th`ese

Sommaire

9.1 Sur le plan conceptuel . . . 157