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.

Transcription

1 N o d'ordre: 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ésident MM. : Jean Bézivin Rapporteurs Olivier Danvy MM. :???? Examinateurs Renaud Marlet Charles Consel

2

3 à Laetitia,

4

5 Remerciements (provisoires) Je tiens tout d'abord à remercier les membres du jury : Jean Bézivin, professeur à l'université de Nantes (France) et Olivier Danvy, professeur à l'université d'aarhus (Danemark), d'avoir accepté la lourde tâche de rapporteur. Renaud Marlet, chargé de recherches INRIA, d'avoir gentiment accepté d'être membre de ce jury malgré un emploi du temps chargé. Charles Consel, professeur des Universités et responsable du projet Ph nix, qui m'a donné l'opportunité de réaliser cette thèse. Je tiens à lui exprimer ma très vive reconnaissance pour l'aide et le soutien qu'il m'a apporté au cours de ces années, et la conance dont il a fait preuve à mon égard. Son intérêt et ses précieux conseils m'ont été d'un grand prot. Je tiens également à remercier tout particulièrement Julien Mercadal et Vincent Malige, 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 relectures toujours pertinentes m'ont permis d'y croire même dans des moments parfois diciles, et pour cela je le remercie. Je tiens également à remercier tous les membres du projet Phoenix (David, Julien 2, Laurent 2, Nicolas, Sylvie, Wilfried et Zoé), ainsi que tous les gens qui de près ou de loin ont participé à cette aventure. Je pense entre autres à Anne-Françoise, Julia ou encore Sapan. Enn et surtout, je remercie mes proches pour leur soutien sans faille et plus particulièrement Laetitia qui m'a toujours donné la force de continuer. Sa patience, sa compréhension et ses encouragements de tous les instants m'ont permis de mener à bien cette aventure et de me concentrer sur mon travail.

6

7 Résumé Le développement logiciel connaît ces dernières années un bouleversement majeur dû à l'émergence de nouveaux programmeurs non-informaticiens. Il ne s'agit plus désormais de fournir des solutions de programmation de plus en plus puissantes et expressives, mais davantage de produire des outils spéciques à un métier, haut niveau et adaptés aux utilisateurs. Cependant, la diversité des prols de développeurs entraîne une multiplicité des besoins en termes de solutions de programmation. Sans une factorisation et une automatisation des processus de conception et d'implémentation, il est impossible de répondre à ces attentes du fait du coût de mise en uvre de telles solutions. De plus, le manque d'expertise en programmation de ces non-informaticiens entraîne des contraintes fortes en termes de abilité, notamment en ce qui concerne le respect des propriétés métiers du domaine d'application. Cette thèse propose une nouvelle approche basée sur les langages dédiés à un domaine (DSL). Un langage dédié est un langage dont les constructions et les notations sont adaptées à la sémantique d'un domaine, ce qui permet aux experts de concevoir les solutions dans des termes métiers et non informatiques. Notre approche repose sur une architecture en couches des langages, introduisant une séparation entre la programmation et la modélisation de solutions. Cette diérenciation permet à la fois d'élever progressivement le niveau d'abstraction des solutions, mais également de spécialiser et d'automatiser les processus de compilation et de vérication 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 deux langages 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. En s'appuyant sur ces langages, notre architecture en couches permet de séparer les préoccupations du domaine de celles liées à l'implémentation. Ainsi, nous montrons que les processus de compilation et de vérication des solutions se trouvent fortement simpliés et à la portée d'outils haut niveau existants, comme des transformateurs de programmes ou des véricateurs de modèles. L'approche proposée dans cette thèse est un premier pas vers la convergence des approches 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érication de programme, téléphonie sur IP

8

9 Abstract Over the last decade, allowing non-programmers to write their own programs has become a practical challenge that is currently receiving enormous attention in the software engineering community. The question is no longer to provide expressive and powerful programming solutions, but to develop domain-specic high-level tools that are adapted to the users. Because a variety of preferences and constraints can be expressed by these non-programmers, a variety of programming solutions must be envisioned that oer dierent visual or textual paradigms and various degrees of expressivity. Providing such a panel of solutions is likely to be a major development process. Moreover, because these non-programmers have no programming training, the reliability of their programs is a fundamental problem that requires verication of domain-specic properties. This thesis proposes a new approach to the development of high-level solutions that is based on a layered view of domain-specic languages (DSL). By nature, DSLs are very dierent. A study of the literature in domain-specic modeling raises the issue of relating and distinguishing the notion of domain-specic languages from a modeling viewpoint and from a programming-language viewpoint. This distinction enables one to separate the domain concerns from the implementation concerns. In doing so, the abstraction level is raised further, bringing up opportunities regarding the compilation of programs and the verication of their domain-specic properties. We have validated our approach in the domain of telephony service creation. Through a complete domain analysis, we have designed two dierent domain-specic languages, SPL and VisuCom. SPL is an expressive programming language that provides service developers with high-level, domain-specic constructs. In contrast, VisuCom allows domain experts to directly express solutions in domain terms, without necessarily requiring programming skills. We show that layering DSLs enables one to separate domain concerns and implementation concerns. In doing so, our approach greatly facilitates the implementation of high-level solutions and the verication of telephony-specic properties, by leveraging on high-level tools such as program-transformation tools or model checkers. The proposed approach is a rst step in the convergence of modeling and programminglanguage approaches, opening up new research opportunities in these two elds. Key words Domain-specic languages, model-driven engineering, program transformation and verication, telephony over IP

10

11 Table des matières 1 Introduction Thèse Contributions Organisation du document I Contexte 13 2 Ingénierie dirigée par les modèles Introduction à la modélisation Motivations Le monde des modèles Approches existantes Architecture dirigée par les modèles Modélisation spécique à un domaine Limitations des approches Architecture dirigée par les modèles Modélisation spécique à un domaine Évolution récente de l'idm Bilan Langages dédiés Introduction Motivations Programmation du domaine de problèmes Sûreté améliorée Réutilisation systématique Processus de développement Conception Implémentation Limitations actuelles Coût de développement Problèmes liés au domaine Propriétés du langage

12 3.5 Bilan Étude de cas : la Téléphonie sur IP Introduction à la téléphonie applicative L'environnement SIP Les principes du protocole SIP SIP par l'exemple Introduction aux services SIP Les enjeux de la création de services État de l'art des solutions existantes Bilan Bilan La diversité des programmeurs Problématiques II Approche proposée 55 6 Présentation de l'approche L'approche proposée Une dichotomie bien réelle Application à la Téléphonie sur IP Analyse du domaine Une programmation trop complexe Des approches divergentes Bilan SPL, un langage dédié de programmation L'environnement d'exécution Le langage Propriétés garanties Implémentation VisuCom, un langage dédié de modélisation De nouveaux besoins Une nouvelle approche Le langage VisuCom Propriétés garanties Application de notre approche Bilan Méthodologie de compilation de DSL Problématique de la compilation d'un DSL Méthodologie de développement de compilateurs La représentation abstraite

13 Table des matières Les diérentes dimensions de compilation Compilation de la représentation abstraite La programmation orientée aspect Les annotations La spécialisation de programme Compilation des unités fonctionnelles Facette environnement d'exécution Facette langage Facette programme Compilation des unités non-fonctionnelles Facette environnement d'exécution Facette langage Facette programme Bilan Compilation et vérication de DSML Introduction Stratego/XT TLA Compilation de DSML Compilation vers SPL Compilation vers TLA Vérication de DSML Vérication de services CPL Le cas particulier du modèle VisuCom Travaux connexes à notre approche en couches Bilan Conclusion Contributions Perspectives et Futures Directions Publications 137 Bibliographie 139 A Le langage TLA+ 153 A.1 Logique temporelle : un peu d'histoire A.2 Qu'est ce que la logique temporelle des actions? A.3 Spécication TLA A.4 Le model checker TLC

14 4 Table des matières

15 Table des gures 2.1 Niveaux de modélisation Architecture dirigée par les modèles (MDA) Modélisation spécique à un domaine (DSM) Processus de développement d'un langage dédié Architecture SIP Service de téléphonie écrit en CPL Vue générale de notre approche Le service Compteur écrit en JAIN SIP L'environnement SIP-SLEE et les méthodes de contrôle Structure d'un service SPL Le service Compteur écrit en SPL Le service hotline écrit en SPL Processus d'interconnexion du SI au système de téléphonie Exemple d'informations concernant un contact Le service VisuCom Filtrage sur Indisponibilité Illustration de notre approche dans la téléphonie Comparaison des approches CPL, VisuCom et SPL Comparaison des approches SPL et JAIN SIP Méthodologie de développement de compilateurs de DSL Le service Compteur écrit en SPL La représentation abstraite du service Compteur écrite en JAIN SIP Comparaison du service SPL et de sa représentation abstraite Aspect correspondant à la facette environnement d'exécution Aspect correspondant à la facette langage (1) Aspect correspondant à la facette langage (2) Aspect correspondant à la facette programme Annotations correspondantes à la facette langage Compilation et vérication de DSML Comparaison des approches CPL et SPL

16 6 Table des gures 9.3 Règles Stratego pour compiler CPL en SPL Règle Stratego pour compiler VisuCom en SPL Règle Stratego pour générer une spécication TLA+ depuis CPL Règle Stratego pour générer une spécication TLA+ depuis VisuCom Extrait des propriétés à vérier pour un service de téléphonie Service CPL inconsistant (adresses) Service CPL inconsistant (dates) Rapport d'erreurs TLC concernant un service CPL Service VisuCom inconsistant vis-à-vis de la base de contacts Rapport d'erreurs TLC concernant un service VisuCom A.1 Séquence d'états A.2 Spécication TLA+ d'un service VisuCom - partie A.3 Spécication TLA+ d'un service VisuCom - partie A.4 Fichier de conguration à un instant donné A.5 Extrait d'un rapport TLC sans erreur

17 Chapitre 1 Introduction Ces dernières années ont vu l'émergence d'un nouveau type de programmeur, l'utilisateur nal [MKB06]. Ces utilisateurs perçoivent la programmation comme un nouveau moyen d'exprimer des solutions en adéquation à leurs problèmes. Un programmeur n'est plus désormais principalement un expert en programmation, mais il peut à la place être un comptable qui manipule des feuilles de calcul, un nancier qui souhaite simuler l'évolution des marchés boursiers, ou encore un électronicien qui désire modéliser le comportement d'un système électronique [SSM05a]. Ces nouveaux développeurs 1 utilisent l'ordinateur pour une tâche bien précise relative à leurs métiers, à leurs domaines de compétence, mais ne possèdent souvent aucune connaissance en programmation. L'un des premiers enjeux consiste donc à faire disparaître toute notion de programme et ne garder que les informations pertinentes du point de vue de l'utilisateur et de son domaine. 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 logicielle comme un moyen de masquer et de gérer toute cette complexité. Abstraire un système consiste à en extraire les caractéristiques essentielles par rapport à un type d'utilisateur et à un domaine particulier. Ce faisant, l'abstraction permet non seulement de cacher les détails non essentiels à l'utilisateur, mais également de s'appuyer sur des connaissances métiers pour résoudre des problèmes récurrents de ce domaine. De nombreuses approches permettent d'élever le niveau d'abstraction et de masquer la complexité des systèmes [CE00]. La plus récente est l'ingénierie Dirigée par les Modèles (IDM). Elle vise à utiliser des représentations abstraites et simpliées de systèmes (appelées modèles) an d'élever le niveau d'abstraction et d'augmenter l'automatisation du développement de programmes [Béz06]. Cependant, la plupart du temps, ces solutions fournissent des abstractions de l'espace de solutions, c'est-à-dire du domaine des technologies informatiques, plutôt que des abstractions de l'espace de problèmes, qui permettraient d'exprimer les besoins dans les termes des domaines d'application (nance, médecine, assurance, ou encore biologie). Or, il ne s'agit pas seulement 1 Dans la suite de ce document, nous utiliserons le terme développeurs pour désigner ces nouveaux utilisateurs sans expérience en programmation, parfois appelés non-programmeurs. 7

18 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 permettent de raisonner au même niveau que le problème, tout en leur assurant un certain nombre de propriétés spéciques à 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 son travail ecacement. 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 plombier d'utiliser la même boîte à outils. Il en va de même pour les outils informatiques. De par la diversité des utilisateurs et des domaines d'application, il est impossible de mettre en uvre une solution généraliste, qui fournirait des abstractions généralistes et qui permettrait à tous les développeurs non-informaticiens de résoudre leurs problèmes. Au contraire, il apparaît évident que cette multitude de domaines et d'utilisateurs nécessite la mise en place d'outils spéciques, dédiés tant au métier qu'au prol du développeur auxquels ils sont destinés. De plus, pour paraphraser Jackson, la valeur d'une abstraction augmente avec son degré de spécicité dans le domaine [Jac01]. Une abstraction plus spécique contient donc davantage de connaissance sur le domaine qu'une abstraction plus généraliste parce qu'elle renferme plus d'informations. En d'autres termes, elle est 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 langages de programmation et plus spéciquement les langages de programmation dédiés à un domaine (DSL 2 ). Elle repose sur une architecture en couches des langages. Cette architecture permet à la fois d'élever progressivement le niveau d'abstraction, mais aussi de prendre en compte toutes les spécicités du domaine d'application, an de fournir aux utilisateurs des outils dédiés à leurs métiers ou à la tâche à eectuer. Les langages de demain ne sont pas des langages de programmation traditionnels, mais bien plus des langages qui sont adaptés aux utilisateurs, à leurs connaissances ou encore à leurs rôles dans l'organisation 3. Nous illustrons et validons notre approche par l'étude du domaine de la création de services de Téléphonie sur IP. Un langage dédié se dénit comme un langage de programmation restreint à un domaine ou un problème particulier. Il représente un moyen reconnu pour permettre aux utilisateurs de programmer sans être experts en programmation. L'utilisation des langages dédiés permet de faciliter de manière signicative la construction de systèmes logiciels pour les domaines auxquels ils sont dédiés [Ben86]. De plus, du fait d'une expressivité restreinte, ils facilitent la vérication de propriétés métiers, ou encore augmentent la productivité logicielle [Thi98]. Cependant, la conception et l'implémentation de DSL sont encore aujourd'hui des tâches considérées comme ardues. C'est l'une des 2 DSL est l'acronyme anglais de Domain-Specic Language. 3 Dans la suite de ce document, le terme organisation désigne une entreprise, une administration, ou tout simplement un service ou tout autre structure professionnelle.

19 Contributions 9 raisons pour lesquelles les langages dédiés ne sont pas aujourd'hui aussi populaires que pourraient le souhaiter les chercheurs. L'approche que nous proposons introduit plusieurs langages dédiés au domaine de la création de services de Téléphonie sur IP. Ces langages évoluent à des niveaux d'abstraction diérents et sont adaptés à des programmeurs ayant des compétences diérentes ainsi que des rôles diérents dans l'organisation. Les langages dédiés de plus haut niveau, c'est-à-dire possédant les plus fortes abstractions, sont implémentés sous la forme d'un langage dédié de plus bas niveau, plus expressif et plus à même de résoudre des familles de problèmes complexes. Ce dernier est ensuite compilé dans un environnement d'exécution. Cette architecture en couches des langages permet de réduire simplement le fossé entre les abstractions du domaine et leurs implémentations, mais également de réutiliser le langage dédié intermédiaire, facilitant ainsi l'implémentation des langages de plus haut niveau. Cette architecture introduit, de plus, une diérenciation des approches entre la modélisation de solutions et la programmation de solutions, ce qui permet à chaque niveau de spécialiser certaines tâches comme la vérication de propriétés ou encore la compilation. 1.2 Contributions La contribution de cette thèse est double. Dans un premier temps, nous montrons comment, par une analyse de domaine et une approche centrée sur les besoins des utilisateurs, 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éphonie sur IP. Cette démarche nous permet de monter en abstraction dans le domaine et de fournir 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ée sur la réutilisation d'outils existants, et évaluons les avantages de cette approche en termes de facilité de compilation et de vérication de propriétés du domaine. Approche orientée utilisateurs des langages dédiés. Nous introduisons une nouvelle approche des langages dédiés, centrée sur les besoins de l'utilisateur nal. Nous montrons qu'une distinction entre des langages orientés programmation et des langages orientés modélisation nous permet de diérencier les besoins des développeurs, mais aussi d'architecturer les langages. Analyse de domaine. Nous présentons une analyse complète du domaine de la création de services de Téléphonie sur IP. Nous identions les diérents acteurs du domaine et leurs rôles, et nous introduisons deux langages dédiés, SPL 4 et VisuCom, qui permettent 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 4 SPL est l'acronyme de Session Processing Language.

20 10 Introduction en abstraction, tout en résolvant le problème du fossé entre le niveau d'abstraction et l'implémentation. Illustrée dans le domaine de la création de services de Téléphonie sur IP, nous montrons que cette architecture permet de séparer les préoccupations du domaine de celles liées à l'implémentation. Processus de compilation simplié. La séparation des préoccupations et l'architecture en couches nous permettent de montrer que le processus de compilation devient beaucoup plus simple de par la diminution du pas de compilation. De plus, chaque niveau d'abstraction est dédié à des aspects diérents, domaine et implémentation, ce qui permet de dédier chaque processus de compilation. Nous montrons également comment les outils de génération de programmes haut niveau peuvent aider à simplier ces étapes de compilation. Vérication de propriétés du domaine. La séparation des préoccupations facilite notablement la vérication des propriétés du domaine. Les détails d'implémentation n'apparaissant plus, seule la logique du domaine est manipulée. Nous montrons alors comment notre architecture facilite la réutilisation des outils haut niveau an de vérier des propriétés du domaine de la téléphonie, à l'aide d'un véricateur de modèles (model checker) par exemple. 1.3 Organisation du document Ce document est organisé en deux parties. Nous présentons tout d'abord le contexte scientique dans lequel s'inscrit cette thèse. Nous décrivons ensuite notre approche et ses avantages, en l'illustrant dans le domaine de la création de services de Téléphonie sur IP. Contexte. La première partie porte sur l'étude du contexte scientique dans lequel nous nous plaçons. Les chapitres 2 et 3 présentent respectivement un état de l'art autour des approches existantes de l'ingénierie Dirigée par les Modèles et des langages dédiés. Ces deux approches sont aujourd'hui les plus répandues pour élever le niveau d'abstraction des systèmes logiciels. Ces chapitres montrent également pourquoi ces mécanismes ne permettent pas à eux seuls de répondre aux besoins énoncés dans ce document et soulignent leurs limites. Le chapitre 4 présente le domaine d'application choisi pour illustrer notre thèse : la création de services de Téléphonie sur IP. Enn, le chapitre 5 dresse le bilan de cette étude et résume les problématiques soulevées par l'ouverture de la programmation à des non-programmeurs. Approche proposée. La seconde partie vise à illustrer l'approche proposée dans le domaine de la création de services de Téléphonie sur IP. Le chapitre 6 présente notre approche en couches des langages, basée sur une décomposition des solutions de programmation 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

21 Organisation du document 11 introduit deux langages dédiés, SPL et VisuCom. Les chapitres 8 et 9 illustrent les avantages de la séparation entre le domaine et l'implémentation, à la fois en termes de processus de compilation et de vérications de propriétés du domaine. Pour conclure, le chapitre 10 récapitule nos contributions et donne les directions futures de nos travaux.

22 12 Introduction

23 Première partie Contexte 13

24

25 Chapitre 2 Ingénierie dirigée par les modèles La complexité et la diversité des technologies existantes, mais aussi la multiplication des besoins, font aujourd'hui du développement logiciel un véritable dé. Pour y faire face, il est nécessaire de fournir une approche permettant d'abstraire toutes les complexités technologiques. L'Ingénierie Dirigée par les Modèles (IDM 1 ) cherche à répondre à cette attente. Cette approche émergente du développement logiciel considère le modèle comme l'objet central de toutes les réexions dans les processus de conception et de développement logiciel. Désormais, il ne s'agit plus de considérer les modèles du seul point de vue contemplatif, mais également d'un point de vue productif, visant l'automatisation 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 solution au problème de la complexité logicielle. Après une brève introduction sur les enjeux et les concepts autour de la modélisation, nous présentons un aperçu macroscopique des solutions existantes, et tout particulièrement l'initiative MDA (Model-Driven Architecture), fer de lance de l'ingénierie Dirigée par les Modèles. Enn, nous nous penchons sur les limites actuelles de ces solutions pour un déploiement industriel. 2.1 Introduction à la modélisation De Bill Gates à Richard Soley 2, en passant bien entendu par les pionniers du monde UML (Unied Modeling Language) comme Graddy Booch, tous arment qu'il est temps de concevoir les applications logicielles à partir de modèles, et surtout, de faire en sorte que ces modèles soient au centre du cycle de vie des applications, autrement dit qu'ils soient productifs [Bla05]. La modélisation, au sens le plus large, vise à représenter de manière abstraite et la plus simpliée possible une entité du monde réel, en vue de la décrire, l'expliquer, 1 Pour évoquer l'ingénierie Dirigée par les Modèles, la littérature anglaise fait état de deux expressions Model-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. 2 Richard Soley est le directeur de l'omg (Object Management Group), un groupement international dont l'objectif est de promouvoir des standards qui garantissent l'interopérabilité entre applications orientées objet. 15

26 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ème logiciel 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 que le concepteur juge important pour la compréhension du système modélisé. Loin de se réduire à l'expression d'une solution à un niveau d'abstraction plus élevé que le code, la modélisation recherche avant tout une automatisation du développement logiciel, ainsi qu'une réduction des coûts de développement. Si ces mécanismes d'abstraction et de modélisation ne représentent pas une innovation en soi et sont le pain quotidien des développeurs depuis toujours, bien souvent leurs utilisations se font de manière implicite ou tout du moins informelle. Le véritable dé de l'approche de l'ingénierie Dirigée par les Modèles est de mécaniser ce processus. Son but est de mettre à disposition des outils, concepts et langages pour créer et transformer les modèles. De manière plus générale, et comme de nombreuses autres approches du génie logiciel (programmation générative, programmation par aspects, ou encore langages dédiés), l'idm est une forme d'ingénierie générative, qui se singularise par une démarche dans laquelle tout ou partie d'une application informatique est générée à partir de modèles Motivations Les motivations et les principes sous-jacents au développement dirigé par les modèles ne sont pas nouveaux. Le but premier est d'élever le niveau d'abstraction et ce faisant, de réduire à la fois l'eort des développeurs ainsi que la complexité des artéfacts logiciels qu'ils utilisent. Ainsi, l'approche vise à automatiser le processus de développement logiciel. Mais, si la maîtrise de la complexité reste aujourd'hui l'un des enjeux majeurs du développement logiciel, elle n'est pas le seul facteur à l'émergence des nouveaux dés du 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 combinaison 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 domaines, des techniques, des processus, ou encore des outils de développement tendent à rendre spécique la tâche de développement logiciel, ainsi qu'à spécialiser les compétences techniques des concepteurs, mais aussi des utilisateurs. Toute généralisation ou automatisation du processus devient alors impensable. De la notion de diversité des besoins découle alors la nécessité de variation de produits logiciels. Cette variation peut se traduire en termes de besoins fonctionnels, mais également non-fonctionnels (e.g., sécurité, abilité, performance, exibilité). Dans un contexte de lignes de produits, cette problématique se retrouve dans le besoin de décliner des gammes de produits. Il est alors primordial de ne pas refaire à chaque fois le processus complexe de conception dans son intégralité mais de factoriser, de capitaliser et d'automatiser le plus possible les étapes de 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é à la notion 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

27 Introduction à la modélisation 17 que les limites des domaines d'application peuvent évoluer, les outils de développement peuvent changer, les plates-formes technologiques peuvent devenir obsolètes. An de répondre à ces attentes, l'ingénierie Dirigée par les Modèles s'appuie sur un principe fort du génie logiciel, la séparation des préoccupations. Il est en eet nécessaire de clairement découpler la logique métier de la mise en uvre technologique. L'abstraction vis-à-vis des technologies d'implémentation permet par exemple d'adapter une logique métier à un contexte d'utilisation particulier, mais aussi d'évoluer plus facilement vers de nouvelles technologies. Voilà pourquoi il est généralement utile d'introduire diérents niveaux d'abstraction pour modéliser un système Le monde des modèles L'Ingénierie Dirigée par les Modèles utilise l'image de modèles productifs comme leitmotiv, an d'expliquer les théories sous-jacentes à l'utilisation actuelle des modèles. An de bien comprendre les concepts et leurs relations, il est primordial de changer notre perception courante des modèles, et de passer d'une vision contemplative des modèles (ayant pour but de documenter, spécier, 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ère précise et pour automatiser tout ou partie de son implémentation. Pour cela, l'approche repose 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 les relations qui existent entre ces concepts. Elle vise avant tout à préciser la terminologie employé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 aucune dénition n'est véritablement reconnue à ce jour, la littérature [BG01] s'accorde à caractériser un modèle de la manière suivante. Un modèle peut être vu comme une abstraction d'un système, et de manière plus générale, comme une abstraction de la réalité. Bien évidemment, du fait qu'un modèle augmente le niveau d'abstraction, des informations sont omises, ce qui rend le système plus simple et plus facile à comprendre. Ainsi, les modèles permettent de capturer la complexité d'un système et de raisonner sur quelques-unes de ses propriétés, en ignorant certains détails de manière à ne considérer que ceux qui peuvent ê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'il contient sont choisies pour être pertinentes. Les critères de choix concernant les informations à visualiser dépendent donc du point de vue considéré. À titre d'exemple, une carte routière est un modèle d'une zone géographique, conçu pour la circulation automobile dans cette zone. Pour être utilisable par un automobiliste, une carte routière ne doit inclure qu'une information très synthétique et spécique sur la zone cartographiée : une carte qui indique la composition des matériaux des diérentes routes ou encore qui indique seulement les chemins pédestres n'est d'aucune utilité pour un automobiliste.

28 18 Ingénierie dirigée par les modèles Méta-modèle : langage de modélisation. An de rendre un modèle utilisable, il est nécessaire de préciser et de spécier le langage dans lequel le modèle est exprimé. Ce langage de modélisation est appelé le méta-modèle. Le méta-modèle dénit ce qu'il est possible de modéliser et la relation entre les concepts manipulés dans le modèle. Il détermine 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 la carte et la signication des diérents symboles utilisés. De manière pratique, un modèle n'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'il est nécessaire d'avoir un méta-modèle pour savoir comment interpréter un modèle, pour pouvoir interpréter un méta-modèle il est nécessaire de disposer d'un langage dans lequel le méta-modèle est exprimé (un méta-modèle pour les méta-modèles). Ce dernier est appelé le méta-méta-modèle. Il représente la vue la plus abstraite et correspond à la couche d'abstraction la plus haute. An d'éviter une innité de niveaux d'abstraction, le méta-méta-modèle est, en eet, auto-descriptif, c'est-à-dire qu'il se dénit lui-même. Le méta-méta-modèle permet de spécier les éléments qui composent un méta-modèle et la manière de les manipuler. Il existe diérents langages disponibles pour l'écriture de méta-modèles comme le MOF (Meta-Object Facility), ECore, Kermeta ou KM3 (Kernel Meta Meta Model). Le choix du méta-méta-modèle est déterminant, car il est la base de toute la chaîne de modélisation et dénit les concepts sous-jacents à la représentation de tous les autres niveaux d'abstraction. χ M3 Méta-méta-modèle µ, ε Langage de méta-modélisation χ ε M2 Méta-modèle µ Langage de modélisation χ ε M1 Modèle χ 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 niveaux de modélisation (M1 : modèle, M2 : méta-modèle et M3 : méta-méta-modèle), ainsi que

29 Approches existantes 19 les relations qui existent entre les diérents concepts. Par exemple, elle montre qu'un modèle est exprimé dans un langage de modélisation et est conforme au modèle qui repré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 plusieurs mises en uvre partageant une vision similaire de ce que doit être le développement logiciel. L'IDM peut être vue comme une famille d'approches dont le principe fondateur 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 la dé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 que l'architecture Dirigée par les Modèles (Model-Driven Architecture ou MDA) [Obj03], le MIC (Model Integrated Computing) [Kar00], ou encore les usines à logiciel (Software Factories) [GSCK04]. Cette section propose un aperçu des deux grandes familles de modélisation, symbolisées par l'approche MDA et les approches de modélisation spéciques à un domaine d'application Architecture dirigée par les modèles L'Architecture Dirigée par les Modèles est une démarche logicielle proposée par l'organisme de standardisation OMG dans les années Cette vision de l'ingénierie Dirigée par les Modèles est développée autour de la notion de plate-forme d'exécution et l'utilisation de standards éprouvés. Forte de son expérience dans les intergiciels et dans la modélisation, l'omg propose à travers l'architecture MDA une norme de métamodélisation des architectures logicielles à base de composants. Une description plus détaillée des enjeux et des principes de l'approche MDA est disponible dans la thèse de Lopes [Lop05]. Principe. L'idée initiale de l'omg consistait à s'appuyer sur des standards comme UML pour décrire séparément les parties des systèmes indépendantes des plates-formes d'exécution (Platform Independant Models ou PIM 3 ) et les parties liées aux platesformes (Platform Specic Models ou PSM 3 ). 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 programmation ou autres aspects liés à l'implémentation. An de cibler des environnements d'exécution spéciques, il sut de concevoir plusieurs modèles spéciques aux platesformes (PSM) qui décrivent la manière dont les modèles de base sont implémentés sur chaque plate-forme. L'approche MDA préconise également de traduire un modèle indépendant (PIM) en un modèle spécique (PSM) à l'aide d'outils automatisés, facilitant 3 Dans 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 Specic Models et PSM.

30 20 Ingénierie dirigée par les modèles la tâche de support de nouvelles technologies, et permettant l'implémentation concrète de système. Il est également possible de transformer un PSM en un autre PSM, ce qui permet de cibler une autre plate-forme. Ces outils sont principalement des outils de transformation de modèles parmi lesquels nous pouvons citer : ATL (Atlas Transformation Language) [JK06a, JK06b], BOTL (Basic Object-oriented Transformation Language) [MB03], QVT Merge [GBA + 05] ou encore VIATRA (VIsual Automated model TRAnsformations) [CHM + 02]. Ces langages sont basés sur diérents paradigmes et sont plus ou moins adaptés à un contexte d'utilisation particulier [MCG05]. La gure 2.2 résume sous une vue schématique la démarche de modélisation MDA présentée dans cette section. PIM transformation PSM PSM transformation génération de code Code Code 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 pas chose facile, car cette dernière est en constante évolution [BCT05]. Initialement, l'approche MDA vise à manipuler diérents modèles d'un système à des niveaux d'abstraction variables, qui ultimement sont traduits dans des technologies d'implémentation variées (grâce à des transformations de modèles bien-dénies). Mais aujourd'hui, l'architecture Dirigée par les Modèles se veut davantage être un cadre unicateur pour normaliser un certain nombre de technologies, s'appuyant sur les standards OMG. La transformation entre les modèles indépendants des plates-formes (PIM) et les modèles spéciques aux plates-formes (PSM) est alors perçue comme une application de l'approche 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 de plate-forme, l'omg semble vouloir se tourner vers de nouveaux enjeux. Sans toutefois changer ses objectifs initiaux, l'approche MDA se veut aujourd'hui plus générale, insistant davantage sur le besoin de standards de modélisation. L'enjeu principal de la philosophie MDA est d'assurer l'intégrité, l'interopérabilité et la portabilité des systèmes tout en facilitant les migrations technologiques tout au long du cycle de vie d'un

31 Approches existantes 21 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 constituent les briques de base de l'architecture MDA. L'architecture repose donc sur un ensemble de recommandations non-propriétaires visant à spécier des technologies interopérables an de réaliser le développement dirigé par les modèles à l'aide de transformations automatisées. Le standard MOF (Meta Object Facility) est le standard central de l'architecture MDA et représente le socle de l'architecture. C'est un langage de métamodélisation qui permet de dénir d'autres langages comme UML (Unied Modeling Language). 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é comme un méta-modèle qui décrit la structure de modèles spéciant des systèmes informatiques. Il faut également noter que la notion de prols UML permet l'élaboration de modèles spéciques aux plates-formes (PSM). D'autres standards sont mis en avant par l'approche MDA, comme le standard d'échange de méta-données XMI (XML Metadata Interchange), le langage de contraintes OCL (Object Constraint Language) ou encore le standard d'entrepôt de méta-données CWM (Common Warehouse Metamodel). Tous ces standards constituent désormais le c ur de l'architecture. En ce qui concerne la notion 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 le langage de transformation de modèles. C'est donc grâce à lui que sont spéciées, entre autres, 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éveloppement générique reposant à la fois sur les modèles et sur un ensemble de standards de l'omg. Cette démarche permet de séparer les spécications fonctionnelles d'un système (PIM) des spécications de son implémentation (PSM). Les standards tels que MOF, UML ou encore CWM jouent un rôle fondamental car ils sont les gardiens de l'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éutilisation de composants au sein de l'architecture Modélisation spécique à un domaine Contrairement à l'approche MDA basée sur des standards de modélisation généralistes, la modélisation spécique à un domaine (Domain-Specic Modeling ou DSM 4 ) [Coo04] met en avant une méthodologie de développement centrée sur la notion de domaine et visant à améliorer la productivité. Comme son nom le suggère, la modélisation spécique à un domaine permet de réduire l'espace de conception, souvent à une simple gamme de produits pour une seule organisation, an d'augmenter le plus possible le niveau d'abstraction des modèles et de pouvoir générer totalement une implémenta- DSM. 4 Dans ce document, nous utiliserons de manière indiérente le terme Domain-Specic Modeling et

32 22 Ingénierie dirigée par les modèles tion sur-mesure pour une organisation. Cette adaptation aux besoins de l'organisation entraîne un gain en productivité. Principe. Le concept central de la modélisation DSM réside dans la notion de langage de modélisation spécique à un domaine (Domain-Specic Modeling Language ou DSML 5 ). L'approche consiste à rassembler la connaissance du domaine d'application dans un langage de modélisation dédié et, à partir de modèles écrits dans ce langage, de générer le code d'une application de manière complète sans intervention humaine. Du fait de sa portée restreinte, il est beaucoup plus facile de dénir un langage de modélisation spécique qu'un langage généraliste comme UML. De plus, sa forte spécialisation dans le domaine permet de totalement dénir une application avec un eort de modélisation relativement faible. Enn, comme il couvre le domaine cible dans son intégralité, un DSML est adapté pour permettre une génération automatique mais surtout complète du code, ou de toute documentation. La gure 2.3 montre une vue schématique du principe de modélisation spécique à un domaine. La mise en uvre de l'approche DSM s'appuie sur un environnement complet qui comprend principalement trois composants : un langage de modélisation spécique à un domaine (DSML), un générateur de 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 modèles écrits avec un haut niveau d'abstraction et la plate-forme d'exécution bas niveau pour laquelle l'application est dédiée. La question importante se situe au niveau de la distinction 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'application alors que le framework fournit un ensemble de services prédénis qui sert d'interface au générateur de code. DSML Générateur de Code Dédié Générateur de Code Dédié Générateur de Code Dédié Code Code Code Framework Framework Framework Fig. 2.3 Modélisation spécique à un domaine (DSM) 5 Dans ce document, nous utiliserons de manière indiérente le terme Domain-Specic Modeling Language et DSML.

33 Approches existantes 23 Perspective. La philosophie DSM concernant la modélisation et la génération de code depuis les modèles est complètement diérente de celle de l'approche MDA. En eet, l'intérêt des langages de modélisation ne se situe plus au niveau d'une modélisation généraliste, mais au niveau de la résolution de problèmes simples et restreints. Chaque domaine de problèmes est diérent, d'une organisation à une autre, d'un produit à un autre, ou d'un système à un autre. En traduisant les concepts et les règles d'un domaine de problèmes directement dans un langage de modélisation spécique à un domaine, il devient possible d'élever le niveau de spécication de la solution bien au delà du code et de fournir une infrastructure adaptée aux besoins de l'organisation et des utilisateurs. L'approche toute entière devient alors spécique, ce qui permet une génération complète de l'application, d'où une production plus ecace et une réduction des cycles de développement. Le problème n'est plus ici de porter un modèle indépendant sur des plates-formes d'exécution diérentes, mais d'automatiser la création de code source exécutable directement depuis les modèles DSM. De ce point de vue, l'approche de modélisation spécique à un domaine ne fait que reprendre l'idée fondamentale qui a fait le 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 des premiers essais de génération de code des outils CASE (Computer-Aided Software Engineering) [Iiv96] des années 1980 : an d'adapter exactement le langage de modélisation et le générateur de code aux besoins de l'organisation, il est indispensable que l'approche soit mise en uvre par l'organisation elle-même. Ce faisant, le temps nécessaire aux développeurs pour apprendre le langage de modélisation est réduit, du fait qu'ils choisissent eux-mêmes les termes et les concepts du langage. De plus, il devient plus facile pour le langage de modélisation d'évoluer en réponse aux changements dans le domaine. 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élisation plus réalisable et concrète, entraînant de meilleurs résultats en termes de productivité [Kel04]. An de mener à bien cette démarche, l'approche implique donc de disposer d'outils ou d'environnements de modélisation simples et puissants, qui permettent de concevoir ces langages de modélisation DSML, de fournir un support de programmation et de faciliter la génération de code. Outils de méta-modélisation. Les outils d'implémentation DSM permettent aux utilisateurs de construire des environnements de génération de code basés sur des modèles spéciques à un domaine. Ainsi, ils permettent de dénir explicitement un métamodèle, et donc un DSML, et au même niveau de programmer tous les outils spéciques nécessaires, allant des éditeurs graphiques aux générateurs de code, en passant par des transformateurs de modèles. De plus, an de guider et restreindre le développement de solutions au sein du domaine, ils autorisent la mise en place de règles. Ces règles contraignent l'utilisation du langage de modélisation en dénissant les relations autorisées entre les diérents concepts et la manière de les manipuler. Elles permettent ainsi de réduire l'espace de conception de solutions et assurent que les applications conçues sont correctes vis-à-vis du domaine. Ces outils d'implémentation DSM dièrent principalement par le langage de méta-modélisation qu'ils manipulent et qui est la base de tout

34 24 Ingénierie dirigée par les modèles l'environnement (e.g., ECore, MOF ou encore KM3). Parmi ces outils, certains sont des environnements commerciaux comme l'outil MetaEdit+ de Metacase [SLTM91], l'environnement XMF-Mosaic de Xactium [CESW04], ou encore l'environnement des DSL Tools de Microsoft [GSCK04]. D'autres sont soit des frameworks comme le Framework de 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 est ainsi d'améliorer la productivité des organisations en leur fournissant des outils et des méthodes de modélisation spéciques à leurs domaines. 2.3 Limitations des approches Bien qu'aujourd'hui les sujets autour de l'ingénierie Dirigée par les Modèles suscitent beaucoup d'intérêt, les possibilités oertes par cette nouvelle branche du génie logiciel sont encore méconnues, et beaucoup de questions restent ouvertes. De plus, en tant que technologie émergente, les approches soutenant l'idm ne sont pas encore matures. Ainsi, comme le montre Schmidt [Sch06], il est dicile de trouver des solutions techniques solides des technologies IDM, des applications industrielles de ces technologies, ou encore des bénéces avérés de cette démarche. En eet, l'approche semble soulever certaines interrogations, notamment celles relatives à la synchronisation entre les modèles et le code généré (ou d'autres représentations des modèles), au débogage de la modélisation, à la compatibilité des outils IDM ou encore à la certication de propriétés de sûreté des modèles écrits dans les DSML. Pour aggraver la situation, l'idm tout entier fait aujourd'hui face à un autre type de problème, celui d'une lutte interne entre les diérentes mouvances an de savoir quelle déclinaison est la plus à même de représenter l'idm : aux pro-uml généralistes s'opposent les pro-dsml spéciques. Dans cette 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ées précédemment Architecture dirigée par les modèles À la lecture du guide proposé par l'omg [Obj03], il apparaît évident que l'approche 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 de l'approche est fondé sur le concept de plate-forme et sur la séparation des spécications fonctionnelles d'un système (PIM) et des spécications de son implémentation (PSM). La généricité de cette démarche entraîne une ambiguïté de la dénition des concepts de l'architecture qui complexie sa mise en uvre. Une architecture ambiguë. Si les buts de l'approche MDA sont relativement clairs aujourd'hui et continuent à s'aner de jour en jour, il n'en est pas de même pour sa mise en uvre. La technologie pour l'implémenter est, en eet, 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

35 Limitations des approches 25 trait, n'importe quel outil de modélisation avec des fonctionnalités de génération de code peut prétendre implémenter l'approche MDA. De la même manière, l'architecture toute 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 au but de la personne qui modélise, et si les utilisateurs considèrent qu'un middleware est une plate-forme, les développeurs considèrent eux que les systèmes d'exploitation sont des plates-formes. La notion de modèle n'est pas plus explicite, puisque l'organisme la dénit comme suit :...une description ou une spécication d'un système et ses environnements 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 un langage 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ë. De plus, comme le suggèrent Muller et al. dans [MBS04], il n'est pas toujours simple, au sein d'une architecture donnée, de bien diérencier le caractère indépendant (PIM) d'un système de ses caractères spéciques (PSM), car cela dépend souvent du point de vue de 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 conrmer les conclusions de Muller et al., reconnaissant que comme beaucoup de points, l'indépendance de la plateforme est une aaire de degré. Par ailleurs, aucune fondation n'était jusqu'ici dénie pour transformer des modèles indépendants de plates-formes en modèles spéciques aux plates-formes [GLR + 02]. Et si la recommandation QVT [JK06a] semble proposer un cadre normatif à la transformation de modèles, très peu d'outils implémentent réellement ce standard. An de cacher l'ambiguïté résultant de tout ceci, les concepteurs de langages de modélisation généralistes mettent en avant le caractère haut niveau de leurs abstractions, suggérant ainsi que ces dernières n'ont pas besoin d'être non-ambiguës, complètes, ou encore signicatives. Cependant, par dénition, une abstraction permet de cacher les détails inutiles pour l'utilisateur, mais ne les supprime en aucun cas. En eet, ces derniers doivent encore être présents, an d'éviter toute ambiguïté due à une sémantique incomplète notamment dans le cadre d'une génération automatique de code ou d'une transformation. La perte d'informations pourrait entraîner par exemple une impossibilité de vérication 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 de résoudre plus facilement les problèmes, il est primordial que le langage de modélisation représente clairement le domaine de problèmes. L'approche MDA privilégie un langage de modélisation généraliste (UML) et utilise ce langage dans tous les domaines en formant les experts du domaine à l'utilisation de ce langage généraliste. Un standard comme UML ne peut être utilisé comme une technique ecace de développement dirigé par les modèles ou comme un langage exécutable. Il lui manque, en eet, la spécialisation 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é

36 26 Ingénierie dirigée par les modèles de méta-modélisation puissante (Meta-Object Facility ou MOF), qui permet d'étendre UML de manière quasiment arbitraire. Ainsi, UML inclut un mécanisme de prol qui lui permet d'être contraint et spécialisé pour des domaines et des plates-formes spéciques [CESW04]. L'exemple le plus connu de spécialisation d'uml à un domaine particulier est SysML [Sys05], un langage de modélisation pour l'ingénierie des systèmes. Malheureusement, 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 extensions 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'une implémentation de référence et d'une explication sémantique compréhensible par un humain an de fournir une sémantique opérationnelle. Il est donc dicile d'interpréter et d'implémenter correctement des outils de transformation de modèles UML. De plus, de par son manque de spécication, les modèles écrits dans un tel langage informel sont ouverts à des interprétations erronées. Le dernier problème réside dans la complexité inhérente à UML et à l'utilisation de prols. Si UML présente incontestablement de nombreux avantages, notamment en termes de conception et de communication, la plupart 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ération d'artéfacts, mais en aucun cas à une génération complète, à cause de son imprécision et sa généricité Modélisation spécique à un domaine Selon Greeneld et Short [GSCK04], la généricité excessive et la construction monolithique de générateurs de code font parties des freins majeurs au développement logiciel. Si le problème de la généricité est bien illustré par la démarche MDA, celui de la construction monolithique résume quant à lui parfaitement les limites liées à l'approche de modélisation spécique. En eet, l'un des problèmes de la modélisation DSM se situe au niveau de la faiblesse des générateurs de code, symbolisée notamment par l'échec des outils de type CASE. Plus le langage de modélisation est haut niveau et plus les besoins de génération de code sont importants. En conséquence, cela peut rapidement introduire une grande complexité au niveau du générateur, le rendant dicile à maintenir ou à faire évoluer. De la même manière, un point important de toute l'approche ré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érateur, 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écicité de la démarche, et de 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 la plate-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 nouvel environnement. Comme dans le cas d'uml, un problème subsiste également au niveau sémantique. En eet, 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

37 Évolution récente de l'idm 27 de sémantique rend la production d'outils DSM automatisés dicile. Pour tenter de répondre à ce problème, les environnements d'implémentation DSM fournissent souvent un 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 peut prêter à discussion et devenir un obstacle. Malgré l'aide d'outils de modélisation, cette approche 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 la démarche MDA est une idée prometteuse. Cependant, sa réalisation au travers d'uml reste 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 ses extensions complexes au prot d'approches s'appuyant sur des langages plus spéciques et sur des techniques issues de la communauté des langages. Une distinction forte, mais non clairement démontrée, est traditionnellement introduite entre les langages de programmation et les langages de modélisation. Le niveau sémantique est l'une des raisons les plus souvent avancées. En eet, les langages de modélisation sont habituellement considérés comme possédant une sémantique informelle et abstraite, alors que les langages 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 productifs, 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 la modélisation d'un point de vue contemplatif. Néanmoins, il pose désormais un problème fondamental, celui du besoin d'une sémantique précise pour les modèles, et donc pour le langage de modélisation, an de pouvoir produire du code exécutable. Cette problématique n'est pas nouvelle et est depuis longtemps adressée par la communauté des langages de programmation. Ainsi, il existe diérents langages généralistes de spécication 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 va de la spécication du programme au code source associé. Mais tout n'est pas pour autant résolu, car se pose alors le problème de la généricité. En eet, pour être ecace, 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 est d'utiliser les modèles an de capturer de manière précise l'intention du développeur et de complètement ou partiellement automatiser son implémentation. Pour cela, il sut de 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. De plus, ce langage doit posséder un certain nombre de règles syntaxiques bien établies (dit "grammaire du langage"), spéciant les combinaisons possibles des diérents concepts et

38 28 Ingénierie dirigée par les modèles termes. La signication 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 devient beaucoup plus facile de générer une implémentation valide. La problématique toute entière mais aussi les diérents critères d'un bon langage de modélisation sont très proches de la notion de langage dédié, du fait que ce dernier modélise les concepts d'un domaine spécique, mais possède également une sémantique précise qui lui permet d'être exécutable. D'autre part, l'approche Ingénierie Dirigée par les Modèles peut également s'avérer un bon soutien pour les langages dédiés. Elle peut être perçue comme un nouvel outil conceptuel et opérationnel pour leur dénition. Elle peut également servir à fournir une implémentation dans certains cas, par exemple sous la forme d'un ensemble d'outils de conversion entre langages. 2.5 Bilan L'originalité de l'ingénierie Dirigée par les Modèles ne se situe pas dans l'utilisation systématique de modèles, mais davantage dans la préoccupation de rendre les modèles productifs plutôt que contemplatifs. La section 2.1 introduit l'idée fondatrice du développement dirigé par les modèles consistant à élever le niveau d'abstraction tout en cachant toute la complexité des technologies, des procédés de développement, etc. Comme dans toutes les branches de la science et de l'ingénierie, deux approches de ce problème se distinguent, l'approche généraliste et l'approche spécique, présentées dans la section 2.2. D'un côté, l'approche MDA propose une architecture générique basée sur l'interopérabilité et la réutilisation de composants, ainsi que sur l'utilisation de standards de modélisation généralistes. De l'autre côté, la modélisation spécique à un domaine met en avant une méthodologie de développement centrée autour de la notion de domaine et 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éciques. Si le développement dirigé par les modèles séduit de plus en plus, son coût est souvent jugé 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'accord industriels et académiques sur l'utilisation des langages dédiés dans le processus de modélisation.

39 Chapitre 3 Langages dédiés Au cours des dernières décennies, l'ingénierie logicielle n'a eu de cesse d'augmenter la productivité des développements logiciels. Le saut le plus important reste sans nul doute le passage des langages assembleur aux langages de programmation de troisième génération (comme le BASIC par exemple). Cependant, depuis les années 60-70, aucun langage de programmation généraliste, ni même aucune nouvelle technologie, architecture ou framework, 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 niveau d'abstraction, ainsi que l'automatisation de la génération d'instructions, sont les principales causes de cette augmentation de la productivité. Aujourd'hui, les langages dédiés sont un moyen reconnu pour orir de tels avantages. En eet, en se concentrant sur un problème particulier, ils permettent d'augmenter le niveau d'abstraction tout en réduisant l'espace de conception. De par l'utilisation de méthodes spéciques et de concepts usuels du domaine, il devient plus facile et plus sûr de modéliser des solutions aux problèmes. Ce chapitre présente une introduction aux langages dédiés, ainsi qu'un aperçu des principaux avantages oerts par leur utilisation, vis-à-vis d'une approche traditionnelle de développement logiciel. Nous décrivons ensuite les diérentes étapes concernant la conception d'un langage dédié. Enn, nous présentons les limites actuelles de cette technologie, qui représentent parfois un frein à son acceptation dans un cadre industriel. 3.1 Introduction Un langage dédié (Domain-Specic Language ou DSL 1 ) est un langage de programmation 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 eet, du point de vue de l'exécutabilité du langage, il est primordial de bien distinguer la notation (syntaxe) et le sens (sémantique), qui font tous les deux 1 Dans ce document, nous utiliserons de manière indiérente le terme langage dédié et DSL. 29

40 30 Langages dédiés partie intégrante de la dénition du langage. Ce point constitue la diérence fondamentale avec les langages de modélisation proposés par les approches IDM. Dans leur désir de passer d'une approche contemplative à une approche productive, les approches de modélisation ont négligé la sémantique de leurs modèles. Un méta-modèle capture les concepts, les notations ou encore les relations entre les concepts d'un langage, mais pas sa sémantique [HR04]. Or, une sémantique explicite est un pré-requis indispensable pour la mise en uvre d'un langage (par transformations ou autres moyens). Cette mise en uvre concerne la compilation mais également la vérication de propriétés. Un langage dédié est un langage qui fournit des constructions et des notations adaptées à la sémantique d'un domaine, ce qui permet aux experts de penser les solutions dans des termes métiers et non informatiques. Ainsi, les concepts manipulés par le langage correspondent directement aux connaissances et aux concepts des experts du domaine. À travers l'utilisation d'abstractions spéciques, un langage dédié permet de concevoir 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, permettent 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écent et leur utilisation est certainement aussi ancienne que la notion de langage de programmation. Ainsi, le langage APT (Automatic Programmed Tool) [Ros78], développé au MIT en 1955 pour faciliter la production de rubans perforés servant à faire fonctionner des machines-outils, peut être considéré comme l'un des premiers DSL. De même, le formalisme de description de spécication syntaxique BNF (Backus Naur Form) [Bac59] date quant à lui de Toutefois, leur démocratisation n'est apparue que dans le milieu des années 90. Parmi les DSL les plus répandus aujourd'hui, nous pouvons citer le langage de formules d'excel pour les feuilles de calcul, SQL pour les requêtes de base de données, LATEX pour la mise en forme de documents ou encore Make pour la compilation d'applications. Ces langages proposent des abstractions spéciques ainsi qu'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, sans se limiter au domaine de l'informatique. Selon le domaine, un DSL peut ou non inclure des concepts de programmation. Ainsi, ils peuvent être plus ou moins centrés sur l'utilisateur nal, ne nécessitant parfois que des compétences du domaine, sans aucune expertise en programmation. Parmi les domaines ayant donnés naissance à de tels DSL, nous pouvons citer le graphisme [KH97, Ell99], les produits nanciers [ADR95], la chimie moléculaire [MR97], les systèmes de commutation téléphonique [LR94, GJKW97], les protocoles [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 des besoins 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 exibilité [KMB + 96]. Néanmoins, en contre partie, elle rend dicile une caractérisation précise des 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 notables entre ces dénitions et reste encore aujourd'hui un point de discussion. En eet,

41 Motivations 31 l'importance de la non-exécutabilité du DSL est soulignée par Wile [Wil01], alors que van Deursen et al. présupposent qu'un langage spécique à un domaine est exécutable pour ê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 des raisons pour laquelle la littérature fait état d'appellations très diérentes pour nommer les DSL. Ainsi, les langages dédiés sont également appelés "langages métier", "langages orientés application" [Sam69], "langages à but particulier" [Wex81], "langages spécialisés" [BG96], "langages spéciques à une tâche" [Nar93], "langages orientés problème" [CE00], "mini(micro ou petits)-langages" [Ben86], "langages pour utilisateur nal" [BCP01], ou encore "langages d'application" [Mar85]. Dans le contexte des langages dédiés à des applications de bases de données, ils peuvent également être appelés langages de quatrième génération (4GLs) [Mar85]. Dans la suite de ce document, nous adoptons la dénition de Consel [Con04] et considérons un DSL comme un langage de programmation exécutable dédié à un domaine 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 classe de problèmes, les langages dédiés se focalisent sur un domaine précis, et donc sur un ensemble ni de problèmes. Ce contexte d'étude particulier permet de spécialiser le processus de développement et donc d'introduire des analyses, des vérications, ou encore des optimisations spéciques au domaine. En amenant la programmation plus près du domaine de problèmes, les DSL permettent de réutiliser de manière systématique une grande partie de la connaissance et d'améliorer la sûreté des applications Programmation du domaine de problèmes Les langages dédiés sont des langages conçus sur mesure pour répondre aux besoins spéciques d'un domaine particulier. Ils facilitent de manière signicative la construction de systèmes logiciels pour ce domaine [Ben86]. En eet, un DSL permet d'augmenter la lisibilité et la concision des programmes ainsi que l'accessibilité du langage pour les experts du domaine. Son principal avantage est de rapprocher l'implémentation de la conception, c'est-à-dire de faire en sorte que l'écriture d'un programme soit la plus simple et naturelle possible pour les acteurs du domaine. La solution est plus proche de la pensée des utilisateurs qu'elle ne l'est avec un langage généraliste. Plus déclaratif qu'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 diuse tout au long du programme comme c'est le cas avec des langages de programmation généralistes. Prenons l'exemple de la commande Unix Make. Cet outil est un utilitaire pour maintenir des programmes : il détermine automatiquement les parties d'un programme qui ont besoin

42 32 Langages dédiés d'être recompilées et les recompile si besoin [SMS06]. Le langage associé est principalement déclaratif, bien qu'il possède des constructions impératives, et son pouvoir d'expression est limité à la dépendance de tâches. Il cache les détails d'implémentation comme la date de dernière modication des chiers et fournit des abstractions du domaine comme les suxes des chiers, ou la notion de règles de compilation. En élevant la programmation au niveau du domaine, les langages dédiés donnent lieu à de meilleures analyses de programmes, facilitant la validation et l'optimisation de solutions. De plus, ils permettent aux erreurs d'être détectées plus tôt dans le processus de conception 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 des programmes qui sont potentiellement plus exposés aux erreurs. L'utilisation de langages dédiés permet le développement de programmes plus sûrs. Le niveau d'abstraction de ces langages élimine un grand nombre d'erreurs courantes dans des langages de plus bas niveau (e.g., gestion de la mémoire, gestion de pointeurs, gestion de processus ou encore débordement de tampon). L'expressivité orientée métier du DSL ore des garanties de sûreté plus fortes que dans le cas de langages généralistes. Dans le meilleur des cas, certaines propriétés critiques du domaine sont rendues décidables grâce à des restrictions ou des enrichissements sémantiques. Ainsi, l'exécution d'un code malveillant ou incorrect est statiquement prohibée (avant l'exécution), car seules les opérations valides sont générées. L'outil Make illustre parfaitement ce point concernant les propriétés rendues critiques. En eet, il signale tous les cycles de dépendances entre les tâches et, de ce fait, empêche totalement la non-terminaison. Considérons un autre exemple, le langage dédié PLAN-P [TMM99], qui permet de programmer des applications pour un réseau actif. Là encore, la conception du langage garantit par construction que tout programme PLAN-P termine et que le chemin emprunté par un paquet au sein du réseau n'est pas cyclique [PB03]. Au-delà de la restriction sémantique du langage, il est également possible d'utiliser des analyses de programmes traditionnelles pour augmenter la sûreté des applications [Rév01]. Toutes ces caractéristiques des DSL rendent possible la détection plus en amont des erreurs dans le processus de production. L'utilisation d'un DSL facilite également la mise en uvre d'optimisations, notamment au niveau de la compilation du DSL. Ces optimisations spéciques au domaine peuvent souvent s'avérer plus ecaces que celles oertes par des compilateurs traditionnels. 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 ecace de la mémoire, ou encore en tirant prot d'informations particulières concernant le protocole de transport utilisé. De plus, ces optimisations permettent de manipuler des concepts haut niveau, mais aussi de pouvoir générer de manière sûre une implémentation correcte et performante. Enn, la connaissance du domaine capturée par le DSL peut être utilisée pour mettre en uvre des outils de développement spéciques comme

43 Processus de développement 33 des éditeurs, des débogueurs, ou tout autre support Réutilisation systématique La plupart des environnements de programmation inclut la capacité d'abstraire des opérations communes dans des bibliothèques. Cependant, la réutilisation de ces bibliothèques est laissée à la charge et à la discrétion de l'utilisateur. À l'inverse, de par sa nature, un langage dédié entraîne une réutilisation systématique, que ce soit au niveau du code ou au niveau de l'expertise du domaine. Le processus de conception d'abstractions consiste à identier des caractéristiques communes au niveau des solutions logicielles existantes du domaine. Ce processus a principalement deux impacts. D'une part, il permet d'associer à une abstraction un motif de code qui sera généré automatiquement. En ce sens, la conception du DSL entraîne donc une réutilisation systématique du code, voire de l'architecture dans le cadre de systèmes logiciels complexes. D'autre part, le processus de conception d'abstractions permet aux experts du domaine, à travers leurs expériences, de créer une collection d'abstractions qui sert à résoudre les problèmes du domaine. De ce point de vue, le DSL conserve la connaissance du domaine. Ainsi, les langages dédiés permettent la réutilisation de maniè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 solutions, 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 du niveau d'abstraction entraîne la concision des solutions, améliorant la productivité des utilisateurs. De plus, le DSL permet de réutiliser de manière systématique une grande partie 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écompose principalement en deux phases : la conception et l'implémentation du DSL. La conception du langage permet de délimiter le domaine d'application, notamment en dénissant précisément les objectifs et la portée du langage. Un domaine trop restreint réduit le domaine d'utilisation du langage et rend le langage inutilisable car trop spécique, alors qu'un domaine trop grand accroît la complexité du langage, de son analyse et de la vérication de propriétés. Une fois le domaine bien délimité, il s'agit de s'occuper de l'implémentation du langage Conception Lors de la conception d'un langage dédié, de nombreux aspects doivent être pris en compte. En eet, il convient de concevoir un langage simple, tant dans sa sémantique (un nombre minimal de concepts et d'abstractions) que dans sa syntaxe, mais susamment expressif pour pouvoir résoudre tous les problèmes du domaine ciblé. Le langage doit, en

44 34 Langages dédiés outre, être lisible, facilement compréhensible, mais aussi able (vis-à-vis des propriétés du domaine à respecter). Un concept clé est au c ur de la conception d'un langage dédié, le domaine. An de pouvoir répondre à toutes les attentes d'un DSL, il est indispensable de bien dénir le 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, notamment parce qu'elle ne prend pas en compte les diérences entre les entités (systèmes) qui constituent ce domaine. Pour cela, il convient d'eectuer une analyse de famille de programmes, qui vise à identier les points communs et les variations des programmes du domaine. An d'aider le concepteur du langage dans sa tâche, il est possible de se reposer sur des méthodologies existantes. Analyse de domaine. Avant de rééchir à la syntaxe d'un langage dédié à un domaine ou encore à ses propriétés, il est indispensable de s'intéresser au problème de l'identication du domaine. Si cette observation semble une évidence, savoir reconnaître le domaine et déterminer sa portée n'est pas aussi facile qu'il y paraît. C'est pour cela que 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 et modéliser ce domaine à partir de sources d'information très hétérogènes. Ces sources incluent, par exemple, les systèmes existants, les experts du domaine, les manuels, les prototypes, les standards ou encore les clients potentiels. Il s'agit de collecter les informations pertinentes du domaine et les intégrer avec cohérence au sein d'un modèle du domaine. Le concept d'analyse de domaine a été déni pour la première fois par Neighbors 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ère précise le domaine d'application et sa portée, l'analyse doit permettre de dénir le contenu et les limites du domaine, que ce soit sous la forme d'exemples de systèmes possibles mais aussi de contre-exemples. Il est également indispensable d'identier les intervenants 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 bien souvent insusante pour spécier l'ensemble du domaine. En eet, elle ne s'intéresse qu'aux points communs qui existent à l'intérieur du domaine, mais pas aux diérences, aux variations. Analyse de famille de programmes. comme suit [Par76] : Parnas dénit une famille de programmes "Nous considérons qu'un ensemble de programmes constitue une famille, lorsqu'il est utile d'étudier les programmes de cet ensemble, en étudiant d'abord ses propriétés communes puis en déterminant les particularités de chaque 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

45 Processus de développement 35 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 famille de programmes consiste à séparer les points communs des points de variations. Le but est d'identier un maximum de points communs an de les réutiliser de façon systématique. Un point commun dénit une caractéristique intrinsèque à tous les membres d'une famille de programmes. Une variation précise, quant à elle, les diérences entre les membres. Parnas propose une méthodologie pour développer une famille de programmes, permettant de réutiliser les points communs de ses membres. Un travail plus récent, l'approche FAST, est également proposé par Weiss [Wei96] et vise à identier et dénir une famille de programmes. Pour cela, il développe une analyse, appelée analyse de points communs, qui permet de découvrir la terminologie du domaine, les points communs et les variations de la famille de programmes. Ces méthodologies ne sont pas les 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ère informelle, mais dans certains cas, des méthodologies peuvent être utilisées et faciliter le travail de conception. Parmi ces méthodologies, nous pouvons citer DARE (Domain Analysis and Reuse Environment) [FPDF98], DSSA (Domain-Specic Software Architectures) [Tra95], FAST (Family-Oriented Abstractions, Specication, and Translation) [WL99], FODA (Feature-Oriented Domain Analysis) [KCH + 90], ODE (Ontology-based Domain Analysis) [FGD02], ou encore ODM (Organization Domain Modeling) [Sim95]. Le but de ces méthodologies est de fournir un support an de déterminer le bon niveau d'abstraction du langage, une terminologie spécique au domaine adéquate, ou encore la dénition et la description des concepts du domaine. Mernik et al. [MHS05] donnent une description plus détaillée de ces approches. Ils proposent également une étude systématique des facteurs à prendre en compte dans les phases de décision, d'analyse, de conception et d'implémentation d'un DSL en se basant sur l'identication de modèles existants, ainsi que sur l'étude de Spinellis [Spi01]. D'autres méthodologies de développement de DSL peuvent encore être citées comme Sprint [CM98]. Sprint est un processus complet de développement logiciel, qui démarre par l'identication des besoins du DSL jusqu'à son implémentation. Il utilise la sémantique dénotationnelle [Sch86] an de formaliser les composants de base du DSL. La structure de la dénition sémantique permet d'é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 domaine d'application. Avant de s'intéresser à la conception du langage, il est indispensable de dénir de manière précise le domaine. Cette phase de conception consiste à délimiter avec précision le domaine, en spéciant les objectifs et la portée du langage, mais aussi en 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 telles conclusions. Elles permettent également d'identier et formuler des propriétés et des concepts du domaine. Il devient alors possible de dénir la syntaxe et la sémantique du langage. Les contraintes concernant le langage, comme des besoins en analyse, sont

46 36 Langages dédiés Littérature Informations des experts Implémentations existantes Intervenants du domaine Analyse de Domaine et de Famille Concepts Points communs Variations Définition du Langage Syntaxe Sémantique Implémentation du Langage Propriétés 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, de rendre décidable certaines propriétés critiques du domaine au niveau du DSL. Il s'agit ensuite de s'intéresser à l'implémentation du langage 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ésentent pas le même coût ni les mêmes avantages. Ce point entraîne donc un choix de conception, qui est souvent guidé par les contraintes du domaine (besoin de performance par exemple). An d'éclairer la tâche des concepteurs, Mernik et al. [MHS05] proposent une comparaison 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 fait d'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 programme et donc d'assurer des propriétés du domaine avant l'exécution. Elle permet également la ré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 construction d'un compilateur ou d'un interprète permet de complètement adapter l'implémentation au domaine. De plus, aucune concession n'est nécessaire au niveau de la notation ou encore des opérations. Néanmoins, le problème reste le coût de la construction du compilateur ou de l'interprète et le manque de réutilisation pour d'autres implémentations de DSL. Langages enchâssés et librairies spéciques. La manière la plus simple de concevoir un langage dédié est de le baser sur un langage existant. Ainsi, son implémentation en devient plus simple et les utilisateurs sont déjà familiers avec la syntaxe ou le paradigme 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 possède toute la puissance et l'expressivité du langage hôte, tout en ajoutant des primitives

47 Processus de développement 37 dédiées au domaine qui sont plus proches des experts du domaine. La réutilisation de l'infrastructure existante du langage hôte est aussi un autre avantage (environnements de 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]). Une autre possibilité est d'étendre un langage existant avec de nouvelles fonctionnalités et de nouveaux concepts, spéciques au domaine (e.g., Swul avec Java [BV04], ou encore Verischemelog avec Scheme [JB00]). Les principales limitations de cette technique se situent au niveau de l'expressivité des mécanismes, qui est restreinte aux possibilité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 souvent cité 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 la robotique [PHH99]. Pré-processing et expansion de macro. Dans cette approche, les constructions du 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 à celle réalisée par le processeur du langage de base. Les traitements ne se font pas au niveau du domaine. Par exemple, la couverture d'erreurs se situe, elle aussi, au niveau du langage de base, ce qui complexie la gestion des erreurs pour l'utilisateur. Les implémentations sont multiples [Spi01]. Parmi celles-ci, nous pouvons citer entre autres : l'expansion de macros (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'approche 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érications plus abouties. Le compilateur ou l'interprète est étendu avec des règles d'optimisation, ou une génération de code, spéciques au domaine. L'interprète TCL [Ous97], ou encore le compilateur DiSTiL [SB97] sont deux implémentations de cette approche. Si les interprètes sont plus faciles à étendre, il est complexe d'appliquer cette technique aux compilateurs, 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 (Commercial O-The-Shelves ou COTS) permet de réutiliser des outils ou des notations existantes et de les appliquer à un domaine en particulier. La meilleure illustration de cette approche reste les langages dédiés sur XML [GK02] (e.g., ACML [KG03]), où de nombreux outils peuvent ê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éque en de nombreux aspects. Toutefois, sa conception n'en demeure pas moins complexe et nécessite une étude et une analyse minutieuses du domaine. En eet, des aspects à la fois fonctionnels, comme le niveau d'abstraction du langage et le degré d'analysabilité,

48 38 Langages dédiés mais aussi non-fonctionnels, comme la lisibilité ou la facilité d'écriture, doivent être pris en compte. Pour cela, il est indispensable de bien dénir et délimiter le domaine d'application. L'analyse de domaine et l'analyse de famille de programmes visent à atteindre cet objectif et permettent d'aboutir à la dénition du langage dédié. Il devient alors possible 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]), qui combinent les avantages des diérentes stratégies. 3.4 Limitations actuelles Si les langages dédiés sont réputés pour orir des gains substantiels dans leurs domaines en termes d'expressivité et de sûreté, leur développement n'est pas une tâche simple. L'implémentation d'un DSL nécessite à la fois la connaissance du domaine, mais aussi une expertise en développement de langages. Peu de personnes possèdent cette double compétence. De ce fait, la décision de développer un DSL est souvent retardée indéniment au sein d'une organisation, et beaucoup de projets de langages dédiés ne dépassent pas l'étape d'une librairie. De la même manière, il existe aujourd'hui d'autres freins à l'acceptation des langages dédiés dans les processus industriels, notamment liés au coût de développement du DSL, à la dénition du domaine et aux propriétés du langage Coût de développement La décision de développer un DSL n'est pas anodine, et prouver la rentabilité d'un tel projet est une tâche dicile. Cela demande un investissement qui peut être coûteux pour 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 par diérentes études, dont celles de Herndon et Berzins [HB88], Batory et al. [BTS94], ou encore Gray et Karsai [GK03]. Néanmoins, il est très dicile de le démontrer a priori. À ce constat vient s'ajouter l'échec de l'adoption des outils de recherche dans le monde industriel, outils qui pourraient diminuer le coût de développement et de maintenance de ces langages 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 applications commerciales, alors que d'autres prétendent qu'un tel exemple rend vague la notion de domaine d'application. Il est clair que la spécicité du domaine est une question de degré. Selon van Deursen et al. [DKV00], l'ambiguïté de la dénition des DSL hérite de l'imprécision de cette dénition de domaine. Du fait que certains le dénissent seulement "comme un ensemble de systèmes", la notion de domaine se réduit parfois aux programmes qu'il contient. Cependant, cette dénition semble trop réductrice. Un domaine est également déni à partir de bien d'autres éléments, et notamment de ses

49 Bilan 39 intervenants et de leurs besoins. Il est indispensable de s'interroger sur le type de personne qui écrit les programmes, et sur ses compétences à la fois spéciques au domaine, et en programmation. Wile tire plusieurs leçons sur ce qu'entraîne l'introduction d'un langage dédié sur une communauté d'utilisateurs [Wil04]. Considérant des réalisations concrètes, l'auteur présente trois types de problèmes qui aectent la conception, mais aussi le développement et l'adoption du DSL. Ces problèmes sont bien entendu d'ordre technologique, mais aussi organisationnel et social. Selon son étude, il apparaît important 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 et impactent donc sur la conception du langage. La notion d'utilisateurs de DSL est pourtant fréquemment délaissée, ce qui conduit souvent à une inadéquation du langage avec les besoins de l'organisation, ou à d'importantes dicultés concernant l'introduction de cette nouvelle approche dans le processus de développement. Selon le domaine, il peut également apparaître intéressant de fournir plusieurs DSL conçus pour diérentes catégories d'utilisateurs an de spécier un unique aspect de l'application (e.g., une version pour les novices et une version avancée pour les experts en programmation). De la même manière, il peut arriver que plusieurs DSL soient nécessaires pour spécier une application complète ou un domaine complexe. Cette situation pose 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 Propriétés du langage Le langage en lui-même peut également être une source de problèmes, et notamment face à des besoins de maintenance et d'évolution du langage, souvent considérés comme des points faibles de l'approche [DK98]. En eet, il n'est pas simple de faire évoluer un DSL. Par exemple, lorsqu'un nouveau type de donnée ou une nouvelle fonction est nécessaire, le compilateur a besoin d'être adapté. Cela nécessite des compétences en compilation, qui peuvent ne pas être présentes au sein des organisations. En eet, une telle compétence correspond rarement à la formation initiale des personnes qui utilisent le DSL. Enn, l'un des arguments contre l'utilisation des DSL qui reçoit le plus d'attention aujourd'hui reste le fameux eet "tour de Babel". Lorsque plusieurs développeurs construisent leurs propres langages spéciques, le nombre important de syntaxes différentes peut créer une confusion. Développer de nouveaux langages pour tous les domaines ne saurait être la solution, car cette eervescence de langages poserait des problè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 naux de programmer sans être experts en programmation. Restreints à un domaine, qui peut prendre la forme d'une famille de programmes, ils permettent de factoriser toute la

50 40 Langages dédiés connaissance relative à ce domaine dans le langage, en utilisant un haut niveau d'abstraction. Au delà d'une programmation simpliée, concise et plus rapide, ils permettent la vérication 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èmes du génie logiciel ; toutefois, un DSL conçu pour un domaine bien identié et adapté aux besoins de ses utilisateurs peut considérablement réduire les coûts de développement d'applications, tout en augmentant la productivité. Pour ces diérentes raisons, les langages dédiés ouvrent des perspectives intéressantes. Cependant, sans une méthodologie et des outils appropriés, ils peuvent apparaître diciles à mettre en uvre et coûteux à concevoir et implémenter (section 3.4).

51 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 : le domaine de la création de services de Téléphonie sur IP. Ce domaine résume la problématique présentée dans ce document, en montrant comment l'ouverture des plates-formes de téléphonie à des développeurs non-informaticiens met en péril des propriétés importantes du domaine. Le chapitre met également l'accent sur les limites des solutions actuelles, inadaptées aux besoins des utilisateurs et nécessitant des compétences importantes dans de nombreux domaines. Ce manque d'outils ables et adaptés fait de la programmation 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 particulièrement la téléphonie basée sur le protocole de signalisation SIP 1 [RSC + 02]. Nous montrons les problématiques relatives à la programmation de services de Téléphonie sur IP, 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 signicative dans la convergence entre les réseaux de téléphonie et les réseaux de données. Par rapport à la téléphonie traditionnelle, la Téléphonie sur IP ore non seulement des perspectives de simplication d'architecture et d'administration d'équipements, mais aussi l'opportunité d'enrichir le système téléphonique de nouvelles fonctionnalités, intégrant les applications informatiques 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 utilisateurs et un réel avantage concurrentiel pour les organisations. En eet, elle permet de transmettre 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 compris les 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 1 SIP est l'acronyme anglais de Session Initiation Protocol. 41

52 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 au niveau de la réduction des coûts (réutilisation du matériel et tarication des communications), comme beaucoup peuvent le penser, mais davantage au niveau des services associés. En eet, elle donne accès à des fonctionnalités avancées et des applications qui améliorent la productivité globale d'une organisation. La téléphonie applicative devient alors un véritable enjeu stratégique pour l'organisation. La convergence des télécommunications et des réseaux informatiques a ajouté un grand nombre de possibilités aux services de téléphonie classiques, grâce à l'interaction avec des éléments tels que le Web, le courrier électronique ou encore les bases de données. De plus, elle a rendu la programmation de services de téléphonie aussi accessible que la programmation de services réseau [Len04], contrairement aux solutions existantes de téléphonie traditionnelle, fermées et propriétaires. En pratique, ces services reposent sur une plate-forme téléphonique qui fournit des opérations de signalisation (e.g., localisation de l'appelé ou paramétrage de la session d'appel). La plate-forme de signalisation basée sur le protocole SIP [RSC + 02] émerge comme le standard de fait de la Téléphonie sur IP, ainsi que de la téléphonie non-laire comme le GPRS 2 et l'umts 3. Cette programmabilité 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 des langages et des interfaces de programmation non-restreints [DRM04, Kut03]. Toutefois, rendre programmable un domaine comme la téléphonie présente un grand nombre de dés. L'un de ces dés concerne la abilité des services développés, qui peuvent entraîner par exemple la corruption de la plate-forme, voire son eondrement. Dans une telle éventualité, la plate-forme de signalisation ne pourrait plus remplir son rôle, et des appels pourraient être perdus. Il est donc indispensable de se pencher sur les besoins de telles plates-formes, an de leur assurer une exécution correcte. Dans le but de bien comprendre les enjeux liés à la programmation de services de Téléphonie sur IP, nous nous 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 des ré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ètement dépassés par la simplicité de SIP et l'ampleur de son déploiement. 2 Le General Packet Radio Service ou GPRS est une norme pour la téléphonie mobile dérivée du GSM (Global System for Mobile Communications), permettant un débit de données plus élevé. Il est également appelé 2,5G. 3 L'Universal Mobile Telecommunications System ou UMTS est l'une des technologies de téléphonie mobile de troisième génération (3G).

53 L'environnement SIP Les principes du protocole SIP Standardisé par l'ietf 4 et adopté par l'itu 5, SIP [RSC + 02] est un protocole pour la création, la modication et la terminaison de sessions avec un ou plusieurs participants. Ces sessions incluent les appels téléphoniques sur Internet ou encore les conférences multimédia. SIP gère la totalité des phases d'une communication multimédia : la localisation, l'analyse du prol des interlocuteurs, la négociation du média vis-à-vis des capacités des intervenants, l'établissement et la gestion de la session. En revanche, il ne se 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 similitudes avec le protocole HTTP 6, comme le codage ASCII des messages ou encore les codes de réponse. Un environnement SIP est principalement constitué de trois types d'entités : le serveur d'enregistrement (registrar server), le serveur dit mandataire ou proxy (proxy server) et des agents utilisateurs (user agents). Le serveur d'enregistrement permet à un utilisateur de spécier sa localisation courante. Il ne gère que les requêtes d'enregistrement (méthode REGISTER du protocole SIP), envoyées par les clients pour signaler 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). Il distribue les messages SIP à leurs destinataires en interrogeant le serveur d'enregistrement. Une plate-forme SIP est essentiellement constituée d'un serveur d'enregistrement et d'un proxy SIP an de gérer les diérents messages provenant ou à destination des utilisateurs d'un domaine donné. Des serveurs proxy additionnels peuvent être ajoutés à l'architecture. Enn, l'agent utilisateur représente un périphérique de l'utilisateur (logiciel ou matériel), c'est-à-dire un téléphone, un ordinateur ou un assistant personnel. Il eectue les actions autorisées par le protocole SIP an d'établir, modier ou terminer une session multimédia. SIP supporte la mobilité des utilisateurs en fournissant à un utilisateur une adresse, appelée SIP URI (Uniform Resource Identier), qui peut être associée à plusieurs équipements de communication. Elle possède une forme similaire à celle d'une adresse de messagerie électronique, contenant un nom d'utilisateur et un nom d'hôte. La gure 4.1 résume sous une représentation simpliée l'architecture SIP décrite ici. Pour aller plus loin dans l'explication d'une plate-forme SIP, nous nous proposons, dans la section suivante, de présenter les principales étapes à réaliser lorsqu'un utilisateur désire passer un appel SIP par l'exemple An d'illustrer la mise en relation entre deux interlocuteurs, nous allons nous placer dans le cadre décrit par la gure 4.1, illustrant un appel téléphonique entre Bob et Alice. Pour passer un appel, un utilisateur, ici Bob, doit initier une session. Pour 4 L'Internet Engineering Task Force ou IETF est un groupe informel, international et ouvert à tout individu, qui participe à l'élaboration de standards pour Internet. 5 L'International Telecommunication Union ou ITU est une organisation internationale, chargée de la réglementation et de la planication des télécommunications dans le monde. 6 Le HyperText Transfer Protocol ou HTTP est un protocole de communication client-serveur développé pour le Web.

54 44 Étude de cas : la Téléphonie sur IP Agent utilisateur Serveur proxy labri.fr Alice sip:alice@labri.fr Serveur d enregistrement labri.fr Réseau Bob sip:bob@inria.fr Agent utilisateur Serveur proxy inria.fr Serveur d enregistrement inria.fr Fig. 4.1 Architecture SIP cela, il émet une requête incluant sa position actuelle et l'adresse de l'appelée, Alice (sip:alice@labri.fr). Cette requête (méthode INVITE du protocole SIP) demande au serveur d'établir une session entre Bob et Alice. De la même manière qu'un message de courrier é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, an de la localiser, et lui envoie la requête sur son téléphone courant. À la réception du message, 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 de la réponse par Bob (méthode ACK), la communication est établie. Si l'un des participants décide de terminer la conversation, il raccroche le téléphone et une requête de terminaison 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'étendre le comportement décrit ici, en programmant la logique de routage des appels. Cette programmation 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 modier la priorité de certains appels, ou encore de rediriger les communications 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.

55 Les enjeux de la création de services 45 Ces services agissent sur la logique de routage des appels et peuvent modier le comportement de la plate-forme en fonction de ressources du réseau informatique comme les ressources Web, les bases de données ou les agendas. Une gamme si étendue de fonctionnalités permet à la téléphonie d'être personnalisée en fonction des préférences, des attentes 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 soit activé pour Alice, autorisant seulement ses clients à la joindre pendant ses heures de travail. Lorsqu'un appel de Bob est reçu par le proxy d'alice, ce dernier invoque le serveur d'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'alice ne sonne. Si Bob est un client, le service demande alors à la plate-forme SIP de contacter Alice. Si elle est déjà en communication, le service pourrait également rediriger l'appel sur sa boîte vocale. An de spécier sa propre logique de routage d'appels au sein de la plate-forme, il existe de multiples interfaces de programmation permettant à un programmeur quelconque d'accéder à un ensemble plus ou moins restreint de ressources. Cependant, une communication téléphonique est une application temps réel, ce qui impose de nombreuses contraintes non présentes dans les applications traditionnelles telles que le transfert de chiers (FTP) ou le Web. La création de services ne peut donc se faire aux dépens de 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 de téléphonie accessible à un large éventail de programmeurs. Toutefois, les plates-formes devenant programmables par des développeurs plus ou moins inexpérimentés, elles deviennent moins ables. En eet, le développement de nouveaux services de téléphonie expose l'environnement à un risque croissant d'erreurs logicielles. Ce manque de abilité 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 conance à leur système téléphonique. À travers cette contradiction, il apparaît donc clair que le succès de la programmation de la Téléphonie sur IP dépend de façon critique de la abilité des services. An de répondre à ce besoin de sécurité, il convient à la fois de s'intéresser à la personne qui programme mais aussi aux propriétés que le service doit assurer vis-à-vis de l'environnement d'exécution. Le programmeur. Un enjeu important de la programmation de services de Téléphonie sur IP consiste à bien dénir la communauté des programmeurs. En particulier, le déploiement de services par des utilisateurs n'ayant aucune compétence en télécommunications n'a pas les mêmes répercussions que dans le cas d'un programmeur expert du domaine. Un compromis doit donc être fait entre les possibilités oertes aux programmeurs et leurs niveaux de compétences, an de pouvoir assurer la abilité des

56 46 Étude de cas : la Téléphonie sur IP plates-formes de téléphonie. Tout dépend du niveau de conance de l'utilisateur. En eet, un environnement complètement ouvert nécessite une expertise étendue dans de nombreux domaines, comme les télécommunications, le protocole SIP et ses protocoles annexes, en programmation distribuée, réseaux, ou encore dans les interfaces de programmation SIP. Cette situation n'est donc absolument pas adaptée à des développeurs débutants. Plus les possibilités oertes par le service sont nombreuses et plus le risque d'erreurs logicielles augmente, ainsi que la possibilité pour un programme d'accomplir des actions malicieuses. Pour les utilisateurs novices, l'accès aux ressources doit être restreint, et le service doit être lisible et facile à concevoir. En ce qui concerne les experts du domaine, l'environnement doit être plus exible. L'enjeu consiste donc ici à fournir un 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'environnement d'exécution. Sans cette garantie, l'exécution d'un service peut corrompre le comportement de la plate-forme de téléphonie. Ces propriétés ont été identiées par Rosenberg et al. [RLS99], dans un cahier des charges des solutions de programmation de services de Téléphonie sur IP. L'une d'entre elles concerne le caractère vériable du service et consiste à 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 oerte aux utilisateurs, cette propriété peut rapidement devenir complexe à vérier. Les sources du problème peuvent être nombreuses et survenir à des niveaux complètement diérents. Cela peut concerner le domaine de la téléphonie (e.g., tout appel doit aboutir à une opération de signalisation), le protocole de signalisation SIP (e.g., la vérication des séquences autorisées de requêtes/réponses), la plate-forme de signalisation SIP (e.g., la détection de conits dans les traitements d'appels), ou encore le service de téléphonie lui-même (e.g., présence de code mort dans le 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 eet, l'utilisation de certaines constructions, comme la notion d'itération arbitraire, rend ce problème non-décidable. De même, l'utilisation d'une ressource doit nécessairement être bornée an de ne pas faire attendre trop longtemps le correspondant et assurer qu'un téléphone va sonner. Ainsi, la vérication des propriétés du domaine est principalement liée à trois facteurs : l'accès aux ressources disponibles depuis le service, les détails des informations du protocole fournis au 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 programmer ses propres services, qu'ils soient experts en télécommunications ou non. Il s'agit alors d'adapter l'environnement de programmation aux compétences de l'utilisateur, tout en assurant les propriétés métiers du domaine.

57 État de l'art des solutions existantes État de l'art des solutions existantes Il existe diérentes solutions de programmation de plates-formes de téléphonie. Ces solutions présentent des approches diérentes du problème, allant de l'interface de programmation restreinte, à l'utilisation d'un langage généraliste. Cette section présente un aperçu de ces solutions et détermine dans quelles mesures elles répondent aux attentes exprimées dans la section 4.3. CPL. Le langage CPL (Call Processing Language) [Len04, LS00] est un dialecte XML qui vise les non-programmeurs. Limité dans son expressivité an de contraindre les utilisateurs, CPL est un langage de programmation sûr, cachant toute complexité au programmeur. Un scénario CPL est représenté sous la forme d'un arbre de décisions statique, dont les n uds spécient des actions ou des décisions à prendre. Le langage CPL est issu des travaux de recherche de Henning Schulzrinne, à l'origine du protocole SIP. Du fait de sa simplicité, ce langage reçoit un grand écho industriel. Il est, entre autres, nativement implémenté dans la plate-forme Vocal de Vovida [DJK02] et est supporté par la quasi-totalité des plates-formes existantes. Néanmoins, CPL ore très peu de fonctionnalités ce qui limite fortement son utilisation pratique. De plus, son haut niveau d'abstraction rend le langage très dicile à faire évoluer, du fait d'un besoin de génération important de code. Enn, aucune vérication sémantique n'est faite au niveau du service. Seules des vérications syntaxiques sont réalisées. Il est par exemple tout à fait possible d'écrire du code qui ne s'exécutera jamais, à cause d'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 abstraite du 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:boss@example.com" (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 de vue 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 inconsistance au niveau des décisions sur les adresses. En eet, le test du n ud 2 inclut celui du n ud 5. La séquence ne peut donc jamais se produire. En programmation, cette situation correspond à du code mort puisque le service contient un chemin d'exécution infaisable. De la même manière, il est tout à fait possible d'introduire de l'inconsistance avec des tests concernant des dates ou des périodes. SER. SIP Express Router (SER) [Kut03] est un langage dont la syntaxe se rapproche de celle du C et qui vise à congurer statiquement les serveurs d'applications. Il permet une manipulation bas niveau des messages SIP. Il est reconnu pour ses performances, obtenues grâce à des analyses ecaces de messages et une faible consommation de ressources. Le langage est également extensible. Pour cela, il possède une primitive de chargement de modules et donc une ouverture sur de nouvelles fonctionnalités. Il en existe de nombreux, pour le support de MySQL, de scénarios CPL ou encore pour

58 48 Étude de cas : la Téléphonie sur IP <?xml version="1.0" encoding="utf-8"?> <cpl> <incoming> <address-switch field="origin"> <address contains="boss"> <location url="sip:bob@phone.example.com"> <proxy /> </location> </address> <otherwise> <...> <address-switch field="origin"> <address is="sip:boss@example.com"> <location url="tel: "> <proxy /> </location> </address> <otherwise> <reject /> </otherwise> </address-switch> </otherwise> </address-switch> </incoming> </cpl> 3 Appel entrant L adresse de l appelant contient-elle "boss"? oui Redirection de l appel sur le téléphone de Bob non... L adresse de l appelant est-elle "sip:boss@example.com"? oui Redirection de l appel sur le téléphone mobile de Bob 1 2 non Rejet de l appel Fig. 4.2 Service de téléphonie écrit en CPL utiliser un serveur d'authentication de type RADIUS. Néanmoins, les vérications effectuées restent très sommaires et ne garantissent pas la sûreté d'un service. De plus, elles sont rendues diciles voire impossibles dans le cas d'utilisation des modules écrits en C. Le langage vise nécessairement des experts en télécommunications et en protocole SIP. En eet, il permet de modier directement les messages SIP et par exemple de réécrire les champs d'un message. Une modication erronée d'un champ SIP peut par exemple entraîner une perte d'appels. De plus, le langage manipule des notions avancées de programmation et de réseau, comme la taille des mémoires tampons lors de la comparaison de messages, la conguration du protocole de transport de la voix, la gestion de 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 Microsoft, Live Communications Server [Mic04], orienté vers la messagerie instantanée. La programmabilité de cette plate-forme permet de décrire tout le spectre des possibilités de programmation de services : de la journalisation d'évènements (logging) au routage personnalisé d'appels. Pour cela, l'environnement utilise deux niveaux de programmation. Une première partie, l'application Manifest, spécie principalement quelles méthodes le service va traiter et comment router les messages. Tous les messages capturés seront ensuite traités par un langage à script, le Microsoft SIP Processing Language (MSPL). Ce langage est couplé à une interface de programmation (API) haut niveau, qui permet de simplier 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 possible de déléguer le traitement des messages à un programme écrit en C# pur. Ce niveau permet de faire tous les traitements possibles sur le message. La solution proposée pour

59 État de l'art des solutions existantes 49 programmer les services est très prometteuse mais son implémentation présente encore des défauts. De plus, elle est complètement intégrée au framework Microsoft et la programmation reste donc limitée aux possibilités de cet environnement (authentication, dépendance d'applications, etc.). Enn, l'ouverture de la programmation aux experts via le langage C# se fait aux dépens de la vérication. Par exemple, l'accès à des boucles non contrôlées (comme while, ou for) dans C# n'assure plus la terminaison du service ni même une consommation limitée des ressources de la plate-forme (processus, temps CPU, etc.). JAIN SIP et les solutions Java. La communauté Java propose plusieurs solutions 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. Une autre possibilité consiste à se tourner vers le framework JAIN SIP [Sun05, DRM04], qui ore 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 sur la même API de programmation, qui demeure complexe et nécessite un processus d'apprentissage laborieux. Elle est, par exemple, constituée de 130 classes et plus de 3000 méthodes, nécessitant des compétences en réseau, en téléphonie ou encore en multimédia. De plus, an de faciliter la réutilisation des méthodes, ces dernières sont rendues génériques, ce qui implique parfois un grand nombre de paramètres dont le programmeur 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 plateforme, rendant dicile toute évolution du service et tout débogage. Enn, d'un point de vue du domaine de la téléphonie, certaines opérations élémentaires peuvent nécessiter de nombreuses étapes. Par exemple, appeler un correspondant requière plus de 10 lignes de code et 15 appels de méthodes. Un dernier problème concerne l'évolution des interfaces de programmation et la nécessité de garder à jour l'application vis-à-vis des derniers changements. Tout ceci complexie considérablement la vérication des propriétés du domaine. Par exemple, rien n'est fait an de vérier que les étapes intermédiaires d'une redirection d'appel sont correctes. Les solutions de création de services de Téléphonie sur IP sont nombreuses, et les plates-formes de programmation sont en pleine émergence. Néanmoins, cette programmation se fait bien souvent aux dépens des règles métiers du domaine (section 4.3), ce qui nécessite de la part des programmeurs d'importantes connaissances dans de nombreux domaines, que ce soit en télécommunications, réseau, ou même en programmation. Les plates-formes de signalisation existantes reposent toutes sur des paradigmes de programmation particuliers. Ainsi, un service écrit pour une plate-forme ne peut pas être réutilisé dans un autre environnement. Ce portage nécessite la réécriture complète du service an de correspondre à la nouvelle cible. De plus, comme le montre l'étude comparative que nous avons réalisée [BCC + 04], ces solutions ne fournissent pas un environnement de développement able, permettant à des programmeurs ayant des compétences diverses de créer des services. Ainsi, aucune de ces approches ne semble réellement être le bon outil, orant les bons concepts, les bonnes abstractions et les

60 50 Étude de cas : la Téléphonie sur IP vérications 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, la Téléphonie sur IP a totalement levé ce verrou. Le protocole SIP représente aujourd'hui le socle de cette révolution, couplant informatique et téléphonie, et orant de nouveaux services aux utilisateurs. En eet, la convergence des télécommunications et des ré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 des développeurs non-informaticiens à concevoir des services. Pour aggraver la situation, les techniques 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 programmation. Elles n'orent également que très peu d'abstractions du domaine. Ces limitations font de la programmation de services de téléphonie un processus sujet à erreurs, pouvant corrompre la abilité des plates-formes téléphoniques.

61 Chapitre 5 Bilan Ce chapitre présente le bilan du contexte scientique de cette thèse. Après avoir résumé les enjeux liés à la diversité des programmeurs, il expose les problématiques soulevées par l'accès à la programmation à des développeurs non-informaticiens. Il souligne également l'inadéquation des approches logicielles actuelles pour le développement de 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, des médecins, des physiciens, des comptables. Ce sont également des assistants, des enseignants, des réceptionnistes. Ce ne sont plus seulement des experts en programmation. Ces nouveaux développeurs utilisent des outils de programmation haut niveau an de les aider dans leurs métiers. Selon une étude récente réalisée par des chercheurs de l'université de Carnegie Mellon [SSM05a], le nombre de développeurs américains noninformaticiens était évalué à près de 55 millions en 2005 contre seulement 3 millions de programmeurs professionnels. De plus, les estimations [SSM05b] montrent qu'en 2012, ce chire devrait dépasser les 90 millions, alors que le nombre de programmeurs professionnels ne devrait, quant à lui, pas évoluer. Ainsi, la majorité des programmes n'est plus aujourd'hui écrite par des informaticiens professionnels. Cependant, à y regarder de plus près, une dichotomie stricte des utilisateurs, entre développeurs non-informaticiens et programmeurs professionnels, n'est pas pour autant exacte et signicative. En eet, il semble plus judicieux de considérer un éventail plus large de comportements des utilisateurs, car tous ne programment pas de la même manière. Selon l'étude présentée précédemment, 60% des développeurs non-informaticiens manipulent des feuilles de calcul ou des bases de données dans leurs métiers de tous les jours. Toutefois, au sein même de ce type de programmation, les utilisateurs démontrent une certaine diversité. Par exemple, selon l'étude de Fisher et al. [FR05], sur 4498 feuilles de calcul seules 44% contiennent des formules de calcul (e.g., moyenne de nombres, écarttype ou encore valeur médiane). De même, selon l'étude de Hall [Hal96], sur 106 feuilles de calcul créées par des employés australiens ayant des connaissances en informatique, 51

62 52 Bilan 47% utilisent des fonctions de type "if", alors que seulement 21% manipulent des liens avec des bases de données. Toutes ces observations montrent bien que les développeurs n'appréhendent pas la programmation des feuilles de calcul de manière identique, mais davantage selon leurs propres besoins. À ce jour, le domaine des feuilles de calcul est l'environnement de programmation pour les développeurs non-informaticiens à avoir été le plus souvent étudié par les chercheurs. Cependant, il est tout à fait envisageable que l'é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 prols 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'organisation est un premier critère discriminant. Toutefois, à cela s'ajoute, entre autres, le niveau de compétence dans le domaine ou encore l'expertise en programmation. Cette multiplicité de critères entraîne une variation des prols de développeurs et donc une diversité des besoins en programmation au sein d'un même domaine d'application. Cette hétérogénéité des besoins se retrouve au niveau fonctionnel (e.g., en termes d'expressivité ou de fonctionnalités oertes) mais également non-fonctionnel (e.g., en termes de abilité, de portabilité, voire de préférences au niveau de l'interface de programmation). La diversité des prols dépend également du domaine d'application ainsi que du contexte d'utilisation des développeurs. Ces diérences n'apparaissaient pas il y a quelques années dans la mesure où les solutions de programmation étaient seulement dédiées à des programmeurs expérimentés. Il semble donc dicile d'utiliser seulement les compétences ou l'expertise comme critères pour caractériser les besoins des développeurs et leur concevoir des solutions sur mesure. Cependant, c'est le fait de monter en abstraction qui a diversié les populations de programmeurs. Donc, plutôt que de s'intéresser à analyser les populations de programmeurs, il paraît plus approprié de se tourner vers une caractérisation du niveau d'abstraction des besoins des développeurs et des tâches à accomplir. En eet, certaines tâches demandent davantage d'expressivité, de compétence (e.g., la programmation d'une plate-forme de téléphonie), alors que d'autres peuvent se faire à un haut niveau d'abstraction (e.g., la conguration d'un service de téléphonie existant). De plus, le niveau d'expertise du programmeur n'inue pas directement sur le choix d'une solution de programmation. En eet, si la tâche à réaliser peut se faire facilement avec un outil de programmation haut niveau, un programmeur même professionnel préférera utiliser le moyen le plus simple plutôt que de se compliquer l'existence avec un outil plus expressif mais également souvent plus complexe. Il apparaît donc intéressant d'étudier la diversité des utilisateurs selon la nature plus ou moins haut niveau des besoins qu'ils expriment. Une catégorisation simple de ces besoins émerge depuis quelques années, reétant l'émergence des approches présentées dans les chapitres 2 et 3. Cette classication repose sur une dichotomie entre des besoins en programmation et des besoins en modélisation. La diversité des programmeurs entraîne une multiplicité des besoins en termes de solutions de développement logiciel. Ces solutions se distinguent fondamentalement par leur niveau d'abstraction et leur approche du problème d'un point de vue programmation ou modélisation. Quoi qu'il en soit, ces solutions partagent bien souvent une grande

63 Problématiques 53 partie de la connaissance du domaine mais aussi une part importante de l'implémentation (section 3.2.3). L'enjeu consiste donc à réconcilier ces approches (programmation et modélisation), mais également à factoriser, capitaliser et automatiser le plus possible les étapes de conception, an de simplier le développement de nouvelles solutions. 5.2 Problématiques L'ouverture de la programmation à des non-informaticiens complexie le développement de solutions logicielles, du fait du fossé grandissant entre le domaine d'utilisation et l'implémentation. De plus, en élevant le niveau d'abstraction des solutions, la population 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 expertise dans le domaine). Cette diversité doit également être prise en compte au niveau du développement des solutions an de diminuer le temps de conception et d'augmenter la productivité. Enn, 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 compétences. L'enjeu consiste donc à leur orir des solutions de programmation adaptées à leurs compétences, an de programmer au niveau de leurs domaines (de l'espace de problèmes), et non plus dans des technologies informatiques (au niveau de l'espace de solutions). De plus, ouvrir la programmation à ces développeurs débutants consiste non seulement à élever le niveau d'abstraction des solutions de programmation, mais aussi à assurer la abilité des propriétés critiques du domaine d'application. Comme le montre la section 2.3, la complexité des technologies existantes et des procédés de développement rend dicile la vérication de ces propriétés, à cause entre autres, d'un entrelacement entre la logique du programme et son implémentation. Nous avons illustré ce point dans le domaine de la création de services de Téléphonie sur IP (chapitre 4). La programmation de ces services nécessite des compétences dans de nombreux domaines comme les télécommunications, les protocoles pour le multimédia, ou encore les systèmes distribués. Or, les solutions de programmation de plates-formes de téléphonie sont souvent généralistes et complexes, ne permettant pas à des utilisateurs novices de programmer (section 4.4). En eet, cette inadéquation des solutions à ce type d'utilisateur augmente le risque d'erreurs logicielles et donc de services erronés, empêchant d'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énierie Dirigée par les Modèles (chapitre 2) et langages dédiés (chapitre 3), ne permettent pas de développer de manière simple et performante de telles solutions de programmation. Nous avons montré les limites de la modélisation, de par son approche généraliste du problème (section 2.3.1), mais aussi à cause de son manque de sémantique (section 2.3.2) nécessaire à la génération d'une implémentation correcte et ecace. Les langages

64 54 Bilan dédiés semblent, quant à eux, plus à même de réduire le fossé entre le niveau d'abstraction et l'implémentation. De plus, du fait d'une expressivité restreinte et d'une sémantique précise, les DSL facilitent l'analyse de programmes, la vérication de propriétés et la production logicielle (section 3.2). Cependant, comme le montre la section 3.4, la conception et l'implémentation de tels langages restent encore diciles. De plus, cette solution n'ore 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 souvent leurs approches sur le domaine d'application (section 3.3.1), ou encore la plateforme d'exécution (section 2.2.1). La notion d'utilisateur est alors trop souvent délaissée. Or, il existe aujourd'hui une variété de programmeurs potentiels dans un même domaine. 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 diversité 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 par des prols complètement diérents, allant du simple utilisateur à l'administrateur d'un PABX 1, en passant par l'opérateur téléphonique. Cette diversité de prols entraîne un besoin de solutions de programmation diérentes. Rendre accessible la programmation à des non-informaticiens pose un certain nombre de problèmes, notamment relatifs au domaine et à ses propriétés, à la complexité du développement de solutions adaptées, et aux multiples prols des programmeurs dans le domaine à prendre en compte. Il apparaît donc évident qu'une architecture répondant à toutes ces contraintes et permettant de développer simplement des solutions de programmation haut niveau est d'un réel intérêt. La partie II de ce document présente notre approche pour y parvenir. 1 Un 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.

65 Deuxième partie Approche proposée 55

66

67 Chapitre 6 Présentation de l'approche Le domaine de la programmation est aujourd'hui en pleine mutation. Face aux experts en programmation, langages et autres technologies, se dresse un nouveau type de développeur, monsieur tout-le-monde. De plus en plus de programmes sont écrits par des novices, désireux d'utiliser la programmation comme un outil qui pourrait les aider dans leurs métiers. Permettre de programmer sans être programmeur, voilà l'un des dés importants du génie logiciel. Néanmoins, à l'autre extrémité du spectre, les programmeurs expérimentés ne peuvent, quant à eux, se contenter de solutions restreintes. Leur activité requiert bien souvent une solution expressive, sans pour autant tomber dans une approche généraliste. Les travaux présentés dans cette thèse visent à rendre la programmation plus accessible à ces nouveaux développeurs, tout en répondant à la diversité des besoins en programmation due à de multiples prols de programmeurs au sein d'un même domaine d'application. Il s'agit également de faciliter le développement des solutions logicielles haut niveau. Ce chapitre présente la vision globale de l'approche que nous proposons an de répondre aux problèmes suscités par cette nouvelle demande et énoncés dans le chapitre précédent. 6.1 L'approche proposée L'approche proposée dans cette thèse [LCM07] repose sur l'utilisation de langages dédiés et sur une architecture en couches des langages, illustrée par la gure 6.1. Notre approche en couches consiste à introduire deux niveaux de langages dédiés : un langage dédié orienté modélisation (Domain-Specic Modeling Language ou DSML) et un langage dédié orienté programmation (Domain-Specic Programming Language ou DSPL 1 ). Cette dichotomie des DSL s'appuie sur la caractérisation des besoins des développeurs énoncée au chapitre précédent. Ces langages évoluent à des niveaux d'abstraction 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é 1 Dans ce document, nous utiliserons de manière indiérente le terme langage dédié orienté programmation et DSPL. 57

68 58 Présentation de l'approche de plus bas niveau (DSPL), plus expressif que le DSML et plus à même de résoudre des familles de problèmes complexes. Le DSPL est ensuite compilé dans une implémentation particulière. DSML Vérifications DOMAINE Compilation Modélisation Programmation DSPL Vérifications Compilation Programmation Implémentation Implémentation 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 signicativement le fossé entre des modèles et leurs implémentations. En utilisant le DSPL comme une interface entre ces deux mondes, le processus de développement de solutions haut niveau se trouve fortement simplié. De plus, cette architecture introduit au sein du domaine une distinction des approches entre la modélisation et la programmation de solutions. Cette séparation permet de mettre à disposition de tous les types d'utilisateurs 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 produire une variété importante d'applications plus ou moins complexes. Le DSPL peut également être caché de l'ensemble des développeurs et ne servir simplement que de langage intermédiaire lors de la génération de code. Cette utilisation diérente du DSPL dépend du domaine d'application, des prols 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érication de propriétés (gure 6.1). Tout d'abord, elle permet de simplier le processus de compilation en réduisant la distance entre le modèle et son implémentation (réduction du pas de compilation). L'approche permet, en eet, à un DSML de se concentrer uniquement sur la logique du programme et de reposer sur un DSPL existant, qui lui, expose les constructions clés et les opérations utiles lors d'une implémentation. Ainsi, la compilation du DSML

69 L'approche proposée 59 est seulement dédiée à la projection de la logique de l'application dans les termes du DSPL. La compilation du DSPL est, quant à elle, dédiée à la génération des détails d'implémentation. Cette stratégie est similaire à celle utilisée pour la compilation de langages de haut niveau comme les langages fonctionnels (e.g., [DF98]). Cette même stratégie est utilisée en génie logiciel ; elle permet de structurer un système complexe en couches logicielles (e.g., [GS96]). La distinction entre la modélisation et la programmation permet également d'étager la vérication de propriétés. Les propriétés liées au domaine (e.g., interaction de comportements entre plusieurs services) sont vériées au niveau du DSML alors que celles liées à la programmation (e.g., contrôle de la consommation de ressources dans une itération non bornée) le sont au niveau du DSPL. Ainsi, la spécialisation de chaque couche permet de simplier le processus de vérication. Enn, de par la nature du DSML mais aussi la présence du DSPL intermédiaire, les processus de compilation et de vérication du langage de modélisation deviennent eux-aussi haut niveau. Il est alors plus facile de réutiliser des outils de génération de programmes, ce qui facilite le développement, mais aussi l'évolutivité du DSML. Reste le problème de l'implémentation du DSPL. An de réduire son coût, l'approche propose également une méthodologie permettant de simplier le processus de compilation du langage. 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 son débogage. L'utilisation du langage dédié de programmation comme pivot de notre architecture nous permet de gérer la variabilité des solutions haut niveau oertes aux développeurs. En eet, le DSPL permet de réutiliser une partie importante de la connaissance du domaine mais aussi de l'implémentation. Ainsi, il expose des constructions clés qui abstraient les variations des plates-formes sous-jacentes, facilitant le développement de langages de modélisation. Parce qu'il est dédié au domaine, un DSPL ore également des 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émenté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é de DSML peut être envisagée, orant divers paradigmes (textuels ou visuels), degrés d'expressivité ou encore abstractions. De même, l'utilisation du DSPL comme point central de notre architecture permet de fournir simplement plusieurs implémentations possibles pour un même DSML. Ce langage étant orienté programmation, un programme écrit dans un DSPL contient les détails nécessaires à la génération automatique de son implémentation dans un environnement d'exécution. Ainsi, l'architecture proposée permet de factoriser, capitaliser et automatiser les étapes de conception, an de simplier le développement et l'évolution de solutions logicielles. L'approche proposée répond à l'ensemble des problématiques énoncées dans ce document. Elle est principalement basée sur la dichotomie entre les langages dédiés de

70 60 Présentation de l'approche programmation et de modélisation. Si cette dichotomie reète bien la diversité des besoins des utilisateurs, il n'existe cependant pas aujourd'hui de moyen permettant de caractériser cette diérence. Toutefois, l'étude de l'existant nous montre que cette dichotomie est bien présente. 6.2 Une dichotomie bien réelle La distinction entre les langages de programmation et de modélisation est aujourd'hui davantage un constat qu'un principe tel qu'énoncé précédemment. La limite entre les deux mondes n'est pas simple à entrevoir et reste souvent subjective. Pourtant, l'état de l'art sur cette question conrme cette diérence avérée (e.g., [Coo04]). Ainsi, cette dichotomie des solutions se retrouvent à la fois au sein de la communauté des langages et 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 ore des notations et des abstractions qui sont spéciques à un domaine donné. Cependant, selon le domaine, un DSL peut ou non être orienté programmation. Beaucoup de DSL développés par des chercheurs en langages de programmation nécessitent des compétences en programmation. Les exemples incluent PADS, un langage pour le traitement de donné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 nombreux autres domaines que l'informatique. Ils sont généralement centrés sur l'utilisateur et la modélisation de solutions, nécessitant des connaissances dans le domaine, mais pas d'expertise en programmation. Des exemples de tels langages incluent Risla, un langage pour la description de produits nanciers [ADR95], ou encore CML, un langage de gestion d'informations moléculaires en chimie [MR97]. Cette séparation entre programmation 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 de toutes les approches IDM [GTK + 06]. Le fait d'avoir introduit la notion de modélisation au niveau de ces langages dédiés particuliers montre bien le désir de se diérencier de l'approche DSL. Ainsi, un grand nombre de langages de modélisation apparaît dans la littérature, parmi lesquels SysML (Systems Modeling Language) [Sys05], WebML (Web Modeling 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élisation ou de programmation. De plus, un manque de clarté autour de ces deux termes a nourri pendant les dernières années un certain nombre d'idées fausses. Ainsi, consensuellement, tous les langages de programmation doivent être textuels, et par conséquent les langages de modélisation doivent être graphiques. Mais ce critère de diérenciation est superciel. Si les langages de programmation sont générallement représentés selon une notation textuelle, cela est en grande partie dû à des raisons historiques. Des exemples de langages de programmation graphiques existent. L'un des plus connus est le langage Lego Mindstorms, un produit utilisé pour construire les robots [CE00]. Il dénit des élé-

71 Une dichotomie bien réelle 61 ments graphiques an de réaliser des opérations arithmétiques, mais aussi de créer des structures 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 textuel n'est pas forcément un langage de programmation. XML est un langage textuel bien connu, par exemple, et peu de personnes le considèrent aujourd'hui comme un langage de programmation. De manière similaire, parce que la plupart des langages de modélisation ont historiquement utilisés une notation graphique, il est souvent supposé, que les langages de modélisation doivent être graphiques. De plus, les langages de modélisation graphiques ont souvent été utilisés pour la documentation et certaines tentatives ont échoué à générer automatiquement du code. Cet héritage a créé une idée fausse selon laquelle les langages de modélisation graphiques ne sont pas un moyen ecace de programmation. Cependant, ce type de langages peut utiliser une grande variété de notations et, dans certains contextes, ils se trouvent être de bons moyens de génération de code [TK05]. La littérature fait état aujourd'hui d'une diérence entre les langages de programmation et les langages de modélisation, sans toutefois clairement l'identier ni même la caractériser. Ainsi, la frontière entre la modélisation et la programmation de solutions est seulement une aaire de niveau d'abstraction. Les langages dédiés de modélisation (DSML) sont simplement des DSL de plus haut niveau que les langages dédiés de programmation (DSPL). C'est dans ce sens que nous interprétons ces concepts et que nous les utilisons dans la suite de ce document. Si cette interprétation peut paraître subjective, l'étude de divers domaines d'application (e.g., création d'interfaces graphiques, description de matériel, ou encore ltrage de courrier électronique) montre que 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 des langages dédiés de programmation et des langages dédiés de plus haut niveau, orant des niveaux d'abstraction plus proches de la pensée des développeurs. Par exemple, le domaine du ltrage de courrier électronique expose des solutions de programmation ayant des niveaux d'abstractions diérents. Les programmeurs expérimentés peuvent utiliser 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, notion de typage). Pour les développeurs non-informaticiens, des langages à la fois textuels et graphiques, respectivement AvelSieve ou Ingo, permettent de simplement exprimer ses besoins, sans connaissance particulière en programmation. Ainsi, de la même manière que nous le faisons dans ce document pour le domaine de la création de services de Téléphonie sur IP, il serait tout à fait possible d'appliquer notre approche à tous ces domaines 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'architecture que nous venons d'introduire. Pour cela, le chapitre 7 revisite le domaine de la création de 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. Les chapitres suivants exposent les bénéces de l'introduction de notre DSPL (SPL) à la fois d'un point de vue du domaine et d'un point de vue de l'implémentation. D'une

72 62 Présentation de l'approche Domaine Création d interfaces graphiques Description de matériel Filtrage de courrier électronique Modélisation de la réalité virtuelle Modélisation de processus métier Langage Dédié de Programmation - DSPL SWUL (SWing User interface Language) VHDL (Very high speed integrated circuit Hardware Description Language) Sieve VRML (Virtual Reality Markup Language) BPEL (Business Process Execution Language) Langages Dédiés de Modélisation - DSMLs CookSwing, SwiX ML, SwingML, JellySwing TDML (Timing Diagrams Editor and Analysis), LogSim, Matlab Mulberry, Ingo, AvelSieve, SmartSieve, WebSieve STEP (Scripting Language for Embodied Agents), XSTEP ActiveBPEL, WS-CDL (Web Services Choreography Description Language), BPML (Business Process Modeling Language) Tab. 6.1 Illustration de la distinction DSPL-DSML part, la nature spécique au domaine de SPL facilite grandement l'implémentation de deux DSML diérents (CPL et VisuCom), fournissant des concepts de programmation dédiés, et cachant les détails d'implémentation. D'autre part, ce DSPL est porté sur la plate-forme de téléphonie JAIN SIP ; il est en outre tout à fait envisageable de le porter sur 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 langages dédiés et présente les résultats de son application sur SPL ciblant l'environnement JAIN SIP. Le chapitre 9 évalue, quant à lui, les avantages de notre architecture en termes de facilité de compilation des DSML et de vérication de propriétés du domaine.

73 Chapitre 7 Application à la Téléphonie sur IP Ce chapitre illustre notre approche dans le domaine de la Téléphonie sur IP applicative. Il présente les résultats de notre analyse de domaine et met en avant le besoin d'une approche répondant aux principes énoncés dans les chapitres précédents. Pour cela, 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és que nous avons développés, SPL et VisuCom, an 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, symbolisé par CPL, et celui de l'implémentation, symbolisé par l'interface de programmation JAIN 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 besoin de connaissance dans de nombreux domaines, l'implémentation de services avec une solution du type JAIN SIP peut rapidement devenir un processus complexe, à la portée de peu de programmeurs. Cette section présente les résultats de notre analyse du domaine de la téléphonie et de l'étude de diverses plates-formes de programmation [BCC + 04] Une programmation trop complexe La programmation de services de Téléphonie sur IP reste aujourd'hui une tâche délicate, même pour un programmeur expérimenté. Elle requiert, en eet, de nombreuses compétences que peu d'utilisateurs possèdent. Plusieurs plates-formes de téléphonie SIP orent une interface de programmation pour le développement de services. Ces API sont basé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

74 64 Application à la Téléphonie sur IP un service via l'interface de programmation JAIN SIP, qui est aujourd'hui l'une des solutions de programmation les plus connues dans le domaine. Considérons un service simple, que nous nommerons le service Compteur, qui gère le compteur des appels ayant été transférés vers une secrétaire, lorsque l'utilisateur associé au service ne peut être joint. Ce compteur est initialisé à zéro lorsque l'utilisateur s'enregistre auprès du serveur d'enregistrement (an de lui signier sa présence), incrémenté lorsqu'un appel est transmis à la secrétaire, et enregistré lorsque l'utilisateur se déconnecte. La gure 7.1 montre les principales étapes de l'implémentation de ce service Compteur en utilisant l'interface de programmation JAIN SIP. Les blocs de code Bi sont utilisés par la suite pour expliciter le service, mais également dans la section 7.2 pour 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 gestion des réponses, et processtimeout pour la gestion des temporisations (timeouts) levées par la plate-forme de téléphonie. La structure de ces méthodes vise à spécier le comportement du service en fonction des requêtes SIP à traiter et des réponses associées. Dans notre exemple Compteur, les méthodes processrequest (ligne 11) et processresponse (ligne 47) spécient le traitement des requêtes et des réponses des méthodes REGISTER et INVITE 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 SIP REGISTER (ligne 78), correspondant au cas où le temps d'enregistrement de l'utilisateur sur la plate-forme de téléphonie a expiré. La diculté de ce service consiste à maintenir le compteur, qui doit être accessible lors du traitement de l'ensemble des messages SIP (requêtes et réponses) associés à un enregistrement particulier de l'utilisateur. En eet, l'api ne fournit pas de moyen d'associer un état à un enregistrement SIP 1. De plus, ce service peut être partagé par plusieurs utilisateurs, empêchant l'utilisation de variables globales partagées. En conséquence, le programmeur doit explicitement implémenter cette association. Ainsi, lorsque le service reçoit une requête REGISTER pour un utilisateur qui n'est pas encore enregistré (bloc B1 de la gure 7.1), il crée un objet de la classe State (bloc B0) qui représente le compteur pour cet enregistrement. Cet objet State est enregistré dans un environnement global env sous un identiant ident qui est unique pour l'enregistrement. Ensuite, lors de l'arrivée d'une requête INVITE pour un utilisateur enregistré (ligne 36-37), la méthode processrequest transfère la requête à l'utilisateur (ligne 38-39). À la réception de la ré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), indiquant que l'utilisateur n'a pas pu prendre l'appel. Le compteur associé à l'utilisateur est alors récupéré depuis l'environnement env (ligne 55-56) et incrémenté (ligne 59) avant de 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. Enn, lorsque l'utilisateur annule son enregistre- 1 Un enregistrement SIP correspond à la période pendant laquelle un utilisateur est associé à un terminal SIP, lui permettant de prendre des appels.

75 Analyse du domaine class State implements Lib.State { 2. private int count; 3. public State() {} 4. void setcounter (int x) { count = x; } B0 5. int getcounter() { return count; } 6. } 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); B1 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()); B2_1 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. } 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. } B4 67. } else { 68. rs_sipprovider.sendresponse(rs_response); 69. } 70. } else { 71. rs_sipprovider.sendresponse(rs_response); 72. } 73. [...] 74. } 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()); B2_2 82. lib.env.delenv (ident); 83. } 84. } 85. } B3 Fig. 7.1 Le service Compteur écrit en JAIN SIP

76 66 Application à la Téléphonie sur IP ment (bloc B2 1) ou que ce dernier expire (bloc B2 2), le compteur est sauvegardé et supprimé de l'environnement env. Certains traitements peuvent nécessiter de la part de la plate-forme de téléphonie de garder un état bien particulier, an de lui permettre d'associer une réponse à sa requête. La transaction 2 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, an d'améliorer les performances, les transactions du service sont sans état (e.g., ligne 31) quand cela est possible. Les transactions à état (e.g., lignes 38-39) sont cependant nécessaires lorsque, comme dans notre exemple, certaines données dénies dans le traitement de la requê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, assurant que toutes les requêtes obtiennent une réponse. Dans le cas d'un service partiellement sans état, qui ne garantit donc pas cette dernière propriété, les requêtes auxquelles le service ne répond pas sont automatiquement retransmises par l'agent utilisateur de l'appelant. De telles retransmissions ré-invoquent le service, ce qui peut avoir des répercutions sur son comportement. Le bloc B3 de notre exemple incrémente un compteur et transmet la requête à la secrétaire. Dans ce cas, même si aucun traitement n'est eectué sur le compteur par la suite, la transaction doit être à état parce que le traitement de la requête INVITE modie le compteur, et n'est donc pas idempotent. L'exemple Compteur montre clairement la diculté de développer des services même simples avec les approches existantes du type JAIN SIP. Ces approches étant basées sur un langage généraliste, il n'existe aucun support pour guider le programmeur à travers les méandres du protocole et de l'api. La séparation du service selon des points d'entrée distincts pour le traitement de requêtes et de réponses obscurcit grandement les ots de contrôle et de données à travers les diérentes transactions. Ainsi, l'api ne reète absolument pas les concepts qui existent dans la gestion des communications du protocole SIP (e.g., transaction, dialogue 3, ou encore enregistrement). Ce manque de décomposition, notamment au niveau du dialogue et de l'enregistrement, entraîne une gestion complexe de l'état. Même pour un programmeur averti, l'implémentation de services de Téléphonie sur IP est aujourd'hui une tâche dicile. Elle demande une parfaite maîtrise d'un ensemble de technologies, où le manque de garde-fous fait de chaque erreur logicielle une menace pour la plate-forme de téléphonie. Il devient donc indispensable d'élever le niveau d'abstraction des solutions de programmation. Comme dans de nombreux domaines, la téléphonie fait face à une divergence de points de vue pour répondre à ce besoin. Aux experts en téléphonie s'opposent les experts en implémentation. 2 Une transaction consiste à associer une réponse à sa requête (e.g., une requête REGISTER et sa réponse). 3 Un dialogue est une relation SIP entre deux entités agents utilisateurs qui persiste pour une certaine durée. Un dialogue est initié par une requête INVITE et conrmé par une requête ACK. Le dialogue persiste jusqu'à ce que l'une des parties envoie une requête BYE.

77 Analyse du domaine Des approches divergentes Le problème posé par la montée en abstraction est celui de la distance qui sépare la modélisation d'une solution logicielle de son implémentation. D'un point de vue implémentation, les approches sont guidées par le désir d'élever le niveau d'abstraction des technologies logicielles. D'un point de vue modélisation, les eorts visent à développer 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, une certaine incompréhension existe entre les experts des deux mondes, ce qui représente un frein au développement de services de Téléphonie sur IP tel que présenté au chapitre précédent. Cette section illustre le problème de la séparation entre conception et implémentation, justiant ainsi davantage le choix du domaine de la création de services de Téléphonie sur IP pour la mise en uvre de notre approche logicielle. Implémentation de services. L'approche implémentation est ascendante (bottomup) ; elle est similaire à la construction d'une maison, en apportant petit à petit des briques techniques qui permettent de structurer l'édice à produire. Dans le cas de la Téléphonie sur IP, cela consiste à élaborer des interfaces de programmation, ou des couches logicielles, qui abstraient les détails du protocole de signalisation (SIP dans notre contexte), ou encore de divers protocoles multimédias (e.g., le protocole de communication RTP - Real-Time Transport Protocol [Sch96]). D'autres exemples peuvent être cités. Les Servlets SIP proposent un framework qui encapsule une architecture client-serveur, nécessaire pour faire face à la nature distribuée des plates-formes de té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 permet pas de répondre à toutes les attentes. Sa complexité, sa généricité mais aussi son manque de vérications de cohérence concernant, par exemple, les étapes intermédiaires d'une redirection d'appel, rendent diciles son apprentissage et son utilisation. L'entrelacement de la logique avec des détails d'implémentation empêche également d'assurer les propriétés du domaine. De plus, cette approche reste spécique à un environnement d'exécution (Java dans le cas de JAIN SIP ou C# dans le cas de la solution de Microsoft) et tout portage de la technologie sur une autre plate-forme est inenvisageable. Enn, cette approche est uniquement destinée à un ensemble réduit de programmeurs expérimentés. Modélisation de services. À l'autre extrémité du spectre se trouve l'approche de modélisation, qui peut être vue comme descendante (top-down). Comme toute approche de ce type, elle repose sur un langage de modélisation dédié et un générateur de code spécique à 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 points faibles qui empêchent souvent son acceptation industrielle. Le principal problème d'une approche comme CPL se situe au niveau de sa spécicité, à la fois concernant la dé- nition du domaine et le type d'utilisateur visé. Une solution trop spécique limite

78 68 Application à la Téléphonie sur IP non seulement son expressivité, mais aussi son adoption et son utilisation. De plus, la nature 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 conditions d'utilisation de la solution. Ainsi, le portage sur une autre plate-forme nécessite de profonds changements au sein du générateur. Un autre problème de la démarche repose sur son niveau d'abstraction. Essayer d'élever le niveau d'abstraction d'un langage a pour eet d'augmenter la distance entre le domaine et l'implémentation, ajoutant de la complexité au générateur de code. Cette situation rend ce dernier dicile à évoluer, bloquant à la fois le langage et le générateur. À titre d'exemple, l'introduction d'un nouveau 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 Bilan Le téléphone est aujourd'hui une ressource indispensable pour tous les usagers, et représente souvent le principal lien commercial de nombreuses organisations avec leurs clients. L'introduction de la programmation au sein des plates-formes téléphoniques suscite donc de nombreuses interrogations relatives à la abilité des solutions. Ces questions ont été partiellement identiées par Lennox [Len04]. Ce dernier présente une analyse du domaine de la programmation de services de Téléphonie sur IP en se focalisant sur les problèmes liés à l'exécution des services. Ainsi, il s'intéresse à la manière d'exécuter la logique, où elle se situe (agent utilisateur ou serveur d'applications), ainsi qu'aux interactions entre le service et l'environnement. Son analyse ne tient compte ni des besoins en programmation des utilisateurs ni de l'étude des solutions existantes. Conscient du constat que l'exécution de services doit se faire de manière able et que le développement de services de Téléphonie sur IP est un processus complexe, il propose une solution de programmation restreinte, CPL. Contrairement à Lennox, notre analyse du domaine est issue de l'étude de diverses plates-formes de signalisation [BCC + 04]. Elle couvre une variété de solutions de programmation 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éveloppement 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. En eet, les services de téléphonie peuvent être programmés par des prols très diérents, allant du simple utilisateur à l'administrateur d'un PABX, en passant par l'opérateur téléphonique. Cette diversité de développeurs entraîne une multiplicité des besoins de solutions de programmation, en termes de niveau d'abstraction et d'expressivité. Cependant 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êchent aujourd'hui les approches de satisfaire l'ensemble des besoins des développeurs.

79 SPL, un langage dédié de programmation 69 Notre étude montre également que la complexité de la téléphonie rend dicile d'assurer les propriétés métiers du domaine. Ces propriétés interviennent à des niveaux diérents : (1) le domaine de la téléphonie, (2) le protocole de signalisation, (3) la plate-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érier de telles 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 inuer sur la abilité des services. Elle peut également répondre à des besoins diverses de la part des programmeurs comme le contrôle d'admission d'un service, la conguration de la plate-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 parfaitement les problématiques évoquées dans ce document. Les approches existantes de ce domaine échouent à simplier 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érentes populations de programmeurs de services. Il est nécessaire de faire un choix entre l'expressivité et la abilité. Enn, la téléphonie possède des propriétés critiques qu'il est indispensable d'assurer. Ce domaine semble donc être un très bon candidat pour illustrer notre 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 et VisuCom. 7.2 SPL, un langage dédié de programmation Cette section présente SPL (Session Processing Language) [BCL + 06a], un DSPL dont le but est de faciliter le développement de services de Téléphonie sur IP sans sacrier la abilité du service. Pour cela, SPL repose sur un environnement d'exécution de logique de service pour SIP (SIP Service Logic Execution Environment ou SIP- SLEE). Cet environnement forme une machine abstraite pour le langage. Il permet d'identier les objets et les opérations métiers du domaine d'application sur lesquels est 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 ore des abstractions haut niveau, il libère le programmeur des détails d'implémentation et de la complexité des technologies sous-jacentes. SPL garantit des propriétés critiques qui ne peuvent pas être vériées dans des langages généralistes comme Java ou C, en introduisant des concepts dédiés au domaine de la téléphonie et des restrictions sémantiques L'environnement d'exécution An de pouvoir déployer des services SPL, le serveur d'applications de la plate-forme de téléphonie est décomposé en deux composants majeurs, comme illustré à la gure 7.2 : un serveur SIP qui permet de recevoir et envoyer des messages SIP, et un environnement d'exécution SIP-SLEE qui ore au programmeur une interface haut niveau dédiée au développement de services SPL. Une contribution clé de cet environnement est l'introduction d'une notion spécique au domaine, appelée session, qui représente

80 70 Application à la Téléphonie sur IP 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 niveau correspondant aux concepts du domaine. Pour cela, il introduit des méthodes de contrôle pour lesquelles le service SPL dénit des gestionnaires (handlers), chargés de spécier la logique à appliquer pour chacune des méthodes à prendre en compte. À la réception de messages SIP et d'évènements (gure 7.2), l'environnement associe des méthodes de contrôle dont le traitement est donné par le service SPL. Ces méthodes représentent une interface SIP uniforme dédiée à la programmation de services. Service SPL méthodes de contrôle résultats SIP - SLEE évènements messages SIP messages SIP Serveur SIP 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 requêtes ranées et des évènements du serveur SIP. Une requête SIP du protocole est propagé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étation et un ranement eectués par l'environnement SIP-SLEE. À titre d'exemple, la requête INVITE est utilisée soit pour initier un dialogue, soit pour modier les caractéristiques d'un dialogue existant. Ainsi, l'environnement rane la requête INVITE soit en méthode de contrôle INVITE dans le premier cas, soit en méthode de contrôle REINVITE dans le cas où le dialogue existe déjà. Ce faisant, le problème de la distinction selon le contexte ne se pose plus au niveau de la programmation, car il est traité à l'extérieur du service au niveau du SIP-SLEE. Par convention, les méthodes de contrôle ranées et celles du protocole sont syntaxiquement notées en majuscule dans SPL. Le dernier type de méthodes de contrôle notie un service d'évènements internes à

81 SPL, un langage dédié de programmation 71 la plate-forme qui sont pertinents pour la logique du service. La méthode de contrôle unregister, 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 correspondent pas à des messages SIP. Séparation des opérations. Les API existantes de programmation sont le plus souvent le reet d'une traduction directe du protocole SIP ainsi que du paradigme de programmation mis en uvre au sein de la plate-forme de téléphonie. Toutefois, bien souvent, ces API ne prennent pas en compte certains concepts spéciques à 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, le concept de dialogue, qui correspond à un appel. Un dialogue est un l conducteur naturel 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, conrmation, modication et terminaison. Les concepts SIP de souscription à un évènement et d'enregistrement ont également ce même cycle de vie et peuvent être perçus comme des abstractions de conception. Enn, un service est déployé et associé à un utilisateur ou un groupe d'utilisateurs. Cette association permet d'introduire des comportements spéciques au niveau du service et doit 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, qui coïncide avec les phases du cycle de vie de ces abstractions. Ainsi, nous introduisons une distinction des méthodes en les classiant en méthode initiale (création), médiale (conrmation et modication), et nale (terminaison), comme résumé dans la classication des méthodes de contrôle exposée au niveau du tableau 7.1. Cette classication reprend l'ensemble des méthodes de contrôle qu'il est possible de gérer au niveau d'un service SPL. La répartition de ces méthodes permet de grandement simplier la conception de services. Concepts Service Enregistrement Dialogue Souscription Initiale deploy REGISTER INVITE SUBSCRIBE Méthodes de Contrôle Médiale REREGISTER CANCEL ACK REINVITE RESUBSCRIBE NOTIFY Finale undeploy unregister BYE uninvite unsubscribe Tab. 7.1 Classication des méthodes de contrôle

82 72 Application à la Téléphonie sur IP L'état. Jusqu'ici nos abstractions de conception concernaient seulement du code (associé 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 souscription, un enregistrement et un service. De plus, il gère cet état d'un bout à l'autre du cycle de vie associé à chacun de ces concepts. Là encore, le problème de la gestion de 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 dans un langage orienté objet et forme ce que nous appelons une session. Nous associons donc une session à chacun des concepts introduits précédemment (service, enregistrement, 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éthode mé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 de services SPL. Une session est constituée d'un ensemble de gestionnaires et d'un état. Un gestionnaire dénit un traitement pour une méthode de contrôle, que ce soit une requête du protocole (e.g., INVITE), une requête ranée (e.g., REINVITE), ou un évènement de la plate-forme (e.g., déploiement de services). Un état permet, quant à lui, de maintenir certaines données à travers plusieurs gestionnaires Le langage Le langage SPL possède des constructions et une sémantique dédiées au domaine de la Téléphonie sur IP. Il est élaboré autour des abstractions fournies par l'environnement SIP-SLEE. Cette section décrit les points forts du langage. Une syntaxe complète est disponible, ainsi que des exemples concrets de services SPL [Pho06]. Organisation hiérarchique des sessions. La syntaxe d'un service SPL reète la structure 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 une approche de développement hiérarchique de services. La gure 7.3 représente la structure 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 enregistrement (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 session souscription (event), manipulant respectivement une session SIP et un évènement SIP. Comme dans les langages orant des blocs lexicaux emboîtés de variables (dont le précurseur est le langage Algol [Mad86]), la structure d'un service SPL permet à une session de n'importe quel niveau d'avoir accès à l'ensemble des variables et des fonctions déclarées aux niveaux supérieurs. La partie droite de la gure 7.3 illustre ce point : la variable 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 de la session service.

83 SPL, un langage dédié de programmation 73 service service_name { [...] handler deploy {...} handler undeploy {...} } } registration { [...] handler REGISTER {...} handler unregister {...} dialog { [...] handler INVITE {...} handler ACK {...} handler BYE {...} } event presence { [...] handler SUBSCRIBE {...} handler NOTIFY {...} } service_var1 Service Session Registration Session registration_var1 Dialog Session dialog_var1 dialog_var2 Event Session event_var1 Fig. 7.3 Structure d'un service SPL 1. service Counter { 2. processing { 3. local void log (int); B registration { 6. int count; response outgoing REGISTER() { 9. count = 0; 10. return forward (); B1 11. } void unregister() { 14. log (count); B2 15. } dialog { 18. response incoming INVITE() { 19. response resp = forward (); 20. if (resp!= /SUCCESS) { 21. count++; 22. return forward 'sip:secretary@company.com'; 23. } else { 24. return resp; 25. } B4 26. } 27. } 28. } 29. } 30. } B3 Fig. 7.4 Le service Compteur écrit en SPL

84 74 Application à la Téléphonie sur IP An d'illustrer plus précisément la structure du langage, nous reprenons l'exemple du service Compteur introduit précédemment (section 7.1.1), que nous programmons avec le langage SPL. Le résultat est présenté à la gure 7.4. Rappelons que le service vise à gérer un compteur des appels qui ont été transférés vers une secrétaire, lorsque l'utilisateur associé au service ne peut être joint. Ce compteur est initialisé à zéro lorsque l'utilisateur s'enregistre auprès du serveur d'enregistrement, incrémenté lorsqu'un appel est transmis à la secrétaire et enregistré lorsque l'utilisateur se déconnecte. À titre de comparaison et pour simplier la compréhension du lecteur, la gure présente également les 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 de ce service, comparé à son homologue écrit en JAIN SIP (gure 7.1). Cet exemple permet de mettre en avant la structure hiérarchique d'un programme SPL 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 la session service (ligne 3) qui est utilisée par le gestionnaire unregister de la session enregistrement (ligne 14). De même, la variable count déclarée au niveau de la session enregistrement (ligne 6) est manipulée à la fois par le gestionnaire REGISTER pour initialiser le compteur (ligne 9), par le gestionnaire unregister pour sauvegarder sa valeur et par le gestionnaire INVITE de la session dialogue pour l'incrémenter (ligne 21). Comme l'illustre cet exemple, SPL ne nécessite pas de manipulation d'état explicite au sein du programme. La variable count est dénie et manipulée comme dans n'importe quel langage de programmation grâce à la manipulation d'état de l'environnement SIP-SLEE. Les manipulations de variables sont, en eet, automatiquement traduites en opérations d'accès, de sauvegarde et de restauration. En dehors de guider la conception du service, SPL ore 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 code qu'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 accomplissent certaines opérations puis transfèrent la requête SIP. Ce transfert cède le contrôle au serveur SIP, qui envoie la requête. Dans les interfaces de programmation existantes, lors de la réception d'une réponse, le code du service doit explicitement associer cette réponse à sa requête. De plus, avant le traitement de la réponse, certaines opérations doivent être mises en uvre pour restaurer le ot de contrôle suspendu au point 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 gestionnaire a 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 de la réponse correspondante, l'environnement restaure le pointeur de code et l'état du service, et l'exécution du gestionnaire continue. La gure 7.4 illustre le traitement d'une transaction SPL. Dans cet exemple, un appel entrant est transféré à l'utilisateur (ligne 19) et sa réponse est assignée à la

85 SPL, un langage dédié de programmation 75 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 également un processus de contrôle. Le protocole SIP décrit un ot de contrôle de session suivant une forte granularité, spéciant par exemple que durant un dialogue le contrôle doit passer du gestionnaire INVITE au gestionnaire ACK et terminer par le gestionnaire BYE. Pour augmenter son expressivité, SPL fournit au programmeur le moyen de raner la spécication 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 à son successeur. Cette abstraction permet, par exemple, de classer une session comme étant personnelle ou professionnelle, ce qui introduit un sous-processus logique à travers les invocations de méthodes restantes de la session. Une branche est choisie pour une session lorsque la session est créée. La branche est sauvegardée dans l'état de la session et est utilisée pour choisir le code correct pour chaque invocation successive de gestionnaires. Pour une session de type service ou enregistrement, la branche initiale est default. Un gestionnaire peut alors spécier une nouvelle branche, qui écrase la précédente. Lors de l'invocation d'un nouveau gestionnaire, le code correspondant à la branche est exécuté. Le traitement est identique en ce qui concerne les sessions dialogue et souscription, où la branche courante est héritée de la session enregistrement. Cependant, si un gestionnaire introduit une nouvelle branche, celle-ci vient s'ajouter à la séquence de branches et ne vient pas écraser la branche courante comme précédemment. Ce mécanisme est illustré à la gure 7.5, qui représente un extrait d'un service de hotline. Le mécanisme de branche permet de diérencier dans ce service deux contextes distincts, 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érateur libre et de comptabiliser le temps passé au téléphone. Cependant, les appels privés ne 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 service est sélectionnée (ligne 22). Si l'appelé est au contraire une personne (ligne 27), l'appel correspond 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 de la nature de l'appel (private ou hotline). La branche correcte correspondante est automatiquement choisie. L'introduction de branches permet ici de spécier plusieurs contextes d'appel et donc des comportements diérents pour un même service selon la branche Propriétés garanties Le domaine de la téléphonie impose des besoins importants en termes de sécurité et de abilité. Un service ne doit pas introduire d'erreurs à l'exécution et doit également respecter les invariants du protocole sous-jacent. Dans cette section, nous considérons

86 76 Application à la Téléphonie sur IP service hotline { processing { type hotliner_t {uri name; time t_call; int ticks;}; [...] registration { [...] response incoming REGISTER() {[...]} void unregister() {[...]} dialog { hotliner_t callee; time t; response incoming INVITE() { if (TO == 'sip:hotline@domain.com') { 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:voic @domain.com'; } else { response r = forward; if (r == /SUCCESS) { hotline_registered.remove (TO); return r branch private; } return r; } } response incoming ACK() { branch hotline { t = get_time(); set_status (h, PHONE); return forward; } branch private {[...]} branch default { return forward; } } response BYE() { branch hotline { callee.t_call += get_time()-t; return forward; } branch default { return forward; } } [...] }}}} Fig. 7.5 Le service hotline écrit en SPL

87 SPL, un langage dédié de programmation 77 certains types d'erreurs qui peuvent se produire lors de la programmation de services de Téléphonie sur IP avec des solutions existantes. Nous montrons de plus la manière dont SPL permet d'empêcher directement ces erreurs ou de les détecter par le biais de vérications statiques. La sémantique de SPL a été formellement spéciée [Pho06], ce qui permet une dénition précise de ses interactions avec l'environnement d'exécution SIP-SLEE. Cette dé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 une opération de signalisation pour ne pas perdre d'appels. En outre, le traitement de chaque message 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'appelé 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 signalisation prennent la forme de mots clés du langage, comme forward pour transférer une requête ou /SUCCESS pour indiquer une réponse de type succès. Ainsi, cela permet de vérier que tous les chemins d'exécution à travers un gestionnaire accomplissent au moins une opération de signalisation, et que ces actions sont cohérentes entre elles. De plus, SPL empêche de changer le nom de la requête lors du transfert de cette dernière ; le seul argument à forward est la destination, laissant la structure et le nom de la requête implicites. Un autre type d'erreur concerne la manipulation de messages SIP. Un message SIP contient de nombreux en-têtes, parmi lesquels certains peuvent être optionnels ou en lecture 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ête peut avoir un sens plus intuitif comme, par exemple, un entier ou un URI 4. Plusieurs actions peuvent alors rentrer en contradiction avec le protocole SIP et produire une erreur : accéder à un en-tête qui n'est pas présent dans le message, essayer de modier la valeur d'un en-tête accessible en lecture seule, ou encore se tromper dans le type d'une valeur d'un en-tête. Le langage SPL empêche l'accès à un en-tête non présent, via une construction when qui combine à la fois une vérication de présence de l'en-tête et l'accès à sa valeur. SPL fournit également une construction with qui permet de mettre à jour la valeur. Dans ce cas, une vérication est faite pour savoir si l'en-tête est accessible en écriture. Ces deux constructions permettent de traiter les en-têtes sous la forme de string ou de types plus élaborés ; dans le dernier cas, une vérication est faite sur la validité de la contrainte de type. Gestion de ressources erronée. Les API SIP basées sur des langages généralistes ne font rien pour se protéger contre les erreurs de programmation qui peuvent se produire avec ces langages. Par exemple, les API ne se protègent pas contre les boucles innies, et les API basées sur C ne se protègent pas contre les accès hors limites des structures 4 Un URI, de l'anglais Uniform Resource Identier, soit littéralement identiant uniforme de ressource, est une chaîne de caractères identiant une ressource sur le Web.

88 78 Application à la Téléphonie sur IP 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 erreurs de programmation les plus courantes sans sacrier la puissance d'expression nécessaire au domaine ciblé. SPL autorise seulement des itérations bornées, comme illustré par la construction foreach de la gure 7.5 (ligne 16). De plus, il inclut des vérications sur l'accès aux structures de données, comme dans Java. Enn, SPL ne possède aucun mécanisme d'allocation dynamique de données Implémentation Une version de l'environnement d'exécution, ainsi qu'un interprète pour le langage SPL, ont été développés par Nicolas Palix, un doctorant du projet Ph nix. Ces composants ont été intégrés au sein de l'architecture d'un serveur d'applications que nous avons conçue [BCL + 06b] et inclus dans le système de téléphonie de l'enseirb 5. Plusieurs services ont été testés [Pho06], notamment un service de le d'attente. Ce service est dédié à la gestion des appels du département Télécommunication. Si la secrétaire du département est déjà en ligne, ce service place les appels entrants en attente. Une estimation du temps d'attente est périodiquement calculée et annoncée aux appelants qui patientent. SPL permet d'écrire ce service en moins de 100 lignes de code, alors qu'il en faudrait quatre à cinq fois plus avec d'autres solutions. Dans cette section, nous avons introduit SPL, un langage dédié de programmation de services de Téléphonie sur IP qui ore des notations et des abstractions haut niveau. Ce langage cache les subtilités des plates-formes SIP, rendant les programmes plus concis que leurs homologues généralistes. Comparée à d'autres approches, la nature haut niveau de SPL rend les ots de contrôle et de données explicites, à la fois localement à une méthode du service, et globalement à une session. De plus, SPL permet de vérier des propriétés au niveau du domaine, du protocole, de la plate-forme et du service. Les exemples d'erreurs détectées dans les services incluent la perte d'appel, le non-respect des invariants du protocole SIP (e.g., transitions incorrectes), ou encore l'utilisation non bornée de ressources. Ainsi, de par sa conception, le langage garantit des propriétés critiques, bien au-delà de ce qu'il est possible de faire avec des langages généralistes tels que 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 services de téléphonie. À l'instar d'un logiciel de création de pages Web comme FrontPage de Microsoft, VisuCom met en place un processus de création intuitif et sûr. Ce langage visuel permet à des développeurs de dénir des traitements d'appels du point de vue de leur métier. Pour cela, VisuCom repose sur une nouvelle approche de développement de 5 L'ENSEIRB (École Nationale Supérieure d'électronique, d'informatique et de Radiocommunications de Bordeaux) est une école d'ingénieurs spécialisée dans les technologies de l'information et de la communication.

89 VisuCom, un langage dédié de modélisation 79 services de Téléphonie sur IP intégrant directement dans le processus de conception des données émanant du système d'informations (SI 6 ) d'une organisation. Dans le cas de VisuCom, le caractère haut niveau du langage va plus loin que le simple fait de présenter les concepts du domaine. En intégrant des données métiers dans la programmation de services, il devient possible d'adapter l'outil de développement de services et de présenter des abstractions vis-à-vis des besoins des développeurs. Ainsi, de par ses notations, mais également ses restrictions sémantiques et ses vérications, VisuCom permet à un utilisateur quelconque d'avoir accès à la programmation de services de Téléphonie sur IP, domaine jusqu'alors réservé aux spécialistes du domaine De nouveaux besoins Avec l'ouverture des plates-formes de téléphonie, il nous semble que de nouvelles perspectives vont naître pour des utilisateurs comme des commerciaux, des médecins ou encore des garagistes, pour qui la gestion de la relation téléphonique représente une part importante de l'activité professionnelle. Ces développeurs en herbe ont le soucis d'améliorer leur système téléphonique an d'optimiser leur relation client et donc leur productivité. Par exemple, un garage automobile peut souhaiter aiguiller automatiquement l'appel d'un client possédant un véhicule en révision vers l'atelier ayant pris le véhicule en charge, en s'aranchissant du passage par l'hôtesse d'accueil. Loin de vouloir un nouvel outil complexe, ces utilisateurs ont bien souvent des exigences 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, mais aussi pour leurs compétences. Toutefois, un besoin commun semble émerger : l'insertion de cet outil au sein de leur environnement professionnel, et en particulier l'intégration avec leur système d'informations, qui peut aller d'une simple feuille de calcul, à un outil de relation client complexe (e.g., un outil CRM 7 ). Il existe aujourd'hui des solutions haut niveau qui permettent de "coupler" la plateforme de téléphonie au système d'informations d'une organisation. Néanmoins, ces processus restent génériques, dicilement congurables et ne font intervenir qu'une faible interconnexion avec le SI. En eet, les solutions existantes apportent aux organisations l'opportunité d'utiliser les ressources du système (e.g., remontée de che client et composition simpliée du numéro), mais en aucun cas de raisonner sur ces informations, ni de 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écupé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èdent aucune connaissance en programmation et les outils existants ne semblent pas répondre à leurs besoins. Cependant, selon les situations, ils connaissent parfaitement les règles 6 Un système d'informations (noté SI) représente l'ensemble des éléments participant à la gestion, au traitement et à la diusion de l'information au sein d'une organisation. 7 Un outil CRM (Customer Relationship Management) est un outil de gestion de la relation client, dont le but est de rendre protable chaque interaction entre l'organisation et le client.

90 80 Application à la Téléphonie sur IP de gestion d'appels à appliquer au sein de leur organisation. Le but n'est donc pas d'amener leur expertise à la programmation, mais au contraire d'amener la programmation à leur expertise. Il faut donc fournir un outil permettant à ces utilisateurs de se concentrer sur la dénition du quoi, c'est-à-dire de ce que doit faire la logique du service, et non sur comment le faire. Un langage de modélisation dédié semble tout indiqué pour cela, élevant le niveau d'abstraction par rapport à ce que peut faire un langage de programmation dédié comme SPL. An de répondre au besoin d'interaction avec le système d'informations d'une organisation, nous proposons une nouvelle approche de développement de services sur laquelle est basé VisuCom, notre langage de modélisation Une nouvelle approche L'interconnexion d'un système de téléphonie avec un système d'informations n'est pas une chose aussi simple qu'il pourrait y paraître. Ce processus pose, en eet, un certain 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 impose certaines 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 du service. Cette section présente les grandes lignes de l'approche que nous proposons pour coupler 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 brevet 8, spéciant notamment le méta-modèle abstrayant le système d'informations de l'organisation, la méthode de construction et de mise à jour des données de ce modèle à partir de diverses sources du système, ainsi que certaines fonctionnalités du langage VisuCom. Approche. L'approche consiste à décomposer un service de téléphonie en deux composants : un arbre décisionnel et un composant issu du SI d'une organisation appelé la base de contacts. La gure 7.6 illustre notre approche et montre le processus d'interconnexion du SI au système de téléphonie et les relations entre les diérents composants. Le premier composant, l'arbre décisionnel, constitue le processus décisionnel de traitement d'appels. Il est représenté sous la forme d'un arbre de décisions qui dénit explicitement des règles de traitement, et dont le but ultime est de traduire chaque appel en une décision de routage. Ces décisions de routage sont en réalité des opérations de signalisation qui permettent de transférer un appel, de le rediriger ou encore de le rejeter. L'arbre de décisions est mis en uvre grâce à un ensemble de tests qui permettent non seulement de 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'une donnée de l'organisation issue du système d'informations (e.g., importance de l'appelant ou date de son dernier appel). Ainsi, il devient possible d'adapter le processus de traitement d'appels aux besoins de l'organisation. Une caractéristique essentielle du 8 Un brevet européen a été déposé le 7 août 2006, s'intitulant "Dispositif d'interconnexion d'un système d'informations d'organisation(s) à un serveur".

91 VisuCom, un langage dédié de modélisation 81 processus consiste donc à extraire ces données issues du système d'informations an de les rendre disponibles et les intégrer aisément au sein du processus de traitement d'appels. Pour cela, l'approche utilise un deuxième composant, la base de contacts, qui représente la vue du système d'informations par rapport au processus de traitement des appels téléphoniques. Le couplage de ces deux composants permet d'interconnecter le système de téléphonie au système d'informations d'une organisation. Cette association rend la programmation de services plus able puisque les données sur lesquelles reposent le service (les "paramètres" du service) sont nécessairement correctes. Notre approche dière en ce point de l'approche CPL où le service contient des paramètres saisis en dur par le développeur (e.g., l'adresse de redirection d'appel 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. Il nous est également possible de prendre en compte l'évolutivité de l'information. Considé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 modication sur tous les services contenant l'adresse de la secrétaire. Dans notre approche, la modication est faite au niveau du SI une fois pour toute et donc au niveau de la base de contacts. Ce faisant, comme les services redirigent l'appel sur l'adresse de la secrétaire en interrogeant la base de contacts, le changement est automatiquement pris en compte. De plus, notre approche permet de raisonner sur le modèle de données de la base de contacts et ainsi assurer la cohérence des informations issues de la base de contacts avec la logique de l'arbre décisionnel. Système d Informations Pilotes P1 P2 P3 Arbre décisionnel Base de contacts Service Fig. 7.6 Processus d'interconnexion du SI au système de téléphonie

92 82 Application à la Téléphonie sur IP La base de contacts : une abstraction du SI. An de pouvoir être générique et réutilisable quelle que soit l'organisation, l'approche doit être indépendante de la ou des sources d'informations du SI et des technologies associées. En eet, selon l'organisation considé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 les sources peuvent être multiples (e.g., tableur, base de données ou service Web). Tout ceci complexie l'intégration des données émanant du système d'informations dans le processus de traitement d'appels. De plus, la téléphonie représentant une ressource indispensable pour la plupart des organisations, la solution doit être pérenne. Ainsi, si une dé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'extraire ces données sans reposer directement sur le SI. En eet, le crash possible d'une source d'informations du SI n'a de ce fait aucun eet sur le processus de traitements d'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'appels ne soit pas présente en tant que telle dans le système d'informations. En eet, les données brutes extraites du système d'informations peuvent nécessiter des transformations spéciques (e.g., agrégation, ltrage ou transformation) an d'être adaptées aux besoins du processus de traitement d'appels téléphoniques. Pour répondre à ces problèmes, une caractéristique essentielle de la démarche consiste à abstraire les données extraites du SI an de les adapter au domaine de la téléphonie. Ces données sont alors rassemblées au sein de la base de contacts. An de faciliter son utilisation, elle manipule des abstractions spéciques 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, administration, groupe de personnes). Les éléments constitutifs d'un contact peuvent être répertoriés selon trois grandes catégories comme illustrés à la gure 7.7. La première regroupe les informations concernant le contact, qui ne constituent qu'une facilité d'utilisation ou de rendu, par exemple au niveau d'une interface graphique. Cela concerne des informations comme le nom du contact, son prénom ou une photo. Le deuxième élément est son identication. Ce type d'information est primordial pour le modèle de calcul de VisuCom puisqu'il permet d'identier le contact de manière unique dans la base 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. Enn, le dernier élément concerne les paramètres du contact. Ce type d'information est également primordial pour le modèle de calcul de VisuCom puisqu'il correspond à des caractéristiques spéciques liées à l'organisation et à la profession de l'utilisateur. Ces paramètres sont découpés en deux sous-catégories que sont les groupes et les attributs. La première sous-catégorie permet de mettre en place une catégorisation des contacts (appartenance à un groupe), alors que les attributs permettent une catégorisation des appels (e.g., notication d'un appel prioritaire, 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 contacts est alimentée par l'intermédiaire de pilotes (gure 7.6). Ces derniers représentent une

93 VisuCom, un langage dédié de modélisation 83 Contact Nom : Doe Prénom : John Photo Informations sur le contact Identifiant SIP : sip:doe@society.org Identifiant Groupes Client VIP Attributs Crédit Hotline : 10 Numéro de contrat: N2010_404 Responsable: sip:bob@company.com Paramètres du contact Fig. 7.7 Exemple d'informations concernant un contact interface avec un ou plusieurs composants du système d'informations. Un pilote est une application permettant d'extraire des informations d'une source de données et de les adapter 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 ou encore des annuaires LDAP (Lightweight Directory Access Protocol). Le rôle d'un pilote est d'extraire un ensemble d'informations sélectionnées, à une fréquence déterminée, et de mettre à jour la base de contacts en conséquence. Le pilote doit donc non seulement gérer l'hétérogénéité des sources et des formats de données du SI, mais aussi introduire de la logique an d'adapter l'information à notre modèle. Pour cela, un pilote possède une architecture en couches et se décompose selon deux niveaux ; le premier fait gure d'accesseur technique, permettant d'accèder à l'information en fonction de la technologie employée au niveau du SI. La seconde couche représente, quant à elle, une couche d'abstraction fonctionnelle, mettant en uvre une logique qui adapte l'information issue du SI au formalisme de la base de contacts. Contrairement aux solutions existantes, l'approche proposée ici met en uvre un nouveau modèle de traitement d'appels téléphoniques permettant de prendre une décision en fonction des données issues du système d'informations d'une organisation, via la base de contacts. Ainsi, il devient possible d'automatiser des décisions de routage en fonction du métier de l'organisation et de la situation actuelle, sans intervention humaine. De plus, les services de traitements d'appels mis en uvre permettent non seulement de tenir compte des données du SI, mais également des modications de la 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 des données au processus de traitement d'appels, d'évolutivité du système de traitement d'appels en fonction de la dynamique de l'organisation, et donc de richesse des services créés.

94 84 Application à la Téléphonie sur IP Le langage VisuCom VisuCom 9 est un langage dédié de modélisation basé sur l'approche que nous venons d'exposer. Un service VisuCom se présente donc sous la forme d'un arbre décisionnel binaire. Les n uds de cet arbre sont des icônes que l'utilisateur relie entre elles. VisuCom propose une répartition des fonctionnalités selon trois types fondamentaux. Le tableau 7.2 résume les fonctionnalités oertes par ce langage, ainsi que les représentations graphiques associées. D'abord, des fonctionnalités dites de décision. Elles représentent les opérations de signalisation disponibles telles que le transfert d'appel, la redirection d'appel sur une personne particulière ou sur un groupe de personnes, le rejet d'un appel ou encore l'envoie d'un courrier électronique au correspondant (e.g., an d'être notié lors d'une absence par exemple). VisuCom ore également des icônes dites de ltrage d'appel. Ces ltrages, ou tests, correspondent à des prédicats et sont eectués au niveau de l'appel. Par exemple, il s'agit de tester la source de l'appel ou encore une plage horaire précise de la journée an d'appliquer un traitement particulier sur l'appel. Il peut également s'agir d'un ltrage sur une caractéristique précise de l'appelant (e.g., son chire d'aaire ou la date de son dernier appel) ou sur sa disponibilité (renseignée par un agenda). Enn, VisuCom propose des fonctionnalités plus avancées dites d'administration. Elles permettent, par exemple, d'introduire l'équivalent de procédures au sein d'un service, an 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 des disjonctions 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'utiliser des 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 groupes de contacts et d'attributs. À travers ces abstractions, et notamment le type d'attributs présents dans la base, le développeur manipule des concepts de son métier. Un autre utilisateur d'une autre organisation possède des attributs diérents, et donc des services dié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 SPL dont le formalisme reète le protocole SIP. Le langage, mais aussi le couplage avec la base de contacts, permettent d'amener l'utilisateur à manipuler des concepts naturels et familiers pour créer, modier ou étendre un service. La facilité d'utilisation de VisuCom 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'utilisateur un environnement complet (e.g., de conception, de vérication et de sauvegarde), et simplie l'utilisation du langage par un système de glisser-déposer (drag-and-drop) des diérentes abstractions graphiques présentées. Un exemple VisuCom. An de mieux illustrer le langage VisuCom, considérons l'exemple Filtrage sur Indisponibilité, présenté à la gure 7.8. Notons tout d'abord que les indications se trouvant à proximité des icônes de l'arbre ont été ajoutées simplement pour rendre plus compréhensible l'exemple, mais sont toutefois disponibles au passage 9 VisuCom fait l'objet d'un transfert technologique auprès de la société Siderion Technologies.

95 VisuCom, un langage dédié de modélisation 85 Fonctionnalités Nom Exemples Représentation Transfert d appel Décision Redirection d appel sur une personne Redirection d appel sur un groupe de personnes Rediriger l appel sur John Doe. Rediriger l appel sur ma secrétaire. Rediriger l appel sur le service informatique. Rediriger l appel sur une secrétaire. Rejet d un appel Envoi d un mail Envoyer le nom de l appelant, l heure et le jour de l appel. Filtrage Avancées Filtrage sur une plage horaire Filtrage sur l appelant Filtrage sur la disponibilité Filtrage sur une caractéristique de l appelant Filtrage réutilisable avancé Action réutilisable avancée L appel survient-il entre 8h et 17h? L appel arrive-t-il pendant les heures d ouverture? L appelant est-il John Doe? L appelant est-il un membre de l administration? Suis-je en rendez-vous? Suis-je en déplacement? Est-il un client Premium? Son crédit hotline est-il épuisé? 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? Si l appel survient pendant les heures d ouverture, alors rediriger l appel sur le standard, sinon sur la boîte vocale. 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é de l'appelé (par rapport à son agenda). Si celui-ci est disponible, l'appel lui est transféré, et s'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., en réunion), le service regarde si l'appelant est un client privilégié ; si c'est le cas, l'appel est transféré sur le mobile de l'appelé. Si le client n'est pas premium, alors un mail est envoyé à l'appelé indiquant les coordonnées de l'appelant, le jour et l'heure de l'appel, an qu'il puisse le contacter. L'expressivité de VisuCom. L'expressivité de VisuCom est un des points clés du langage. Les premières versions étaient issues directement de notre connaissance du domaine 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ésultait des fonctionnalités beaucoup trop complexes, et des notations et des concepts hors de portée des non-programmeurs. VisuCom a alors subi une refonte complète en partant des besoins des utilisateurs. Ainsi, le langage est apparu totalement diérent et de beaucoup 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 variable explicitement. De plus, l'une des forces du langage est de raner les concepts pour les rendre accessibles. Ainsi, nous pouvons noter que la seule abstraction forward

96 86 Application à la Téléphonie sur IP Fig. 7.8 Le service VisuCom Filtrage sur Indisponibilité de SPL se traduit en réalité en plusieurs concepts dans VisuCom selon les besoins de l'utilisateur (e.g., transférer l'appel, rediriger vers une personne ou encore rediriger sur un groupe). Nous pouvons également nous apercevoir que la notion de continuation liée au forward de SPL (association requête-réponse) est explicitement représentée dans VisuCom (gure 7.8). En eet, dès que le développeur réalise une opération de signalisation qui implique une réponse, ce dernier est invité à indiquer s'il veut traiter cette réponse. S'il ne le souhaite pas, aucune autre action n'est possible. De plus, le langage manipule explicitement la notion de ltrage. Là encore, la construction if de SPL se traduit en diérents ltrages intuitifs (tableau 7.2). Enn, de par la nature haut niveau du langage, l'éditeur dédié permet à VisuCom d'être contextuel. Ainsi, pour un utilisateur donné, les services créés ne peuvent se faire que selon ses propres attributs. Par exemple, 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ésignant une 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'est pas 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 de contacts permet ainsi de restreindre le contexte de conception des services, empêchant le développeur de manipuler des informations erronées (e.g., ltrer un appel sur la valeur d'un attribut qu'il ne possède pas ou rediriger sur une personne inconnue).