THÈSEflfs.emn.fr/images/3/39/TheseFabry.pdf · 2014-01-14 · Sapan. En n et surtout, je remercie...

No d'ordre: 00000

THÈSE

présentée

devant l'Université de Bordeaux 1

pour obtenir

le grade de : Docteur de l'Université de Bordeaux 1

Mention Informatique

par

Fabien Latry

Équipe d'accueil : PhoenixÉcole Doctorale : Mathématiques et Informatique

Composante universitaire : LaBRI

Titre de la thèse :

Approche langage au développement logiciel :

Application au domaine des services de Téléphonie sur IP

À soutenir le ? ? septembre 2007 devant la commission d'examen

M. : ? ? ? ? PrésidentMM. : Jean Bézivin Rapporteurs

Olivier DanvyMM. : ? ? ? ? Examinateurs

Renaud MarletCharles Consel

à Laetitia,

Remerciements (provisoires)

Je tiens tout d'abord à remercier les membres du jury :� Jean Bézivin, professeur à l'Université de Nantes (France) et Olivier Danvy, pro-fesseur à l'Université d'Aarhus (Danemark), d'avoir accepté la lourde tâche derapporteur.

� Renaud Marlet, chargé de recherches INRIA, d'avoir gentiment accepté d'êtremembre de ce jury malgré un emploi du temps chargé.

� Charles Consel, professeur des Universités et responsable du projet Ph÷nix, quim'a donné l'opportunité de réaliser cette thèse. Je tiens à lui exprimer ma trèsvive reconnaissance pour l'aide et le soutien qu'il m'a apporté au cours de ces an-nées, et la con�ance dont il a fait preuve à mon égard. Son intérêt et ses précieuxconseils m'ont été d'un grand pro�t.

Je tiens également à remercier tout particulièrement Julien Mercadal et VincentMalige, sans qui ce travail n'aurait pas pu être possible. La collaboration de Julien aété décisive et des plus enrichissantes. De plus, sa disponibilité, sa patience et sa qualitéont été des aides précieuses. Quant à Vincent, son soutien sans faille et ses relecturestoujours pertinentes m'ont permis d'y croire même dans des moments parfois di�ciles,et pour cela je le remercie.

Je tiens également à remercier tous les membres du projet Phoenix (David, Julien2,Laurent2, Nicolas, Sylvie, Wilfried et Zoé), ainsi que tous les gens qui de près ou de loinont participé à cette aventure. Je pense entre autres à Anne-Françoise, Julia ou encoreSapan.

En�n et surtout, je remercie mes proches pour leur soutien sans faille et plus par-ticulièrement Laetitia qui m'a toujours donné la force de continuer. Sa patience, sacompréhension et ses encouragements de tous les instants m'ont permis de mener à biencette aventure et de me concentrer sur mon travail.

Résumé

Le développement logiciel connaît ces dernières années un bouleversement majeurdû à l'émergence de nouveaux programmeurs non-informaticiens. Il ne s'agit plus désor-mais de fournir des solutions de programmation de plus en plus puissantes et expressives,mais davantage de produire des outils spéci�ques à un métier, haut niveau et adaptésaux utilisateurs. Cependant, la diversité des pro�ls de développeurs entraîne une multi-plicité des besoins en termes de solutions de programmation. Sans une factorisation etune automatisation des processus de conception et d'implémentation, il est impossiblede répondre à ces attentes du fait du coût de mise en ÷uvre de telles solutions. Deplus, le manque d'expertise en programmation de ces non-informaticiens entraîne descontraintes fortes en termes de �abilité, notamment en ce qui concerne le respect despropriétés métiers du domaine d'application.

Cette thèse propose une nouvelle approche basée sur les langages dédiés à un do-maine (DSL). Un langage dédié est un langage dont les constructions et les notationssont adaptées à la sémantique d'un domaine, ce qui permet aux experts de concevoirles solutions dans des termes métiers et non informatiques. Notre approche repose surune architecture en couches des langages, introduisant une séparation entre la program-mation et la modélisation de solutions. Cette di�érenciation permet à la fois d'éleverprogressivement le niveau d'abstraction des solutions, mais également de spécialiser etd'automatiser les processus de compilation et de véri�cation de propriétés du domaine.

Nous illustrons notre démarche avec le domaine de la création de services de Télé-phonie sur IP. À la suite d'une analyse complète du domaine, nous avons conçu deuxlangages dédiés, SPL et VisuCom, évoluant à des niveaux d'abstraction di�érents et ré-pondant à des besoins distincts des développeurs. À travers VisuCom, nous proposonségalement une nouvelle approche du développement de services de téléphonie, visantà intégrer le métier de l'utilisateur dans le processus de conception de services. Ens'appuyant sur ces langages, notre architecture en couches permet de séparer les préoc-cupations du domaine de celles liées à l'implémentation. Ainsi, nous montrons que lesprocessus de compilation et de véri�cation des solutions se trouvent fortement simpli�éset à la portée d'outils haut niveau existants, comme des transformateurs de programmesou des véri�cateurs de modèles.

L'approche proposée dans cette thèse est un premier pas vers la convergence desapproches de l'Ingénierie Dirigée par les Modèles et des langages de programmation,ouvrant ainsi de nouvelles perspectives de recherche relatives à ces deux approches.

Mots clés

Langages dédiés, ingénierie dirigée par les modèles, transformation et véri�cation deprogramme, téléphonie sur IP

Abstract

Over the last decade, allowing non-programmers to write their own programs has be-come a practical challenge that is currently receiving enormous attention in the softwareengineering community. The question is no longer to provide expressive and powerfulprogramming solutions, but to develop domain-speci�c high-level tools that are adap-ted to the users. Because a variety of preferences and constraints can be expressed bythese non-programmers, a variety of programming solutions must be envisioned thato�er di�erent visual or textual paradigms and various degrees of expressivity. Providingsuch a panel of solutions is likely to be a major development process. Moreover, becausethese non-programmers have no programming training, the reliability of their programsis a fundamental problem that requires veri�cation of domain-speci�c properties.

This thesis proposes a new approach to the development of high-level solutions thatis based on a layered view of domain-speci�c languages (DSL). By nature, DSLs arevery di�erent. A study of the literature in domain-speci�c modeling raises the issueof relating and distinguishing the notion of domain-speci�c languages from a modelingviewpoint and from a programming-language viewpoint. This distinction enables oneto separate the domain concerns from the implementation concerns. In doing so, theabstraction level is raised further, bringing up opportunities regarding the compilationof programs and the veri�cation of their domain-speci�c properties.

We have validated our approach in the domain of telephony service creation. Througha complete domain analysis, we have designed two di�erent domain-speci�c languages,SPL and VisuCom. SPL is an expressive programming language that provides servicedevelopers with high-level, domain-speci�c constructs. In contrast, VisuCom allows do-main experts to directly express solutions in domain terms, without necessarily requi-ring programming skills. We show that layering DSLs enables one to separate domainconcerns and implementation concerns. In doing so, our approach greatly facilitates theimplementation of high-level solutions and the veri�cation of telephony-speci�c proper-ties, by leveraging on high-level tools such as program-transformation tools or modelcheckers.

The proposed approach is a �rst step in the convergence of modeling and programming-language approaches, opening up new research opportunities in these two �elds.

Key words

Domain-speci�c languages, model-driven engineering, program transformation andveri�cation, telephony over IP

Table des matières

1 Introduction 71.1 Thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3 Organisation du document . . . . . . . . . . . . . . . . . . . . . . . . . . 10

I Contexte 13

2 Ingénierie dirigée par les modèles 152.1 Introduction à la modélisation . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.1.2 Le monde des modèles . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2 Approches existantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.1 Architecture dirigée par les modèles . . . . . . . . . . . . . . . . 192.2.2 Modélisation spéci�que à un domaine . . . . . . . . . . . . . . . 21

2.3 Limitations des approches . . . . . . . . . . . . . . . . . . . . . . . . . . 242.3.1 Architecture dirigée par les modèles . . . . . . . . . . . . . . . . 242.3.2 Modélisation spéci�que à un domaine . . . . . . . . . . . . . . . 26

2.4 Évolution récente de l'IDM . . . . . . . . . . . . . . . . . . . . . . . . . 272.5 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3 Langages dédiés 293.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2.1 Programmation du domaine de problèmes . . . . . . . . . . . . . 313.2.2 Sûreté améliorée . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.2.3 Réutilisation systématique . . . . . . . . . . . . . . . . . . . . . . 33

3.3 Processus de développement . . . . . . . . . . . . . . . . . . . . . . . . . 333.3.1 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.3.2 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.4 Limitations actuelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.4.1 Coût de développement . . . . . . . . . . . . . . . . . . . . . . . 383.4.2 Problèmes liés au domaine . . . . . . . . . . . . . . . . . . . . . . 383.4.3 Propriétés du langage . . . . . . . . . . . . . . . . . . . . . . . . 39

1

3.5 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4 Étude de cas : la Téléphonie sur IP 414.1 Introduction à la téléphonie applicative . . . . . . . . . . . . . . . . . . . 414.2 L'environnement SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2.1 Les principes du protocole SIP . . . . . . . . . . . . . . . . . . . 434.2.2 SIP par l'exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2.3 Introduction aux services SIP . . . . . . . . . . . . . . . . . . . . 44

4.3 Les enjeux de la création de services . . . . . . . . . . . . . . . . . . . . 454.4 État de l'art des solutions existantes . . . . . . . . . . . . . . . . . . . . 474.5 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5 Bilan 515.1 La diversité des programmeurs . . . . . . . . . . . . . . . . . . . . . . . 515.2 Problématiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

II Approche proposée 55

6 Présentation de l'approche 576.1 L'approche proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.2 Une dichotomie bien réelle . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7 Application à la Téléphonie sur IP 637.1 Analyse du domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7.1.1 Une programmation trop complexe . . . . . . . . . . . . . . . . . 637.1.2 Des approches divergentes . . . . . . . . . . . . . . . . . . . . . . 677.1.3 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7.2 SPL, un langage dédié de programmation . . . . . . . . . . . . . . . . . 697.2.1 L'environnement d'exécution . . . . . . . . . . . . . . . . . . . . 697.2.2 Le langage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727.2.3 Propriétés garanties . . . . . . . . . . . . . . . . . . . . . . . . . 757.2.4 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

7.3 VisuCom, un langage dédié de modélisation . . . . . . . . . . . . . . . . 787.3.1 De nouveaux besoins . . . . . . . . . . . . . . . . . . . . . . . . . 797.3.2 Une nouvelle approche . . . . . . . . . . . . . . . . . . . . . . . . 807.3.3 Le langage VisuCom . . . . . . . . . . . . . . . . . . . . . . . . . 847.3.4 Propriétés garanties . . . . . . . . . . . . . . . . . . . . . . . . . 87

7.4 Application de notre approche . . . . . . . . . . . . . . . . . . . . . . . . 887.5 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

8 Méthodologie de compilation de DSL 938.1 Problématique de la compilation d'un DSL . . . . . . . . . . . . . . . . . 938.2 Méthodologie de développement de compilateurs . . . . . . . . . . . . . 95

8.2.1 La représentation abstraite . . . . . . . . . . . . . . . . . . . . . 95

Table des matières 3

8.2.2 Les di�érentes dimensions de compilation . . . . . . . . . . . . . 968.3 Compilation de la représentation abstraite . . . . . . . . . . . . . . . . . 98

8.3.1 La programmation orientée aspect . . . . . . . . . . . . . . . . . 1018.3.2 Les annotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1028.3.3 La spécialisation de programme . . . . . . . . . . . . . . . . . . . 102

8.4 Compilation des unités fonctionnelles . . . . . . . . . . . . . . . . . . . . 1038.4.1 Facette environnement d'exécution . . . . . . . . . . . . . . . . . 1038.4.2 Facette langage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1048.4.3 Facette programme . . . . . . . . . . . . . . . . . . . . . . . . . . 107

8.5 Compilation des unités non-fonctionnelles . . . . . . . . . . . . . . . . . 1088.5.1 Facette environnement d'exécution . . . . . . . . . . . . . . . . . 1098.5.2 Facette langage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1098.5.3 Facette programme . . . . . . . . . . . . . . . . . . . . . . . . . . 110

8.6 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

9 Compilation et véri�cation de DSML 1139.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

9.1.1 Stratego/XT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1169.1.2 TLA+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

9.2 Compilation de DSML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1189.2.1 Compilation vers SPL . . . . . . . . . . . . . . . . . . . . . . . . 1199.2.2 Compilation vers TLA+ . . . . . . . . . . . . . . . . . . . . . . . 121

9.3 Véri�cation de DSML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1249.3.1 Véri�cation de services CPL . . . . . . . . . . . . . . . . . . . . . 1259.3.2 Le cas particulier du modèle VisuCom . . . . . . . . . . . . . . . 128

9.4 Travaux connexes à notre approche en couches . . . . . . . . . . . . . . 1319.5 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

10 Conclusion 13310.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13310.2 Perspectives et Futures Directions . . . . . . . . . . . . . . . . . . . . . . 135

Publications 137

Bibliographie 139

A Le langage TLA+ 153A.1 Logique temporelle : un peu d'histoire... . . . . . . . . . . . . . . . . . . 153A.2 Qu'est ce que la logique temporelle des actions ? . . . . . . . . . . . . . . 154A.3 Spéci�cation TLA+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155A.4 Le model checker TLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

4 Table des matières

Table des �gures

2.1 Niveaux de modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2 Architecture dirigée par les modèles (MDA) . . . . . . . . . . . . . . . . 202.3 Modélisation spéci�que à un domaine (DSM) . . . . . . . . . . . . . . . 22

3.1 Processus de développement d'un langage dédié . . . . . . . . . . . . . . 36

4.1 Architecture SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2 Service de téléphonie écrit en CPL . . . . . . . . . . . . . . . . . . . . . 48

6.1 Vue générale de notre approche . . . . . . . . . . . . . . . . . . . . . . . 58

7.1 Le service Compteur écrit en JAIN SIP . . . . . . . . . . . . . . . . . . 657.2 L'environnement SIP-SLEE et les méthodes de contrôle . . . . . . . . . 707.3 Structure d'un service SPL . . . . . . . . . . . . . . . . . . . . . . . . . 737.4 Le service Compteur écrit en SPL . . . . . . . . . . . . . . . . . . . . . . 737.5 Le service hotline écrit en SPL . . . . . . . . . . . . . . . . . . . . . . . 767.6 Processus d'interconnexion du SI au système de téléphonie . . . . . . . . 817.7 Exemple d'informations concernant un contact . . . . . . . . . . . . . . 837.8 Le service VisuCom Filtrage sur Indisponibilité . . . . . . . . . . . . . . 867.9 Illustration de notre approche dans la téléphonie . . . . . . . . . . . . . 887.10 Comparaison des approches CPL, VisuCom et SPL . . . . . . . . . . . . 897.11 Comparaison des approches SPL et JAIN SIP . . . . . . . . . . . . . . . 91

8.1 Méthodologie de développement de compilateurs de DSL . . . . . . . . . 968.2 Le service Compteur écrit en SPL . . . . . . . . . . . . . . . . . . . . . . 988.3 La représentation abstraite du service Compteur écrite en JAIN SIP . . 1008.4 Comparaison du service SPL et de sa représentation abstraite . . . . . . 1018.5 Aspect correspondant à la facette environnement d'exécution . . . . . . 1048.6 Aspect correspondant à la facette langage (1) . . . . . . . . . . . . . . . 1058.7 Aspect correspondant à la facette langage (2) . . . . . . . . . . . . . . . 1068.8 Aspect correspondant à la facette programme . . . . . . . . . . . . . . . 1088.9 Annotations correspondantes à la facette langage . . . . . . . . . . . . . 110

9.1 Compilation et véri�cation de DSML . . . . . . . . . . . . . . . . . . . . 1159.2 Comparaison des approches CPL et SPL . . . . . . . . . . . . . . . . . . 120

5

6 Table des �gures

9.3 Règles Stratego pour compiler CPL en SPL . . . . . . . . . . . . . . . . 1209.4 Règle Stratego pour compiler VisuCom en SPL . . . . . . . . . . . . . . 1219.5 Règle Stratego pour générer une spéci�cation TLA+ depuis CPL . . . . 1239.6 Règle Stratego pour générer une spéci�cation TLA+ depuis VisuCom . . 1249.7 Extrait des propriétés à véri�er pour un service de téléphonie . . . . . . 1259.8 Service CPL inconsistant (adresses) . . . . . . . . . . . . . . . . . . . . . 1269.9 Service CPL inconsistant (dates) . . . . . . . . . . . . . . . . . . . . . . 1279.10 Rapport d'erreurs TLC concernant un service CPL . . . . . . . . . . . . 1289.11 Service VisuCom inconsistant vis-à-vis de la base de contacts . . . . . . 1309.12 Rapport d'erreurs TLC concernant un service VisuCom . . . . . . . . . 130

A.1 Séquence d'états . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154A.2 Spéci�cation TLA+ d'un service VisuCom - partie 1 . . . . . . . . . . . 155A.3 Spéci�cation TLA+ d'un service VisuCom - partie 2 . . . . . . . . . . . 156A.4 Fichier de con�guration à un instant donné . . . . . . . . . . . . . . . . 159A.5 Extrait d'un rapport TLC sans erreur . . . . . . . . . . . . . . . . . . . 159

Chapitre 1

Introduction

Ces dernières années ont vu l'émergence d'un nouveau type de programmeur, l'utili-sateur �nal [MKB06]. Ces utilisateurs perçoivent la programmation comme un nouveaumoyen d'exprimer des solutions en adéquation à leurs problèmes. Un programmeur n'estplus désormais principalement un expert en programmation, mais il peut à la place êtreun comptable qui manipule des feuilles de calcul, un �nancier qui souhaite simuler l'évo-lution des marchés boursiers, ou encore un électronicien qui désire modéliser le com-portement d'un système électronique [SSM05a]. Ces nouveaux développeurs1 utilisentl'ordinateur pour une tâche bien précise relative à leurs métiers, à leurs domaines decompétence, mais ne possèdent souvent aucune connaissance en programmation. L'undes premiers enjeux consiste donc à faire disparaître toute notion de programme et negarder que les informations pertinentes du point de vue de l'utilisateur et de son do-maine. Il est alors nécessaire de cacher toute complexité, qu'elle soit issue de la diversitédes technologies, des méthodes de conception ou encore des procédés de développement.Le mécanisme d'abstraction est ainsi utilisé depuis longtemps par l'ingénierie logiciellecomme un moyen de masquer et de gérer toute cette complexité.

Abstraire un système consiste à en extraire les caractéristiques essentielles par rap-port à un type d'utilisateur et à un domaine particulier. Ce faisant, l'abstraction per-met non seulement de cacher les détails non essentiels à l'utilisateur, mais égalementde s'appuyer sur des connaissances métiers pour résoudre des problèmes récurrents dece domaine. De nombreuses approches permettent d'élever le niveau d'abstraction etde masquer la complexité des systèmes [CE00]. La plus récente est l'Ingénierie Dirigéepar les Modèles (IDM). Elle vise à utiliser des représentations abstraites et simpli�éesde systèmes (appelées modèles) a�n d'élever le niveau d'abstraction et d'augmenterl'automatisation du développement de programmes [Béz06]. Cependant, la plupart dutemps, ces solutions fournissent des abstractions de l'espace de solutions, c'est-à-diredu domaine des technologies informatiques, plutôt que des abstractions de l'espace deproblèmes, qui permettraient d'exprimer les besoins dans les termes des domaines d'ap-plication (�nance, médecine, assurance, ou encore biologie). Or, il ne s'agit pas seulement

1Dans la suite de ce document, nous utiliserons le terme développeurs pour désigner ces nouveauxutilisateurs sans expérience en programmation, parfois appelés non-programmeurs.

7

8 Introduction

de cacher la complexité ou d'élever le niveau d'abstraction. Il s'agit également de fournirà ces développeurs non-informaticiens des outils adaptés à leurs besoins. Ces outils per-mettent de raisonner au même niveau que le problème, tout en leur assurant un certainnombre de propriétés spéci�ques à leurs métiers (e.g., performance et �abilité).

Dans tous les métiers, l'ouvrier dispose d'outils dédiés, pour l'aider à accomplir sontravail e�cacement. Un maçon qui construit une maison possède par exemple une boîteà outils contenant une équerre, un cordeau à tracer ou encore une truelle, chacun spé-cialisé à une tâche précise du métier de maçon. Il ne viendrait pas à l'idée d'un plombierd'utiliser la même boîte à outils. Il en va de même pour les outils informatiques. De parla diversité des utilisateurs et des domaines d'application, il est impossible de mettreen ÷uvre une solution généraliste, qui fournirait des abstractions généralistes et quipermettrait à tous les développeurs non-informaticiens de résoudre leurs problèmes. Aucontraire, il apparaît évident que cette multitude de domaines et d'utilisateurs nécessitela mise en place d'outils spéci�ques, dédiés tant au métier qu'au pro�l du développeurauxquels ils sont destinés. De plus, pour paraphraser Jackson, �la valeur d'une abstrac-tion augmente avec son degré de spéci�cité dans le domaine� [Jac01]. Une abstractionplus spéci�que contient donc davantage de connaissance sur le domaine qu'une abstrac-tion plus généraliste parce qu'elle renferme plus d'informations. En d'autres termes, elleest plus puissante pour résoudre les problèmes du domaine.

1.1 Thèse

La thèse présentée dans ce document propose une approche centrée sur les langagesde programmation et plus spéci�quement les langages de programmation dédiés à undomaine (DSL2). Elle repose sur une architecture en couches des langages. Cette archi-tecture permet à la fois d'élever progressivement le niveau d'abstraction, mais aussi deprendre en compte toutes les spéci�cités du domaine d'application, a�n de fournir auxutilisateurs des outils dédiés à leurs métiers ou à la tâche à e�ectuer. Les langages dedemain ne sont pas des langages de programmation traditionnels, mais bien plus deslangages qui sont adaptés aux utilisateurs, à leurs connaissances ou encore à leurs rôlesdans l'organisation3. Nous illustrons et validons notre approche par l'étude du domainede la création de services de Téléphonie sur IP.

Un langage dédié se dé�nit comme un langage de programmation restreint à undomaine ou un problème particulier. Il représente un moyen reconnu pour permettreaux utilisateurs de programmer sans être experts en programmation. L'utilisation deslangages dédiés permet de faciliter de manière signi�cative la construction de systèmeslogiciels pour les domaines auxquels ils sont dédiés [Ben86]. De plus, du fait d'uneexpressivité restreinte, ils facilitent la véri�cation de propriétés métiers, ou encore aug-mentent la productivité logicielle [Thi98]. Cependant, la conception et l'implémentationde DSL sont encore aujourd'hui des tâches considérées comme ardues. C'est l'une des

2DSL est l'acronyme anglais de Domain-Speci�c Language.3Dans la suite de ce document, le terme organisation désigne une entreprise, une administration, ou

tout simplement un service ou tout autre structure professionnelle.

Contributions 9

raisons pour lesquelles les langages dédiés ne sont pas aujourd'hui aussi populaires quepourraient le souhaiter les chercheurs.

L'approche que nous proposons introduit plusieurs langages dédiés au domaine de lacréation de services de Téléphonie sur IP. Ces langages évoluent à des niveaux d'abstrac-tion di�érents et sont adaptés à des programmeurs ayant des compétences di�érentesainsi que des rôles di�érents dans l'organisation. Les langages dédiés de plus haut ni-veau, c'est-à-dire possédant les plus fortes abstractions, sont implémentés sous la formed'un langage dédié de plus bas niveau, plus expressif et plus à même de résoudre desfamilles de problèmes complexes. Ce dernier est ensuite compilé dans un environnementd'exécution. Cette architecture en couches des langages permet de réduire simplementle fossé entre les abstractions du domaine et leurs implémentations, mais également deréutiliser le langage dédié intermédiaire, facilitant ainsi l'implémentation des langages deplus haut niveau. Cette architecture introduit, de plus, une di�érenciation des approchesentre la modélisation de solutions et la programmation de solutions, ce qui permet àchaque niveau de spécialiser certaines tâches comme la véri�cation de propriétés ouencore la compilation.

1.2 Contributions

La contribution de cette thèse est double. Dans un premier temps, nous montronscomment, par une analyse de domaine et une approche centrée sur les besoins desutilisateurs, il est possible d'architecturer les langages dédiés à un domaine d'application.Nous appliquons la démarche sur le domaine de la création de services de Téléphoniesur IP. Cette démarche nous permet de monter en abstraction dans le domaine et defournir ainsi des solutions et des outils adaptés aux besoins et aux types d'utilisateurs.Dans un second temps, nous proposons une mise en ÷uvre de cette architecture, baséesur la réutilisation d'outils existants, et évaluons les avantages de cette approche entermes de facilité de compilation et de véri�cation de propriétés du domaine.

Approche orientée utilisateurs des langages dédiés. Nous introduisons une nou-velle approche des langages dédiés, centrée sur les besoins de l'utilisateur �nal. Nousmontrons qu'une distinction entre des langages orientés programmation et des langagesorientés modélisation nous permet de di�érencier les besoins des développeurs, maisaussi d'architecturer les langages.

Analyse de domaine. Nous présentons une analyse complète du domaine de la créa-tion de services de Téléphonie sur IP. Nous identi�ons les di�érents acteurs du domaineet leurs rôles, et nous introduisons deux langages dédiés, SPL4 et VisuCom, qui per-mettent de programmer des services de téléphonie à des niveaux d'abstraction di�érents.

Approche langage. Nous décrivons l'architecture en couches des langages dédiés.Nous montrons dans quelle mesure elle permet de répondre au besoin de la montée

4SPL est l'acronyme de Session Processing Language.

10 Introduction

en abstraction, tout en résolvant le problème du fossé entre le niveau d'abstraction etl'implémentation. Illustrée dans le domaine de la création de services de Téléphoniesur IP, nous montrons que cette architecture permet de séparer les préoccupations dudomaine de celles liées à l'implémentation.

Processus de compilation simpli�é. La séparation des préoccupations et l'archi-tecture en couches nous permettent de montrer que le processus de compilation devientbeaucoup plus simple de par la diminution du pas de compilation. De plus, chaque ni-veau d'abstraction est dédié à des aspects di�érents, domaine et implémentation, ce quipermet de dédier chaque processus de compilation. Nous montrons également commentles outils de génération de programmes haut niveau peuvent aider à simpli�er ces étapesde compilation.

Véri�cation de propriétés du domaine. La séparation des préoccupations facilitenotablement la véri�cation des propriétés du domaine. Les détails d'implémentationn'apparaissant plus, seule la logique du domaine est manipulée. Nous montrons alorscomment notre architecture facilite la réutilisation des outils haut niveau a�n de véri�erdes propriétés du domaine de la téléphonie, à l'aide d'un véri�cateur de modèles (modelchecker) par exemple.

1.3 Organisation du document

Ce document est organisé en deux parties. Nous présentons tout d'abord le contextescienti�que dans lequel s'inscrit cette thèse. Nous décrivons ensuite notre approche etses avantages, en l'illustrant dans le domaine de la création de services de Téléphoniesur IP.

Contexte. La première partie porte sur l'étude du contexte scienti�que dans lequelnous nous plaçons. Les chapitres 2 et 3 présentent respectivement un état de l'artautour des approches existantes de l'Ingénierie Dirigée par les Modèles et des langagesdédiés. Ces deux approches sont aujourd'hui les plus répandues pour élever le niveaud'abstraction des systèmes logiciels. Ces chapitres montrent également pourquoi cesmécanismes ne permettent pas à eux seuls de répondre aux besoins énoncés dans cedocument et soulignent leurs limites. Le chapitre 4 présente le domaine d'applicationchoisi pour illustrer notre thèse : la création de services de Téléphonie sur IP. En�n,le chapitre 5 dresse le bilan de cette étude et résume les problématiques soulevées parl'ouverture de la programmation à des non-programmeurs.

Approche proposée. La seconde partie vise à illustrer l'approche proposée dansle domaine de la création de services de Téléphonie sur IP. Le chapitre 6 présentenotre approche en couches des langages, basée sur une décomposition des solutions deprogrammation selon les besoins des utilisateurs. En s'appuyant sur cette décomposition,le chapitre 7 revisite le domaine de la création de services de Téléphonie sur IP et

Organisation du document 11

introduit deux langages dédiés, SPL et VisuCom. Les chapitres 8 et 9 illustrent lesavantages de la séparation entre le domaine et l'implémentation, à la fois en termes deprocessus de compilation et de véri�cations de propriétés du domaine. Pour conclure, lechapitre 10 récapitule nos contributions et donne les directions futures de nos travaux.

12 Introduction

Première partie

Contexte

13

Chapitre 2

Ingénierie dirigée par les modèles

La complexité et la diversité des technologies existantes, mais aussi la multiplicationdes besoins, font aujourd'hui du développement logiciel un véritable dé�. Pour y faireface, il est nécessaire de fournir une approche permettant d'abstraire toutes les com-plexités technologiques. L'Ingénierie Dirigée par les Modèles (IDM1) cherche à répondreà cette attente. Cette approche émergente du développement logiciel considère le mo-dèle comme l'objet central de toutes les ré�exions dans les processus de conception etde développement logiciel. Désormais, il ne s'agit plus de considérer les modèles du seulpoint de vue contemplatif, mais également d'un point de vue productif, visant l'auto-matisation de la production logicielle et donc la réduction des coûts de développement.

Dans ce chapitre, nous présentons l'approche orientée modèle comme une solutionau problème de la complexité logicielle. Après une brève introduction sur les enjeux etles concepts autour de la modélisation, nous présentons un aperçu macroscopique dessolutions existantes, et tout particulièrement l'initiative MDA (Model-Driven Architec-ture), fer de lance de l'Ingénierie Dirigée par les Modèles. En�n, nous nous penchonssur les limites actuelles de ces solutions pour un déploiement industriel.

2.1 Introduction à la modélisation

De Bill Gates à Richard Soley2, en passant bien entendu par les pionniers du mondeUML (Uni�ed Modeling Language) comme Graddy Booch, tous a�rment qu'il est tempsde concevoir les applications logicielles à partir de modèles, et surtout, de faire en sorteque ces modèles soient au centre du cycle de vie des applications, autrement dit qu'ilssoient productifs [Bla05].

La modélisation, au sens le plus large, vise à représenter de manière abstraite etla plus simpli�ée possible une entité du monde réel, en vue de la décrire, l'expliquer,

1Pour évoquer l'Ingénierie Dirigée par les Modèles, la littérature anglaise fait état de deux expressionsModel-Driven Engineering (MDE) ou encore Model-Driven Development (MDD). Dans ce document,nous utiliserons de manière indi�érente le terme Ingénierie Dirigée par les Modèles et IDM.

2Richard Soley est le directeur de l'OMG (Object Management Group), un groupement internationaldont l'objectif est de promouvoir des standards qui garantissent l'interopérabilité entre applicationsorientées objet.

15

16 Ingénierie dirigée par les modèles

ou encore la simuler. Un modèle permet alors de réduire la complexité d'un systèmelogiciel en éliminant les détails jugés non indispensables pour l'utilisateur du modèle.En prenant en compte le point de vue de l'utilisateur, le modèle re�ète donc ce quele concepteur juge important pour la compréhension du système modélisé. Loin de seréduire à l'expression d'une solution à un niveau d'abstraction plus élevé que le code, lamodélisation recherche avant tout une automatisation du développement logiciel, ainsiqu'une réduction des coûts de développement.

Si ces mécanismes d'abstraction et de modélisation ne représentent pas une inno-vation en soi et sont le pain quotidien des développeurs depuis toujours, bien souventleurs utilisations se font de manière implicite ou tout du moins informelle. Le véritabledé� de l'approche de l'Ingénierie Dirigée par les Modèles est de mécaniser ce proces-sus. Son but est de mettre à disposition des outils, concepts et langages pour créeret transformer les modèles. De manière plus générale, et comme de nombreuses autresapproches du génie logiciel (programmation générative, programmation par aspects, ouencore langages dédiés), l'IDM est une forme d'ingénierie générative, qui se singula-rise par une démarche dans laquelle tout ou partie d'une application informatique estgénérée à partir de modèles.

2.1.1 Motivations

Les motivations et les principes sous-jacents au développement dirigé par les modèlesne sont pas nouveaux. Le but premier est d'élever le niveau d'abstraction et ce faisant,de réduire à la fois l'e�ort des développeurs ainsi que la complexité des artéfacts logi-ciels qu'ils utilisent. Ainsi, l'approche vise à automatiser le processus de développementlogiciel. Mais, si la maîtrise de la complexité reste aujourd'hui l'un des enjeux majeursdu développement logiciel, elle n'est pas le seul facteur à l'émergence des nouveaux dé�sdu génie logiciel que vise à relever l'Ingénierie Dirigée par les Modèles.

Comme le remarquent Clark et al. [CESW04], ces dé�s sont souvent une combinai-son de trois facteurs principaux : la complexité, la diversité et l'évolution. La complexitédes plates-formes technologiques, mais également l'hétérogénéité et la diversité des do-maines, des techniques, des processus, ou encore des outils de développement tendentà rendre spéci�que la tâche de développement logiciel, ainsi qu'à spécialiser les com-pétences techniques des concepteurs, mais aussi des utilisateurs. Toute généralisationou automatisation du processus devient alors impensable. De la notion de diversité desbesoins découle alors la nécessité de variation de produits logiciels. Cette variation peutse traduire en termes de besoins fonctionnels, mais également non-fonctionnels (e.g., sé-curité, �abilité, performance, �exibilité). Dans un contexte de lignes de produits, cetteproblématique se retrouve dans le besoin de décliner des gammes de produits. Il est alorsprimordial de ne pas refaire à chaque fois le processus complexe de conception dans sonintégralité mais de factoriser, de capitaliser et d'automatiser le plus possible les étapesde conception. Dans le cas contraire, le processus deviendrait beaucoup trop coûteux,lent et sujet à erreurs. À tout cela s'ajoute le besoin d'évolution, intimement lié à lanotion de diversité, et qui ne doit pas être sous-estimé. Chacun des axes de diversitépeut devenir une dimension d'évolution du logiciel. Les besoins des utilisateurs ainsi

Introduction à la modélisation 17

que les limites des domaines d'application peuvent évoluer, les outils de développementpeuvent changer, les plates-formes technologiques peuvent devenir obsolètes.

A�n de répondre à ces attentes, l'Ingénierie Dirigée par les Modèles s'appuie sur unprincipe fort du génie logiciel, la séparation des préoccupations. Il est en e�et nécessairede clairement découpler la logique métier de la mise en ÷uvre technologique. L'abs-traction vis-à-vis des technologies d'implémentation permet par exemple d'adapter unelogique métier à un contexte d'utilisation particulier, mais aussi d'évoluer plus facile-ment vers de nouvelles technologies. Voilà pourquoi il est généralement utile d'introduiredi�érents niveaux d'abstraction pour modéliser un système.

2.1.2 Le monde des modèles

L'Ingénierie Dirigée par les Modèles utilise l'image de modèles productifs commeleitmotiv, a�n d'expliquer les théories sous-jacentes à l'utilisation actuelle des modèles.A�n de bien comprendre les concepts et leurs relations, il est primordial de changer notreperception courante des modèles, et de passer d'une vision contemplative des modèles(ayant pour but de documenter, spéci�er, ou communiquer) à une vision productive.Au lieu de se restreindre à exprimer le dessein de l'utilisateur de manière informelle,l'Ingénierie Dirigée par les Modèles utilise les modèles pour capturer le but de manièreprécise et pour automatiser tout ou partie de son implémentation. Pour cela, l'approcherepose sur des langages de modélisation.

Cette section dé�nit les concepts de base de l'Ingénierie Dirigée par les Modèles et lesrelations qui existent entre ces concepts. Elle vise avant tout à préciser la terminologieemployée dans la suite du document et est adaptée de la description de Fleurey [Fle06]et de Bézivin et al. [BBB+04].

Modèles. La notion de modèle est l'élément central de toute l'approche. Si aucunedé�nition n'est véritablement reconnue à ce jour, la littérature [BG01] s'accorde à carac-tériser un modèle de la manière suivante. Un modèle peut être vu comme une abstractiond'un système, et de manière plus générale, comme une abstraction de la réalité. Bien évi-demment, du fait qu'un modèle augmente le niveau d'abstraction, des informations sontomises, ce qui rend le système plus simple et plus facile à comprendre. Ainsi, les modèlespermettent de capturer la complexité d'un système et de raisonner sur quelques-unesde ses propriétés, en ignorant certains détails de manière à ne considérer que ceux quipeuvent être pertinents, utiles et intéressants, vis-à-vis de l'utilisation qui en sera faite.Un modèle est construit dans un but précis dans la mesure où les informations qu'ilcontient sont choisies pour être pertinentes. Les critères de choix concernant les infor-mations à visualiser dépendent donc du point de vue considéré. À titre d'exemple, unecarte routière est un modèle d'une zone géographique, conçu pour la circulation auto-mobile dans cette zone. Pour être utilisable par un automobiliste, une carte routière nedoit inclure qu'une information très synthétique et spéci�que sur la zone cartographiée :une carte qui indique la composition des matériaux des di�érentes routes ou encore quiindique seulement les chemins pédestres n'est d'aucune utilité pour un automobiliste.


Méta-modèle : langage de modélisation. A�n de rendre un modèle utilisable, ilest nécessaire de préciser et de spéci�er le langage dans lequel le modèle est exprimé. Celangage de modélisation est appelé le méta-modèle. Le méta-modèle dé�nit ce qu'il estpossible de modéliser et la relation entre les concepts manipulés dans le modèle. Il déter-mine la terminologie à utiliser pour dé�nir des modèles. Dans le cas d'une carte routière,le méta-modèle utilisé est donné par la légende qui précise, entre autres, l'échelle de lacarte et la signi�cation des di�érents symboles utilisés. De manière pratique, un modèlen'a aucun sens sans son méta-modèle.

Méta-méta-modèle : langage de méta-modélisation. De la même manière qu'ilest nécessaire d'avoir un méta-modèle pour savoir comment interpréter un modèle, pourpouvoir interpréter un méta-modèle il est nécessaire de disposer d'un langage dans lequelle méta-modèle est exprimé (un méta-modèle pour les méta-modèles). Ce dernier estappelé le méta-méta-modèle. Il représente la vue la plus abstraite et correspond à lacouche d'abstraction la plus haute. A�n d'éviter une in�nité de niveaux d'abstraction,le méta-méta-modèle est, en e�et, auto-descriptif, c'est-à-dire qu'il se dé�nit lui-même.Le méta-méta-modèle permet de spéci�er les éléments qui composent un méta-modèleet la manière de les manipuler. Il existe di�érents langages disponibles pour l'écriture deméta-modèles comme le MOF (Meta-Object Facility), ECore, Kermeta ou KM3 (KernelMeta Meta Model). Le choix du méta-méta-modèle est déterminant, car il est la base detoute la chaîne de modélisation et dé�nit les concepts sous-jacents à la représentationde tous les autres niveaux d'abstraction.

Langage de méta-modélisation

Langage de modélisation

Méta-méta-modèle

Méta-modèle

Modèle

M3

M2

M1 χ est conforme àε est exprimé dansµ représente

χ

χ

χ

ε

ε

µ, ε

µ

Fig. 2.1 � Niveaux de modélisation

La �gure 2.1, extraite de la thèse de Fleurey [Fle06], résume les di�érents niveauxde modélisation (M1 : modèle, M2 : méta-modèle et M3 : méta-méta-modèle), ainsi que

Approches existantes 19

les relations qui existent entre les di�érents concepts. Par exemple, elle montre qu'unmodèle est exprimé dans un langage de modélisation et est conforme au modèle quireprésente ce langage.

2.2 Approches existantes

L'Ingénierie Dirigée par les Modèles est une démarche générique qui regroupe plu-sieurs mises en ÷uvre partageant une vision similaire de ce que doit être le dévelop-pement logiciel. L'IDM peut être vue comme une famille d'approches dont le principefondateur est l'utilisation des modèles comme base pour le processus de développement.Pour chacune de ces approches de développement, l'utilisation de modèles nécessite ladé�nition de langages de modélisation et de transformations de modèles.

Il existe plusieurs implémentations de l'Ingénierie Dirigée par les Modèles telles quel'Architecture Dirigée par les Modèles (Model-Driven Architecture ou MDA) [Obj03],le MIC (Model Integrated Computing) [Kar00], ou encore les usines à logiciel (SoftwareFactories) [GSCK04]. Cette section propose un aperçu des deux grandes familles de mo-délisation, symbolisées par l'approche MDA et les approches de modélisation spéci�quesà un domaine d'application.

2.2.1 Architecture dirigée par les modèles

L'Architecture Dirigée par les Modèles est une démarche logicielle proposée parl'organisme de standardisation OMG dans les années 2000. Cette vision de l'IngénierieDirigée par les Modèles est développée autour de la notion de plate-forme d'exécutionet l'utilisation de standards éprouvés. Forte de son expérience dans les intergiciels etdans la modélisation, l'OMG propose à travers l'architecture MDA une norme de méta-modélisation des architectures logicielles à base de composants. Une description plusdétaillée des enjeux et des principes de l'approche MDA est disponible dans la thèse deLopes [Lop05].

Principe. L'idée initiale de l'OMG consistait à s'appuyer sur des standards commeUML pour décrire séparément les parties des systèmes indépendantes des plates-formesd'exécution (Platform Independant Models ou PIM3) et les parties liées aux plates-formes (Platform Speci�c Models ou PSM3). Il s'agit donc de construire des modèles(PIM) de systèmes de façon à prendre en compte tous les besoins fonctionnels, maisà demeurer complètement indépendants de toutes plates-formes, langages de program-mation ou autres aspects liés à l'implémentation. A�n de cibler des environnementsd'exécution spéci�ques, il su�t de concevoir plusieurs modèles spéci�ques aux plates-formes (PSM) qui décrivent la manière dont les modèles de base sont implémentés surchaque plate-forme. L'approche MDA préconise également de traduire un modèle indé-pendant (PIM) en un modèle spéci�que (PSM) à l'aide d'outils automatisés, facilitant

3Dans ce document, nous utiliserons de manière indi�érente le terme Platform Independant Models

et PIM. De la même manière, nous utiliserons indi�éremment le terme Platform Speci�c Models etPSM.


la tâche de support de nouvelles technologies, et permettant l'implémentation concrètede système. Il est également possible de transformer un PSM en un autre PSM, cequi permet de cibler une autre plate-forme. Ces outils sont principalement des outilsde transformation de modèles parmi lesquels nous pouvons citer : ATL (Atlas Trans-formation Language) [JK06a, JK06b], BOTL (Basic Object-oriented TransformationLanguage) [MB03], QVT Merge [GBA+05] ou encore VIATRA (VIsual Automated mo-del TRAnsformations) [CHM+02]. Ces langages sont basés sur di�érents paradigmes etsont plus ou moins adaptés à un contexte d'utilisation particulier [MCG05]. La �gure2.2 résume sous une vue schématique la démarche de modélisation MDA présentée danscette section.

PIM

PSM

Code

PSMPSM

CodeCode

transformation

génération de code

transformation

Fig. 2.2 � Architecture dirigée par les modèles (MDA)

Perspective. Dé�nir de manière exacte la philosophie de l'approche MDA n'est paschose facile, car cette dernière est en constante évolution [BCT05]. Initialement, l'ap-proche MDA vise à manipuler di�érents modèles d'un système à des niveaux d'abstrac-tion variables, qui ultimement sont traduits dans des technologies d'implémentationvariées (grâce à des transformations de modèles bien-dé�nies). Mais aujourd'hui, l'Ar-chitecture Dirigée par les Modèles se veut davantage être un cadre uni�cateur pournormaliser un certain nombre de technologies, s'appuyant sur les standards OMG. Latransformation entre les modèles indépendants des plates-formes (PIM) et les modèlesspéci�ques aux plates-formes (PSM) est alors perçue comme une application de l'ap-proche MDA, au même titre que les transformations PIM-PIM ou encore PSM-PSM.Après avoir longtemps promulgué une approche autour de la notion d'indépendance deplate-forme, l'OMG semble vouloir se tourner vers de nouveaux enjeux. Sans toutefoischanger ses objectifs initiaux, l'approche MDA se veut aujourd'hui plus générale, in-sistant davantage sur le besoin de standards de modélisation. L'enjeu principal de laphilosophie MDA est d'assurer l'intégrité, l'interopérabilité et la portabilité des sys-tèmes tout en facilitant les migrations technologiques tout au long du cycle de vie d'un


système (conception, assemblage, intégration, évolution, etc.).

La modélisation par la standardisation. Pour mettre en ÷uvre l'approche MDA,l'OMG insiste sur l'importance de manipuler des standards de modélisation, qui consti-tuent les briques de base de l'architecture MDA. L'architecture repose donc sur unensemble de recommandations non-propriétaires visant à spéci�er des technologies inter-opérables a�n de réaliser le développement dirigé par les modèles à l'aide de transforma-tions automatisées. Le standard MOF (Meta Object Facility) est le standard central del'architecture MDA et représente le socle de l'architecture. C'est un langage de méta-modélisation qui permet de dé�nir d'autres langages comme UML (Uni�ed ModelingLanguage). Le standard UML est le standard favori pour l'élaboration de modèles indé-pendants de plates-formes (PIM). Dans le MDA, le standard UML est considéré commeun méta-modèle qui décrit la structure de modèles spéci�ant des systèmes informa-tiques. Il faut également noter que la notion de pro�ls UML permet l'élaboration demodèles spéci�ques aux plates-formes (PSM). D'autres standards sont mis en avant parl'approche MDA, comme le standard d'échange de méta-données XMI (XML MetadataInterchange), le langage de contraintes OCL (Object Constraint Language) ou encorele standard d'entrepôt de méta-données CWM (Common Warehouse Metamodel). Tousces standards constituent désormais le c÷ur de l'architecture. En ce qui concerne lanotion de transformation de modèles, le standard QVT (Query View Transformation)est le standard de référence. Ce standard est stratégique pour le MDA car il dé�nit lelangage de transformation de modèles. C'est donc grâce à lui que sont spéci�ées, entreautres, les transformations PIM vers PSM, PSM vers PSM ou encore PSM vers code.

En résumé, l'approche MDA peut être dé�nie comme une démarche de développe-ment générique reposant à la fois sur les modèles et sur un ensemble de standards del'OMG. Cette démarche permet de séparer les spéci�cations fonctionnelles d'un sys-tème (PIM) des spéci�cations de son implémentation (PSM). Les standards tels queMOF, UML ou encore CWM jouent un rôle fondamental car ils sont les gardiens del'interopérabilité et l'intégrité des systèmes. De plus, ces standards facilitent la mise en÷uvre de ponts technologiques (transformations de modèles), ainsi que la réutilisationde composants au sein de l'architecture.

2.2.2 Modélisation spéci�que à un domaine

Contrairement à l'approche MDA basée sur des standards de modélisation généra-listes, la modélisation spéci�que à un domaine (Domain-Speci�c Modeling ou DSM4)[Coo04] met en avant une méthodologie de développement centrée sur la notion de do-maine et visant à améliorer la productivité. Comme son nom le suggère, la modélisationspéci�que à un domaine permet de réduire l'espace de conception, souvent à une simplegamme de produits pour une seule organisation, a�n d'augmenter le plus possible leniveau d'abstraction des modèles et de pouvoir générer totalement une implémenta-

4Dans ce document, nous utiliserons de manière indi�érente le terme Domain-Speci�c Modeling etDSM.


tion sur-mesure pour une organisation. Cette adaptation aux besoins de l'organisationentraîne un gain en productivité.

Principe. Le concept central de la modélisation DSM réside dans la notion de lan-gage de modélisation spéci�que à un domaine (Domain-Speci�c Modeling Language ouDSML5). L'approche consiste à rassembler la connaissance du domaine d'applicationdans un langage de modélisation dédié et, à partir de modèles écrits dans ce langage, degénérer le code d'une application de manière complète sans intervention humaine. Dufait de sa portée restreinte, il est beaucoup plus facile de dé�nir un langage de modéli-sation spéci�que qu'un langage généraliste comme UML. De plus, sa forte spécialisationdans le domaine permet de totalement dé�nir une application avec un e�ort de modéli-sation relativement faible. En�n, comme il couvre le domaine cible dans son intégralité,un DSML est adapté pour permettre une génération automatique mais surtout com-plète du code, ou de toute documentation. La �gure 2.3 montre une vue schématiquedu principe de modélisation spéci�que à un domaine. La mise en ÷uvre de l'approcheDSM s'appuie sur un environnement complet qui comprend principalement trois com-posants : un langage de modélisation spéci�que à un domaine (DSML), un générateurde code dédié et un environnement d'exécution (framework) ciblé par le générateur.Le but du générateur de code et du framework est de combler le fossé entre les mo-dèles écrits avec un haut niveau d'abstraction et la plate-forme d'exécution bas niveaupour laquelle l'application est dédiée. La question importante se situe au niveau de ladistinction des tâches entre chacune des parties (modèles, générateur et framework).En général, les modèles ne capturent que la logique du comportement de l'applicationalors que le framework fournit un ensemble de services prédé�nis qui sert d'interface augénérateur de code.

DSML

Générateur de Code Dédié

Code

Générateurde Code Dédié

Générateurde Code Dédié

Code Code

Framework Framework Framework

Fig. 2.3 � Modélisation spéci�que à un domaine (DSM)

5Dans ce document, nous utiliserons de manière indi�érente le terme Domain-Speci�c Modeling

Language et DSML.


Perspective. La philosophie DSM concernant la modélisation et la génération de codedepuis les modèles est complètement di�érente de celle de l'approche MDA. En e�et,l'intérêt des langages de modélisation ne se situe plus au niveau d'une modélisationgénéraliste, mais au niveau de la résolution de problèmes simples et restreints. Chaquedomaine de problèmes est di�érent, d'une organisation à une autre, d'un produit à unautre, ou d'un système à un autre. En traduisant les concepts et les règles d'un domainede problèmes directement dans un langage de modélisation spéci�que à un domaine, ildevient possible d'élever le niveau de spéci�cation de la solution bien au delà du codeet de fournir une infrastructure adaptée aux besoins de l'organisation et des utilisa-teurs. L'approche toute entière devient alors spéci�que, ce qui permet une générationcomplète de l'application, d'où une production plus e�cace et une réduction des cyclesde développement. Le problème n'est plus ici de porter un modèle indépendant surdes plates-formes d'exécution di�érentes, mais d'automatiser la création de code sourceexécutable directement depuis les modèles DSM. De ce point de vue, l'approche de mo-délisation spéci�que à un domaine ne fait que reprendre l'idée fondamentale qui a faitle succès des compilateurs : lors de la génération de code, le processus doit être complet.Un autre point important de la philosophie DSM doit être noté, qui la di�érencie despremiers essais de génération de code des outils CASE (Computer-Aided Software Engi-neering) [Iiv96] des années 1980 : a�n d'adapter exactement le langage de modélisationet le générateur de code aux besoins de l'organisation, il est indispensable que l'ap-proche soit mise en ÷uvre par l'organisation elle-même. Ce faisant, le temps nécessaireaux développeurs pour apprendre le langage de modélisation est réduit, du fait qu'ilschoisissent eux-mêmes les termes et les concepts du langage. De plus, il devient plusfacile pour le langage de modélisation d'évoluer en réponse aux changements dans ledomaine. La démarche DSM se veut plus modeste que les approches existantes de l'IDM(du type MDA), en spécialisant le processus à un domaine. Ceci rend la modélisationplus réalisable et concrète, entraînant de meilleurs résultats en termes de productivité[Kel04]. A�n de mener à bien cette démarche, l'approche implique donc de disposerd'outils ou d'environnements de modélisation simples et puissants, qui permettent deconcevoir ces langages de modélisation DSML, de fournir un support de programmationet de faciliter la génération de code.

Outils de méta-modélisation. Les outils d'implémentation DSM permettent auxutilisateurs de construire des environnements de génération de code basés sur des mo-dèles spéci�ques à un domaine. Ainsi, ils permettent de dé�nir explicitement un méta-modèle, et donc un DSML, et au même niveau de programmer tous les outils spéci�quesnécessaires, allant des éditeurs graphiques aux générateurs de code, en passant par destransformateurs de modèles. De plus, a�n de guider et restreindre le développementde solutions au sein du domaine, ils autorisent la mise en place de règles. Ces règlescontraignent l'utilisation du langage de modélisation en dé�nissant les relations autori-sées entre les di�érents concepts et la manière de les manipuler. Elles permettent ainsi deréduire l'espace de conception de solutions et assurent que les applications conçues sontcorrectes vis-à-vis du domaine. Ces outils d'implémentation DSM di�èrent principale-ment par le langage de méta-modélisation qu'ils manipulent et qui est la base de tout


l'environnement (e.g., ECore, MOF ou encore KM3). Parmi ces outils, certains sont desenvironnements commerciaux comme l'outil MetaEdit+ de Metacase [SLTM91], l'en-vironnement XMF-Mosaic de Xactium [CESW04], ou encore l'environnement des DSLTools de Microsoft [GSCK04]. D'autres sont soit des frameworks comme le Frameworkde Modélisation d'Eclipse (EMF) associé au Framework de Modélisation Graphique(GMF), soit des outils de recherche comme l'Environnement de Modélisation Générique(GME) basé sur les idées du MIC [LBM+01]. L'objectif premier de l'approche DSM estainsi d'améliorer la productivité des organisations en leur fournissant des outils et desméthodes de modélisation spéci�ques à leurs domaines.

2.3 Limitations des approches

Bien qu'aujourd'hui les sujets autour de l'Ingénierie Dirigée par les Modèles sus-citent beaucoup d'intérêt, les possibilités o�ertes par cette nouvelle branche du génielogiciel sont encore méconnues, et beaucoup de questions restent ouvertes. De plus, entant que technologie émergente, les approches soutenant l'IDM ne sont pas encore ma-tures. Ainsi, comme le montre Schmidt [Sch06], il est di�cile de trouver des solutionstechniques solides des technologies IDM, des applications industrielles de ces techno-logies, ou encore des béné�ces avérés de cette démarche. En e�et, l'approche semblesoulever certaines interrogations, notamment celles relatives à la synchronisation entreles modèles et le code généré (ou d'autres représentations des modèles), au débogage dela modélisation, à la compatibilité des outils IDM ou encore à la certi�cation de pro-priétés de sûreté des modèles écrits dans les DSML. Pour aggraver la situation, l'IDMtout entier fait aujourd'hui face à un autre type de problème, celui d'une lutte interneentre les di�érentes mouvances a�n de savoir quelle déclinaison est la plus à même de re-présenter l'IDM : aux pro-UML généralistes s'opposent les pro-DSML spéci�ques. Danscette section, nous traitons donc des limites et des problèmes de l'approche de l'Ingé-nierie Dirigée par les Modèles, en se concentrant sur chacune des approches présentéesprécédemment.

2.3.1 Architecture dirigée par les modèles

À la lecture du guide proposé par l'OMG [Obj03], il apparaît évident que l'ap-proche MDA se veut généraliste, s'appuyant sur des dé�nitions (plate-forme, modèle,transformation), des standards et des outils eux aussi généralistes. Or, l'ensemble del'approche est fondé sur le concept de plate-forme et sur la séparation des spéci�cationsfonctionnelles d'un système (PIM) et des spéci�cations de son implémentation (PSM).La généricité de cette démarche entraîne une ambiguïté de la dé�nition des concepts del'architecture qui complexi�e sa mise en ÷uvre.

Une architecture ambiguë. Si les buts de l'approche MDA sont relativement clairsaujourd'hui et continuent à s'a�ner de jour en jour, il n'en est pas de même pour samise en ÷uvre. La technologie pour l'implémenter est, en e�et, très vaguement spéci�ée,et les limites du cadre de la démarche ne sont pas clairement identi�ées. En forçant le

Limitations des approches 25

trait, n'importe quel outil de modélisation avec des fonctionnalités de génération decode peut prétendre implémenter l'approche MDA. De la même manière, l'architecturetoute entière s'appuie sur la notion de plate-forme, mais à la lecture de la littérature,il demeure peu évident de savoir ce qui constitue exactement une plate-forme. Ainsi,selon la propre dé�nition de l'OMG [Obj03], la notion de plate-forme �est sujette aubut de la personne qui modélise, et si les utilisateurs considèrent qu'un middleware estune plate-forme, les développeurs considèrent eux que les systèmes d'exploitation sontdes plates-formes�. La notion de modèle n'est pas plus explicite, puisque l'organisme ladé�nit comme suit :

�...une description ou une spéci�cation d'un système et ses environne-ments en ce qui concerne certains buts. Un modèle est souvent représentécomme une combinaison de dessins et de texte. Le texte devrait être dans unlangage de modélisation ou en langage naturel.�

Tout cela rend la mise en ÷uvre de l'approche MDA très �oue et très ambiguë. Deplus, comme le suggèrent Muller et al. dans [MBS04], il n'est pas toujours simple, ausein d'une architecture donnée, de bien di�érencier le caractère indépendant (PIM) d'unsystème de ses caractères spéci�ques (PSM), car cela dépend souvent du point de vuede l'utilisateur. Or, cette séparation apparaît comme un concept clé de la démarche.Là encore, la dé�nition ne nous renseigne pas plus et vient con�rmer les conclusions deMuller et al., reconnaissant que �comme beaucoup de points, l'indépendance de la plate-forme est une a�aire de degré�. Par ailleurs, aucune fondation n'était jusqu'ici dé�niepour transformer des modèles indépendants de plates-formes en modèles spéci�quesaux plates-formes [GLR+02]. Et si la recommandation QVT [JK06a] semble proposerun cadre normatif à la transformation de modèles, très peu d'outils implémentent réel-lement ce standard. A�n de cacher l'ambiguïté résultant de tout ceci, les concepteurs delangages de modélisation généralistes mettent en avant le caractère haut niveau de leursabstractions, suggérant ainsi que ces dernières n'ont pas besoin d'être non-ambiguës,complètes, ou encore signi�catives. Cependant, par dé�nition, une abstraction permetde cacher les détails inutiles pour l'utilisateur, mais ne les supprime en aucun cas. Ene�et, ces derniers doivent encore être présents, a�n d'éviter toute ambiguïté due à unesémantique incomplète notamment dans le cadre d'une génération automatique de codeou d'une transformation. La perte d'informations pourrait entraîner par exemple uneimpossibilité de véri�cation de propriétés, ou tout simplement interdire toute exécution.

Le piège de la généricité. Si les modèles permettent aux experts du domaine derésoudre plus facilement les problèmes, il est primordial que le langage de modélisa-tion représente clairement le domaine de problèmes. L'approche MDA privilégie unlangage de modélisation généraliste (UML) et utilise ce langage dans tous les domainesen formant les experts du domaine à l'utilisation de ce langage généraliste. Un standardcomme UML ne peut être utilisé comme une technique e�cace de développement dirigépar les modèles ou comme un langage exécutable. Il lui manque, en e�et, la spécia-lisation et la dé�nition sémantique nécessaires à la génération d'une implémentation[CESW04]. Pour pallier ce manque, la version 2.0 d'UML [FGDS06] inclut une facilité


de méta-modélisation puissante (Meta-Object Facility ou MOF), qui permet d'étendreUML de manière quasiment arbitraire. Ainsi, UML inclut un mécanisme de pro�l qui luipermet d'être contraint et spécialisé pour des domaines et des plates-formes spéci�ques[CESW04]. L'exemple le plus connu de spécialisation d'UML à un domaine particulierest SysML [Sys05], un langage de modélisation pour l'ingénierie des systèmes. Mal-heureusement, certaines constructions dans UML 2.0 restent encore sans sémantique[HT06, HR04]. Ce manque de dé�nition sémantique empêche l'usage précis des exten-sions UML, réduit leur pouvoir expressif et empêche d'assurer une certaine conformitéau niveau des outils. Comme Thomas le note [Tho04], UML 2.0 manque à la fois d'uneimplémentation de référence et d'une explication sémantique compréhensible par unhumain a�n de fournir une sémantique opérationnelle. Il est donc di�cile d'interpréteret d'implémenter correctement des outils de transformation de modèles UML. De plus,de par son manque de spéci�cation, les modèles écrits dans un tel langage informel sontouverts à des interprétations erronées. Le dernier problème réside dans la complexitéinhérente à UML et à l'utilisation de pro�ls. Si UML présente incontestablement denombreux avantages, notamment en termes de conception et de communication, la plu-part du temps, il ne permet pas de représenter les besoins réels des modèles [FS00].Par ailleurs, la génération de code se limite dans la plupart des cas à la générationd'artéfacts, mais en aucun cas à une génération complète, à cause de son imprécision etsa généricité.

2.3.2 Modélisation spéci�que à un domaine

Selon Green�eld et Short [GSCK04], la généricité excessive et la construction mo-nolithique de générateurs de code font parties des freins majeurs au développementlogiciel. Si le problème de la généricité est bien illustré par la démarche MDA, celui dela construction monolithique résume quant à lui parfaitement les limites liées à l'ap-proche de modélisation spéci�que. En e�et, l'un des problèmes de la modélisation DSMse situe au niveau de la faiblesse des générateurs de code, symbolisée notamment parl'échec des outils de type CASE. Plus le langage de modélisation est haut niveau et plusles besoins de génération de code sont importants. En conséquence, cela peut rapidementintroduire une grande complexité au niveau du générateur, le rendant di�cile à main-tenir ou à faire évoluer. De la même manière, un point important de toute l'approcheréside dans la séparation des tâches entre les modèles, le générateur et le framework.Une mauvaise séparation peut là encore avoir des impacts sur la complexité du généra-teur, une impossibilité d'évolution ou un framework trop restrictif car trop haut niveau.Un autre frein majeur de l'approche se situe autour de la spéci�cité de la démarche, etde la plate-forme d'exécution. Si cette approche facilite le développement, cela restreintégalement la solution à cet environnement et introduit de fortes dépendances avec laplate-forme au niveau du générateur de code. Ceci empêche donc toute réutilisabilitéet implique la création d'un nouveau générateur (voire framework) pour chaque nouvelenvironnement. Comme dans le cas d'UML, un problème subsiste également au niveausémantique. En e�et, il est important que la sémantique du langage de modélisation,et donc du modèle, ne soit pas seulement dé�nie au travers du générateur. Le manque

Évolution récente de l'IDM 27

de sémantique rend la production d'outils DSM automatisés di�cile. Pour tenter derépondre à ce problème, les environnements d'implémentation DSM fournissent souventun langage de règles pour limiter la sémantique du domaine. Néanmoins, sa mise en÷uvre reste complexe et son impact limité à l'expressivité du langage de règles. En-�n, le développement du langage et du générateur par l'organisation elle-même peutprêter à discussion et devenir un obstacle. Malgré l'aide d'outils de modélisation, cetteapproche nécessite tout de même de la part des développeurs une certaine expertise,méthodologie et tournure d'esprit.

2.4 Évolution récente de l'IDM

Face aux limitations des solutions actuelles de l'Ingénierie Dirigée par les Modèles,une nouvelle tendance semble émerger. Dans le principe, l'architecture proposée par ladémarche MDA est une idée prometteuse. Cependant, sa réalisation au travers d'UMLreste discutable, en utilisant un langage généraliste pour modéliser le domaine. Ainsi,il semble que la communauté MDA envisage progressivement de délaisser UML et sesextensions complexes au pro�t d'approches s'appuyant sur des langages plus spéci�queset sur des techniques issues de la communauté des langages. Une distinction forte, maisnon clairement démontrée, est traditionnellement introduite entre les langages de pro-grammation et les langages de modélisation. Le niveau sémantique est l'une des raisonsles plus souvent avancées. En e�et, les langages de modélisation sont habituellementconsidérés comme possédant une sémantique informelle et abstraite, alors que les lan-gages de programmation sont dits plus concrets du fait de leur besoin d'être exécutables.Or, l'idée novatrice de l'Ingénierie Dirigée par les Modèles est de rendre les modèles pro-ductifs, c'est-à-dire capable de générer du code, et donc d'avoir des modèles exécutables.Ce besoin d'exécutabilité était jusque-là complètement absent lors de l'utilisation de lamodélisation d'un point de vue contemplatif. Néanmoins, il pose désormais un problèmefondamental, celui du besoin d'une sémantique précise pour les modèles, et donc pourle langage de modélisation, a�n de pouvoir produire du code exécutable. Cette problé-matique n'est pas nouvelle et est depuis longtemps adressée par la communauté deslangages de programmation. Ainsi, il existe di�érents langages généralistes de spéci�ca-tion exécutable, comme le langage de la méthode B [Abr96], qui pourraient être utilisésà la place d'UML. Ces langages permettent d'établir une chaîne de production qui vade la spéci�cation du programme au code source associé. Mais tout n'est pas pour au-tant résolu, car se pose alors le problème de la généricité. En e�et, pour être e�cace,l'approche nécessite d'être spécialisée à un domaine.

Si nous regardons le problème de plus près, le principe même de la modélisation estd'utiliser les modèles a�n de capturer de manière précise l'intention du développeur etde complètement ou partiellement automatiser son implémentation. Pour cela, il su�tde disposer d'un langage de modélisation qui élève réellement le niveau d'abstraction,mais aussi qui permette aux experts du domaine de manipuler des concepts familiers. Deplus, ce langage doit posséder un certain nombre de règles syntaxiques bien établies (dit"grammaire du langage"), spéci�ant les combinaisons possibles des di�érents concepts et


termes. La signi�cation de toutes les expressions doit également être clairement dé�nie.Ainsi, toute ambiguïté concernant la compréhension du modèle est levée, et il devientbeaucoup plus facile de générer une implémentation valide. La problématique touteentière mais aussi les di�érents critères d'un bon langage de modélisation sont trèsproches de la notion de langage dédié, du fait que ce dernier modélise les concepts d'undomaine spéci�que, mais possède également une sémantique précise qui lui permet d'êtreexécutable. D'autre part, l'approche Ingénierie Dirigée par les Modèles peut égalements'avérer un bon soutien pour les langages dédiés. Elle peut être perçue comme un nouveloutil conceptuel et opérationnel pour leur dé�nition. Elle peut également servir à fournirune implémentation dans certains cas, par exemple sous la forme d'un ensemble d'outilsde conversion entre langages.

2.5 Bilan

L'originalité de l'Ingénierie Dirigée par les Modèles ne se situe pas dans l'utilisationsystématique de modèles, mais davantage dans la préoccupation de rendre les modèlesproductifs plutôt que contemplatifs. La section 2.1 introduit l'idée fondatrice du dévelop-pement dirigé par les modèles consistant à élever le niveau d'abstraction tout en cachanttoute la complexité des technologies, des procédés de développement, etc. Comme danstoutes les branches de la science et de l'ingénierie, deux approches de ce problème sedistinguent, l'approche généraliste et l'approche spéci�que, présentées dans la section2.2. D'un côté, l'approche MDA propose une architecture générique basée sur l'inter-opérabilité et la réutilisation de composants, ainsi que sur l'utilisation de standards demodélisation généralistes. De l'autre côté, la modélisation spéci�que à un domaine meten avant une méthodologie de développement centrée autour de la notion de domaineet visant à améliorer la productivité.

Même s'il existe un certain nombre de travaux concernant l'ingénierie des modèles,sa mise en ÷uvre n'en est qu'à ses débuts et de nombreuses interrogations subsistent.La section 2.3 fait état de quelques-uns de ces problèmes, notamment relatifs à l'inadé-quation des solutions face aux besoins des utilisateurs et du manque d'outils spéci�ques.Si le développement dirigé par les modèles séduit de plus en plus, son coût est souventjugé trop lourd et son manque de maturité retarde son adoption par les organisations.Néanmoins, comme le montre la section 2.4, une idée semble émerger et mettre d'ac-cord industriels et académiques sur l'utilisation des langages dédiés dans le processusde modélisation.

Chapitre 3

Langages dédiés

Au cours des dernières décennies, l'ingénierie logicielle n'a eu de cesse d'augmenter laproductivité des développements logiciels. Le saut le plus important reste sans nul doutele passage des langages assembleur aux langages de programmation de troisième généra-tion (comme le BASIC par exemple). Cependant, depuis les années 60-70, aucun langagede programmation généraliste, ni même aucune nouvelle technologie, architecture ou fra-mework, ne semble avoir d'impact aussi important sur la productivité des organisations[Jon06, DSM06]. Comment un tel saut a-t-il donc pu être possible ? L'élévation du ni-veau d'abstraction, ainsi que l'automatisation de la génération d'instructions, sont lesprincipales causes de cette augmentation de la productivité. Aujourd'hui, les langagesdédiés sont un moyen reconnu pour o�rir de tels avantages. En e�et, en se concentrantsur un problème particulier, ils permettent d'augmenter le niveau d'abstraction touten réduisant l'espace de conception. De par l'utilisation de méthodes spéci�ques et deconcepts usuels du domaine, il devient plus facile et plus sûr de modéliser des solutionsaux problèmes.

Ce chapitre présente une introduction aux langages dédiés, ainsi qu'un aperçu desprincipaux avantages o�erts par leur utilisation, vis-à-vis d'une approche traditionnellede développement logiciel. Nous décrivons ensuite les di�érentes étapes concernant laconception d'un langage dédié. En�n, nous présentons les limites actuelles de cettetechnologie, qui représentent parfois un frein à son acceptation dans un cadre industriel.

3.1 Introduction

Un langage dédié (Domain-Speci�c Language ou DSL1) est un langage de program-mation restreint à un domaine particulier. Contrairement aux langages de modélisation(section 2.4), un DSL possède par nature une sémantique, qu'elle soit opérationnelle,dénotationnelle, donnée par un interprète, ou encore sous une forme mathématique[Sch86]. En e�et, du point de vue de l'exécutabilité du langage, il est primordial debien distinguer la notation (syntaxe) et le sens (sémantique), qui font tous les deux

1Dans ce document, nous utiliserons de manière indi�érente le terme langage dédié et DSL.

29

30 Langages dédiés

partie intégrante de la dé�nition du langage. Ce point constitue la di�érence fonda-mentale avec les langages de modélisation proposés par les approches IDM. Dans leurdésir de passer d'une approche contemplative à une approche productive, les approchesde modélisation ont négligé la sémantique de leurs modèles. Un méta-modèle captureles concepts, les notations ou encore les relations entre les concepts d'un langage, maispas sa sémantique [HR04]. Or, une sémantique explicite est un pré-requis indispensablepour la mise en ÷uvre d'un langage (par transformations ou autres moyens). Cette miseen ÷uvre concerne la compilation mais également la véri�cation de propriétés.

Un langage dédié est un langage qui fournit des constructions et des notations adap-tées à la sémantique d'un domaine, ce qui permet aux experts de penser les solutionsdans des termes métiers et non informatiques. Ainsi, les concepts manipulés par lelangage correspondent directement aux connaissances et aux concepts des experts dudomaine. À travers l'utilisation d'abstractions spéci�ques, un langage dédié permet deconcevoir une solution plus lisible et plus concise qu'avec un langage généraliste. De plus,l'expressivité restreinte du langage, ainsi que l'absence de détails d'implémentation, per-mettent de guider la programmation, rendant le processus de développement plus sûr.Tout ceci permet d'augmenter considérablement la productivité des utilisateurs.

Les langages dédiés à une tâche particulière ne correspondent pas à un concept récentet leur utilisation est certainement aussi ancienne que la notion de langage de program-mation. Ainsi, le langage APT (Automatic Programmed Tool) [Ros78], développé auMIT en 1955 pour faciliter la production de rubans perforés servant à faire fonctionnerdes machines-outils, peut être considéré comme l'un des premiers DSL. De même, le for-malisme de description de spéci�cation syntaxique BNF (Backus Naur Form) [Bac59]date quant à lui de 1959. Toutefois, leur démocratisation n'est apparue que dans lemilieu des années 90. Parmi les DSL les plus répandus aujourd'hui, nous pouvons citerle langage de formules d'Excel pour les feuilles de calcul, SQL pour les requêtes debase de données, LATEX pour la mise en forme de documents ou encore Make pourla compilation d'applications. Ces langages proposent des abstractions spéci�ques ainsiqu'une expressivité focalisée sur leur domaine d'application.

Les langages dédiés sont utilisés dans de nombreux domaines très di�érents, sansse limiter au domaine de l'Informatique. Selon le domaine, un DSL peut ou non in-clure des concepts de programmation. Ainsi, ils peuvent être plus ou moins centrés surl'utilisateur �nal, ne nécessitant parfois que des compétences du domaine, sans aucuneexpertise en programmation. Parmi les domaines ayant donnés naissance à de tels DSL,nous pouvons citer le graphisme [KH97, Ell99], les produits �nanciers [ADR95], la chimiemoléculaire [MR97], les systèmes de commutation téléphonique [LR94, GJKW97], lesprotocoles [CL97, TMC98], les systèmes d'exploitation [PBC+97], les pilotes de périphé-riques [Rév01], ou encore les langages de robotique [Bja96]. Cette diversité témoigne desbesoins des DSL vis-à-vis de langages généralistes (General Purpose Languages ou GPL),mettant en évidence des béné�ces comme la productivité, la �abilité, ou encore la �exibi-lité [KMB+96]. Néanmoins, en contre partie, elle rend di�cile une caractérisation précisedes DSL. Plusieurs dé�nitions sont ainsi proposées [Con04, Ben86, DKV00, MHS05].La notion d'exécutabilité d'un langage dédié est, par exemple, une des di�érences no-tables entre ces dé�nitions et reste encore aujourd'hui un point de discussion. En e�et,

Motivations 31

l'importance de la non-exécutabilité du DSL est soulignée par Wile [Wil01], alors quevan Deursen et al. présupposent qu'un langage spéci�que à un domaine est exécutablepour être considéré comme un langage dédié [DKV00]. Tout ceci fait qu'il existe di�é-rentes perceptions de ce que doit représenter un langage dédié [MHS05]. C'est l'une desraisons pour laquelle la littérature fait état d'appellations très di�érentes pour nommerles DSL. Ainsi, les langages dédiés sont également appelés "langages métier", "lan-gages orientés application" [Sam69], "langages à but particulier" [Wex81], "langagesspécialisés" [BG96], "langages spéci�ques à une tâche" [Nar93], "langages orientés pro-blème" [CE00], "mini(micro ou petits)-langages" [Ben86], "langages pour utilisateur�nal" [BCP01], ou encore "langages d'application" [Mar85]. Dans le contexte des lan-gages dédiés à des applications de bases de données, ils peuvent également être appeléslangages de quatrième génération (4GLs) [Mar85].

Dans la suite de ce document, nous adoptons la dé�nition de Consel [Con04] etconsidérons un DSL comme un langage de programmation exécutable dédié à un do-maine particulier ou à un problème particulier. Il permet aux utilisateurs de ré�échir,concevoir et implémenter les solutions dans les termes du domaine.

3.2 Motivations

Contrairement aux langages généralistes qui permettent d'adresser une large classede problèmes, les langages dédiés se focalisent sur un domaine précis, et donc sur unensemble �ni de problèmes. Ce contexte d'étude particulier permet de spécialiser le pro-cessus de développement et donc d'introduire des analyses, des véri�cations, ou encoredes optimisations spéci�ques au domaine. En amenant la programmation plus près dudomaine de problèmes, les DSL permettent de réutiliser de manière systématique unegrande partie de la connaissance et d'améliorer la sûreté des applications.

3.2.1 Programmation du domaine de problèmes

Les langages dédiés sont des langages conçus sur mesure pour répondre aux besoinsspéci�ques d'un domaine particulier. Ils facilitent de manière signi�cative la constructionde systèmes logiciels pour ce domaine [Ben86]. En e�et, un DSL permet d'augmenterla lisibilité et la concision des programmes ainsi que l'accessibilité du langage pour lesexperts du domaine. Son principal avantage est de rapprocher l'implémentation de laconception, c'est-à-dire de faire en sorte que l'écriture d'un programme soit la plussimple et naturelle possible pour les acteurs du domaine. La solution est plus prochede la pensée des utilisateurs qu'elle ne l'est avec un langage généraliste. Plus déclaratifqu'impératif, un DSL se concentre sur "quoi" calculer et non "comment" le calculer.Il supprime les détails d'implémentation propices aux erreurs et diminue la complexitéde la solution. La logique de l'application n'est donc plus di�use tout au long du pro-gramme comme c'est le cas avec des langages de programmation généralistes. Prenonsl'exemple de la commande Unix Make. Cet outil est un utilitaire pour maintenir desprogrammes : il détermine automatiquement les parties d'un programme qui ont besoin


d'être recompilées et les recompile si besoin [SMS06]. Le langage associé est princi-palement déclaratif, bien qu'il possède des constructions impératives, et son pouvoird'expression est limité à la dépendance de tâches. Il cache les détails d'implémenta-tion comme la date de dernière modi�cation des �chiers et fournit des abstractions dudomaine comme les su�xes des �chiers, ou la notion de règles de compilation.

En élevant la programmation au niveau du domaine, les langages dédiés donnentlieu à de meilleures analyses de programmes, facilitant la validation et l'optimisation desolutions. De plus, ils permettent aux erreurs d'être détectées plus tôt dans le processusde conception.

3.2.2 Sûreté améliorée

Rendre accessible la programmation d'un domaine à des non-programmeurs né-cessite une gestion plus �ne de la �abilité des solutions. Ces développeurs écrivent desprogrammes qui sont potentiellement plus exposés aux erreurs. L'utilisation de langagesdédiés permet le développement de programmes plus sûrs. Le niveau d'abstraction deces langages élimine un grand nombre d'erreurs courantes dans des langages de plus basniveau (e.g., gestion de la mémoire, gestion de pointeurs, gestion de processus ou encoredébordement de tampon). L'expressivité orientée métier du DSL o�re des garanties desûreté plus fortes que dans le cas de langages généralistes. Dans le meilleur des cas, cer-taines propriétés critiques du domaine sont rendues décidables grâce à des restrictionsou des enrichissements sémantiques. Ainsi, l'exécution d'un code malveillant ou incor-rect est statiquement prohibée (avant l'exécution), car seules les opérations valides sontgénérées. L'outil Make illustre parfaitement ce point concernant les propriétés renduescritiques. En e�et, il signale tous les cycles de dépendances entre les tâches et, de cefait, empêche totalement la non-terminaison. Considérons un autre exemple, le langagedédié PLAN-P [TMM99], qui permet de programmer des applications pour un réseauactif. Là encore, la conception du langage garantit par construction que tout programmePLAN-P termine et que le chemin emprunté par un paquet au sein du réseau n'est pascyclique [PB03]. Au-delà de la restriction sémantique du langage, il est également pos-sible d'utiliser des analyses de programmes traditionnelles pour augmenter la sûreté desapplications [Rév01]. Toutes ces caractéristiques des DSL rendent possible la détectionplus en amont des erreurs dans le processus de production.

L'utilisation d'un DSL facilite également la mise en ÷uvre d'optimisations, notam-ment au niveau de la compilation du DSL. Ces optimisations spéci�ques au domainepeuvent souvent s'avérer plus e�caces que celles o�ertes par des compilateurs tradition-nels. Elles ne sont rendues possibles que par l'utilisation de la connaissance du domaine.Ainsi, le compilateur Flick [EFF+97], utilisé dans le domaine de la dé�nition d'interface(IDL), permet d'optimiser la génération de stubs, avec, par exemple, une gestion e�-cace de la mémoire, ou encore en tirant pro�t d'informations particulières concernant leprotocole de transport utilisé. De plus, ces optimisations permettent de manipuler desconcepts haut niveau, mais aussi de pouvoir générer de manière sûre une implémenta-tion correcte et performante. En�n, la connaissance du domaine capturée par le DSLpeut être utilisée pour mettre en ÷uvre des outils de développement spéci�ques comme

Processus de développement 33

des éditeurs, des débogueurs, ou tout autre support.

3.2.3 Réutilisation systématique

La plupart des environnements de programmation inclut la capacité d'abstraire desopérations communes dans des bibliothèques. Cependant, la réutilisation de ces biblio-thèques est laissée à la charge et à la discrétion de l'utilisateur. À l'inverse, de par sanature, un langage dédié entraîne une réutilisation systématique, que ce soit au niveaudu code ou au niveau de l'expertise du domaine.

Le processus de conception d'abstractions consiste à identi�er des caractéristiquescommunes au niveau des solutions logicielles existantes du domaine. Ce processus a prin-cipalement deux impacts. D'une part, il permet d'associer à une abstraction un motif decode qui sera généré automatiquement. En ce sens, la conception du DSL entraîne doncune réutilisation systématique du code, voire de l'architecture dans le cadre de systèmeslogiciels complexes. D'autre part, le processus de conception d'abstractions permet auxexperts du domaine, à travers leurs expériences, de créer une collection d'abstractionsqui sert à résoudre les problèmes du domaine. De ce point de vue, le DSL conservela connaissance du domaine. Ainsi, les langages dédiés permettent la réutilisation demanière systématique de la connaissance du métier.

En réduisant la distance conceptuelle entre l'espace de problèmes et l'espace de solu-tions, un langage dédié rend la programmation plus accessible aux experts du domaine,qui peuvent concevoir des solutions sans être experts en programmation. L'élévation duniveau d'abstraction entraîne la concision des solutions, améliorant la productivité desutilisateurs. De plus, le DSL permet de réutiliser de manière systématique une grandepartie de la connaissance du domaine et d'améliorer la sûreté des applications.

3.3 Processus de développement

Le développement d'un langage dédié n'est pas une tâche facile. Il se décomposeprincipalement en deux phases : la conception et l'implémentation du DSL. La concep-tion du langage permet de délimiter le domaine d'application, notamment en dé�nissantprécisément les objectifs et la portée du langage. Un domaine trop restreint réduit ledomaine d'utilisation du langage et rend le langage inutilisable car trop spéci�que, alorsqu'un domaine trop grand accroît la complexité du langage, de son analyse et de lavéri�cation de propriétés. Une fois le domaine bien délimité, il s'agit de s'occuper del'implémentation du langage.

3.3.1 Conception

Lors de la conception d'un langage dédié, de nombreux aspects doivent être pris encompte. En e�et, il convient de concevoir un langage simple, tant dans sa sémantique (unnombre minimal de concepts et d'abstractions) que dans sa syntaxe, mais su�sammentexpressif pour pouvoir résoudre tous les problèmes du domaine ciblé. Le langage doit, en


outre, être lisible, facilement compréhensible, mais aussi �able (vis-à-vis des propriétésdu domaine à respecter).

Un concept clé est au c÷ur de la conception d'un langage dédié, le domaine. A�nde pouvoir répondre à toutes les attentes d'un DSL, il est indispensable de bien dé�nirle domaine d'application dans son intégralité. C'est le rôle de l'analyse de domaine.Cependant, elle ne permet pas à elle seule de bien caractériser le domaine, notammentparce qu'elle ne prend pas en compte les di�érences entre les entités (systèmes) quiconstituent ce domaine. Pour cela, il convient d'e�ectuer une analyse de famille deprogrammes, qui vise à identi�er les points communs et les variations des programmesdu domaine. A�n d'aider le concepteur du langage dans sa tâche, il est possible de sereposer sur des méthodologies existantes.

Analyse de domaine. Avant de ré�échir à la syntaxe d'un langage dédié à un do-maine ou encore à ses propriétés, il est indispensable de s'intéresser au problème del'identi�cation du domaine. Si cette observation semble une évidence, savoir reconnaîtrele domaine et déterminer sa portée n'est pas aussi facile qu'il y paraît. C'est pour celaque l'analyse de domaine est une composante primordiale de la conception d'un DSL.Le principe consiste à étudier et dé�nir le domaine d'application de manière précise etmodéliser ce domaine à partir de sources d'information très hétérogènes. Ces sourcesincluent, par exemple, les systèmes existants, les experts du domaine, les manuels, lesprototypes, les standards ou encore les clients potentiels. Il s'agit de collecter les infor-mations pertinentes du domaine et les intégrer avec cohérence au sein d'un modèle dudomaine. Le concept d'analyse de domaine a été dé�ni pour la première fois par Neigh-bors en 1980 [Nei80], mais a été revisité de nombreuses fois, que ce soit par McCain[McC85], Arango [Ara89], ou encore Prieto-Diaz [PD90]. Pour caractériser de manièreprécise le domaine d'application et sa portée, l'analyse doit permettre de dé�nir lecontenu et les limites du domaine, que ce soit sous la forme d'exemples de systèmespossibles mais aussi de contre-exemples. Il est également indispensable d'identi�er lesintervenants du domaine, ainsi que leurs besoins et leurs buts. Ils font partie inté-grante de la dé�nition du domaine [CE00]. Néanmoins, une analyse de domaine est biensouvent insu�sante pour spéci�er l'ensemble du domaine. En e�et, elle ne s'intéressequ'aux points communs qui existent à l'intérieur du domaine, mais pas aux di�érences,aux variations.

Analyse de famille de programmes. Parnas dé�nit une famille de programmescomme suit [Par76] :

"Nous considérons qu'un ensemble de programmes constitue une famille,lorsqu'il est utile d'étudier les programmes de cet ensemble, en étudiantd'abord ses propriétés communes puis en déterminant les particularités dechaque membre de la famille.".

Une famille de programmes représente donc un domaine, comme dé�ni par Neighbors.Cependant, contrairement à un domaine quelconque, une famille de programmes est


un ensemble restreint où il est possible d'étudier les variations de l'ensemble, c'est-à-dire les particularités de chaque membre. Un point important de l'analyse de famillede programmes consiste à séparer les points communs des points de variations. Le butest d'identi�er un maximum de points communs a�n de les réutiliser de façon systé-matique. Un point commun dé�nit une caractéristique intrinsèque à tous les membresd'une famille de programmes. Une variation précise, quant à elle, les di�érences entreles membres. Parnas propose une méthodologie pour développer une famille de pro-grammes, permettant de réutiliser les points communs de ses membres. Un travail plusrécent, l'approche FAST, est également proposé par Weiss [Wei96] et vise à identi�er etdé�nir une famille de programmes. Pour cela, il développe une analyse, appelée analysede points communs, qui permet de découvrir la terminologie du domaine, les pointscommuns et les variations de la famille de programmes. Ces méthodologies ne sont pasles seules pour faciliter la conception de langages dédiés. Nous donnons plus loin unéventail des approches existantes.

Méthodologie. La plupart du temps, l'analyse de domaine est réalisée de manièreinformelle, mais dans certains cas, des méthodologies peuvent être utilisées et faciliterle travail de conception. Parmi ces méthodologies, nous pouvons citer DARE (DomainAnalysis and Reuse Environment) [FPDF98], DSSA (Domain-Speci�c Software Archi-tectures) [Tra95], FAST (Family-Oriented Abstractions, Speci�cation, and Translation)[WL99], FODA (Feature-Oriented Domain Analysis) [KCH+90], ODE (Ontology-basedDomain Analysis) [FGD02], ou encore ODM (Organization Domain Modeling) [Sim95].Le but de ces méthodologies est de fournir un support a�n de déterminer le bon niveaud'abstraction du langage, une terminologie spéci�que au domaine adéquate, ou encorela dé�nition et la description des concepts du domaine. Mernik et al. [MHS05] donnentune description plus détaillée de ces approches. Ils proposent également une étude sys-tématique des facteurs à prendre en compte dans les phases de décision, d'analyse, deconception et d'implémentation d'un DSL en se basant sur l'identi�cation de modèlesexistants, ainsi que sur l'étude de Spinellis [Spi01]. D'autres méthodologies de dévelop-pement de DSL peuvent encore être citées comme Sprint [CM98]. Sprint est un processuscomplet de développement logiciel, qui démarre par l'identi�cation des besoins du DSLjusqu'à son implémentation. Il utilise la sémantique dénotationnelle [Sch86] a�n de for-maliser les composants de base du DSL. La structure de la dé�nition sémantique permetd'étager les décisions de conception et d'intégrer les problèmes d'implémentation.

La �gure 3.1 résume le processus de développement d'un langage dédié à un domained'application. Avant de s'intéresser à la conception du langage, il est indispensable dedé�nir de manière précise le domaine. Cette phase de conception consiste à délimiteravec précision le domaine, en spéci�ant les objectifs et la portée du langage, mais aussien caractérisant les propriétés communes et variables de tous les systèmes du domaine.Des analyses, de domaine et de famille de programmes, permettent d'aboutir à de tellesconclusions. Elles permettent également d'identi�er et formuler des propriétés et desconcepts du domaine. Il devient alors possible de dé�nir la syntaxe et la sémantiquedu langage. Les contraintes concernant le langage, comme des besoins en analyse, sont


Analyse de Domaine et de Famille

Littérature

Implémentationsexistantes

Informationsdes experts

Concepts

Points communs

Variations

Propriétés

Syntaxe

SémantiqueDéfinition

du Langage Implémentation

du Langage

Intervenantsdu domaine

Fig. 3.1 � Processus de développement d'un langage dédié

directement intégrées dans le processus de conception. Cela permet, par exemple, derendre décidable certaines propriétés critiques du domaine au niveau du DSL. Il s'agitensuite de s'intéresser à l'implémentation du langage.

3.3.2 Implémentation

La dernière phase du processus de développement d'un langage dédié correspond àson implémentation. Il existe di�érentes techniques de mise en ÷uvre, qui ne présententpas le même coût ni les mêmes avantages. Ce point entraîne donc un choix de concep-tion, qui est souvent guidé par les contraintes du domaine (besoin de performance parexemple). A�n d'éclairer la tâche des concepteurs, Mernik et al. [MHS05] proposent unecomparaison plus aboutie de ces approches que celles présentées dans ce document.

Interprétation et compilation. L'interprétation et la compilation de DSL (e.g.,Mawl [ABBC99] ou Atmol [Eng01]) sont les approches les plus répandues. L'interpré-tation est plus appropriée pour les langages présentant un caractère dynamique du faitd'un contrôle plus important sur l'environnement d'exécution. La compilation, quant àelle, présente l'avantage de pouvoir réaliser une analyse statique complète du programmeet donc d'assurer des propriétés du domaine avant l'exécution. Elle permet également laréutilisation des outils de compilation standards [ASU86, Ben86], ou des outils dédiés àl'implémentation de DSL comme Draco [Nei84], ou ASF+SDF [vDHK96]. La construc-tion d'un compilateur ou d'un interprète permet de complètement adapter l'implémen-tation au domaine. De plus, aucune concession n'est nécessaire au niveau de la notationou encore des opérations. Néanmoins, le problème reste le coût de la construction ducompilateur ou de l'interprète et le manque de réutilisation pour d'autres implémenta-tions de DSL.

Langages enchâssés et librairies spéci�ques. La manière la plus simple de conce-voir un langage dédié est de le baser sur un langage existant. Ainsi, son implémentationen devient plus simple et les utilisateurs sont déjà familiers avec la syntaxe ou le para-digme du langage. Le concept de langage enchâssé a été introduit par Hudak [Hud96].Un des avantages d'une telle approche réside dans le fait que le nouveau langage pos-sède toute la puissance et l'expressivité du langage hôte, tout en ajoutant des primitives


dédiées au domaine qui sont plus proches des experts du domaine. La réutilisation del'infrastructure existante du langage hôte est aussi un autre avantage (environnementsde développement et de débogage, éditeurs). Une possibilité de mise en ÷uvre consisteà partiellement utiliser un langage hôte existant (e.g., Hancock avec C [CFPR00]). Uneautre possibilité est d'étendre un langage existant avec de nouvelles fonctionnalités etde nouveaux concepts, spéci�ques au domaine (e.g., Swul avec Java [BV04], ou en-core Verischemelog avec Scheme [JB00]). Les principales limitations de cette techniquese situent au niveau de l'expressivité des mécanismes, qui est restreinte aux possibili-tés du langage hôte, mais également au niveau de l'environnement d'exécution héritédu langage hôte, qui n'est pas optimisé pour le langage enchâssé. Haskell est souventcité comme le langage le plus approprié à ce type d'implémentation de langages dédiés[PHH99], avec des réalisations dans le domaine de la musique [HMGW96], ou encore larobotique [PHH99].

Pré-processing et expansion de macro. Dans cette approche, les constructionsdu DSL sont traduites par un pré-processing dans les expressions d'un langage de base.Son principal avantage est sa simplicité. Néanmoins, l'analyse statique est limitée à celleréalisée par le processeur du langage de base. Les traitements ne se font pas au niveau dudomaine. Par exemple, la couverture d'erreurs se situe, elle aussi, au niveau du langagede base, ce qui complexi�e la gestion des erreurs pour l'utilisateur. Les implémentationssont multiples [Spi01]. Parmi celles-ci, nous pouvons citer entre autres : l'expansion demacros (e.g., Latex), la méta-programmation par patrons ou templates (e.g., Blitz++[Vel98]), ou encore la traduction successive appelée pipeline (e.g., CHEM [BJK87]).

Extension de compilateur et d'interprète. Cette approche est similaire à l'ap-proche précédente, à l'exception que le pré-processing est ici intégré au compilateur ouà l'interprète. Il est alors possible de réaliser des optimisations et des véri�cations plusabouties. Le compilateur ou l'interprète est étendu avec des règles d'optimisation, ouune génération de code, spéci�ques au domaine. L'interprète TCL [Ous97], ou encorele compilateur DiSTiL [SB97] sont deux implémentations de cette approche. Si les in-terprètes sont plus faciles à étendre, il est complexe d'appliquer cette technique auxcompilateurs, sauf si la possibilité d'extension a été prévue dès leur conception.

Approche COTS. L'approche basée sur les �composants sur étagère� (CommercialO�-The-Shelves ou COTS) permet de réutiliser des outils ou des notations existantes etde les appliquer à un domaine en particulier. La meilleure illustration de cette approchereste les langages dédiés sur XML [GK02] (e.g., ACML [KG03]), où de nombreux outilspeuvent être réutilisés (analyseurs SAX, outils de transformation XSLT).

L'utilisation d'un langage dédié en lieu et place d'un langage généraliste est béné�queen de nombreux aspects. Toutefois, sa conception n'en demeure pas moins complexe etnécessite une étude et une analyse minutieuses du domaine. En e�et, des aspects à lafois fonctionnels, comme le niveau d'abstraction du langage et le degré d'analysabilité,


mais aussi non-fonctionnels, comme la lisibilité ou la facilité d'écriture, doivent être prisen compte. Pour cela, il est indispensable de bien dé�nir et délimiter le domaine d'appli-cation. L'analyse de domaine et l'analyse de famille de programmes visent à atteindrecet objectif et permettent d'aboutir à la dé�nition du langage dédié. Il devient alorspossible d'implémenter le DSL, facilité par l'utilisation de méthodologies existantes,ou par des approches hybrides (e.g., GAL [TMC97] ou encore PLAN-P [TMC98]), quicombinent les avantages des di�érentes stratégies.

3.4 Limitations actuelles

Si les langages dédiés sont réputés pour o�rir des gains substantiels dans leurs do-maines en termes d'expressivité et de sûreté, leur développement n'est pas une tâchesimple. L'implémentation d'un DSL nécessite à la fois la connaissance du domaine, maisaussi une expertise en développement de langages. Peu de personnes possèdent cettedouble compétence. De ce fait, la décision de développer un DSL est souvent retardéeindé�niment au sein d'une organisation, et beaucoup de projets de langages dédiés nedépassent pas l'étape d'une librairie. De la même manière, il existe aujourd'hui d'autresfreins à l'acceptation des langages dédiés dans les processus industriels, notamment liésau coût de développement du DSL, à la dé�nition du domaine et aux propriétés dulangage.

3.4.1 Coût de développement

La décision de développer un DSL n'est pas anodine, et prouver la rentabilité d'untel projet est une tâche di�cile. Cela demande un investissement qui peut être coûteuxpour transposer le travail dans un langage généraliste et comparer les résultats. Ainsi,les béné�ces des DSL ont souvent été observés dans la pratique et ont été quanti�és pardi�érentes études, dont celles de Herndon et Berzins [HB88], Batory et al. [BTS94], ouencore Gray et Karsai [GK03]. Néanmoins, il est très di�cile de le démontrer a priori.À ce constat vient s'ajouter l'échec de l'adoption des outils de recherche dans le mondeindustriel, outils qui pourraient diminuer le coût de développement et de maintenancede ces langages.

3.4.2 Problèmes liés au domaine

Comme nous l'avons montré dans la section 3.1, la dé�nition d'un langage dédién'est pas simple. Certains considèrent Cobol comme un langage dédié pour les appli-cations commerciales, alors que d'autres prétendent qu'un tel exemple rend vague lanotion de domaine d'application. Il est clair que la spéci�cité du domaine est une ques-tion de degré. Selon van Deursen et al. [DKV00], l'ambiguïté de la dé�nition des DSLhérite de l'imprécision de cette dé�nition de domaine. Du fait que certains le dé�nissentseulement "comme un ensemble de systèmes", la notion de domaine se réduit parfoisaux programmes qu'il contient. Cependant, cette dé�nition semble trop réductrice. Undomaine est également dé�ni à partir de bien d'autres éléments, et notamment de ses

Bilan 39

intervenants et de leurs besoins. Il est indispensable de s'interroger sur le type de per-sonne qui écrit les programmes, et sur ses compétences à la fois spéci�ques au domaine,et en programmation. Wile tire plusieurs leçons sur ce qu'entraîne l'introduction d'unlangage dédié sur une communauté d'utilisateurs [Wil04]. Considérant des réalisationsconcrètes, l'auteur présente trois types de problèmes qui a�ectent la conception, maisaussi le développement et l'adoption du DSL. Ces problèmes sont bien entendu d'ordretechnologique, mais aussi organisationnel et social. Selon son étude, il apparaît impor-tant de bien comprendre le rôle organisationnel des personnes qui utiliseront le langage,ainsi que leurs expériences, car elles font partie intégrante de la dé�nition du domaine etimpactent donc sur la conception du langage. La notion d'utilisateurs de DSL est pour-tant fréquemment délaissée, ce qui conduit souvent à une inadéquation du langage avecles besoins de l'organisation, ou à d'importantes di�cultés concernant l'introduction decette nouvelle approche dans le processus de développement.

Selon le domaine, il peut également apparaître intéressant de fournir plusieurs DSLconçus pour di�érentes catégories d'utilisateurs a�n de spéci�er un unique aspect del'application (e.g., une version pour les novices et une version avancée pour les expertsen programmation). De la même manière, il peut arriver que plusieurs DSL soient néces-saires pour spéci�er une application complète ou un domaine complexe. Cette situationpose le problème central de la composition des langages dédiés au sein d'un domaine,qui est aujourd'hui une thématique de recherche importante autour des langages dédiés.

3.4.3 Propriétés du langage

Le langage en lui-même peut également être une source de problèmes, et notammentface à des besoins de maintenance et d'évolution du langage, souvent considérés commedes points faibles de l'approche [DK98]. En e�et, il n'est pas simple de faire évoluerun DSL. Par exemple, lorsqu'un nouveau type de donnée ou une nouvelle fonction estnécessaire, le compilateur a besoin d'être adapté. Cela nécessite des compétences encompilation, qui peuvent ne pas être présentes au sein des organisations. En e�et, unetelle compétence correspond rarement à la formation initiale des personnes qui utilisentle DSL.

En�n, l'un des arguments contre l'utilisation des DSL qui reçoit le plus d'atten-tion aujourd'hui reste le fameux e�et "tour de Babel". Lorsque plusieurs développeursconstruisent leurs propres langages spéci�ques, le nombre important de syntaxes dif-férentes peut créer une confusion. Développer de nouveaux langages pour tous les do-maines ne saurait être la solution, car cette e�ervescence de langages poserait des pro-blèmes d'interopérabilité et de réutilisation d'infrastructures ou d'outils.

3.5 Bilan

Les langages dédiés sont un moyen reconnu pour permettre aux utilisateurs �nauxde programmer sans être experts en programmation. Restreints à un domaine, qui peutprendre la forme d'une famille de programmes, ils permettent de factoriser toute la


connaissance relative à ce domaine dans le langage, en utilisant un haut niveau d'abs-traction. Au delà d'une programmation simpli�ée, concise et plus rapide, ils permettentla véri�cation statique de propriétés critiques pour le domaine considéré (section 3.2).Les DSL ne représentent pas aujourd'hui la panacée pour résoudre tous les problèmesdu génie logiciel ; toutefois, un DSL conçu pour un domaine bien identi�é et adapté auxbesoins de ses utilisateurs peut considérablement réduire les coûts de développementd'applications, tout en augmentant la productivité. Pour ces di�érentes raisons, les lan-gages dédiés ouvrent des perspectives intéressantes. Cependant, sans une méthodologieet des outils appropriés, ils peuvent apparaître di�ciles à mettre en ÷uvre et coûteuxà concevoir et implémenter (section 3.4).

Chapitre 4

Étude de cas : la Téléphonie sur IP

Le but de ce chapitre est d'illustrer notre démarche par l'étude d'un cas concret : ledomaine de la création de services de Téléphonie sur IP. Ce domaine résume la probléma-tique présentée dans ce document, en montrant comment l'ouverture des plates-formesde téléphonie à des développeurs non-informaticiens met en péril des propriétés im-portantes du domaine. Le chapitre met également l'accent sur les limites des solutionsactuelles, inadaptées aux besoins des utilisateurs et nécessitant des compétences impor-tantes dans de nombreux domaines. Ce manque d'outils �ables et adaptés fait de laprogrammation de services de téléphonie un processus complexe et réservé aux experts.

Dans ce chapitre, nous présentons le domaine de la Téléphonie sur IP, et plus par-ticulièrement la téléphonie basée sur le protocole de signalisation SIP1 [RSC+02]. Nousmontrons les problématiques relatives à la programmation de services de Téléphonie surIP, avant de terminer par un état de l'art des solutions existantes.

4.1 Introduction à la téléphonie applicative

La Téléphonie sur IP est une véritable révolution technologique ainsi qu'une ré-volution des usages. Elle constitue une avancée signi�cative dans la convergence entreles réseaux de téléphonie et les réseaux de données. Par rapport à la téléphonie tradi-tionnelle, la Téléphonie sur IP o�re non seulement des perspectives de simpli�cationd'architecture et d'administration d'équipements, mais aussi l'opportunité d'enrichir lesystème téléphonique de nouvelles fonctionnalités, intégrant les applications informa-tiques des organisations.

La Téléphonie sur IP apparaît comme un bouleversement majeur de nos habitudes.Au-delà des apports technologiques, elle représente un gain de confort pour les utilisa-teurs et un réel avantage concurrentiel pour les organisations. En e�et, elle permet detransmettre des communications vocales au travers de réseaux régis par le protocole IP(Internet Protocol). Elle fédère ainsi tous les postes de travail d'une société, y comprisles travailleurs itinérants, en un seul réseau convergé. Ce faisant, elle permet de simpli-�er l'architecture globale de l'organisation en acheminant la voix et les données sur un

1SIP est l'acronyme anglais de Session Initiation Protocol.

41

42 Étude de cas : la Téléphonie sur IP

seul réseau. Cependant, le véritable avantage de la Téléphonie sur IP ne se situe pas auniveau de la réduction des coûts (réutilisation du matériel et tari�cation des commu-nications), comme beaucoup peuvent le penser, mais davantage au niveau des servicesassociés. En e�et, elle donne accès à des fonctionnalités avancées et des applications quiaméliorent la productivité globale d'une organisation. La téléphonie applicative devientalors un véritable enjeu stratégique pour l'organisation.

La convergence des télécommunications et des réseaux informatiques a ajouté ungrand nombre de possibilités aux services de téléphonie classiques, grâce à l'interactionavec des éléments tels que le Web, le courrier électronique ou encore les bases de don-nées. De plus, elle a rendu la programmation de services de téléphonie aussi accessibleque la programmation de services réseau [Len04], contrairement aux solutions existantesde téléphonie traditionnelle, fermées et propriétaires. En pratique, ces services reposentsur une plate-forme téléphonique qui fournit des opérations de signalisation (e.g., locali-sation de l'appelé ou paramétrage de la session d'appel). La plate-forme de signalisationbasée sur le protocole SIP [RSC+02] émerge comme le standard de fait de la Téléphoniesur IP, ainsi que de la téléphonie non-�laire comme le GPRS2 et l'UMTS3. Cette pro-grammabilité des services de téléphonie est rendue possible pour les développeurs grâceà des interfaces restreintes [DJK02, LS00], et pour les administrateurs en utilisant deslangages et des interfaces de programmation non-restreints [DRM04, Kut03]. Toutefois,rendre programmable un domaine comme la téléphonie présente un grand nombre dedé�s. L'un de ces dé�s concerne la �abilité des services développés, qui peuvent en-traîner par exemple la corruption de la plate-forme, voire son e�ondrement. Dans unetelle éventualité, la plate-forme de signalisation ne pourrait plus remplir son rôle, et desappels pourraient être perdus. Il est donc indispensable de se pencher sur les besoinsde telles plates-formes, a�n de leur assurer une exécution correcte. Dans le but de biencomprendre les enjeux liés à la programmation de services de Téléphonie sur IP, nousnous plaçons dans le cadre de plates-formes de signalisation SIP.

4.2 L'environnement SIP

Le protocole SIP apparaît de plus en plus comme une brique fondamentale desréseaux convergents. Si d'autres protocoles issus des télécommunications, comme MGCP[AF03] ou H.323 [Uni99], existent sur le marché, ils semblent aujourd'hui complètementdépassés par la simplicité de SIP et l'ampleur de son déploiement.

2Le General Packet Radio Service ou GPRS est une norme pour la téléphonie mobile dérivée duGSM (Global System for Mobile Communications), permettant un débit de données plus élevé. Il estégalement appelé 2,5G.

3L'Universal Mobile Telecommunications System ou UMTS est l'une des technologies de téléphoniemobile de troisième génération (3G).

L'environnement SIP 43

4.2.1 Les principes du protocole SIP

Standardisé par l'IETF4 et adopté par l'ITU5, SIP [RSC+02] est un protocole pour lacréation, la modi�cation et la terminaison de sessions avec un ou plusieurs participants.Ces sessions incluent les appels téléphoniques sur Internet ou encore les conférencesmultimédia. SIP gère la totalité des phases d'une communication multimédia : la lo-calisation, l'analyse du pro�l des interlocuteurs, la négociation du média vis-à-vis descapacités des intervenants, l'établissement et la gestion de la session. En revanche, il nese charge pas du transport des médias pendant la session ; il se limite à la signalisation.

Basé sur un modèle client-serveur, le protocole SIP partage de nombreuses simili-tudes avec le protocole HTTP6, comme le codage ASCII des messages ou encore lescodes de réponse. Un environnement SIP est principalement constitué de trois typesd'entités : le serveur d'enregistrement (registrar server), le serveur dit mandataire ouproxy (proxy server) et des agents utilisateurs (user agents). Le serveur d'enregistrementpermet à un utilisateur de spéci�er sa localisation courante. Il ne gère que les requêtesd'enregistrement (méthode REGISTER du protocole SIP), envoyées par les clients poursignaler leur emplacement. Un proxy SIP sert d'intermédiaire entre deux entités SIP(client ou proxy) qui ne connaissent pas leur localisation respective (adresse IP). Ildistribue les messages SIP à leurs destinataires en interrogeant le serveur d'enregistre-ment. Une plate-forme SIP est essentiellement constituée d'un serveur d'enregistrementet d'un proxy SIP a�n de gérer les di�érents messages provenant ou à destination desutilisateurs d'un domaine donné. Des serveurs proxy additionnels peuvent être ajoutésà l'architecture. En�n, l'agent utilisateur représente un périphérique de l'utilisateur (lo-giciel ou matériel), c'est-à-dire un téléphone, un ordinateur ou un assistant personnel.Il e�ectue les actions autorisées par le protocole SIP a�n d'établir, modi�er ou terminerune session multimédia. SIP supporte la mobilité des utilisateurs en fournissant à unutilisateur une adresse, appelée SIP URI (Uniform Resource Identi�er), qui peut êtreassociée à plusieurs équipements de communication. Elle possède une forme similaireà celle d'une adresse de messagerie électronique, contenant un nom d'utilisateur et unnom d'hôte. La �gure 4.1 résume sous une représentation simpli�ée l'architecture SIPdécrite ici. Pour aller plus loin dans l'explication d'une plate-forme SIP, nous nous pro-posons, dans la section suivante, de présenter les principales étapes à réaliser lorsqu'unutilisateur désire passer un appel.

4.2.2 SIP par l'exemple

A�n d'illustrer la mise en relation entre deux interlocuteurs, nous allons nous pla-cer dans le cadre décrit par la �gure 4.1, illustrant un appel téléphonique entre Bobet Alice. Pour passer un appel, un utilisateur, ici Bob, doit initier une session. Pour

4L'Internet Engineering Task Force ou IETF est un groupe informel, international et ouvert à toutindividu, qui participe à l'élaboration de standards pour Internet.

5L'International Telecommunication Union ou ITU est une organisation internationale, chargée dela réglementation et de la plani�cation des télécommunications dans le monde.

6Le HyperText Transfer Protocol ou HTTP est un protocole de communication client-serveur déve-loppé pour le Web.


Réseau

Agent utilisateur138.96.64.22

Agent utilisateur147.210.9.15

Serveur proxylabri.fr

Serveur proxyinria.fr

Serveur d’enregistrementlabri.fr

Serveur d’enregistrementinria.frBob

sip:[email protected]

Alicesip:[email protected]

Fig. 4.1 � Architecture SIP

cela, il émet une requête incluant sa position actuelle et l'adresse de l'appelée, Alice(sip:[email protected]). Cette requête (méthode INVITE du protocole SIP) demande auserveur d'établir une session entre Bob et Alice. De la même manière qu'un message decourrier électronique, la requête est routée par une succession de serveurs proxy, jusqu'àatteindre le serveur responsable du domaine de l'appelé (dans notre cas labri.fr). Àce niveau, ce dernier interroge le serveur d'enregistrement responsable d'Alice, a�n dela localiser, et lui envoie la requête sur son téléphone courant. À la réception du mes-sage, le téléphone d'Alice sonne. Si elle décroche, une réponse (de type OK) est renvoyéeà Bob, incluant la localisation actuelle d'Alice. Après acquittement de la réception dela réponse par Bob (méthode ACK), la communication est établie. Si l'un des partici-pants décide de terminer la conversation, il raccroche le téléphone et une requête determinaison d'appel (méthode BYE) est envoyée à l'autre participant.

L'une des forces des plates-formes SIP actuelles réside dans la possibilité d'étendrele comportement décrit ici, en programmant la logique de routage des appels. Cetteprogrammation se fait par l'ajout de composants exécutables que sont les services SIP.Ils permettent, par exemple, de �ltrer des appels selon l'appelant, de modi�er la prioritéde certains appels, ou encore de rediriger les communications.

4.2.3 Introduction aux services SIP

De nombreuses plates-formes de signalisation SIP permettent aux utilisateurs de dé-ployer des services au niveau d'un composant additionnel, appelé serveur d'applications.

Les enjeux de la création de services 45

Ces services agissent sur la logique de routage des appels et peuvent modi�er le com-portement de la plate-forme en fonction de ressources du réseau informatique commeles ressources Web, les bases de données ou les agendas. Une gamme si étendue de fonc-tionnalités permet à la téléphonie d'être personnalisée en fonction des préférences, desattentes et des souhaits des usagers, qui sont de plus en plus exigeants.

Nous illustrons la notion de service avec notre exemple. Supposons qu'un service soitactivé pour Alice, autorisant seulement ses clients à la joindre pendant ses heures de tra-vail. Lorsqu'un appel de Bob est reçu par le proxy d'Alice, ce dernier invoque le serveurd'applications associé, qui exécute alors le service. Si l'adresse de Bob n'appartient pasà la liste des clients d'Alice, alors le service rejette l'appel, sans que le téléphone d'Alicene sonne. Si Bob est un client, le service demande alors à la plate-forme SIP de contacterAlice. Si elle est déjà en communication, le service pourrait également rediriger l'appelsur sa boîte vocale.

A�n de spéci�er sa propre logique de routage d'appels au sein de la plate-forme, ilexiste de multiples interfaces de programmation permettant à un programmeur quel-conque d'accéder à un ensemble plus ou moins restreint de ressources. Cependant, unecommunication téléphonique est une application temps réel, ce qui impose de nom-breuses contraintes non présentes dans les applications traditionnelles telles que le trans-fert de �chiers (FTP) ou le Web. La création de services ne peut donc se faire aux dépensde ces propriétés métiers du domaine de la téléphonie.

4.3 Les enjeux de la création de services

La nature ouverte d'une plate-forme SIP rend en principe l'écriture de services detéléphonie accessible à un large éventail de programmeurs. Toutefois, les plates-formesdevenant programmables par des développeurs plus ou moins inexpérimentés, elles de-viennent moins �ables. En e�et, le développement de nouveaux services de téléphonieexpose l'environnement à un risque croissant d'erreurs logicielles. Ce manque de �abi-lité peut corrompre, voire interrompre, un service ou la plate-forme toute entière. Or,la téléphonie est appréhendée par le grand public comme une ressource indispensable,au même titre que l'eau et l'électricité. Les usagers font donc fortement con�ance à leursystème téléphonique. À travers cette contradiction, il apparaît donc clair que le succèsde la programmation de la Téléphonie sur IP dépend de façon critique de la �abilité desservices. A�n de répondre à ce besoin de sécurité, il convient à la fois de s'intéresser à lapersonne qui programme mais aussi aux propriétés que le service doit assurer vis-à-visde l'environnement d'exécution.

Le programmeur. Un enjeu important de la programmation de services de Télépho-nie sur IP consiste à bien dé�nir la communauté des programmeurs. En particulier, ledéploiement de services par des utilisateurs n'ayant aucune compétence en télécommu-nications n'a pas les mêmes répercussions que dans le cas d'un programmeur expertdu domaine. Un compromis doit donc être fait entre les possibilités o�ertes aux pro-grammeurs et leurs niveaux de compétences, a�n de pouvoir assurer la �abilité des


plates-formes de téléphonie. Tout dépend du niveau de con�ance de l'utilisateur. Ene�et, un environnement complètement ouvert nécessite une expertise étendue dans denombreux domaines, comme les télécommunications, le protocole SIP et ses protocolesannexes, en programmation distribuée, réseaux, ou encore dans les interfaces de pro-grammation SIP. Cette situation n'est donc absolument pas adaptée à des développeursdébutants. Plus les possibilités o�ertes par le service sont nombreuses et plus le risqued'erreurs logicielles augmente, ainsi que la possibilité pour un programme d'accomplirdes actions malicieuses. Pour les utilisateurs novices, l'accès aux ressources doit être res-treint, et le service doit être lisible et facile à concevoir. En ce qui concerne les expertsdu domaine, l'environnement doit être plus �exible. L'enjeu consiste donc ici à fournirun mécanisme de programmation adapté pour tous.

Les propriétés du domaine. Quelles que soient les compétences du programmeur,il est primordial que le service assure certaines propriétés vis-à-vis de l'environnementd'exécution. Sans cette garantie, l'exécution d'un service peut corrompre le comporte-ment de la plate-forme de téléphonie. Ces propriétés ont été identi�ées par Rosenberget al. [RLS99], dans un cahier des charges des solutions de programmation de servicesde Téléphonie sur IP. L'une d'entre elles concerne le caractère véri�able du service etconsiste à assurer qu'un service s'exécute correctement par rapport au routage d'appel ;c'est-à-dire que tous les chemins du programme routent les appels vers une personne.Selon l'expressivité de programmation o�erte aux utilisateurs, cette propriété peut ra-pidement devenir complexe à véri�er. Les sources du problème peuvent être nombreuseset survenir à des niveaux complètement di�érents. Cela peut concerner le domaine de latéléphonie (e.g., tout appel doit aboutir à une opération de signalisation), le protocolede signalisation SIP (e.g., la véri�cation des séquences autorisées de requêtes/réponses),la plate-forme de signalisation SIP (e.g., la détection de con�its dans les traitementsd'appels), ou encore le service de téléphonie lui-même (e.g., présence de code mort dansle service). La deuxième propriété métier concerne la terminaison des services de télé-phonie en un temps �ni. Elle est directement liée à la fois à l'expressivité du langage età l'utilisation de ressources externes. En e�et, l'utilisation de certaines constructions,comme la notion d'itération arbitraire, rend ce problème non-décidable. De même, l'uti-lisation d'une ressource doit nécessairement être bornée a�n de ne pas faire attendretrop longtemps le correspondant et assurer qu'un téléphone va sonner. Ainsi, la véri�-cation des propriétés du domaine est principalement liée à trois facteurs : l'accès auxressources disponibles depuis le service, les détails des informations du protocole fournisau service et le niveau de contrôle que le service possède sur l'environnement d'exécution.

Malgré l'introduction de services plus ou moins complexes, les plates-formes de té-léphonie doivent assurer le même niveau de �abilité que pour la téléphonie classique.Ainsi, la programmation ne doit pas se faire aux dépens de la �abilité de la plate-forme.De plus, un des enjeux consiste à permettre à di�érents niveaux d'utilisateurs de pro-grammer ses propres services, qu'ils soient experts en télécommunications ou non. Ils'agit alors d'adapter l'environnement de programmation aux compétences de l'utilisa-teur, tout en assurant les propriétés métiers du domaine.

État de l'art des solutions existantes 47

4.4 État de l'art des solutions existantes

Il existe di�érentes solutions de programmation de plates-formes de téléphonie. Cessolutions présentent des approches di�érentes du problème, allant de l'interface de pro-grammation restreinte, à l'utilisation d'un langage généraliste. Cette section présente unaperçu de ces solutions et détermine dans quelles mesures elles répondent aux attentesexprimées dans la section 4.3.

CPL. Le langage CPL (Call Processing Language) [Len04, LS00] est un dialecte XMLqui vise les non-programmeurs. Limité dans son expressivité a�n de contraindre lesutilisateurs, CPL est un langage de programmation sûr, cachant toute complexité auprogrammeur. Un scénario CPL est représenté sous la forme d'un arbre de décisionsstatique, dont les n÷uds spéci�ent des actions ou des décisions à prendre. Le langageCPL est issu des travaux de recherche de Henning Schulzrinne, à l'origine du protocoleSIP. Du fait de sa simplicité, ce langage reçoit un grand écho industriel. Il est, entreautres, nativement implémenté dans la plate-forme Vocal de Vovida [DJK02] et estsupporté par la quasi-totalité des plates-formes existantes. Néanmoins, CPL o�re trèspeu de fonctionnalités ce qui limite fortement son utilisation pratique. De plus, sonhaut niveau d'abstraction rend le langage très di�cile à faire évoluer, du fait d'unbesoin de génération important de code. En�n, aucune véri�cation sémantique n'estfaite au niveau du service. Seules des véri�cations syntaxiques sont réalisées. Il estpar exemple tout à fait possible d'écrire du code qui ne s'exécutera jamais, à caused'une inconsistance au niveau d'une succession de tests. Considérons l'exemple de la�gure 4.2, illustrant un scénario CPL (sur la gauche), et une représentation abstraitedu même service (sur la droite). Dans cet exemple, lorsqu'un appel arrive pour Bob(n÷ud 1), si l'adresse de l'appelant contient "boss" (n÷ud 2), alors l'appel est redirigésur son téléphone (n÷ud 3). Dans le cas contraire (n÷ud 4), si l'adresse de l'appelant est"sip:[email protected]" (n÷ud 5), alors l'appel est redirigé sur son téléphone mobile(n÷ud 6), et sinon il est rejeté (n÷ud 7). Ce service est totalement correct d'un point devue du langage CPL et peut être déployé sur une plate-forme de téléphonie. Cependant,à y regarder de plus près, nous pouvons nous apercevoir qu'il contient une inconsistanceau niveau des décisions sur les adresses. En e�et, le test du n÷ud 2 inclut celui du n÷ud5. La séquence 1-2-4-5-6 ne peut donc jamais se produire. En programmation, cettesituation correspond à du code mort puisque le service contient un chemin d'exécutioninfaisable. De la même manière, il est tout à fait possible d'introduire de l'inconsistanceavec des tests concernant des dates ou des périodes.

SER. SIP Express Router (SER) [Kut03] est un langage dont la syntaxe se rapprochede celle du C et qui vise à con�gurer statiquement les serveurs d'applications. Il permetune manipulation bas niveau des messages SIP. Il est reconnu pour ses performances,obtenues grâce à des analyses e�caces de messages et une faible consommation de res-sources. Le langage est également extensible. Pour cela, il possède une primitive dechargement de modules et donc une ouverture sur de nouvelles fonctionnalités. Il enexiste de nombreux, pour le support de MySQL, de scénarios CPL ou encore pour


<?xml version="1.0" encoding="UTF-8"?><cpl><incoming><address-switch field="origin"><address contains="boss"><location url="sip:[email protected]"><proxy /></location></address> <otherwise><...><address-switch field="origin"><address is="sip:[email protected]"><location url="tel:+330687126587"><proxy /></location></address><otherwise><reject /></otherwise></address-switch></otherwise></address-switch></incoming></cpl>

Appel entrant

...

oui non

L’adresse de l’appelantcontient-elle "boss" ?

Redirection de l’appel sur le

téléphone mobile de Bob


téléphone de Bob

L’adresse de l’appelantest-elle

"sip:[email protected]" ?

Rejet de l’appel

oui non

1

2

3

5

6 7

4

Fig. 4.2 � Service de téléphonie écrit en CPL

utiliser un serveur d'authenti�cation de type RADIUS. Néanmoins, les véri�cations ef-fectuées restent très sommaires et ne garantissent pas la sûreté d'un service. De plus,elles sont rendues di�ciles voire impossibles dans le cas d'utilisation des modules écritsen C. Le langage vise nécessairement des experts en télécommunications et en protocoleSIP. En e�et, il permet de modi�er directement les messages SIP et par exemple deréécrire les champs d'un message. Une modi�cation erronée d'un champ SIP peut parexemple entraîner une perte d'appels. De plus, le langage manipule des notions avancéesde programmation et de réseau, comme la taille des mémoires tampons lors de la com-paraison de messages, la con�guration du protocole de transport de la voix, la gestionde processus, ou encore le nombre de retransmissions du serveur de noms de domaine(DNS).

MSPL/C# . Une autre alternative consiste à utiliser l'environnement SIP de Mi-crosoft, Live Communications Server [Mic04], orienté vers la messagerie instantanée. Laprogrammabilité de cette plate-forme permet de décrire tout le spectre des possibilités deprogrammation de services : de la journalisation d'évènements (logging) au routage per-sonnalisé d'appels. Pour cela, l'environnement utilise deux niveaux de programmation.Une première partie, l'Application Manifest, spéci�e principalement quelles méthodesle service va traiter et comment router les messages. Tous les messages capturés serontensuite traités par un langage à script, le Microsoft SIP Processing Language (MSPL).Ce langage est couplé à une interface de programmation (API) haut niveau, qui permetde simpli�er le traitement de messages. Les experts en programmation ont, quant à eux,un niveau de programmabilité supplémentaire. Dans la partie écrite en MSPL, il est pos-sible de déléguer le traitement des messages à un programme écrit en C# pur. Ce niveaupermet de faire tous les traitements possibles sur le message. La solution proposée pour

État de l'art des solutions existantes 49

programmer les services est très prometteuse mais son implémentation présente encoredes défauts. De plus, elle est complètement intégrée au framework Microsoft et la pro-grammation reste donc limitée aux possibilités de cet environnement (authenti�cation,dépendance d'applications, etc.). En�n, l'ouverture de la programmation aux expertsvia le langage C# se fait aux dépens de la véri�cation. Par exemple, l'accès à des bouclesnon contrôlées (comme while, ou for) dans C# n'assure plus la terminaison du serviceni même une consommation limitée des ressources de la plate-forme (processus, tempsCPU, etc.).

JAIN SIP et les solutions Java. La communauté Java propose plusieurs solu-tions de programmation de plates-formes de téléphonie. La plus simple, les Servlets SIP[Kri03], permet de ne se charger que de la programmation de la logique de service. Uneautre possibilité consiste à se tourner vers le framework JAIN SIP [Sun05, DRM04], quio�re une plus grande souplesse grâce à davantage de fonctionnalités relatives à l'accèsà des ressources extérieures. Néanmoins, ces deux interfaces reposent plus ou moins surla même API de programmation, qui demeure complexe et nécessite un processus d'ap-prentissage laborieux. Elle est, par exemple, constituée de 130 classes et plus de 3000méthodes, nécessitant des compétences en réseau, en téléphonie ou encore en multimé-dia. De plus, a�n de faciliter la réutilisation des méthodes, ces dernières sont renduesgénériques, ce qui implique parfois un grand nombre de paramètres dont le program-meur doit s'accommoder. Certaines méthodes nécessitent ainsi plus de 12 arguments.La logique du service devient totalement entrelacée avec l'implémentation de la plate-forme, rendant di�cile toute évolution du service et tout débogage. En�n, d'un point devue du domaine de la téléphonie, certaines opérations élémentaires peuvent nécessiter denombreuses étapes. Par exemple, appeler un correspondant requière plus de 10 lignes decode et 15 appels de méthodes. Un dernier problème concerne l'évolution des interfacesde programmation et la nécessité de garder à jour l'application vis-à-vis des dernierschangements. Tout ceci complexi�e considérablement la véri�cation des propriétés dudomaine. Par exemple, rien n'est fait a�n de véri�er que les étapes intermédiaires d'uneredirection d'appel sont correctes.

Les solutions de création de services de Téléphonie sur IP sont nombreuses, et lesplates-formes de programmation sont en pleine émergence. Néanmoins, cette program-mation se fait bien souvent aux dépens des règles métiers du domaine (section 4.3), cequi nécessite de la part des programmeurs d'importantes connaissances dans de nom-breux domaines, que ce soit en télécommunications, réseau, ou même en programma-tion. Les plates-formes de signalisation existantes reposent toutes sur des paradigmesde programmation particuliers. Ainsi, un service écrit pour une plate-forme ne peutpas être réutilisé dans un autre environnement. Ce portage nécessite la réécriture com-plète du service a�n de correspondre à la nouvelle cible. De plus, comme le montrel'étude comparative que nous avons réalisée [BCC+04], ces solutions ne fournissent pasun environnement de développement �able, permettant à des programmeurs ayant descompétences diverses de créer des services. Ainsi, aucune de ces approches ne sembleréellement être le bon outil, o�rant les bons concepts, les bonnes abstractions et les


véri�cations associées. Il apparaît inévitable de devoir choisir entre l'expressivité et la�abilité.

4.5 Bilan

Si la téléphonie traditionnelle a pendant longtemps résisté à la vague Internet, laTéléphonie sur IP a totalement levé ce verrou. Le protocole SIP représente aujourd'huile socle de cette révolution, couplant informatique et téléphonie, et o�rant de nou-veaux services aux utilisateurs. En e�et, la convergence des télécommunications et desréseaux informatiques a ajouté un grand nombre de possibilités aux services de télé-phonie classiques. Cependant, cette évolution vers une téléphonie applicative amène desdéveloppeurs non-informaticiens à concevoir des services. Pour aggraver la situation, lestechniques existantes de programmation sont le plus souvent bas niveau et non sûres,nécessitant une certaine compétence en télécommunications, mais aussi en programma-tion. Elles n'o�rent également que très peu d'abstractions du domaine. Ces limitationsfont de la programmation de services de téléphonie un processus sujet à erreurs, pouvantcorrompre la �abilité des plates-formes téléphoniques.

Chapitre 5

Bilan

Ce chapitre présente le bilan du contexte scienti�que de cette thèse. Après avoirrésumé les enjeux liés à la diversité des programmeurs, il expose les problématiquessoulevées par l'accès à la programmation à des développeurs non-informaticiens. Il sou-ligne également l'inadéquation des approches logicielles actuelles pour le développementde solutions adaptées à ce nouveau type de programmeur.

5.1 La diversité des programmeurs

Qui sont aujourd'hui les programmeurs ? Ce sont des ingénieurs en mécanique, desmédecins, des physiciens, des comptables. Ce sont également des assistants, des ensei-gnants, des réceptionnistes. Ce ne sont plus seulement des experts en programmation.Ces nouveaux développeurs utilisent des outils de programmation haut niveau a�n deles aider dans leurs métiers. Selon une étude récente réalisée par des chercheurs del'Université de Carnegie Mellon [SSM05a], le nombre de développeurs américains non-informaticiens était évalué à près de 55 millions en 2005 contre seulement 3 millions deprogrammeurs professionnels. De plus, les estimations [SSM05b] montrent qu'en 2012,ce chi�re devrait dépasser les 90 millions, alors que le nombre de programmeurs profes-sionnels ne devrait, quant à lui, pas évoluer. Ainsi, la majorité des programmes n'estplus aujourd'hui écrite par des informaticiens professionnels.

Cependant, à y regarder de plus près, une dichotomie stricte des utilisateurs, entredéveloppeurs non-informaticiens et programmeurs professionnels, n'est pas pour autantexacte et signi�cative. En e�et, il semble plus judicieux de considérer un éventail pluslarge de comportements des utilisateurs, car tous ne programment pas de la même ma-nière. Selon l'étude présentée précédemment, 60% des développeurs non-informaticiensmanipulent des feuilles de calcul ou des bases de données dans leurs métiers de tous lesjours. Toutefois, au sein même de ce type de programmation, les utilisateurs démontrentune certaine diversité. Par exemple, selon l'étude de Fisher et al. [FR05], sur 4498 feuillesde calcul seules 44% contiennent des formules de calcul (e.g., moyenne de nombres, écart-type ou encore valeur médiane). De même, selon l'étude de Hall [Hal96], sur 106 feuillesde calcul créées par des employés australiens ayant des connaissances en informatique,

51

52 Bilan

47% utilisent des fonctions de type "if", alors que seulement 21% manipulent des liensavec des bases de données. Toutes ces observations montrent bien que les développeursn'appréhendent pas la programmation des feuilles de calcul de manière identique, maisdavantage selon leurs propres besoins. À ce jour, le domaine des feuilles de calcul estl'environnement de programmation pour les développeurs non-informaticiens à avoir étéle plus souvent étudié par les chercheurs. Cependant, il est tout à fait envisageable quel'étude d'autres environnements (e.g., la création de pages web, le �ltrage de courrierélectronique ou encore la simulation) révèle une variété comparable de comportements.

La diversité des pro�ls de développeurs tient à plusieurs facteurs. Comme indiquédans la section 3.4.2, le rôle organisationnel et social des développeurs au sein de l'orga-nisation est un premier critère discriminant. Toutefois, à cela s'ajoute, entre autres, leniveau de compétence dans le domaine ou encore l'expertise en programmation. Cettemultiplicité de critères entraîne une variation des pro�ls de développeurs et donc unediversité des besoins en programmation au sein d'un même domaine d'application. Cettehétérogénéité des besoins se retrouve au niveau fonctionnel (e.g., en termes d'expres-sivité ou de fonctionnalités o�ertes) mais également non-fonctionnel (e.g., en termesde �abilité, de portabilité, voire de préférences au niveau de l'interface de program-mation). La diversité des pro�ls dépend également du domaine d'application ainsi quedu contexte d'utilisation des développeurs. Ces di�érences n'apparaissaient pas il y aquelques années dans la mesure où les solutions de programmation étaient seulementdédiées à des programmeurs expérimentés. Il semble donc di�cile d'utiliser seulementles compétences ou l'expertise comme critères pour caractériser les besoins des déve-loppeurs et leur concevoir des solutions sur mesure. Cependant, c'est le fait de monteren abstraction qui a diversi�é les populations de programmeurs. Donc, plutôt que des'intéresser à analyser les populations de programmeurs, il paraît plus approprié de setourner vers une caractérisation du niveau d'abstraction des besoins des développeurset des tâches à accomplir. En e�et, certaines tâches demandent davantage d'expressi-vité, de compétence (e.g., la programmation d'une plate-forme de téléphonie), alors qued'autres peuvent se faire à un haut niveau d'abstraction (e.g., la con�guration d'unservice de téléphonie existant). De plus, le niveau d'expertise du programmeur n'in�uepas directement sur le choix d'une solution de programmation. En e�et, si la tâche àréaliser peut se faire facilement avec un outil de programmation haut niveau, un pro-grammeur même professionnel préférera utiliser le moyen le plus simple plutôt que dese compliquer l'existence avec un outil plus expressif mais également souvent plus com-plexe. Il apparaît donc intéressant d'étudier la diversité des utilisateurs selon la natureplus ou moins haut niveau des besoins qu'ils expriment. Une catégorisation simple deces besoins émerge depuis quelques années, re�étant l'émergence des approches présen-tées dans les chapitres 2 et 3. Cette classi�cation repose sur une dichotomie entre desbesoins en programmation et des besoins en modélisation.

La diversité des programmeurs entraîne une multiplicité des besoins en termes desolutions de développement logiciel. Ces solutions se distinguent fondamentalement parleur niveau d'abstraction et leur approche du problème d'un point de vue programma-tion ou modélisation. Quoi qu'il en soit, ces solutions partagent bien souvent une grande

Problématiques 53

partie de la connaissance du domaine mais aussi une part importante de l'implémenta-tion (section 3.2.3). L'enjeu consiste donc à réconcilier ces approches (programmationet modélisation), mais également à factoriser, capitaliser et automatiser le plus possibleles étapes de conception, a�n de simpli�er le développement de nouvelles solutions.

5.2 Problématiques

L'ouverture de la programmation à des non-informaticiens complexi�e le développe-ment de solutions logicielles, du fait du fossé grandissant entre le domaine d'utilisationet l'implémentation. De plus, en élevant le niveau d'abstraction des solutions, la popu-lation de programmeurs se retrouve diversi�ée en fonction de nombreux critères (e.g.,les compétences du développeur, son rôle dans l'organisation, ou encore son expertisedans le domaine). Cette diversité doit également être prise en compte au niveau dudéveloppement des solutions a�n de diminuer le temps de conception et d'augmenter laproductivité. En�n, cette ouverture implique également de forts besoins en termes de�abilité des programmes.

Des solutions haut niveau et �ables. Beaucoup d'utilisateurs n'ont pas le temps,ou l'envie, de prendre en main de nouveaux outils, ou d'apprendre de nouvelles com-pétences. L'enjeu consiste donc à leur o�rir des solutions de programmation adaptéesà leurs compétences, a�n de programmer au niveau de leurs domaines (de l'espace deproblèmes), et non plus dans des technologies informatiques (au niveau de l'espace desolutions). De plus, ouvrir la programmation à ces développeurs débutants consistenon seulement à élever le niveau d'abstraction des solutions de programmation, maisaussi à assurer la �abilité des propriétés critiques du domaine d'application. Commele montre la section 2.3, la complexité des technologies existantes et des procédés dedéveloppement rend di�cile la véri�cation de ces propriétés, à cause entre autres, d'unentrelacement entre la logique du programme et son implémentation. Nous avons illus-tré ce point dans le domaine de la création de services de Téléphonie sur IP (chapitre4). La programmation de ces services nécessite des compétences dans de nombreux do-maines comme les télécommunications, les protocoles pour le multimédia, ou encore lessystèmes distribués. Or, les solutions de programmation de plates-formes de téléphoniesont souvent généralistes et complexes, ne permettant pas à des utilisateurs novices deprogrammer (section 4.4). En e�et, cette inadéquation des solutions à ce type d'utili-sateur augmente le risque d'erreurs logicielles et donc de services erronés, empêchantd'assurer les propriétés critiques de la téléphonie (section 4.3).

Des approches de développement inadaptées. Les approches actuelles, Ingénie-rie Dirigée par les Modèles (chapitre 2) et langages dédiés (chapitre 3), ne permettentpas de développer de manière simple et performante de telles solutions de programma-tion. Nous avons montré les limites de la modélisation, de par son approche généralistedu problème (section 2.3.1), mais aussi à cause de son manque de sémantique (section2.3.2) nécessaire à la génération d'une implémentation correcte et e�cace. Les langages

54 Bilan

dédiés semblent, quant à eux, plus à même de réduire le fossé entre le niveau d'abstrac-tion et l'implémentation. De plus, du fait d'une expressivité restreinte et d'une séman-tique précise, les DSL facilitent l'analyse de programmes, la véri�cation de propriétéset la production logicielle (section 3.2). Cependant, comme le montre la section 3.4, laconception et l'implémentation de tels langages restent encore di�ciles. De plus, cettesolution n'o�re aujourd'hui que très peu d'opportunités d'évolutivité et de réutilisation,d'où un développement coûteux.

L'utilisateur en marge des approches. Les solutions existantes concentrent sou-vent leurs approches sur le domaine d'application (section 3.3.1), ou encore la plate-forme d'exécution (section 2.2.1). La notion d'utilisateur est alors trop souvent délais-sée. Or, il existe aujourd'hui une variété de programmeurs potentiels dans un mêmedomaine. Ces derniers di�èrent, entre autres, par leurs rôles au sein de l'organisation,leurs compétences, ou encore leur niveau d'expertise relatif au domaine. Cette diver-sité impacte sur leurs besoins en termes de solutions de programmation (section 3.4.2).Ainsi, dans le cas de la Téléphonie sur IP, les services peuvent être programmés pardes pro�ls complètement di�érents, allant du simple utilisateur à l'administrateur d'unPABX1, en passant par l'opérateur téléphonique. Cette diversité de pro�ls entraîne unbesoin de solutions de programmation di�érentes.

Rendre accessible la programmation à des non-informaticiens pose un certain nombrede problèmes, notamment relatifs au domaine et à ses propriétés, à la complexité dudéveloppement de solutions adaptées, et aux multiples pro�ls des programmeurs dansle domaine à prendre en compte. Il apparaît donc évident qu'une architecture répon-dant à toutes ces contraintes et permettant de développer simplement des solutions deprogrammation haut niveau est d'un réel intérêt. La partie II de ce document présentenotre approche pour y parvenir.

1Un Private Automatic Branch eXchange ou PABX est un commutateur téléphonique privé, servantà relier les postes téléphoniques d'un établissement (lignes internes) avec le réseau téléphonique public.

Deuxième partie

Approche proposée

55

Chapitre 6

Présentation de l'approche

Le domaine de la programmation est aujourd'hui en pleine mutation. Face aux ex-perts en programmation, langages et autres technologies, se dresse un nouveau type dedéveloppeur, monsieur tout-le-monde. De plus en plus de programmes sont écrits pardes novices, désireux d'utiliser la programmation comme un outil qui pourrait les aiderdans leurs métiers. Permettre de programmer sans être programmeur, voilà l'un desdé�s importants du génie logiciel. Néanmoins, à l'autre extrémité du spectre, les pro-grammeurs expérimentés ne peuvent, quant à eux, se contenter de solutions restreintes.Leur activité requiert bien souvent une solution expressive, sans pour autant tomberdans une approche généraliste.

Les travaux présentés dans cette thèse visent à rendre la programmation plus ac-cessible à ces nouveaux développeurs, tout en répondant à la diversité des besoins enprogrammation due à de multiples pro�ls de programmeurs au sein d'un même domained'application. Il s'agit également de faciliter le développement des solutions logicielleshaut niveau. Ce chapitre présente la vision globale de l'approche que nous proposonsa�n de répondre aux problèmes suscités par cette nouvelle demande et énoncés dans lechapitre précédent.

6.1 L'approche proposée

L'approche proposée dans cette thèse [LCM07] repose sur l'utilisation de langagesdédiés et sur une architecture en couches des langages, illustrée par la �gure 6.1. Notreapproche en couches consiste à introduire deux niveaux de langages dédiés : un lan-gage dédié orienté modélisation (Domain-Speci�c Modeling Language ou DSML) etun langage dédié orienté programmation (Domain-Speci�c Programming Language ouDSPL1). Cette dichotomie des DSL s'appuie sur la caractérisation des besoins des déve-loppeurs énoncée au chapitre précédent. Ces langages évoluent à des niveaux d'abstrac-tion di�érents, et sont adaptés à leurs utilisateurs. Le langage dédié de plus haut niveau(DSML), possédant les plus fortes abstractions, est implémenté dans un langage dédié

1Dans ce document, nous utiliserons de manière indi�érente le terme langage dédié orienté program-

mation et DSPL.

57

58 Présentation de l'approche

de plus bas niveau (DSPL), plus expressif que le DSML et plus à même de résoudre desfamilles de problèmes complexes. Le DSPL est ensuite compilé dans une implémentationparticulière.

ProgrammationModélisation

Implémentation

Compilation

Programmation

DSML

DSPL

Implémentation

Vérifications

Compilation

Vérifications

DOMAINE

Fig. 6.1 � Vue générale de notre approche

Cette architecture en couches permet d'élever le niveau d'abstraction, mais aussi,grâce à l'introduction d'une couche langage intermédiaire (DSPL), de combler signi�-cativement le fossé entre des modèles et leurs implémentations. En utilisant le DSPLcomme une interface entre ces deux mondes, le processus de développement de solutionshaut niveau se trouve fortement simpli�é. De plus, cette architecture introduit au seindu domaine une distinction des approches entre la modélisation et la programmation desolutions. Cette séparation permet de mettre à disposition de tous les types d'utilisa-teurs une solution adaptée, expressive pour les experts en programmation via le DSPL,et simple et haut niveau pour les experts du domaine via le DSML. Ainsi, le langage dé-dié de programmation peut être utilisé directement par un programmeur pour produireune variété importante d'applications plus ou moins complexes. Le DSPL peut égale-ment être caché de l'ensemble des développeurs et ne servir simplement que de langageintermédiaire lors de la génération de code. Cette utilisation di�érente du DSPL dépenddu domaine d'application, des pro�ls des programmeurs et de leurs besoins.

La distinction entre la modélisation et la programmation de solutions permet àchaque couche de spécialiser la compilation mais aussi la véri�cation de propriétés (�gure6.1). Tout d'abord, elle permet de simpli�er le processus de compilation en réduisantla distance entre le modèle et son implémentation (réduction du pas de compilation).L'approche permet, en e�et, à un DSML de se concentrer uniquement sur la logiquedu programme et de reposer sur un DSPL existant, qui lui, expose les constructionsclés et les opérations utiles lors d'une implémentation. Ainsi, la compilation du DSML

L'approche proposée 59

est seulement dédiée à la projection de la logique de l'application dans les termes duDSPL. La compilation du DSPL est, quant à elle, dédiée à la génération des détailsd'implémentation. Cette stratégie est similaire à celle utilisée pour la compilation delangages de haut niveau comme les langages fonctionnels (e.g., [DF98]). Cette mêmestratégie est utilisée en génie logiciel ; elle permet de structurer un système complexe encouches logicielles (e.g., [GS96]).

La distinction entre la modélisation et la programmation permet également d'éta-ger la véri�cation de propriétés. Les propriétés liées au domaine (e.g., interaction decomportements entre plusieurs services) sont véri�ées au niveau du DSML alors quecelles liées à la programmation (e.g., contrôle de la consommation de ressources dansune itération non bornée) le sont au niveau du DSPL. Ainsi, la spécialisation de chaquecouche permet de simpli�er le processus de véri�cation.

En�n, de par la nature du DSML mais aussi la présence du DSPL intermédiaire,les processus de compilation et de véri�cation du langage de modélisation deviennenteux-aussi haut niveau. Il est alors plus facile de réutiliser des outils de génération deprogrammes, ce qui facilite le développement, mais aussi l'évolutivité du DSML. Restele problème de l'implémentation du DSPL. A�n de réduire son coût, l'approche proposeégalement une méthodologie permettant de simpli�er le processus de compilation dulangage. Cette méthodologie de développement de compilateurs de DSL est, elle aussi,centrée sur l'utilisation de techniques de génération de programmes. Ceci permet làencore de faciliter le développement du compilateur, mais aussi son évolution ou sondébogage.

L'utilisation du langage dédié de programmation comme pivot de notre architecturenous permet de gérer la variabilité des solutions haut niveau o�ertes aux développeurs.En e�et, le DSPL permet de réutiliser une partie importante de la connaissance dudomaine mais aussi de l'implémentation. Ainsi, il expose des constructions clés quiabstraient les variations des plates-formes sous-jacentes, facilitant le développement delangages de modélisation. Parce qu'il est dédié au domaine, un DSPL o�re égalementdes abstractions haut niveau qui sont proches des concepts du domaine. Néanmoins,ces abstractions sont assez générales pour permettre à divers DSML d'être implémen-tés. Il devient alors possible de fournir plusieurs solutions de modélisation di�érentes,ciblant des utilisateurs avec des besoins di�érents. Du fait de l'existence d'une variétéde préférences et de contraintes pouvant être exprimées par les experts, une variété deDSML peut être envisagée, o�rant divers paradigmes (textuels ou visuels), degrés d'ex-pressivité ou encore abstractions. De même, l'utilisation du DSPL comme point centralde notre architecture permet de fournir simplement plusieurs implémentations possiblespour un même DSML. Ce langage étant orienté programmation, un programme écritdans un DSPL contient les détails nécessaires à la génération automatique de son im-plémentation dans un environnement d'exécution. Ainsi, l'architecture proposée permetde factoriser, capitaliser et automatiser les étapes de conception, a�n de simpli�er ledéveloppement et l'évolution de solutions logicielles.

L'approche proposée répond à l'ensemble des problématiques énoncées dans ce do-cument. Elle est principalement basée sur la dichotomie entre les langages dédiés de


programmation et de modélisation. Si cette dichotomie re�ète bien la diversité des be-soins des utilisateurs, il n'existe cependant pas aujourd'hui de moyen permettant decaractériser cette di�érence. Toutefois, l'étude de l'existant nous montre que cette di-chotomie est bien présente.

6.2 Une dichotomie bien réelle

La distinction entre les langages de programmation et de modélisation est aujour-d'hui davantage un constat qu'un principe tel qu'énoncé précédemment. La limite entreles deux mondes n'est pas simple à entrevoir et reste souvent subjective. Pourtant, l'étatde l'art sur cette question con�rme cette di�érence avérée (e.g., [Coo04]). Ainsi, cettedichotomie des solutions se retrouvent à la fois au sein de la communauté des langageset de celle de la modélisation.

Considérons tout d'abord la communauté des langages. Les langages dédiés ont étéétudiés dans de nombreux domaines de l'Informatique. Généralement, un DSL o�re desnotations et des abstractions qui sont spéci�ques à un domaine donné. Cependant, selonle domaine, un DSL peut ou non être orienté programmation. Beaucoup de DSL déve-loppés par des chercheurs en langages de programmation nécessitent des compétencesen programmation. Les exemples incluent PADS, un langage pour le traitement de don-nées [FG05], ou encore MAWL, un langage pour les services Web interactifs [ABBC99].Cependant, comme mentionné précédemment, des DSL sont créés dans de nombreuxautres domaines que l'Informatique. Ils sont généralement centrés sur l'utilisateur etla modélisation de solutions, nécessitant des connaissances dans le domaine, mais pasd'expertise en programmation. Des exemples de tels langages incluent Risla, un lan-gage pour la description de produits �nanciers [ADR95], ou encore CML, un langage degestion d'informations moléculaires en chimie [MR97]. Cette séparation entre program-mation et modélisation existe également au niveau de la communauté de modélisation.Le concept de langage dédié de modélisation (DSML) est un concept primordial detoutes les approches IDM [GTK+06]. Le fait d'avoir introduit la notion de modélisationau niveau de ces langages dédiés particuliers montre bien le désir de se di�érencier del'approche DSL. Ainsi, un grand nombre de langages de modélisation apparaît dans lalittérature, parmi lesquels SysML (Systems Modeling Language) [Sys05], WebML (WebModeling Language) [CFB00], ECSL (Embedded Control Systems Language) [BGK+06],ou encore BPML (Business Process Modeling Language) [TSPB02].

Il n'existe aujourd'hui aucune dé�nition établie de la notion de langage de modéli-sation ou de programmation. De plus, un manque de clarté autour de ces deux termes anourri pendant les dernières années un certain nombre d'idées fausses. Ainsi, consensuel-lement, tous les langages de programmation doivent être textuels, et par conséquent leslangages de modélisation doivent être graphiques. Mais ce critère de di�érenciation estsuper�ciel. Si les langages de programmation sont générallement représentés selon unenotation textuelle, cela est en grande partie dû à des raisons historiques. Des exemplesde langages de programmation graphiques existent. L'un des plus connus est le langageLego Mindstorms, un produit utilisé pour construire les robots [CE00]. Il dé�nit des élé-

Une dichotomie bien réelle 61

ments graphiques a�n de réaliser des opérations arithmétiques, mais aussi de créer desstructures de contrôle de programmes comme les boucles, les branches conditionnelles,ou encore les structures. L'inverse n'est pas non plus la panacée ; un langage textueln'est pas forcément un langage de programmation. XML est un langage textuel bienconnu, par exemple, et peu de personnes le considèrent aujourd'hui comme un langagede programmation. De manière similaire, parce que la plupart des langages de modéli-sation ont historiquement utilisés une notation graphique, il est souvent supposé, queles langages de modélisation doivent être graphiques. De plus, les langages de modéli-sation graphiques ont souvent été utilisés pour la documentation et certaines tentativesont échoué à générer automatiquement du code. Cet héritage a créé une idée fausseselon laquelle les langages de modélisation graphiques ne sont pas un moyen e�cacede programmation. Cependant, ce type de langages peut utiliser une grande variété denotations et, dans certains contextes, ils se trouvent être de bons moyens de générationde code [TK05].

La littérature fait état aujourd'hui d'une di�érence entre les langages de program-mation et les langages de modélisation, sans toutefois clairement l'identi�er ni même lacaractériser. Ainsi, la frontière entre la modélisation et la programmation de solutionsest seulement une a�aire de niveau d'abstraction. Les langages dédiés de modélisa-tion (DSML) sont simplement des DSL de plus haut niveau que les langages dédiésde programmation (DSPL). C'est dans ce sens que nous interprétons ces concepts etque nous les utilisons dans la suite de ce document. Si cette interprétation peut pa-raître subjective, l'étude de divers domaines d'application (e.g., création d'interfacesgraphiques, description de matériel, ou encore �ltrage de courrier électronique) montreque cette dichotomie est réelle dans la pratique. Le tableau 6.1 présente des exemples.Dans chacun des domaines �gurant dans ce tableau, il est possible de distinguer deslangages dédiés de programmation et des langages dédiés de plus haut niveau, o�rantdes niveaux d'abstraction plus proches de la pensée des développeurs. Par exemple, ledomaine du �ltrage de courrier électronique expose des solutions de programmationayant des niveaux d'abstractions di�érents. Les programmeurs expérimentés peuventutiliser le langage à script dédié Sieve, nécessitant des connaissances en programmation(e.g., manipulation de structures de contrôle ou encore d'expressions régulières, notionde typage). Pour les développeurs non-informaticiens, des langages à la fois textuels etgraphiques, respectivement AvelSieve ou Ingo, permettent de simplement exprimer sesbesoins, sans connaissance particulière en programmation. Ainsi, de la même manièreque nous le faisons dans ce document pour le domaine de la création de services deTéléphonie sur IP, il serait tout à fait possible d'appliquer notre approche à tous cesdomaines et de compiler les DSML dans les termes de leur DSPL respectif.

Dans le reste de ce document, nous présentons une mise en ÷uvre de l'architectureque nous venons d'introduire. Pour cela, le chapitre 7 revisite le domaine de la créationde services de Téléphonie sur IP et introduit un langage dédié de modélisation (DSML)et un langage dédié de programmation (DSPL), respectivement VisuCom et SPL. Leschapitres suivants exposent les béné�ces de l'introduction de notre DSPL (SPL) à lafois d'un point de vue du domaine et d'un point de vue de l'implémentation. D'une


STEP (Scripting Language for Embodied Agents), XSTEPVRML (Virtual Reality Markup Language)Modélisation de la réalité virtuelle

CookSwing, SwiXML, SwingML, JellySwingSWUL (SWing User interface Language)Création d’interfaces graphiques

TDML (Timing Diagrams Editor and Analysis), LogSim, MatlabVHDL (Very high speed integrated circuit Hardware Description Language)Description de matériel

Mulberry, Ingo, AvelSieve, SmartSieve, WebSieveSieveFiltrage de courrier électronique

ActiveBPEL, WS-CDL (Web Services Choreography Description Language), BPML (Business Process Modeling Language)

BPEL (Business Process Execution Language)Modélisation de processus métier

Langages Dédiés de Modélisation - DSMLsLangage Dédié de Programmation - DSPLDomaine

Tab. 6.1 � Illustration de la distinction DSPL-DSML

part, la nature spéci�que au domaine de SPL facilite grandement l'implémentation dedeux DSML di�érents (CPL et VisuCom), fournissant des concepts de programmationdédiés, et cachant les détails d'implémentation. D'autre part, ce DSPL est porté sur laplate-forme de téléphonie JAIN SIP ; il est en outre tout à fait envisageable de le portersur d'autres environnements (e.g., Asterisk ou encore Live Communications Server).Ainsi, le chapitre 8 décrit la méthodologie de développement de compilateurs de langagesdédiés et présente les résultats de son application sur SPL ciblant l'environnement JAINSIP. Le chapitre 9 évalue, quant à lui, les avantages de notre architecture en termes defacilité de compilation des DSML et de véri�cation de propriétés du domaine.

Chapitre 7

Application à la Téléphonie sur IP

Ce chapitre illustre notre approche dans le domaine de la Téléphonie sur IP appli-cative. Il présente les résultats de notre analyse de domaine et met en avant le besoind'une approche répondant aux principes énoncés dans les chapitres précédents. Pourcela, il montre la complexité liée à l'implémentation de services de Téléphonie sur IP,mais aussi la di�érence de points de vue des approches existantes du domaine, qui tendà élargir le fossé déjà présent entre la modélisation et l'implémentation de solutions.Pour répondre à ces problématiques, le chapitre introduit alors deux langages dédiésque nous avons développés, SPL et VisuCom, a�n d'illustrer notre architecture. Ainsi,nous présentons les béné�ces de notre approche en utilisant SPL comme couche pivot(DSPL), et VisuCom et CPL comme langages de modélisation (DSML).

7.1 Analyse du domaine

Le domaine de la création de services de Téléphonie sur IP fait aujourd'hui face àune véritable scission entre deux mondes : celui de la modélisation de solutions, symbo-lisé par CPL, et celui de l'implémentation, symbolisé par l'interface de programmationJAIN SIP. Cette division représente un frein au développement logiciel tel que présentéau chapitre précédent. De plus, de par la nature distribuée de la téléphonie et le besoinde connaissance dans de nombreux domaines, l'implémentation de services avec une so-lution du type JAIN SIP peut rapidement devenir un processus complexe, à la portée depeu de programmeurs. Cette section présente les résultats de notre analyse du domainede la téléphonie et de l'étude de diverses plates-formes de programmation [BCC+04].

7.1.1 Une programmation trop complexe

La programmation de services de Téléphonie sur IP reste aujourd'hui une tâchedélicate, même pour un programmeur expérimenté. Elle requiert, en e�et, de nombreusescompétences que peu d'utilisateurs possèdent. Plusieurs plates-formes de téléphonie SIPo�rent une interface de programmation pour le développement de services. Ces API sontbasées sur des langages de programmation généralistes comme C, Java ou encore C#.Cette section donne un aperçu de la complexité de ce type d'interface en implémentant

63

64 Application à la Téléphonie sur IP

un service via l'interface de programmation JAIN SIP, qui est aujourd'hui l'une dessolutions de programmation les plus connues dans le domaine.

Considérons un service simple, que nous nommerons le service Compteur, qui gèrele compteur des appels ayant été transférés vers une secrétaire, lorsque l'utilisateur as-socié au service ne peut être joint. Ce compteur est initialisé à zéro lorsque l'utilisateurs'enregistre auprès du serveur d'enregistrement (a�n de lui signi�er sa présence), incré-menté lorsqu'un appel est transmis à la secrétaire, et enregistré lorsque l'utilisateur sedéconnecte. La �gure 7.1 montre les principales étapes de l'implémentation de ce ser-vice Compteur en utilisant l'interface de programmation JAIN SIP. Les blocs de codeBi sont utilisés par la suite pour expliciter le service, mais également dans la section 7.2pour faciliter la comparaison avec notre langage dédié de programmation (SPL).

Un service JAIN SIP implémente l'interface SipListener, qui est constituée des mé-thodes processRequest pour la gestion des requêtes, processResponse pour la gestiondes réponses, et processTimeout pour la gestion des temporisations (timeouts) levéespar la plate-forme de téléphonie. La structure de ces méthodes vise à spéci�er le compor-tement du service en fonction des requêtes SIP à traiter et des réponses associées. Dansnotre exemple Compteur, les méthodes processRequest (ligne 11) et processResponse(ligne 47) spéci�ent le traitement des requêtes et des réponses des méthodes REGISTER etINVITE du protocole (respectivement, lignes 15 et 36 pour la méthode processRequest,et lignes 70 et 57 pour la méthode processResponse). La méthode processTimeout

(ligne 76) implémente seulement le traitement des timeouts concernant la méthode SIPREGISTER (ligne 78), correspondant au cas où le temps d'enregistrement de l'utilisateursur la plate-forme de téléphonie a expiré.

La di�culté de ce service consiste à maintenir le compteur, qui doit être accessiblelors du traitement de l'ensemble des messages SIP (requêtes et réponses) associés à unenregistrement particulier de l'utilisateur. En e�et, l'API ne fournit pas de moyen d'asso-cier un état à un enregistrement SIP1. De plus, ce service peut être partagé par plusieursutilisateurs, empêchant l'utilisation de variables globales partagées. En conséquence, leprogrammeur doit explicitement implémenter cette association. Ainsi, lorsque le servicereçoit une requête REGISTER pour un utilisateur qui n'est pas encore enregistré (bloc B1de la �gure 7.1), il crée un objet de la classe State (bloc B0) qui représente le compteurpour cet enregistrement. Cet objet State est enregistré dans un environnement globalenv sous un identi�ant ident qui est unique pour l'enregistrement. Ensuite, lors del'arrivée d'une requête INVITE pour un utilisateur enregistré (ligne 36-37), la méthodeprocessRequest transfère la requête à l'utilisateur (ligne 38-39). À la réception de laréponse, la méthode processResponse exécute le code comprenant les blocs B3 et B4.Le bloc B3 gère le cas où une réponse avec un code d'erreur est reçue (ligne 58), indi-quant que l'utilisateur n'a pas pu prendre l'appel. Le compteur associé à l'utilisateur estalors récupéré depuis l'environnement env (ligne 55-56) et incrémenté (ligne 59) avantde transférer l'appel sur la secrétaire. Le bloc B4 traite, quant à lui, le cas normal oùl'utilisateur décroche son téléphone. En�n, lorsque l'utilisateur annule son enregistre-

1Un enregistrement SIP correspond à la période pendant laquelle un utilisateur est associé à unterminal SIP, lui permettant de prendre des appels.

Analyse du domaine 65

1. class State implements Lib.State {2. private int count;3. public State() {}4. void setCounter (int x) { count = x; }5. int getCounter() { return count; }6. }7.8. public class Counter implements SipListener {9. Lib lib; 10. [...]11. public void processRequest (RequestEvent requestEvent) {12. Request rq_request = requestEvent.getRequest();13. SipProvider rq_sipProvider = (SipProvider)requestEvent.getSource();14. String method = rq_request.getMethod();15. if (method.equals (Request.REGISTER)) {16. if (!lib.registrar.hasExpiresZero (rq_request)) {17. if (!lib.registrar.hasRegistration (rq_request)) {18. State state = new State();19. int ident = lib.env.getId (rq_request);20. lib.env.setEnv (ident, state);21. state.setCounter (0);22. rq_sipProvider.sendRequest (rq_request);23. } else {24. rq_sipProvider.sendRequest (rq_request);25. }26. } else if (lib.registrar.hasRegistration(rq_request)){27. int ident = lib.env.getId (rq_request);28. State state = (State)lib.env.getEnv (ident);29. lib.local.log (state.getCounter());30. lib.env.delEnv (ident);31. rq_sipProvider.sendRequest (rq_request);32. } else {33. rq_sipProvider.sendRequest (rq_request);34. }35. }36. if (method.equals (Request.INVITE)) {37. if (lib.registrar.hasRegistration (rq_request)) {38. ClientTransaction ct = rq_sipProvider.getNewClientTransaction(rq_request);39. ct.sendRequest (rq_request); 40. } else {41. rq_sipProvider.sendRequest (rq_request);42. }43. }44. [...]45. }46.47. public void processResponse (ResponseEvent responseEvent) {48. ClientTransaction rs_ct = responseEvent.getClientTransaction();49. Response rs_response = responseEvent.getResponse();50. int rs_responseCode = rs_response.getStatusCode();51. SipProvider rs_sipProvider = (SipProvider) responseEvent.getSource();52. if (rs_ct != null) {53. Request rs_request = rs_ct.getRequest();54. String method = rs_request.getMethod();55. int ident = lib.env.getId(rs_request);56. State state = (State)lib.env.getEnv(ident);57. if (method.equals (Request.INVITE)) {58. if (rs_responseCode >= 300) {59. state.setCounter (state.getCounter() + 1);60. AddressFactory addressFactory = lib.getAddressFactory(); 61. SipURI sipURI = addressFactory.createSipURI ("secretary", "company.com");62. rs_request.setRequestURI (sipURI); 63. rs_sipProvider.sendRequest(rs_request);64. } else {65. rs_ct.sendResponse (rs_response);66. }67. } else {68. rs_sipProvider.sendResponse(rs_response);69. } 70. } else {71. rs_sipProvider.sendResponse(rs_response);72. }73. [...]74. }75.76. public void processTimeout (TimeoutEvent timeOutEvent) {77. Timeout timeout = timeOutEvent.getTimeout();78. if (timeout.equals (Timeout.REGISTER)){79. int ident = timeout.getId();80. State state = (State)lib.env.getEnv (ident);81. local.log (state.getCounter());82. lib.env.delEnv (ident);83. }84. }85. }

B0

B1

B2_1

B3

B4

B2_2

Fig. 7.1 � Le service Compteur écrit en JAIN SIP


ment (bloc B2 1) ou que ce dernier expire (bloc B2 2), le compteur est sauvegardé etsupprimé de l'environnement env.

Certains traitements peuvent nécessiter de la part de la plate-forme de téléphonie degarder un état bien particulier, a�n de lui permettre d'associer une réponse à sa requête.La transaction2 est alors dite à état (stateful), par opposition à sans état (stateless).Mais cette association a un coût au niveau de la plate-forme. C'est pourquoi, a�n d'amé-liorer les performances, les transactions du service sont sans état (e.g., ligne 31) quandcela est possible. Les transactions à état (e.g., lignes 38-39) sont cependant nécessaireslorsque, comme dans notre exemple, certaines données dé�nies dans le traitement de larequête sont utilisées dans le traitement de la réponse. Ce type de transaction permetégalement la retransmission des messages SIP par la plate-forme de téléphonie, assurantque toutes les requêtes obtiennent une réponse. Dans le cas d'un service partiellementsans état, qui ne garantit donc pas cette dernière propriété, les requêtes auxquellesle service ne répond pas sont automatiquement retransmises par l'agent utilisateur del'appelant. De telles retransmissions ré-invoquent le service, ce qui peut avoir des réper-cutions sur son comportement. Le bloc B3 de notre exemple incrémente un compteur ettransmet la requête à la secrétaire. Dans ce cas, même si aucun traitement n'est e�ectuésur le compteur par la suite, la transaction doit être à état parce que le traitement dela requête INVITE modi�e le compteur, et n'est donc pas idempotent.

L'exemple Compteur montre clairement la di�culté de développer des services mêmesimples avec les approches existantes du type JAIN SIP. Ces approches étant basées surun langage généraliste, il n'existe aucun support pour guider le programmeur à tra-vers les méandres du protocole et de l'API. La séparation du service selon des pointsd'entrée distincts pour le traitement de requêtes et de réponses obscurcit grandementles �ots de contrôle et de données à travers les di�érentes transactions. Ainsi, l'API nere�ète absolument pas les concepts qui existent dans la gestion des communications duprotocole SIP (e.g., transaction, dialogue3, ou encore enregistrement). Ce manque dedécomposition, notamment au niveau du dialogue et de l'enregistrement, entraîne unegestion complexe de l'état.

Même pour un programmeur averti, l'implémentation de services de Téléphonie surIP est aujourd'hui une tâche di�cile. Elle demande une parfaite maîtrise d'un ensemblede technologies, où le manque de garde-fous fait de chaque erreur logicielle une me-nace pour la plate-forme de téléphonie. Il devient donc indispensable d'élever le niveaud'abstraction des solutions de programmation. Comme dans de nombreux domaines, latéléphonie fait face à une divergence de points de vue pour répondre à ce besoin. Auxexperts en téléphonie s'opposent les experts en implémentation.

2Une transaction consiste à associer une réponse à sa requête (e.g., une requête REGISTER et saréponse).

3Un dialogue est une relation SIP entre deux entités agents utilisateurs qui persiste pour une certainedurée. Un dialogue est initié par une requête INVITE et con�rmé par une requête ACK. Le dialoguepersiste jusqu'à ce que l'une des parties envoie une requête BYE.

Analyse du domaine 67

7.1.2 Des approches divergentes

Le problème posé par la montée en abstraction est celui de la distance qui séparela modélisation d'une solution logicielle de son implémentation. D'un point de vue im-plémentation, les approches sont guidées par le désir d'élever le niveau d'abstractiondes technologies logicielles. D'un point de vue modélisation, les e�orts visent à dévelop-per des projections entre des modèles plus ou moins abstraits et des implémentations.Chaque démarche possède ainsi ses propres terminologies et méthodes. De ce fait, unecertaine incompréhension existe entre les experts des deux mondes, ce qui représente unfrein au développement de services de Téléphonie sur IP tel que présenté au chapitreprécédent. Cette section illustre le problème de la séparation entre conception et implé-mentation, justi�ant ainsi davantage le choix du domaine de la création de services deTéléphonie sur IP pour la mise en ÷uvre de notre approche logicielle.

Implémentation de services. L'approche implémentation est ascendante (bottom-up) ; elle est similaire à la construction d'une maison, en apportant petit à petit desbriques techniques qui permettent de structurer l'édi�ce à produire. Dans le cas de laTéléphonie sur IP, cela consiste à élaborer des interfaces de programmation, ou descouches logicielles, qui abstraient les détails du protocole de signalisation (SIP dansnotre contexte), ou encore de divers protocoles multimédias (e.g., le protocole de com-munication RTP - Real-Time Transport Protocol [Sch96]). D'autres exemples peuventêtre cités. Les Servlets SIP proposent un framework qui encapsule une architectureclient-serveur, nécessaire pour faire face à la nature distribuée des plates-formes detéléphonie modernes. La logique du service peut également reposer sur une librairieétendue pour gérer la variété des paramètres d'un appel (e.g, appelant, destinataire,heure). Cependant, comme illustré par l'interface JAIN SIP, cette approche ne permetpas de répondre à toutes les attentes. Sa complexité, sa généricité mais aussi son manquede véri�cations de cohérence concernant, par exemple, les étapes intermédiaires d'uneredirection d'appel, rendent di�ciles son apprentissage et son utilisation. L'entrelace-ment de la logique avec des détails d'implémentation empêche également d'assurer lespropriétés du domaine. De plus, cette approche reste spéci�que à un environnementd'exécution (Java dans le cas de JAIN SIP ou C# dans le cas de la solution de Mi-crosoft) et tout portage de la technologie sur une autre plate-forme est inenvisageable.En�n, cette approche est uniquement destinée à un ensemble réduit de programmeursexpérimentés.

Modélisation de services. À l'autre extrémité du spectre se trouve l'approche demodélisation, qui peut être vue comme descendante (top-down). Comme toute approchede ce type, elle repose sur un langage de modélisation dédié et un générateur de codespéci�que à une implémentation. Si l'expérience montre que sa mise en ÷uvre peutêtre béné�que, cette démarche, symbolisée par le langage CPL, présente certains pointsfaibles qui empêchent souvent son acceptation industrielle. Le principal problème d'uneapproche comme CPL se situe au niveau de sa spéci�cité, à la fois concernant la dé-�nition du domaine et le type d'utilisateur visé. Une solution trop spéci�que limite


non seulement son expressivité, mais aussi son adoption et son utilisation. De plus, lanature dédiée du générateur de code �xe la solution à un environnement d'exécution,introduisant souvent de fortes dépendances. Ceci restreint un peu plus les conditionsd'utilisation de la solution. Ainsi, le portage sur une autre plate-forme nécessite de pro-fonds changements au sein du générateur. Un autre problème de la démarche reposesur son niveau d'abstraction. Essayer d'élever le niveau d'abstraction d'un langage apour e�et d'augmenter la distance entre le domaine et l'implémentation, ajoutant dela complexité au générateur de code. Cette situation rend ce dernier di�cile à évoluer,bloquant à la fois le langage et le générateur. À titre d'exemple, l'introduction d'un nou-veau paramètre dans le traitement d'un appel en CPL peut impliquer des changementsà des niveaux d'abstraction arbitrairement bas au sein de la plate-forme.

7.1.3 Bilan

Le téléphone est aujourd'hui une ressource indispensable pour tous les usagers, etreprésente souvent le principal lien commercial de nombreuses organisations avec leursclients. L'introduction de la programmation au sein des plates-formes téléphoniques sus-cite donc de nombreuses interrogations relatives à la �abilité des solutions. Ces questionsont été partiellement identi�ées par Lennox [Len04]. Ce dernier présente une analyse dudomaine de la programmation de services de Téléphonie sur IP en se focalisant sur lesproblèmes liés à l'exécution des services. Ainsi, il s'intéresse à la manière d'exécuter lalogique, où elle se situe (agent utilisateur ou serveur d'applications), ainsi qu'aux inter-actions entre le service et l'environnement. Son analyse ne tient compte ni des besoinsen programmation des utilisateurs ni de l'étude des solutions existantes. Conscient duconstat que l'exécution de services doit se faire de manière �able et que le développe-ment de services de Téléphonie sur IP est un processus complexe, il propose une solutionde programmation restreinte, CPL.

Contrairement à Lennox, notre analyse du domaine est issue de l'étude de diversesplates-formes de signalisation [BCC+04]. Elle couvre une variété de solutions de pro-grammation comme, par exemple, Vocal (Vovida) [DJK02], SIP Express Router (SER)[Kut03], Live Communication Server (Microsoft) [Mic04], et AppEngine (DynamicSoft).Ces plates-formes fournissent un environnement plus ou moins complet de développe-ment d'applications SIP, et exposent des avantages di�érents. Les conclusions de notreétude montrent qu'une solution unique et restreinte comme CPL ne peut répondre àl'ensemble de la problématique de développement de services de Téléphonie sur IP. Ene�et, les services de téléphonie peuvent être programmés par des pro�ls très di�érents,allant du simple utilisateur à l'administrateur d'un PABX, en passant par l'opérateurtéléphonique. Cette diversité de développeurs entraîne une multiplicité des besoins desolutions de programmation, en termes de niveau d'abstraction et d'expressivité. Ce-pendant aucune approche existante ne permet de fournir un si large spectre. De plus,se posent les problèmes du développement de ces solutions et de la distance qui sé-pare les abstractions du domaine de leurs implémentations. Ces problèmes empêchentaujourd'hui les approches de satisfaire l'ensemble des besoins des développeurs.

SPL, un langage dédié de programmation 69

Notre étude montre également que la complexité de la téléphonie rend di�cile d'as-surer les propriétés métiers du domaine. Ces propriétés interviennent à des niveauxdi�érents : (1) le domaine de la téléphonie, (2) le protocole de signalisation, (3) laplate-forme de signalisation SIP, et (4) les services de téléphonie. L'une de ces proprié-tés concerne, par exemple, la terminaison des appels en un temps borné. Véri�er detelles propriétés est une étape majeure pour garantir l'exécution correcte du service.La gestion des ressources est une autre préoccupation importante qui peut in�uer surla �abilité des services. Elle peut également répondre à des besoins diverses de la partdes programmeurs comme le contrôle d'admission d'un service, la con�guration de laplate-forme, ou encore la dé�nition de politiques de facturation.

Le domaine de la création de services de Téléphonie sur IP illustre donc parfaitementles problématiques évoquées dans ce document. Les approches existantes de ce domaineéchouent à simpli�er le développement logiciel et augmenter la productivité. De plus,aucune solution ne prend en compte l'ensemble des besoins exprimés par les di�érentespopulations de programmeurs de services. Il est nécessaire de faire un choix entre l'ex-pressivité et la �abilité. En�n, la téléphonie possède des propriétés critiques qu'il estindispensable d'assurer. Ce domaine semble donc être un très bon candidat pour illustrernotre approche. Les sections suivantes introduisent un langage dédié de programmation(DSPL) et un langage dédié de modélisation (DSML), nommés respectivement SPL etVisuCom.

7.2 SPL, un langage dédié de programmation

Cette section présente SPL (Session Processing Language) [BCL+06a], un DSPLdont le but est de faciliter le développement de services de Téléphonie sur IP sanssacri�er la �abilité du service. Pour cela, SPL repose sur un environnement d'exécutionde logique de service pour SIP (SIP Service Logic Execution Environment ou SIP-SLEE). Cet environnement forme une machine abstraite pour le langage. Il permetd'identi�er les objets et les opérations métiers du domaine d'application sur lesquelsest basé le DSL. SPL est le résultat d'une analyse approfondie du domaine suite àl'étude de diverses plates-formes de téléphonie. Parce qu'il o�re des abstractions hautniveau, il libère le programmeur des détails d'implémentation et de la complexité destechnologies sous-jacentes. SPL garantit des propriétés critiques qui ne peuvent pas êtrevéri�ées dans des langages généralistes comme Java ou C, en introduisant des conceptsdédiés au domaine de la téléphonie et des restrictions sémantiques.

7.2.1 L'environnement d'exécution

A�n de pouvoir déployer des services SPL, le serveur d'applications de la plate-formede téléphonie est décomposé en deux composants majeurs, comme illustré à la �gure7.2 : un serveur SIP qui permet de recevoir et envoyer des messages SIP, et un envi-ronnement d'exécution SIP-SLEE qui o�re au programmeur une interface haut niveaudédiée au développement de services SPL. Une contribution clé de cet environnementest l'introduction d'une notion spéci�que au domaine, appelée session, qui représente


un framework de conception de services. Une session est constituée d'opérations et d'unétat.

Opérations. Pour élever le niveau d'abstraction de la programmation de services,l'environnement SIP-SLEE est chargé de fournir un ensemble d'opérations haut niveaucorrespondant aux concepts du domaine. Pour cela, il introduit des méthodes de contrôlepour lesquelles le service SPL dé�nit des gestionnaires (handlers), chargés de spéci�erla logique à appliquer pour chacune des méthodes à prendre en compte. À la réceptionde messages SIP et d'évènements (�gure 7.2), l'environnement associe des méthodes decontrôle dont le traitement est donné par le service SPL. Ces méthodes représententune interface SIP uniforme dédiée à la programmation de services.

Service SPL

SIP - SLEE

Serveur SIP

messages SIP

évènements messages SIP

méthodesde contrôle

résultats

Fig. 7.2 � L'environnement SIP-SLEE et les méthodes de contrôle

Les méthodes de contrôle correspondent à des requêtes SIP du protocole, des re-quêtes ra�nées et des évènements du serveur SIP. Une requête SIP du protocole estpropagée telle quelle par le SIP-SLEE si son sens est non-ambigu (e.g., la requête ACK).Certaines requêtes sont cependant sensibles au contexte et nécessitent une interpréta-tion et un ra�nement e�ectués par l'environnement SIP-SLEE. À titre d'exemple, larequête INVITE est utilisée soit pour initier un dialogue, soit pour modi�er les caracté-ristiques d'un dialogue existant. Ainsi, l'environnement ra�ne la requête INVITE soit enméthode de contrôle INVITE dans le premier cas, soit en méthode de contrôle REINVITEdans le cas où le dialogue existe déjà. Ce faisant, le problème de la distinction selon lecontexte ne se pose plus au niveau de la programmation, car il est traité à l'extérieurdu service au niveau du SIP-SLEE. Par convention, les méthodes de contrôle ra�néeset celles du protocole sont syntaxiquement notées en majuscule dans SPL.

Le dernier type de méthodes de contrôle noti�e un service d'évènements internes à


la plate-forme qui sont pertinents pour la logique du service. La méthode de contrôleunregister, par exemple, est associée à l'expiration de l'enregistrement d'un utilisateur.De telles méthodes sont notées en minuscules pour indiquer qu'elles ne correspondentpas à des messages SIP.

Séparation des opérations. Les API existantes de programmation sont le plus sou-vent le re�et d'une traduction directe du protocole SIP ainsi que du paradigme deprogrammation mis en ÷uvre au sein de la plate-forme de téléphonie. Toutefois, biensouvent, ces API ne prennent pas en compte certains concepts spéci�ques à la téléphonie,et qui ne sont pas clairement explicités dans le protocole. Ces concepts peuvent pourtantêtre utilisés comme un cadre de conception des services. Considérons, par exemple, leconcept de dialogue, qui correspond à un appel. Un dialogue est un �l conducteur natu-rel pour concevoir un service ; à travers l'utilisation de di�érentes méthodes de contrôle(e.g., INVITE, ACK, ou encore BYE), il couvre le cycle de vie complet de l'appel : création,con�rmation, modi�cation et terminaison.

Les concepts SIP de souscription à un évènement et d'enregistrement ont égalementce même cycle de vie et peuvent être perçus comme des abstractions de conception.En�n, un service est déployé et associé à un utilisateur ou un groupe d'utilisateurs. Cetteassociation permet d'introduire des comportements spéci�ques au niveau du service etdoit donc persister jusqu'à ce que ce dernier ne soit plus déployé sur la plate-forme.

Ces concepts (service, enregistrement, dialogue et souscription) doivent être repré-sentés au niveau du langage de programmation, ainsi que les di�érentes étapes associées.Pour cela, nous introduisons une séparation au niveau des méthodes de contrôle, quicoïncide avec les phases du cycle de vie de ces abstractions. Ainsi, nous introduisonsune distinction des méthodes en les classi�ant en méthode initiale (création), médiale(con�rmation et modi�cation), et �nale (terminaison), comme résumé dans la classi�-cation des méthodes de contrôle exposée au niveau du tableau 7.1. Cette classi�cationreprend l'ensemble des méthodes de contrôle qu'il est possible de gérer au niveau d'unservice SPL. La répartition de ces méthodes permet de grandement simpli�er la concep-tion de services.

SUBSCRIBE

INVITE

REGISTER

deploy

Initiale

Méthodes de Contrôle

unsubscribeRESUBSCRIBENOTIFYSouscription

undeployServiceunregisterREREGISTEREnregistrementBYEuninvite

CANCELACKREINVITE

Dialogue

FinaleMédialeConcepts

Tab. 7.1 � Classi�cation des méthodes de contrôle


L'état. Jusqu'ici nos abstractions de conception concernaient seulement du code (as-socié aux gestionnaires), mais les services ont également besoin de manipuler leur propreétat. L'environnement d'exécution permet d'attacher un état à un dialogue, une sous-cription, un enregistrement et un service. De plus, il gère cet état d'un bout à l'autredu cycle de vie associé à chacun de ces concepts. Là encore, le problème de la gestionde l'état ne se pose plus au niveau du service, car il est traité par l'environnement.

Une telle association d'opérations et d'un état est analogue à la notion d'objet dansun langage orienté objet et forme ce que nous appelons une session. Nous associonsdonc une session à chacun des concepts introduits précédemment (service, enregistre-ment, dialogue et souscription), chacune comprenant les méthodes correspondantes àson cycle de vie. Ainsi, une méthode de contrôle initiale crée une session, une méthodemédiale s'exécute à l'intérieur de cette session et une méthode �nale clôt la session.

En résumé, la notion de session est donc structurante pour le développement deservices SPL. Une session est constituée d'un ensemble de gestionnaires et d'un état. Ungestionnaire dé�nit un traitement pour une méthode de contrôle, que ce soit une requêtedu protocole (e.g., INVITE), une requête ra�née (e.g., REINVITE), ou un évènement dela plate-forme (e.g., déploiement de services). Un état permet, quant à lui, de maintenircertaines données à travers plusieurs gestionnaires.

7.2.2 Le langage

Le langage SPL possède des constructions et une sémantique dédiées au domaine dela Téléphonie sur IP. Il est élaboré autour des abstractions fournies par l'environnementSIP-SLEE. Cette section décrit les points forts du langage. Une syntaxe complète estdisponible, ainsi que des exemples concrets de services SPL [Pho06].

Organisation hiérarchique des sessions. La syntaxe d'un service SPL re�ète lastructure des sessions de l'environnement SIP-SLEE. Chaque type de session est repré-senté par un bloc contenant les déclarations des variables et des gestionnaires associésà la session. Cette notion fournit au programmeur un cadre de conception pour uneapproche de développement hiérarchique de services. La �gure 7.3 représente la struc-ture d'un service SPL. Un programme SPL dé�nit d'abord une session service (service)nécessaire pour le déploiement de la logique ; un bloc interne déclare la session enregistre-ment (registration) et la logique associée pour gérer l'enregistrement de l'utilisateur.Les feuilles du programme SPL consistent en une session dialogue (dialog) et une ses-sion souscription (event), manipulant respectivement une session SIP et un évènementSIP. Comme dans les langages o�rant des blocs lexicaux emboîtés de variables (dont leprécurseur est le langage Algol [Mad86]), la structure d'un service SPL permet à unesession de n'importe quel niveau d'avoir accès à l'ensemble des variables et des fonctionsdéclarées aux niveaux supérieurs. La partie droite de la �gure 7.3 illustre ce point : lavariable registration var1 est accessible au niveau du bloc de session registration,mais également des sessions dialog et event. Toutefois, elle ne l'est pas au niveau dela session service.


service service_name {[...]handler deploydeploy {...} handler undeployundeploy {...}

registration {[...]handler REGISTERREGISTER {...}handler unregisterunregister {...}

dialog {[...]handler INVITEINVITE {...}handler ACKACK {...}handler BYEBYE {...}

}

event presence {[...]handler SUBSCRIBESUBSCRIBE {...}handler NOTIFYNOTIFY {...}

}}

}

Dialog Session• dialog_var1• dialog_var2•…

Registration Session

• registration_var1• …

Service Session

• service_var1•…

Event Session• event_var1• …

Fig. 7.3 � Structure d'un service SPL

B0

B1

B2

B3

B4

1. service Counter {2. processing {3. local void log (int); 4.5. registration {6. int count; 7.8. response outgoing REGISTERREGISTER() {9. count = 0;10. return forward ();11. }12.13. void unregisterunregister() {14. log (count);15. }16.17. dialog {18. response incoming INVITEINVITE() {19. response resp = forward ();20. if (resp != /SUCCESS) {21. count++;22. return forward 'sip:[email protected]'; 23. } else {24. return resp;25. }26. }27. }28. }29. }30. }

Fig. 7.4 � Le service Compteur écrit en SPL


A�n d'illustrer plus précisément la structure du langage, nous reprenons l'exempledu service Compteur introduit précédemment (section 7.1.1), que nous programmonsavec le langage SPL. Le résultat est présenté à la �gure 7.4. Rappelons que le servicevise à gérer un compteur des appels qui ont été transférés vers une secrétaire, lorsquel'utilisateur associé au service ne peut être joint. Ce compteur est initialisé à zéro lorsquel'utilisateur s'enregistre auprès du serveur d'enregistrement, incrémenté lorsqu'un appelest transmis à la secrétaire et enregistré lorsque l'utilisateur se déconnecte. À titre decomparaison et pour simpli�er la compréhension du lecteur, la �gure présente égalementles blocs Bi de code utilisés lors de l'explication du service dans la section précédente.Avant toute chose, nous pouvons déjà constater la concision et la lisibilité du code dece service, comparé à son homologue écrit en JAIN SIP (�gure 7.1).

Cet exemple permet de mettre en avant la structure hiérarchique d'un programmeSPL ainsi que la restauration automatiquement de l'état par l'environnement SIP-SLEE.Nous pouvons voir que ce service Compteur déclare une fonction log au niveau de lasession service (ligne 3) qui est utilisée par le gestionnaire unregister de la sessionenregistrement (ligne 14). De même, la variable count déclarée au niveau de la sessionenregistrement (ligne 6) est manipulée à la fois par le gestionnaire REGISTER pour initia-liser le compteur (ligne 9), par le gestionnaire unregister pour sauvegarder sa valeur etpar le gestionnaire INVITE de la session dialogue pour l'incrémenter (ligne 21). Commel'illustre cet exemple, SPL ne nécessite pas de manipulation d'état explicite au sein duprogramme. La variable count est dé�nie et manipulée comme dans n'importe quel lan-gage de programmation grâce à la manipulation d'état de l'environnement SIP-SLEE.Les manipulations de variables sont, en e�et, automatiquement traduites en opérationsd'accès, de sauvegarde et de restauration. En dehors de guider la conception du service,SPL o�re donc une vision haut niveau des couches sous-jacentes (e.g., API JAIN SIP),dans lesquelles le code d'un gestionnaire SPL est divisé en autant de sections de codequ'il y a d'interactions requête-réponse entre un client et un serveur.

Flot de contrôle intra-méthode. Les gestionnaires des méthodes de contrôle ac-complissent certaines opérations puis transfèrent la requête SIP. Ce transfert cède lecontrôle au serveur SIP, qui envoie la requête. Dans les interfaces de programmationexistantes, lors de la réception d'une réponse, le code du service doit explicitement as-socier cette réponse à sa requête. De plus, avant le traitement de la réponse, certainesopérations doivent être mises en ÷uvre pour restaurer le �ot de contrôle suspendu aupoint du transfert.

L'un des objectifs de SPL est de factoriser ces opérations fastidieuses et complexesà l'extérieur du service. Dans le langage, un gestionnaire est écrit comme une unitéindividuelle qui traite une transaction de la requête à la réponse. Lorsqu'un gestionnairea besoin de transférer un appel, ce dernier utilise l'expression forward, qui donne àl'environnement SIP-SLEE le pointeur de code courant et l'état. À la réception dela réponse correspondante, l'environnement restaure le pointeur de code et l'état duservice, et l'exécution du gestionnaire continue.

La �gure 7.4 illustre le traitement d'une transaction SPL. Dans cet exemple, unappel entrant est transféré à l'utilisateur (ligne 19) et sa réponse est assignée à la


variable resp. La réponse est ensuite véri�ée. Si l'appel n'est pas accepté (ligne 20),la requête originale est redirigée sur la secrétaire et la nouvelle réponse est retournée àl'appelant (ligne 22).

Flot de contrôle inter-méthode. La notion de session SPL représente égalementun processus de contrôle. Le protocole SIP décrit un �ot de contrôle de session suivantune forte granularité, spéci�ant par exemple que durant un dialogue le contrôle doitpasser du gestionnaire INVITE au gestionnaire ACK et terminer par le gestionnaire BYE.Pour augmenter son expressivité, SPL fournit au programmeur le moyen de ra�nerla spéci�cation du �ot de contrôle via le mécanisme de branche (expression branch

du langage). Ce mécanisme passe une information de contrôle d'un gestionnaire à sonsuccesseur. Cette abstraction permet, par exemple, de classer une session comme étantpersonnelle ou professionnelle, ce qui introduit un sous-processus logique à travers lesinvocations de méthodes restantes de la session.

Une branche est choisie pour une session lorsque la session est créée. La brancheest sauvegardée dans l'état de la session et est utilisée pour choisir le code correct pourchaque invocation successive de gestionnaires. Pour une session de type service ou en-registrement, la branche initiale est default. Un gestionnaire peut alors spéci�er unenouvelle branche, qui écrase la précédente. Lors de l'invocation d'un nouveau gestion-naire, le code correspondant à la branche est exécuté. Le traitement est identique ence qui concerne les sessions dialogue et souscription, où la branche courante est héri-tée de la session enregistrement. Cependant, si un gestionnaire introduit une nouvellebranche, celle-ci vient s'ajouter à la séquence de branches et ne vient pas écraser labranche courante comme précédemment.

Ce mécanisme est illustré à la �gure 7.5, qui représente un extrait d'un service dehotline. Le mécanisme de branche permet de di�érencier dans ce service deux contextesdistincts, personnel et professionnel (respectivement les branches private et hotline).Dans le cas professionnel, le but du service est de transférer l'appel à un opérateurlibre et de comptabiliser le temps passé au téléphone. Cependant, les appels privésne doivent pas être pris en compte. Ainsi, à l'arrivée d'une requête INVITE destinéeà l'adresse de la hotline (ligne 15), la branche correspondante (hotline) du serviceest sélectionnée (ligne 22). Si l'appelé est au contraire une personne (ligne 27), l'appelcorrespond donc à un appel privé et la branche private est alors choisie (ligne 31).À la réception des requêtes ACK (ligne 37) et BYE (ligne 47), le traitement dépend dela nature de l'appel (private ou hotline). La branche correcte correspondante estautomatiquement choisie. L'introduction de branches permet ici de spéci�er plusieurscontextes d'appel et donc des comportements di�érents pour un même service selon labranche.

7.2.3 Propriétés garanties

Le domaine de la téléphonie impose des besoins importants en termes de sécurité etde �abilité. Un service ne doit pas introduire d'erreurs à l'exécution et doit égalementrespecter les invariants du protocole sous-jacent. Dans cette section, nous considérons


service hotline {processing {type hotliner_t {uri name; time t_call; int ticks;}; [...]registration {[...] response incoming REGISTER()REGISTER() {[...]} void unregisterunregister()() {[...]}

dialog {hotliner_t callee; time t;

response incoming INVITE()INVITE() { if (TO == 'sip:[email protected]') { foreach (h in hotline_registered) { if (get_status (h) == AVAILABLE) { response r = forward h.name; if (r == /SUCCESS) { callee = h; hotline_registered.remove (h); return r branch hotline; } }

} return forward 'sip:[email protected]'; } else { response r = forward; if (r == /SUCCESS) { hotline_registered.remove (TO); return r branch private;

} return r; } }

response incoming ACK()ACK() { branch hotline { t = get_time(); set_status (h, PHONE); return forward; } branch private {[...]} branch default { return forward; } }

response BYE()BYE() { branch hotline {callee.t_call += get_time()-t; return forward; } branch default { return forward; } } [...]

}}}}

1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.36.37.38.39.40.41.42.43.44.45.46.47.48.49.50.51.52.53.54.55.

Fig. 7.5 � Le service hotline écrit en SPL


certains types d'erreurs qui peuvent se produire lors de la programmation de servicesde Téléphonie sur IP avec des solutions existantes. Nous montrons de plus la manièredont SPL permet d'empêcher directement ces erreurs ou de les détecter par le biais devéri�cations statiques.

La sémantique de SPL a été formellement spéci�ée [Pho06], ce qui permet unedé�nition précise de ses interactions avec l'environnement d'exécution SIP-SLEE. Cettedé�nition formelle sert de fondation pour la dé�nition d'analyses de programmes.

Traitement d'appel erroné. Le but du service SIP est ultimement de réaliser uneopération de signalisation pour ne pas perdre d'appels. En outre, le traitement de chaquemessage doit être compatible avec le traitement du message original. Par exemple,une erreur consisterait à renvoyer une réponse d'erreur à l'appelant alors que l'ap-pelé a accepté l'appel. Une autre erreur consisterait à traiter un type de requête (e.g.,INVITE), et à en transférer une autre (e.g., ACK). Dans SPL, les opérations de signa-lisation prennent la forme de mots clés du langage, comme forward pour transférerune requête ou /SUCCESS pour indiquer une réponse de type succès. Ainsi, cela permetde véri�er que tous les chemins d'exécution à travers un gestionnaire accomplissent aumoins une opération de signalisation, et que ces actions sont cohérentes entre elles. Deplus, SPL empêche de changer le nom de la requête lors du transfert de cette dernière ; leseul argument à forward est la destination, laissant la structure et le nom de la requêteimplicites.

Un autre type d'erreur concerne la manipulation de messages SIP. Un message SIPcontient de nombreux en-têtes, parmi lesquels certains peuvent être optionnels ou enlecture seule. De plus, les messages SIP sont implémentés sous une forme textuelle.L'implémentation sous-jacente de tous les en-têtes est de type string, même si un en-têtepeut avoir un sens plus intuitif comme, par exemple, un entier ou un URI4. Plusieursactions peuvent alors rentrer en contradiction avec le protocole SIP et produire uneerreur : accéder à un en-tête qui n'est pas présent dans le message, essayer de modi�erla valeur d'un en-tête accessible en lecture seule, ou encore se tromper dans le typed'une valeur d'un en-tête. Le langage SPL empêche l'accès à un en-tête non présent, viaune construction when qui combine à la fois une véri�cation de présence de l'en-tête etl'accès à sa valeur. SPL fournit également une construction with qui permet de mettre àjour la valeur. Dans ce cas, une véri�cation est faite pour savoir si l'en-tête est accessibleen écriture. Ces deux constructions permettent de traiter les en-têtes sous la forme destring ou de types plus élaborés ; dans le dernier cas, une véri�cation est faite sur lavalidité de la contrainte de type.

Gestion de ressources erronée. Les API SIP basées sur des langages généralistes nefont rien pour se protéger contre les erreurs de programmation qui peuvent se produireavec ces langages. Par exemple, les API ne se protègent pas contre les boucles in�nies,et les API basées sur C ne se protègent pas contre les accès hors limites des structures

4Un URI, de l'anglais Uniform Resource Identi�er, soit littéralement identi�ant uniforme de res-source, est une chaîne de caractères identi�ant une ressource sur le Web.


de données ou l'accès à des données libérées. Ainsi, à la di�érence de langages géné-ralistes, SPL propose quelques restrictions simples qui permettent d'éviter les erreursde programmation les plus courantes sans sacri�er la puissance d'expression nécessaireau domaine ciblé. SPL autorise seulement des itérations bornées, comme illustré parla construction foreach de la �gure 7.5 (ligne 16). De plus, il inclut des véri�cationssur l'accès aux structures de données, comme dans Java. En�n, SPL ne possède aucunmécanisme d'allocation dynamique de données.

7.2.4 Implémentation

Une version de l'environnement d'exécution, ainsi qu'un interprète pour le langageSPL, ont été développés par Nicolas Palix, un doctorant du projet Ph÷nix. Ces com-posants ont été intégrés au sein de l'architecture d'un serveur d'applications que nousavons conçue [BCL+06b] et inclus dans le système de téléphonie de l'ENSEIRB5. Plu-sieurs services ont été testés [Pho06], notamment un service de �le d'attente. Ce serviceest dédié à la gestion des appels du département Télécommunication. Si la secrétairedu département est déjà en ligne, ce service place les appels entrants en attente. Uneestimation du temps d'attente est périodiquement calculée et annoncée aux appelantsqui patientent. SPL permet d'écrire ce service en moins de 100 lignes de code, alors qu'ilen faudrait quatre à cinq fois plus avec d'autres solutions.

Dans cette section, nous avons introduit SPL, un langage dédié de programmation deservices de Téléphonie sur IP qui o�re des notations et des abstractions haut niveau. Celangage cache les subtilités des plates-formes SIP, rendant les programmes plus concisque leurs homologues généralistes. Comparée à d'autres approches, la nature haut niveaude SPL rend les �ots de contrôle et de données explicites, à la fois localement à uneméthode du service, et globalement à une session. De plus, SPL permet de véri�er despropriétés au niveau du domaine, du protocole, de la plate-forme et du service. Lesexemples d'erreurs détectées dans les services incluent la perte d'appel, le non-respectdes invariants du protocole SIP (e.g., transitions incorrectes), ou encore l'utilisationnon bornée de ressources. Ainsi, de par sa conception, le langage garantit des propriétéscritiques, bien au-delà de ce qu'il est possible de faire avec des langages généralistes telsque Java, C# ou encore C.

7.3 VisuCom, un langage dédié de modélisation

VisuCom est un langage de modélisation graphique dédié au développement de ser-vices de téléphonie. À l'instar d'un logiciel de création de pages Web comme FrontPagede Microsoft, VisuCom met en place un processus de création intuitif et sûr. Ce langagevisuel permet à des développeurs de dé�nir des traitements d'appels du point de vue deleur métier. Pour cela, VisuCom repose sur une nouvelle approche de développement de

5L'ENSEIRB (École Nationale Supérieure d'Électronique, d'Informatique et de Radiocommunica-tions de Bordeaux) est une école d'ingénieurs spécialisée dans les technologies de l'information et de lacommunication.

VisuCom, un langage dédié de modélisation 79

services de Téléphonie sur IP intégrant directement dans le processus de conception desdonnées émanant du système d'informations (SI6) d'une organisation. Dans le cas deVisuCom, le caractère haut niveau du langage va plus loin que le simple fait de présenterles concepts du domaine. En intégrant des données métiers dans la programmation deservices, il devient possible d'adapter l'outil de développement de services et de présen-ter des abstractions vis-à-vis des besoins des développeurs. Ainsi, de par ses notations,mais également ses restrictions sémantiques et ses véri�cations, VisuCom permet à unutilisateur quelconque d'avoir accès à la programmation de services de Téléphonie surIP, domaine jusqu'alors réservé aux spécialistes du domaine.

7.3.1 De nouveaux besoins

Avec l'ouverture des plates-formes de téléphonie, il nous semble que de nouvellesperspectives vont naître pour des utilisateurs comme des commerciaux, des médecinsou encore des garagistes, pour qui la gestion de la relation téléphonique représente unepart importante de l'activité professionnelle. Ces développeurs en herbe ont le soucisd'améliorer leur système téléphonique a�n d'optimiser leur relation client et donc leurproductivité. Par exemple, un garage automobile peut souhaiter aiguiller automatique-ment l'appel d'un client possédant un véhicule en révision vers l'atelier ayant pris levéhicule en charge, en s'a�ranchissant du passage par l'hôtesse d'accueil.

Loin de vouloir un nouvel outil complexe, ces utilisateurs ont bien souvent des exi-gences simples en termes de fonctionnalités en ce qui concerne les services de téléphonie.En conséquence, un langage comme SPL apparaît trop complexe pour la situation, maisaussi pour leurs compétences. Toutefois, un besoin commun semble émerger : l'insertionde cet outil au sein de leur environnement professionnel, et en particulier l'intégrationavec leur système d'informations, qui peut aller d'une simple feuille de calcul, à un outilde relation client complexe (e.g., un outil CRM7).

Il existe aujourd'hui des solutions haut niveau qui permettent de "coupler" la plate-forme de téléphonie au système d'informations d'une organisation. Néanmoins, ces pro-cessus restent génériques, di�cilement con�gurables et ne font intervenir qu'une faibleinterconnexion avec le SI. En e�et, les solutions existantes apportent aux organisationsl'opportunité d'utiliser les ressources du système (e.g., remontée de �che client et com-position simpli�ée du numéro), mais en aucun cas de raisonner sur ces informations, nide les prendre en compte dans le processus de traitement d'appels. Ainsi, le couplage"téléphonie-informatique" présent au sein des organisations n'est utilisé que pour récu-pérer de l'information et aider les utilisateurs à prendre une décision.

En résumé, les nouveaux développeurs de services de Téléphonie sur IP ne possèdentaucune connaissance en programmation et les outils existants ne semblent pas répondreà leurs besoins. Cependant, selon les situations, ils connaissent parfaitement les règles

6Un système d'informations (noté SI) représente l'ensemble des éléments participant à la gestion,au traitement et à la di�usion de l'information au sein d'une organisation.

7Un outil CRM (Customer Relationship Management) est un outil de gestion de la relation client,dont le but est de rendre pro�table chaque interaction entre l'organisation et le client.


de gestion d'appels à appliquer au sein de leur organisation. Le but n'est donc pasd'amener leur expertise à la programmation, mais au contraire d'amener la program-mation à leur expertise. Il faut donc fournir un outil permettant à ces utilisateurs dese concentrer sur la dé�nition du quoi, c'est-à-dire de ce que doit faire la logique duservice, et non sur comment le faire. Un langage de modélisation dédié semble toutindiqué pour cela, élevant le niveau d'abstraction par rapport à ce que peut faire unlangage de programmation dédié comme SPL. A�n de répondre au besoin d'interac-tion avec le système d'informations d'une organisation, nous proposons une nouvelleapproche de développement de services sur laquelle est basé VisuCom, notre langage demodélisation.

7.3.2 Une nouvelle approche

L'interconnexion d'un système de téléphonie avec un système d'informations n'estpas une chose aussi simple qu'il pourrait y paraître. Ce processus pose, en e�et, uncertain nombre de questions relatives aux types d'informations du SI, à leur disponibilitéet à leur cohérence du point de vue du service. Le domaine de la téléphonie imposecertaines contraintes, notamment de temps d'exécution et d'aboutissement d'appels,qui nécessitent d'être prises en compte dans ce processus d'interconnexion. Par exemple,une information non disponible au niveau du SI ne doit pas empêcher l'exécution duservice. Cette section présente les grandes lignes de l'approche que nous proposons pourcoupler les deux systèmes, tout en assurant les propriétés de la téléphonie. Ce procédéa fait l'objet d'un dépôt de brevet8, spéci�ant notamment le méta-modèle abstrayant lesystème d'informations de l'organisation, la méthode de construction et de mise à jourdes données de ce modèle à partir de diverses sources du système, ainsi que certainesfonctionnalités du langage VisuCom.

Approche. L'approche consiste à décomposer un service de téléphonie en deux com-posants : un arbre décisionnel et un composant issu du SI d'une organisation appelé labase de contacts. La �gure 7.6 illustre notre approche et montre le processus d'intercon-nexion du SI au système de téléphonie et les relations entre les di�érents composants. Lepremier composant, l'arbre décisionnel, constitue le processus décisionnel de traitementd'appels. Il est représenté sous la forme d'un arbre de décisions qui dé�nit explicitementdes règles de traitement, et dont le but ultime est de traduire chaque appel en une déci-sion de routage. Ces décisions de routage sont en réalité des opérations de signalisationqui permettent de transférer un appel, de le rediriger ou encore de le rejeter. L'arbre dedécisions est mis en ÷uvre grâce à un ensemble de tests qui permettent non seulementde router l'appel en fonction des caractéristiques de l'appel (e.g., l'appelant, l'appelé,ou la date), mais également selon son contexte, et plus précisément en fonction d'unedonnée de l'organisation issue du système d'informations (e.g., importance de l'appe-lant ou date de son dernier appel). Ainsi, il devient possible d'adapter le processusde traitement d'appels aux besoins de l'organisation. Une caractéristique essentielle du

8Un brevet européen a été déposé le 7 août 2006, s'intitulant "Dispositif d'interconnexion d'unsystème d'informations d'organisation(s) à un serveur".


processus consiste donc à extraire ces données issues du système d'informations a�nde les rendre disponibles et les intégrer aisément au sein du processus de traitementd'appels. Pour cela, l'approche utilise un deuxième composant, la base de contacts, quireprésente la vue du système d'informations par rapport au processus de traitement desappels téléphoniques. Le couplage de ces deux composants permet d'interconnecter lesystème de téléphonie au système d'informations d'une organisation. Cette associationrend la programmation de services plus �able puisque les données sur lesquelles reposentle service (les "paramètres" du service) sont nécessairement correctes. Notre approchedi�ère en ce point de l'approche CPL où le service contient des paramètres saisis en durpar le développeur (e.g., l'adresse de redirection d'appel sip:[email protected]).En abstrayant un modèle de données, cela nous permet de prémunir le système de télé-phonie des erreurs de programmation liées, par exemple, à la saisie de ces paramètres. Ilnous est également possible de prendre en compte l'évolutivité de l'information. Consi-dérons par exemple que l'adresse de la secrétaire soit modi�ée ; dans l'approche CPL,il est nécessaire de répercuter la modi�cation sur tous les services contenant l'adressede la secrétaire. Dans notre approche, la modi�cation est faite au niveau du SI une foispour toute et donc au niveau de la base de contacts. Ce faisant, comme les servicesredirigent l'appel sur l'adresse de la secrétaire en interrogeant la base de contacts, lechangement est automatiquement pris en compte. De plus, notre approche permet deraisonner sur le modèle de données de la base de contacts et ainsi assurer la cohérencedes informations issues de la base de contacts avec la logique de l'arbre décisionnel.

Système d’Informations

Pilotes

Base de contacts

P1 P2 P3

Service

Arbre décisionnel

Fig. 7.6 � Processus d'interconnexion du SI au système de téléphonie


La base de contacts : une abstraction du SI. A�n de pouvoir être générique etréutilisable quelle que soit l'organisation, l'approche doit être indépendante de la ou dessources d'informations du SI et des technologies associées. En e�et, selon l'organisationconsidérée, l'information peut apparaître sous di�érents formats (propriétaires ou non),avec des représentations hétérogènes (e.g., code binaire, texte ou diagramme), et lessources peuvent être multiples (e.g., tableur, base de données ou service Web). Toutceci complexi�e l'intégration des données émanant du système d'informations dans leprocessus de traitement d'appels. De plus, la téléphonie représentant une ressource in-dispensable pour la plupart des organisations, la solution doit être pérenne. Ainsi, si unedécision porte sur une donnée du système d'informations, celle-ci doit être accessible àtout moment par le processus de traitements d'appels. Il est alors indispensable d'ex-traire ces données sans reposer directement sur le SI. En e�et, le crash possible d'unesource d'informations du SI n'a de ce fait aucun e�et sur le processus de traitementsd'appels puisque l'information est désormais retenue dans la base de contacts. De plus,il peut arriver que l'information compréhensible par le processus de traitement d'appelsne soit pas présente en tant que telle dans le système d'informations. En e�et, les don-nées brutes extraites du système d'informations peuvent nécessiter des transformationsspéci�ques (e.g., agrégation, �ltrage ou transformation) a�n d'être adaptées aux besoinsdu processus de traitement d'appels téléphoniques. Pour répondre à ces problèmes, unecaractéristique essentielle de la démarche consiste à abstraire les données extraites du SIa�n de les adapter au domaine de la téléphonie. Ces données sont alors rassemblées ausein de la base de contacts. A�n de faciliter son utilisation, elle manipule des abstractionsspéci�ques en introduisant entre autres la notion de contact ou de groupe de contacts.Un contact peut être une entité physique (personne) ou virtuelle (e.g., organisation, ad-ministration, groupe de personnes). Les éléments constitutifs d'un contact peuvent êtrerépertoriés selon trois grandes catégories comme illustrés à la �gure 7.7. La premièreregroupe les informations concernant le contact, qui ne constituent qu'une facilité d'uti-lisation ou de rendu, par exemple au niveau d'une interface graphique. Cela concernedes informations comme le nom du contact, son prénom ou une photo. Le deuxièmeélément est son identi�cation. Ce type d'information est primordial pour le modèle decalcul de VisuCom puisqu'il permet d'identi�er le contact de manière unique dans labase de contacts. Cela peut correspondre à un numéro de téléphone mobile, un identi-�ant SIP ou encore un numéro de sécurité sociale. En�n, le dernier élément concerneles paramètres du contact. Ce type d'information est également primordial pour le mo-dèle de calcul de VisuCom puisqu'il correspond à des caractéristiques spéci�ques liées àl'organisation et à la profession de l'utilisateur. Ces paramètres sont découpés en deuxsous-catégories que sont les groupes et les attributs. La première sous-catégorie permetde mettre en place une catégorisation des contacts (appartenance à un groupe), alorsque les attributs permettent une catégorisation des appels (e.g., noti�cation d'un appelprioritaire, interrogation d'un crédit hotline ou association à un numéro de contrat).

Pilotes. De la même manière qu'un pilote de périphérique est une couche intermé-diaire permettant à un programme d'interagir avec un périphérique, la base de contactsest alimentée par l'intermédiaire de pilotes (�gure 7.6). Ces derniers représentent une


Nom : DoePrénom : JohnPhoto

Identifiant SIP : sip:[email protected]

GroupesClient VIP

AttributsCrédit Hotline : 10Numéro de contrat: N2010_404 Responsable: sip:[email protected]

Informations sur le contact

Identifiant

Paramètres du contact

Contact

Fig. 7.7 � Exemple d'informations concernant un contact

interface avec un ou plusieurs composants du système d'informations. Un pilote est uneapplication permettant d'extraire des informations d'une source de données et de lesadapter au modèle de la base de contacts (contact, groupe et attribut). Il peut s'agir,par exemple, de pilotes pour des feuilles de calcul Excel, des bases de données Oracle ouencore des annuaires LDAP (Lightweight Directory Access Protocol). Le rôle d'un piloteest d'extraire un ensemble d'informations sélectionnées, à une fréquence déterminée, etde mettre à jour la base de contacts en conséquence. Le pilote doit donc non seulementgérer l'hétérogénéité des sources et des formats de données du SI, mais aussi introduirede la logique a�n d'adapter l'information à notre modèle. Pour cela, un pilote possèdeune architecture en couches et se décompose selon deux niveaux ; le premier fait �gured'accesseur technique, permettant d'accèder à l'information en fonction de la technolo-gie employée au niveau du SI. La seconde couche représente, quant à elle, une couched'abstraction fonctionnelle, mettant en ÷uvre une logique qui adapte l'information issuedu SI au formalisme de la base de contacts.

Contrairement aux solutions existantes, l'approche proposée ici met en ÷uvre unnouveau modèle de traitement d'appels téléphoniques permettant de prendre une déci-sion en fonction des données issues du système d'informations d'une organisation, viala base de contacts. Ainsi, il devient possible d'automatiser des décisions de routageen fonction du métier de l'organisation et de la situation actuelle, sans interventionhumaine. De plus, les services de traitements d'appels mis en ÷uvre permettent nonseulement de tenir compte des données du SI, mais également des modi�cations dela valeur de ces informations en fonction de l'évolution de l'organisation. De ce fait,l'approche présente de nombreux avantages en termes d'intégration automatique desdonnées au processus de traitement d'appels, d'évolutivité du système de traitementd'appels en fonction de la dynamique de l'organisation, et donc de richesse des servicescréés.


7.3.3 Le langage VisuCom

VisuCom9 est un langage dédié de modélisation basé sur l'approche que nous venonsd'exposer. Un service VisuCom se présente donc sous la forme d'un arbre décisionnel bi-naire. Les n÷uds de cet arbre sont des icônes que l'utilisateur relie entre elles. VisuCompropose une répartition des fonctionnalités selon trois types fondamentaux. Le tableau7.2 résume les fonctionnalités o�ertes par ce langage, ainsi que les représentations gra-phiques associées. D'abord, des fonctionnalités dites de décision. Elles représentent lesopérations de signalisation disponibles telles que le transfert d'appel, la redirection d'ap-pel sur une personne particulière ou sur un groupe de personnes, le rejet d'un appel ouencore l'envoie d'un courrier électronique au correspondant (e.g., a�n d'être noti�é lorsd'une absence par exemple). VisuCom o�re également des icônes dites de �ltrage d'ap-pel. Ces �ltrages, ou tests, correspondent à des prédicats et sont e�ectués au niveaude l'appel. Par exemple, il s'agit de tester la source de l'appel ou encore une plagehoraire précise de la journée a�n d'appliquer un traitement particulier sur l'appel. Ilpeut également s'agir d'un �ltrage sur une caractéristique précise de l'appelant (e.g.,son chi�re d'a�aire ou la date de son dernier appel) ou sur sa disponibilité (renseignéepar un agenda). En�n, VisuCom propose des fonctionnalités plus avancées dites d'ad-ministration. Elles permettent, par exemple, d'introduire l'équivalent de procédures ausein d'un service, a�n de pouvoir stocker une partie de l'arbre décisionnel et la réutiliserà plusieurs autres endroits. De même, elles permettent de créer des conjonctions et desdisjonctions de �ltrages et de pouvoir les réutiliser dans le service.

Un service VisuCom repose sur une base de contacts, ce qui lui permet d'utiliserdes informations issues du SI de l'organisation. Les fonctionnalités présentées précé-demment s'appuient donc sur ces informations, sous la forme de contacts, de groupesde contacts et d'attributs. À travers ces abstractions, et notamment le type d'attributsprésents dans la base, le développeur manipule des concepts de son métier. Un autreutilisateur d'une autre organisation possède des attributs di�érents, et donc des servicesdi�érents. De plus, VisuCom ne nécessite aucune connaissance en programmation. Il estégalement totalement indépendant du protocole sous-jacent, ce qui le démarque de SPLdont le formalisme re�ète le protocole SIP. Le langage, mais aussi le couplage avec labase de contacts, permettent d'amener l'utilisateur à manipuler des concepts naturelset familiers pour créer, modi�er ou étendre un service. La facilité d'utilisation de Vi-suCom est accentuée par son aspect visuel, renforçant le caractère intuitif du langage.De plus, VisuCom est accompagné de son éditeur graphique qui fournit à l'utilisateurun environnement complet (e.g., de conception, de véri�cation et de sauvegarde), etsimpli�e l'utilisation du langage par un système de glisser-déposer (drag-and-drop) desdi�érentes abstractions graphiques présentées.

Un exemple VisuCom. A�n de mieux illustrer le langage VisuCom, considéronsl'exemple Filtrage sur Indisponibilité, présenté à la �gure 7.8. Notons tout d'abord queles indications se trouvant à proximité des icônes de l'arbre ont été ajoutées simplementpour rendre plus compréhensible l'exemple, mais sont toutefois disponibles au passage

9VisuCom fait l'objet d'un transfert technologique auprès de la société Siderion Technologies.


Avancées

L’appelant est-il John Doe ?L’appelant est-il un membre de l’administration ?

Filtrage sur l’appelant

L’appel survient-il entre 8h et 17h ?L’appel arrive-t-il pendant les heures d’ouverture ?

Filtrage sur une plagehoraire

Filtrage

Transfert d’appel

Décision

Rediriger l’appel sur John Doe.Rediriger l’appel sur ma secrétaire.

Redirection d’appelsur une personne

Rediriger l’appel sur le service informatique.Rediriger l’appel sur une secrétaire.

Redirection d’appelsur un groupe de personnes

Rejet d’un appel

Envoyer le nom de l’appelant, l’heure et le jour de l’appel.Envoi d’un mail

Suis-je en rendez-vous ?Suis-je en déplacement ?

Filtrage sur la disponibilité

Est-il un client Premium ?Son crédit hotline est-il épuisé ?

Filtrage sur unecaractéristique de l’appelant

L’appelant est-il un client Premium et son appel est-il urgent ?L’appelant est-il un membre de l’administration ou de l’exécutif ?

Filtrage réutilisable avancé

Action réutilisable avancée

Nom

Si l’appel survient pendant les heures d’ouverture, alors redirigerl’appel sur le standard, sinon sur la boîte vocale.

ReprésentationExemplesFonctionnalités

Tab. 7.2 � Fonctionnalités de VisuCom

de la souris sur les icônes. À la réception d'un appel, le service teste la disponibilité del'appelé (par rapport à son agenda). Si celui-ci est disponible, l'appel lui est transféré, ets'il ne répond pas (e.g., parce qu'il est déjà en communication ou parti de son bureau),l'appel est redirigé vers sa secrétaire. Dans le cas où l'appelé est indisponible (e.g., enréunion), le service regarde si l'appelant est un client privilégié ; si c'est le cas, l'appelest transféré sur le mobile de l'appelé. Si le client n'est pas premium, alors un mail estenvoyé à l'appelé indiquant les coordonnées de l'appelant, le jour et l'heure de l'appel,a�n qu'il puisse le contacter.

L'expressivité de VisuCom. L'expressivité de VisuCom est un des points clés dulangage. Les premières versions étaient issues directement de notre connaissance du do-maine et de notre expérience avec SPL. Cependant cette approche a rapidement montréses limites, car en totale inadéquation avec les besoins des développeurs. Il en résul-tait des fonctionnalités beaucoup trop complexes, et des notations et des concepts horsde portée des non-programmeurs. VisuCom a alors subi une refonte complète en par-tant des besoins des utilisateurs. Ainsi, le langage est apparu totalement di�érent et debeaucoup plus haut niveau, notamment en comparaison avec SPL. À titre d'exemple,VisuCom ne traite que la partie INVITE du protocole SIP et ne manipule aucune va-riable explicitement. De plus, l'une des forces du langage est de ra�ner les conceptspour les rendre accessibles. Ainsi, nous pouvons noter que la seule abstraction forward


Fig. 7.8 � Le service VisuCom Filtrage sur Indisponibilité

de SPL se traduit en réalité en plusieurs concepts dans VisuCom selon les besoins del'utilisateur (e.g., transférer l'appel, rediriger vers une personne ou encore rediriger surun groupe). Nous pouvons également nous apercevoir que la notion de continuation liéeau forward de SPL (association requête-réponse) est explicitement représentée dansVisuCom (�gure 7.8). En e�et, dès que le développeur réalise une opération de signa-lisation qui implique une réponse, ce dernier est invité à indiquer s'il veut traiter cetteréponse. S'il ne le souhaite pas, aucune autre action n'est possible. De plus, le langagemanipule explicitement la notion de �ltrage. Là encore, la construction if de SPL setraduit en di�érents �ltrages intuitifs (tableau 7.2). En�n, de par la nature haut niveaudu langage, l'éditeur dédié permet à VisuCom d'être contextuel. Ainsi, pour un utili-sateur donné, les services créés ne peuvent se faire que selon ses propres attributs. Parexemple, considérons le cas de deux utilisateurs Bob et Alice, et considérons que Bob,contrairement à Alice, n'a pas de secrétaire et donc aucun attribut personnel désignantune telle personne. Lorsque Bob développe un service avec l'éditeur dédié à VisuCom,il lui est impossible de rediriger ses appels vers sa secrétaire, puisque l'information n'estpas présente dans la base de contacts et donc non fournie au niveau de VisuCom. Àl'inverse, Alice peut tout à fait réaliser un tel service. L'interaction avec la base decontacts permet ainsi de restreindre le contexte de conception des services, empêchantle développeur de manipuler des informations erronées (e.g., �ltrer un appel sur la valeurd'un attribut qu'il ne possède pas ou rediriger sur une personne inconnue).


7.3.4 Propriétés garanties

A�n d'assurer la �abilité des services, VisuCom garantit des propriétés du domainepar construction, mais aussi grâce à la mise en ÷uvre de règles sémantiques au ni-veau de l'éditeur graphique. Tout d'abord, certaines analyses empêchent la conceptionde services incomplets, ou syntaxiquement incorrects. En e�et, bien que graphiques,les abstractions du langage possèdent une syntaxe précise qui permet la validationde contraintes concernant l'enchaînement des di�érents concepts. La sémantique desconnecteurs qui lient les icônes du langage entraîne de plus la validation dynamique decertaines de ces contraintes. Ainsi, l'analyse du service empêche par exemple de conti-nuer un traitement après avoir rejeté un appel, puisque cette action est nécessairementterminale. De plus, l'analyse d'un service force tous les chemins d'exécution à être spé-ci�és. Par exemple, tous les �ltrages doivent nécessairement indiquer une action dans lecas du succès et de l'échec du prédicat. Dans le cas contraire, l'analyse permet d'iden-ti�er de manière précise la cause et la position de l'erreur dans l'arbre. L'ensemble deces règles sémantiques est détaillé dans la spéci�cation technique de VisuCom et de sonenvironnement. Ces règles gèrent également les propriétés liées à chaque abstraction,interdisant par exemple, un �ltrage sur un attribut sans valeur ou une redirection surune personne qui n'existe pas. Ce dernier point est très important dans VisuCom etcontribue grandement à sa �abilité. Contrairement à CPL, en se basant sur la base decontacts, le langage force une certaine cohérence des services puisque les paramètres duservice sont extraits du système d'informations. L'utilisateur n'a pas à saisir d'adressede redirection par exemple. Il sélectionne un contact vers qui rediriger l'appel. De même,l'attribut de l'utilisateur est forcément présent dans la base de contacts, car dans le cascontraire il n'apparaîtrait pas au niveau de l'éditeur. Cette insertion des données dansle service empêche un grand nombre d'erreurs, liées à une mauvaise saisie d'une adresseou d'une valeur par exemple.

VisuCom introduit également une certaine forme de typage, ce qui lui permet derenforcer la �abilité des services. Pour ajouter de la �exibilité au langage, il est ainsipossible de rediriger ses appels en utilisant ses propres attributs, comme par exemple,son mobile, sa secrétaire ou encore son responsable (�gure 7.7). Toutefois, simplementautoriser la redirection sur attribut n'est pas correcte. En e�et, tous les attributs necorrespondent pas à des entités susceptibles de pouvoir prendre des appels (e.g., no-ti�cation d'un appel prioritaire, interrogation d'un crédit hotline ou association d'unnuméro de contrat). Le langage introduit donc un typage plus fort de ces attributs, enconsidérant les attributs de type contact ou numéro de téléphone. Ceci permet detyper la redirection d'appel. En�n, parce qu'il est haut niveau et qu'il fortement res-treint, le langage VisuCom assure également les invariants du protocole SIP.

VisuCom est un langage dédié de modélisation basé sur une nouvelle approche dedéveloppement de services. L'utilisation d'une base de contacts permet non seulementde spécialiser le processus aux besoins du développeur, mais également de renforcer la�abilité des services. Cet outil fournit donc aux experts du domaine la possibilité d'expri-mer facilement les règles de traitement d'appels à appliquer au sein de leur organisation.


Cependant, les informations du système d'informations évoluant en permanence avec lavie de l'organisation, le contenu de la base évolue également. Ce faisant, il peut arriverque les services ne soient plus en adéquation avec son contenu. Le traitement des appelspeut alors devenir obsolète voire incohérent suite à une modi�cation de la base. Il estdonc nécessaire de mettre en place un moyen de véri�er cette adéquation. L'approcheen couches présentée dans le chapitre précédent apporte une solution à ce problème. Cepoint est évoqué dans le chapitre 9. Mais avant de s'intéresser à ce problème, illustronsnotre architecture avec le domaine de la téléphonie et notamment avec les deux langagesdédiés introduits dans ce chapitre. La section suivante expose un aperçu des béné�cesde l'introduction de SPL comme couche pivot de notre architecture.

7.4 Application de notre approche

La nature di�érente de SPL et de VisuCom nous permet de mettre en ÷uvre l'archi-tecture en couches présentée au chapitre précédent. La �gure 7.9 montre l'adaptationde cette démarche au domaine de la téléphonie. Ainsi, par l'introduction de SPL commecouche pivot entre le domaine et l'implémentation, il est tout à fait possible d'éleverprogressivement le niveau d'abstraction. En passant par cette étape intermédiaire quereprésente le DSPL, cette approche en couches facilite l'implémentation de langages dehaut niveau, comme CPL ou VisuCom. De plus, elle représente une solution au pro-blème du portage de services de téléphonie (section 4.4). Si nous ne montrons dansce document qu'une implémentation sur JAIN SIP, la démarche est identique sur desenvironnements comme Live Communications Server de Microsoft (API de type C#)ou Asterisk. Le travail est délégué au compilateur de SPL, laissant les modèles hautniveau inchangés.

ProgrammationModélisation

Implémentation

Compilation

Programmation

CPL

SPL

JAIN SIP

Compilation

DOMAINE

VisuCom

AsteriskC#

Fig. 7.9 � Illustration de notre approche dans la téléphonie

Application de notre approche 89

1. <?xml version="1.0" encoding="UTF-8"?>2. <cpl>3. <incoming>4. <location url="sip:[email protected]">5. <proxy>6. <default>7. <address-switch field="origin">8. <address is="sip:[email protected]">9. <location url="tel:+19175554242">10. <proxy />11. </location>12. </address>13. <otherwise>14. <location url="sip:[email protected]">15. <proxy />16. </location>17. </otherwise>18. </address-switch>19. </default>20. </proxy>21. </location>22. </incoming>23. </cpl>

1. service example {2. [...]3.4. response incoming INVITE()INVITE() { 5. response r = forward 'sip:[email protected]';6. if (r == /ERROR) {7. if (FROM == 'sip:[email protected]') {8. return forward 'tel:+19175554242'; 9. } else {10. return forward 'sip:[email protected]';11. }12. } 13. return r;14. }15. [...]16. }

1. public class example implements SipListener {2. [...]3. private AddressFactory factory = getAddressFactory(); 4.5. public void processRequest (RequestEvent requestEvent) {6. Request rq_request = requestEvent.getRequest();7. SipProvider rq_sipProvider = (SipProvider) requestEvent.getSource();8. String method = rq_request.getMethod(); 9. [...]10. if (method.equals (Request.INVITE)) {11. SipURI uri = factory.createSipURI ("bob", "phone.example.com");12. rq_request.setRequestURI (uri); 13. ClientTransaction ct = rq_sipProvider.getNewClientTransaction(rq);14. ct.sendRequest (rq_request); 15. } 16. [...]17. }18.19. public void processResponse (ResponseEvent responseEvent) { 20. ClientTransaction rs_ct = responseEvent.getClientTransaction();21. if (rs_ct != null) {22. Request rs_request = rs_ct.getRequest();23. Response rs_response = responseEvent.getResponse();24. SipProvider rs_sipProvider = (SipProvider) responseEvent.getSource();25. String method = rs_request.getMethod();26. rs_responseCode = rs_response.getStatusCode(); 27. if (method.equals (Request.INVITE)) { 28. if (rs_responseCode > 300) {29. if (rs_request.getHeader("FROM").equals("sip:[email protected]")) {30. TelURL tel = factory.createTelURL ("tel:+19175554242");31. rs_request.setRequestURI (tel); 32. rs_sipProvider.sendRequest (rs_request); 33. } else {34. SipURI uri = factory.createSipURI ("bob", "voicemail.example.com");35. rs_request.setRequestURI (uri); 36. rs_sipProvider.sendRequest (rs_request); 37. }38. } else {39. rs_sipProvider.sendResponse(rs_response);40. } 41. } 42. } else {[...]}43. }44. [...]45. }

Fig. 7.10 � Comparaison des approches CPL, VisuCom et SPL

A�n d'illustrer notre propos, nous considérons un service que nous implémentonsdans les quatre solutions de programmation évoquées précédemment (CPL, VisuCom,SPL et JAIN SIP). Ce service est destiné à traiter les appels pour un utilisateur pré-nommé Bob. Lorsque le service reçoit un appel pour Bob, il le transfère directement surson téléphone. Si Bob ne peut répondre (e.g., parce qu'il est absent ou occupé) et quel'appel provient de son responsable, l'appel est alors redirigé sur son téléphone mobile.Sinon, si l'appel ne provient pas de son patron, il est redirigé sur sa boîte vocale. Les�gures 7.10 et 7.11 comparent les di�érentes approches de programmation. La partiehaute de la �gure 7.10 présente les solutions écrites en CPL (partie gauche) et VisuCom(partie droite), alors que la partie basse correspond à la solution écrite en SPL. La �gure7.11 propose, quant à elle, une comparaison entre la version écrite en SPL (partie haute)et celle écrite en JAIN SIP (partie basse).

Lorsque des DSML tels que CPL et VisuCom doivent être traduits directement dansdes environnements d'exécution généralistes, leurs implémentations sont des processusde développement lourds, coûteux et souvent ambigus. L'écart qui existe entre les ser-


vices CPL et VisuCom, représentés à la �gure 7.10, et la représentation JAIN SIP enest une bonne illustration. Dans le cas d'une compilation directe, ce fossé introduit unegrande complexité au niveau du compilateur et augmente la probabilité d'erreurs logi-cielles. Le coût introduit par de tels développements freine la mise en ÷uvre de nouveauxDSML. En outre, chaque DSML est possiblement développé de manière indépendante,empêchant cette approche de passer à l'échelle. Du point de vue de l'ingénierie logicielle,il est plus intéressant que les DSML partagent une couche d'implémentation.

Dans notre approche, ce partage est e�ectué en introduisant SPL comme composantpivot entre les di�érents DSML et les implémentations. Cette architecture simpli�ede manière importante la traduction d'un DSML en une implémentation. Comme lemontrent les di�érentes versions de notre service, la projection entre un DSML et unDSPL est plus directe. En e�et, l'implémentation d'un DSML se focalise sur des aspectsdu domaine lorsqu'un DSPL est ciblé. La compilation devient alors haut niveau, plussimple et réalisable par des outils de transformation, de modèles comme ATL [JK06b]ou de programmes comme Stratego [Vis01] (chapitre 9).

Cette élévation progressive du niveau d'abstraction est parfaitement illustrée parl'exemple des codes de réponses. VisuCom manipule directement les concepts de joi-gnable/injoignable lors d'un transfert d'appel. Ces notions sont compréhensibles par laplupart des développeurs. SPL a�ne cette abstraction en introduisant des codes de ré-ponses hiérarchiques a�n d'expliciter des classes d'erreurs (e.g., /ERROR/CLIENT/BUSY).Il spéci�e ainsi par exemple si l'erreur provient de l'agent utilisateur, du serveur, ou sile correspondant n'a pas été trouvé du fait d'une mauvaise adresse. L'API JAIN SIP,quant à elle, manipule directement des codes numériques (ligne 28 �gure 7.11). À moinsd'avoir des connaissances en code de statuts HTTP, cette représentation est beaucoupmoins explicite.

Cette montée en abstraction permet également d'étager les véri�cations et de lesfactoriser au niveau de SPL. De ce fait, elles ne dépendent plus de la plate-forme cible.Par conséquent, il devient plus facile et plus sûr d'introduire de nouveaux DSML, lors-qu'ils sont implémentés au dessus du DSPL. À titre d'exemple, VisuCom introduit leconcept de contact qui se traduit en identi�ant SIP au niveau de SPL (ligne 7 �gure7.10). SPL véri�e la validité de cette adresse en introduisant un type URI dans sonlangage, alors qu'elle est manipulée sous une simple chaîne de caractères dans JAINSIP (ligne 29 �gure 7.11).

En passant par SPL, l'architecture permet de cacher les complexités de l'interfacede programmation JAIN SIP. Par conséquent, la partie haute du DSPL, c'est-à-direle domaine, est indépendante de son implémentation. De plus, les évolutions des APIn'a�ectent pas les modèles existants ; elles ont seulement un impact sur le compilateurde SPL. Les experts en implémentation peuvent alors décomposer le compilateur a�nde minimiser les e�orts de portage et faciliter la réutilisation. En e�et, les points com-muns et les variations des plates-formes de téléphonie ne sont pas seulement utilisablespour la conception de SPL ; ils peuvent également être exploités pour structurer sonimplémentation. En rendant explicites les points communs des plates-formes, le DSPLfacilite le travail d'implémentation en rendant certaines parties du compilateur inva-riantes. Par exemple, les codes de réponses hiérarchiques de SPL sont traduits dans les

Application de notre approche 91





Fig. 7.11 � Comparaison des approches SPL et JAIN SIP


mêmes valeurs numériques, indépendamment de la plate-forme. En e�et, les codes deréponses font parties de la spéci�cation du protocole ; leurs valeurs sont donc garantiespar la conformité de la plate-forme à la spéci�cation.

En implémentant des familles de systèmes de téléphonie via SPL, les programmesexposent seulement la logique sans rentrer dans les détails de l'implémentation. Ainsi,la conception est seulement concernée par les règles et les contraintes du domaine, ou-vrant la voie à di�érents DSML. Le DSPL représente le point de convergence de toutesles approches, permettant à des développeurs di�érents de programmer à l'aide d'outilsadaptés. De plus, en limitant les impacts sur la compilation vers SPL, l'architecture per-met une évolution rapide de ces langages de plus haut niveau en réponse à de nouveauxbesoins.

7.5 Bilan

A�n de faciliter le développement de services de téléphonie, nous avons conçu et misen ÷uvre deux langages dédiés, SPL et VisuCom. Ces langage o�rent des constructionset des extensions spéci�ques au domaine, qui abstraient la complexité des technologiessous-jacentes. De plus, ils garantissent des propriétés critiques de la téléphonie, bienau-delà de ce qu'il est possible avec des langages généralistes tels que Java, C# ouencore C. Toutefois, ces deux langages n'évoluent pas au même niveau d'abstractionet surtout répondent à des besoins di�érents. SPL vise à libérer le programmeur desdétails d'implémentation et de la complexité des plates-formes, tout en lui permettantd'exprimer des logiques complexes. La �nalité de VisuCom est tout autre. Le but est derépondre aux attentes de non-programmeurs, qui désirent utiliser le langage comme unmoyen d'exprimer facilement les règles de gestion d'appels à appliquer au sein de leurorganisation.

Les deux langages présentés dans ce chapitre illustrent parfaitement les problèmesliés aujourd'hui à la programmation. Les besoins des populations de développeurs peuventêtre très di�érents au sein d'un même domaine, ce qui impose des solutions de pro-grammation di�érentes. L'approche proposée dans ce document est une réponse à cetteproblématique. Les sections suivantes présentent plus en détail sa mise ÷uvre et sesbéné�ces.

Chapitre 8

Méthodologie de compilation deDSL

L'introduction d'un langage dédié de programmation en tant que couche pivot denotre architecture ne résout pas le dé� lié à l'implémentation d'un tel langage. En e�et,le coût de développement d'un DSL est un réel problème (section 3.4.1) et représentegénéralement un point faible vis-à-vis de l'adoption de l'approche par les organisations.A�n d'optimiser notre démarche et de simpli�er la mise en ÷uvre de notre architecture,ce chapitre propose une méthodologie de développement de compilateurs de langagesdédiés [LCRC05], centrée sur l'utilisation d'outils de génération de programme.

Notre approche vise à structurer le développement d'un compilateur de DSL en ledécomposant en facettes, représentant des dimensions de compilation di�érentes (liéesà l'environnement, au langage cible et au programme). Chaque facette peut être implé-mentée de manière modulaire, en utilisant par exemple des aspects, des annotations ouencore de la spécialisation de programme. Parce que ces approches et les outils associéssont haut niveau, ils correspondent aux besoins du DSL, facilitant le développement ducompilateur et le rendant évolutif.

Ce chapitre présente cette méthodologie et l'illustre au travers de la compilation dulangage SPL vers l'API JAIN SIP et son environnement d'exécution.

8.1 Problématique de la compilation d'un DSL

L'approche DSL est aujourd'hui un moyen reconnu pour faciliter la traduction d'unmodèle conceptuel haut niveau en une solution exprimée dans un langage généraliste(General-Purpose Language ou GPL1). Toutefois, cette démarche complexi�e le proces-sus de compilation, notamment à cause de l'écart qui existe entre les niveaux d'abstrac-tion des langages source et cible, dans notre cas respectivement SPL et Java (JAIN SIP).En élevant le niveau d'abstraction, un DSL abstrait davantage de détails qui doiventêtre traduits lors de la compilation.

1Dans ce document, nous utiliserons de manière indi�érente les termes langage généraliste et GPL.

93

94 Méthodologie de compilation

Une compilation di�érente. La nature d'un DSL rend sa compilation très di�é-rente de la compilation d'un langage généraliste. Il s'agit de produire du code GPL,laissant la compilation de plus bas niveau au compilateur du langage généraliste. Paressence, le compilateur du DSL doit dé�nir des correspondances entre des informationshaut niveau et des couches d'implémentation GPL (e.g., objets, intergiciels ou encoreprotocoles). Ainsi, la compilation s'occupe non seulement de la traduction de la lo-gique du programme, mais aussi, par exemple, de la gestion de l'état ou des ressources,d'analyses spéci�ques au domaine ou encore d'optimisations en fonction du contexted'exécution. Il s'agit donc de fournir tous les détails qui permettent de spéci�er l'exécu-tion du DSL. Par conséquent, plus le langage dédié est haut niveau, et plus le besoin entermes de génération de code est important. Concrètement, une ligne d'un programmeécrite dans un DSL se compile traditionnellement dans plusieurs lignes de code GPL.À titre d'exemple, un programme SPL est en moyenne quatre fois plus concis que sonhomologue JAVA basé sur l'API JAIN SIP. Cette augmentation de la quantité de codeà générer complexi�e non seulement le développement du compilateur, mais le rendégalement di�cile à déboguer, tout en augmentant la probabilité d'erreurs de program-mation. Il est en e�et reconnu que la compilation d'un langage de très haut niveau versun langage de plus bas niveau nécessite une décomposition et une "strati�cation" duprocessus (e.g., Fradet[DF98]).

De plus, une caractéristique importante de la compilation de programmes DSL sesitue au niveau de la traduction des nombreux motifs de programme du langage GPL.Le processus de génération de ces motifs peut être relativement complexe, reposantsur des conditions diverses et nécessitant par exemple la manipulation, l'insertion ou lecalcul de nombreuses constantes liées au programme.

Face à ces problèmes, il existe aujourd'hui un véritable manque de méthodologiepour supporter le développement des compilateurs de langages dédiés.

Les informations spéci�ques, un concept clé. La di�érence fondamentale entreun langage dédié et un langage généraliste se situe au niveau des informations spéci-�ques au domaine et de leurs traitements. Du point de vue du concepteur du DSL,ces informations sont au centre du paradigme de programmation. Par construction dulangage, le programmeur est sollicité pour fournir de telles informations. Elles peuventprendre la forme de types, de constructions syntaxiques ou encore de notations dédiées.Elles servent des préoccupations elles aussi spéci�ques au domaine, comme l'interfaçageavec des librairies, l'optimisation ou encore l'instrumentation de code. Les informationsqui ne sont pas spéci�ques sont directement traduites dans la représentation GPL, alorsque celles dédiées au domaine correspondent à des traitements et des interprétationsparticuliers.

Là encore, aucun outil ne semble adapté pour traiter à la fois la nature haut niveaudu langage et la richesse de ses informations dédiées au domaine. De plus, ce manque desupport rend di�cile un traitement modulaire des préoccupations spéci�ques exposéespar le programme.

A�n de répondre aux problèmes suscités par l'implémentation des DSL, la section

Méthodologie de développement de compilateurs 95

suivante présente notre méthodologie de développement de compilateurs de langagesdédiés. L'idée consiste à reposer sur des outils de génération de programme [CE00], a�nde soulager le processus de compilation.

8.2 Méthodologie de développement de compilateurs

Notre approche de la compilation d'un DSL repose sur l'idée de capturer la richessedes informations spéci�ques au domaine incluses dans le langage et de les traiter avecde la génération de programme. Selon les traitements qui leur sont appliqués, ces infor-mations peuvent être utilisées pour servir di�érentes préoccupations d'implémentation.Cela peut être d'ordre fonctionnel comme la gestion de l'état, ou non-fonctionnel commele contrôle de ressources. L'idée est alors de traiter ces préoccupations à travers des outilsadaptés de génération de programme. Cependant, certains outils ne sont utilisables quedans le contexte d'un programme GPL et imposent une structure particulière du pro-gramme pour être e�caces. A�n de résoudre ces problèmes, notre méthodologie reposesur une représentation du programme faisant abstraction des détails d'implémentationet écrite dans le GPL ciblé. Cette représentation est appelée la représentation abstraiteet est basée sur une séparation des préoccupations d'implémentation en dimensions decompilation, que nous nommons facettes.

Notre méthodologie se décompose en deux étapes, comme illustré par la �gure 8.1. Lapremière consiste à générer, à partir d'un programme DSL, la représentation abstraitestructurée correspondante. Il s'agit également d'encoder les informations spéci�ques duDSL sous une forme particulière, telle que par exemple des aspects [KLM+97] ou desannotations [CEI+05], a�n de les rendre manipulables par des outils de génération. Laseconde étape est chargée de realiser l'approche générative a�n de produire le programmeGPL dans son intégralité.

8.2.1 La représentation abstraite

Le point de départ de notre méthodologie réside dans la traduction du programmeDSL vers sa représentation abstraite. Cette représentation expose seulement la traduc-tion de la logique du programme, sans faire apparaître les détails d'implémentation.Elle est dite abstraite car elle inclut des opérations dont l'interprétation n'est pas né-cessairement encore dé�nie ; elle peut donc ne pas être exécutable. Bien qu'abstraite,la représentation générée encode les informations spéci�ques du domaine comprises im-plicitement ou explicitement dans le langage dédié. Cet encodage permet de dé�nir uncontexte dans lequel ces informations peuvent être interprétées par des outils de généra-tion de programme. De plus, la représentation abstraite est structurée selon des régionsde code relatives à un intérêt particulier du point de vue de la compilation. Ce faisant,la représentation devient manipulable par ces outils. A�n de simpli�er notre discours,nous parlons d'unités de compilation pour désigner les di�érentes parties de code res-ponsables de la génération associée à ces outils. Ces unités peuvent correspondre à unaspect de l'approche programmation orientée aspect (Aspect-Oriented Programming ouAOP) ou encore à une annotation de code.


Programme GPL

Représentationabstraite

Compiler

Annotations Aspects …

Outils de Génération de Programmes

ProgrammeDSL

77

structuration encodage

Étape 1

Étape 2

Fig. 8.1 � Méthodologie de développement de compilateurs de DSL

La première étape de compilation se fait donc de manière directe dans la mesureoù elle vise à générer du code abstrait, dans lequel les mécanismes du langage dédié nesont pas encore expansés et laissés non-interprétés.

8.2.2 Les di�érentes dimensions de compilation

Le code généré lors d'un processus traditionnel de compilation se décompose se-lon deux types de préoccupations, fonctionnelles et non-fonctionnelles. De la mêmemanière, a�n de compléter son implémentation, la représentation abstraite fait l'objetd'interprétations di�érentes de la part des approches de génération de programme. Latâche de chacune de ces interprétations peut être caractérisée selon les mêmes critères.Ainsi, une première distinction s'opère entre les unités de compilation fonctionnelleset non-fonctionnelles. D'une part, les unités fonctionnelles visent à dé�nir des procé-dés de génération de code qui viennent compléter la représentation abstraite a�n de larendre exécutable. D'autre part, les unités non-fonctionnelles enrichissent et ra�nentl'implémentation obtenue. Cependant, la compilation d'unités fonctionnelles varie à lafois en fonction du langage GPL cible et de l'environnement d'exécution sous-jacent.De plus, la compilation des unités non-fonctionnelles peut également varier en fonctiondes besoins du programme en termes, par exemple, de performance, de �abilité ou desécurité. A�n de prendre en compte ces spéci�cités mais aussi de rendre l'approcheplus modulaire, nous introduisons des dimensions di�érentes au niveau des unités de

Méthodologie de développement de compilateurs 97

compilation fonctionnelles et non-fonctionnelles. Ces dimensions nous permettent de dé-composer les traitements qui dépendent soit de l'environnement d'exécution, du langageou du programme lui-même. Ces trois catégories de traitements sont appelées facettesde compilation.

Facette environnement d'exécution. Le but de la facette environnement d'exécu-tion est de réduire le fossé entre le modèle du DSL et l'environnement d'exécution cible.Le modèle du DSL, possiblement implicite, est supposé être haut niveau et portable,abstrayant la complexité de l'environnement. Cette facette vise donc à générer le codenécessaire pour interfacer la représentation abstraite avec les couches d'implémentationsous-jacentes. Si nous reprenons notre cas d'étude, la facette environnement d'exécu-tion permet de réduire le fossé entre le modèle de SPL basé sur les gestionnaires derequêtes et l'architecture de gestion événementielle de JAIN SIP. Par exemple, une destâches de cette facette est d'introduire des gestionnaires de requêtes par défaut, dès lorsque le programme SPL ne traite pas tous les cas. En e�et, la simple déclaration d'unevariable au niveau de la session d'enregistrement SPL implique la création d'un étatpar le SIP-SLEE au niveau du gestionnaire de la requête REGISTER. Cependant, parceque ce gestionnaire n'est pas obligatoire en SPL, la méthode correspondante peut nepas être présente dans la représentation abstraite dans le cas où le programmeur nespéci�e aucun traitement particulier. Dans un tel cas, il est tout de même nécessaired'introduire le gestionnaire par défaut, et de générer le code nécessaire au niveau duprogramme GPL cible.

Facette langage. La facette langage est chargée de l'interprétation et de l'expansiondes mécanismes du langage cible, explicites ou non dans la représentation abstraite. Unetelle facette génère les motifs de code intrinsèques au langage. Par exemple, les opéra-tions de routage de tous les services SPL nécessitent d'être analysées pour déterminersi un état doit être géré ou non. Une solution consiste à rendre cette notion explicitedans la représentation abstraite en ajoutant certaines informations à chaque invocationd'opérations de routage. Ceci permet à la facette langage de générer le code adéquat.

Facette programme. La facette programme invoque les traitements du compilateurqui sont spéci�ques au programme. À titre d'exemple, un gestionnaire de requêtes né-cessite des opérations d'extraction d'état qui dépendent des variables de sessions quiapparaissent dans le programme. Un tel traitement est spéci�que à un service SPLdonné et fait donc partie de la facette programme. Un autre exemple de dépendance vis-à-vis du programme est la gestion ou le contrôle des ressources manipulées par le service.

En résumé, grâce à notre approche, il devient possible de décomposer le processusde compilation d'un DSL selon la tâche précise du code généré. Ainsi, nous distin-guons trois catégories de tâches que nous appelons facettes, et qui correspondent à desphases de compilation di�érentes. Une catégorie de facettes adresse la traduction du pro-gramme DSL en environnement d'exécution cible. Une seconde catégorie est dévouée


à la compilation des abstractions du langage, alors qu'une troisième dé�nit le proces-sus de génération de code qui est spéci�que au programme en lui-même. Des outils degénération de programme sont alors utilisés pour dé�nir la compilation de ces facettesdu DSL en termes de processus de génération. Cette approche permet de modulariserle processus global de compilation. Chaque module est responsable d'une partie bienprécise de code à générer a�n de compiler un DSL. De plus, chaque technique générativefournit un paradigme, des abstractions et des outils qui lui sont propres. Le développeurdu compilateur peut alors choisir l'approche de programmation la plus appropriée pourune facette donnée.

Les sections suivantes proposent une illustration de notre méthodologie. Pour cela,nous reprenons l'exemple du compteur exposé dans le chapitre précédent. Le serviceSPL associé est rappelé au niveau de la �gure 8.2.

1. service Counter {2. processing {3. local void log (int); 4.5. registration {6. int count; 7.8. response outgoing REGISTERREGISTER() {9. count = 0;10. return forward ();11. }12.13. void unregisterunregister() {14. log (count);15. }16.17. dialog {18. response incoming INVITEINVITE() {19. response resp = forward ();20. if (resp != /SUCCESS) {21. count++;22. return forward 'sip:[email protected]'; 23. } else {24. return resp;25. }26. }27. }28. }29. }30. }

Fig. 8.2 � Le service Compteur écrit en SPL

8.3 Compilation de la représentation abstraite

La première étape de notre méthodologie consiste à traduire le programme SPLdans une représentation qui abstrait les détails d'implémentation. La �gure 8.3 montrela traduction de notre exemple Compteur (�gure 8.2) dans sa représentation abstraiteécrite en Java/JAIN SIP. Nous pouvons déjà noter que cet extrait présente des di�é-rences avec celui exposant la version complète du service (�gure 7.1). Tout d'abord,

Compilation de la représentation abstraite 99

contrairement à la version complète, la logique du programme est clairement visible etcompréhensible, puisque tous les détails d'implémentation ont été omis. De plus, confor-mément à notre méthodologie, cette représentation abstraite ne présente pas la mêmestructure de programme (e.g., insertion de la méthode handler REGISTER, ligne 4), nile même type de requêtes (e.g., insertion d'un type booléen à la requête sendRequest,ligne 6 ou 13). En e�et, cela résulte de la structuration de programme et de l'encodagede l'information a�n de faciliter une interprétation ultérieure. Ce faisant, cette repré-sentation abstraite se trouve très proche du service SPL. La �gure 8.4 illustre ce pointet montre que les deux versions du service sont fortement semblables rendant ainsi leprocessus de compilation simple et direct.

Comme nous pouvons le voir sur la �gure 8.4 avec les blocs handler REGISTER ouhandler INVITE (lignes 3-6 et 8-10 de la représentation abstraite), la représentationabstraite est une traduction directe de la logique du service. L'organisation de la re-présentation re�ète parfaitement la structure du programme SPL. Ainsi, il est tout àfait possible d'identi�er les di�érents blocs de code où les messages du protocole SIPsont traités et de les mettre en correspondance avec les gestionnaires SPL associés. Demême, les expressions manipulant les variables sont reproduites mot pour mot (e.g., lavariable count).

L'utilisation de l'encodage d'informations sous la forme d'arguments additionnelsest également illustré. Comme indiqué précédemment, la gestion de l'état, notammentsa restauration au niveau d'une transaction, est une notion importante d'un service detéléphonie. L'un des avantages de SPL réside dans l'abstraction faite au niveau de l'ex-pression forward, qui se compile en une transition avec ou sans état selon le contexte.Ce point est illustré par l'interprétation présentée dans la �gure 8.4. Alors que le rou-tage des messages dans SPL ne se soucie pas de la gestion de l'état, cette propriétéest explicitement encodée dans la version GPL abstraite. En e�et, l'encodage de cetteinformation sous la forme d'un booléen additionnel à la méthode sendRequest (lignes5 et 9 de la représentation abstraite) permet de di�érencier les contextes d'utilisationet donc leurs traductions. L'un des avantages est ici de séparer la production de l'infor-mation de son exploitation, laissant son interprétation à d'autres phases de compilation.

Une fois que la représentation abstraite est générée, il s'agit d'utiliser les approchesgénératives a�n de compléter la génération de code ; il devient alors possible d'introduireles détails d'implémentation manquants entre la représentation abstraite du programmeet sa représentation complète (présentées repectivement aux �gures 8.3 et 7.1). A�nd'illustrer notre approche, nous avons choisi trois techniques di�érentes de générationde programme : la programmation orientée aspect, les annotations et la spécialisationde programme. Toutefois, conceptuellement, d'autres approches pourraient être choi-sies. Dans notre cas, l'AOP nous permet d'introduire des comportements transversesdans la représentation abstraite (e.g., du code en prologue et épilogue d'invocationsde l'API JAIN SIP). Les annotations facilitent l'introduction de préoccupations non-fonctionnelles dans le processus de compilation (e.g., consommation de ressources). En-�n, la spécialisation de programme se charge de la génération de code optimisé (e.g.,génération de composants logiciels sur mesure). Les sections suivantes présentent briève-


1. public class Counter implements SipListener {2. Lib lib;3. [...]4. private void handler_REGISTER(Request rq_request, String method) {5. count = 0;6. sendRequest (false, rq_request); /** SPL, ligne 10 **/7. }8. private void handler_unregister(Request rq_request, String method) {9. lib.local.log(getCounter()); /** SPL, ligne 14 **/10. sendRequest (false, rq_request); /** SPL, comportement par défaut **/11. }12. private void handler_INVITE(Request rq_request, String method) {13. sendRequest (true, rq_request); /** SPL, ligne 19 **/14. }15.16. public void processRequest (RequestEvent requestEvent) {17. String method = rq_request.getMethod();18. if (method.equals (Request.REGISTER)) { /** SPL, ligne 5 **/19. if (!lib.registrar.hasExpiresZero (rq_request)) {20. if (!lib.registrar.hasRegistration (rq_request)) { /** SPL, ligne 8 **/21. handler_REGISTER(rq_request, method);22. } else { /** SPL, comportement par défaut **/23. sendRequest (false,rq_request);24. }25. } else if (lib.registrar.hasRegistration(rq_request)){ /** SPL, ligne 13 **/26. handler_unregister(rq_request, method);27. } else { /** SPL, comportement par défaut **/28. sendRequest (false,rq_request);29. }30. }31. if (method.equals (Request.INVITE)) { /** SPL, ligne 18 **/32. if (lib.registrar.hasRegistration (rq_request)) { 33. handler_INVITE(rq_request, method);34. } else { /** SPL, comportement par défaut **/35. sendRequest (false,rq_request);36. }37. }38. [...]39. }40.41. public void processResponse (ResponseEvent responseEvent) {42. String method = rs_request.getMethod();43. int rs_responseCode = rs_response.getStatusCode();44. if (method.equals (Request.INVITE)) { /** SPL, ligne 18 **/45. if (rs_responseCode >= 300) { /** SPL, ligne 20 **/46. count++ ; /** SPL, ligne 21 **/47. AddressFactory addressFactory = lib.getAddressFactory(); 48. SipURI sipURI = addressFactory.createSipURI ("secretary", "company.com");49. rs_request.setRequestURI (sipURI); 50. sendRequest (false, rs_request); /** SPL, ligne 22 **/51. } else {52. sendResponse (true, rs_response); /** SPL, ligne 24 **/53. }54. } else { /** SPL, comportement par défaut **/55. sendResponse (false, rs_response);56. } 57. [...]58. }59.60. public void processTimeout (TimeoutEvent timeOutEvent) {[...]}61. }

Fig. 8.3 � La représentation abstraite du service Compteur écrite en JAIN SIP

Compilation de la représentation abstraite 101

1. service Counter {2. processing {3. local void log (int); 4.5. registration {6. int count; 7.8. response outgoing REGISTERREGISTER() {9. count = 0;10. return forward ();11. }12.13. void unregisterunregister() {14. log (count);15. }16.17. dialog {18. response incoming INVITEINVITE() {19. response resp = forward ();20. if (resp != /SUCCESS) {21. count++;22. return forward 'sip:[email protected]'; 23. } else {24. return resp;25. }26. }}}}}

8. response outgoing REGISTERREGISTER() {9. count = 0;10. return forward ();11. }

18. response incoming INVITEINVITE() {19. response resp = forward ();

SPL

1. public class Counter implements SipListener {2. [...]3. private void handler_REGISTER(Request rq, String method) {4. setCounter(0);5. sendRequest (false, rq); 6. }}7. [...]8. private void handler_INVITE(Request rq, String method) {9. sendRequest(true, rq); 10. }11.12. public void processRequest (RequestEvent requestEvent) {13. String method = rq_request.getMethod();14. if (method.equals (Request.REGISTER)) { 15. if (!lib.registrar.hasExpiresZero (rq_request)) {16. if (!lib.registrar.hasRegistration (rq_request)) { 17. handler_REGISTER(rq_request, method);18. [...] 19. } else if (method.equals (Request.INVITE)) {20. if (lib.registrar.hasRegistration (rq_request)) { 21. handler_INVITE(rq_request, method);22. [...]

3. private void handler_REGISTER(Request rq_request, String method) {4. count = 0;5. sendRequest (false, rq_request); 6.6. }}

17. handler_REGISTER(rq_request, method);

21. handler_INVITE(rq_request, method);

Représentation abstraite

8. private void handler_INVITE(Request rq_request, String method) {9. sendRequest (true, rq_request); 10. }

Fig. 8.4 � Comparaison du service SPL et de sa représentation abstraite

ment chacune de ces techniques avant d'illustrer la compilation des unités fonctionnelles(section 8.4) et non-fonctionnelles (section 8.5).

8.3.1 La programmation orientée aspect

La programmation orientée aspect [KLM+97] est un paradigme de programmationqui permet de réduire fortement les couplages entre les di�érents aspects techniquesd'un logiciel. L'AOP facilite l'encapsulation d'un besoin transverse (e.g., monitoragede programme, authenti�cation ou encore persistance) dans un seul module, appelé unaspect. Ce dernier étend la fonctionnalité d'un objet en y ajoutant un comportementsupplémentaire appelé gre�on (advice). Pour utiliser un aspect, il faut dé�nir des pointsd'exécution (joinpoints), qui correspondent aux endroits spéci�ques dans le �ot d'exé-cution du programme où il est valide d'insérer du code. Ces points sont con�gurés enspéci�ant des points de coupure ou d'activation (pointcut). La dé�nition d'un point decoupure permet de spéci�er plusieurs points d'exécution dans le programme, c'est-à-dire plusieurs endroits où est inséré un même gre�on. Un aspect correspond donc à unmodule dé�nissant des gre�ons et leurs points de coupure.

Selon notre expérience, les unités fonctionnelles de compilation sont particulièrementbien adaptées à la programmation orientée aspect. Cependant, pour être utilisable, l'ap-proche impose une forte structuration de la représentation abstraite a�n de correspondreà l'expressivité du langage de points de coupure. En e�et, il est très important de bienidenti�er les endroits où insérer le code dans la représentation abstraite. L'identi�cation


de ces points du programme implique le remaniement de la représentation abstraiteet l'introduction d'entités langage comme des invocations ou des dé�nitions de mé-thodes, ou encore des déclarations de variables. Ainsi, il peut arriver qu'une séquencede commandes ait besoin d'être placée à l'intérieur d'une méthode de la représentationabstraite a�n de permettre d'insérer du code avant, après ou à la place de son exécution.La partie haute de la représentation abstraite écrite en JAIN SIP (�gure 8.3) montre,par exemple, des méthodes privées (e.g., handler REGISTER) qui ont été introduitespar le compilateur du DSL pour insérer facilement du code au début et à la �n desinvocations des gestionnaires de requêtes SPL.

L'un des avantages de cette technique est de permettre au compilateur de DSL d'êtreconçu et structuré en termes de modules, qui correspondent à des aspects. Chaque aspectdé�nit un comportement spéci�que du DSL dont la nature transverse est véritablementgérée par l'AOP.

8.3.2 Les annotations

En programmation, une annotation [CEI+05] est une approche permettant d'ajou-ter des informations à un programme. Ces annotations peuvent ensuite être utiliséesà la compilation pour automatiser certaines tâches. De même, elles peuvent permettrede générer du code de sorte à traiter de manière spéci�que l'exécution du programme.Ces annotations prennent souvent la forme de commentaires, comme par exemple lesannotations JML (Java Modeling Language) [JP01] de Java. Elles n'a�ectent jamais lalogique du programme mais fournissent seulement des informations sur son comporte-ment. Ainsi, elles permettent de dé�nir des propriétés, des invariants ou des conditions,qui peuvent par la suite être véri�és par un prouveur de cohérence du type Krakatoa[MPMU04]. De telles applications permettent par exemple de savoir si le programmerespecte les annotations, et donc de savoir s'il est correct vis-à-vis de certaines proprié-tés.

Dans notre cas, les annotations peuvent être incluses dans la représentation abstraitea�n de rendre certaines informations explicites lors de la traduction du programme DSL.Comme elles n'in�uent pas sur la logique du programme, les annotations sont tradi-tionnellement utilisées pour exprimer des besoins non-fonctionnels. Ainsi, elles peuventpermettre de rendre la consommation de ressources explicite ou de déclencher des véri-�cations à des points précis du programme.

Comme les aspects, les annotations permettent de modulariser la compilation duDSL parce qu'elles introduisent des informations qui sont par la suite interprétées selonun processeur d'annotations donné. Elles permettent donc de découpler la dé�nition del'information de son exploitation.

8.3.3 La spécialisation de programme

La spécialisation de programme [CD93, JGS93] est une autre technique de program-mation générative. Elle consiste à instancier un programme par rapport à certains deses paramètres d'entrée, permettant ainsi d'obtenir un code adapté pour un contexte

Compilation des unités fonctionnelles 103

d'utilisation donné. Ainsi, la spécialisation permet à des composants logiciels génériquesd'être personnalisés en fonction du contexte dans lequel ils sont utilisés.

Dans notre cas, la spécialisation peut être utilisée plus particulièrement a�n d'opti-miser l'implémentation d'un programme DSL. Parce que les unités de compilation sontinvoquées par le code généré par le compilateur, les contextes de personnalisation sontdéterminés par le compilateur du DSL. En outre, parce que les composants sont �xes, ouévoluent lentement, leur spécialisation peut être déterminée de manière précise. Ainsi,cette transformation de programme peut être prévisible, ce qui n'est pas le cas en gé-néral.

Les deux sections suivantes proposent une illustration de l'application de ces ap-proches de programmation générative au sein de notre méthodologie. Elles montrentcomment ces techniques permettent de compléter notre représentation abstraite entermes de génération de code et de combler les détails d'implémentation à travers lacompilation d'unités fonctionnelles et non-fonctionnelles.

8.4 Compilation des unités fonctionnelles

Le paradigme de la programmation orientée aspect convient particulièrement bienà la compilation d'unités fonctionnelles, qui vise à introduire les mécanismes d'implé-mentation, explicites ou non dans le programme source. De plus, grâce à l'expressivitéde son langage de points de coupure, l'AOP permet d'expanser des parties du codecomplètement di�érentes. Dans les exemples qui suivent, cette stratégie nous a permisd'agir notamment sur les déclarations des méthodes et les manipulations de variables.Ainsi, nous avons utilisé les aspects pour générer l'ensemble des facettes fonctionnellesde compilation, qu'elles soient liées à l'environnement d'exécution, au langage ou auprogramme.

Pour illustrer notre approche, nous avons utilisé un outil connu et éprouvé d'AOPappelé AspectJ [KHH+01]. Il nous a permis de dé�nir la compilation des unités fonc-tionnelles pour SPL. Les limites mises en avant dans les exemples suivants ne sontpas intrinsèques à l'approche AOP, mais davantage spéci�ques à l'outil AspectJ. Parexemple, l'introduction de variables ne peut se faire qu'au niveau d'une classe, et nonà l'intérieur d'une méthode. De plus, les aspects sont sensibles au contexte. Ces li-mitations ont parfois obligé à certaines manipulations de la représentation abstraite(e.g., structuration du programme et introduction de variables) a�n de pouvoir utiliserAspectJ.

8.4.1 Facette environnement d'exécution

Le but de la facette fonctionnelle environnement d'exécution est de réduire la dis-tance entre le modèle du DSL et l'environnement d'exécution cible. Dans notre cas, cettefacette vise à générer le code nécessaire à l'interfaçage entre la représentation abstraitede programme et la plate-forme sous-jacente JAIN SIP. Si nous reprenons le service


JAIN SIP complet présenté à la �gure 7.1, cette étape consiste notamment à extrairedes informations des messages SIP reçus par la plate-forme.

public aspect Environment {

// processRequestpublic Request Counter.rq_request;public SipProvider Counter.rq_sipProvider;

pointcut processRequest():execution(public void Counter.processRequest (RequestEvent));

before (RequestEvent requestEvent, Counter obj): processRequest() && args(requestEvent) && target(obj) {

obj.rq_request = requestEvent.getRequest(); obj.rq_sipProvider = (SipProvider) requestEvent.getSource();

}

// processResponsepublic Response Counter.rs_response;public SipProvider Counter.rs_sipProvider;

pointcut processResponse(): execution(public void Counter.processResponse (ResponseEvent));

before (ResponseEvent responseEvent, Counter obj): processResponse() &&args(responseEvent) && target(obj) {

obj.rs_response = responseEvent.getResponse(); obj.rs_sipProvider = (SipProvider) responseEvent.getSource();

}}

Fig. 8.5 � Aspect correspondant à la facette environnement d'exécution

La �gure 8.5 présente l'aspect Environment responsable de cette facette. Il déclaredeux points de coupures et deux gre�ons, qui correspondent respectivement au code àinsérer au niveau des méthodes processRequest et processResponse de la représen-tation abstraite. Cet aspect implémente le modèle SPL en termes de l'architecture àévènements de la plate-forme JAIN SIP. Pour cela, les gre�ons présentés ici permettentd'extraire respectivement la requête et la réponse courantes correspondant aux objetsrequestEvent et responseEvent générés par la plate-forme. La distribution des re-quêtes selon leur type (e.g., REGISTER ou INVITE) peut alors être faite au niveau de lareprésentation abstraite (lignes 17-18 et 31 de la �gure 8.3) a�n d'invoquer le gestion-naire SPL associé traduit en JAVA. De plus, le code pour extraire l'objet sipProviderest généré a�n d'instancier l'entité capable de manipuler et d'envoyer les messages SIP.

Grâce à cette facette fonctionnelle, la représentation abstraite du programme n'a pasbesoin de s'occuper des détails d'implémentation liés à la plate-forme. Une telle stratégieaide à isoler la génération de programme dépendante de l'environnement d'exécutioncible sous la forme modulaire d'un aspect.

8.4.2 Facette langage

La facette fonctionnelle langage est chargée de l'interprétation et l'expansion desmécanismes du langage cible. Dans notre exemple, cette facette est notamment illustréepar la gestion de l'état et l'implémentation d'opérations de routage avec ou sans étatselon les contextes. En e�et, ces opérations nécessitent la génération de motifs de code


récurrents qui sont liés à l'utilisation de Java et de l'API de programmation JAIN SIP.Les aspects correspondants sont donnés au niveau des �gures 8.6 et 8.7.

Gestion de l'état. Comme l'illustre la �gure 8.3, la logique du programme GPLn'inclut pas de code pour attacher un état à une session et gérer cet état tout au long ducycle de vie de la session. Ainsi, par exemple, l'état associé à la session d'enregistrementa besoin d'être créé lors du traitement de la requête REGISTER et détruit si la requêteéchoue ou si la session se termine (section 7.2). Pour mettre en ÷uvre ce processus, unefacette langage est dédiée à la gestion de l'état. Un extrait de cette facette est exposé àla �gure 8.6.

public aspect Langage {

// Drapeaux indiquant le contexteprivate boolean handler_REGISTER = true;private boolean handler_REREGISTER = false;private boolean handler_unregister = true

public State Counter.state;[...]

pointcut register():execution(private void Counter.handler_REGISTER (Request, String));

before (Request rq, String method, Counter obj): register() &&args(rq, method) && target(obj) {

State state = new State();int ident = obj.lib.env.getId (obj.rq_request);obj.lib.env.setEnv (ident, state);obj.stat = state;

}

pointcut processRequest():execution(public void Counter.processRequest (RequestEvent));

before (Counter obj): processRequest() && target(obj) {if (!handler_REGISTER) {if (obj.method.equals(Request.REGISTER)) {if (!obj.lib.registrar.hasExpirationZero(obj.rq_request)) {if (!obj.lib.registrar.hasRegistration(obj.rq_request)) {State state = new State();int ident = obj.lib.env.getId (obj.rq_request);obj.lib.env.setEnv (ident, state);obj.state = state; }} [...]

} [...]

}

Fig. 8.6 � Aspect correspondant à la facette langage (1)

Le premier gre�on spéci�e le code à exécuter pour la création d'un état d'enregistre-ment lié au traitement de la requête REGISTER. Cependant, parce que le gestionnaire dela requête REGISTER n'est pas obligatoire en SPL, la méthode correspondante peut nepas être présente dans la représentation abstraite dans le cas où le programmeur ne spé-ci�e pas de comportement particulier pour cette requête. Dans un tel cas, le code doittout de même être inséré dans le programme JAIN SIP �nal pour capturer la requêteREGISTER et créer l'état d'enregistrement. Toutefois, la capacité de �ltrage du langage


public aspect Langage {

[...]public Request Counter.rs_request;public ClientTransaction Counter.rs_ct;

pointcut rq_sendRequest():call(public void Counter.sendRequest (boolean, Request)) &&(withincode(public void processRequest (RequestEvent)) || withincode(* Counter.handler_*(..)));

void around (boolean b, Request rq_request, Counter obj): rq_sendRequest() &&args(b,rq_request) && target(obj) {

if (b) {ClientTransaction ct = obj.rq_sipProvider.getNewClientTransaction(rq_request);ct.sendRequest (rq_request);return;} else {obj.rq_sipProvider.sendRequest (rq_request);return;}

}

pointcut processResponse():execution(public void Counter.processResponse (ResponseEvent));

void around (ResponseEvent responseEvent, Counter obj): processResponse() &&args(rs_Event) && target(obj) {

obj.rs_ct = responseEvent.getClientTransaction();if (obj.rs_ct != null) {obj.rs_request = obj.rs_ct.getRequest(); proceed(rs_Event, obj);} else {obj.rs_sipProvider.sendResponse (obj.rs_response);return;}

}[...]}

1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.36.37.

Fig. 8.7 � Aspect correspondant à la facette langage (2)

de points de jonction ne nous permet pas de tester la non-existence de la dé�nitiond'une méthode. Pour résoudre ce problème, cette information est encodée sous la formede drapeaux introduits dans l'aspect (partie haute de la �gure 8.6). Ces drapeaux per-mettent de savoir si le gre�on doit être introduit on non à partir du contexte, commeillustré par l'utilisation du drapeau handler REGISTER. Dans notre exemple, le secondgre�on n'est pas inséré dans la mesure où le drapeau indique que le gestionnaire est déjàprésent dans la représentation abstraite. Ce mécanisme permet de rendre le compilateurcontextuel et d'insérer les mécanismes du langage seulement si cela est nécessaire.

Opérations de routage. Un point important qui complexi�e l'utilisation de l'APIJAIN SIP concerne la gestion du �ot de contrôle au sein du programme (section 7.2.2).En e�et, dans le cas de transactions avec état, lors de la réception d'une réponse, lecode du service doit explicitement associer cette réponse à sa requête initiale. Il estdonc important de di�érencier les envois de requêtes qui nécessitent une restaurationde contexte, car leur compilation est di�érente. Cette propriété est totalement abstraitedans SPL grâce à l'utilisation de l'expression forward. Pour permettre une générationautomatique, cette information est rendue explicite dans la représentation abstraite,


grâce à une analyse du programme SPL. Ainsi, dans la représentation abstraite, lepremier argument de la méthode sendRequest indique si les opérations de routagenécessitent une gestion d'état. L'aspect de la �gure 8.7 (partie haute) décrit le fragmentde code récurrent qui doit être exécuté lors du traitement d'une telle opération. Dansnotre exemple, les appels à la méthode sendRequest (ligne 7) , qu'ils soient à l'intérieurde la méthode processRequest ou au niveau des di�érents gestionnaires, sont compilésen opérations de routage, avec ou sans état, selon le contexte et la valeur de ce premierargument (utilisation du booléen b ligne 13).

De la même manière, le second gre�on permet d'insérer le code nécessaire pourassocier une requête à une réponse au niveau de la méthode processResponse (ligne23). En e�et, ce code restaure l'entité responsable de la transaction (ClientTransactionrs ct ligne 5) à partir de l'évènement ResponseEvent déclenché par la plate-forme (ligne27). Cette entité permet alors de récupérer la requête qui a généré cette réponse (ligne29).

L'utilisation de cette facette fonctionnelle langage permet à la représentation abs-traite du programme d'être plus près de la logique. Par exemple, la gestion de l'étatnécessite une compréhension précise du protocole SIP a�n de déterminer le moment oùles sessions doivent être créées et détruites. Une telle complexité est factorisée dans cettefacette, permettant au développeur du compilateur de s'occuper de ce type de problèmed'implémentation une fois pour toutes et de manière localisée. De plus, cette facette gèred'autres mécanismes d'expansion du langage, non-présentés ici (e.g., gestion de réponseavec état ou encore sauvegarde et restauration de l'état). Toutefois, le mécanisme estidentique et les aspects similaires.

8.4.3 Facette programme

La dernière facette fonctionnelle concerne le code spéci�que au programme. Cettefacette permet de manipuler les informations qui changent d'un service SPL à un autre.Par exemple, la création et la modi�cation de l'état attaché à une session dépendent desvariables de session et des gestionnaires qui les manipulent. La manipulation de tellesvariables est intimement liée au service.

Une telle situation est illustrée par le service Compteur (�gure 8.2), où la variablecount est utilisée par le gestionnaire REGISTER (ligne 9). La manipulation de cettevariable ne dépend ni de l'environnement ni du langage. Ses occurrences conduisent àla déclaration d'un aspect, illustré à la �gure 8.8. Cet aspect insère la dé�nition d'uneclasse State et des méthodes pour accéder à la variable d'instance. De plus, il spéci�eque chaque occurrence de la variable count dans la représentation abstraite doit êtreremplacée pour un accès à l'objet State.

La facette fonctionnelle programme permet donc de dé�nir une compilation du DSLau niveau de la granularité du programme, en utilisant des informations implicites etexplicites du programme source. Elle permet de garder la représentation abstraite plusproche du programme source SPL.

La compilation des unités fonctionnelles a donc permis à travers la programma-


public aspect Program {

public int Counter.count;class State implements Lib.State {private int count;public State() {}void setCounter (int x) { count = x; }int getCounter() { return count; }

}

// Modification de la variablepointcut set_count():

set(int Counter.count);void around (int count, Counter obj): set_count() && args(count) && target(obj) {obj.state.setCounter(count)

}

// Accès à la variablepointcut get_count():

get(int Counter.count);int around (Counter obj): get_count() && target(obj) {return obj.state.getCounter();

}}

Fig. 8.8 � Aspect correspondant à la facette programme

tion orientée aspect de générer la totalité du code nécessaire à l'implémentation duservice. Elle a comblé au niveau de la représentation abstraite les détails manquantsliés à l'environnement, au langage et au programme. Pour être applicable correctement,l'ordre d'insertion des aspects est toutefois important. Par exemple, certains gre�ons dé-�nissent des entités qui sont manipulées par des parties de code d'un autre aspect. Pourrésoudre ce problème, l'AOP permet de dé�nir des relations de précédence entre aspectsa�n de déterminer l'ordre d'exécution des gre�ons. Notre approche par décompositionen facettes s'insère complètement dans cette démarche puisque l'ordre d'insertion re-�ète le niveau de spéci�cité du code à introduire (environnement, puis langage et en�nprogramme).

La modularité introduite par la programmation orientée aspect permet entre autresde limiter les e�ets d'une évolution de l'API de programmation sur la compilation. Ene�et, en localisant le code à introduire dans des aspects bien dé�nis, il su�t de propagerla modi�cation au niveau du gre�on qui se répercutera automatiquement à de multiplesendroits dans le code (e.g., l'envoi de requêtes).

8.5 Compilation des unités non-fonctionnelles

Les unités non-fonctionnelles sont compilées en exploitant des informations qui raf-�nent ou qui étendent l'implémentation de la représentation abstraite du programme.Comme les unités fonctionnelles, la compilation de ces unités couvre toutes les facettesdu DSL, c'est-à-dire environnement d'exécution, langage et programme.

Compilation des unités non-fonctionnelles 109

8.5.1 Facette environnement d'exécution

La spécialisation de programme peut être appliquée au niveau de la facette environ-nement d'exécution a�n d'optimiser le processus de compilation. Cette technique est, ene�et, souvent utilisée avec succès pour personnaliser un environnement d'exécution selonun contexte d'utilisation particulier. Dans notre cas, la plate-forme JAIN SIP est res-ponsable de l'invocation de méthodes spéci�ques dans la représentation abstraite pourle traitement des requêtes et des réponses. Lorsqu'aucune méthode n'est dé�nie dansle programme (e.g., absence du gestionnaire handler REGISTER ou handler INVITE),la plate-forme n'a pas besoin de transférer le message SIP au service. À la place, il estpossible d'accomplir le comportement par défaut de la plate-forme. Un tel �ltrage desmessages est similaire au �ltrage de paquets en réseau, où seuls certains paquets sonttransmis à la couche applicative. La spécialisation de programme a déjà été appliquéedans ce contexte [TCL+00] et a démontré ses béné�ces. Dans notre exemple, une stra-tégie similaire vise à spécialiser le �ltrage des messages de la plate-forme JAIN SIP parrapport aux noms des requêtes présentes dans la représentation abstraite.

Cette approche permet de spécialiser systématiquement et automatiquement lescomposants logiciels génériques, comme la plate-forme JAIN SIP, selon un contexte depersonnalisation dérivé de la représentation abstraite, et donc du service SPL.

8.5.2 Facette langage

Chander et al. [CEI+05] ont récemment proposé une approche de contrôle de res-sources. Leur approche contraint l'utilisation de ressources par rapport à une politiquespéci�ant ce que le programme peut utiliser et les limites d'utilisation correspondantes.L'idée clé est d'assurer que pour chaque opération consommant des ressources, une quan-tité su�sante est toujours disponible. Ils proposent pour cela d'annoter un programmeavec une commande consume e spéci�ant que e unités de ressources sont utilisées, etavec une commande reserve e pour spéci�er que e unités doivent être réservées. L'undes avantages de cette approche est de rendre possible l'utilisation d'un prouveur dethéorèmes pour assurer que les véri�cations adéquates sont réalisées a�n de garantirune utilisation correcte des ressources pour un programme donné. Leur véri�cateur estcomposé de deux composants : un générateur de conditions de sûreté qui extrait desprédicats logiques dont la validité implique la sûreté de l'utilisation des ressources et unprouveur qui prouve les prédicats.

La �gure 8.9 illustre l'application de cette approche à la compilation de la facettenon-fonctionnelle langage. Elle permet d'introduire de la gestion de ressources au seinde notre programme. La partie gauche de la �gure montre un programme SPL où uneliste d'appelants callers est dé�nie, spéci�ant les trois personnes qui sont autorisées àcontacter le propriétaire du service. Si l'appelant n'est pas autorisé, l'appel est redirigésur une liste de quatre opérateurs operators jusqu'à ce que l'un d'entre eux décroche.La représentation abstraite correspondante est représentée sur la partie droite de la�gure.

Dans le domaine de la téléphonie, l'action de transfert d'appel représente une res-


[...]public void processRequest (RequestEvent requestEvent) {String method = rq_request.getMethod();if (method.equals (Request.INVITE)) {if (lib.registrar.hasRegistration (rq_request)) {//@ reserve 4Header from_h = rq_request.getHeader(FromHeader.getName());String FROM = from_h.getDisplayName();int i = 0;int size = callers.size();while (i < size) {String caller = (String) callers.get(i);if (FROM.equals(caller)) {//@ consume 1sendRequest(false, rq_request);return;}i++;} //@ inv(i <= 3, 3 - i)//@ consume 4sendRequest(false, operators, rq_request);return;}[...]}

}[...]

service limit_forward {processing {uri<4> operators = < ... >;uri<3> callers = < ... >;

registration {dialog {

response incoming INVITEINVITE() {foreach (caller in callers) {if (FROM == caller) {return forward;

}} return forward operators;

}}

}}

}

Fig. 8.9 � Annotations correspondantes à la facette langage

source clé parce qu'elle déclenche une chaîne d'opérations qui peuvent être coûteusespour la plate-forme. Il peut donc apparaître intéressant de considérer cette action commeune ressource et de contrôler son utilisation. Pour cela, les opérations de routage de lareprésentation abstraite ont été annotées (consume), ainsi que les boucles, avec l'inser-tion d'un invariant inv(i ≤ 3, 3− i) qui indique que le prédicat i ≤ 3 doit toujoursêtre vrai et qu'au moins 3−i unités de ressources doivent être disponibles. À travers uneanalyse d'annotations, nous pouvons déterminer que cet exemple nécessite, au pire, laréservation de quatre unités de ressources (reserve 4), correspondant au cas où aucunopérateur ne peut prendre l'appel. Ainsi, nous pouvons assurer que su�samment de res-sources ont été réservées avant l'exécution du programme. Notons que nos annotationsconsume sont rendues explicites dans la représentation abstraite, mais qu'elles peuventêtre aussi bien incorporées dans une librairie en étendant l'API JAIN SIP existante.

Cet exemple illustre l'utilisation de traitements non-fonctionnels sur la représenta-tion abstraite. Ainsi, la véri�cation de limites de ressources est introduite par réutilisa-tion d'un langage d'annotations et d'outils existants [CEI+05]. Ce faisant, le dévelop-peur du compilateur de DSL est guidé par le langage d'annotations pour déterminer lesinformations non-fonctionnelles requises dans le programme abstrait. De plus, les anno-tations permettent une modularisation du compilateur et une spéci�cation des tâches,dans la mesure où leur traitement est réalisé indépendamment par un prouveur existant.

8.5.3 Facette programme

Contrairement à la facette fonctionnelle programme qui dé�nit des traitements ducompilateur spéci�ques à un programme donné, la facette non-fonctionnelle programme

Bilan 111

correspond à des traitements d'informations collectées sur ce programme. Si nous consi-dérons l'exemple de la �gure 8.9, une extension de l'approche par annotations pourraitcollecter les annotations reserve pour chaque gestionnaire SPL, a�n de calculer lenombre maximum d'opérations de routage accomplies par le programme. Ce nombrepourrait ensuite être utilisé par une politique de sécurité de l'environnement d'exécu-tion. Ce faisant, certaines restrictions pourraient être appliquées sur le nombre d'opé-rations de routage réalisées par un service SPL, a�n de préserver les performances dela plate-forme. Cette application peut être faite avant l'exécution du programme parrapport aux ressources actuellement disponibles. Ce processus peut être perçu commeun contrôle d'admission. Cette approche pourrait être étendue à toutes les ressourcesconsommées par le programme. Ainsi, un service de téléphonie serait accompagné d'uneliste de ressources nécessaires à son exécution.

Notons que cette facette programme est di�érente de la facette langage présentéeprécédemment. En e�et, la facette langage n'adresse pas la consommation de ressourcesde manière globale au service ; elle assure seulement que la ressource consommée a étéauparavant allouée.

Un problème important du domaine de la téléphonie concerne la facturation. Il esttout à fait possible de prendre en compte cette problématique au niveau d'une facettenon-fonctionnelle programme En examinant le type de traitements de compilation àréaliser pour introduire des opérations de facturation, nous pouvons noter que cettestratégie équivaut à introduire des aspects non-fonctionnels, analogues aux activités demonitorage (e.g., logging). Par exemple, des minuteurs pourraient être déclenchés dansle gestionnaire d'initiation de session d'appel et stoppés dans le gestionnaire de termi-naison d'appel.

La prise en compte des unités non-fonctionnelles a permis d'optimiser et de ra�nerla compilation du DSL. Grâce à ce type de préoccupation et des outils adaptés, ilest également possible d'enrichir le processus en introduisant par exemple du contrôlede ressources ou d'autres traitements sur les informations récoltées au niveau de lareprésentation abstraite. Ce type de démarche est très di�cile à mettre en ÷uvre lorsd'une compilation traditionnelle, car elle est intégrée à la génération de code et queles traitements sont disséminés dans le compilateur. Or, les objectifs de générationfonctionnelle d'un part, et l'optimisation ou l'enrichissement non-fonctionnel d'autrepart, sont complètement di�érents et pour être e�caces, ils doivent être appréhendésde manière distincte.

8.6 Bilan

Le coût de développement d'un langage dédié est aujourd'hui un véritable frein à ladémocratisation de l'approche DSL. Ce processus apparaît souvent complexe et labo-rieux. Dans ce chapitre, nous proposons une approche de développement de compilateursde DSL basée sur l'utilisation d'outils de génération de programme. Notre approche estconstituée de deux étapes : la compilation d'une représentation abstraite et la mise en


÷uvre de techniques de programmation générative. La compilation de la logique produitune représentation GPL qui abstrait les détails d'implémentation tout en étant mani-pulable par des outils de génération de programme. Ces outils permettent de modéliserla nature haut niveau des DSL et de traiter des informations riches et spéci�ques audomaine.

Notre nouvelle utilisation des outils de génération de programme permet d'intro-duire une approche qui facilite le développement de ce nouveau type de compilateurimposé par la nature des DSL. Les paradigmes de programmation haut niveau peuventêtre utilisés pour traiter de manière modulaire les informations et les abstractions dé-diées au domaine. Notre démarche permet ainsi de modulariser le processus tout entierde développement du compilateur, et donc de le simpli�er. Chaque approche généra-tive possède son propre paradigme, ses abstractions et ses outils, dédiés à une famillespéci�que de facettes de programme. Le développeur du compilateur peut alors choisirl'approche la plus appropriée pour une dimension de compilation donnée.

Chapitre 9

Compilation et véri�cation deDSML

L'architecture présentée dans ce document vise à répondre aux problématiques desimpli�cation du développement logiciel et d'augmentation de la productivité. L'ob-jectif est de fournir aux développeurs des solutions adaptées à leurs besoins, tout enpermettant d'assurer les propriétés métiers du domaine.

Pour répondre à ces attentes, l'architecture propose d'élever progressivement le ni-veau d'abstraction en s'appuyant sur des couches de langages dédiés. Ceci permet à lafois de simpli�er le processus de compilation mais également d'ouvrir des perspectivesde véri�cation. Ainsi, il devient possible d'utiliser des outils haut niveau existants a�nde compiler ou encore de raisonner sur un service, car les processus de compilation et devéri�cation deviennent également haut niveau. Ce chapitre a pour but d'illustrer notredémarche dans le domaine de la téléphonie et de démontrer la facilité de réutilisationde ces outils à partir des langages VisuCom et CPL.

Nous illustrons l'approche en utilisant l'outil de transformation de programme Stra-tego/XT, ainsi que le langage de spéci�cation TLA+. Pour cela, deux processus decompilation sont dé�nis pour un programme écrit avec un DSML (e.g., CPL ou Visu-Com). Le premier cible un DSPL (SPL), illustrant un processus de compilation simpleet haut niveau, alors que le second traduit le service dans une spéci�cation TLA+,illustrant la véri�cation de propriétés spéci�ques.

9.1 Introduction

En utilisant un langage dédié de programmation (DSPL) comme une interface entrela modélisation et l'implémentation de solutions, notre architecture simpli�e fortement leprocessus de développement logiciel. En e�et, le DSPL représente le point de convergencede tous les DSML du domaine. Cette approche permet de factoriser et d'automatiserles étapes d'implémentation, augmentant ainsi la productivité logicielle et répondant aubesoin de variabilité des solutions énoncé au chapitre 5.

Cette factorisation au niveau du DSPL introduit une séparation claire des préoccu-

113

114 Compilation et véri�cation de DSML

pations : la compilation et la véri�cation des DSML deviennent indépendantes de cellesdu DSPL.

Compilation simpli�ée. Tout d'abord, l'architecture permet de simpli�er le pro-cessus de compilation en réduisant la distance entre le modèle et son implémentation(réduction du pas de compilation). L'approche permet à un DSML de se concentreruniquement sur la logique du programme et de reposer sur un DSPL existant. La com-pilation du DSML est alors seulement dédiée à la projection de la logique de l'applicationdans le DSPL.

En réduisant ainsi la compilation à la traduction de la logique du programme, l'ap-proche permet d'élever le niveau du processus de compilation, l'amenant à la portéed'outils de génération de programme. Ce faisant, la complexité liée au développementde solutions se voit diminuée ainsi que l'impact de l'évolution des DSML, qui reste limitéà cette étape de compilation sans in�uencer la compilation du DSPL vers l'environne-ment d'exécution.

Véri�cation de propriétés du domaine. La distinction entre la modélisation etla programmation de solutions permet également d'étager la véri�cation de propriétés.En élevant le niveau d'abstraction des services, il est possible de raisonner à un niveausupérieur et donc d'exprimer simplement ces propriétés. Plus nous descendons dans lesniveaux d'abstraction, plus il devient complexe d'expliciter ces propriétés et donc de lesvéri�er. Par exemple, dans le cas d'une solution JAIN SIP, le mécanisme d'exceptionJAVA peut rapidement introduire une modi�cation du �ot de contrôle qui doit être priseen compte. De plus, la complexité d'un tel mécanisme (e.g., à cause de la hiérarchiedes exceptions) fait qu'il devient impossible de déterminer le comportement exact duservice. Étudier le �ot de contrôle d'applications Java est déjà une activité di�cile ensoi [Mye99] ; tenir compte de celui des exceptions rend la tâche très délicate [RM99]. Ladi�usion de l'information dans le code est un autre facteur de complexité qui empêchel'expression simple des propriétés au niveau des couches inférieures aux DSML.

L'approche proposée ici permet de raisonner directement sur la logique de l'applica-tion et donc d'extraire simplement les informations importantes du domaine. Il devientalors possible de générer à partir de ces informations une spéci�cation de l'applicationqui donne lieu à la véri�cation de certaines propriétés.

Ce chapitre présente notre approche pour le traitement des DSML [LCM07, LCM06].Nous montrons que la nature haut niveau de ces langages rend possible l'utilisationd'outils également haut niveau pour compiler et véri�er des modèles. La compilationet la véri�cation de services sont alors ramenées à la dé�nition de processus de gé-nération de programme. Dans notre approche, la compilation a principalement deuxcibles : un DSPL et un langage de spéci�cation formelle d'un outil de véri�cation. Demanière di�érente, chacune de ces cibles est spéci�que à un domaine. Un DSPL o�redes constructions spéci�ques qui facilitent grandement la compilation de modèles, ca-chant les technologies sous-jacentes. Un langage de spéci�cation est un langage dédié

Introduction 115

constitué de notations appropriées a�n de spéci�er formellement et de manière concisela sémantique d'un modèle.

La �gure 9.1 donne un aperçu de notre approche. Elle illustre à la fois le processusde compilation et de véri�cation des modèles écrits dans un DSML (CPL ou VisuCom).Pour cela, nous avons choisi d'utiliser deux outils, (1) un environnement de transforma-tion de programme, appelé Stratego/XT [BKVV06] et (2) un langage de spéci�cationformelle, TLA+ [Lam02], permettant la véri�cation de propriétés spéci�ques. L'outilStratego/XT est utilisé pour générer à partir d'un programme DSML à la fois desprogrammes SPL et des spéci�cations TLA+. La spéci�cation est alors véri�ée par unvéri�cateur de modèles, appelé TLC [YML99]. Ces exemples illustrent la variété de trai-tements et d'outils qu'il devient possible d'appliquer grâce à notre approche en coucheset au haut niveau d'abstraction des DSML.

ProgrammeDSML

Stratego/XT

TLC

ProgrammeSPL

SpécificationTLA+

Rapportd’erreurs

Stratego/XT

Fig. 9.1 � Compilation et véri�cation de DSML

Le travail présenté ici est issu des travaux réalisés en collaboration avec Julien Merca-dal, un doctorant du projet Phoenix. Les sections suivantes visent à illustrer la faisabilitéde l'approche ainsi que ses avantages. Après avoir donné un aperçu des outils utilisés, cechapitre présente les résultats de l'application de ces solutions au domaine de la Télé-phonie sur IP, conformément à notre architecture. Davantage de détails concernant lesoutils mais également les transformations sont disponibles dans le rapport de Master deJulien Mercadal [Mer06] et sur notre site Web [Pho07].


9.1.1 Stratego/XT

Stratego/XT [BKVV06] est un environnement de développement pour la créationde systèmes de transformation autonomes. Il est destiné à l'analyse, la manipulation etla génération de programme, et supporte un large éventail de transformations. Il a déjàpermis le développement de multiples systèmes incluant des compilateurs, des analy-seurs statiques, des optimiseurs dédiés ou encore des générateurs de code. Ce frameworkcomprend le langage Stratego, permettant d'écrire des règles de transformations sur desreprésentations abstraites de programmes, et la collection d'outils et de langages décla-ratifs de XT, qui supporte la génération des composants utiles lors de transformations.

Le langage Stratego. Stratego [Vis01] est un langage haut niveau dédié à la réécri-ture d'arbres sous la forme de règles, constituant l'unité de base des transformations.Soit R le nom d'une règle Stratego et p1 et p2 deux motifs de code ; R s'écrit alors de lafaçon suivante R : p1 -> p2. Appliquer une règle R à un n÷ud N de l'arbre consiste,dans un premier temps, à véri�er si N correspond au motif p1 (pattern matching). S'ily a correspondance alors le n÷ud N est remplacé par une instance du motif p2. Sinon,la règle R n'est pas appliquée.

Stratego utilise également des stratégies de réécriture programmables a�n de contrô-ler l'application des règles. En e�et, traditionnellement, l'ensemble des règles de réécri-ture est appliqué sur un n÷ud jusqu'à ce qu'aucune règle ne puisse plus l'être. Toutefois,cette manière de procéder n'est pas idéale car, par exemple, une règle peut en défaireune autre, ce qui entraîne un problème de terminaison. Un autre con�it peut venir del'ordre dans lequel les règles sont appliquées ce qui peut conduire à des résultats di�é-rents (non-con�uence). Stratego permet donc d'éviter ces problèmes en autorisant lesprogrammeurs à spéci�er l'ordre, les parties du programme ou les phases pendant les-quelles les règles doivent être appliquées via des stratégies de réécriture programmables[Vis05]. Un exemple de stratégie est le suivant : s1 <+ s2 où s1 et s2 sont deux autresstratégies. Cet exemple spéci�e que s1 est d'abord appliquée, puis en cas d'échec, c'estau tour de s2 d'être appliquée. La séparation des stratégies et des règles de réécriturepermet non seulement d'écrire des règles de transformation réutilisables mais égalementde dé�nir des motifs de contrôle indépendants des règles via les stratégies.

En�n, Stratego fournit la possibilité d'exprimer les règles de réécriture dans la syn-taxe concrète du langage [Vis02]. Certaines transformations de programme complexesdeviennent di�ciles à lire, à écrire et à maintenir avec une représentation dans unesyntaxe abstraite car la distance entre les programmes concrets que nous comprenonset les arbres abstraits utilisés pour les transformations est trop importante. De plus,la syntaxe abstraite devient rapidement verbeuse. C'est pourquoi il peut s'avérer inté-ressant d'avoir la possibilité d'écrire des fragments ou bien des règles entières dans lasyntaxe des langages source et cible.

Les outils XT. La collection d'outils XT o�re, quant à elle, un ensemble de com-posants de transformations réutilisables et �exibles, comme des générateurs de parserset de pretty-printers, ainsi que des outils de manipulation de grammaire. À partir de

Introduction 117

grammaires écrites dans le langage de dé�nition de syntaxe SDF (Syntax De�nitionFormalism) [HHKR89], ces composants permettent de générer les di�érentes partiesqui constituent les systèmes de transformation de programme.

Dans notre contexte, Stratego/XT est utilisé pour compiler des services CPL etVisuCom à la fois en programmes SPL et en spéci�cations TLA+. Pour cela, les dé�ni-tions de syntaxe d'entrée et de sortie (respectivement CPL/VisuCom et SPL/TLA+),écrites en SDF, sont utilisées pour générer les di�érents composants intermédiaires, quisont ensuite manipulés par XT a�n de produire un compilateur indépendant basé surles règles de transformation exprimées en Stratego. En suivant ce processus, nous avonsproduit deux compilateurs pour chaque DSML ciblant SPL et TLA+.

9.1.2 TLA+

La véri�cation de modèles (Model Checking) [Hol97] désigne une famille de tech-niques de véri�cation automatique des systèmes informatiques. Il s'agit de tester al-gorithmiquement si un modèle d'un système satisfait une spéci�cation logique, géné-ralement formulée en termes de logique temporelle. Cette technique permet d'analyserexhaustivement l'évolution d'un système à états �nis en simulant l'ensemble de ses exé-cutions possibles. Par exemple, pour démontrer l'absence d'erreurs à l'exécution, il su�tde tester l'absence d'états d'erreurs dans l'ensemble des états accessibles du système.A�n de mettre en ÷uvre ce type de véri�cation au sein de notre architecture, nous avonschoisi d'utiliser un langage de spéci�cation formelle, TLA+ [Lam02]. Une descriptionplus complète du langage et de son fonctionnement est fournie en annexe A.

Le langage TLA+. TLA+ est un langage dédié de spéci�cation basé sur la logiquetemporelle des actions (Temporal Logic of Actions ou TLA) et sur la théorie des en-sembles. La logique temporelle est utilisée pour raisonner sur des propositions dont lavaleur de vérité dépend du temps. Une spéci�cation TLA+ correspond à une descrip-tion de ce qu'un système est supposé faire. Autrement dit, il s'agit de dé�nir tous lescomportements autorisés lors de l'exécution du système. Un comportement est alorsassimilé à une séquence d'états. Le langage permet également d'exprimer des proprié-tés temporelles que le système doit véri�er et qui correspondent aux comportementsattendus.

Une spéci�cation TLA+ est constituée de formules temporelles, de constantes despéci�cation, de variables d'état propres à la spéci�cation, d'invariants concernant cesvariables et d'un ensemble d'actions. Chaque action TLA+ spéci�e de quelle manière lesvaleurs des variables d'état peuvent changer pendant une étape (c'est-à-dire le passaged'un état à un autre), autrement dit quelles sont les transitions autorisées par le pro-gramme. Ainsi, l'exécution d'une spéci�cation peut être vue comme une séquence d'étatsoù chaque état correspond à l'a�ectation d'une valeur à chacune des variables d'étatsdéclarées. À travers ces mécanismes, la spéci�cation permet de simuler l'ensemble desexécutions possibles du système.


La véri�cation de modèles. TLA+ est supporté par un ensemble d'outils (e.g.,SANY, +CAL, TLATeX) et notamment un véri�cateur de modèles appelé TLC [YML99].Ce dernier permet de véri�er automatiquement que les spéci�cations écrites en TLA+satisfont bien les propriétés temporelles dé�nies, sans violer les invariants spéci�és. Ilaide également à trouver les di�érentes erreurs qui se sont glissées dans les spéci�cationsTLA+ en générant les di�érents états possibles du système qui mènent à la violationd'une propriété. TLC distingue deux types d'erreurs : les erreurs de typage et les inter-blocages (deadlocks). Le véri�cateur prend en entrée des spéci�cations TLA+, telles quedé�nies précédemment, et les �chiers de con�guration associés. Ces �chiers de con�gu-ration a�ectent des valeurs aux constantes a�n de donner un modèle pour l'exécution dusystème, et déclarent également les paramètres de la spéci�cation ainsi que les diversespropriétés temporelles à véri�er. TLC fournit en sortie un rapport indiquant, d'unepart, si des erreurs de syntaxe ont été détectées (présence d'un analyseur syntaxique, lefrontal de TLC), et d'autre part, si certaines propriétés temporelles ont été violées lorsde la génération des comportements du système.

Les sections suivantes présentent une illustration de l'utilisation de Stratego etTLA+ au sein de notre architecture. Ces outils permettent respectivement de compilersimplement un service écrit dans un DSML en un service SPL mais aussi de véri�er lespropriétés du domaine. Ils ont été choisis de manière arbitraire et n'ont pour but qued'illustrer notre démarche. Bien évidemment, d'autres outils auraient pu être utilisés.

En ce qui concerne la compilation et la transformation de programme, le langageTXL (Tree Transformation Language) [Cor06], mais aussi l'outil JTS/JAK [BLS98]auraient pu remplacer Stratego. De même, il est tout à fait possible d'utiliser des ou-tils de transformation de modèles. Grâce aux travaux de Frédérick Jouault [JBC+06],nous avons expérimenté cette voie et utilisé l'outil ATL [JK06b] a�n de mettre en÷uvre le processus de compilation de CPL vers SPL [JBC+06]. Les di�érents modèles(méta-modèles, modèle TCS, transformations ATL) qui ont été construits pour cetteapplication sont fournis dans sa thèse [Jou06]. De plus, ce cas d'utilisation d'ATL estpublié sous Eclipse et le code est disponible [eP07]. De la même manière, l'utilisationde TLA+ n'est pas obligatoire et la véri�cation des propriétés aurait pu être basée surd'autres outils ou langages logiques comme Prolog [CM87] ou encore Spin [Hol97].

9.2 Compilation de DSML

Cette section présente une illustration de la compilation de langages dédiés de modé-lisation. Elle vise à mettre en avant combien ce processus est facilité par notre approcheen couches et l'introduction d'un point pivot sous la forme d'un DSPL. Pour cela, ellepropose des extraits de règles de transformation Stratego qui nous ont permis de com-piler les DSML, CPL et VisuCom, dans notre langage dédié de programmation SPL etle langage de spéci�cation TLA+.

Compilation de DSML 119

9.2.1 Compilation vers SPL

Cette section donne un aperçu du processus de compilation d'un DSML vers unDSPL. Elle illustre la démarche en introduisant des exemples de génération de codeSPL à partir de services CPL et VisuCom.

De CPL à SPL. Un extrait des règles de réécriture permettant de compiler un ser-vice CPL en un service SPL est donné à la �gure 9.3. Il représente deux règles detransformation Stratego utilisées lors de la compilation du service de Bob, présenté à la�gure 7.10 et dont les versions CPL et SPL sont rappelées à la �gure 9.2. Rappelons quelorsque ce service reçoit un appel, il le transfère directement sur le téléphone de Bob.Si celui-ci ne peut pas répondre et que l'appel provient de son patron, l'appel est alorsredirigé sur son téléphone mobile. Sinon, si l'appel ne provient pas de son patron, il estredirigé sur sa boîte vocale. La partie gauche des règles de transformation correspondau motif CPL à traduire et la partie droite dé�nit son homologue SPL à générer. Lesrègles Stratego de notre compilateur consistent essentiellement à expliciter l'arbre dedécision formé par le service CPL. Parce que la distance entre les deux langages estréduite, une construction CPL ne nécessite pas un processus de génération complexecomme en témoigne l'exemple de la �gure 9.3. La première règle RuleRedirect portesur la traduction du transfert d'appel et du test sur la réponse. Nous pouvons nousapercevoir que pour ce motif la traduction est directe et quasiment mot pour mot. A�nde manipuler la variable r correspondant à la réponse du transfert d'appel, Strategopermet de générer, via le mot clé new, des variables fraîches avec des noms aléatoires.

La seconde règle RuleFROMTest est issue du test sur l'appelant pour savoir si l'appelprovient du patron de Bob. Là encore, la traduction du motif CPL est quasi immédiateen utilisant la variable SPL prédé�nie FROM. Le haut niveau du processus permet ici derestreindre la compilation à une traduction de la logique.

De VisuCom à SPL. A�n d'illustrer le processus de compilation de VisuCom, nousallons considérer la transformation du motif qui permet de tester si l'appelant appar-tient à un groupe. Le principe est exactement le même que précédemment, excepté quepour des raisons de lisibilité les règles s'appuient cette fois-ci sur une représentationabstraite du langage VisuCom et non sur sa syntaxe concrète. La règle de réécritureRuleGroupTest présentée à la �gure 9.4 transforme tous les n÷uds de l'arbre décisionnelqui testent l'appartenance de l'appelant à un groupe, dans les instructions appropriéesde notre langage dédié de programmation. En SPL, il n'existe pas d'instruction permet-tant de tester directement si une adresse appartient ou non à un groupe de personnes,du moins pas aussi facilement qu'en VisuCom. De ce fait, a�n de tester si la source del'appel appartient au groupe group, plusieurs instructions SPL sont nécessaires. Toutd'abord, une variable, nommée b, est créée et initialisée à la valeur false. Ensuite, uneboucle foreach est utilisée a�n de parcourir l'ensemble des adresses stockées dans laséquence obtenue via l'instruction get addressBook(group), qui regroupe les membresdu groupe. Si une des adresses présentes dans la séquence correspond à FROM (mot cléSPL désignant la source de l'appel), alors la variable b est mise à true et la boucle est


1. <?xml version="1.0" encoding="UTF-8"?>2. <cpl>3. <incoming>4. <location url="sip:[email protected]">5. <proxy>6. <default>7. <address-switch field="origin">8. <address is="sip:[email protected]">9. <location url="tel:+19175554242">10. <proxy />11. </location>12. </address>13. <otherwise>14. <location url="sip:[email protected]">15. <proxy />16. </location>17. </otherwise>18. </address-switch>19. </default>20. </proxy>21. </location>22. </incoming>23. </cpl>



Fig. 9.2 � Comparaison des approches CPL et SPL

RuleRedirect :|[ <location url=callee> <proxy> <default> stat1* </default>

</proxy> </location> ]|->

|[ response r = forward callee ;if (r == /ERROR) {stat1*

} ]|where new => r

RuleFROMTest :|[ <address-switch field="origin"> <address is=caller> stat1*

</address> <otherwise> stat2* </otherwise> </address-switch> ]|->

|[ if (FROM == caller) {stat1*

} else {stat2*

} ]|

Fig. 9.3 � Règles Stratego pour compiler CPL en SPL


quittée via le mot clé break. En�n, si à la sortie de la boucle, la variable b est égale àtrue alors le bloc d'instructions stat1* est exécuté sinon c'est le bloc stat2*.

RuleGroupTest :GroupTest(group, stat1*, stat2*)

->|[ bool b = false ;

foreach (addr in get_addressBook(group)) {if (FROM == addr) {b = true ;break ;

}}if (b) {stat1*

} else {stat2*

} ]|where new => b; new => addr

Fig. 9.4 � Règle Stratego pour compiler VisuCom en SPL

Les autres règles de réécriture pour transformer un service CPL ou VisuCom en SPLsont toutes aussi simples que celles présentées ici. Ainsi, parce que le fossé séparant ceslangages, et plus généralement un DSML de son DSPL, est réduit, le processus decompilation devient très facile. En e�et, toute la complexité engendrée par les diversesplates-formes de téléphonie et les di�érents détails d'implémentation a été capturée parle compilateur de SPL. En ciblant ce DSPL, le compilateur du DSML se concentresur des aspects dédiés au domaine et n'est chargé que de la traduction de la logiquedu programme. À titre indicatif, en ce qui concerne la compilation de VisuCom, latraduction fait seulement état d'une dizaine de règles de transformation.

9.2.2 Compilation vers TLA+

A�n de véri�er des propriétés du domaine, notre approche propose de déduire unespéci�cation TLA+ depuis un service écrit dans un DSML. Cette spéci�cation sera parla suite véri�ée aux vues de certaines propriétés énoncées dans la section suivante. Pourdes raisons de lisibilité et de compréhension, nous présentons ici seulement deux extraitsde règles de compilation1. La première concerne la traduction d'un motif de �ltrageCPL sur le jour de l'appel. Cet exemple est mis en avant car ce point fait l'objet d'unepropriété à véri�er, présentée dans la section suivante. La seconde règle propose quant àelle la compilation du motif VisuCom évoqué précédemment concernant l'appartenancede l'appelant à un groupe donné.

De CPL à TLA+. Compiler un service écrit en CPL dans une spéci�cation TLA+ estéquivalent à dé�nir une abstraction qui modélise les aspects du DSML pour lesquels unevéri�cation est nécessaire. De manière spéci�que, notre abstraction consiste à modéliser

1Si le processus de traduction est en soi identique à celui présenté précédemment, la traduction estici beaucoup plus verbeuse.


les prédicats utilisés pour déterminer les décisions de routage incluses dans un service. La�gure 9.5 montre un exemple de règle Stratego, RuleTimeDay, qui dé�nit une abstractiondu �ltrage d'appels en fonction d'un calendrier. Plus spéci�quement, elle génère lesformules TLA+ pour un prédicat qui teste le jour de l'appel. A�n de pouvoir utiliserle langage de spéci�cation et se ramener à une notation ensembliste, cette abstractionsuppose qu'un jour est représenté sous la forme d'un enregistrement à trois éléments,constitué de son nom, son numéro dans l'année et le nom du mois. Contrairement àprécédemment, pour des besoins de lisibilité de l'exemple, cette règle présente le motifCPL sous sa forme abstraite.

La règle de réécriture présentée ici ajoute deux nouvelles actions à la spéci�cationTLA+ qui doit être générée. Comme dans l'exemple précédent avec la variable b, lesnoms de ces actions, représentées par les variables ifThen et ifElse (respectivementlignes 5 et 11), sont générés aléatoirement par Stratego (lignes 29). Il en est de mêmepour la variable str de la règle de réécriture. Cette variable représente une chaîne decaractères permettant d'identi�er le n÷ud qui teste le jour de l'appel. Le mot clé new deStratego a donc permis de générer un identi�ant unique pour la spéci�cation. Toutefois,cet identi�ant a besoin d'être mis entre guillemets au niveau de TLA+, ce que faitla fonction <double-quote> de l'API Stratego (lignes 6 et 12). Ensuite, les variablesstr1 (ligne 3) et str2 (ligne 4) de la règle de réécriture représentent respectivement lesidenti�ants des prochains n÷uds à visiter selon le cas du succès (thenNext, ligne 17)ou de l'échec (elseNext, ligne 23) du test. De ce fait, la variable d'état currentNodede l'action ifThen doit prendre la valeur str1 dans le prochain état (ligne 7) et cellede l'action ifElse la valeur str2 (ligne 13).

De plus, en fonction du résultat du test, les variables de la spéci�cation doiventêtre modi�ées en conséquence. Dans notre cas, cela concerne notamment la variabledate qui contient l'ensemble des valeurs des jours qui ont véri�é ou non le prédicatselon le cas de �gure. Les autres variables restent inchangées par l'action (UNCHANGED)(lignes 9 et 15). Ainsi, l'action ifThen, qui représente le succès du test, permet d'incluredans date les jours qui véri�ent le prédicat (ligne 8). À l'inverse, l'action ifElse inclutl'ensemble complémentaire (ligne 14). Le �ltrage sur un jour est alors ramené à un calculensembliste.

En�n, ces deux actions doivent être ajoutées à l'ensemble des actions accessibles a�nd'être prises en compte par le véri�cateur de modèles. C'est le rôle de la règle dynamiquenommée Next (lignes 30-34). Elle permet d'ajouter à l'action Next de la spéci�cationTLA+ les deux disjonctions correspondantes aux nouvelles actions ifThen et ifElse.Cette action est par la suite utilisée par le véri�cateur a�n de choisir la prochaine actionautorisée à s'exécuter lors de toutes simulations.

De VisuCom à TLA+. La �gure 9.6 représente un extrait des règles de réécriturepermettant de transformer un service de téléphonie développé avec VisuCom dans unespéci�cation TLA+. Cet extrait représente une règle nommée RuleGroupTest qui trans-forme tous les n÷uds de l'arbre décisionnel testant l'appartenance de l'appelant à ungroupe donné, en deux actions TLA+, représentant comme précédemment le succès oul'échec du �ltrage.


RuleTimeDay :DayTest(String(day),

[Action(Id(thenNext), Conjunction([Eq(Id(id3), String(str1)), rest1*])), action1*],[Action(Id(elseNext), Conjunction([Eq(Id(id4), String(str2)), rest2*])), action2*]) ->

|[ ifThen ≜∧ currentNode = <double-quote> str∧ currentNode’ = str1∧ date’ = {t ∈ date : t.day = day}∧ UNCHANGED ...

ifElse ≜∧ currentNode = <double-quote> str∧ currentNode’ = str2∧ date’ = {t ∈ date : t.day ≠ day}∧ UNCHANGED ...

thenNext ≜∧ id3 = str1∧ rest1*

action1*

elseNext ≜∧ id4 = str2∧ rest2*

action2* ]|

where new => ifThen ; new => ifElse ; new => str; rules ( Next :+ Action(Id("Next"), Disjunction(exp*)) ->

|[ Next ≜∨ exp*∨ ifThen∨ ifElse ]| )

1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.

Fig. 9.5 � Règle Stratego pour générer une spéci�cation TLA+ depuis CPL

Le principe est ici exactement le même que dans le cas de l'exemple CPL, hormis lamodi�cation des variables liée à l'action. A�n de garder une trace de la succession destests sur l'appelant, la spéci�cation utilise une variable d'état nommée callerTests

(lignes 8 et 14). Cette variable stocke, sous la forme d'une séquence d'ensembles, lespersonnes susceptibles d'appeler le propriétaire du service en fonction de la succes-sion de prédicats. Cet ensemble ne doit donc jamais être vide, synonyme d'un pointdu programme inaccessible car aucun contexte n'est compatible avec le service. Cettesituation fait l'objet d'une propriété à véri�er au niveau de VisuCom, présentée à lasection suivante. Ainsi, l'action ifThen ajoute à la séquence callerTests les adressesdes personnes qui appartiennent au groupe group (ligne 8), alors que l'action ifElse

ajoute l'ensemble des adresses des personnes n'appartenant pas au groupe (ligne 14). Làencore, la règle Next est appliquée (lignes 30-34). Une seconde règle dynamique permetquant à elle d'ajouter aux constantes de la spéci�cation TLA+ le groupe group dans lecas où il n'y serait pas encore (lignes 36-38).

L'approche en couches permet donc de réaliser une compilation par petits pas, sim-pli�ant considérablement le passage d'un DSML à son implémentation concrète ou à saspéci�cation TLA+. De par le haut niveau des langages employés ici (CPL, VisuCom,SPL et TLA+) et le fait que les DSML manipulent seulement la logique du programme,les processus de transformation se concentrent sur le domaine et la compilation de-


RuleGroupTest :GroupTest(group,

[Action(Id(thenNext), Conjunction([Eq(Id(id3), String(str1)), rest1*])), action1*],[Action(Id(elseNext), Conjunction([Eq(Id(id4), String(str2)), rest2*])), action2*]) ->

|[ ifThen ≜∧ currentNode = <double-quote> str∧ currentNode’ = str1∧ callerTests’ = Append(callerTests, group)∧ UNCHANGED ...

ifElse ≜∧ currentNode = <double-quote> str∧ currentNode’ = str2∧ callerTests’ = Append(callerTests, Contacts \ group)∧ UNCHANGED ...

thenNext ≜∧ id3 = str1∧ rest1*

action1*

elseNext ≜∧ id4 = str2∧ rest2*

action2* ]|

where new => ifThen ; new => ifElse ; new => str; rules ( Next :+ Action(Id("Next"), Disjunction(exp*)) ->

|[ Next ≜∨ exp*∨ ifThen∨ ifElse ]| )

; rules ( CstGroup :+ Constants(id*) ->|[ CONSTANTS id*, <double-quote> group ]|

where not(<elem> (Id(<double-quote> group), id*)) )

1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.36.37.38.

Fig. 9.6 � Règle Stratego pour générer une spéci�cation TLA+ depuis VisuCom

vient alors haut niveau et à la portée d'outils dédiés comme Stratego/XT. De plus, ilest important de noter que le compilateur d'un DSML devient ainsi indépendant de laplate-forme d'exécution.

9.3 Véri�cation de DSML

À partir des spéci�cations TLA+ générées depuis les services écrits dans les DSML,il devient possible d'assurer que ces derniers respectent les propriétés du domaine.Contrairement aux véri�cations e�ectuées au niveau de SPL (section 7.2.3), ces pro-priétés concernent le langage mais aussi l'intention du développeur et la sémantique duservice dans son intégralité. Ces deux derniers points se voient considérablement sim-pli�és car CPL et VisuCom ne manipulent que des informations et des calculs dédiésau domaine ; il devient donc plus facile de raisonner dessus.

Les propriétés spéci�ques au domaine sont exprimées sous la forme de formulesTLA+ qui sont véri�ées par le véri�cateur de modèles TLC. À titre d'exemple, certaineslimitations sémantiques de CPL ont déjà été identi�ées par Nakamura et al. [NLMK03].Les résultats obtenus montrent l'importance de véri�er les propriétés spéci�ques au

Véri�cation de DSML 125

domaine par rapport au contexte du service (e.g., interaction de services et identi�cationdes intervenants). Des exemples de telles propriétés sont donnés à la �gure 9.7, sous laforme de formules TLA+. Les sections suivantes examinent ces dernières à la fois dupoint de vue de CPL et de VisuCom. Elles présentent des cas concrets d'exemples écritsdans ces DSML qui obligent ces propriétés à être véri�ées [Pho07].

NoTwiceRedirectToTheSameURI ≜□ (∀n ∈ 1..Len(signalingActions) : ∀m ∈ n+1..Len(signalingActions) :

signalingActions[n] ≠ "Continuation" ⇒ signalingActions[n] ≠ signalingActions[m])

NoRedirectToTheCaller ≜□(∃x ∈ Contacts :

∧ ∀n ∈ 1..Len(callerTests) : x ∈ callerTests[n]∧ ∀m ∈ 1..Len(signalingActions) : signalingActions[m] ≠ x)

Consistency ≜∧ □(∃x ∈ Contacts : ∀n ∈ 1..Len(callerTests) : x ∈ callerTests[n])∧ □(date ≠ {})

Fig. 9.7 � Extrait des propriétés à véri�er pour un service de téléphonie

9.3.1 Véri�cation de services CPL

Cette section vise à illustrer chacune des propriétés présentées ci-dessus, en consi-dérant des services écrits en CPL.

Aucune duplication de redirection. Cette propriété assure que, dans un mêmechemin d'exécution, l'appel n'est pas redirigé deux fois vers la même personne (pro-priété NoTwiceRedirectToTheSameUri de la �gure 9.7). La téléphonie est un domaineoù le temps d'exécution du service est une donnée importante correspondant au dé-lai d'attente de l'appelant. Si, lors de l'exécution d'un service, une personne n'est pasjoignable, il est peu probable qu'elle le soit une fraction de seconde plus tard. Cette pro-priété permet donc de détecter des opérations inutiles, mais aussi de réduire le tempsd'exécution du service à son minimum. Pour cela, elle nécessite l'introduction d'unetrace des opérations de signalisation pour formuler que deux actions d'un même che-min d'exécution ne sont jamais équivalentes. Cette trace est réalisée grâce à la variabled'état signalingActions, qui contient l'ensemble des adresses sur lesquelles le servicea déjà redirigé les appels. La propriété revient donc à contrôler qu'aucun doublon parmiles diverses adresses de redirection n'est présent dans la séquence signalingActions.En�n, cette formule doit toujours être vraie, comme indiqué par l'opérateur logique '�'(voir annexe A pour plus de détails).

Aucune redirection sur l'appelant. Cette propriété (NoRedirectToTheCaller dela �gure 9.7) véri�e qu'il n'existe aucun chemin d'exécution où l'appel est redirigé surl'appelant. En e�et, cette situation n'est généralement pas souhaitable par le dévelop-peur dans la mesure où elle empêche implicitement l'appelé d'être joignable par cettepersonne.


Aucun chemin infaisable. La propriété Consistency assure qu'une cascade de testsest correcte dans le sens où chacun des tests est faisable. En e�et, si syntaxiquementcertains tests apparaissent totalement corrects, leur succession peut poser des problèmesde consistance. Deux types de �ltrage CPL sont pris en compte : (1) les �ltrages sur lesadresses, c'est-à-dire les identi�ants des appelants et (2) les �ltrages sur les dates.

Appel entrant

...

oui non

L’adresse de l’appelantprovient-elle du domaine

"example.com" ?

Redirection de l’appel sur la

boîte vocale de Bob



L’adresse de l’appelantprovient-elle du domaine

"work.example.com" ?

Rejet de l’appel

oui non

2

5

3

76

4

1

Fig. 9.8 � Service CPL inconsistant (adresses)

La �gure 9.8 présente une représentation logique d'un service erroné concernantune succession de tests sur le domaine d'où provient l'appel. À l'arrivée d'un appel,si l'adresse de l'appelant appartient au domaine example.com (n÷ud 2), l'appel estredirigé sur le téléphone mobile de Bob (n÷ud 3). Dans le cas contraire (n÷ud 4), sil'appelant appartient au domaine work.example.com (n÷ud 5), alors l'appel est redirigésur sa boîte vocale (n÷ud 6). Néanmoins, ce cas ne peut jamais se produire parce qu'ilest inclus au niveau du n÷ud 2. Ainsi ce service est totalement correct du point de vuedu langage CPL, mais il contient cependant une inconsistance dans les décisions sur lesadresses entraînant l'infaisabilité de la séquence 1-2-4-5-6. En programmation, ce codecorrespond à du code mort. Cet exemple est similaire à celui présenté à la �gure 4.2 dela section 4.4. Ce dernier repose non pas sur un problème d'identi�cation du domainemais directement sur l'adresse de l'appelant. Une telle cascade de tests est relativementfréquente au niveau de la programmation de services de téléphonie écrits en CPL.

Sur le même principe, il peut arriver qu'un enchaînement de tests sur des évènementsd'un calendrier puisse produire le même type d'inconsistance. En e�et, considérons leservice illustré par la �gure 9.9. Ce service traite les appels di�éremment selon le jour dela semaine et notamment si ces derniers se produisent le mardi (e.g., jour de la réunionhebdomadaire). Si tel est le cas, le service teste par la suite si l'appel a lieu entre le12/07 et le 17/07 a�n d'aiguiller l'appel sur la boîte vocale pendant cette période (e.g.,


vacances annuelles). Cependant, il n'y a aucun mardi pendant cette période et donc, làencore, le chemin 1-2-3-4-5 n'est pas réalisable.

Appel entrant

...

oui non

L’appel a-t-il lieuun mardi ?

Redirection de l’appel sur la

boîte vocale de Bob


téléphone de Bob

L’appel a-t-il lieuentre le 12/07et le 17/07 ?



oui non

1

2

7

4

5 6

3

réunionhebdomadaire

vacancesannuelles

Fig. 9.9 � Service CPL inconsistant (dates)

La nature verbeuse de CPL (dialecte XML) ne facilite pas la détection de tels con�itslors de services plus complexes. De plus, de multiples aspects du langage peuvent êtretestés de la même manière. Ces exemples montrent bien le besoin de véri�cation deservices et notamment de faisabilité des branches d'exécution.

Pour compléter cette illustration, nous présentons à la �gure 9.10 le résultat de lavéri�cation du service CPL contenant une inconsistence au niveau des dates (�gure9.9). Cet extrait présente le rapport d'erreurs produit par TLC. Dans cette situation,TLC spéci�e qu'une propriété ne peut pas être véri�ée (ici Consistency, �gure 9.7) eta�che le numéro de la ligne où l'invariant a été violé, c'est-à-dire date 6= {}. Ensuiteil génère un contre-exemple illustrant la séquence d'états qui a mené à la violation del'invariant (état 4, avec date = {}). Cette illustration montre bien que la générationd'une spéci�cation TLA+ à partir d'un service CPL permet de véri�er de manièreautomatique des propriétés importantes pour le domaine.

Interaction de services. Si un service peut sembler correct individuellement, soninsertion dans un environnement d'exécution nécessite la prise en compte du contexteet notamment des services déjà existants. En e�et, l'interaction entre plusieurs ser-vices peut entraîner des comportements non souhaités, voire corrompre la plate-forme.L'exemple le plus simple consiste à introduire une boucle in�nie entre les services. Sup-posons trois utilisateurs, Bob, Alice et John. Si Bob renvoie tous ses appels sur Alice,qui redirige tous ses appels sur John, qui les transfère à Bob, alors il est impossiblede joindre l'une de ces personnes. L'appel va boucler indé�niment au sein de la plate-forme, qui sans une détection de cette interaction va produire des appels, consommerdes ressources et �nir par s'e�ondrer. Or, au sein d'une spéci�cation TLA+, il est tout à


TLC Version 2.0 of January 16, 2006Model-checking...Finished computing initial states: 1 distinct state generated.Error: Invariant line 143, col 23 to line 143, col 35 of module CPL is violated.

The behavior up to this point is:STATE 1: <Initial predicate>

∧ callerTests = 〈〉∧ currentNode = "Incoming"∧ signalingActions = 〈〉∧ date = {[day ↦ "sun", dayNum ↦ 1, month ↦ "January"],

...[day ↦ "sun", dayNum ↦ 365, month ↦ “December"] }

STATE 2: <Action line 51, col 9 to line 53, col 60 of module CPL>∧ callerTests = 〈〉∧ currentNode = "WeeklyMeeting"∧ signalingActions = 〈〉∧ date = {[day ↦ "sun", dayNum ↦ 1, month ↦ "January"],

...[day ↦ "sun", dayNum ↦ 365, month ↦ “December"] }

STATE 3: <Action line 98, col 9 to line 101, col 54 of module CPL>∧ callerTests = 〈〉∧ currentNode = "AnnualHolidays"∧ signalingActions = 〈〉∧ date = {[day ↦ "tue", dayNum ↦ 3, month ↦ "January"],

...[day ↦ "tue", dayNum ↦ 192, month ↦ "July"],[day ↦ "tue", dayNum ↦ 199, month ↦ "July"],...[day ↦ "tue", dayNum ↦ 360, month ↦ "December"] }

STATE 4: <Action line 110, col 9 to line 113, col 55 of module CPL>∧ callerTests = 〈〉∧ currentNode = "RedirectToBobVoiceMail"∧ signalingActions = 〈〉∧ date = {}

5 states generated, 5 distinct states found, 2 states left on queue.The depth of the complete state graph search is 4.

Fig. 9.10 � Rapport d'erreurs TLC concernant un service CPL

fait possible de manipuler d'autres spéci�cations et d'interagir avec elles. Ceci permet,entre autres, de détecter ce type d'interaction de services. En e�et, le fait de pouvoirexplicitement déterminer quel service doit être exécuté permet de connaître la spéci�ca-tion à véri�er ultérieurement. Il su�t alors de l'initialiser avec les valeurs des variablesd'état de l'exécution de la spéci�cation précédente pour introduire une continuation auniveau de la simulation. Ceci permet de véri�er des propriétés supplémentaires et, parexemple, d'assurer qu'il n'y a pas de boucle entre les di�érents services.

9.3.2 Le cas particulier du modèle VisuCom

La particularité du modèle VisuCom, basé sur le couplage d'un arbre de décisionset des informations issues d'une base de contacts (section 7.3.2), fait que certainespropriétés à véri�er se traduisent di�éremment de celles de CPL. C'est notammentle cas de la propriété Consistency.

Les informations du système d'informations évoluant avec la vie de l'organisation,


le contenu de la base de contacts évolue également. Ce faisant, il peut arriver que lesservices mis en oeuvre ne soient plus en adéquation avec le contenu de la base. Le traite-ment des appels peut alors devenir obsolète voire incohérent suite à une modi�cation del'information paramétrant ce traitement. Il est ainsi possible qu'un service soit correctà un instant donné mais produise des erreurs ultérieurement. Il est donc primordial derépondre à ce besoin et de véri�er à tout moment la cohérence entre un processus detraitement d'appels téléphoniques et les informations le paramétrant. Cela se traduitpar la véri�cation de la réalisabilité des décisions de routage en fonction des informa-tions contenues dans la base de contacts (principalement les correspondants et leurscaractéristiques).

Il est important de comprendre que la spéci�cation TLA+ d'un service VisuComreprésente une abstraction à un certain moment de la vie de ce service. A�n de prendreen compte l'évolution de la base, il s'avère donc indispensable de générer, chaque foisque la base de contacts évolue, un nouveau �chier de con�guration pour la spéci�cationTLA+ du service (section 9.1.2). Il devient alors possible de préserver une consistanceet une cohérence entre les deux et ainsi de pouvoir véri�er les diverses propriétés.

A�n de mieux illustrer la possibilité de con�it entre un service VisuCom et la basede contacts, considérons l'exemple donné à la �gure 9.11. À la réception d'un appel, leservice teste si l'appelant fait parti du groupe client. Si c'est le cas et que le client est unclient premium, alors l'appel est transféré ; dans le cas où le client n'est pas premium,l'appel est redirigé vers la secrétaire. Si l'appelant n'est pas un client, alors l'appel estrejeté. Considérons l'hypothèse suivante : dans la base de contacts, à l'instant précisoù ce service est exécuté, aucune personne du groupe client ne possède la caracté-ristique premium. De ce fait, l'appel ne sera jamais transmis au client du service. Laspéci�cation TLA+ formule cette propriété (Consistency) en véri�ant que, pour toutcomportement, il existe au moins une adresse de Contacts qui appartient à chacun desensembles présents dans la séquence callerTests. Rappelons que cette variable d'étatreprésente la séquence des ensembles résultants des di�érents prédicats relatifs à l'appe-lant pour un même chemin d'exécution. Dans notre exemple, la séquence callerTests,au niveau du n÷ud Transférer l'appel, contient l'ensemble des adresses appartenant augroupe client et l'ensemble des adresses de la base de contacts qui possèdent la ca-ractéristique premium. Au regard des hypothèses, l'intersection des deux ensembles estdonc vide. La �gure 9.12 présente le rapport d'erreurs fourni par TLC lors de la simula-tion de ce service avec un �chier de con�guration répondant aux hypothèses énoncées.Ce rapport indique qu'une propriété temporelle a été violée et fournit une séquenced'états qui ne véri�e pas la propriété. Ainsi, à l'état 4, la variable d'état callerTestscontient les deux ensembles suivants : {"Alice", "Bob", "Daniel"} et {"Franck"} et doncl'intersection est bien vide. La propriété Consistency peut également couvrir d'autresproblèmes, comme par exemple le �ltrage d'appels sur une personne qui n'apparaît plusdans la base de contacts.

La nature haut niveau et dédiée des DSML facilite donc l'expression des propriétésspéci�ques au domaine et leurs implémentations dans des outils de véri�cation existantscomme TLA+. Ce faisant, il devient possible d'assurer que les services sont corrects


Fig. 9.11 � Service VisuCom inconsistant vis-à-vis de la base de contacts

TLC Version 2.0 of January 16, 2006Model-checking...Finished computing initial states: 1 distinct state generated.Error: Invariant line 184, col 19 to line 184, col 32 of module VisuCom is violated.

The behavior up to this point is:STATE 1: <Initial predicate>

∧ callerTests = 〈〉∧ currentNode = "Incoming"∧ signalingActions = 〈〉

STATE 2: <Action line 32, col 9 to line 34, col 54 of module VisuCom>∧ callerTests = 〈〉∧ currentNode = "ClientGroup"∧ signalingActions = 〈〉

STATE 3: <Action line 37, col 9 to line 40, col 53 of module VisuCom>∧ callerTests = 〈 {"Alice", "Bob", "Daniel"} 〉∧ currentNode = "Premium"∧ signalingActions = 〈〉

STATE 4: <Action line 49, col 9 to line 52, col 59 of module VisuCom>∧ callerTests = 〈 {"Alice", "Bob", "Daniel"}, {"Franck"} 〉∧ currentNode = "Transmettre"∧ signalingActions = 〈〉


Fig. 9.12 � Rapport d'erreurs TLC concernant un service VisuCom

Travaux connexes à notre approche en couches 131

vis-à-vis du domaine et que toute incohérence est détectée. Cette technique permet éga-lement d'aller plus loin dans la véri�cation. En e�et, il est tout à fait envisageable devéri�er des propriétés plus spéci�ques à l'application développée. Par exemple, assu-rer qu'une secrétaire ne passe pas d'appels à l'étranger ou encore que les appels sontultimement transmis à une boite vocale sont deux véri�cations facilement réalisables.

Il faut tout de même noter que les véri�cations ci-dessus auraient pu être réaliséesau niveau de SPL, puisque ce dernier représente le point de convergence des DSML.Cependant, les langages dédiés de modélisation exposent ces informations à un niveauqui rend leur traduction vers une spéci�cation TLA+ beaucoup plus simple. SPL estplus bas niveau et expose davantage de détails (e.g., abstraction du protocole SIP) quidoivent également être modélisés. Ainsi, l'e�ort de traduction aurait été plus important.

9.4 Travaux connexes à notre approche en couches

Le domaine des langages dédiés est aujourd'hui en plein essor du fait de son po-tentiel pour améliorer le développement logiciel. De nombreuses approches et outilsont été proposés pour développer des DSL, adressant à la fois leur conception et leurimplémentation.

Concernant leur conception, comme indiqué dans le chapitre 2, plusieurs environne-ments de développement sont disponibles commeMetacase [SLTM91], AMMA [JBC+06],ou les usines logiciels de Microsoft [GSCK04]. Ces approches constituent un ensembled'outils riches et haut niveau pour créer des DSL. Ils o�rent de puissants environne-ments graphiques pour concevoir des langages visuels, des mécanismes haut niveau pourcontraindre la composition de constructions du langage, et un haut degré d'automati-sation a�n de générer les outils nécessaires pour un nouveau DSL.

Néanmoins, ces outils o�rent un support limité quant à la génération de code. Plusspéci�quement, le fossé existant entre les modèles et leurs implémentations nécessitesouvent l'intervention d'experts en programmation a�n de couvrir tous les aspects de lagénération de code. La solution en couches présentée dans ce document est totalementcomplémentaire à ces environnements de développement ; elle fournit une approche quirend le processus de génération de code réalisable par la génération de programme.

Concernant l'implémentation des DSL, plusieurs approches ont émergé. Nous iden-ti�ons quatre stratégies principales : la génération de code, la génération de compilateurbasée sur la sémantique, la transformation basée sur les modèles, et la transformationbasée sur XML.

La génération de code. Le développement d'un générateur de code spéci�que estla principale alternative à notre approche. Il consiste en une compilation directe duDSL dans du code souvent généraliste. Cette solution par l'approche DSM présente denombreux désavantages (voir chapitre 2).

La génération de compilateur basée sur la sémantique. Le but de cette ap-proche est de générer un compilateur depuis une spéci�cation formelle et haut niveau


du langage. La sémantique dénotationnelle est le meilleur exemple de cette approche ;elle a été illustrée dans de nombreux cas [Sch86]. Cette technique a principalement étéutilisée pour générer des compilateurs pour des langages dédiés. Dans ce contexte, cetteapproche a pendant longtemps concurrencé les compilateurs écrits à la main, sans grandsuccès. De ce fait, peu de recherches sont encore menées sur ce sujet aujourd'hui.

La transformation basée sur les modèles. Cette approche suppose que le DSLest un langage haut niveau et donc qu'il est adapté aux outils de transformations demodèles comme ATL et KM3 [JB06, JK06b]. L'idée consiste à dé�nir un méta-modèlepour un tel DSL et d'appliquer des transformations qui le traduisent dans une autreforme. De ce point de vue, cette approche est complémentaire à notre démarche dansla mesure où elle o�re un outil supplémentaire à la manipulation de modèles DSML.

La transformation basée sur XML. Le but de cette approche est d'utiliser destransformateurs XML pour compiler un modèle DSML. Pour cela, le programme sourceest supposé être représenté sous une forme XML. Des outils comme XPath [Rec99a] ouXSLT [Rec99b] peuvent être utilisés. Néanmoins, certains langages ne sont pas adaptésau XML et conduisent à des développements de processus de transformation maladroits.Cela est dû au fait que les outils XML sont ultimement dédiés à la conversion de données,et non à la transformation de programme.

9.5 Bilan

Ce chapitre illustre notre architecture pour réduire le fossé entre le domaine de laTéléphonie sur IP et son implémentation. Ce problème est aujourd'hui une étape clédans la course à la productivité, non seulement dans le domaine de la téléphonie maiségalement dans le développement logiciel en général.

Parce que la sémantique d'un DSML repose seulement sur des calculs relatifs audomaine, il devient plus facile de générer une implémentation mais aussi de raisonner surun tel langage. Notre approche en couches permet de réduire le processus de compilationà une traduction de la logique. En ciblant la couche pivot que représente le DSPL, cettetransformation devient à la portée d'outils haut niveau de génération de programme.De plus, de par la nature des DSML, des aspects pertinents pour la véri�cation depropriétés peuvent simplement être extraits des modèles écrits dans de tels langages. Latransformation de ces programmes DSML dans un langage de spéci�cation d'un outilexistant comme TLA+ devient alors accessible à des outils de transformation. Cecipermet d'assurer que les services écrits avec un langage dédié de modélisation sont bienconformes aux propriétés du domaine.

Nous avons validé notre approche avec les deux DSML présentés dans ce document,CPL et VisuCom, ainsi que notre DSPL, SPL. Ces langages ont permis d'illustrer lanature haut niveau des processus de transformation. Ainsi, ils ont permis de montrerla manière dont les DSML peuvent s'appuyer sur des outils existants à la fois pour lacompilation mais aussi pour la véri�cation de propriétés.

Chapitre 10

Conclusion

Le développement logiciel connaît ces dernières années un bouleversement majeuravec l'émergence de nouveaux programmeurs et donc de nouveaux besoins. Il ne s'agitplus désormais de fournir des solutions de plus en plus puissantes et expressives, maisdavantage de produire des outils spéci�ques, haut niveau et adaptés aux utilisateurs.Cependant, la multiplication des pro�ls de développeurs entraîne la prolifération desbesoins en termes de solutions de programmation. Sans une automatisation du processusde développement logiciel, il est impossible de répondre à cette attente du fait du coûtde construction de telles solutions. De plus, le manque d'expertise en programmation deces développeurs entraîne des contraintes fortes en termes de �abilité des programmes,d'où la nécessité d'introduire un processus de véri�cation.

A�n de répondre à ces attentes, nous avons présenté dans cette thèse une nouvelleapproche basée sur les langages dédiés à un domaine (DSL) et reposant sur une ar-chitecture en couches des langages. À travers une distinction sur la nature des DSL,cette architecture introduit une séparation entre la programmation et la modélisationde solutions. Cette di�érenciation permet à la fois d'élever progressivement le niveaud'abstraction des solutions, mais également de spécialiser et d'automatiser les processusde compilation et de véri�cation de propriétés du domaine. Nous avons illustré notredémarche avec le domaine de la Téléphonie sur IP. Pour cela, nous avons conçu deuxlangages dédiés évoluant à des niveaux d'abstraction di�érents.

Ce chapitre dresse un bilan des di�érentes contributions de notre thèse et présentequelques perspectives de recherche.

10.1 Contributions

La contribution de cette thèse est double. Dans un premier temps, nous montronscomment, en architecturant les langages dédiés d'un domaine d'application, il devientpossible de faciliter le développement de solutions logicielles haut niveau. Cette approchepermet alors de rendre la programmation plus accessible aux nouveaux développeurs enleur fournissant simplement des outils �ables et adaptés. Dans un second temps, nousproposons une mise en oeuvre de cette architecture dans le domaine de la Téléphonie

133

134 Conclusion

sur IP. Grâce à la réutilisation d'outils existants, nous évaluons alors les avantages decette approche en termes de facilité de compilation et de véri�cation de propriétés dudomaine.

Approche langage au développement de solutions haut niveau. Nous avonsintroduit une nouvelle approche des langages dédiés (DSL), centrée sur les besoins del'utilisateur �nal. Nous avons montré qu'une distinction entre des langages orientés pro-grammation (DSPL) et des langages orientés modélisation (DSML) permet d'apporterdes solutions adaptées à ces besoins, mais également de prendre en compte leur diver-sité. En architecturant ces langages en couches, nous avons mis en évidence qu'il estpossible de répondre au problème de la montée en abstraction, en réduisant le fosséentre le niveau d'abstraction des solutions et leurs implémentations.

Analyse de domaine. Nous avons e�ectué une analyse complète du domaine de laTéléphonie sur IP. À partir des résultats obtenus, nous avons conçu deux langages dédiéshaut niveau pour la création de services. Ces solutions de programmation sont adaptéesà des pro�ls di�érents de développeurs, selon leur expertise du domaine et leurs besoins.

Le premier, SPL, est un langage dédié de programmation expressif et �able, permet-tant à des experts de développer des services. Il garantit des propriétés critiques qui nepeuvent pas être véri�ées dans des langages généralistes, en introduisant des conceptsspéci�ques au domaine ainsi que des restrictions sémantiques.

Le second, VisuCom, est un langage dédié de modélisation qui ne nécessite aucuneexpertise en programmation. Intuitif et sûr, ce langage visuel permet à des développeursde dé�nir des traitements d'appels du point de vue de leur métier. Pour cela, nousavons introduit une nouvelle approche de développement de services de téléphonie quivise à intégrer directement dans le processus de conception des données émanant dusystème d'informations d'une organisation. En intégrant le métier de l'utilisateur dans laprogrammation de services, cela nous permet à la fois d'adapter VisuCom en présentantdes abstractions vis-à-vis des besoins des développeurs, mais également de renforcer la�abilité des services.

Séparation des préoccupations. En utilisant le DSPL comme pivot de notre archi-tecture, nous avons séparé les préoccupations du domaine de celles liées à l'implémen-tation. En ciblant un tel langage, les détails d'implémentation se trouvent cachés dupoint de vue des solutions haut niveau (DSML). La compilation de ces détails est alorsreportée au niveau du compilateur du DSPL. Ce langage fait o�ce d'interface, sépa-rant la compilation du domaine de la compilation liée à l'implémentation. La séparationdes préoccupations permet à un DSML de se concentrer uniquement sur la logique duprogramme et de raisonner dessus de manière indépendante.

Processus de compilation simpli�é. Notre approche en couches permet de réduirele fossé existant entre les abstractions et l'implémentation. En séparant la compilation

Perspectives et Futures Directions 135

de la logique de la compilation des détails d'implémentation, le processus de compila-tion devient plus simple. Cette facilité de compilation des DSML introduite par notrearchitecture se traduit par la possibilité d'utiliser des outils haut niveau existants. Nousavons montré, grâce à notre étude de cas, que la compilation est alors à la portée d'outilsdiverses, comme, par exemple, ceux de transformation de programme (Stratego/XT) oubien de transformation de modèles (ATL). Nous avons ainsi implémenté deux compila-teurs en Stratego pour chacun des DSML, ciblant SPL et un langage de spéci�cationformelle.

Le DSPL permet de partager, au sein de notre architecture, une grande partie del'implémentation. Ainsi, notre approche facilite la prise en compte de la variabilité dessolutions de programmation. La compilation de nouvelles solutions se trouve alors ré-duite à la traduction de nouveaux modèles dans le DSPL, d'où une simpli�cation duprocessus de développement. De plus, la séparation des préoccupations permet égale-ment de recibler plus simplement un DSML sur un autre environnement d'exécution,sans e�ort de compilation supplémentaire.

A�n de simpli�er l'implémentation du DSPL, nous avons également proposé uneméthodologie de compilation de langages dédiés, basée sur les techniques de généra-tion de programme. Nous avons montré que cette approche permet de modulariser leprocessus tout entier de génération du compilateur, et donc de le simpli�er.

Véri�cation de propriétés du domaine. Parce que la sémantique d'un DSMLrepose seulement sur des calculs du domaine, il devient plus facile de raisonner sur detels langages. De par la nature des DSML, des aspects pertinents pour la véri�cation depropriétés peuvent simplement être extraits des modèles. Ainsi, nous avons démontréque le processus de véri�cation devient haut niveau et à la portée d'outils de véri�cationformelle. La transformation de ces modèles dans un langage de spéci�cation d'un outilexistant devient alors accessible à des outils de transformation. Ceci permet d'assurerque les services écrits avec un langage dédié de modélisation sont bien conformes auxpropriétés du domaine. Nous avons validé notre approche avec les deux DSML présentésdans ce document, CPL et VisuCom. Cela nous a permis d'assurer des propriétés quisont impossibles à véri�er dans le cadre de développements traditionnels.

10.2 Perspectives et Futures Directions

Les travaux présentés dans cette thèse décrivent une nouvelle approche pour le dé-veloppement de solutions de programmation haut niveau, basée sur l'utilisation deslangages dédiés. Les résultats obtenus ouvrent la voie mais de nombreuses investiga-tions et travaux restent à e�ectuer, que ce soit au niveau des langages dédiés ou de lamodélisation.

Nous avons montré au chapitre 6 qu'une distinction des langages dédiés est possibleselon les besoins des utilisateurs. Cependant, il n'existe aucun moyen de clairement iden-ti�er les di�érences. Aucune classi�cation existante ne permet aujourd'hui de répondre à

136 Conclusion

ce problème. En e�et, les taxonomies actuelles s'intéressent pour la plupart à catégoriserles DSL selon leur implémentation, les paradigmes du langage, le type de constructionmis à disposition ou encore leur représentation [MHS05]. Elles ne s'occupent en aucuncas de caractériser ces langages selon le contexte d'utilisation (e.g., le type de dévelop-peur ciblé, la manière d'utiliser le langage, les compétences nécessaires spéci�ques audomaine ou à la programmation). De nombreuses études s'accordent pourtant à direque ces notions de contextes et d'utilisateurs sont liées à la dé�nition du domaine, etqu'elles apparaissent primordiales lors de la conception d'un DSL. Une telle classi�-cation pourrait permettre de simplement di�érencier les langages et savoir dans quelscontextes ils peuvent être utilisés et à quels types de développeurs ils sont destinés.

Il est également envisageable de catégoriser les di�érentes tâches du domaine quipermettent de répondre à l'ensemble des besoins des développeurs. Chaque tâche, oucombinaison de tâches, peut alors être utilisée pour dé�nir un DSML potentiel du do-maine. Dans le cas de la téléphonie, il pourrait s'agir de tâches comme le transfertd'appel, la gestion de la présence, la consultation d'un agenda ou encore la gestionmultimédia. La classi�cation de ces tâches permettrait de caractériser l'ensemble deslangages du domaine.

En ce qui concerne la modélisation de solutions, des perspectives de recherche sontouvertes au niveau de VisuCom. Aujourd'hui, il permet de gérer uniquement la pro-grammation de routage d'appels téléphoniques. Cependant, les concepts sous-jacents àce langage de modélisation sont manipulables dans d'autres contextes. Ainsi, il apparaîtintéressant d'étudier di�érentes extensions à VisuCom. Il pourrait s'agir d'extensionsà d'autres caractéristiques du protocole SIP (évènements), mais également à d'autresdomaines comme le mail, ou d'autres stimuli de communication comme la présence.

En fonction des di�érentes solutions obtenues, des travaux pourraient consister àétudier les concepts langages manipulés au niveau des modèles de chaque déclinaisonde VisuCom, et la manière de les conceptualiser. Par exemple, le couplage avec la basede contacts permet d'introduire implicitement dans le modèle une notion de variable etde paramètre qui est totalement cachée du point de vue de l'utilisateur.

En�n, dans cette thèse, nous avons souligné la complémentarité des approches exis-tantes, à savoir l'Ingénierie Dirigée par les Modèles et les langages dédiés de programma-tion. Il a également été mis en avant la distance qui existait aujourd'hui entre ces deuxmondes. Le travail présenté ici ne constitue qu'un premier pas vers la convergence entrela programmation et la modélisation de solutions. Une prochaine direction de rechercheconsiste à étudier de manière plus approfondie chacun des domaines a�n de mettre enrelation des concepts, des vocabulaires, mais aussi des approches di�érentes. Ce travailpermettrait de savoir ce que chaque domaine peut apporter à l'autre et comment lesutiliser conjointement dans un projet logiciel.

Publications

Conférences internationales

1. F. Latry, C. Consel, et J. Mercadal. Staging Telephony Service Creation : ALanguage Approach. Dans Proceedings of the 1st ACM SIGCOMM InternationalConference on Principles, Systems and Applications of IP Telecommunications(IPTComm'07), Columbia University, New York City, USA, Juillet 2007.

2. L. Burgy, C. Consel, J. Lawall, F. Latry, N. Palix, et L. Réveillère. LanguageTechnology for Internet-Telephony Service Creation. Dans Proceedings of the IEEEInternational Conference on Communications (ICC'06), Istanbul, Turkey, Juin2006.

3. L. Burgy, C. Consel, F. Latry, N. Palix, et L. Réveillère. A High-Level, OpenEnded Architecture For SIP-based Services. Dans Proceedings of the 10th IEEEInternational Conference on Intelligence in service delivery Networks (ICIN'06),Bordeaux, France, Mai 2006.

4. F. Latry, P. Cointe, C. Consel, et L. Réveillère. A Generative Programming Ap-proach to Developing DSL Compilers. Dans Processings of the 4th ACM Interna-tional Conference on Generative Programming and Component Engineering (GP-CE'05) (R. Gluck et M. Lowry, eds.), volume 3676 de Lecture Notes in ComputerScience, pages 29-46. Springer-Verlag. Tallinn, Estonia, Septembre 2005.

5. L. Burgy, L. Caillot, C. Consel, F. Latry, et L. Réveillère. A Comparative Studyof SIP Programming Interfaces. Dans Proceedings of the 9th IEEE Internatio-nal Conference on Intelligence in service delivery Networks (ICIN'04), Bordeaux,France, Octobre 2004.

Workshops internationaux

1. F. Latry, C. Consel, et J. Mercadal. Processing Domain-Speci�c Modeling Lan-guages : A Case Study in Telephony Services. Dans Proceedings of the 1st GPCEWorkshop for QoS Provisioning in Distributed Systems (GPCE4QoS), Portland,USA, Octobre 2006.

2. J. Bézivin, C. Consel, F. Jouault, I. Kurtev, et F. Latry. Building DSLs withAMMA/ATL, a Case Study on SPL and CPL Telephony Languages. Dans Pro-ceedings of the 1st ECOOP Workshop on Domain-Speci�c Program Development(DSPD'06), Nantes, France, Juillet 2006.

137

138 Publications

Journaux

1. L. Burgy, C. Consel, F. Latry, N. Palix, et L. Réveillère. Telephony over IP :Experience and Challenges. European Research Consortium for Informatics andMathematics (ERCIM'05) - Security and Trust Management, volume 63, pages53-54, Octobre 2005.

Brevet et dépôt logiciel

1. Dépôt de brevet d'invention européen : "Dispositif d'interconnexion d'un systèmed'informations d'entreprise(s) à un serveur". Brevet INRIA, 06291276.1, déposéle 7 août 2006.

2. Dépôt logiciel à l'Agence de Protection des Programmes (APP) concernant lelogiciel VisuCom et son environnement d'exécution, version 1.0.

Bibliographie

[ABBC99] D. Atkins, T. Ball, G. Bruns, et K. Cox. Mawl : A Domain-Speci�c Lan-guage for Form-Based Services. IEEE Transactions on Software Enginee-ring, volume 25(3), pages 334�346. IEEE Computer Society, Juin 1999.

[Abr96] J.R. Abrial. The B-Book : Assigning Programs to Meanings. CambridgeUniversity Press, New York (NY), USA, 1996.

[ADR95] B. Arnold, A. van Deursen, et M. Res. An Algebraic Speci�cation of aLanguage for Describing Financial Products. Dans Proceedings of the 17thICSE Workshop on Formal Methods Application in Software EngineeringPractice (M. Wirsing, ed.), pages 6�13. IEEE Computer Society Press,Avril 1995.

[AF03] A. Andreasen et B. Foster. Media Gateway Control Protocol (MGCP).Request for Comments 3435, The Internet Engineering Task Force, Janvier2003.

[Ara89] A. Arango. Domain Analysis : From Art Form to Engineering Discipline.Dans Proceedings of the 5th International Workshop on Software Speci�ca-tion and Design (IWSSD'89), pages 152�159. ACM Press, 1989.

[ASU86] A.V. Aho, R. Sethi, et J.D. Ullman. Compilers Principles, Techniques, andTools. Addison-Wesley, 1986.

[Bac59] J.W. Backus. The Syntax and Semantics of the Proposed InternationalAlgebraic Language of the Zurich ACM-GAMM Conference. Dans Pro-ceedings of the 1st International Conference on Information Processing(ICIP'59), pages 125�132, 1959.

[BBB+04] J. Bézivin, M. Blay, M. Bouzhegoub, J. Estublier, J.M. Favre, S. Gérard, etJ.M. Jézéquel. Rapport de synthèse de l'AS CNRS sur le MDA. RapportTechnique, CNRS, Novembre 2004.

[BCC+04] L. Burgy, L. Caillot, C. Consel, F. Latry, et L. Réveillère. A ComparativeStudy of SIP Programming Interfaces. Dans Proceedings of the 9th Interna-tional Conference on Intelligence in service delivery Networks (ICIN'04),Bordeaux, France, Octobre 2004.

[BCL+06a] L. Burgy, C. Consel, F. Latry, J. Lawall, N. Palix, et L. Réveillère. LanguageTechnology for Internet-Telephony Service Creation. Dans Proceedings

139

140 Bibliographie

of the 41st IEEE International Conference on Communications (ICC'06),pages 1795�1800. IEEE Communications Society Press, Juin 2006.

[BCL+06b] L. Burgy, C. Consel, F. Latry, N. Palix, et L. Réveillère. A High-Level,Open Ended Architecture For SIP-based Services. Dans Proceedings of the10th International Conference on Intelligence in service delivery Networks(ICIN'06), Bordeaux, France, Mai 2006.

[BCP01] M.M. Burnett, S.K. Chekka, et R.K. Pandey. FAR : An End-User Languageto Support Cottage E-Services. Dans Proceedings of the IEEE InternationalSymposium on Human-Centric Computing Languages and Environments(HCC'01), pages 195�202. IEEE Computer Society Press, Septembre 2001.

[BCT05] A.W. Brown, J. Conallen, et D. Tropeano. Models, Modeling, and ModelDriven Development. Dans Model-Driven Software Development (S. Bey-deda, M. Book, et V. Gruhn, eds.), pages 1�17. Springer-Verlag, 2005.

[Ben86] J.L. Bentley. Programming Pearls : Little Languages. Communications ofthe ACM, volume 29(8), pages 711�721. 1986.

[Béz06] J. Bézivin. Model Driven Engineering : An Emerging Technical Space.Dans Generative and Transformational Techniques in Software Engineering(R. Lämmel, J. Saraiva, et J. Visser, eds.), volume 4143 de Lecture Notesin Computer Science, pages 36�64. Springer-Verlag, 2006.

[BG96] Bergin et Gibson. History of programming languages � II. ACM Press,New York (NY), USA, 1996.

[BG01] J. Bézivin et J. Gerbé. Towards a Precise De�nition of the OMG/MDAFramework. Dans Proceedings of the 16th IEEE International Conferenceon Automated Software Engineering (ASE'01), pages 273�280. IEEE Com-puter Society Press, 2001.

[BGK+06] K. Balasubramanian, A. Gokhale, G. Karsai, J. Sztipanovits, et S. Neema.Developing Applications Using Model-Driven Design Environments. IEEEComputer Society Press, volume 39(2), pages 33�40. Février 2006.

[Bja96] E. Bjarnason. APPLAB : a Laboratory for Application Languages. DansProceedings of the 7th Nordic Workshop on Programming Environment Re-search (NWPER'96) (L. Bendix, K. Nørmark, et K. Østerby, eds.). Rap-port Technique R-96-2019, Aalborg University, Mai 1996.

[BJK87] J. Bentley, L. Jelinski, et B. Kernighan. CHEM - a Program for Photo-typesetting Chemical Structure Diagrams. Computers & Chemistry, vo-lume 11(4), pages 281�297. 1987.

[BKVV06] M. Bravenboer, K. T. Kalleberg, R. Vermaas, et E. Visser. Stratego/XT0.16 : Components for Transformation Systems. Dans Proceedings of theACM SIGPLAN Symposium on Partial Evaluation and semantics-basedProgram Manipulation (PEPM'06), pages 95�99. ACM Press, 2006.

[Bla05] X. Blanc. MDA en action. Eyrolles, Paris, France, 2005.

Bibliographie 141

[BLS98] D. Batory, B. Lofaso, et Y. Smaragdakis. JTS : Tools for ImplementingDomain-Speci�c Languages. Dans Proceedings of the 5th InternationalConference on Software Reuse (ICSR'98), pages 143�153. IEEE ComputerSociety Press, 1998.

[BTS94] D. Batory, J. Thomas, et M. Sirkin. Reengineering a Complex Applica-tion using a Scalable Data Structure Compiler. Dans Proceedings of the2nd ACM SIGSOFT Symposium on Foundations of Software Engineering(SIGSOFT'94), pages 111�120. ACM Press, 1994.

[BV04] M. Bravenboer et E. Visser. Concrete Syntax for Objects : Domain-Speci�cLanguage Embedding and Assimilation Without Restrictions. Dans Pro-ceedings of the 19th annual ACM SIGPLAN Conference on Object-OrientedProgramming, Systems, Languages, and Applications (OOPSLA'04), pages365�383. ACM Press, 2004.

[CD93] C. Consel et O. Danvy. Tutorial Notes on Partial Evaluation. DansProceedings of the 20th Annual ACM SIGPLAN-SIGACT Symposium onPrinciples of Programming Languages, pages 493�501. ACM Press, Janvier1993.

[CE00] K. Czarnecki et U.W. Eisenecker. Generative Programming : Methods,Tools, and Applications. Addison-Wesley, New York (NY), USA, 2000.

[CEI+05] A. Chander, D. Espinosa, N. Islam, P. Lee, et G. Necula. Enforcing Re-source Bounds via Static Veri�cation of Dynamic Checks. Dans Procee-dings of the 14th European Symposium on Programming (ESOP'05), vo-lume 3444, pages 311�325. Springer-Verlag, 2005.

[CESW04] T. Clark, A. Evans, P. Sammut, et J. Willans. Applied Metamodelling : AFoundation for Language Driven Development. Xactium, Septembre 2004.

[CFB00] S. Ceri, P. Fraternali, et A. Bongio. Web Modeling Language (WebML) :a Modeling Language for Designing Web Sites. Computer Networks, vo-lume 33(1-6), pages 137�157. Elsevier North-Holland, Inc., 2000.

[CFPR00] C. Cortes, K. Fisher, D. Pregibon, et A. Rogers. Hancock : a Languagefor Extracting Signatures from Data Streams. Dans Proceedings of the 6thACM International Conference on Knowledge Discovery and Data mining(SIGKDD'00), pages 9�17. ACM Press, 2000.

[CHM+02] G. Csert, G. Huszerl, I. Majzik, Z. Pap, A. Pataricza, et D. Varr. VIATRA :Visual Automated Transformations for Formal Veri�cation and Validationof UML Models. Dans Proceedings of the 17th IEEE International Confe-rence on Automated Software Engineering (ASE'02), pages 267�270. IEEEComputer Society Press, Septembre 2002.

[CL97] S. Chandra et J. Larus. Experience with a Language for Writing CoherenceProtocols. Dans Proceedings of the 1st USENIX Conference on Domain-Speci�c Languages (DSL'97), Octobre 1997.

[CM87] W. Clocksin et C. Mellish. Programming in Prolog. Springer-Verlag, 1987.

142 Bibliographie

[CM98] C. Consel et R. Marlet. Architecture Software Using A Methodology forLanguage Development. Dans Proceedings of the 10th International Sym-posium on Principles of Declarative Programming (PLILP'98), pages 170�194. Springer-Verlag, 1998.

[Con04] C. Consel. Domain-Speci�c Program Generation ; International Seminar,Dagstuhl Castle, chapitre From A Program Family To A Domain-Speci�cLanguage, pages 19�29. Number 3016 in Lecture Notes in ComputerScience. Springer-Verlag, 2004.

[Coo04] S. Cook. Domain-Speci�c Modeling and Model Driven Architecture. DansThe MDA Journal : Model Driven Architecture Straight from the Masters(D. Frankel et J. Parodi, eds.), chapitre 3. Meghan Ki�er, Décembre 2004.

[Cor06] J.R. Cordy. Source Transformation, Analysis and Generation in TXL.Dans Proceedings of the ACM SIGPLAN Symposium on Partial Evaluationand semantics-based Program Manipulation (PEPM'06), pages 1�11. ACMPress, 2006.

[DF98] R. Douence et P. Fradet. A Systematic Study of Functional Language Im-plementations. ACM Transactions on Programming Languages and Sys-tems, volume 20(2), pages 344�387. ACM Press, 1998.

[DJK02] L. Dang, C. Jennings, et D. G. Kelly. Practical VoIP Using Vocal. O'Reilly,Juillet 2002.

[DK98] A. van Deursen et P. Klint. Little Languages : Little Maintenance. Journalof Software Maintenance, volume 10(2), pages 75�92. John Wiley & Sons,1998.

[DKV00] A. van Deursen, P. Klint, et J. Visser. Domain-speci�c languages : Anannotated bibliography. ACM SIGPLAN Notices, volume 35(6), pages 26�36. 2000.

[DRM04] J. Deruelle, M. Ranganathan, et D. Montgomery. Programmable ActiveServices for JAIN SIP. Rapport Technique, National Institute of Standardsand Technology, June 2004.

[DSM06] DSM Forum : Domain-Speci�c Modeling. http ://www.dsmforum.org,2006.

[EFF+97] E. Eide, K. Frei, B. Ford, J. Lepreau, et G. Lindstrom. Flick : a Flexible,Optimizing IDL Compiler. Dans Proceedings of the ACM SIGPLAN Confe-rence on Programming Language Design and Implementation (PLDI'97),pages 44�56. ACM Press, 1997.

[Ell99] C. Elliott. An Embedded Modeling Language Approach to Interactive 3Dand Multimedia Animation. IEEE Transactions on Software Engineering,volume 25(3), pages 291�308. IEEE Press, 1999.

[Eng01] R. van Engelen. ATMOL : A Domain-Speci�c Language for AtmosphericModeling. Journal of Computing and Information Technology, volume 9(4),pages 289�303. 2001.

Bibliographie 143

[eP07] Groupe ATLAS et Phoenix. ATL Use Case - DSLs coordination for Tele-phony. http ://www.eclipse.org/m2m/atl/usecases/DSLsTelephony/, Fé-vrier 2007.

[FG05] K. Fisher et R. Gruber. PADS : A Domain-Speci�c Language for ProcessingAd-Hoc Data. Dans Proceedings of the ACM SIGPLAN Conference onProgramming Language Design and Implementation (PLDI'05), pages 295�304. ACM Press, 2005.

[FGD02] R. Falbo, G. Guizzardi, et K. Duarte. An Ontological Approach to DomainEngineering. Dans Proceedings of the 14th International Conference onSoftware Engineering and Knowledge Engineering (SEKE'02), pages 351�358. ACM Press, 2002.

[FGDS06] R.B. France, S. Ghosh, T. Dinh, et A. Solberg. Model-Driven DevelopmentUsing UML 2.0 : Promises and Pitfalls. Computer, volume 39(2), pages 59�66. IEEE Computer Society Press, 2006.

[Fle06] F. Fleurey. Langage et Méthode pour une Ingénierie des Modèles Fiable.Thèse de doctorat, Université de Rennes 1, Rennes, France, Octobre 2006.

[FPDF98] W. Frakes, R. Prieto-Diaz, et F. Fox. DARE : Domain Analysis and ReuseEnvironment. Annals of Software Engineering, volume 5, pages 125�141.J. C. Baltzer AG, Science Publishers, 1998.

[FR05] M. Fisher II et G. Rothermel. The EUSES Spreadsheet Corpus : A SharedResource for Supporting Experimentation with Spreadsheet DependabilityMechanism. Dans Proceedings of the 1st Workshop on End-user SoftwareEngineering (WEUSE'05), pages 47�51. ACM Press, Mai 2005.

[FS00] M. Fowler et K. Scott. UML Distilled (2nd ed.) : a Brief Guide to theStandard Object Modeling Language. Addison-Wesley, Boston (MA), USA,2000.

[GBA+05] R. Grønmo, M. Belaunde, J. Aagedal, K.D. Engel, M. Faugere, et I. Sol-heim. Evaluation of the Proposed QVTMerge Language for Model Trans-formations. Dans Proceedings of the Joint Workshop on Web Services andModel-Driven Enterprise Information Services (WSMDEIS'05), pages 65�74. Institute for Systems and Technologies of Information, Control andCommunication (INSTICC) Press, 2005.

[GJKW97] N. Gupta, L. Jagadeesan, E. Koutso�os, et D. Weiss. Auditdraw : Genera-ting Audits the FASTWay. Dans Proceedings of the 3rd IEEE InternationalSymposium on Requirements Engineering (ISRE'97), pages 188�197. IEEEComputer Society Press, 1997.

[GK02] K. Gondow et H. Kawashima. Towards ANSI C Program Slicing usingXML. Electronic Notes Theoretical Computer Science, volume 65(3). 2002.

[GK03] J. Gray et G. Karsai. An Examination of DSLs for Concisely Represen-ting Model Traversals and Transformations. Dans Proceedings of the 36thannual Hawaii International Conference on System Sciences (HICSS'03),page 325.1. IEEE Computer Society Press, 2003.

144 Bibliographie

[GLR+02] A. Gerber, M. Lawley, K. Raymond, J. Steel, et A. Wood. Transforma-tion : The Missing Link of MDA. Dans Proceedings of the 1st InternationalConference on Graph Transformation (ICGT'02), volume 2505 de LectureNotes in Computer Science, pages 90�105. Springer-Verlag, 2002.

[GS96] D. Garlan et M. Shaw. Software Architecture : Perspectives on an EmergingDiscipline. Prentice-Hall, 1996.

[GSCK04] J. Green�eld, K. Short, S. Cook, et S. Kent. Software Factories : Assem-bling Applications with Patterns, Models, Frameworks, and Tools. JohnWiley & Sons, 2004.

[GTK+06] J. Gray, J.P. Tolvanen, S. Kelly, A. Gokhale, S. Neema, et J. Sprinkle.Domain-Speci�c Modeling. Dans Handbook of Dynamic System Modeling(P. Fishwick, ed.), page (in publication). CRC, 2006.

[Hal96] M. Hall. A Risk and Control Oriented Study of the Practices of SpreadsheetApplication Developers. Dans Proceedings of the 29th Hawaii InternationalConference on System Sciences (HICSS'96), volume 2, page 364. IEEEComputer Society Press, 1996.

[HB88] R.M. Herndon et V.A. Berzins. The Realizable Bene�ts of a LanguagePrototyping Language. IEEE Transaction on Software Engineering, vo-lume 14(6), pages 803�809. IEEE Computer Society Press, 1988.

[HHKR89] J. Heering, P.R. Hendriks, P. Klint, et J. Rekers. The Syntax De�nitionFormalism SDF - Reference Manual -. SIGPLAN Notices, volume 24(11),pages 43�75. ACM Press, 1989.

[HMGW96] P. Hudak, M. Makucevich, S. Gadde, et B. Whong. Haskore Music Notation- An Algebra of Music. Journal of Functional Programming, volume 6(3),pages 465�483. 1996.

[Hol97] G. Holzmann. The Model Checker SPIN. IEEE Transactions on SoftwareEngineering, volume 23(5), pages 279�295. IEEE Computer Society Press,1997.

[HR04] D. Harel et B. Rumpe. Meaningful Modeling : What's the Semantics of"Semantics" ? Computer, volume 37(10), pages 64�72. IEEE ComputerSociety Press, 2004.

[HT06] B. Hailpern et P. Tarr. Model-Driven Development : the Good, the Bad,and the Ugly. IBM Systems Journal, volume 45(3), pages 451�461. IBMCorp., 2006.

[Hud96] P. Hudak. Building Domain-Speci�c Embedded Languages. ACM Compu-ting Survey, volume 28(4es), pages 196. ACM Press, 1996.

[Iiv96] J. Iivari. Why are CASE tools not used ? Communications of the ACM,volume 39(10), pages 94�103. ACM Press, 1996.

[Jac01] M. Jackson. Problem Frames : Analyzing and Structuring Software Deve-lopment Problems. Addison-Wesley, Boston (MA), USA, 2001.

Bibliographie 145

[JB00] J. Jennings et E. Beuscher. Verischemelog : Verilog Embedded in Scheme.ACM SIGPLAN Notices, volume 35(1), pages 123�134. ACM Press, 2000.

[JB06] J. Jouault et J. Bézivin. KM3 : A DSL for Metamodel Speci�cation. DansProceedings of the 8th IFIP WG 6.1 International Conference on FormalMethods for Open Object-Based Distributed Systems (FMOODS'06), vo-lume 4037 de Lecture Notes in Computer Science, pages 171�185. Springer-Verlag, 2006.

[JBC+06] F. Jouault, J. Bézivin, C. Consel, I. Kurtev, et F. Latry. Building DSLswith AMMA/ATL, a Case Study on SPL and CPL Telephony Languages.Dans Proceedings of the 1st ECOOP Workshop on Domain-Speci�c Pro-gram Development (DSPD'06), Juillet 2006.

[JGS93] N.D. Jones, C. Gomard, et P. Sestoft. Partial Evaluation and AutomaticProgram Generation. International Series in Computer Science. Prentice-Hall, Juin 1993.

[JK06a] F. Jouault et I. Kurtev. On the Architectural Alignment of ATL andQVT. Dans Proceedings of the 21st ACM Symposium on Applied Compu-ting (SAC'06), pages 1188�1195. ACM Press, 2006.

[JK06b] F. Jouault et I. Kurtev. Transforming Models with ATL. Dans Satel-lite Events at the MoDELS Conference (J.M. Bruel, ed.), volume 3844 deLecture Notes in Computer Science, pages 128�138. Springer-Verlag, 2006.

[Jon06] C. Jones. Software Productivity Research, Programming Languages Table.http ://www.spr.com, 2006.

[Jou06] F. Jouault. Contribution à l'Étude des Langages de Transformation deModèles. Thèse de doctorat, Université de Nantes (LINA), Nantes, France,Septembre 2006.

[JP01] B. Jacobs et E. Poll. A Logic for the Java Modeling Language JML.Dans Proceedings of the 4th International Conference on FundamentalApproaches to Software Engineering (FASE'01), pages 284�299. Springer-Verlag, 2001.

[Kar00] G. Karsai. Model Integrated Computing (MIC). ACM SIGSOFT SoftwareEngineering Notes, volume 25(1). ACM Press, 2000.

[KCH+90] K. Kang, S. Cohen, J. Hess, W. Novak, et S. Peterson. Feature-Oriented Domain Analysis (FODA) Feasibility Study. Rapport TechniqueCMU/SEI-90-TR-21, Software Engineering Institute, Novembre 1990.

[Kel04] S. Kelly. Comparison of Eclipse EMF/GEF and MetaEdit+ for DSM.Dans Proceedings of the 19th Annual ACM Conference on Object-OrientedProgramming, Systems, Languages, and Applications, Workshop on BestPractices for Model Driven Software Development. ACM Press, 2004.

[KG03] H. Kawashima et K. Gondow. Experience with ANSI C Markup Languagefor a Cross-Referencer. Dans Proceedings of the 36th Annual Hawaii Inter-national Conference on System Sciences (HICSS'03), pages 324�352. IEEEComputer Society Press, 2003.

146 Bibliographie

[KH97] S.N. Kamin et D. Hyatt. A Special-Purpose Language for Picture-Drawing.Dans Proceedings of the 1st USENIX Conference on Domain-Speci�c Lan-guages (DSL'97), pages 297�310, 1997.

[KHH+01] G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm, et W. Gris-wold. An Overview of AspectJ. Dans Proceedings of the 15th EuropeanConference on Object-Oriented Programming (ECOOP'01), pages 327�353.Springer-Verlag, 2001.

[KLM+97] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J.M. Loing-tier, et J. Irwin. Aspect-Oriented Programming. Dans Proceedings ofthe European Conference on Object-oriented Programming (ECOOP'97)(M. Aksit et S. Matsuoka, eds.), volume 1241 de Lecture Notes in Compu-ter Science, pages 220�242. Springer-Verlag, Juin 1997.

[KMB+96] R. Kieburtz, L. McKinney, J. Bell, J. Hook, A. Kotov, J. Lewis, D. Oliva,T. Sheard, I. Smith, et L. Walton. A Software Engineering Experimentin Software Component Generation. Dans Proceedings of the 18th IEEEInternational Conference on Software Engineering (ICSE'96), pages 542�553, 1996.

[Kri03] A. Kristensen. SIP Servlet API 1.0 Speci�cation. Java Speci�cation Re-quest 116, Java Community ProcessSM Program, Février 2003.

[Kut03] J. Kuthan. SIP Express Router (SER). IEEE Network Magazine, Juillet2003.

[Lam94] L. Lamport. The Temporal Logic of Actions. ACM Transactions on Pro-gramming Languages and Systems, volume 16(3), pages 872�923. Mai 1994.

[Lam02] L. Lamport. Specifying Systems : The TLA+ Language and Tools for Hard-ware and Software Engineers. Addison-Wesley, 2002.

[LBM+01] A. Ledeczi, A. Bakay, M. Maroti, P. Volgyesi, G. Nordstrom, J. Sprinkle,et G. Karsai. Composing Domain-Speci�c Design Environments. IEEEComputer Society Press, volume 34(11), pages 44�51. 2001.

[LCM06] F. Latry, C. Consel, et J. Mercadal. Processing Domain-Speci�c Mode-ling Languages : A Case Study in Telephony Services. Dans Proceedingsof the 1st GPCE Workshop for QoS Provisioning in Distributed Systems(GPCE4QoS), Octobre 2006.

[LCM07] F. Latry, C. Consel, et J. Mercadal. Staging Telephony Service Creation :A Language Approach. Dans Proceedings of the ACM SIGCOMM Inter-national Conference on Principles, Systems and Applications of IP Tele-communications (IPTComm'07), Juillet 2007.

[LCRC05] F. Latry, C. Consel, L. Réveillère, et P. Cointe. A Generative ProgrammingApproach to Developing DSL Compilers. Dans Processings of the 4th ACMInternational Conference on Generative Programming and Component En-gineering (GPCE'05) (R. Gluck et M. Lowry, eds.), volume 3676 de LectureNotes in Computer Science, pages 29�46. Springer-Verlag, Septembre 2005.

Bibliographie 147

[Len04] J. Lennox. Services for Internet Telephony. Thèse de doctorat, ColumbiaUniversity, Janvier 2004.

[Lop05] D.C.P. Lopes. Étude et Applications de l'Approche MDA pour des Plates-Formes de Services Web. Thèse de doctorat, Université de Nantes, France,Juillet 2005.

[LR94] D.A. Ladd et J.C. Ramming. Two Application Languages in SoftwareProduction. Dans Proceedings of the USENIX Symposium on Very HighLevel Languages (VHLL'94), pages 169�177, 1994.

[LS00] J. Lennox et H. Schulzrinne. CPL : A Language for User Control of In-ternet Telephony Services. Internet Engineering Task Force, IPTEL WG,November 2000.

[Mad86] O.L. Madsen. Block Structure and Object Oriented Languages. ACMSIGPLAN Notices, volume 21(10), pages 133�142. ACM Press, 1986.

[Mar85] J. Martin. Fourth-Generation Languages. Volume I : Principles. Prentice-Hall, Upper Saddle River (NJ), USA, 1985.

[MB03] F. Marschall et P. Braun. Model Transformations for the MDA with BOTL.Dans Proceedings of the Workshop on Model Driven Architecture : Foun-dations and Applications (A. Rensink, ed.), pages 25�36, Juin 2003.

[MBS04] P. Muller, D. Bresch, et P Studer. Model-Driven Architecture forAutomatic-Control : An Experience Report. Dans The Uni�ed ModellingLanguage : Modelling Languages and Applications (T. Baar, A. Strohmeier,A.M.D. Moreira, et S.J. Mellor, eds.), volume 3273 de Lecture Notes inComputer Science, pages 260�274. Springer-Verlag, 2004.

[McC85] R. McCain. Reusable Software Component Construction : A Product-Oriented Paradigm. Dans Proceedings of the 5th AiAA/ACM/NASA/IEEEComputers in Aerospace Conference, Long Beach, California, Octobre 1985.

[MCG05] T. Mens, K. Czarnecki, et P. van Gorp. A Taxonomy of Model Transforma-tions. Dans Language Engineering for Model-Driven Software Development(J. Bezivin et R. Heckel, eds.), number 04101 in Dagstuhl Seminar Procee-dings, 2005.

[Mer06] J. Mercadal. Modélisation et Langages Métiers : Application aux Servicesde Téléphonie. Thèse de Mastère, University of Bordeaux I, France, Juin2006.

[MHS05] M. Mernik, J. Heering, et A.M. Sloane. When and How to Develop Domain-Speci�c Languages. ACM Computing Survey, volume 37(4), pages 316�344.ACM Press, 2005.

[Mic04] Microsoft. Live Communications Server 2005 Enterprise Edition Deploy-ment Guide, Novembre 2004.

[MKB06] B.A. Myers, A.J. Ko, et M.M. Burnett. Invited Research Overview : End-User Programming. Dans Proceedings of the Extended Abstracts on HumanFactors in Computing Systems (CHI'06), pages 75�80. ACM Press, 2006.

148 Bibliographie

[MPMU04] C. Marché, C. Paulin-Mohring, et X. Urbain. The Krakatoa Tool forCerti�cation of Java/JavaCard Programs annotated in JML. Journal ofLogic and Algebraic Programming, volume 58(1�2), pages 89�106. 2004.

[MR97] P. Murray-Rust. Chemical Markup Language (CML). World Wide WebJournal, volume 2(4), pages 135�147. O'Reilly & Associates, Inc., 1997.

[Mye99] A.C. Myers. JFlow : Practical Mostly-Static Information Flow Control.Dans Proceedings of the 26th ACM SIGPLAN-SIGACT Symposium onPrinciples Of Programming Languages (POPL'99), pages 228�241. ACMPress, 1999.

[Nar93] B.A. Nardi. A Small Matter of Programming : Perspectives on End UserComputing. MIT Press, Cambridge (MA), USA, 1993.

[Nei80] J. Neighbors. Software Construction Using Components. Thèse de docto-rat, University of California, Irvine, 1980.

[Nei84] J. Neighbors. The Draco Approach to Constructing Software from ReusableComponents. IEEE Transaction on Software Engineering, volume 10(5),pages 564�574. 1984.

[NLMK03] M. Nakamura, P. Leelaprute, K. Matsumoto, et T. Kikuno. Semantic War-nings and Feature Interaction in Call Processing Language on InternetTelephony. Dans Proceedings of the Symposium on Applications and theInternet (SAINT'03), pages 283�291. IEEE Computer Society Press, 2003.

[Obj03] Object Management Group (OMG), Framingham, Massachusett. MDAGuide Version 1.0.1, Juin 2003.

[Ous97] J. Ousterhout. Scripting : Higher-level programming for the 21st century.http ://www.sunlabs.com/people/john.ousterhout/, 1997.

[Par76] D.L. Parnas. On the Design and Development of Program Families. IEEETransactions on Software Engineering, volume 2, pages 1�9. Mars 1976.

[PB03] L. Porto Barreto. Conception Aisée et Robustes d'Ordonnanceurs au moyend'un Langage Dédié. Thèse de doctorat, Université de Rennes, France, Juin2003.

[PBC+97] C. Pu, A. Black, C. Cowan, J. Walpole, et C. Consel. Microlanguagesfor Operating System Specialization. Dans Proceedings of the 1st ACM-SIGPLAN Workshop on Domain-Speci�c Languages. Rapport TechniqueComputer Science, University of Illinois at Urbana-Champaign, Janvier1997.

[PD90] R. Prieto-Díaz. Domain Analysis : an Introduction. ACM SIGSOFT Soft-ware Engineering Notes, volume 15(2), pages 47�54. ACM Press, 1990.

[PHH99] J. Peterson, G. Hager, et P. Hudak. A Language for Declarative Robo-tic Programming. Dans Proceedings of IEEE Conference on Robotics andAutomation, volume 2, pages 1144�1151. IEEE Computer Society Press,1999.

Bibliographie 149

[Pho06] Phoenix Group. Le Langage SPL (Session Processing Language), 2006.http ://phoenix.labri.fr/software/spl/.

[Pho07] Phoenix Group. Compilation and Veri�cation of CPL and VisuCom Ser-vices, 2007. http ://phoenix.labri.fr/processings/.

[Rec99a] W3C Recommendation. XML Path Language Version 1.0.http ://www.w3.org/TR/xpath, Novembre 1999.

[Rec99b] W3C Recommendation. XSL Transformations (XSLT) Version 1.0.http ://www.w3.org/TR/xslt, Novembre 1999.

[Rév01] L. Réveillère. Approche Langage au Développement de Pilotes de Péri-phériques Robustes. Thèse de doctorat, Université de Rennes 1, France,Décembre 2001.

[RLS99] J. Rosenberg, J. Lennox, et H. Schulzrinne. Programming Internet Te-lephony Services. IEEE Internet Computing, volume 3(3), pages 63�72.1999.

[RM99] M.P. Robillard et G. Murphy. Analyzing Exception Flow in Java Programs.Dans Proceedings of the 7th European Software Engineering Conference,pages 322�337. Springer-Verlag, 1999.

[Ros78] D.T. Ross. Origins of the APT Language for Automatically ProgrammedTools. Dans Proceedings of the 1st ACM SIGPLAN Conference on Historyof Programming Languages (HOPL-1), pages 61�99. ACM Press, 1978.

[RSC+02] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson,R. Sparks, M. Handley, et E. Schooler. SIP : Session Initiation Proto-col. Request for Comments 3261, The Internet Engineering Task Force,Juin 2002.

[Sam69] J.E. Sammet. Programming Languages : History and Fundamentals.Prentice-Hall, Upper Saddle River (NJ), USA, 1969.

[SB97] Y. Smaragdakis et D. Batory. DiSTiL : A Transformation Library for DataStructures. Dans Proceedings of the 1st USENIX Conference on Domain-Speci�c Languages (DSL'97), pages 257�270, 1997.

[Sch86] D.A. Schmidt. Denotational Semantics : a Methodology for Language De-velopment. Allyn and Bacon, Inc., 1986.

[Sch96] Schulzrinne, H. et al. RTP : A Transport Protocol for Real-Time Applica-tions. Request for Comments 1889, The Internet Engineering Task Force,Janvier 1996.

[Sch06] D.C. Schmidt. Model-Driven Engineering. IEEE Computer Society Press,volume 39(2). Février 2006.

[Sim95] M.A. Simos. Organization Domain Modeling (ODM) : Formalizing the CoreDomain Modeling Life Cycle. Dans Proceedings of the ACM SIGSOFTSymposium on Software reusability (SSR'95), pages 196�205. ACM Press,1995.

150 Bibliographie

[SLTM91] K. Smolander, K. Lyytinen, V. Tahvanainen, et P. Marttiin. MetaEdit : aFlexible Graphical Environment for Methodology Modelling. Dans Procee-dings of the 3rd International Conference on Advanced information SystemsEngineering (CAiSE'91), pages 168�193. Springer-Verlag, 1991.

[SMS06] R. Stallman, R. McGrath, et P.D. Smith. GNU Make : A Program for Di-recting Recompilation. 1-882114-83-3. Free Software Foundation, Novembre2006.

[Spi01] D. Spinellis. Notable Design Patterns for Domain-Speci�c Languages. Jour-nal of Systems and Software, volume 56(1), pages 91�99. Elsevier ScienceInc., 2001.

[SSM05a] C. Sca�di, M. Shaw, et B. Myers. Estimating the Numbers of End Usersand End User Programmers. Dans Proceedings of the IEEE Symposiumon Visual Languages and Human-Centric Computing (VL/HCC'05), pages207�214. IEEE Computer Society Press, 2005.

[SSM05b] C. Sca�di, M. Shaw, et B. Myers. The "55M End-User Programmers" Es-timate Revisited. Rapport Technique CMU-ISRI-05-100 and Human Com-puter Interaction Institute Technical Report CMU-HCII-05-100, RapportTechnique Carnegie Mellon University ISRI, Février 2005.

[Sun05] Sun Microsystems. The JAIN SIP API Speci�cation v1.2. Rapport Tech-nique, Sun Microsystems, 2005.

[Sys05] SysML Partners. Systems Modeling Language (SysML) Speci�cation, ver-sion 1, Novembre 2005.

[TCL+00] S. Thibault, C. Consel, J. Lawall, R. Marlet, et G. Muller. Static andDynamic Program Compilation by Interpreter Specialization. Higher-Orderand Symbolic Computation, volume 13(3), pages 161�178. Septembre 2000.

[Thi98] S. Thibault. Langage Dédiés : Conception, Implémentation et Application.Thèse de doctorat, Université de Rennes, France, Octobre 1998.

[Tho04] D. Thomas. MDA : Revenge of the Modelers or UML Utopia ? IEEESoftware, volume 21(3), pages 15�17. IEEE Computer Society Press, 2004.

[TK05] J. Tolvanen et S. Kelly. De�ning Domain-Speci�c Modeling Languages toAutomate Product Derivation : Collected Experiences. Dans Proceedingsof the 9th International Conference of Software Product Lines (SPLC'05)(J.H. Obbink et K. Pohl, eds.), volume 3714 de Lecture Notes in ComputerScience, pages 198�209. Springer-Verlag, 2005.

[TMC97] S. Thibault, R. Marlet, et C. Consel. A Domain-Speci�c Language forVideo Device Driver : from Design to Implementation. Dans Proceedingsof the 1st USENIX Conference on Domain-Speci�c Languages (DSL'97),Octobre 1997.

[TMC98] S. Thibault, G. Muller, et C. Consel. Safe and E�cient Active NetworkProgramming. Dans Proceedings of the The 17th IEEE Symposium onReliable Distributed Systems (SRDS'98), page 135. IEEE Computer SocietyPress, 1998.

Bibliographie 151

[TMM99] S. Thibault, J. Marant, et G. Muller. Adapting Distributed ApplicationsUsing Extensible Networks. Dans Proceedings of the 19th InternationalConference on Distributed Computing Systems, pages 234�243. IEEE Com-puter Society Press, Mai 1999.

[Tra95] W. Tracz. DSSA (Domain-Speci�c Software Architecture) : pedagogicalexample. ACM SIGSOFT Software Engineering Notes, volume 20(3), pages49�62. ACM Press, 1995.

[TSPB02] R. Thiagarajan, A. Srivastava, A. Pujari, et V. Bulusu. BPML : A ProcessModeling Language for Dynamic Business Models. Dans Proceedings of the4th IEEE International Workshop on Advanced Issues of E-Commerce andWeb-Based Information Systems (WECWIS'02), page 239. IEEE Compu-ter Society Press, 2002.

[Uni99] International Telecommunications Union. Recommendation H.323, Packet-Based Multimedia Communications Systems, Février 1999.

[vDHK96] A. van Deursen, J. Heering, et P. Klint. Language Prototyping : An Alge-braic Speci�cation Approach, volume 5 de AMAST Series in Computing.World Scienti�c Publishing Co., 1996.

[Vel98] T.L. Veldhuizen. Arrays in Blitz++. Dans Proceedings of the Internatio-nal Symposium on Computing in Object-Oriented Parallel Environments,volume 1505 de Lecture Notes in Computer Science. Springer-Verlag, Dé-cembre 1998.

[Vis01] E. Visser. Stratego : A Language for Program Transformation Based onRewriting Strategies. Dans Proceedings of the 12th International Confe-rence on Rewriting Techniques and Applications (RTA'01), pages 357�362.Springer-Verlag, 2001.

[Vis02] E. Visser. Meta-Programming with Concrete Object Syntax. Dans Pro-ceedings of the Generative Programming and Component Engineering (GP-CE'02) (D. Batory, C. Consel, et W. Taha, eds.), volume 2487 de LectureNotes in Computer Science, pages 299�315. Springer-Verlag, Octobre 2002.

[Vis05] E. Visser. A Survey of Strategies in Rule-Based Program TransformationSystems. Journal of Symbolic Computation, volume 40(1), pages 831�873.2005.

[Wei96] D.M. Weiss. Family-oriented Abstraction Speci�cation and Translation :the FAST Process. Dans Proceedings of the 11th Annual Conference onComputer Assurance (COMPASS'96), pages 14�22. IEEE Computer So-ciety Press, 1996.

[Wex81] R. L. Wexelblat. History of Programming Languages. Academic Press, Inc.,Orlando (FL), USA, 1981.

[Wil01] D.S. Wile. Supporting the DSL Spectrum. Journal of Computing andInformation Technology, volume 9(4), pages 263�287. 2001.

152 Bibliographie

[Wil04] D.S. Wile. Lessons learned from real DSL experiments. Science of Com-puter Programming, volume 51(3), pages 265�290. Elsevier North-Holland,Inc., 2004.

[WL99] D.M. Weiss et C.T. Lai. Software Product-Line Engineering : a Family-Based Software Development Process. Addison-Wesley, Boston (MA), USA,1999.

[YML99] Y. Yu, P. Manolios, et L. Lamport. Model Checking TLA+ Speci�cations.Dans Proceedings of the 10th IFIP WG 10.5 Advanced Research WorkingConference on Correct Hardware Design and Veri�cation Methods (CHAR-ME'99), pages 54�66. Springer-Verlag, 1999.

Annexe A

Le langage TLA+

Extrait du mémoire de Julien Mercadal [Mer06].

Le langage TLA+ est une extension de la logique temporelle linéaire associée à unelogique des actions. À travers un outil de véri�cation, appelé un véri�cateur de modèles(model checker), il permet la véri�cation de formules logiques et donc de propriétéstemporelles.

Cette annexe présente les principes de ce langage de spéci�cation formelle en expli-citant la spéci�cation TLA+ associée à l'exemple donnée à la �gure 9.11.

A.1 Logique temporelle : un peu d'histoire...

La logique temporelle est utilisée pour raisonner sur des propositions dont la valeurde vérité dépend du temps. Soit la proposition suivante : "Je travaille". La valeur devérité de cette proposition varie en fonction du temps : quelquefois cette propositionest vraie, quelquefois elle est fausse, mais jamais les deux en même temps. Ainsi, lalogique temporelle voit le temps comme une séquence d'états. Elle est di�érente de lalogique classique où la valeur de vérité des propositions reste constante dans le temps. Lalogique temporelle résulte d'une extension de la logique du premier ordre. Elle introduitun nouvel opérateur : � (prononcé box). Soit une formule booléenne F, alors �F signi�eque F est toujours vraie.

La logique temporelle est étudiée depuis l'époque des philosophes grecs avec Aris-tote. Mais c'est dans les années soixante qu'Arthur Prior et d'autres logiciens dé�nissentet introduisent véritablement la logique temporelle (initialement connue sous le nom detense logic). Puis, en 1977, Amir Pnueli introduit la logique temporelle en informa-tique. Toutefois, la logique de Pnueli a assez vite révélé un manque d'expressivité. Ene�et, certaines propriétés d'un système ne pouvaient pas être décrites. C'est pourquoide nombreuses autres logiques davantage expressives ont été proposées. Elles introdui-saient toutes des opérateurs temporels nouveaux, toujours plus puissants tels que next(immédiatement après) ou encore until (jusqu'à). La logique temporelle des actions,quant à elle, propose une approche di�érente.

153

154 Le langage TLA+

A.2 Qu'est ce que la logique temporelle des actions ?

La logique temporelle des actions (Temporal Logic of Actions - TLA) [Lam94] estune logique proposée par Leslie Lamport à la �n des années quatre-vingt (1989). Il s'agiten fait d'une version légèrement étendue de la logique de Pnueli, à peine plus expressive.La logique temporelle des actions permet de décrire des systèmes de transitions d'étatsainsi que de formuler leurs propriétés.

x = 1y = 1

x = 2y = 3

x = 3y = 5

…

Fig. A.1 � Séquence d'états

La �gure A.1 décrit une séquence de transitions d'état où [x=3, y=5] est un étatdans lequel les variables x et y ont respectivement été a�ectées aux valeurs 3 et 5.Une étape (step) correspond à une paire successive d'états. Par exemple, [x=1, y=1]

→ [x=2, y=3] est une étape. Ainsi, contrairement aux autres extensions de la logiquede Pnueli, la logique temporelle des actions est basée sur la notion d'action a�n deraisonner sur un couple d'états. Une action est une expression booléenne qui contientdes variables d'état primées et/ou non primées. Un exemple d'action est la formulesuivante : x' = x + 1. Cette action indique que la variable x sera incrémentée d'unpas à chaque nouvel état, ce qui est illustré par la �gure A.1. Ainsi, une action spéci�eun ensemble de transitions d'état autorisées. Une transition d'état autorisée par uneaction A est appelée une A transition (ou A étape). Le terme variable d'état dé�nitun terme primitif représentant des données qui peuvent évoluer au cours de l'exécutiondu programme. Dans l'exemple de la �gure A.1, x et y sont des variables d'état. Unevariable non-primée représente la valeur de la variable dans le premier état d'une étapealors qu'une variable primée représente la valeur de la variable dans le second état del'étape. Le premier et le second état d'une étape sont également respectivement quali�ésde vieil et nouvel état. Les formules en logique temporelle des actions sont construites àpartir de formules dites élémentaires et d'opérateurs logiques. Ces formules élémentairessont réparties en deux types. Il y a, d'une part, des formules de la forme [A]vars où A

est une action et vars est un sous-ensemble des variables d'état. Cette formule signi�eque soit l'action A est valide maintenant, soit les variables apparaissant dans vars sontrestées inchangées. Ce type de formule permet d'avoir des étapes dites de bégaiement(stuttering step), c'est-à-dire des étapes dans la spéci�cation du système où aucunevariable du programme n'est changée. Autrement dit, un état peut se répéter à l'in�ni. Ily a, d'autre part, des formules créées à partir de variables d'état déclarées, de constanteset d'opérateurs constants mais qui ne contiennent ni de variables primées, ni d'opérateur�. Un exemple est donné par la formule suivante : x = 5 ∨ y = 7. Ces formules sontappelées des fonctions d'état ou des prédicats d'état lorsque celles-ci sont booléennes,ce qui est le cas de la formule donnée en exemple juste au-dessus. Finalement, la logiquetemporelle des actions dispose de toute la puissance expressive nécessaire pour spéci�er

Spéci�cation TLA+ 155

et raisonner sur des systèmes concurrents, distribués ou asynchrones. Le langage TLA+s'appuie sur cet type de logique.

A.3 Spéci�cation TLA+

Le langage TLA+ est un langage formel de spéci�cation basé sur la logique mathé-matique et sur la théorie des ensembles. Une spéci�cation correspond à une descriptionécrite de ce qu'un système est supposé faire. Autrement dit, il s'agit de dé�nir tousles comportements autorisés lors de l'exécution du système. Ainsi, les spéci�cationsécrites en TLA+ simulent le comportement des systèmes spéci�és. Un comportementcorrespond à une séquence in�nie d'états (Cf. �gure A.1).

MODULE VisuCom

EXTENDS Naturals, SequencesCONSTANTS

ContactsAddressBook, ContactsProgram,Client, Friend, Family,Premium, NotPremium

Unknown ≜ CHOOSE c: c ∉ (ContactsAddressBook ∪ ContactsProgram)

Contacts ≜ ContactsAddressBook ∪ ContactsProgram ∪ {Unknown}

VARIABLES currentNode, callerTests, signalingActions

Fig. A.2 � Spéci�cation TLA+ d'un service VisuCom - partie 1

Les spéci�cations écrites en TLA+ sont partitionnées en modules. Chaque moduleM de la spéci�cation (excepté les sous-modules) doit se trouver dans un �chier nomméM.TLA. Un �chiers TLA commence alors obligatoirement par une ligne spéci�ant le nomdu module (c'est-à-dire, le nom du �chier TLA). Par exemple, sur la �gure A.2, le nomdu module est VisuCom. Cette �gure représente un extrait de la spéci�cation TLA+ duservice VisuCom illustré par la �gure 9.11. Ensuite, un module peut étendre d'autresmodules via le mot clé EXTENDS. Par exemple, le module VisuCom de la �gure A.2étend les modules Naturals et Sequences. De ce fait, il est désormais possible d'utiliserau sein du module VisuCom, des opérateurs arithmétiques tels que modulo ou encoredes primitives sur les séquences telles que Len qui donne la longueur d'une séquence (Cf.�gure A.3). Le mot clé CONSTANTS permet de déclarer des paramètres constants de laspéci�cation. Dans l'exemple de la �gure A.2, Client est une constante qui représenteun groupe de la base de contacts. Le mot clé VARIABLES permet de déclarer, quant àlui, les variables d'état du programme.

Ensuite, un prédicat d'état, nommé ici Init, doit être dé�ni. Il spéci�e l'état initialc'est-à-dire les valeurs initiales possibles que peuvent prendre les di�érentes variablesd'état. La �gure A.3 illustre ce prédicat de la spéci�cation TLA+ correspondant à notreservice de téléphonie VisuCom. Puis, une action, nommée Next, doit être dé�nie. Ellespéci�e de quelle manière les valeurs des variables d'état peuvent changer pendant uneétape, autrement dit quelles sont les transitions autorisées par le programme. Il faut

156 Le langage TLA+

Init ≜∧ currentNode = "Incoming"∧ callerTests = ⟨ ⟩∧ signalingActions = ⟨ ⟩

...Next ≜

∨ Incoming∨ ClientGroupTrue∨ ClientGroupFalse∨ PremiumTrue∨ PremiumFalse∨ Forward∨ RedirectToTheSecretary∨ Reject∨ End

vars ≜ ⟨currentNode, callersTests, signaligActions⟩

Spec ≜ Init ∧ □[Next]vars

Safety ≜ □Inv

Fairness ≜ □ ◊ ⟨Next⟩vars

TemporalSpec ≜ Spec ∧ WFvars(Next)

Consistency ≜ □(∃x ∈ Contacts : ∀n ∈ 1..Len(callerTests) : x ∈ callerTests[n])...THEOREM TemporalSpec ⇒

∧ Safety∧ Fairness∧ Consistency∧ NoTwiceForwardToTheSameUri

...

Fig. A.3 � Spéci�cation TLA+ d'un service VisuCom - partie 2

rappeler qu'une transition est dite autorisée si elle peut être produite par une opéra-tion du programme. Ainsi, comme le montre la �gure A.3, l'action Next correspond àune disjonction de ces actions. De plus, des formules temporelles peuvent être ajoutéesau programme. L'extrait de la �gure A.3 montre les formules temporelles suivantes :Fairness ou encore Consistency. Si l'action Next spéci�e ce que le programme peutfaire, les formules temporelles décrivent quant à elles ce que le programme doit ultime-ment faire. Finalement, une spéci�cation standard écrite en TLA+ se présente gérérale-ment sous la forme suivante : Spec

∆= Init ∧ 2[Next]vars ∧ TemporalForlumas

où TemporalFormulas est la conjonction de l'ensemble des formules temporelles qui se-ront véri�ées par le système. En outre, une formule temporelle particulière est dé�nievia le mot clé THEOREM. Cette formule doit être satisfaite par tous les comportements dusystème. Comme le montre la �gure A.3, un théorème est décrit par une implication quisigni�e que la spéci�cation temporelle du système spéci�é (TemporalSpec) implique quetoutes les propriétés présentes soient véri�ées. Si tel est le cas alors le service VisuComen question est en accord avec la base de contacts au moment de la véri�cation et avecles besoins du domaine de la téléphonie.

A�n de présenter certains opérateurs temporels linéaires utilisés en TLA+, la nota-tion suivante sera utilisée : F et G sont deux formules temporelles, A est une action etvars est un ensemble des variables d'état.

2F F est toujours vrai, c'est-à-dire que F est vrai pour toute étape dans le comporte-

Le model checker TLC 157

ment.

3F F n'est pas toujours faux, c'est-à-dire que F deviendra vrai à un certain moment.Cet opérateur est souvent assimilé à "ultimement" ou "un jour" (eventually).Cette formule peut être récrite avec l'opérateur 2 : 3F <=> ¬2¬F.

F ; G si F est vrai alors un jour G sera à son tour vrai. La formule F ; G est lueF "conduit à" G. Cette formule peut être récrite avec l'opérateur 2 :F ; G <=> 2(F =⇒ 3G).

2[A vars ] cette formule est vrai pour un comportement si et seulement si chaque pairesuccessive d'étapes du comportement est une étape [A]vars . Cette formule estéquivalente à la formule suivante : A ∨ (vars′ = vars).

3〈A〉vars a�rme qu'à un certain moment une étape 〈A〉vars arrivera. Cette formule peutêtre récrite sous la forme : ¬2[¬A]vars , ce qui est équivalent à :A ∧ (vars 6= vars′).

23F a�rme que F est in�niment souvent vrai. En particulier, 23〈A〉vars a�rme qu'in-�niment souvent des étapes 〈A〉vars arriveront.

32F a�rme qu'à un certain moment F devient vrai et reste toujours vrai par la suite.En particulier, 32[A]vars a�rme qu'à partir d'un certain moment, toute étapeest une [A]vars étape.

enabled A signi�e que l'action A est permise. Autrement dit enabled A est unefonction d'état qui est vraie dans un état s si et seulement si il existe un certainétat t tel que s → t est une A étape.

WF(A)vars si à partir d'un moment, A est toujours permise alors des A étapes arriverontin�niment souvent. Cette formule dé�nit l'équité faible de l'action A. Cette formuleest équivalente à la formule suivante : 32(enabled 〈A〉vars) =⇒ 23〈A〉vars .

SF(A)vars si A est toujours in�niment permise alors des A étapes arriveront in�nimentsouvent. Cette formule dé�nit l'équité forte de l'action A. Cette formule est équi-valente à la formule suivante : 23(enabled 〈A〉vars) =⇒ 23〈A〉vars .

Le langage TLA+ utilise d'autres opérateurs de logique temporelle tels que ∃∃∃∃∃∃ , ∀∀∀∀∀∀et +−. . Il est à noter qu'à l'exception de ces trois opérateurs temporels, tous les autresdé�nis ci-dessus sont exprimables en fonction de l'opérateur 2. Cette section ne donnequ'un bref aperçu des possibilités du langage TLA+. Ainsi, le lecteur voulant en ap-prendre davantage peut se référer au livre de Leslie Lamport [Lam02].

A.4 Le model checker TLC

Le langage TLA+ est supporté par un ensemble d'outils : TLC, SANY, +CAL,TLATeX. Le plus sophistiqué d'entre eux est le véri�cateur de modèles TLC. Cet ou-til a été développé par Yuan Wu et l'équipe de Leslie Lamport en 1999. Il permet devéri�er automatiquement que les spéci�cations écrites en TLA+ satisfont bien les pro-priétés temporelles dé�nies. Il aide également à trouver les di�érentes erreurs qui sesont glissées dans les spéci�cations TLA+ en générant les di�érents états possibles du

158 Le langage TLA+

système. TLC distingue deux types d'erreurs : les erreurs de typage et les interblocages(deadlocks). TLC prend en entrée des modules TLA+, tels que dé�nis précédemment,et les �chiers de con�guration associés. Ces �chiers de con�guration a�ectent des va-leurs aux constantes a�n de donner un modèle pour l'exécution du système, et déclarentégalement les paramètres de la spéci�cation ainsi que les diverses propriétés temporellesà véri�er.

Le "model checker" TLC permet de véri�er des propriétés dites de sûreté (safety), devivacité (liveness) ou encore d'équité (fairness). Tout d'abord, les propriétés de sûretésont généralement exprimées via l'opérateur 2. Elles garantissent qu'aucun état erronén'arrivera, autrement dit que tous les comportements autorisés par le système spéci�écorrespondent bien à ce que le système est supposé faire. Ainsi, une propriété de sûretédoit être véri�ée par tous les états du système. Par exemple, il s'agit de véri�er queles invariants du système sont bien maintenus quel que soit le comportement exécuté.Ensuite, les propriétés de vivacité sont généralement exprimées via les deux opérateurssuivants : 3 et ; . Elles garantissent qu'à un certain moment un bon état surviendra.Autrement dit, toute propriété de vivacité sera véri�ée un jour ou l'autre pour chacundes comportements autorisés par le système spéci�é. Il est à noter que TLC ne permetpas de véri�er les propriétés de vivacité sur les actions mais sur les variables d'état dusystème. En�n, les propriétés d'équité sont généralement exprimées via 23 et 32. Unsystème est dit équitable si une action toujours exécutable a une chance d'être exécutée.En outre, il existe deux niveaux d'équité : l'équité faible exprimée par WF et l'équitéforte exprimée par SF. Un système est dit faiblement équitable si toute action toujoursréalisable à partir d'un certain moment est in�niment souvent réalisée. Un systèmeest dit fortement équitable si toute action toujours in�niment réalisable est in�nimentsouvent réalisée. Dans le cas d'un service VisuCom, véri�er l'équité du système revientà véri�er que toutes les arètes de l'arbre décisionnel sont in�niment souvent parcourues.

Le véri�cateur de modèles TLC fournit en sortie une sorte de rapport indiquant,d'une part, si des erreurs de syntaxe ont été détectées (présence d'un analyseur syn-taxique, le frontal de TLC), et d'autre part, si certaines propriétés temporelles ont étéviolées lors de la génération des comportements du système. La �gure A.5 est le résul-tat de l'exécution du service VisuCom de la �gure 9.11 avec le �chier de con�gurationdonné à la �gure A.4. Dans cet exemple, aucune erreur n'a été trouvée. De plus, TLC agénéré douze états dont neuf distincts. Un exemple de �chier de con�guration erroné etde rapport d'erreurs signi�ant la violation d'une propriété est donné à la section 9.3.2.

SPECIFICATION TemporalSpec

INVARIANT Inv

Properties Safety Fairness Consistency NoTwiceForwardToTheSameUri ...

CONSTANTSUnknown = "Unknown"

ContactsAddressBook = {"Alice", "Bob", "Charlie", "Daniel", "Eric", "Franck"}

ContactsProgram = {"Secretary"}

Client = {"Alice", "Bob", "Daniel"}

Friend = {"Daniel"}

Family = {"Alice", "Charlie", "Franck"}

Premium = {"Bob", "Franck"}

NotPremium = {"Charlie", "Eric"}

Fig. A.4 � Fichier de con�guration à un instant donné

TLC Version 2.0 of January 16, 2006Model-checking...Finished computing initial states: 1 distinct state generated.Checking temporal properties for the complete space.Model checking completed. No error has been found.

Estimates of the probability that TLC did not check all reachable statesbecause two distinct states had the same fingerprint:calculated (optimistic): 1.463672932855431E-18based on the actual fingerprints: 6.588389014860541E-18


Fig. A.5 � Extrait d'un rapport TLC sans erreur

Résumé

Le développement logiciel connaît ces dernières années un bouleversement majeurdû à l'émergence de nouveaux programmeurs non-informaticiens. Il ne s'agit plus désor-mais de fournir des solutions de programmation de plus en plus puissantes et expressives,mais davantage de produire des outils spéci�ques à un métier, haut niveau et adaptésaux utilisateurs. Cependant, la diversité des pro�ls de développeurs entraîne une multi-plicité des besoins en termes de solutions de programmation. Sans une factorisation etune automatisation des processus de conception et d'implémentation, il est impossiblede répondre à ces attentes du fait du coût de mise en ÷uvre de telles solutions. Deplus, le manque d'expertise en programmation de ces non-informaticiens entraîne descontraintes fortes en termes de �abilité, notamment en ce qui concerne le respect despropriétés métiers du domaine d'application.

Cette thèse propose une nouvelle approche basée sur les langages dédiés à un do-maine (DSL). Un langage dédié est un langage dont les constructions et les notationssont adaptées à la sémantique d'un domaine, ce qui permet aux experts de concevoirles solutions dans des termes métiers et non informatiques. Notre approche repose surune architecture en couches des langages, introduisant une séparation entre la program-mation et la modélisation de solutions. Cette di�érenciation permet à la fois d'éleverprogressivement le niveau d'abstraction des solutions, mais également de spécialiser etd'automatiser les processus de compilation et de véri�cation de propriétés du domaine.

Nous illustrons notre démarche avec le domaine de la création de services de Télé-phonie sur IP. À la suite d'une analyse complète du domaine, nous avons conçu deuxlangages dédiés, SPL et VisuCom, évoluant à des niveaux d'abstraction di�érents et ré-pondant à des besoins distincts des développeurs. À travers VisuCom, nous proposonségalement une nouvelle approche du développement de services de téléphonie, visantà intégrer le métier de l'utilisateur dans le processus de conception de services. Ens'appuyant sur ces langages, notre architecture en couches permet de séparer les préoc-cupations du domaine de celles liées à l'implémentation. Ainsi, nous montrons que lesprocessus de compilation et de véri�cation des solutions se trouvent fortement simpli�éset à la portée d'outils haut niveau existants, comme des transformateurs de programmesou des véri�cateurs de modèles.

L'approche proposée dans cette thèse est un premier pas vers la convergence desapproches de l'Ingénierie Dirigée par les Modèles et des langages de programmation,ouvrant ainsi de nouvelles perspectives de recherche relatives à ces deux approches.

Mots clés

Langages dédiés, ingénierie dirigée par les modèles, transformation et véri�cation deprogramme, téléphonie sur IP

THÈSEflfs.emn.fr/images/3/39/TheseFabry.pdf · 2014-01-14 · Sapan. En n et surtout, je remercie...

Documents

Transcript of THÈSEflfs.emn.fr/images/3/39/TheseFabry.pdf · 2014-01-14 · Sapan. En n et surtout, je remercie...