Soutenance mémoire
Besoin de facilités d’ingénierie pour les langages de modélisation dédiés
La définition et l’outillage d’un langage dédié demande un effort de développement important pour un public par définition réduit. En effet, le développement de langages généralistes justifie des efforts importants de définition et d’outillage. Ce même effort se justifie plus difficilement dans le cadre de nombreux langages dédiés, qui par définition s’adressent à un nombre restreint d’utilisateurs. Ces utilisateurs ont pourtant besoin des mêmes outils que les utilisateurs de langages généralistes (éditeurs, analyseurs syntaxiques, simulateurs, compilateurs, outils de vérification, etc.). De même que la réutilisation de briques logicielles (méthodes, objets, composants) entre différents systèmes permet de diminuer l’effort de développement d’un logiciel [BBM96, MC07], la réutilisation d’outils entre différents langages de modélisation dédiés permettrait de diminuer l’effort de développement d’un langage de modélisation dédié [KSW+13]. Certains concepts de base de l’ingénierie dirigée par les modèles sont actuellement un frein à l’établissement de facilités d’ingénierie permettant de diminuer le coût de définition et d’outillage des langages de modélisation dédiés. En particulier, la relation de conformité interdit la réutilisation par polymorphisme de sous-type au niveau des modèles et ne prend en compte que les éléments de modèle (i.e., les objets) en ignorant les transformations associées aux modèles. Malgré la volonté de l’ingénierie dirigée par les modèles de faire des modèles des entités de première classe, placées au centre du développement logiciel, rares sont les langages et les environnements de modélisation qui offrent cette possibilité. En effet, même au sein de standards de facto comme le MOF ou Ecore, ni la notion de modèle, ni celle de métamodèle n’apparaît. Dans ces métalangages, et dans ceux qui s’appuient sur eux, un métamodèle n’est défini et manipulable qu’au travers d’un ensemble de packages. S’abstraire de ces concepts de bas niveau sous-jacents à l’ingénierie dirigée par les modèles permettrait d’offrir aux utilisateurs des environnements de modélisation in-the-large, i.e., des environnements permettant de manipuler les modèles et leurs relations comme des entités dites de première classe, c’est à dire des concepts directement exprimables dans un langage.
Qu’est-ce-qu’un langage logiciel
Un langage est généralement défini comme un ensemble (potentiellement) infini de phrases ou d’énoncés [Fav04a, Kle08]. Les « phrases » ou « énoncés » d’un langage sont toutes les phrases valides qui peuvent être écrites dans ce langage.
Définition 2.1. (Langage) Un langage est un ensemble de phrases. Au-delà de cette définition très large, qui englobe également les langages naturels, le terme langage logiciel se réfère à tous les langages artificiels qui sont impliqués dans le développement de systèmes logiciels [FGLW09].
Définition 2.2. (Langage logiciel) Un langage logiciel est un langage artificiel impliqué dans le développement de systèmes logiciels. Les langages logiciels englobent donc les langages de programmation aussi bien génériques (e.g., Java) que dédiés (e.g., Logo 1) ; mais aussi les langages de modélisation : d’exigences (e.g., KAOS [DDMvL97] ou i* [Yu97]), de la variabilité logicielle (e.g., les langages de feature model [SHT06]), de processus de développement (e.g., SPEM [OMG08]), ou génériques (e.g., UML [OMG11]) ; les langages de requête (e.g., SQL [ISO11b]) ; les ontologies (e.g., Cyc [Len95]) ; ou les langages de stockage et d’échange de données (e.g., XML [W3Ca]).
Langages généralistes et langages dédiés
Une solution pour aborder le nombre et la complexité croissants de préoccupations à prendre en compte dans le développement de systèmes logiciels complexes est de séparer ces préoccupations afin de les traiter indépendamment. Une manière de séparer ces préoccupations est de modulariser le système à l’aide de différentes abstractions (procédures, modules, objets, composants, aspects, etc.). Il est possible de pousser plus loin la séparation des préoccupations en séparant non seulement les artefacts de conception et de développement mais également les langages utilisés pour décrire ces artefacts. Les langages dédiés se concentrent sur une préoccupation donnée et cherchent à faciliter l’expression de solutions aux experts de cette préoccupation. Un langage dédié est donc un langage conçu spécifiquement pour répondre à une préoccupation, pour aborder un domaine donné. La définition même de domaine étant lâche, il n’existe pas de limite claire entre les langages dédiés d’une part et les langages généralistes d’autre part 2 3. Cependant, il est possible d’énoncer des caractéristiques des langages dédiés généralement admises :
– les langages dédiés cherchent à capitaliser le savoir et le savoir-faire d’un domaine ;
– les langages dédiés fournissent généralement un nombre réduit de concepts ;
– les langages dédiés permettent d’exprimer des solutions au niveau d’abstraction du domaine.
Ces caractéristiques sont à la fois la source de bénéfices et de désavantages pour les concepteurs et les utilisateurs de langages dédiés [vDKV00, MHS05]. En capitalisant le savoir d’un domaine au sein des concepts dédiés, les langages dédiés en facilitent la réutilisation, ainsi que la capitalisation du savoir-faire du domaine au travers d’outils spécialisés. Les langages dédiés offrent de plus des possibilités d’analyse, de vérification et d’optimisation spécifiques aux domaines. En effet, les solutions exprimées à l’aide de langages généralistes peuvent impliquer des motifs complexes, qui peuvent impliquer des analyses sémantiques poussées et dont il est plus difficile d’extraire les informations nécessaires à des outils d’analyse, de vérification ou d’optimisation, alors que ces informations sont par définition directement présentes dans les mograms d’un langage dédié. La taille réduite du langage et la possibilité d’exprimer des solutions à un niveau d’abstraction approprié facilitent l’accès aux langages dédiés. En effet, le langage possède un nombre réduit de concepts, qui sont de plus familiers aux experts du domaine, ce qui facilite l’apprentissage. De plus, ces experts peuvent exprimer à l’aide d’un langage dédié des solutions d’une manière qui leur est plus naturelle, car plus proche de leur domaine d’expertise. L’expressivité des langages dédiés permet en effet d’exprimer les mêmes solutions qu’avec un langage généraliste, mais souvent d’une manière plus simple et plus concise. De plus, les concepts utilisés sont moins génériques et donc plus parlants (au moins pour les experts du domaine), ce qui participe directement à la documentation du mogram. À l’inverse, les langages dédiés présentent plusieurs désavantages, directement liés à leur spécificité. Alors que le développement de quelques langages généralistes s’adressant à un très grand nombre d’utilisateurs justifie des efforts importants de définition et d’outillage, il est difficile de fournir le même effort dans le cadre de langages dédiés, qui par définition s’adressent à un nombre d’utilisateurs restreint. Les coûts de spécification, d’outillage et de maintenance d’un langage dédié sont d’autant plus importants à cause de la faible disponibilité des langages dédiés, destinés à un usage restreint, voire confidentiel. En effet, cette confidentialité rend la réutilisation de tout ou partie des langages dédiés existants difficile. La formation des utilisateurs à un nouveau langage a également un coût, qui peut être multiplié par le nombre de langages dédiés mis en œuvre. Selon le niveau d’expertise des utilisateurs dans le domaine ciblé par le langage dédié, l’apprentissage peut être plus ou moins coûteux. Enfin, un langage dédié peut entraîner une perte de performance par rapport à des langages généralistes donnant la possibilité à l’utilisateur de manipuler des informations de « bas niveau » (e.g., mémoire ou parallélisation). Le choix d’utiliser un langage dédié ou un langage généraliste dépendra donc de plusieurs facteurs : l’expérience des utilisateurs dans des langages généralistes et dans le domaine ciblé par le langage dédié, des possibilités ouvertes par le langage dédié (e.g., nouvelles optimisations) et du coût de conception et d’outillage du langage dédié. Afin de faire basculer ce compromis en faveur des langages dédiés, l’ingénierie des langages logiciels cherche à offrir des solutions facilitant la définition et l’outillage de langages. En effet, l’expertise des utilisateurs et les possibilités ouvertes par un langage dédié sont spécifiques à chaque cas d’utilisation, il n’est donc pas possible de fournir des solutions génériques permettant de diminuer les coûts qui en découlent. À l’inverse, il est possible d’offrir des méthodes et des outils qui facilitent la définition et l’outillage des langages logiciels de manière générale.
Sémantique d’un langage logiciel
La sémantique d’un langage définit la signification des différentes constructions du langage et donne ainsi un sens aux mograms de ce langage. Selon ses usages, la sémantique peut être spécifiée de manière complète et non-ambigüe, ou de manière moins précise. Si les mograms du langage doivent être interprétés ou manipulés par une machine, la sémantique du langage doit être complète et non-ambigüe. Par exemple, un langage exécutable (e.g., un langage de programmation) doit posséder une sémantique exécutable qui donne un unique sens à chaque mogram du langage. Elle doit donc être exprimée de manière complète (elle doit définir une signification pour chaque construction du langage) et non-ambigüe (une construction du langage ne peut pas avoir plusieurs significations possibles). Si les mograms du langage sont interprétés et manipulés uniquement par des humains, les contraintes peuvent être moins importantes. Par exemple, la sémantique d’un langage de description graphique, sans outillage informatique, peut rester informelle (e.g., sous la forme de langage naturel). Elle peut être exprimée de manière complète et non-ambigüe à l’aide de langages ou de formalismes appropriés mais elle peut également être exprimée de manière moins précise. La sémantique d’un langage est définie grâce à un ou plusieurs domaines sémantiques et à des mappings entre les concepts de la syntaxe abstraite ou d’une syntaxe concrète et les concepts du domaine sémantique. La sémantique d’un langage peut être exprimée dans différents domaines sémantiques (e.g., la sémantique opérationnelle structurelle [Plo81], la logique de Hoare [Hoa69], le langage naturel, d’autres langages logiciels, etc.). Il n’est pas rare qu’un langage logiciel possède plusieurs domaines sémantiques, et donc plusieurs mappings vers ces domaines sémantiques. Par exemple, la sémantique du langage C est à la fois exprimée en langage naturel et dans différents jeux d’instructions de différents processeurs. Dans le cas où le domaine sémantique est le langage naturel, le mapping est exprimé au travers de la norme ISO/IEC 9899 :2011 [ISO11a]. Dans le cas où les domaines sémantiques sont les jeux d’instructions de processeurs, le mapping est exprimé par les différents compilateurs qui génèrent les instructions du processeur. Il se pose alors la question de la cohérence entre ces différentes sémantiques, qui, si elle est un problème important, n’est pas abordée dans cette thèse. La sémantique d’un graphe de flot de contrôle peut, par exemple, être implémentée par un générateur de code assembleur qui génère pour chaque instruction d’un bloc les instructions correspondantes en assembleur et qui génère un saut pour chaque arc. Dans ce cas le domaine sémantique est le langage assembleur, et le mapping est exprimé à travers le générateur de code.
D’un « artisanat » à une ingénierie des langages logiciels
Cette augmentation du nombre de langages logiciels amène une nécessité de passer d’un « artisanat » de la définition et de l’outillage des langages logiciels, pratiqué par quelques spécialistes des langages, à une approche systématique pour le développement de langages logiciels outillés, utilisable par un grand nombre d’utilisateurs d’un autre domaine d’expertise. Il est donc nécessaire de proposer de nouveaux outils et méthodes pour le développement des langages logiciels et de mettre à portée des experts métier les outils existants (i.e., qui ne sont pas spécialistes de la définition et de l’outillage des langages). Certains de ces outils et méthodes existent et sont utilisés depuis longtemps déjà. Par exemple, les générateurs d’analyseurs lexicaux et syntaxiques tels que Lex, YACC et Antlr permettent l’outillage automatique des langages logiciels définis à partir des métalangages BNF et EBNF. Cependant, maîtriser ces outils, pourtant bien établis, nécessite un effort qui n’est généralement pas à la portée des experts métier. L’ingénierie des langages logiciels s’intéresse donc aux approches systématiques de gestion du cycle de vie des langages logiciels (de la conception et de la mise en œuvre à l’utilisation et l’évolution). De telles approches, mesurées et automatisées, permettent de diminuer les coûts de spécification, d’implémentation et de maintenance d’un nouveau langage logiciel. De plus, l’automatisation peut rendre accessible la définition et l’outillage de langages aux experts métiers (i.e., aux non-informaticiens ou aux informaticiens ayant développé une expertise dans un autre domaine que celui de la spécification ou l’implémentation de langages logiciels). Ainsi, ces experts métier sont non seulement capables de manipuler des langages proches de leur domaine d’application, mais également de participer à la création même de ces langages. Ce besoin de faciliter la définition et l’outillage des langages logiciels a conduit à la création d’environnements de développement de langages (language workbenches en anglais) [Mar05]. Les environnements de développement de langages fournissent aux concepteurs de langages logiciels des (méta)langages et des (méta-)outils afin de rendre la création de langages logiciels plus facile. CENTAUR [CIK90] est probablement l’un des premiers environnements de développement de langages créés. Les approches plus récentes incluent l’Eclipse Modeling Framework [SBPM09] et les outils de son écosystème (e.g., Xtext, EMFText, Xtend 8 , Kermeta , ATL 10), MetaEdit+ [TR03], Monticore [GKR+08], Spoofax [KV10] et MPS [Voe11]. Ces environnements de développement de langages permettent généralement de ne spécifier que la syntaxe abstraite ou la syntaxe concrète, pour ensuite générer l’autre syntaxe et le mapping entre elles (e.g., un analyseur syntaxique). Ils proposent également de générer des outils tels que des éditeurs évolués (e.g., avec auto-complétion et coloration syntaxique). Malgré les facilités offertes par les environnements de développement de langages, la définition et l’outillage d’un langage logiciel restent des tâches longues et coûteuses. En effet, si la spécification de la syntaxe abstraite, de la syntaxe concrète et de leur mapping bénéficient des facilités offertes par les métalangages et outils, ce n’est généralement pas le cas de l’expression de la sémantique d’un langage logiciel. Définir un compilateur, un interpréteur ou un vérificateur demande une connaissance approfondie du domaine du langage. Ceci rend l’automatisation de telles tâches complexe, et laisse cette charge aux mains du concepteur du langage. C’est pourquoi de nouvelles facilités d’ingénierie développées au sein de l’ingénierie des langages logiciels permettraient de diminuer les coûts de définition et d’outillage des langages logiciels, et particulièrement de faciliter l’apparition de langages dédiés.
|
Table des matières
1 Introduction générale
1.1 Langages dédiés
1.2 Besoin de facilités d’ingénierie pour les langages de modélisation dédiés
1.3 Contributions
1.4 Plan
I Ingénierie des langages dédiés
2 Ingénierie des langages logiciels
2.1 Langages logiciels
2.1.1 Qu’est-ce-qu’un langage logiciel
2.1.2 « Phrases », « énoncés », ou mograms
2.1.3 Langages généralistes et langages dédiés
2.2 Spécification d’un langage logiciel
2.2.1 Syntaxes d’un langage logiciel
2.2.2 Sémantique d’un langage logiciel
2.2.3 Validité d’un mogram par rapport à la spécification d’un langage
2.2.4 Métalangages et méta-outils
2.3 Multiplication des langages logiciels et ingénierie des langages logiciels
2.3.1 Multiplication des langages logiciels
2.3.2 D’un « artisanat » à une ingénierie des langages logiciels
2.4 Conclusion
3 Définition de langages de modélisation dédiés
3.1 Spécification de langages de modélisation dédiés
3.1.1 Métamodèle
3.1.2 Syntaxe abstraite des langages de modélisation dédiés
3.1.3 Outillage des langages de modélisation dédiés : transformations de modèles
3.2 Relation de conformité
3.2.1 La relation de conformité dans la littérature
3.2.2 La relation de conformité dans les standards de facto
3.2.3 Définition de la relation de conformité
3.2.4 Limites de la relation de conformité
3.3 Facilités d’ingénierie pour les langages de modélisation dédiés
3.3.1 Modélisation in-the-large
3.3.2 Réutilisation de transformations de modèles
3.3.3 Limites des approches existantes
3.4 Conclusion
4 Typage de modèles
4.1 Principes de base du typage objet
4.1.1 Objets
4.1.2 Types objets
4.1.3 Classes
4.1.4 Interface et implémentation
4.2 Réutilisation : polymorphisme et héritage
4.2.1 Polymorphisme de sous-type : relations de sous-typage
4.2.2 Héritage
4.2.3 Sous-typage < Héritage
4.2.4 Polymorphisme paramétrique : paramètres de types et variables de types
4.3 Polymorphisme de groupe de types et spécialisations de groupe de classes
4.3.1 Limites du sous-typage objet pour les groupes de types
4.3.2 Types chemin-dépendants
4.3.3 Spécialisation de groupes de classes
4.3.4 Correspondance entre types objets
4.4 Typage de modèles
4.4.1 Types de modèles
4.4.2 Relation de sous-typage entre types de modèles
4.4.3 Extension aux hétérogénéités structurelles
4.5 Limites actuelles du typage de modèles
4.5.1 Définition du typage de modèles
4.5.2 Correspondances illégales
4.5.3 Conclusion
II Facilités de typage pour l’ingénierie des langages
5 Présentation de l’approche
5.1 Limites des approches de métamodélisation actuelles
5.1.1 Relation de conformité
5.1.2 Facilités d’ingénierie
5.1.3 Typage de modèles
5.2 metal : un métalangage supportant une famille de systèmes de types orientésmodèle
5.2.1 Séparation des interfaces et des implémentations
5.2.2 Séparation des modélisations in-the-small et in-the-large
5.2.3 metal : un meta ´ langage pour la modélisation in-the-large
5.2.4 Une famille de systèmes de types orientés-modèle
6 Réification de concepts pour la modélisation in-the-large
6.1 Modélisation in-the-small
6.1.1 metal, MOF et Ecore
6.1.2 Types objets
6.1.3 Types chemins-dépendants
6.1.4 Classes et type exact
6.1.5 Autres types d’éléments de modèles : types de « valeurs »
6.2 Modélisation in-the-large
6.2.1 Relations entre modèles : champs et opérations de modèles
6.2.2 Types de modèles
6.2.3 Métamodèles
6.2.4 Représentation des types de modèles et métamodèles
6.3 Relation de typage de modèle
6.4 Conclusion
7 Relations entre langages : sous-typage et héritage
7.1 Relations de sous-typage entre types de modèles
7.1.1 Correspondance de types objets
7.1.2 Correspondance de signatures d’opérations
7.1.3 Correspondance de champs
7.1.4 Correspondance de champs et de signatures d’opérations de modèles
7.1.5 Correspondance de classes et instanciation
7.1.6 Classification des relations de sous-typage de types de modèles
7.1.7 Définition de quatre relations de sous-typage entre types de modèles
7.1.8 Syntaxe abstraite de metal pour les relations de sous-typage entre types de modèles
7.2 Relation d’héritage entre métamodèles
7.2.1 Héritage, extension et redéfinition
7.2.2 Héritage de champs de modèles
7.2.3 Héritage d’opérations de modèles
7.2.4 Héritage de classes
7.2.5 Héritage non-isomorphique, héritage partiel
7.2.6 Héritage entre métamodèles et types chemin-dépendants
7.2.7 Syntaxe abstraite de metal pour les relations d’héritage entre métamodèles
7.3 Conception d’un système de types orienté-modèle
7.3.1 Déclaration des relations de sous-typage entre types de modèles
7.3.2 Vérification des relations de sous-typage entre types de modèles
7.3.3 Une famille de systèmes de types orientés-modèle
7.4 Conclusion
III Implémentation et Validation
8 Implémentation d’un système de types orienté-modèle dans Kermeta
8.1 Présentation de Kermeta
8.1.1 Définition d’un langage de modélisation dédié au sein de l’environnement Kermeta
8.1.2 Composition des différentes préoccupations
8.1.3 Compilation de la composition
8.2 Présentation du système de types implémenté
8.3 Syntaxe abstraite
8.4 Syntaxe concrète
8.4.1 Métamodèles et types de modèles
8.4.2 Types chemins-dépendants
8.4.3 Opérations et champs de modèles
8.4.4 Relation de sous-typage et d’héritage
8.5 Sémantique
8.5.1 Modifications apportées au front-end du compilateur Kermeta
8.5.2 Modifications apportées au back-end du compilateur Kermeta : Sémantique translationnelle en Scala
8.6 Conclusion
9 Application au passage en forme Static Single Assignment
9.1 Présentation de la forme Static Single Assignment
9.2 Calcul de la frontière de dominance
9.3 Insertion de φ-fonctions et renommage de variables
9.4 Réutilisation du passage en forme Static Single Assignment
9.5 Adaptations pour GeCoS
9.5.1 Graphes de flot de contrôle dans GeCoS
9.5.2 Adaptations entre GeCoS IR et SSA_Form
9.6 Conclusion
IV Conclusion et perspectives
10 Conclusion et perspectives
10.1 Conclusion
10.2 Perspectives
10.2.1 « Fonctions de modèles »
10.2.2 Opérateurs d’adaptation
10.2.3 Application du typage de modèles à d’autres espaces technologiques
10.2.4 Extension des types de modèles
10.2.5 Évaluation expérimentale
Bibliographie
Télécharger le rapport complet
