Présentation de l’IDM

Avant de développer les travaux basés sur l’IDM nous présentons en premier lieu les principes de cette approche du développement informatique : modélisation et métamodélistion, transformation des modèles, modélisation spécifique au domaine (DSM pour Domain-specific Modeling), etc. L’outillage d’Eclipse est également présenté : EMF (Eclipse Modeling Framework), GMF (Graphical Modeling Framework). Cette présentation nous semble importante car c’est l’univers méthodologique et technologique dans le quel nous avons inscrit nos travaux.

L'ingénierie dirigée par les modèles (IDM), en anglais Model Driven Engineering (MDE), est une approche spécifique du génie logiciel qui place le modèle au centre du processus de conception. Elle a pour objectif de définir un cadre théorique pour générer du code en utilisant des combinaisons et des transformations successives de modèles [Caron 2007a]. Ce courant s’est développé suite à la définition de l’approche MDA (Model Driven Architecture) fin 2000 par OMG (Object Management Group) [OMG 2006], en vue de fournir des solutions aux problèmes liés à l’émergence continuelle des technologies logicielles qui oblige les entreprises à migrer⁵ leurs systèmes logiciels à chaque émergence d’une

technologie [Laforcade 2010]. Le but principal de MDA est de séparer les parties métiers de leur mise en œuvre technologique et ainsi de garantir l'interopérabilité des modèles fonctionnels pour différents choix d'implémentation. L’IDM est une approche plus globale et générale que MDA. Cette dernière concerne seulement les technologies OMG principalement, par contre, l'IDM consiste à appliquer les mêmes principes de MDA à tout espace technologique et à les généraliser. En fait, MDA est un processus de type IDM

[Laforcade 2007a].

2.3.2.1.1 Principes d'IDM

Le premier principe est d'utiliser la modélisation et des modèles pour développer des systèmes logiciels. Le deuxième est la séparation entre les fonctionnalités d'un système

5 Une migration, en informatique, est le passage d'un état existant d'un système d'information ou d'une application vers une cible définie dans un projet ou un programme [Wikipédia, consultation en 2012].

d'information d'une entreprise et la mise en œuvre de ces fonctionnalités sur des plateformes technologiques spécifiques (EJB, CORBA, etc.). La spécification abstraite du système est devenu le principal atout dans le développement des logiciels : de nombreuses implémentations utilisant des technologies concrètes peuvent être dérivées de la même spécification abstraite. Cette approche est dite dirigée par les modèles, car elle fournit un moyen facilitant l’utilisation des modèles pour guider la compréhension, la conception, la construction, le déploiement, l'exploitation, la maintenance et la modification d’un système informatique [OMG 2006].

Le processus de développement des logiciels est basé sur des transformations automatiques ou semi-automatiques entre les modèles, à partir des modèles abstraits, centrés domaine métier et généralement informels (CIM : Computation Independent Model) vers des modèles spécifiques à une plateforme (PSM : Platform Specific Model).

En effet, l’IDM est séduisante pour approcher l’ingénierie des EIAH pour deux raisons principales [Choquet 2007] :

elle préconise le développement de modèles productifs, ce qui aide le concepteur à maîtriser les choix de développement et d’implantation,

elle permet de s’inscrire explicitement dans l’univers métier de l’application cible en définissant des langages spécifiques à son domaine.

L'IDM repose sur les principes suivants [Laforcade 2007b] :

i/ Capitalisation : parmi ses avantages on trouve la possibilité de réutilisation et de

capitalisation des modèles et des pratiques (la transformation et les règles de transcription entre les modèles).

ii/ Abstraction : les modèles doivent être indépendants des technologies de mise en œuvre

afin d'adapter la logique métier à différents contextes techniques et de permettre de faire plus facilement évoluer les applications vers de nouvelles technologies.

iii/ Modélisation : la modélisation est abordée selon une vision productive (pour générer le

code final du logiciel pour une technologie de mise en œuvre donnée) par opposition à la traditionnelle vision contemplative (but de documentation, spécification, communication).

iv/ Séparation des préoccupations : l'IDM s'illustre généralement selon les deux

principales préoccupations du métier et de la plate- forme de mise en œuvre mais d'autres préoccupations sont possibles.

2.3.2.1.2 Les niveaux d'abstraction dans IDM

L'IDM est fondée sur une architecture à quatre niveaux [Bezivin et Blanc 2002], initialement proposée dans le cadre du MDA, de concret à abstrait : système (monde réel), modèle, métamodèle et méta-méta-modèle. La figure 13 ci-dessous illustre les niveaux d'abstraction d'IDM.

Figure 13 : Architecture à quatre niveaux [Bezivin et Blanc 2002].

• M3 est le niveau supérieur : le méta-méta-modèle. Il donne les notions de base

permettant l'expression des métamodèles (M2), et des modèles (M1). Il permet d'exprimer les règles de conformités qui lient les entités du niveau M1 à celles du niveau M2. M3 se définit lui-même [Caron 2007a].

• M2 définit le métamodèle. MDA repose par exemple sur un métamodèle principal

UML extensible par des profils. M2 permet de manipuler des modèles pour en préciser le sens et les rendre opérationnalisables, cela en définissant des règles de transformation, de fusion, de composition, ou de tissage des modèles [Caron 2007a]. • Le niveau M1 définit les modèles. Chaque modèle doit être conforme à son

métamodèle selon des règles de conformité définies au niveau du méta-méta-modèle. Un modèle doit être validé formellement pour favoriser son opérationnalisation. C'est cette validation qui distingue l'IDM des méthodes de modélisations antérieures.

Par conséquent, les modèles sont des concepts clés de l'IDM, utilisés tout au long du processus d’ingénierie. L'IDM offre la capacité de « projeter » la connaissance métier exprimée dans les modèles abstraits vers ceux qui sont concrets et dépendants d’une plateforme cible, cela en proposant une automatisation du processus d’ingénierie, par des transformations et des affinements successifs des modèles, jusqu'au code. L’IDM a pour objectif la production et la manipulation de modèles productifs, qui peuvent être opérationnalisés et manipulés par la machine, c’est-à-dire qui peuvent être utilisés pour générer – plus ou moins automatiquement – tout ou partie du code de l’application qu’ils représentent. Ces modèles doivent être conformes à des métamodèles explicites et formels et représenter sans ambiguïté un point de vue sur l’artefact à produire. La relation de « conforme-à » signifie que le modèle est défini formellement par son métamodèle à l’aide du langage associé, et que ce métamodèle est lui-même explicite, donc défini formellement par un méta-métamodèle. Ce même méta-métamodèle définit alors les règles de consistance et de cohérence de la relation « conforme-à » liant un modèle à son métamodèle. La relation de « représente » consiste à faire une simplification [Choquet 2007] [Caron 2007a].

2.3.2.1.3 Les types de modèles

Rappelons que l'IDM consiste à effectuer les différentes transformations des modèles en vue de générer tout ou une partie du code automatiquement. Elle définit trois niveaux de modèles (qui sont initialement proposés par MDA) :

• CIM (Computer Independent Model) : ce modèle comporte les besoins des

utilisateurs recensés à partir du domaine métier ;

• PIM (Platform Independent Model) : ce modèle spécifie la partie métier d'une

application sans utiliser le langage technique ;

• PSM (Platform Specific Model) : ce modèle spécifie l'application sur une plate-forme

technologique donnée.

El-Kechaï [El-Kechaï 2008] relève que certains travaux de la communauté EIAH ont repris cette approche dans le cadre de la scénarisation pédagogique. Le cycle des transformations appliquées aux EIAH est illustré dans la figure 14.

Figure 14 : Cycle de transfor

Toutefois, l’IDM est considérée com

exemple assez naïf de supposer que le métamodèle UML, généraliste, soit le meilleur support à la définition des PIM. C’est pourquoi certains

toujours dans une approche IDM, préfèrent définir leurs modèles à l’aide de langages spécifiques à un domaine (DSML

métamodèle plus simple mais plus ciblé sur le métier des experts du domaine. Notons qu’un domaine est défini par [Czarnecki et Eisenecker 2000]

précisé, afin de maximiser la satisfaction des besoins de ses acteurs, in de concepts et une terminologie compris par les praticiens dans cet espace.

2.3.2.2 Modélisation spécifique au domaine