4.2 Structure g´ en´ erique d’un DSTL
4.2.4 Composition des langages dans le framework
Il existe quatre techniques pour composer des langages [86]. Ces techniques sont : r´euti- liser, embarquer, r´ef´erencer et ´etendre. Les deux premi`eres techniques, r´eutiliser et embar- quer [46], n’introduisent pas de d´ependance entre les langages compos´es mais un troisi`eme langage, nomm´e langage adaptateur (adapter language), est n´ecessaire `a ce type de com-
position et d´epend des deux langages compos´es. La r´eutilisation conserve des fragments de code homog`enes pour les deux langages compos´es et s’appuie sur un concept du langage adaptateur qui ´etend un des concepts d’un premier langage, le langage source, et qui r´ef´e- rence un concept d’un deuxi`eme langage, le langage r´eutilis´e. C’est le cas de Java Native Interface (JNI) qui permet `a du code Java d’appeler ou d’ˆetre appel´e par des applications natives ou par des biblioth`eques d’autres langages (C, C++ assembleur . . .). Embarquer un langage introduit une d´ependance entre les fragments de code des deux langages : les programmes d´ecrits en langage adaptateur utilisent des concepts des deux langages com- pos´es. Pour mettre en place ce type de composition, un concept du langage adaptateur doit ´etendre un des concepts du langage hˆote et doit aussi ˆetre compos´e d’un concept du langage embarqu´e. Par cons´equent, les programmes d´ecrits en langage adaptateur forment un ensemble de fragments de code h´et´erog`enes. Du code SQL peut ˆetre embarqu´e dans de nombreux programmes ´ecrits, par exemple en C, C++ ou COBOL. Pour les bases de donn´ees de type PostgreSQL, le code SQL embarqu´e dans du code C est pr´e-compil´e, par un pr´e-compilateur nomm´e ECPG transformant le code SQL en code C.
Dans notre framework, nous avons utilis´e le r´ef´erencement et l’extension de langages car nous ne souhaitions pas introduire de nouveau langage jouant le rˆole de langage adap- tateur. Le DSTL ATA 21, le langage pivot et le langage core r´ef´erencent les langages Tools et ICD. Nous avons con¸cu ces deux langages ind´ependamment car ils r´epondent `a des pro- bl´ematiques communes `a une majorit´e de domaines avioniques.
Une d´ependance se cr´ee lorsque les concepts du langage r´ef´erenc´e se composent aux concepts du langage `a concevoir. On dit alors que le langage fait r´ef´erence aux concepts du langage de base. C’est le cas pour les langages Tools et ICD lorsque les DSTL et le langage pivot font r´ef´erence aux outils du banc et aux param`etres avioniques de l’ICD.
Le langage Tools formalise la gestion des outils externes du banc et leurs fonctionnalit´es. Un chapitre de test r´ef´erence des outils d´efinis par le langage Tools et seuls les outils r´ef´erenc´es et leurs fonctionnalit´es sont utilisables dans les instructions de tests du chapitre. Le langage ICD formalise les param`etres d’interface d’un syst`eme. Ces param`etres sont r´ef´erenc´es dans les instructions du langage pivot ou encore dans les fichiers de d´eclaration des param`etres de haut niveau du DSTL ATA 21.
La deuxi`eme technique utilis´ee repose sur l’extension de langages. Le langage core est ´
etendu par les langages impl´ementant les jeux d’instructions de chaque domaine avio- nique. Une instruction sera utilisable dans les blocs d’un chapitre uniquement si elle ´etend le concept Statement ou les concepts Step, Check, Trace, Log ou Reminder du lan- gage core. Dans le cas o`u un concept correspondant `a une instruction n’´etend pas un des concepts cit´es pr´ec´edemment, il ne sera pas possible de l’instancier dans un concept Setup ou Test d’un chapitre de test. Un chapitre de test formalis´e grˆace au langage core devra ˆ
etre compos´e d’instructions provenant d’un langage sp´ecifique `a un domaine avionique. La conception d’un jeu d’instructions r´epondant aux besoins de l’ATA 42 est pr´esent´ee `a la section suivante.
est grandement simplifi´ee car seules les instructions du DSTL sont `a concevoir. Il est alors possible de concevoir autant de langages d´edi´es qu’il y a de domaines `a couvrir.
Figure 4.11 – Interface MPS de gestion des d´ependances du DSTL ATA 42
La structuration du langage core peut ˆetre utilis´ee pour d´efinir simplement le DSTL ATA 21 grˆace au m´ecanisme d’h´eritage de MPS. En effet, les instructions d’affectation du DSTL ATA 21 (commen¸cant par Set, Increase ou Decrease) seraient typ´ees par Step et les instructions d’assertion (commen¸cant par Check ou Verify) seraient typ´ees par Check. La figure 4.11 traduit l’interface de gestion des d´ependances du DSTL ATA 42. On peut y voir le lien avec le langage Tools qui permet au DSTL de r´ef´erencer les concepts d’outils et de fonctions au sein des instructions. Cette figure explicite aussi le lien de d´ependance entre le langage core et le jeu d’instructions d´edi´e `a l’ATA 42. Ce lien est caract´eris´e par Extends ce qui permet aux instructions de l’ATA 42 d’´etendre les concepts Step, Check, Trace, Log ou Reminder. Les concepts impl´ementant ces instructions ´etendront le type qui leur aura ´et´e attribu´e via les m´ecanismes d’h´eritage de MPS. A l’utilisation, le langage core et le langage impl´ementant un jeu d’instructions doivent ˆetre import´es dans la mˆeme solution MPS. Une solution est le nom d’un projet MPS dans lequel les programmes DSL peuvent ˆetre con¸cus.