Un modle de composants pour latelier de dveloppement S MART T OOLS

Carine Courbis* Pascal Degenne** Alexandre Fau** Didier Parigot* Joseph Variamparambil*
* INRIA Sophia Antipolis Projet OASIS et ** W3C

2004, route des Lucioles BP 93 06902 Sophia-Antipolis cedex, France http://www-sop.inria.fr/oasis/SmartTools/ Prnom.Nom@sophia.inria.fr
RSUM. Depuis quelques annes, lapproche par composants dans la conception de logiciels complexes est apparue pour rsoudre les problmes de rpartition, de dploiement et de rutilisation de code. Cette approche savre la mieux adapte pour assurer la prennit, lvolution, linteroprabilit et la maintenance dapplications. Cet article prsente le modle de composants adopt pour la ralisation dun atelier de dveloppement. Loriginalit de ce modle est dtre extensible et exportable vers dautres modles plus connus tels que les Web Services, CCM (CORBA Component Model) ou EJB (Entreprise Java Bean) tout en respectant nos besoins. La validit de ce modle est aussi prouve puisquil a t utilis pour limplantation de notre outil. Cette approche pragmatique nous a permis de concevoir un modle de composants simple et raliste.

Since some years, the component approach for the design of complex softwares has appeared to solve problems of code repartition, deployment and reusability. This approach turns out to suit the best to insure application evolution, interoperability and maintenance. This article introduces the component model used to realize an Integrated Development Environment. The original feature of this model is that it is extensible and transposable into well-known models such as Web-Services, CORBA Component Model or EJB. The validity of this model has been experimented as it was used to implement our tool. This pragmatic approach was helpful for us to design an easy and realistic component model.
ABSTRACT. MOTS-CLS : KEYWORDS:

Modle de composants, technologies XML Component model, XML technologies

Systmes composants adaptables et extensibles 17-18 octobre 2002.

1. Introduction Avec lmergence dInternet, la conception et le dveloppement dapplications complexes doivent imprativement prendre en compte les aspects de rpartition (application distribue), dploiement et rutilisation de code. Cette volution a pour consquence un changement radical dans la programmation de telles applications. Lapproche objet ne permet pas dexprimer des interconnexions complexes entre les objets. Elle est trop oriente vers la programmation et se situe un niveau trop n. Lapproche composant [MAR 02, BRU 01] est apparue pour une meilleure sparation entre les aspects de communication et les parties fonctionnelles, pour sabstraire des langages de programmation et pour construire des applications par assemblage de composants. Cet article dcrit une approche composant dans le contexte particulier de la conception dun atelier de dveloppement, nomm S MART T OOLS [PAR 02]. Cest un gnrateur denvironnements de dveloppement pour des langages de programmation ou mtiers qui sappuie fortement sur les technologies objets et XML [COU 02]. A partir dune description dun langage, il produit automatiquement des outils de transformation ou de manipulation des programmes crits dans ce langage. Ces programmes (ou documents) sont reprsents en interne sous forme darbres de syntaxe abstraite. Ainsi, lutilisateur obtient rapidement un environnement de dveloppement. Il peut ensuite lenrichir, laide de S MART T OOLS, avec dautres lments spciques comme : des vues graphiques sur les documents (pretty-printers) ; des analyseurs lexicaux et syntaxiques (parsers) ; des traitements particuliers (transformation, vrication et interprtation) lis ce langage, crits en Java avec le patron visiteur (visitor design pattern) ou tout simplement des transformations crites en XSL (eXtensible Stylesheet Language) du W3C (World Wide Web Consortium). S MART T OOLS est constitu doutils de base et de composants spciques pour chaque langage trait. Ces outils et composants offrent et requirent des services quil faut connecter et rendre accessibles travers une interface utilisateur. Par exemple, chaque manipulation au niveau dune vue graphique (slection, remplacement, insertion ou appel dun traitement) va se traduire par linvocation des services au niveau du document associ. Laspect gnrique de S MART T OOLS, un mta-outil, impose que son interface utilisateur et son architecture soient les plus congurables et extensibles possibles pour pouvoir les adapter aux services spciques de chaque nouveau langage trait. Il est impratif que toutes les entits logicielles produites soient autonomes et puissent tre excutes sans ncessiter la prsence de linterface, par exemple en mode commande (batch) ou dans dautres environnements. Il doit aussi tre facile dajouter des composants externes en ne modiant ni la plate-forme, ni ces composants. Dans les premires versions de loutil, labsence dune vraie approche par composants tait un handicap pour son volution. Nos composants taient indissociables dun bus logiciel [BER 98] qui assurait toutes les communications. Toute intgration et toute exportation de composants impliquaient la prsence de ce bus. Lapproche

Les composants S MART T OOLS

oriente composant sest donc impose pour la ralisation de notre outil. Aucun des modles existants, tels que les Web Services, les composants CORBA (CCM - CORBA Component Model) [MAR 01] ou les EJB, ne semblait correspondre parfaitement nos besoins spciques et cette dpendance vis--vis dune technologie nous paraissait prjudiciable lvolution de loutil. Nous avons donc conu notre propre modle (indpendamment de ces technologies) adapt et restreint nos besoins, mais surtout transposable vers ces technologies de composants. Il ressort, de nos premires expriences, que concevoir un modle abstrait permet dtre en parfaite adquation avec les besoins et contraintes du champ dapplication. Nos langages de description de composants sont ainsi adapts et offrent un moyen dclaratif pour dcrire prcisment les composants et lassemblage qui forme une application. Limplantation effective du modle (par gnration de conteneurs partir de ces descriptifs) prend en compte toutes les particularits de notre domaine sans pour autant nuire la lisibilit de ces descriptifs. Cette gnration de conteneurs automatise la programmation des parties non-fonctionnelles des composants. Elle facilite lajout de nouvelles fonctionnalits, non initialement prvues. Cette sparation entre le modle et sa mise en uvre rend possible lutilisation de nos composants dans dautres technologies. En effet, partir de ces descriptifs, un outil de transformation gnre les descriptions (ou interfaces) quivalentes pour les Web Services, les composants CORBA ou encore les EJB. Cette exportation nous a permis didentier les particularits, avantages et inconvnients de chaque modle. Cela a conrm que lutilisation dune de ces technologies aurait t prjudiciable. En effet, certaines caractristiques dynamiques de nos composants auraient t difcilement exprimables sans une spcialisation des composants en fonction des langages traits. Cette dmarche correspond la nouvelle stratgie dfendue par lOMG, MDA (Model-Driven Architecture) [BZ 01], qui est base sur une notion de transformation de modles. Un des rsultats importants de notre dmarche est de montrer, sur un exemple particulier, lintrt de dnir un modle indpendant de limplantation (PIM - Plateform Independant Model) et ensuite de proposer diffrentes transformations vers des modles spciques (PSM - Plateform Specic Model). Larticle se dcompose en quatre sections. La premire section dcrit le modle de composants et son implantation. La deuxime section traite des particularits dynamiques de ce modle et prsente la projection des composants vers ces technologies existantes. La troisime section value notre modle suivant des critres communment admis [MAR 02]. Enn, la dernire section dresse le bilan de cette approche.

2. Description du modle et de sa mise en uvre Cette section introduit notre modle de composants et son implantation. Lors de la conception de ce modle, nous nous sommes imposs deux contraintes : avoir une nette sparation entres les parties fonctionnelles et non-fonctionnelles, et avoir un modle qui, bien que spcique nos besoins, soit ((projetable)) vers dautres technologies existantes. En respectant ces contraintes, nous avons conu un langage de description

Systmes composants adaptables et extensibles 17-18 octobre 2002.

de composants. Puis pour limplantation, un gnrateur de conteneurs et un gestionnaire de composants ont t raliss.

2.1. Le langage de description de nos composants Avec ce langage, on dcrit le type dun composant : les services (connecteurs) en entre ou en sortie, les modes de communication et les attributs de conguration de ltat du composant. Pour chaque service, on indique son nom logique, la mthode appeler dans la partie mtier (dans la faade du composant), les paramtres ( ) de la mthode. Les modes de communication sont soit asynou ), soit synchrone ( ). Il est possible de factoriser les chrone ( parties communes des descriptions dans des descriptions abstraites. Par exemple, la description abstraite (Figure 1) est importe par toutes les autres descriptions. La Figure 2 donne la description du composant Graphe 1 et la Figure 3 sa reprsentation graphique.
<?xml version="1.0" encoding="ISO-8859-1"?> <component name="abstractContainer"> <input method="quit" name="quit"/> <output name="connectTo" method="connectTo"> <parameter name="ref_src" javatype="java.lang.String"/> <parameter name="type_dest" javatype="java.lang.String"/> <parameter name="id_dest" javatype="java.lang.String"/> <parameter name="actions" javatype="java.util.HashMap"/> </output> <output name="exit" method="exit"/> <output name="initData" method="initData"> <parameter name="inits" javatype="java.util.HashMap"/> </output> <inout name="requestData" method="request" output="initData" outputParameter="inits"/> </component>

Figure 1: Description abstraite abstractContainer

2.2. La mise en uvre du modle Pour limplantation du modle, un gnrateur de conteneur et un gestionnaire de composants ont t conus en fonction des contraintes de notre plate-forme. Pour chaque application construite avec S MART T OOLS, un chier de lancement prcise les composants charger et instancier au dmarrage. Le gnrateur Le gnrateur produit le conteneur du composant partir de son descriptif. Il peut ventuellement tendre la faade si cette dernire est incomplte (vrie par intros1. Les autres composants sont trop complexes pour tre donns en exemple.

    

  $  #  !  &  % "

    

      

Les composants S MART T OOLS

<?xml version="1.0" encoding="ISO-8859-1"?> <component name="graph" type="graph" extends="abstractContainer"> <containerclass name="GraphContainer"/> <facadeclass name="GraphFacade"/> <dependance name="koala-graphics" jar="koala-graphics.jar"/> <attribute name="nodeType" javatype="java.lang.String"/> <input name="addComponent" method="addNode"> <parameter name="nodeName" javatype="java.lang.String"/> <parameter name="nodeColor" javatype="java.lang.String"/> </input> <input name="addEdge" method="addEdge"> <parameter name="srcNodeName" javatype="java.lang.String"/> <parameter name="destNodeName" javatype="java.lang.String"/> </input> </component>

Figure 2: Description du composant Graphe

Composant Graphe

Legende Classes GraphFacade input inout GraphContainer nodeType quit addEdge addNode output attribute

requestData initData exit connectTo

Figure 3: Schma du composant Graphe

pection). Cette extension sert mettre en place le mcanisme de communication faade vers conteneur (proche du patron de conception Observer) pour les services en sortie ( ). Ce gnrateur produit aussi une archive (un paquetage de dploiement) contenant lensemble des classes dont le conteneur et les descriptifs du composant. Cette phase de gnration rend transparents les moyens de communication mis en uvre dans le conteneur et automatise les tches de cration de paquetage pour chaque nouveau langage trait. Le gestionnaire de composants Le gestionnaire de composants charge les paquetages des composants et cre les instances en fonction dune description de lancement de lapplication (Figure 5) et des demandes interactives des utilisateurs (par exemple, louverture du premier document associ un langage donn). Il mmorise lensemble des paquetages chargs et des instances cres. Il offre aussi le service pour connecter deux composants (Figure 4). Ce service effectue aussi la cration des composants sils nexistent pas encore. Pour les connexions, le gestionnaire utilise les descriptifs respectifs de ces composants. En fonction des noms, les connecteurs de sortie (vs. dentre) sont mis en relation avec les connecteurs dentre (vs. de sortie) de lautre composant, sils existent. Aprs ce processus de connexion, les deux instances de composant dialoguent directement entre elles sans passer par le gestionnaire.

 "  #  #  

    

Systmes composants adaptables et extensibles 17-18 octobre 2002.

Gestionnaire de Composants Description du composant (XML) Faade Description du lancement de lapplication (XML)

Conteneur

Description du composant C1 (XML) Conteneur gnr

connectTo

Description du composant C2 (XML) Conteneur gnr

Extension de services (XML)

Faade Classes Composant C1

Faade Classes Composant C2

Figure 4: Schma de notre modle de composant Exemple de lancement dune application Au dmarrage de notre outil, le gestionnaire de composants est charg et cr automatiquement. Puis avec le chier de lancement de la Figure 5, il charge trois , et ) et tablit une connexion entre lui-mme types de composants ( et une instance du composant interface utilisateur ( ). La cration de cette instance est paramtre par les attributs du service . Par exemple, le chier de conguration boot.lml (Figure 6) dcrit les documents et les vues ouvrir dans cette instance.
<?xml version="1.0" encoding="ISO-8859-1"?> <application repository="file:stlib/" library="file:lib/"> <load_component jar="view.jar" name="glayout"/> <load_component jar="lml.jar" name="lml"/> <load_component jar="tiny.jar" url="file:extralib/tiny.jar" name="tiny"/> <connectTo id_src="ComponentManager" type_dest="glayout"> <attribute name="docRef" value="file:resources/lml/boot.lml"/> <attribute name="xslTransform" value="file:resources/xsl/lml2bml.xsl"/> <attribute name="behaviors" value="file:resources/behaviors/bootbehav.xml"/> </connectTo> </application>

Figure 5: Exemple de descriptif de lancement Interface utilisateur Linterface utilisateur est ralise suivant le mme schma que pour un programme : cest une vue sur un arbre qui dcrit lensemble des vues et des documents ouverts un instant donn. Ltat de linterface peut ainsi tre sauvegard (serialisable). Les actions sur linterface (ajout dun nouvel onglet, fermeture dune vue, etc) correspondent des actions ddition sur cet arbre. Le chier de conguration de linterface utilisateur (voir la Figure 6) donne larbre dans un format XML. Pour chaque vue, on indique le chemin vers le document visualiser, le type de vue, la transformation effectuer sur le document pour obtenir les objets graphiques de cette vue et la feuille

  

  #  #     

  

  

Les composants S MART T OOLS

de style appliquer sur ces objets. Pour un mme document, il est possible davoir plusieurs vues graphiques associes.
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE layout SYSTEM "file:resources/lml.dtd"> <layout> <frame title="Smarttools V4.Alpha" statusBar="on"> <set title="LML Layout"> <view title="Layout" behavior="" viewType="fr.smarttools.view.GdocView" docRef="file:resources/lml/boot.lml" styleSheet="file:resources/css/lmlstyles.css" transform="file:resources/xsl/genericBoxes.xsl" /> </set> <set title="Tiny Workbench"> <view title="samples/tiny/ex1.tiny" behavior="" viewType="fr.smarttools.view.GdocView" docRef="file:samples/tiny/ex1.tiny" styleSheet="file:resources/css/tiny-styles.css" transform="file:resources/xsl/genericBoxes.xsl" /> </set> </frame> </layout>

La Figure 7 montre les types de composant chargs (les rectangles) et les instances cres (les ovales) pour cette conguration (les chiers des Figures 5 et 6). Dtails dimplantation Comme notre outil est interactif, il tait important que linterface graphique ne soit pas bloque lors de traitements sur les documents. Pour rsoudre ce problme, chaque instance de composant est excute dans un processus indpendant (Thread) et le mode de communication est donc asynchrone (envoi dvnements stocks la rception dans une le dattente). Ces mcanismes sont transparents pour lutilisateur car ils sont grs au niveau du conteneur qui est gnr. Les mcanismes utiliss dans les conteneurs gnrs sont simples et efcaces (appel direct des mthodes de la faade, multi-threading, listener, etc). Ce modle de composants est oprationnel dans la version courante de S MART T OOLS.

3. Avantages du modle 3.1. Composants extensibles Dans notre cadre, linterface des composants doit tre extensible dynamiquement pour lajout de nouveaux services, par exemple, aux composants de visualisation. En effet, ceux-ci ne connaissent pas les services spciques des composants documents auxquels ils sont rattachs. Ils doivent donc tre enrichis dynamiquement par ces services dcrits dans un chier dextension du composant document. Ce chier prcise les lments graphiques (menus et barre doutils) ajouter aux composants de visualisation et les nouvelles connections tablir entre ces composants et le document.

 

Figure 6: Exemple dun arbre de linterface graphique (

Systmes composants adaptables et extensibles 17-18 octobre 2002.

Composant Interface graphique glayout Interface utilisateur Vue sur boot.lml

Composant vue

Vue sur ex1.tiny

Gestionnaire de composants Document de boot.lml Document ex1.tiny Composant Gestionnaire de composants Composant Document Tiny

Composant Document Lml

Figure 7: Composants chargs et instances cres avec leurs connexions

Une autre caractristique du modle est la possibilit dajouter des services qui agissent lintrieur mme de nos composants. En effet, notre plate-forme fournit une technique de programmation par aspect [BOU 01, PAR 02] pour mieux spcier (par separation of concerns) les traitements sur les arbres. Notre technique a lavantage dtre totalement dynamique (sans transformation de programmes). Leffet de bord de cette possibilit est que les interfaces de nos composants documents doivent imprativement tre extensibles. Lexemple type, que nous traitons dj, est lajout dun mode dexcution pas--pas aux divers traitements, totalement ralis laide dun aspect. Cet aspect utilise une vue graphique particulire et cela demande dintroduire dynamiquement de nouveaux services (dans les deux sens) entre le composant document et cette vue. Il nous reste encore gnraliser cette possibilit sur dautres exemples plus complexes.

3.2. Exportation des composants vers dautres technologies Pour valider notre approche, nous avons conu un outil de transformation de nos descriptifs de composant vers les descriptions (ou interfaces) quivalentes pour les Web Services, les composants CORBA et les composants EJB. La Figure 8 donne un aperu des chiers gnrs automatiquement par cet outil pour chaque technologie. Les dtails techniques et particularits de cet outil sont dcrits dans [VAR 02]. Notre composant de visualisation de graphe a t transform automatiquement pour ces trois technologies. Cette transformation nutilise que le descriptif du composant et aucun code source additionnel nest crire. Par exemple pour les Web Services 2 , cet outil traduit nos descriptifs de composant en des descriptifs WSDL quivalents. Par descriptif, il gnre aussi le code source Java qui ralise les appels effectifs aux mthodes de la faade du composant (SOAPBinding). Ce code, normalement la charge des utilisateurs, complte la gnration de code source Java issu des outils associs
2. Lune des technologies les plus simples de mise en uvre et les plus proches de notre modle.

Les composants S MART T OOLS

aux Web Services comme AXIS. Ainsi, tous les services dun composant peuvent tre accessibles travers un serveur WEB comme Tomcat.
x.xml descriptif du composant x

Gnrateur de conteneurs

Exportateur de descriptifs

xContainer.java xExtensionFacade.java SmartTools

x.wsdl xSoapBindingImpl.java Web Service Web-Service

x.idl xCorbaServer.java CCM CCM

xHomeInterface.java xRemoteInterface.java EJB

Figure 8: Exemple de descriptif de composant Mais surtout, il ressort de cette exprience que lutilisation dune de ces technologies correspond faire un choix de conception dont on ne peut sabstraire par la suite. Utiliser EJB implique un modle client/serveur, CORBA une dpendance vis--vis de son protocole de communication (ORB - Object Request Broker) et les Web-Services une spcialisation Internet des composants. En dautres termes, concevoir un modle spcique ses besoins vite de choisir une solution trop lie une technologie existante. De plus, certains de nos besoins (extensions de services) sont difcilement exprimables dans ces diffrents modles. Par exemple, il faudrait spcialiser les composants vues pour chaque langage en fonction des services proposs par le composant document associ. Les intrts de dnir un modle abstrait sont les suivants : spcications appropries aux fonctionnalits des composants sans transposition des besoins et sans les contraintes lies une technologie ; implantation efcace et en parfaite adquation avec les contraintes de lapplication ; et projection plus simple vers les modles existants.

4. valuation de notre modle Comme il existe un nombre important de modles et de concepts, il est assez difcile de faire une comparaison prcise et exhaustive de notre approche. Nous utiliserons plutt le patron dvaluation, issu des principaux modles de composants, propos par [MAR 02] qui prsente un tat de lart des diffrents modles et une taxonomie des rles dans le processus de production dapplications base de composants. Nous allons regarder ladquation de notre dmarche avec cette taxonomie pour prciser les avantages ou inconvnients de notre modle. Analyse des besoins en terme dapplicatif et de composant : Notre modle est issu dune analyse des besoins spciques notre plate-forme et est donc adapt ce domaine dapplication. Conception des types de composant : Notre langage de description de composants permet de nous abstraire dune technologie de composant particulire. Ce lan-

10

Systmes composants adaptables et extensibles 17-18 octobre 2002.

gage contient les trois aspects dun composant : ses interfaces, ses proprits, ainsi que la manire dont il coopre avec les autres types de composants. Implantation des types de composant : La partie non-fonctionnelle des composants est assure par la gnration automatique des conteneurs. Une partie des contraintes techniques (noms des conteneurs, des faades et des archives gnrs) est dcrite dans les descriptifs des composants. Diffusion des implantations de composants : Notre gnrateur de conteneur prend en charge la constitution dune archive (paquetage) pour chaque composant. Assemblage des types de composant : Les langages de dploiement et de description de linterface graphique permettent de spcier et de congurer lassemblage des composants dune application. Par contre, il nest pas encore possible de considrer le rsultat de cet assemblage comme un composant. Dploiement des implantations de composant et des applicatifs : Notre gestionnaire de composants joue ce rle de dploiement de composants. Il prend en charge la cration de nouvelles instances et la recherche des instances existantes. Dans notre modle, le dploiement nest pas encore congurable en terme de structure daccueil (par exemple pour une version rpartie sur diffrentes machines). Utilisation des instances de composant et des applicatifs : La dcouverte des services offerts par un composant seffectue dans notre modle exclusivement par lintermdiaire des descriptifs des composants (format XML). Nous utilisons une introspection sur ce format neutre, indpendant dun langage de programmation particulier. Bien que notre modle soit ddi notre outil, il possde de nombreuses bonnes proprits dun modle de composants en regard de cette taxonomie. Il contient tout de mme quelques particularits et restrictions. La topologie dune application est dynamique et congurable. Ce changement de topologie seffectue en cours dexcution et la prise de dcision de connexion est locale un composant. Par exemple, si un nouveau composant vue est cr, cest lui qui va prendre en charge dynamiquement sa connexion avec le composant document associ. Les possibilits dextension de nos composants pour la qualit de service (comme les besoins de scurit, de persistance et de transaction) sont actuellement peu traites dans notre modle. Ces besoins ntaient pas vitaux pour un premier fonctionnement de notre plate-forme. De plus, lexportation de nos composants vers dautres modles nous affranchit de fournir de tels services couramment proposs par les autres modles. En les exportant, ils sont ainsi utilisables dans des applications ou environnements plus complexes qui requirent ces types de services. Par contre, notre outil demande des services particuliers comme par exemple, la persistance des sessions ddition. Pour cela, le choix de reprsenter le contenu de linterface utilisateur sous la forme dun arbre a permis de raliser facilement ce service. Mais lintrt dun modle par composant est de laisser ces parties non-fonctionnelles la charge du gnrateur de conteneurs. Ainsi, pour intgrer ces types de services an de faire voluer notre plate-forme, il suft de modier ce gnrateur. Par exemple, la ralisation dune version rpartie devrait tre facilite par ce gnrateur. De mme, notre outil de transformation pourrait tre tendu pour dautres

Les composants S MART T OOLS

11

modles de composants (par exemple ceux proposs par la plate-forme ObjectWeb [Obj]).

5. Conclusion La principale motivation de ce travail tait de dnir un modle de composants en adquation avec nos besoins et non den faire un modle gnral. Par exemple, nous avons pas encore trouv le besoin vital dintroduire la notion de composant hirarchique [BRU 02] dans notre modle. Un exemple dutilisation de cette notion doit tre, avant tout, clairement identi pour bien comprendre de quel type de composant hirarchique nous avons besoin. De mme, une excution rpartie de nos composants (sur plusieurs machines) introduirait, dans notre cadre, une problmatique nouvelle ddition collaborative des documents et des traitements associs. Ces perspectives intressantes dpassent nos objectifs initiaux lors de la conception de ce modle par composant. Ce modle est un moyen dclaratif de dcrire larchitecture de S MART T OOLS, indpendamment dune technologie de composants et dun langage de programmation. Les technologies existantes, comme les composants CORBA ou EJB, nous ont sembl tre assez loignes de nos proccupations ou ne rpondaient pas compltement nos attentes. Pour autant, notre modle sappuie fortement sur les mmes concepts de base mais sa mise en uvre est adapte notre mode de fonctionnement. Nous avons prfr dnir notre propre modle, indpendamment des technologies existantes, tout en permettant une transformation vers celles-ci. Les perspectives intressantes de cette approche sont de pouvoir tendre les composants en modiant leurs comportements internes laide de la technique de programmation par aspect. Lune des principales caractristiques de S MART T OOLS est dtre base sur une approche par gnration de code partir de spcications, non seulement pour les parties non-fonctionnelles mais aussi pour les parties fonctionnelles. Pour les composants documents, cette approche est utilise pour offrir une technique dynamique de programmation par aspect au-dessus des visiteurs. Pour rpondre aux besoins dextensions ou de separation of concerns il existe essentiellement trois types dapproche [BOU 01] : par transformation de programme, par mcanisme de rexivit [MAL 96] (MOP - Meta-Object Protocol) et enn par gnration de code. Lintrt de lapproche par gnration (conteneur ou visiteur) est de produire un code incluant directement les mcanismes appropris dextension. Cette approche, bien que non gnraliste, rend ces mcanismes transparents lutilisateur et reste simple et efcace dans son implantation (vu nos premiers rsultats). Tous ces travaux cherchent rsoudre les problmes rencontrs lors de la conception et ralisation dun tel mta-outil. Par son auto-utilisation dans sa propre construction, S MART T OOLS offre un cadre pour tester concrtement les solutions proposes. Cest avant tout une plate-forme dexprimentation pour nos futurs travaux de recherche, en particulier sur la composition daspects et de services pour les composants.

12

Systmes composants adaptables et extensibles 17-18 octobre 2002.

De plus les extensions naturelle de notre modle (composant hirarchique ou excution rparties) offrent des perspectives trs intressant en connexion avec dautres domaines de recherche.

Remerciements Ce projet est partiellement nanc par le W3C dans le cadre du contrat europen QUESTION-HOW ( ).

6. Bibliographie
[BER 98] B ERGSTRA J., K LINT P., ( The discrete time ToolBus A software coordination ( architecture ) Science of Computer Programming, vol. 31, n o 2-3, 1998, p. 205229. ), [BOU 01] B OURAQADI -S ADANI N. M. N., L EDOUX T., ( Le point sur la programmation ( par aspects ) Technique et Sciences Informatiques, vol. 20, page 505 528, Herms, ), 2001. [BRU 01] B RUNETON E., R IVEILL M., ( Experiments with JavaPod, a Platform Designed for ( the Adaptation of Non-functional Properties ) Metalevel Architectures and Separation of ), Crosscutting Concerns, REFLECTION 2001, vol. 2192 de LNCS, Kyoto, Japan, sept 2001, p. 5272. [BRU 02] B RUNETON E., C OUPAYE T., S TEFANI J.-B., ( Recursive and Dynamic Software ( Composition with Sharing ) In Proceedings of the 7th ECOOP International Workshop ), on Component-Oriented Programming (WCOP02), Malaga (Spain), June 2002. [BZ 01] B ZIVIN J., ( From Object Composition to Model Transformation with MDA ) ( ), TOOLS USA, IEEE TOOLS-39, 2001. [COU 02] C OURBIS C., D EGENNE P., FAU A., PARIGOT D., ( Lapport des technolo( gies XML et Objets pour un gnrateur denvironnements : SmartTools ) revue LOb), jet, numro spcial XML et les Objets, , 2002, Herms Sciences, paratre, ftp://ftpsop.inria.fr/oasis/publications/2002/smartobjet02.pdf. [MAL 96] M ALENFANT J., C OINTE P., ( Aspect-Oriented Programming versus Reection ) ( ), rapport, 1996, Ecole des Mines de Nantes. [MAR 01] M ARVIE R., M ERLE P., G EIB J.-M., VADET M., ( OpenCCM : une plate-forme ( ouverte pour composants CORBA ) Actes de la seconde Confrence Franaise sur les ), Systmes dExploitation (CFSE2), Paris, France, Avril 2001. [MAR 02] M ARVIE R., P ELLEGRINI M.-C., ( Modles de composants, un tat de lart ) ( ), Numro spcial de LObjet, vol. 8, no 3, 2002, Herms Sciences. [Obj] ( ObjectWeb ) http://www.objectweb.org/. ( ), [PAR 02] PARIGOT D., C OURBIS C., D EGENNE P., FAU A., PASQUIER C., F ILLON J., H ELP C., ATTALI I., ( Aspect and XML-oriented Semantic Framework Ge( nerator: SmartTools ) ), ETAPS2002, LDTA workshop, Grenoble, France, April 2002, Electronic Notes in Theoretical Computer Science (ENTCS), ftp://ftpsop.inria.fr/oasis/publications/2002/smartldta02.pdf. [VAR 02] VARIAMPARAMBIL J. G., ( Enabling SmartTools components with component ( technologies:WebServices, CORBA and EJBs ) rapport, 2002, INRIA. ),