Langages dédiés
Le nombre et la complexité toujours croissants des préoccupations prises en compte dans les systèmes logiciels complexes (e.g., sécurité, IHM, scalabilité, préoccupations du domaine d’application) poussent les concepteurs de tels systèmes à séparer ces préoccupations afin de les traiter de manière indépendante. Par exemple, la compilation optimisante utilise différentes représentations intermédiaires d’un programme (e.g., graphe de flot de contrôle, forme Static Single Assignment, représentation polyédrique), chacune de ces représentations étant dédiée à une préoccupation d’analyses ou d’optimisation (e.g., propagation de constante, élimination de code mort, parallélisation). Les langages dédiés permettent de manipuler les concepts spécifiques à une préoccupation particulière tout en s’affranchissant de la complexité liée à l’apprentissage et l’utilisation de langages généralistes tels que Java ou C++.
L’ingénierie dirigée par les modèles s’appuie sur les concepts de l’orienté-objet pour modéliser et outiller des langages dédiés, permettant aux experts de séparer les différentes préoccupations métiers sur un même système en autant de langages dits de modélisation dédiés [JCV12]. Un langage de modélisation dédié est constitué d’une syntaxe abstraite, d’une syntaxe concrète et d’une sémantique. En ingénierie dirigée par les modèles, la syntaxe abstraite est généralement définie sous la forme d’un ensemble de classes et une « phrase » issue du langage est un ensemble d’objets, instances de ces classes (un modèle). La syntaxe concrète et la sémantique d’un langage de modélisation dédié sont implémentées par des transformations de modèles qui vont afficher, interpréter ou compiler les modèles.
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.
Contributions
Dans les langages orientés-objet, l’abstraction et la réutilisation sont notamment fournies par le système de types et les mécanismes de sous-typage et d’héritage. Cette thèse se fonde sur des travaux préliminaires abordant le typage de modèles [SJ07, LG13] pour fournir la définition d’une famille de systèmes de types orientés-modèle. Cette définition est un socle formel permettant d’implémenter un système de types orienté-modèle supportant diverses facilités de typage au sein d’un environnement de développement de langages de modélisation dédiés. Dans ce but nous définissons :
– Une relation de typage entre les modèles et les langages de modélisation dédiés au travers des types de modèles. Les types de modèles exposent les éléments de modèles et les transformations de modèles associés à un langage de modélisation dédié et permettent de considérer les modèles comme des entités de première classe.
– Des relations de sous-typage et d’héritage entre langages de modélisation dédiés permettant la réutilisation de la structure (i.e., de la syntaxe abstraite) et du comportement (i.e., des transformations de modèles) de ces langages.
Ingénierie des langages dédiés
Ingénierie des langages logiciels
Les systèmes logiciels croissent en complexité et en taille, et leurs concepteurs doivent prendre de plus en plus de préoccupations différentes en compte : sécurité, IHM, scalabilité, interopérabilité, portabilité, mais également préoccupations des domaines d’applications de plus en plus nombreux (calcul scientifique, avionique, génomique, domotique, etc.). Afin de faire face à la complexité et au nombre toujours croissants de ces préoccupations, les concepteurs de logiciels complexes cherchent à les séparer pour les traiter indépendamment [DK75, Mit90]. Une façon de traiter séparément les différentes préoccupations dans la conception d’un système logiciel est d’utiliser un langage dédié à chacune d’elle. Cette approche permet aux concepteurs de se concentrer sur une préoccupation, sur un domaine, et d’aborder les problèmes à l’aide d’un langage proche de ce domaine. Cependant l’utilisation de plusieurs langages dédiés plutôt que celle d’un langage généraliste amène une multiplication des langages logiciels, i.e., des langages artificiels impliqués dans le développement logiciel.
Langages logiciels
Le terme langage logiciel englobe tous les langages artificiels impliqués dans le développement de systèmes logiciels. Les « phrases » issues de ces langages sont utilisées pour décrire, spécifier, implémenter ou manipuler des systèmes logiciels. Dans cette première section, nous présentons le concept de langages logiciels ainsi que celui de mogram (i.e., « phrase ») issu d’un langage logiciel.
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 ) ; 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]).
« Phrases », « énoncés », ou mograms
Si les termes « phrases » et « énoncés » sont appropriés pour désigner les éléments de langages naturels, ils peuvent sembler moins intuitifs lorsqu’il s’agit de désigner d’une manière générale les éléments de langages logiciels, qui incluent non seulement des langages textuels, mais aussi des langages graphiques (comme UML). Les termes « programme », « modèle », « diagramme », « requête » ou « document », qui sont habituellement employés dans le cadre de certains langages logiciels sont inadéquats à désigner les éléments de l’ensemble des langages logiciels. Il semble en effet difficile de parler d’un programme XML ou d’un modèle Java. Enfin le terme « élément » est trop large et peut prêter à confusion dans certains contextes (en particulier dans celui de l’ingénierie dirigée par les modèles où il est employé pour désigner les éléments de modèles). C’est pourquoi nous utiliserons pour désigner les éléments d’un langage logiciel le mot-valise mogram, contraction de modèle et de programme, proposé par Kleppe [Kle08, Chap. 3].
|
Table des matières
INTRODUCTION
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
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
CONCLUSION
