4.5 Limites actuelles du typage de modèles
4.5.2 Correspondances illégales
Dans la définition4.4, Steel et al. autorisent les multiplicités à être restreintes du super- type de modèles au sous-type de modèles. La figure4.5présente deux classes InfiniteNode et FiniteNode telles que FiniteNode <# InfiniteNode. Cependant la substitution d’objets instances de InfiniteNode par des objets instances de FiniteNode n’est pas sûre. En effet une transformation de modèles écrite par rapport à la classe InfiniteNode peut modifier le champ edges en en enlevant tous les éléments ou en ajoutant plus de cinq éléments. Ces deux manipulations sont légales et ne causent pas d’erreurs sur une instance de InfiniteNode. Ce- pendant sur une instance de FiniteNode, ces deux manipulations provoqueraient des erreurs à l’exécution. La première en provoquant un underflow (moins d’éléments que nécessaire), la seconde un overflow (trop d’éléments).
De plus, la relation de correspondance ne prend pas en compte les champs obligatoires (mandatory en anglais) de la classe "correspondante" (e.g., FiniteNode) si ils n’apparaissent pas dans la classe "correspondue" (e.g., InfiniteNode). Une transformation de modèles écrite par rapport à la classe InfiniteNode pourrait chercher à instancier un nouvel objet. Cependant si la classe réelle est FiniteNode et non InfiniteNode, le champ name ne sera pas initialisé et l’objet obtenu ne sera pas conforme à sa classe (la classe FiniteNode exige que le champ name ne soit pas vide).
La définition relâchée proposée par Moha et al. (définition4.6) pose un autre problème : en autorisant la correspondance au niveau des sous-classes, les transformations de modèles ne sont pas garanties de trouver certains champs. La figure4.6présente deux classes RGBColoredNo- deet ColoredNode telless que ColoredNode <# RGBColoredNode. Cette correspondance est autorisée car la sous-classe SpecificColor de la classe Color correspond à la classe RGBColor. Cependant une transformation de modèles cherchant à accéder au champ red de l’objet ré-
66 Typage de modèles
1 class RGBColoredNode {
2 field color : RGBColor
3 [...]
4 }
5
6 class RGBColor {
7 field name : String
8 field red : Integer
9 field green : Integer
10 field blue : Integer
11 }
1 class ColoredNode {
2 field color : Color
3 [...]
4 }
5
6 class Color {
7 field name : String
8 }
9
10 class SpecificColor extends Color {
11 field red : Integer
12 field green : Integer
13 field blue : Integer
14 }
Figure 4.6 – Deux classes RGBColoredNode et ColoredNode telles que ColoredNode <# RGBColoredNoded’après la définition4.6.
férencé par le champ color n’est pas garantie de trouver ce champ. Si color pointe sur une instance de Color et non une instance de SpecificColor, le code .color.red causera une erreur à l’exécution.
4.5.3 Conclusion
Le typage de modèles offre à l’ingénierie dirigée par les modèles certaines facilités fournies par les systèmes de types dans les langages de programmation orientés-objet. Cependant, certaines limites subsistent afin d’offrir le niveau de flexibilité et de sécurité que l’on peut trouver dans les langages orientés-objet tels que Java ou Scala. Notamment, la séparation de l’interface à travers laquelle un modèle est manipulable et de l’implémentation à partir de laquelle il est créé, et la séparation de la modélisation in-the-small et de la modélisation in-the-largene sont pas prises en compte.
C’est pourquoi, dans la suite de cette thèse, nous proposons une clarification et une exten- sion des types de modèles, ainsi que des relations de typage de modèles et de sous-typage entre types de modèles. Ces extensions prennent en compte la séparation de l’interface et de l’implémentation d’un langage de modélisation dédié au travers des types de modèles d’une part et des métamodèles de l’autre, et la séparation de la modélisation in-the-small et de la modélisation in-the-large.
Notre relation de typage offre un socle pour de nombreuses facilités d’ingénierie, supportées par plusieurs relations de sous-typage. Nous proposons de remplacer la relation de conformité, trop contraignante, par cette relation de typage afin de faciliter la définition et l’outillage des langages de modélisation dédiés.
Deuxième partie
Facilités de typage pour l’ingénierie
des langages
Chapitre 5
Présentation de l’approche
Nous proposons de remplacer la relation de conformité, trop contraignante, par une relation de typage des modèles. La relation de typage de modèles, et par extension les types de modèles, fournissent une base sur laquelle il est possible de définir des systèmes de types orientés- modèle, à même de supporter les mêmes facilités que les systèmes de types orientés-objet. Pour pouvoir implémenter de tels systèmes de types au sein d’environnements de développement de langages de modélisation dédiés, il est nécessaire de fournir une base formelle définissant les types de modèles, la relation de typage et les relations entre ces types de modèles.
Ce chapitre commence par motiver le besoin de tels systèmes de types orientés-modèle en rappelant les limites de l’ingénierie dirigée par les modèles et des facilités qu’elle propose (cf. Section5.1). Nous présentons ensuite la contribution de cette thèse : le métalangage me- tal, qui regroupe les concepts et relations nécessaires pour supporter les systèmes de types orientés-modèle (cf. Section5.2). Ce métalangage s’articule autour de deux axes : la sépara- tion de l’interface et de l’implémentation des modèles (cf. Section5.2.1) ; et la séparation de la modélisation in-the-small et de la modélisation in-the-large (cf. Section5.2.2).
5.1 Limites des approches de métamodélisation actuelles
Malgré les avancées de l’ingénierie dirigée par les modèles pour faciliter la définition et l’outillage des langages dédiés (e.g., définition de la syntaxe abstraite sous forme de graphe de classes, outils de génération de syntaxes concrètes et d’analyseurs syntaxiques), les approches de métamodélisation existantes présentent encore certaines limites. La relation de conformité, en limitant un modèle à n’être lié qu’à un métamodèle, est un frein à la réutilisation de la structure et du comportement entre langages de modélisation dédiés. De plus, les différentes facilités proposées jusqu’ici (e.g., facilités de réutilisation de transformations de modèles, ma- nipulation des modèles comme entités de première classe) manquent d’un cadre unificateur permettant de les combiner et de les comparer. Nous pensons que le typage de modèles peut fournir un tel cadre, mais ses premières incarnations souffrent de limites, notamment parce qu’elles s’appuient sur la relation de conformité.5.1.1 Relation de conformité
La relation de conformité, qui lie un modèle à un métamodèle, permet de déterminer si un modèle est un mogram valide d’un langage de modélisation dédié. C’est donc un concept central de l’ingénierie dirigée par les modèles, qui est utilisé comme une relation de typage
70 Présentation de l’approche
pour, par exemple, autoriser ou non le passage d’un modèle à une transformation de modèles, ou le chaînage de transformations de modèles.
Cependant, la relation de conformité s’appuie sur les classes de la syntaxe abstraite d’un langage de modélisation dédié. La relation de conformité dépend donc de l’implémentation des langages de modélisation dédiés, puisqu’elle s’appuie sur la relation d’instanciation entre éléments de modèles (i.e., objets) et classes. Un objet ne peut être instance que d’une classe, qui elle-même n’appartient qu’à un métamodèle. Un modèle étant composé d’objets, la relation de conformité limite un modèle à être lié à un unique métamodèle, qui contient les classes de tous les éléments du modèle. Un modèle n’est donc valide que par rapport à un unique langage de modélisation dédié, qui a permis de le construire. En interdisant à un modèle d’être valide vis-à-vis de plusieurs langages de modélisation dédiés, la relation de conformité empêche toute forme de polymorphisme : un modèle n’a qu’une "forme", celle définie par le métamodèle auquel il se conforme (cf. Section3.2.4).