Langages extensibles - Conception et Implantation d'un Environnement de Développement de Logici

ACME [GMW97] est, non pas un langage de description d’architecture, mais un format pivot pour fédérer différents ADL. Tout comme Wright, il a été développé à l’Université Carnegie Mellon.

3.5.1.1 Caractéristiques

Le constat de base qui motive la définition d’ACME est qu’il existe de nombreux ADL qui ont cha-cun des caractéristiques diverses et variées. Les développeurs remarquent qu’une tentative de définition d’un nouveau langage qui regrouperait les caractéristiques des ADL existants ne serait pas une solution durable étant donné qu’il est très difficile de définir un langage implantant l’union des caractéristiques désirées. En revanche, ils constatent qu’une grande partie des ADL sont basés sur les mêmes concepts, surtout en ce qui concerne la définition des structures organisationnelles.

ACME définit un langage dont la base repose sur ces concepts partagés. On peut noter que les carac-téristiques de base sont héritées de Wright : la composition hiérarchique est supportée et les connecteurs sont considérés comme des éléments de premier niveau dans la description d’architecture. De plus, des templatessont proposés afin de définir des systèmes (configurations dans le jargon Wright) réutilisables et paramétrables. La particularité du langage ACME est qu’il est doté d’annotations pour intégrer des expressions spécifiques à un ADL donné. Parmi les utilisations communes des annotations, citons l’ex-pression des modèles comportementaux et des aspects non-fonctionnels comme des contraintes de temps réel ou de qualité de service. Remarquons que les annotations fournissent une forme d’extensibilité au langage de base. Ces aspects sont mieux formalisés dans xACME [xAC] qui propose l’utilisation de schémas XML pour décrire la grammaire et certaines propriétés des éléments d’extension qui seraient décrites sous forme d’annotations dans ACME.

Parce qu’ACME est un langage pivot pour fédérer divers langages, son outillage est censé fournir des traductions entre les langages supportés. Un exemple d’utilisation d’ACME est illustré dans [GMW97] où les auteurs présentent comment une description écrite en Wright peut être traduite en Rapide en passant par ACME.

3.5.1.2 Mise en œuvre

La figure 3.7 présente l’application PingPong. Les deux instances de composants Ping et Pong sont décrites séparément en précisant leurs ports. Remarquons qu’il n’y a pas de sémantique de type

en-3.5. Langages extensibles

trée/sortie ou fournis/requis associée aux ports. Une annotation est ajoutée au composant Ping pour déterminer un seuil à partir duquel il n’enverra plus de messages.

La description des connecteurs se fait similairement à celle des composants. À ce stade, on déclare les rôles qui correspondent aux points d’interaction des connecteurs. Nous illustrons dans la figure 3.7 l’association des propriétés protocolaires (synchrone ou asynchrone) aux connecteurs en utilisant des annotations. System PingPong = { Component Ping = { p o r t p i n g ; p o r t pong ; P r o p e r t i e s = {max : i n t = 100 ; } } Component Pong = { p o r t p i n g ; p o r t pong ; } Connector B u f f e r e d L i n k = { Roles { i , o} P r o p e r t i e s = { b u f f e r e d : b o o l e a n = t r u e ; } } Connector S i n g l e t o n L i n k = { Roles { i , o} P r o p e r t i e s = { b u f f e r e d : b o o l e a n = f a l s e ; } } A t t a c h m e n t s = { P i n g . p i n g t o B u f f e r e d . i ; B u f f e r e d . o t o Pong . p i n g ; Pong . pong t o S i n g l e t o n L i n k . i ; S i n g l e t o n L i n k . o t o P i n g . pong ; } }

FIG. 3.7 – Exemple d’une description de sysème Ping-Pong en ACME.

Une fois la définition de toutes les instances de composants et de connecteurs terminée, il reste à définir dans la partie attachment leurs interconnexions. Notons qu’une description de système telle que présentée dans la figure 3.7 peut être réutilisée dans une autre description et peut contenir des ports pour définir ses points d’interactions avec son environnement.

3.5.1.3 Evaluation

ACME est, à notre connaissance, le premier travail qui constate que la diversité des ADL devient très importante et qu’il est nécessaire de chercher à fédérer les langages existants et leurs outillages associés. Dans ce contexte, il propose un langage pivot pour passer d’un ADL à un autre. Ce langage contient des constructions de base, inspirées de Wright, pour décrire l’organisation structurelle d’un système, et bénéficie d’annotations pour intégrer des informations secondaires.

Bien qu’au niveau des idées ACME apporte une contribution considérable, sa mise en œuvre reste malheureusement difficile à utiliser. En effet, aucun outillage n’est proposé avec le langage ACME. Par conséquent, pour chaque extension définie pour fédérer deux ADL, les concepteurs doivent écrire des traducteurs entre ces ADL et ACME. De plus, la traduction ne suffirait pas étant donné que les concepteurs doivent manipuler des fichier ACME étendus pour enrichir la représentation unifiée obtenue en ACME avant de traduire cette dernière dans le langage cible. Par exemple, si l’on veut fédérer Wright

et Rapide (dans le sens indiqué), on doit d’abord utiliser (après l’avoir écrit) un traducteur pour passer de Wright à ACME, ensuite modifier les fichiers intermédiaires pour y intégrer des informations de type Rapide et enfin traduire cette représentation unifiée en Rapide. Cette procédure de fédération d’un langage vers un autre étant déjà complexe, il nous semble que l’utilisation d’ACME sera peu efficace pour fédérer des descriptions effectuées dans de multiples langages.

3.5.2 xArch et xADL

xArch [DvdHT05] et son évolution xADL [DdHT01, DvdH01] sont deux exemples de langages extensibles qui ont pur but d’intégrer les constructions classiques des ADL et les informations spécifiques aux contextes d’utilisation en se basant sur la technologie XML. Ils sont issus de travaux de l’Université de Californie à Irvine et de l’Université Carnegie Mellon.

3.5.2.1 Caractéristiques

xArch est un des premiers efforts qui visent à proposer un langage ouvert et flexible pour remplacer de multiples ADLs propriétaires par un ADL extensible, afin d’intégrer plusieurs concepts. La démarche adoptée est proche de celle d’ACME : définir un langage avec des éléments de base pour décrire l’organi-sation structurelle d’une architecture à composants, et définir un moyen d’extension pour permettre aux utilisateurs d’enrichir le langage avec des informations propres à leur contexte d’utilisation. xArch se dif-férencie d’ACME par l’utilisation de schémas XML pour décrire la grammaire des extensions apportées au langage de base.

Le langage xArch permet de décrire une instance de système à l’aide de composants, d’interfaces, de

connecteurset de liens. Notons que les connecteurs peuvent encapsuler des sémantiques de

communica-tion arbitrairement complexes et sont liés aux composants à l’aide de liens. Une architecture est décrite sous la forme d’un assemblage de ces quatre éléments. Elle peut être composée de plusieurs fichiers, chacun constituant une sous-architecture. Enfin, xArch définit une notion de groupe pour désigner un ensemble quelconque de composants ou de connecteurs. Un groupe peut par exemple être utilisé pour identifier les composants qui ont la même localisation dans le système réparti.

xADL est une évolution de xArch qui vise à décrire l’architecture des familles de produits, ce dernier étant dédié uniquement à la description des instances de systèmes. La notion de famille de produits fait référence à un ensemble de logiciels qui ont une représentation identique à quelques éléments près. À titre d’exemple, nous pouvons citer un logiciel qui a différentes versions, ou bien un logiciel d’aide à la conception qui intègre de multiples fonctionnalités optionnelles dans le cadre d’une même base architecturale.

xADL se base sur les schémas XML. Nous présentons ci-dessous les schémas d’extension définis pour xADL.

Structures et types Ce sont les éléments qui permettent de modéliser les unités de conception. Il s’agit par exemple des descriptions templates des architectures avec des composants et connecteurs abs-traits. Ces descriptions sont destinées à être enrichies par des informations liées aux implantations et au déploiement des composants pour devenir une description d’instance à la xArch. Un système de type basé sur des signatures est aussi spécifié afin de capturer la compatibilité des assemblages de composants.

Groupes Ils représentent des regroupements conceptuels de composants et de connecteurs. À titre d’exemple, citons un groupe de composants écrits par le même auteur.

Implantation Elle représente les informations liées à la mise en œuvre des composants logiciels. Par exemple, un schéma d’implantation en Java est spécifié afin de lier les éléments structurels comme les composants, les interfaces et les connecteurs à leurs classes d’implantation en Java.

3.5. Langages extensibles

Options Elles représentent les éléments optionnels d’un assemblage de composants. Nous pouvons par exemple imaginer qu’un composant de debuggage est optionnel dans l’architecture d’un environ-nement d’aide au développement (IDE).

Variantes Elles représentent des points de variations qui peuvent être intégrés à une architecture. Il s’agit, plus précisément, d’énumérer différentes variantes pour implanter une sous-architecture afin de permettre au concepteur d’en choisir une. Citons par exemple différentes variations de l’interface graphique d’un logiciel multimédia.

Versions Elles représentent les différentes versions d’un même composant. Cet élément nous semble très utile lorsque la description d’une famille de produits est utilisée pour représenter l’architecture d’un logiciel dont l’implantation des composants évolue au cours du temps.

3.5.2.2 Mise en œuvre

Les langages xArch et XADL sont basés sur XML. Le choix de XML est justifié par son extensibilité et par les outils de support déjà présents et largement utilisés. À l’origine, ces deux langages étaient basés sur la technologie XML-DTD. Les schémas XML ont été adoptés à partir de xADL v2.0 pour ses nombreux avantages par rapport à XML-DTD. Parmi ceux qui semblent utiles dans le cadre de xADL, citons l’aspect hiérarchique des descriptions qui permet de définir des relations d’héritage entre les schémas, et le système de type intégré qui permet d’effectuer de nombreuses vérifications sur des documents XML. Les extensions apportées à ces deux langages se font sous forme de nouveaux schémas qui étendent la grammaire initiale pour y intégrer de nouvelles propriétés.

La mise en œuvre de xADL v.20 imposant trop de lignes de code, nous nous limitons dans la figure 3.8 à la présentation de l’application de PingPong en xArch. La description se fait par une liste de balises qui décrivent les instances présentes dans l’architecture de l’application. Les lignes 4 à 24 décrivent le composant Ping. Cette description comprend l’attribution d’un nom (lignes 5 à 7), et la définition des interfaces pingItf et pongItf (lignes 8 à 23). À chaque instance de composant, de connecteur ou d’interface est associé un identifiant global sous forme d’un numéro. La description du composant Pong n’est pas représentée dans la figure mais serait très similaire à celle du composant Ping en inversant le sens des interfaces.

La description d’un connecteur est illustrée aux lignes 28 à 40. La description des connecteurs est très similaire à celle des composants, mais leur rôle est différent. Conformément à notre exemple clas-sique de PingPong, deux instances de connecteurs sont nécessaires ; nous n’en avons représenté qu’une seule à cause des limitations d’espace. Une fois toutes les instances de composants et de connecteurs définies, les liens doivent être mis en place pour décrire la manière dont ces derniers sont assemblés. Un exemple de lien est illustré aux lignes 42 à 50. La description du lien contient deux balises point qui définissent les points de connexions. Les identifiants des interfaces sont alors utilisés. Par exemple, le lien qui lie le composant Ping au connecteur ConnecteurSimple est lié via deux points : l’interface

pingItfdu composant Ping qui est identifiée par 2 et l’interface entrée du connecteur ConnecteurSimple

qui est identifiée par 8.

Comme nous pouvons le remarquer dans l’exemple, le langage xArch (et naturellement xADL) est très verbeux. Ceci est d’abord dû au fait que la syntaxe utilisée est XML, et ensuite au fait que les balises contiennent des informations répétitives. De plus, la gestion des identifiants globaux est une difficulté importante. Notons que ces langages ne sont destinés à être manipulés par des programmeurs, mais par des outils, graphiques ou autres. Les auteurs donnent quelques pistes sur les outillages existants dans [DdHT01]. Néanmoins, il n’y a, à notre connaissance, pas d’outil pour intégrer ces derniers dans un processus de développement complet.

1 <xArch> 2 3 < !−− D é f i n i t i o n du composant Ping −−> 4 5 6 name = P i n g 7 8 9 10 name = p i n g I t f 11 12 13 o u t 14 15 16 17 18 name = p o n g I t f 19 20 21 i n 22 23 24 25 < !−− D é f i n i t o n du composant Pong −−> 26 Les i d e n t i f i a n t s a t t r i b u é s l e s i n t e r f a c e s s o n t p i n g I t f : 5 p o n g I t f : 6 27 < !−− Fin de l a d é f i n i t i o n du composant Pong −−>

28 < !−− D é f i n i t i o n des c o n n e c t e u r s −−> 29 30 31 name = C o n n e c t e u r S i m p l e 32 33 34 35 name = e n t r é e 36 37 38 i n 39 . . . 40 41 < !−− D é f i n i t i o n de l e s a u t r e s c o n n e c t e u r s −−> . . . < !−− D é f i n i t i o n des l i e n s −−> 42 43 44 46 47 49 50 < !−− D é f i n i t i o n des a u t r e s l i e n s −−> . . . 51 52 < / xArch>

Dans le document Conception et Implantation d'un Environnement de Développement de Logiciels à Base de Composants, Applications aux Systèmes Multiprocesseurs sur Puce (Page 75-80)