Soutenance mémoire
Le logiciel est devenu un élément, non seulement indispensable, mais aussi omniprésent dans notre société [1]. Par ailleurs, la taille et la complexité de celui-ci n’ont cessé de croître. Ainsi, le développement du logiciel est devenu une tâche tellement complexe qu’il devient rare d’avoir un logiciel sans faille.
Le génie logiciel a été introduit pour résoudre les problèmes des projets de développement du logiciel qui mènent à des résultats de faible qualité. Les problèmes surviennent lorsque le développement dépasse les délais et/ou les budgets ou que la qualité n’est pas au niveau des exigences [2]. Ainsi, le génie logiciel a pour objectif la construction de logiciels de manière cohérente, correctement, dans les délais, sans dépassement du budget et répondant aux exigences. Cependant, face à la croissance continue du besoin logiciel, ainsi que la complexité des logiciels qui ne cesse d’augmenter [3, 4], une approche a vu le jours qu’est l’Ingénierie Dirigée par les Modèles (IDM). Apparue dans les années 1992, le message central de l’IDM est de déplacer le cœur central du développement logiciel du programme (code) aux modèles, jusqu’à même arriver à concevoir des modèles qui peuvent être directement compilés et exécutés [5, 6]. Étant donné que les modèles sont plus proches de la compréhension humaine que le code, manipuler les modèles serait moins sujet à des erreurs que le code source [7]. Ainsi, l’ingénierie dirigée par des modèles est une approche de développement logiciel qui propose d’élever le niveau d’abstraction des langages afin de déplacer l’effort de conception et de compréhension du point de vue du programmeur vers celui du concepteur. Pour mettre cette vision en pratique, des Langages de Modélisation Spécifiques aux Domaines (DSML) ont émergé en industrie [8]. L’utilisation de ces derniers dans différents cas d’études industriels a augmenté la productivité de 500% à 1000% selon [9].
Pour concevoir des DSML de qualité, la construction de métamodèles précis demeure une tâche primordiale. Un métamodèle représente la syntaxe abstraite d’un langage de modélisation spécifique au domaine [10]. Étant l’artefact principal autour duquel est construit le DSML, le métamodèle est composé d’une partie structurelle, qui capture tous les concepts du domaine, ainsi que les relations entre les différents concepts [9, 11]. Les métamodèles sont souvent définis avec des langages, comme MOF (Meta-Object Facility) [12], un standard du consortium OMG (Object Management Group). Considérant la difficulté ou l’impossibilité d’exprimer certaines informations par le biais de diagrammes, des contraintes textuelles, autrement appelées des règles de bonne formation (ou WellFormedness Rules (WFR)) et qui sont souvent spécifiées avec le langage OCL (Object Constraint Language) [13], sont souvent ajoutées afin de préciser certains concepts. Ceci assure que la sémantique structurelle des modèles générés à partir du métamodèle soit en adéquation avec le domaine visée. Par conséquent, on ne peut bénéficier de toute la puissance de l’ingénierie dirigée par les modèles que si le métamodèle est suffisamment précis pour décrire adéquatement les parties syntaxiques et sémantiques du domaine visé.
Ingénierie dirigée par les modèles (IDM)
Souvent, les développeurs font une démarcation entre la modélisation et le codage. Les modèles sont utilisés pour concevoir des systèmes, mieux les comprendre, spécifier des fonctionnalités requises, et créer de la documentation. Par conséquent, le code est écrit pour implémenter les modèles, ce qui fait que le débogage, les tests, ainsi que la maintenance sont faits au niveau du code. Cette séparation entre le code et le modèle n’est pas nécessaire car il existe plusieurs façons d’aligner le code et les modèles.
— D’abord, dans le cas le plus extrême, aucun modèle n’est créé. La spécification des fonctionnalités se fait directement sur le code source. Cette approche fonctionne bien dans le cas où le projet est de petite taille.
— Ensuite, certains développeurs créent des modèles, mais qui servent juste à abstraire les détails d’implémentation pour se focaliser sur le domaine. Cependant, ces derniers sont indépendants du code. Cette méthode n’est pas rentable puisque le coût nécessaire pour garder à jour à la fois le code source, mais aussi le modèle, est supérieur au bénéfice qu’apporte l’utilisation des modèles.
— Le troisième cas est celui de la visualisation de code. Cette méthode est surtout utilisée en rétro-ingénierie pour permettre de visualiser le fonctionnement d’un code déjà fonctionnel.
— Le quatrième cas est celui du modèle « Aller-retour » ou « Round-Trip » en anglais. Ce dernier automatise le processus de mise à jour entre le code source et le modèle. Ce modèle fonctionne seulement quand les formats du code et du modèle sont similaires, et quand il n’y a pas de perte d’information entre les différentes transformations. Aussi, ce mode de fonctionnement est contraire au concept d’utiliser les modèles pour abstraire des détails d’implémentation et donc de se focaliser sur le domaine. Si le modèle inclut tous les détails d’implémentation, ce dernier ne sera pas d’une grande utilité.
— Enfin, dans la dernière approche, le modèle est d’abord créé. Ce dernier étant abstrait, il représente les différents concepts du domaine et les relations entre les concepts, sans aucun détail d’implémentation, ce qui le rend beaucoup moins complexe à manipuler en comparaison au code. Ainsi, le modèle devient l’artefact principal dans ce processus de développement. À partir du modèle, un langage d’implémentation est ciblé puis du code source est généré pour ensuite être compilé ou interprété pour l’exécution. Cette approche est le fondement de l’ingénierie dirigée par des modèles.
Compte-tenu de la croissance continue de la complexité logicielle [4, 24, 25], l’ingénierie dirigée par les modèles permet donc de élever le niveau d’abstraction, du code source vers les modèles [26]. De ce fait, les modèles sont placés comme artefacts centraux dans le processus de développement. Ainsi, les développeurs se concentrent sur le domaine du problème, plutôt que sur les technologies sous-jacentes pour créer, maintenir, tester et manipuler des modèles.
Modèle
Un modèle est une abstraction d’un système souvent utilisé pour étudier un système [27-29]. La pratique de modélisation est adoptée par les domaines de l’ingénierie ainsi que d’autres domaines tels que la physique, les mathématiques, la biologie, l’économie, la politique et la philosophie [30]. Dans la littérature, il existe une multitude de définitions de ce qu’est un modèle. Nous en citerons les suivantes:
1. “le modèle est un ensemble de déclarations concernant le système étudié” [31] ;
2. “Le modèle est une abstraction d’un système (réel ou basé sur le langage) permettant de faire des prédictions ou des déductions” [29] ;
3. “Le modèle est une représentation réduite d’un système qui met en évidence les propriétés intéressantes d’un point de vue donné” [32] ;
4. “un modèle est une simplification d’un système construit dans un but précis ; un modèle doit donc être capable de répondre à des questions à la place du système original” [33].
Pour soutenir l’utilisation de modèles comme artefacts principaux, l’OMG a défini quatre niveaux d’abstraction comme illustré dans la figure 2.2, à savoir les systèmes modélisés, les modèles, les métamodèles, et les méta-métamodèles. Il existe trois relations en IDM : la conformité (x), la représentation (µ) et l’appartenance (∈). Par conséquent, l’OMG définit 4 niveaux de modélisation, chaque niveau (sauf le niveau M3) étant constitué d’éléments qui sont des instances d’éléments du niveau supérieur :
— M0 : système réel, système modélisé.
— M1 : modèle du système réel défini dans un certain langage. Ce dernier représente un système réel. Il est conforme à un métamodèle et appartient donc à un langage de modélisation.
— M2 : métamodèle définissant le langage. Il représente un langage de modélisation. Un métamodèle est conforme à un méta-métamodèle, et donc appartient à un langage de métamodélisation.
— M3 : méta-métamodèle définissant le métamodèle. Suivant le concept de métacircularité, il est conforme à lui-même puisqu’il doit permettre d’être créé à partir de lui-même. Un méta-métamodèle appartient et représente un langage de métamodélisation.
Métamodèles
Bien que les modèles non structurés qui servent comme représentation graphique soient utiles pour soutenir la communication entre différentes parties prenantes [35], les modèles ne sont plus considérés comme une documentation basique avec l’avancée de l’IDM. Ces derniers deviennent une force dans le processus de développement logiciel [36]. Afin d’apporter une valeur tangible aux processus automatiques impliquant des représentations abstraites, la traduction des modèles en code exécutable efficace doit être automatisée. En effet, lorsque les modèles sont bien définis (c’est-à-dire qu’une méta définition est fournie), les processus automatisés peuvent interpréter leur structure. En IDM, la conversion des représentations abstraites en implémentions concrètes se fait à l’aide d’une séquence de transformations automatisées qui génèrent, à partir d’un modèle de haut niveau, le code exécutable de bas niveau [37, 38]. Ce processus entraîne un gain de productivité considérable [39, 40]. Dans la pratique, l’utilisation de l’IDM accélère sans doute les réponses aux changements d’exigences, facilite la communication avec les parties prenantes et augmente la portabilité, la maintenabilité et bien sûr la productivité [26, 41]. Pour soutenir l’automatisation proposée par l’IDM, les métamodèles jouent un rôle majeur. Les métamodèles sont des composants essentiels de l’écosystème de langage de modélisation [26]. Ils définissent les aspects structurels d’un domaine métier qui composeront les modèles, c’est-à-dire les principaux concepts, leurs propriétés, les relations entre eux, ainsi que leurs occurrences [42].
|
Table des matières
I Introduction
1 Introduction
1.1 Introduction
1.2 Motivation
1.3 Contributions de la thèse
1.3.1 Identification et catégorisation des structures imprécises dans les métamodèles
1.3.2 Identification de l’apparition de MIS lors de la co-évolution métamodèle/contrainte
1.4 Structure du rapport
II Contexte de travail et état de l’art
2 Contexte de travail
2.1 Ingénierie dirigée par les modèles (IDM)
2.2 Modèle
2.3 Métamodèles
2.4 Meta-Object Facility (MOF)
2.5 Le Langage de Contraintes d’Objets (OCL)
2.6 Métamodélisation précise
2.6.1 Transformation de modèles
2.6.2 Les différents types de transformation
2.6.2.1 L’évolution
2.6.2.2 La maintenance
2.6.2.3 Le refactoring
2.6.2.4 La coévolution
2.7 En résumé
3 Etat de l’art
3.1 Assistance à la métamodélisation de qualité
3.1.1 Évaluation de la qualité des métamodèles
3.1.2 Assistance à la production de contraintes OCL
3.2 Gestion de la maintenance et évolution des métamodèles
3.2.1 Maintenance et évolution des métamodèles
3.2.2 Maintenance et coévolution des contraintes OCL
3.2.2.1 Maintenance et refactoring de contraintes OCL
3.2.2.2 Coévolution de contraintes OCL
3.3 Positionnement de la problématique de thèse
3.4 En résumé
III Contributions
4 Étude d’investigation sur les structures imprécises dans les métamodèles
4.1 Introduction
4.2 Problématique et Motivations
4.2.1 Types de contraintes OCL
4.2.2 Exemple Illustratif
4.3 Processus expérimental
4.3.1 Objectifs et question de recherche
4.3.2 Approche et données
4.4 Résultats
4.4.1 Restriction de la valeur d’un attribut
4.4.2 Restriction des Littéraux d’une énumération
4.4.3 Attribut optionnel hérité
4.4.4 Restriction de la Multiplicité d’une Association Héritée
4.4.5 Restriction de la Valeur d’un Attribut Hérité
4.4.6 Restriction de la Valeur d’une Opération Héritée
4.4.7 Relation entre Types
4.4.8 Restriction des Cycles
4.4.9 Relation entre les Chemins
4.4.10 La distribution des contraintes liées aux MIS dans le métamodèle UML 2.5
4.5 En résumé
5 Approche d’identification de MIS lors de la coévolution métamodèle/- contrainte
5.1 Introduction
5.2 Problématique et Motivation
5.3 Approche
5.3.1 Opérateurs d’évolution de métamodèles
5.3.2 Identification de MIS pendant la coévolution métamodèle/contrainte
5.4 Étude des opérateurs d’évolution de métamodèle pour expliciter le lien de causalité avec les MIS
5.4.1 Les opérateurs d’ajout/Suppression d’éléments
5.4.1.1 Ajouter Classe
5.4.1.2 Supprimer Classe
5.4.1.3 Ajouter Package
5.4.1.4 Supprimer Package
5.4.1.5 Ajouter TypeDonnées, TypePrimitif, Énumeration
5.4.1.6 Supprimer TypeDonnées, TypePrimitif, Énumeration
5.4.1.7 Ajouter LittéralÉnumération
5.4.1.8 Retirer LittéralÉnumération
5.4.1.9 Ajouter Attribut
5.4.1.10 Supprimer Attribut
5.4.1.11 Ajouter Association
5.4.1.12 Supprimer Association
5.4.1.13 Ajouter Opération (Classe / TypeDonnées)
5.4.1.14 Supprimer Opération (Classe / TypeDonnées)
5.4.1.15 Introduire Généralisation
5.4.1.16 Supprimer Généralisation
5.4.2 Les opérateurs de Manipulation de Propriétés
5.4.2.1 Déplacer Propriété
5.4.2.2 Déplacer un attribut vers les sous-classes
5.4.2.3 Déplacer une association vers les sous-classes
5.4.2.4 Regrouper un attribut commun dans la super-classe
5.4.2.5 Regrouper une association commune dans la super-classe
5.4.2.6 Restreindre une association unidirectionnelle
5.4.2.7 Généraliser une association unidirectionnelle
5.4.3 Les opérateurs de refactoring
5.4.3.1 Extraire Classe
5.4.3.2 Fusionner Classe
5.4.3.3 Extraire Super-classe
5.4.3.4 Aplatir Hiérarchie
5.4.3.5 Association vers Classe
5.4.3.6 Généralisation vers Composition
5.4.3.7 Introduire Pattern Composite
5.5 En résumé
6 Evaluation
IV Conclusion
