Ingénierie dirigée par les modèles (IDM)
Due aux progrès technologique, les systèmes logiciels sont devenus de plus en plus complexes. Le développement classique basé sur le code ne parvient pas à faire face à la complexité croissante menant à de plus en plus d’erreurs. L’Ingénierie Dirigée par les Modèles (IDM) (en anglais Model Driven Engineering, abrégé en MDE, parfois Model Driven Development, abrégé en MDD) propose des pistes pour permettre aux organisations de surmonter les exigences du développement de logiciels.
L’IDM se réfère à l’utilisation systématique de modèles comme entités de première classe tout au long du cycle de vie du logiciel. Les approches d’IDM orientent le développement logiciel des langages de programmation de troisième génération à des modèles exprimés dans des langages de modélisation. L’objectif est d’accroître la productivité et de réduire le délai, permettant ainsi le développement des systèmes complexes au moyen de modèles définis avec des concepts qui sont beaucoup moins liés à la technologie d’implémentation sous-jacente et sont beaucoup plus proches du domaine du problème. Cela rend les modèles plus faciles à spécifier, à comprendre et à maintenir . Ceci aide à la compréhension des problèmes complexes et de leurs solutions potentielles par le bais des abstractions.
L’IDM est une forme d’ingénierie générative, par laquelle tout ou une partie d’une application informatique est générée à partir de modèles . Les idées de base de cette approche sont voisines de celles de nombreuses autres approches du génie logiciel, comme la programmation générative, les langages spécifiques de domaines (DSL pour domain-specific language) , le MIC (Model Integrated Computing) qui a été conçu initialement pour le développement de systèmes embarqués
complexes , les usines à logiciels (Software Factories) pour l’industrialisation du développement de logiciels et s’explique par analogie à une chaine de montage industrielle classique (Greenfield et al, 2004), etc. L’IDM est née d’un besoin simple : répondre aux exigences grandissantes du génie logiciel en termes de qualité des systèmes, de portabilité et d’interopérabilité. Pour cela, l’IDM propose comme solution de regrouper des concepts au sein d’abstractions de systèmes : les modèles. Dans cette nouvelle perspective, les modèles doivent en contrepartie être suffisamment précis afin de pouvoir être interprétés ou transformés par des machines. Le processus de développement des systèmes peut alors être vu comme un ensemble de transformations de modèles partiellement ordonné, chaque transformation prenant des modèles en entrée et produisant des modèles en sortie, jusqu’à obtention d’artefacts exécutables. Pour donner aux modèles cette dimension opérationnelle, il est essentiel de décrire de manière précise les langages utilisés pour les représenter. On parle alors de méta-modélisation.
Architecture dirigée par les modèles (MDA)
Le principe du MDA : L’objectif principal d’une approche d’ingénierie dirigée par les modèles est de reporter la complexité d’implémentation d’une application au niveau de sa spécification. Cela devient alors un problème d’abstraction du langage de programmation en utilisant un processus de modélisation abstrait.
L’architecture dirigée par les modèles (MDA) est une démarche de développement à l’initiative de l’OMG (Object Management Group) rendue publique fin 2000. MDA est basée sur les problématiques suivantes :
Spécification d’un système indépendamment de la plateforme sur laquelle ce système doit être déployé, Spécification de plateformes, Définition d’une plateforme pour un système, Transformation des spécifications d’un système en un système associé à une plateforme particulière.
L’idée de base du MDA est de séparer les spécifications fonctionnelles d’un système des spécifications de son implémentation sur une plateforme donnée. Pour cela, le MDA définit une architecture de spécifications structurée en modèles indépendants des plateformes (Platform Independent Models, PIM) et en modèles spécifiques (Platform Specific Models, PSM). L’approche MDA permet de réaliser le même modèle sur plusieurs plateformes grâce à des projections normalisées. Elle permet aux applications d’inter-opérer en reliant leurs modèles et supporte l’évolution des plates-formes et des techniques. La mise en œuvre du MDA est entièrement basée sur les modèles et leurs transformations.
Les niveaux de modélisation
Dans l’architecture MDA, l’OMG définit quatre niveaux d’abstraction où la notion de modèle est utilisée. Entre chaque niveau, la relation « conforme à » s’applique, chaque niveau inférieur est conforme au modèle défini au niveau supérieur. Plusieurs variantes d’un système réel peuvent exister en fonction des valeurs réelles d’implémentation (niveau M0). Pour capturer l’essentiel du système indépendamment des valeurs d’implémentation, les fonctions et l’architecture de ce dernier doivent être modélisées au niveau M1. Le langage de modélisation employé pour définir ce système est classé au niveau M2. Les entités permettant de créer ce nouveau langage doivent être spécifiées au niveau M3. Le MOF est son propre métamodèle. Il est réflexif car il est capable de se décrire à partir de ses propres concepts pour éviter la nécessité d’une infinité de niveaux. En dessous, au niveau M2 chaque métamodèle définit un langage par domaine d’intérêt. On y retrouve par exemple UML qui permet de modéliser les artefacts d’un système logiciel orienté objet. C’est également à ce niveau que sont définies les extensions des concepts généraux du métamodèle UML, les relations entre les nouveaux concepts du langage, ainsi que les contraintes potentielles sur le langage UML. En somme, c’est à ce niveau que sont définis les profils UML; ceci justifiant d’autant plus leur définition comme une alternative aux métamodèles. Les profils UML et les métamodèles sont en effet deux méthodes distinctes pour décrire un nouveau langage de modélisation et elles se situent toutes les deux au même niveau M2. Un modèle au niveau M1 ne définit aucun nouveau concept du langage, il n’est que l’instance d’un langage défini en M2 et est conforme à celui-ci. De manière générale, un modèle au niveau M1 est conforme à une syntaxe abstraite qui peut être soit un métamodèle soit un profil UML. Enfin, le système réel est défini au niveau M0, il ne s’agit plus d’un modèle mais d’une réelle conception potentiellement exécutable d’un système. La structure et les interactions étant déjà modélisées au niveau supérieur, le concepteur n’a plus qu’à instancier ce modèle en le complétant de valeurs réelles pour chaque élément.
Définition de la coévolution
Dans le dictionnaire français, le terme coévolution désigne une évolution simultanée, parallèle et/ou interdépendante de deux entités de même espèce. Par exemple, les plantes à fleurs et les insectes qui en assurent la pollinisation. Dans (Levendovszky et al, 2010) la coévolution est définit, dans son sens le plus large, comme une adaptation évolutive qui se produit chez plusieurs éléments (gènes ou espèces) à la suite de leurs influences réciproques.
Dans le domaine de la modélisation, un métamodèle représente la définition d’un langage de modélisation et un modèle est une instance du métamodèle. Les métamodèles sont exprimés dans un formalisme de méta-modélisation tel que MOF standardisé par OMG (OMG, 2006) et Ecore (Ecore, 2013). Tous ces formalismes fournissent des moyens similaires au diagramme de classe UML.
Il arrive souvent que les métamodèles évoluent au cours du processus de conception ou de maintenance d’un système logiciel. Dans de tels cas, il est souvent demandé d’adapter les modèles conformes au métamodèle initial, de telle sorte qu’ils soient conformes au métamodèle évolué. Ce processus est dénommé coévolution des modèles (ou évolution couplée des métamodèles et modèles). Dans la littérature, ce problème est appelé évolution du métamodèle et coévolution des modèles (Wachsmuth, 2007), adaptation des modèles (Garcès et al, 2009) ou migration des modèles (Rose et al, 2010). Dans notre travail nous utiliserons ces termes de manière indifférente.
Classification des changements d’un métamodèle
Les métamodèles peuvent changer de différentes manières. L’évolution d’un métamodèle d’une ancienne à une nouvelle version est décrite par un ensemble de changements. Plusieurs travaux dans le domaine de l’évolution et la coévolution ont proposé des classifications différentes des changements effectués sur un métamodèle. Dans (Wachsmuth, 2007), l’auteur propose une classification des opérations de changement selon leur impact sur un métamodèle. Ces impacts sont de trois types : les opérations qui préservent la sémantique (refactoring) ; les opérations qui augmentent la taille du métamodèle (construction) et les opérations qui réduisent la taille du métamodèle (destruction). Par ailleurs dans (Cicchetti et al, 2008) La classification des changements proposée distingue entre les changements additifs faisant référence aux additions des éléments dans un métamodèle ; les changements soustractifs qui consistent en la suppression de quelques éléments du métamodèle et les changements modificatifs représentant quelques modifications et mises à jour des éléments déjà existants dans le métamodèle. Une autre classification est celle proposée dans (Herrmannsdoerfer et al, 2008a) où les changements sont classés en changements primitifs structurels qui affectent la structure du métamodèle ; les changements primitifs non structurels qui préservent la structure du métamodèle tout en changeant uniquement les éléments existants et les changements composites qui regroupent une séquence de changements primitifs.
Ces classifications considèrent l’effet des changements sur les métamodèles. Une autre classification est proposée dans (Gruschko et al, 2008). Cette classification projette les changements sur le niveau M1 en se basant sur l’impact des changements sur les modèles. En fait, Il y a des changements qui ne cassent pas les modèles et par conséquent ne nécessitent aucune ou une légère révision de ces modèles. D’autres changements introduisent des incompatibilités et des incohérences entre les versions, donc invalident (ou cassent) la conformité des modèles. Pour adresser cette issue les instances M1 du métamodèle changé doivent être migrées à la nouvelle version du métamodèle. L’effort nécessaire pour performer cette migration dépend de la nature des changements effectués sur le métamodèle. Elle peut se faire automatiquement ou nécessite une intervention manuelle.
Evolution des langages de modélisation
L’évolution dans le domaine de l’IDM est compliquée car l’IDM implique la combinaison de plusieurs Types d’artefacts interdépendants (Deursen et al, 2007). Plus spécifiquement, il y a trois types d’artefacts de développement spécifiques à IDM (modèles, métamodèles et la spécification des opérations de gestion des modèles). Le changement d’un type d’artefact peut affecter d’autres artefacts (éventuellement de types différents) (Rose, 2011).
Les classifications actuelles des approches d’évolution et de coévolution se concentrent soit sur le type d’informations considérées au cours de l’évolution, soit sur la technique utilisée pour la stratégie de migration. Quelques travaux classent les types d’évolution du modèle en deux catégories: évolution du modèle syntaxique et sémantique .
Évolution du modèle syntaxique: Cette méthode modifie les modèles du domaine existants de sorte que les modèles obéissent aux règles syntaxiques du nouveau métamodèle. Dans ce cas, aucune information n’est connue sur l’intention du changement évolutif. Un inconvénient de l’évolution syntaxique est que les nouvelles données ne reflètent pas nécessairement la sémantique voulue de l’ancien domaine.
Cependant, la migration syntaxique peut être entièrement automatisable. L’évolution du modèle sémantique est une transformation ou un ensemble de transformations qui réécrivent un modèle pour avoir le même sens dans le nouveau langage qu’il avait dans son langage original. La migration sémantique nécessite une adaptation manuelle. Le manque d’informations sur la sémantique de l’évolution peut réduire la possibilité d’automatiser la propagation des changements. Par exemple, si on considère le cas où une classe est supprimée d’un métamodèle. Les questions suivantes doivent être posées pour faciliter l’évolution :
Les sous-types de la classe supprimée doivent-ils également être supprimés? Sinon, leur hiérarchie d’héritage doit elle changée ?
Est-ce que les instances d’une classe supprimée d’un métamodèle devraient être supprimées également où leurs données devraient être déplacées vers une autre classe ?
Une deuxième classification des approches pour automatiser la migration des modèles en réponse à l’évolution des métamodèles est proposée dans (Rose et al, 2009). Les auteurs identifient trois catégories des approches : les spécifications manuelles, les approches à base d’états (matching des métamodèles) et les approches à base d’opérateurs.
Table des matières
Introduction générale
1. Contexte de recherche
2. Problématique
3. Objectifs et contributions
4. Contenu de la thèse
Chapitre 1 Modélisation et méta modélisation
Introduction
1.1 Ingénierie dirigée par les modèles (IDM)
a) Système
b) Modèle
c) Métamodèle
d) Langage de modélisation
e) Méta-métamodèle
f) Transformation de modèle
1.2 Architecture dirigée par les modèles (MDA)
1.2.1 Le principe du MDA
a) Le modèle d’exigence (CIM)
b) Le modèle indépendant de toute plateforme (PIM)
c) Le modèle de description de la plateforme (PDM)
d) Le modèle spécifique à une plate-forme (PSM)
1.2.2 Avantages du processus MDA
1.2.3 Les niveaux de modélisation
1.2.4 Les langages de méta-modélisation
a) Meta-Object Facility (MOF)
b) Ecore de Eclipse Modelling Framework
Conclusion
Chapitre 2 Evolution des métamodèles et coévolution des modèles
Introduction
2.1 Définition de l’évolution
2.2 Définition de la coévolution
2.3 Classification des changements d’un métamodèle
2.4 Evaluation des approches existantes
2.4.1 Evaluation des approches dans les domaines connexes
2.4.1.1 Evolution des schémas des bases de données
2.4.1.2 Evolution dans des schémas XML
2.4.2 Evolution des langages de modélisation
2.4.2.1 Les approches manuelles
a) Un langage visuel spécifique au domaine (DSVL) pour l’évolution des modèles du domaine
b) MCL : un langage de changement de modèles
c) Migration de modèles avec Epsilon Flock
2.4.2.2 Les approches à base d’états
a) Vers la synchronisation des modèles avec les métamodèles évolués
b) Une approche transformationnelle pour la coévolution des modèles
c) Gestion de l’adaptation des modèles par la détection précise des changements du métamodèle
2.4.2.3 Les approches à base des opérateurs
a) Metamodel adaptation and model co-adaptation
b) COPE- automatisation de l’évolution couplée des métamodèles et des modèles
2.4.3 Analyse comparative des approches existantes
Conclusion
Chapitre 3 Encodage des métamodèles en langage des prédicats
Introduction
3.1 Encodage des modèles
3.1.1 Encodage
3.1.2 Transformation
3.2 Introduction à la programmation logique
3.2.1 Notion de terme
3.2.2 Exemple
3.2.3 Principe de résolution SLD
Conclusion
Chapitre 4 Approche intelligente de coévolution des modèles et des métamodèles
Introduction
4.1 Positionnement de notre approche
4.2 Aperçu générale de l’approche proposée
4.2.1 La phase préliminaire
4.2.1.1 Encodage des métamodèles et des modèles
a) Niveau méta-métamodèle
b) Niveau métamodèle
4.2.1.2 Encodage des changements d’un métamodèle en PL
4.2.1.3 Encodage des opérateurs d’évolution
a) Détermination des éléments évolutifs
b) Description des opérateurs d’évolution
c) Aperçu de la bibliothèque d’opérateurs
d) Formalisation des opérateurs atomiques en langage des prédicats
e) Formalisation des opérateurs composites en langage des prédicats
4.2.2 Détection des changements
4.2.3 Reconstruction du scénario d’évolution
4.2.3.1 Reconstruction des opérations d’évolution primitives
4.2.3.2 Reconstruction des opérateurs d’évolution composites
4.2.4 Détermination du scénario de migration
4.2.5 La migration
Conclusion
Chapitre 5 Implémentation et expérimentation
Introduction
5.1 Outils utilisés
5.2 Description du Prototype
5.2.1 La phase préliminaire
5.2.2 La phase détection des changements
5.2.3 La phase reconstruction du scénario d’évolution
5.2.4 Génération du scenario de migration et migration des modèles
Conclusion
Conclusion générale
Perspectives de recherche
Références
