partie de la connaissance du domaine mais aussi une part importante de l'implémenta-tion (secl'implémenta-tion 3.2.3). L'enjeu consiste donc à réconcilier ces approches (programmal'implémenta-tion 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.
dédiés semblent, quant à eux, plus à même de réduire le fossé entre le niveau d'abstrac-tion et l'implémentad'abstrac-tion. De plus, du fait d'une expressivité restreinte et d'une séman-tique précise, les DSL facilitent l'analyse de programmes, la vé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 sou-vent leurs approches sur le domaine d'application (section 3.3.1), ou encore la plate-forme d'exécution (section 2.2.1). La notion d'utilisateur est alors trop souvent délais-sée. Or, il existe aujourd'hui une variété de programmeurs potentiels dans un mê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 diver-sité impacte sur leurs besoins en termes de solutions de programmation (section 3.4.2).
Ainsi, dans le cas de la Téléphonie sur IP, les services peuvent être programmés par des prols complètement diérents, allant du simple utilisateur à l'administrateur d'un PABX1, 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épon-dant à 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.
1Un Private Automatic Branch eXchange ou PABX est un commutateur téléphonique privé, servant à relier les postes téléphoniques d'un établissement (lignes internes) avec le réseau téléphonique public.
Approche proposée
55
Présentation de l'approche
Le domaine de la programmation est aujourd'hui en pleine mutation. Face aux ex-perts en programmation, langages et autres technologies, se dresse un nouveau type 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 pro-grammeurs expérimentés ne peuvent, quant à eux, se contenter de solutions restreintes.
Leur activité requiert bien souvent une solution expressive, sans pour autant tomber dans une approche généraliste.
Les travaux présentés dans cette thèse visent à rendre la programmation plus ac-cessible à ces nouveaux développeurs, tout en répondant à la diversité des besoins 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 lan-gage dédié orienté modélisation (Domain-Specic Modeling Language ou DSML) et un langage dédié orienté programmation (Domain-Specic Programming Language ou DSPL1). Cette dichotomie des DSL s'appuie sur la caractérisation des besoins des déve-loppeurs énoncée au chapitre précédent. Ces langages évoluent à des niveaux d'abstrac-tion diérents, et sont adaptés à leurs utilisateurs. Le langage dédié de plus haut niveau (DSML), possédant les plus fortes abstractions, est implémenté dans un langage dédié
1Dans ce document, nous utiliserons de manière indiérente le terme langage dédié orienté program-mation et DSPL.
57
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.
Programmation Modélisation
Implémentation Compilation
Programmation
DSML
DSPL
Implémentation
Vérifications
Compilation
Vérifications DOMAINE
Fig. 6.1 Vue générale de notre approche
Cette architecture en couches permet d'élever le niveau d'abstraction, mais aussi, grâce à l'introduction d'une couche langage intermédiaire (DSPL), de combler signi-cativement le fossé entre des modèles et leurs implémentations. En utilisant le 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'utilisa-teurs une solution adaptée, expressive pour les experts en programmation via le DSPL, et simple et haut niveau pour les experts du domaine via le DSML. Ainsi, le langage dé-dié de programmation peut être utilisé directement par un programmeur pour produire une variété importante d'applications plus ou moins complexes. Le DSPL peut égale-ment être caché de l'ensemble des développeurs et ne servir simpleégale-ment 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
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'éta-ger 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émen-tés. Il devient alors possible de fournir plusieurs solutions de modélisation diérentes, ciblant des utilisateurs avec des besoins diérents. Du fait de l'existence d'une variété de préférences et de contraintes pouvant être exprimées par les experts, une variété de DSML peut être envisagée, orant divers paradigmes (textuels ou visuels), degrés d'ex-pressivité 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 im-plé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 do-cument. Elle est principalement basée sur la dichotomie entre les langages dédiés de
programmation et de modélisation. Si cette dichotomie reète bien la diversité des be-soins des utilisateurs, il n'existe cependant pas aujourd'hui de moyen permettant de caractériser cette diérence. Toutefois, l'étude de l'existant nous montre que cette di-chotomie est bien présente.