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
Je tiens tout d'abord à remercier les membres du jury :
Jean Bézivin, professeur à l'Université de Nantes (France) et Olivier Danvy, pro- fesseur à l'Université d'Aarhus (Danemark), d'avoir accepté la lourde tâche 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 an- né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, Julien2, Laurent2, 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 par- ticuliè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.
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ésor- mais 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 multi- plicité 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 do- maine (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 program- mation 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éoc- cupations 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
Over the last decade, allowing non-programmers to write their own programs has be- come a practical challenge that is currently receiving enormous attention in the 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 adap- ted 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 do- main experts to directly express solutions in domain terms, without necessarily requi- ring programming skills. We show that layering DSLs enables one to separate domain concerns and implementation concerns. In doing so, our approach greatly facilitates the implementation of high-level solutions and the verication of telephony-specic proper- ties, 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 programming- language 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
Table des matières
1 Introduction 7
1.1 Thèse . . . 8
1.2 Contributions . . . 9
1.3 Organisation du document . . . 10
I Contexte 13 2 Ingénierie dirigée par les modèles 15 2.1 Introduction à la modélisation . . . 15
2.1.1 Motivations . . . 16
2.1.2 Le monde des modèles . . . 17
2.2 Approches existantes . . . 19
2.2.1 Architecture dirigée par les modèles . . . 19
2.2.2 Modélisation spécique à un domaine . . . 21
2.3 Limitations des approches . . . 24
2.3.1 Architecture dirigée par les modèles . . . 24
2.3.2 Modélisation spécique à un domaine . . . 26
2.4 Évolution récente de l'IDM . . . 27
2.5 Bilan . . . 28
3 Langages dédiés 29 3.1 Introduction . . . 29
3.2 Motivations . . . 31
3.2.1 Programmation du domaine de problèmes . . . 31
3.2.2 Sûreté améliorée . . . 32
3.2.3 Réutilisation systématique . . . 33
3.3 Processus de développement . . . 33
3.3.1 Conception . . . 33
3.3.2 Implémentation . . . 36
3.4 Limitations actuelles . . . 38
3.4.1 Coût de développement . . . 38
3.4.2 Problèmes liés au domaine . . . 38
3.4.3 Propriétés du langage . . . 39 1
4 Étude de cas : la Téléphonie sur IP 41
4.1 Introduction à la téléphonie applicative . . . 41
4.2 L'environnement SIP . . . 42
4.2.1 Les principes du protocole SIP . . . 43
4.2.2 SIP par l'exemple . . . 43
4.2.3 Introduction aux services SIP . . . 44
4.3 Les enjeux de la création de services . . . 45
4.4 État de l'art des solutions existantes . . . 47
4.5 Bilan . . . 50
5 Bilan 51 5.1 La diversité des programmeurs . . . 51
5.2 Problématiques . . . 53
II Approche proposée 55 6 Présentation de l'approche 57 6.1 L'approche proposée . . . 57
6.2 Une dichotomie bien réelle . . . 60
7 Application à la Téléphonie sur IP 63 7.1 Analyse du domaine . . . 63
7.1.1 Une programmation trop complexe . . . 63
7.1.2 Des approches divergentes . . . 67
7.1.3 Bilan . . . 68
7.2 SPL, un langage dédié de programmation . . . 69
7.2.1 L'environnement d'exécution . . . 69
7.2.2 Le langage . . . 72
7.2.3 Propriétés garanties . . . 75
7.2.4 Implémentation . . . 78
7.3 VisuCom, un langage dédié de modélisation . . . 78
7.3.1 De nouveaux besoins . . . 79
7.3.2 Une nouvelle approche . . . 80
7.3.3 Le langage VisuCom . . . 84
7.3.4 Propriétés garanties . . . 87
7.4 Application de notre approche . . . 88
7.5 Bilan . . . 92
8 Méthodologie de compilation de DSL 93 8.1 Problématique de la compilation d'un DSL . . . 93
8.2 Méthodologie de développement de compilateurs . . . 95
8.2.1 La représentation abstraite . . . 95
8.2.2 Les diérentes dimensions de compilation . . . 96
8.3 Compilation de la représentation abstraite . . . 98
8.3.1 La programmation orientée aspect . . . 101
8.3.2 Les annotations . . . 102
8.3.3 La spécialisation de programme . . . 102
8.4 Compilation des unités fonctionnelles . . . 103
8.4.1 Facette environnement d'exécution . . . 103
8.4.2 Facette langage . . . 104
8.4.3 Facette programme . . . 107
8.5 Compilation des unités non-fonctionnelles . . . 108
8.5.1 Facette environnement d'exécution . . . 109
8.5.2 Facette langage . . . 109
8.5.3 Facette programme . . . 110
8.6 Bilan . . . 111
9 Compilation et vérication de DSML 113 9.1 Introduction . . . 113
9.1.1 Stratego/XT . . . 116
9.1.2 TLA+ . . . 117
9.2 Compilation de DSML . . . 118
9.2.1 Compilation vers SPL . . . 119
9.2.2 Compilation vers TLA+ . . . 121
9.3 Vérication de DSML . . . 124
9.3.1 Vérication de services CPL . . . 125
9.3.2 Le cas particulier du modèle VisuCom . . . 128
9.4 Travaux connexes à notre approche en couches . . . 131
9.5 Bilan . . . 132
10 Conclusion 133 10.1 Contributions . . . 133
10.2 Perspectives et Futures Directions . . . 135
Publications 137 Bibliographie 139 A Le langage TLA+ 153 A.1 Logique temporelle : un peu d'histoire... . . 153
A.2 Qu'est ce que la logique temporelle des actions ? . . . 154
A.3 Spécication TLA+ . . . 155
A.4 Le model checker TLC . . . 157
Table des gures
2.1 Niveaux de modélisation . . . 18
2.2 Architecture dirigée par les modèles (MDA) . . . 20
2.3 Modélisation spécique à un domaine (DSM) . . . 22
3.1 Processus de développement d'un langage dédié . . . 36
4.1 Architecture SIP . . . 44
4.2 Service de téléphonie écrit en CPL . . . 48
6.1 Vue générale de notre approche . . . 58
7.1 Le service Compteur écrit en JAIN SIP . . . 65
7.2 L'environnement SIP-SLEE et les méthodes de contrôle . . . 70
7.3 Structure d'un service SPL . . . 73
7.4 Le service Compteur écrit en SPL . . . 73
7.5 Le service hotline écrit en SPL . . . 76
7.6 Processus d'interconnexion du SI au système de téléphonie . . . 81
7.7 Exemple d'informations concernant un contact . . . 83
7.8 Le service VisuCom Filtrage sur Indisponibilité . . . 86
7.9 Illustration de notre approche dans la téléphonie . . . 88
7.10 Comparaison des approches CPL, VisuCom et SPL . . . 89
7.11 Comparaison des approches SPL et JAIN SIP . . . 91
8.1 Méthodologie de développement de compilateurs de DSL . . . 96
8.2 Le service Compteur écrit en SPL . . . 98
8.3 La représentation abstraite du service Compteur écrite en JAIN SIP . . 100
8.4 Comparaison du service SPL et de sa représentation abstraite . . . 101
8.5 Aspect correspondant à la facette environnement d'exécution . . . 104
8.6 Aspect correspondant à la facette langage (1) . . . 105
8.7 Aspect correspondant à la facette langage (2) . . . 106
8.8 Aspect correspondant à la facette programme . . . 108
8.9 Annotations correspondantes à la facette langage . . . 110
9.1 Compilation et vérication de DSML . . . 115
9.2 Comparaison des approches CPL et SPL . . . 120 5
9.3 Règles Stratego pour compiler CPL en SPL . . . 120
9.4 Règle Stratego pour compiler VisuCom en SPL . . . 121
9.5 Règle Stratego pour générer une spécication TLA+ depuis CPL . . . . 123
9.6 Règle Stratego pour générer une spécication TLA+ depuis VisuCom . . 124
9.7 Extrait des propriétés à vérier pour un service de téléphonie . . . 125
9.8 Service CPL inconsistant (adresses) . . . 126
9.9 Service CPL inconsistant (dates) . . . 127
9.10 Rapport d'erreurs TLC concernant un service CPL . . . 128
9.11 Service VisuCom inconsistant vis-à-vis de la base de contacts . . . 130
9.12 Rapport d'erreurs TLC concernant un service VisuCom . . . 130
A.1 Séquence d'états . . . 154
A.2 Spécication TLA+ d'un service VisuCom - partie 1 . . . 155
A.3 Spécication TLA+ d'un service VisuCom - partie 2 . . . 156
A.4 Fichier de conguration à un instant donné . . . 159
A.5 Extrait d'un rapport TLC sans erreur . . . 159
Introduction
Ces dernières années ont vu l'émergence d'un nouveau type de programmeur, l'utili- sateur nal [MKB06]. Ces utilisateurs perçoivent la programmation comme un 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'évo- lution des marchés boursiers, ou encore un électronicien qui désire modéliser le com- portement d'un système électronique [SSM05a]. Ces nouveaux développeurs1 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 do- maine. Il est alors nécessaire de cacher toute complexité, qu'elle soit issue de la diversité des technologies, des méthodes de conception ou encore des procédés de développement.
Le mécanisme d'abstraction est ainsi utilisé depuis longtemps par l'ingénierie 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 rap- port à un type d'utilisateur et à un domaine particulier. Ce faisant, l'abstraction per- met non seulement de cacher les détails non essentiels à l'utilisateur, mais é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'ap- plication (nance, médecine, assurance, ou encore biologie). Or, il ne s'agit pas seulement
1Dans la suite de ce document, nous utiliserons le terme développeurs pour désigner ces nouveaux utilisateurs sans expérience en programmation, parfois appelés non-programmeurs.
7
de cacher la complexité ou d'élever le niveau d'abstraction. Il s'agit également de fournir à ces développeurs non-informaticiens des outils adaptés à leurs besoins. Ces outils per- mettent de raisonner au même niveau que le problème, tout en leur assurant un 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 abstrac- tion 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 abstrac- tion 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 (DSL2). Elle repose sur une architecture en couches des langages. Cette archi- tecture permet à la fois d'élever progressivement le niveau d'abstraction, mais aussi 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'organisation3. 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 aug- mentent 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
2DSL est l'acronyme anglais de Domain-Specic Language.
3Dans la suite de ce document, le terme organisation désigne une entreprise, une administration, ou tout simplement un service ou tout autre structure professionnelle.
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'abstrac- tion 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 ni- veau, 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 nou- velle 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éa- tion 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, SPL4 et VisuCom, qui per- mettent de programmer des services de téléphonie à des niveaux d'abstraction diérents.
Approche langage. Nous décrivons l'architecture en couches des langages dédiés.
Nous montrons dans quelle mesure elle permet de répondre au besoin de la montée
4SPL est l'acronyme de Session Processing Language.
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'archi- tecture 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 ni- veau 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
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.
Contexte
13
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 com- plexités technologiques. L'Ingénierie Dirigée par les Modèles (IDM1) cherche à répondre à cette attente. Cette approche émergente du développement logiciel considère le mo- dèle comme l'objet central de toutes les réexions dans les processus de conception 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'auto- matisation de la production logicielle et donc la réduction des coûts de développement.
Dans ce chapitre, nous présentons l'approche orientée modèle comme une 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 Architec- ture), 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 Soley2, 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,
1Pour é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.
2Richard 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
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 inno- vation 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 proces- sus. 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 singula- rise par une démarche dans laquelle tout ou partie d'une application informatique est générée à partir de modèles.
2.1.1 Motivations
Les motivations et les principes sous-jacents au développement dirigé par les modè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 logi- ciels 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 combinai- son de trois facteurs principaux : la complexité, la diversité et l'évolution. La complexité des plates-formes technologiques, mais également l'hétérogénéité et la diversité des do- maines, des techniques, des processus, ou encore des outils de développement tendent à rendre spécique la tâche de développement logiciel, ainsi qu'à spécialiser les com- pétences techniques des concepteurs, mais aussi des utilisateurs. Toute géné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
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'abs- traction 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 facile- ment 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.
2.1.2 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 à carac- té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 évi- demment, 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 infor- mations à 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 auto- mobile 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.
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éter- mine la terminologie à utiliser pour dénir des modèles. Dans le cas d'une carte routière, le méta-modèle utilisé est donné par la légende qui précise, entre autres, l'échelle de 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.
Langage de méta-modélisation
Langage de modélisation
Méta-méta-modèle
Méta-modèle
Modèle M3
M2
M1 χ est conforme à
ε est exprimé dans µ représente χ
χ χ
ε
ε µ, ε
µ
Fig. 2.1 Niveaux de modélisation
La gure 2.1, extraite de la thèse de Fleurey [Fle06], résume les diérents niveaux de modélisation (M1 : modèle, M2 : méta-modèle et M3 : méta-méta-modèle), ainsi que
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 plu- sieurs mises en ÷uvre partageant une vision similaire de ce que doit être le dévelop- pement logiciel. L'IDM peut être vue comme une famille d'approches dont le 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 mo- délisation, symbolisées par l'approche MDA et les approches de modélisation spéciques à un domaine d'application.
2.2.1 Architecture dirigée par les modèles
L'Architecture Dirigée par les Modèles est une démarche logicielle proposée par l'organisme de standardisation OMG dans les années 2000. 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éta- modé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 PIM3) et les parties liées aux plates- formes (Platform Specic Models ou PSM3). Il s'agit donc de construire des modèles (PIM) de systèmes de façon à prendre en compte tous les besoins fonctionnels, mais à demeurer complètement indépendants de toutes plates-formes, langages de program- mation ou autres aspects liés à l'implémentation. An de cibler des environnements d'exécution spéciques, il sut de concevoir plusieurs modèles spéciques aux plates- formes (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
3Dans ce document, nous utiliserons de manière indiérente le terme Platform Independant Models et PIM. De la même manière, nous utiliserons indiéremment le terme Platform Specic Models et PSM.
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 Trans- formation Language) [JK06a, JK06b], BOTL (Basic Object-oriented Transformation Language) [MB03], QVT Merge [GBA+05] ou encore VIATRA (VIsual Automated mo- del 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
PSM
Code PSMPSM
CodeCode
transformation
génération de code transformation
Fig. 2.2 Architecture dirigée par les modèles (MDA)
Perspective. Dénir de manière exacte la philosophie de l'approche MDA n'est pas chose facile, car cette dernière est en constante évolution [BCT05]. Initialement, l'ap- proche MDA vise à manipuler diérents modèles d'un système à des niveaux d'abstrac- tion variables, qui ultimement sont traduits dans des technologies d'implémentation variées (grâce à des transformations de modèles bien-dénies). Mais aujourd'hui, l'Ar- chitecture Dirigée par les Modèles se veut davantage être un cadre 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'ap- proche MDA, au même titre que les transformations PIM-PIM ou encore PSM-PSM.
Après avoir longtemps promulgué une approche autour de la notion d'indépendance 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, in- sistant 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 sys- tèmes tout en facilitant les migrations technologiques tout au long du cycle de vie d'un
système (conception, assemblage, intégration, évolution, etc.).
La modélisation par la standardisation. Pour mettre en ÷uvre l'approche MDA, l'OMG insiste sur l'importance de manipuler des standards de modélisation, qui consti- tuent les briques de base de l'architecture MDA. L'architecture repose donc sur un ensemble de recommandations non-propriétaires visant à spécier des technologies inter- opérables an de réaliser le développement dirigé par les modèles à l'aide de transforma- tions automatisées. Le standard MOF (Meta Object Facility) est le standard central de l'architecture MDA et représente le socle de l'architecture. C'est un langage de méta- modélisation qui permet de dénir d'autres langages comme UML (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 informa- tiques. 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éveloppe- ment 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 sys- tè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.
2.2.2 Modélisation spécique à un domaine
Contrairement à l'approche MDA basée sur des standards de modélisation généra- listes, la modélisation spécique à un domaine (Domain-Specic Modeling ou DSM4) [Coo04] met en avant une méthodologie de développement centrée sur la notion de do- maine et visant à améliorer la productivité. Comme son nom le suggère, la modé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-
4Dans ce document, nous utiliserons de manière indiérente le terme Domain-Specic Modeling et DSM.
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 lan- gage de modélisation spécique à un domaine (Domain-Specic Modeling Language ou DSML5). 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éli- sation 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éli- sation 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 com- plè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 com- posants : 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 mo- dè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é
Code
Générateur de Code Dédié
Générateur de Code Dédié
Code Code
Framework Framework Framework
Fig. 2.3 Modélisation spécique à un domaine (DSM)
5Dans ce document, nous utiliserons de manière indiérente le terme Domain-Specic Modeling Language et DSML.
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 utilisa- teurs. 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 mo- dé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 Engi- neering) [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'ap- proche 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 mo- dèles spéciques à un domaine. Ainsi, ils permettent de dénir explicitement un méta- modèle, et donc un DSML, et au même niveau de programmer tous les outils spé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 autori- sé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 principale- ment par le langage de méta-modélisation qu'ils manipulent et qui est la base de tout
l'environnement (e.g., ECore, MOF ou encore KM3). Parmi ces outils, certains sont des environnements commerciaux comme l'outil MetaEdit+ de Metacase [SLTM91], l'en- vironnement 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 sus- citent 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 ma- tures. Ainsi, comme le montre Schmidt [Sch06], il est dicile de trouver des solutions techniques solides des technologies IDM, des applications industrielles de ces techno- logies, ou encore des bénéces avérés de cette démarche. En 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 pro- prié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 re- pré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.
2.3.1 Architecture dirigée par les modèles
À la lecture du guide proposé par l'OMG [Obj03], il apparaît évident que l'ap- proche MDA se veut généraliste, s'appuyant sur des dénitions (plate-forme, modèle, transformation), des standards et des outils eux aussi généralistes. Or, l'ensemble 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
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 environne- ments en ce qui concerne certains buts. Un modèle est souvent représenté comme une combinaison de dessins et de texte. Le texte devrait être dans 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 plate- forme 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éel- lement 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élisa- tion 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écia- lisation et la dénition sémantique nécessaires à la génération d'une implémentation [CESW04]. Pour pallier ce manque, la version 2.0 d'UML [FGDS06] inclut une facilité
de méta-modélisation puissante (Meta-Object Facility ou MOF), qui permet d'é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. Mal- heureusement, certaines constructions dans UML 2.0 restent encore sans sémantique [HT06, HR04]. Ce manque de dénition sémantique empêche l'usage précis des exten- sions UML, réduit leur pouvoir expressif et empêche d'assurer une certaine conformité au niveau des outils. Comme Thomas le note [Tho04], UML 2.0 manque à la fois d'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 plu- part du temps, il ne permet pas de représenter les besoins réels des modèles [FS00].
Par ailleurs, la génération de code se limite dans la plupart des cas à la génération d'artéfacts, mais en aucun cas à une génération complète, à cause de son imprécision et sa généricité.
2.3.2 Modélisation spécique à un domaine
Selon Greeneld et Short [GSCK04], la généricité excessive et la construction mo- nolithique de générateurs de code font parties des freins majeurs au dé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'ap- proche 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 à main- tenir 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éra- teur, une impossibilité d'évolution ou un framework trop restrictif car trop haut niveau.
Un autre frein majeur de l'approche se situe autour de la spé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
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 pro- grammation 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 lan- gages de programmation sont dits plus concrets du fait de leur besoin d'être exécutables.
Or, l'idée novatrice de l'Ingénierie Dirigée par les Modèles est de rendre les modèles pro- ductifs, c'est-à-dire capable de générer du code, et donc d'avoir des modèles exécutables.
Ce besoin d'exécutabilité était jusque-là complètement absent lors de l'utilisation de 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écica- tion exécutable, comme le langage de la méthode B [Abr96], qui pourraient être utilisés à la place d'UML. Ces langages permettent d'établir une chaîne de production qui va de la spécication du programme au code source associé. Mais tout n'est pas pour au- tant résolu, car se pose alors le problème de la généricité. En 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
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évelop- pement 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'inter- opé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'ac- cord industriels et académiques sur l'utilisation des langages dédiés dans le processus de modélisation.
