Télécharger le fichier original (Mémoire de fin d’études)
Contexte et état de l’art
Ce chapitre détaille le contexte des travaux présentés dans ce document. L’objectif de cette thèse est de proposer des techniques pour améliorer la qualité des processus de développement basés sur les modèles. Cet état de l’art est donc naturellement divisé en deux axes : l’ingénierie des modèles et la validation de logiciels. La section 2.1 présente l’ingénierie des modèles d’un point de vue général et détaille les techniques employées pour la définition de modèles et de transformations de modèles. La section 2.2 présente les principes du test de logiciel et détaille un ensemble de travaux pour l’automatisation de la génération de données de test. Enfin, la section présente des travaux existants pour la fiabilisation des processus de développement basés sur les modèles.
Ingénierie des modèles
L’Ingénierie dirigée par les modèles (IDM) [EFB+05] propose des pistes pour per-mettre aux organisations de surmonter la mutation des exigences du développement de logiciel. L’IDM est une forme d’ingénierie générative, par laquelle tout ou 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) [vDKV00, CM98], le MIC (Model Integrated Computing) [SKB+95, SK97], les usines à logiciels (Software Factories) [GSC+04], etc.
Dans cette nouvelle perspective, les modèles occupent une place de premier plan parmi les artefacts de développement des systèmes, et 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 spécifier leurs points de variations sémantiques, et donc aussi de décrire de manière précise les langages utilisés pour les représenter. On parle alors de meta-modélisation.
L’intérêt pour l’Ingénierie Dirigée par les Modèles a été fortement amplifié, en no-vembre 2000, lorsque l’OMG (Object Management Group) a rendu publique son ini-tiative MDA [StOs00a] qui vise à la définition d’un cadre normatif pour l’IDM. Il existe cependant bien d’autres alternatives technologiques aux normes de l’OMG, par exemple Ecore dans la sphère Eclipse, mais aussi les grammaires, les schémas de bases de données, les schémas XML. Finalement, l’IDM dépasse largement le MDA, pour se positionner plutôt à la confluence de différentes disciplines.
Cette section d’état de l’art sur l’ingénierie des modèles a deux objectifs. Le premier est de préciser le contexte et les travaux existant dans ce domaine. Le second est de définir un certain nombre de concepts qui sont utilisés dans les chapitres suivants de ce document. La section 2.1.1 présente un tour d’horizon des différentes approches de développement basées sur l’utilisation de modèles. La section 2.1.2 définit les notions de modèle, méta-modèle et méta-méta-modèle qui sont largement utilisées dans la suite du document. La section 2.1.3 présente rapidement les principaux langages de méta-modélisation existants et s’attarde sur les concepts propre à ces langages. Enfin, la section 2.1.5 définit la notion de transformation de modèle et présente les différentes techniques de transformations existantes.
Les approches de développement basées sur les modèles
Dans le courant des langages spécifiques et de la programmation générative, un certain nombre d’approches basées sur les modèles se développent depuis une décennie. Parmi ces approches, et par ordre chronologique d’apparition, on peut citer le Model-Integrated Computing (MIC), le Model-Driven Architecture (MDA) et les Software Factories. Les sous-sections qui suivent présentent les grandes lignes de chacune de ces approches.
Model-Integrated Computing (MIC)
Les travaux autour du Model-Integated Computing (MIC) [SKB+95, SK97] pro-posent, dès le milieu des années 90, une vision du génie logiciel dans laquelle les artefacts de base sont des modèles spécifiques au domaine d’application considéré. Initialement, le MIC est conçu pour le développement de systèmes embarqués complexes [KSLB03]. Dans [LBM+01] les auteurs discutent de l’implantation et de l’outillage des idées du MIC.
La méthodologie proposée décompose le développement logiciel en deux grandes phases. La première phase est réalisée par des ingénieurs logiciels et systèmes. Elle consiste en une analyse du domaine d’application ayant pour but de produire un en-vironnement de modélisation spécifique à ce domaine. Au cours de cette phase, il faut choisir les paradigmes de modélisation et définir formellement les langages de modélisa-tion qui seront utilisés. A partir de ces éléments, un ensemble de méta-outils sont utilisés pour générer un environnement spécifique au domaine. Cet environnement a l’avantage d’être utilisable directement par des ingénieurs du domaine. La seconde phase consiste à modéliser l’application à réaliser en utilisant l’environnement généré. Cette phase est
Ingénierie des modèles 15
réalisée uniquement par des ingénieurs du domaine et permet de synthétiser automati-quement le logiciel.
En pratique, les idées du MIC sont implantées dans la suite d’outils (GME) [Dav03] (The Generic Modeling Environment). Dans sa dernière version (5.0), GME s’intègre
l’environnement de développement Visual Studio .NET 2003 de Microsoft et propose des outils pour la création de langages de modélisation et de modèles. La définition de la sémantique des langages de modélisation, et donc la semantique des modèles manipulés, n’est pas supportée directement : l’interprétation sémantique des modèles doit être réalisée dans une phase aval.
Model-Driven Architecture (MDA)
Le Model-Driven Architecture (MDA) [StOS00b] est une démarche de développe-ment à l’initiative de l’OMG (Object Management Group) rendue publique fin 2000. 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 plate-forme donnée. Pour cela, le MDA définit une architecture de spécifications structurée en modèles indépendants des plates-formes (Platform Indepandant 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 plates-formes grâce à des projections normalisées. Elle permet aux applications d’interopérer en re-liant leurs modèles et supporte l’évolution des plates-formes et des techniques. La mise en oeuvre du MDA est entièrement basée sur les modèles et leurs transformations.
L’initiative MDA de l’OMG a donné lieu à une importante normalisation des tech-nologies pour la modélisation. La proposition initiale était d’utiliser le langage UML (Unified Modeling Langage) et ses différentes vues comme unique langage de modé-lisation. Cependant, il a fallu rapidement ajouter la possibilité d’étendre le langage UML, par exemple en créant des profils, afin de permettre d’exprimer de nouvelles notions. Ces extensions devenant de plus en plus importantes, la communauté MDA a progressivement délaissé UML au profit d’approches utilisant des langages spécifiques. Le langage de méta-modélisation MOF, et plus récemment MOF 2.0, a été créé pour permettre la spécification de méta-modèles, c’est-à-dire de langages de modélisation. Il est intéressant de noter que, par exemple, UML est construit à partir de MOF.
Les usines logicielles (Software Factories) Les usines logicielles (Software Factories) [GSCK04] sont la vision de Microsoft de l’ingénierie des modèles. Le terme d’usine logicielle fait référence à une industrialisation du développement logiciel et s’explique par l’analogie entre le processus de développe-ment proposé et une chaine de montage industrielle classique. En effet, dans l’industrie classique :
– Une usine fabrique une seule famille de produits. Si l’on considère par exemple l’industrie automobile, une chaîne de montage ne fabrique généralement qu’un seul type de voiture avec différentes combinaisons d’options.
Table des matières
Remerciements
Table des matières
1 Introduction
2 Contexte et état de l’art
2.1 Ingénierie des modèles
2.1.1 Les approches de développement basées sur les modèles
2.1.2 Modèles, méta-modèles et méta-méta-modèle
2.1.3 Méta-modélisation orientée-objets
2.1.4 Expression de contraintes et utilisation d’OCL
2.1.5 Transformation de modèles
2.2 Le test de logiciel
2.2.1 Principes et problématiques du test
2.2.2 Le critère d’arrêt
2.2.3 Le problème de l’oracle
2.2.4 La réduction/minimisation de suite de tests
2.2.5 La localisation d’erreurs
2.2.6 Génération de données de test
2.3 Validation et ingénierie des modèles
2.3.1 Validation des modèles
2.3.2 Validation des transformations de modèles
2.4 Conclusion
3 Noyau pour la méta-modélisation
3.1 Contexte et motivations
3.1.1 Exemple de la pratique actuelle
3.1.2 Analyse et proposition
3.2 Un méta-méta-modèle exécutable
3.2.1 Choix du langage de méta-données
3.2.2 Choix du langage d’actions
3.2.3 Processus de construction de Kermeta
3.3 Le langage Kermeta
3.3.1 Structures issues de EMOF
3.3.2 Héritage et redéfinition
3.3.3 Classes et opérations génériques
3.3.4 Expressions Kermeta
3.3.5 Clôtures lexicales
3.3.6 Contraintes
3.4 Système de types de Kermeta
3.4.1 Les types Kermeta
3.4.2 Relations et règles de sous-typage
3.4.3 Environnement de typage
3.4.4 Typage de la structure
3.4.5 Typage des expressions
3.5 Conclusion
4 Utilisation de Kermeta : études de cas
4.1 Exemple des automates
4.1.1 Définition de contraintes
4.1.2 Définition d’une sémantique opérationnelle et simulation
4.1.3 Validation de la sémantique
4.1.4 Interopérabilité et sérialisation
4.1.5 Manipulation de modèles et transformations
4.1.6 Conclusion
4.2 Transformation de modèles
4.2.1 Méta-modèles d’entrée et de sortie
4.2.2 Spécification de la transformation
4.2.3 Conception et implantation en Kermeta
4.2.4 Conclusion
4.3 Modélisation orientée-aspect
4.3.1 Contexte et motivations
4.3.2 Composition de diagrammes de classes
4.3.3 Tissage de diagrammes de séquences
4.3.4 Conclusion
4.4 Langages spécifiques à l’ingénierie des exigences
4.4.1 Processus de traitement des exigences
4.4.2 Modèle sémantique et simulation
4.4.3 Analyse sémantique d’exigences textuelles
4.4.4 Conclusion
4.5 Conclusion
5 Test de transformations de modèles
5.1 Validation de transformations de modèles
5.1.1 Définitions
5.1.2 Motivations
5.1.3 Test de transformations de modèles
5.2 Un framework pour la sélection de modèles de test
5.2.1 Exemple et intuition
5.2.2 Valeurs et multiplicité des propriétés
5.2.3 Combinaisons de valeurs : fragments d’objets et de modèles
5.2.4 Sélection des modèles de tests
5.3 Exemple de critères de test
5.3.1 Critères simples
5.3.2 Combinaisons classe par classe
5.3.3 Utilisation de l’héritage
5.3.4 Comparaison des critères et discussion
5.4 Génération de modèles
5.4.1 Problématique et motivations
5.4.2 Algorithme de génération itératif
5.4.3 Algorithme pseudo-aléatoire
5.4.4 Conclusion
5.5 Conclusion et perspectives
6 Conclusion et perspectives
6.1 Contribution
6.2 Perspectives
A Sémantique du langage Kermeta
Sémantique du langage Kermeta
A.1 Structure de données et notations
A.2 Sémantique des expressions
A.2.1 Structures de contrôles
A.2.2 Variables
A.2.3 Affectation et cast
A.2.4 Appel de propriétés et d’opérations
A.2.5 Fonctions
Glossaire
Bibliographie
Table des figures
Publications
Télécharger le rapport complet
