pour une taxonomie complète). Les langages de transformation de modèles sont encore à l’état de recherche et les transformations sont encore peu utilisées à l’échelle industrielle. On distingue actuellement deux grandes approches : (i) les approches à base de règles (la majorité) et (ii) les approches opérationnelles. métamodèles sources métamodèles sources métamodèles cibles métamodèles cibles métamodèle de langage de transformation métamodèle de langage de transformation modèles sources modèles cibles « conforme à » « conforme à » Transformation de modèles
Figure 14 - Schématisation d'une transformation de modèles.
Dans une approche à base de règles (Tefkat [140], ATL [141], SmartQVT43 [143], EML [144]), une transformation spécifie un ensemble de relations liant des fragments de modèles d’entrée à des fragments de modèles de sortie. Dans ce contexte, une règle est composée de deux parties : un motif et une production. Le motif spécifie les fragments de modèles sur lesquels la règle s’applique. La production spécifie les fragments produits lorsque la règle s’applique. Le code de la production est fonction des éléments du motif. Les approches à base de règles diffèrent suivant des critères tels que l’ordonnancement des règles (implicite, ordre total ou partiel) et la nature du code (déclaratif, impératif, hybride). L’approche opérationnelle (par exemple, Kermeta [145-146]) considère une transformation comme un ensemble d’actions définies directement au sein du métamodèle source. C’est une approche orientée objet, où le code de la transformation est structuré en fonction des éléments du métamodèle : chaque métaclasse est munie d’un ensemble d’opérations instanciées pour chacune de ses instances.
3.2 Spécification par transformation de modèles de la sémantique d’un
langage
La sémantique d'un langage consiste en une relation sémantique entre une syntaxe abstraite et un domaine. Dans cette section, nous présentons les deux approches possibles pour décrire la sémantique d’un langage dans le cadre conceptuel de l’IDM. La première consiste en l’implémentation d’une transformation de la syntaxe abstraite du langage (un métamodèle) vers la syntaxe abstraite d’un langage formel où la sémantique dynamique est déjà implémentée par un outil (section 3.2.1). Dans ce cas, on réutilise un formalisme. La deuxième approche consiste en une implémentation de la sémantique dynamique au niveau de la syntaxe abstraite du langage (section 3.2.2).
3.2.1 Homéomorphisme
43 SmartQVT est une implémentation de la norme QVT [142] (Query View Transformation) de l’OMG. Cette norme constitue un premier pas vers une uniformisation des approches à base de règles incluant trois langages complémentaires (comprenant des constructions déclaratives et impératives).
L’approche par homéomorphisme consiste en la spécification d’une transformation de modèles entre le métamodèle représentant le langage et un métamodèle représentany son domaine. Cette approche permet de réutiliser la sémantique d’un langage déjà existant (le domaine), ce qui correspond à la définition d’un langage donnée en section 1. Dans la littérature, ce type de transformation est parfois appelé projection, morphisme ou encore transformation homéomorphe [47, 116]44. Elle est par exemple utilisé dans le cadre du projet PUML [147] visant à munir UML [50] d’une sémantique formelle définie sur le formalisme Z [128]. Il est alors possible de profiter conjointement de la syntaxe accessible de UML et des outils d’analyses formelles associés à Z. Les outils de vérification présentés en section 3.2.3 du Chapitre I implémentent aussi des homéomorphismes, réalisés de manière ad-hoc.
Les langages à base de règles sont les plus indiqués dans ce cas. Cette approche nécessite généralement la spécification d’un programme transformant une instance du métamodèle du domaine en un texte sémantiquement équivalent45. Ce texte est ensuite fourni à un outil implémentant la sémantique du domaine. Ce programme n’est pas nécessaire si l’outil a été implémenté en suivant une approche dirigée par les modèles. Dans ce cas, l’outil accepte directement le modèle du domaine produit par la transformation homéomorphe. La Figure 15 schématise les deux possibilités d’implémentation d’un homéomorphisme, suivant que l’outil réutilisé est implémenté avec des technologies IDM ou non.
métamodèle du langage métamodèle du langage métamodèle du domaine métamodèle du domaine métamodèle du domaine métamodèle du domaine formalisme non IDM formalisme IDM métamodèle du langage métamodèle du langage homéomorphisme sémantique opérationnelle pretty printer parser
Figure 15 – Schématisation d’une spécification de la sémantique dynamique d’un langage par transformation homéomorphe.
3.2.2 Sémantique opérationnelle embarquée
La deuxième approche consiste en la spécification d’une sémantique opérationnelle au niveau du métamodèle du langage. Une sémantique opérationnelle est décrite par un ensemble d’opérations manipulant les concepts du métamodèle du langage. Ces opérations sont spécifiées à l’aide d’un langage d’action comme Kermeta [146]. Dans ce cas, le métamodèle du langage représente à la fois la syntaxe abstraite et le domaine sémantique du langage46 (syntaxe et domaine se confondent). Cette approche est indiquée pour décrire la sémantique d’un formalisme (comme par exemple la sémantique du formalisme IDM de la Figure 15). La suite de cette section présente brièvement Kermeta et illustre la spécification d’une sémantique opérationnelle avec ce langage.
Définition – sémantique opérationnelle : sémantique dynamique exécutable, décrite par un
ensemble d’opérations associées aux métaclasses du métamodèle. Tout modèle conforme à un métamodèle muni d'une sémantique opérationnelle est exécutable.
Le langage d’action Kermeta [145] est une extension d’une version simplifiée de EMOF47. Kermeta permet ainsi de spécifier la sémantique opérationnelle de métamodèles conformes à EMOF.
44 Mathématiquement, un homéomorphisme conserve la structure de l’information suivant les lois des langages vu comme des groupes (en particulier les lois de composition).
45 Ce type de programme est appelée « pretty printer » en compilation (fonction inverse du « parsing »).
46 La fonction sémantique est dans ce cas l’identité, c’est-à-dire que tout modèle est l’image de lui-même pas la fonction sémantique.
47
Le langage d’action est impératif, orienté objet et a été spécialement conçu pour intégrer un processus de développement dirigé par les modèles. Il fournit les constructions classiques d’un langage de programmation orienté objet (encapsulation, héritage …) et des constructions dédiées à la manipulation de modèles (constructions « à la OCL » comme la navigation, les opérations sur les collections telles select ou collect). Le langage d’action de Kermeta est particulièrement adapté aux activités de métamodélisation comme la spécification des langages de modélisation, la simulation et prototypage de métamodèle.
La Figure 16 fournit (a) un métamodèle possible de machine à état et (b) le même métamodèle muni d’une sémantique opérationnelle de simulation (ajout d’opérations et de relations). Ces opérations sont embarquées dans les différents concepts du métamodèle (par exemple fire() dans la métaclasse TRANSITION). L’association currentState entre les concepts FSM et STATE a été ajoutée pour maintenir en mémoire l’état courant d’une machine à état en cours de simulation. La Figure 17 fournit une implémentation en Kermeta de l’opération step embarquée par le concept STATE (cf. Figure 16). La spécification informelle de cette action est donnée ci-dessous :
- L’action step ne peut être appelée que sur l’état courant (voir la pré-condition).
- Si un évènement entrant satisfait l’événement d’entrée d’une transition de l’état courant, alors la transition est tirée et l’état courant mis à jour (soit la redirection du lien instance de
currentState vers la cible TRANSITION.target de la transition tirée).
- Si plusieurs transitions sont satisfaites, la machine à état est indéterministe et une exception est levée.
(a)
(b)
Figure 16 - Un métamodèle possible d'une machine à état (a) et le même métamodèle muni d’une sémantique opérationnelle embarquée de simulation (b).
operation step(c : String) : String pre owningFsm.currentState == self
var validTransitions : Collection<Transition>
validTransitions := outgoingTransition.select{t|t.input.equals(c)} if validTransitions.size > 1 then raise NonDeterminism.new end result := validTransitions.one.fire end
operation step(c : String) : String pre owningFsm.currentState == self
var validTransitions : Collection<Transition>
validTransitions := outgoingTransition.select{t|t.input.equals(c)} if validTransitions.size > 1 then raise NonDeterminism.new end result := validTransitions.one.fire end
Figure 17 - Code Kermeta pour l'action « step ».
Cette approche a plusieurs avantages. Tout modèle conforme au métamodèle de la Figure 16 (b) est exécutable par construction. Pour le modeleur (celui qui crée des machines à états dans l’exemple de la Figure 16), c’est un mécanisme intéressant pour la vérification des modèles, puisqu’un modèle ne se comportant pas correctement n’est pas valide structurellement (sauf erreur au niveau de la spécification de la sémantique opérationnelle). Pour le métamodeleur (celui qui conçoit la sémantique
opérationnelle), l’exécutabilité facilite la validation de la sémantique opérationnelle définie au niveau du métamodèle. Cependant, il est important de noter qu’une sémantique opérationnelle n’est pas toujours facile à spécifier de cette manière. Cela dépend de ce qui est représenté par le métamodèle. Lorsque le langage représenté est un formalisme, une sémantique opérationnelle est facile à définir comme une composition des concepts de sa syntaxe abstraite. Dans le cas contraire, il est plus intéressant de définir un homéomorphisme vers un métamodèle de la syntaxe abstraite du domaine (première approche), quitte à munir celui-ci dans un deuxième temps d’une sémantique opérationnelle.
4 Composition de modèles
La composition de modèles [40-46, 78] est un problème général, utile à un grand nombre de domaines informatiques. C’est une étape nécessaire si l’on désire analyser automatiquement une spécification décrite à l’aide d’une collection de spécifications partielles48. C’est en outre une technique supérieure aux approches de comparaison en ce qui concerne la détection d’incohérences [40]. La composition de modèles revêt plusieurs appellations, suivant le domaine en question et la nature de ce qui est composé : composition de points de vue, de vues, de spécifications partielles, intégration de vues, fusion, amalgamation ou encore tissage d'aspects. Nous préférerons dans la suite l'appellation composition de modèles, cette dernière étant plus générale car ne faisant aucune hypothèse sur ce qui est composé.
La section 4.1 introduit les principes généraux d'un processus de composition de spécifications partielles hétérogènes. Elle présente un processus de composition comme une transformation de modèles et définit un cadre conceptuel IDM pour la composition. La section 4.2 présente les travaux clés sur la composition de modèles dans les domaines de l'ingénierie des exigences et le domaine du développement logiciel par aspect (AOSD). Ces travaux sont décrits avec la terminologie proposée en sections 1 et 2, bien que la plupart ne soient pas construits avec des technologies IDM. Cette section n’offre pas une rétrospective complète. Néanmoins, les travaux présentés couvrent un large spectre et sont représentatifs des travaux plus anciens.