Mise en application de développement logiciel dans l’IDM

Mise en application de développement logiciel dans l’IDM 

Approches de développement basées sur les modèles

Nous avons retenu quatre approches de développement basé sur les modèles qui sont parmi les principales développées depuis une décennie. Nous nous intéressons principalement à la dernière, le MDA, car elle appartient à la même partie de l’espace technique modelware (mêmes méta-modèles, même outillage) que l’ensemble des travaux de cette thèse.

Rational Unified Process (RUP)

Le Rational Unified Process (RUP) [Kruchten’99] est un processus de développement fondé sur le cycle de vie en spirale. Il comble les lacunes du classique cycle en V (figure 2-10) pour limiter le risque de remise en question de la totalité (ou d’une trop grande part) du développement en cas de problème (coût sous-estimé, réalisation incohérente ou incorrecte, etc.). Chaque itération de la spirale est un incrément du système pour successivement passer d’une phase du projet à une autre jusqu’à la livraison du système (il y a quatre phases qui se nomment : inception puis élaboration puis construction puis transition). Chaque phase comprend un certain nombre d’itérations et selon la phase d’une itération l’effort est porté différemment sur l’analyse, la conception, l’implémentation, le test, etc. Le RUP exploite directement la modélisation en utilisant les diagrammes UML (Unified Modeling Language) [OMG’07] pour toutes les étapes d’analyse et de conception. Dans cette approche, les modèles sont exploités pour limiter l’utilisation d’un cahier des charges textuel pour le codage du logiciel mais également pour être facilement retravaillés et améliorés à chaque nouvelle itération. Les modèles assistent le développement, facilitent le travail d’équipe, la répartition des rôles, le développement itératif.

Model-Integrated Computing (MIC) 

Le Model-Integrated Computing [Sztipanovits’95] est une méthodologie qui décompose le développement logiciel en deux phases. La première phase est réalisée par des ingénieurs logiciels et systèmes. Elle consiste à étudier le domaine d’application visé pour produire un environnement de modélisation spécifique. Dans une seconde phase, les ingénieurs du domaine utilisent cet environnement pour modéliser l’application. L’implantation est ensuite générée automatiquement à partir du modèle et des fonctionnalités de l’environnement. La suite d’outils Generic Modeling Environment (GME) [Davis’03] permet la mise en œuvre du MIC. GME est intégré dans l’environnement de développement logiciel Visual Studio .NET 2003 de Microsoft. Cependant la génération du logiciel à partir du modèle n’est pas complètement supportée car les langages de modélisation développés n’ont pas de sémantique.

Usines logicielles

Microsoft propose sa propre vision de l’IDM avec les usines logicielles (Software Factories) [Greenfield’03]. L’idée consiste à adapter pour le développement logiciel des caractéristiques du développement matériel ayant fait leur preuve (d’où le nom d’usine). La première caractéristique retenue est la spécialisation des fournisseurs et des développeurs de logiciels. La deuxième est l’utilisation d’outils dédiés au domaine d’application sous la forme de transformations de modèles, de langages et d’outils de modélisations. La troisième est la réutilisation de composants logiciels mis à disposition. Ces idées sont intégrées dans l’environnement de développement logiciel Visual Studio .NET 2005 de Microsoft.

MDA

L’OMG a proposé le MDA (Model Driven Architecture) en 2000 [Soley’00] pour mettre en avant de bonnes pratiques de modélisation et d’exploitation des modèles. Le MDA avance plusieurs idées. Tout d’abord, pour construire un système, il faut abstraire son développement en séparant les spécifications fonctionnelles et les contraintes de la plate-forme d’implantation. Dans cet objectif, le MDA définit une architecture de spécifications à plusieurs niveaux : d’un coté le système est modélisé avec des modèles indépendants de la plate-forme (PIM : Platform Independent Models), de l’autre côté le système est modélisé avec les caractéristiques de la plate-forme prises en compte (PSM : Platform Specific Models). Ensuite, des transformations de modèles sont utilisées pour automatiser le passage d’un PSM à partir d’un PIM. Des transformations servent également à modifier et améliorer les PSM et les PIM.

L’approche MDA permet de réutiliser le même modèle pour l’implémenter sur différentes plates-formes. Elle permet de relier les modèles de différentes applications pour les faire interagir. Elle supporte l’évolution des plates-formes et des techniques. L’initiative de l’OMG a entrainé plusieurs normalisations de technologies pour l’ingénierie des modèles. Le MDA initial proposait d’utiliser le langage UML (Unified Modeling Language) comme unique langage de modélisation. Ce langage a été étendu avec la possibilité de créer des profils pour l’ajout de nouveaux concepts de modélisation. Ce mécanisme ne suffisant pas à la communauté MDA, le langage UML ne fut plus le sommet de la pyramide de métamodélisation, mais un méta-modèle parmi d’autres. Ces méta-modèles sont des langages de méta-modélisation qui sont créés dans un contexte particulier et qui sont conformes à un métaméta-modèle : le MOF (Meta-Object Facility).

Méta-modélisation orientée objet 

Dans ce document, nous nous restreignons aux approches orientées objet. Dans ce contexte, les principaux langages de méta-modélisation sont MOF [OMG’97a], CMOF [OMG’04], EMOF [OMG’04], ECore [Ecore]. L’OMG a normalisé le MOF 1.4 en même temps qu’UML 1.4. EMOF (Essential MOF) et CMOF (Complete MOF) sont des évolutions du MOF 1.4 qui se différencient selon le nombre de concepts qu’elles définissent. Elles ont été normalisées dans le MOF 2.0 [OMG’04] au moment de la création d’UML 2.0. Le langage de modélisation UML [OMG’07] est conforme au MOF (selon leurs versions respectives). IBM a proposé Ecore [Ecore] comme langage de méta-modélisation pour le framework de modélisation EMF (Eclipse Modeling Framework) [EMF] intégré dans la plate forme de développement Eclipse. Ecore a été aligné sur la norme EMOF. Nous avons retenu EMOF pour tous les développements de cette thèse car c’est un standard et qu’il est adopté dans la communauté française et supporté dans les outils de l’équipe Triskell. Dans ce point, nous présentons les principales constructions de méta-modélisation qui permettent d’obtenir et de manipuler des modèles.

Transformation de modèles

Dans l’IDM, les transformations de modèles ont beaucoup d’importance. Elles permettent de manipuler automatiquement des modèles. Cette automatisation est essentielle pour plusieurs raisons :
❖ la complexité des modèles et donc la difficulté de les traiter manuellement.
❖ Les modèles traités peuvent être nombreux ou les mêmes traitements doivent être appliqués plusieurs fois.
❖ La séparation des rôles dans un cycle de développement complexifie la tâche si le spécialiste de la plateforme doit traiter manuellement le modèle produit par le spécialiste des fonctionnalités du système développé.
❖ Le gain obtenu grâce à l’abstraction fournie par les modèles (en productivité, en coût, en diminution des risques, en maîtrise de la complexité, etc.) est moindre si le passage vers différents niveaux d’abstraction n’est pas automatisé.

Les transformations sont utilisées pour réaliser différents traitements sur des modèles et sont employées dans différents domaines qui exploitent l’IDM. Dans le MDA, les transformations sont utilisées pour changer de niveau d’abstraction et produire le modèle spécifique à une plateforme [Gerber’02]. Cette approche permet d’utiliser des transformations pour produire automatiquement des modèles qui prennent en compte des contraintes complexes liées à la plate-forme qu’il est préférable d’abstraire pour modéliser les fonctionnalités. De cette manière l’utilisateur peut se concentrer sur la vision abstraite du système développé et réutiliser des transformations qui ajoutent des fonctionnalités telles que le parallélisme [Yu’07] ou des contraintes pour embarquer des systèmes sur puces [Bondé’04, Bondé’06]. Les lignes de produits logiciel sont un important champ d’investigation pour l’utilisation de transformations de modèles. Oldevik et al. [Oldevik’07] proposent d’utiliser des transformations pour fournir la variabilité à une ligne de produits. A partir d’un modèle commun à l’ensemble de la chaîne, chaque produit peut être le résultat d’une transformation. Chaque transformation peut prendre en compte la variabilité de la plate-forme cible ou la variabilité fonctionnelle des produits. Un système en développement peut être amélioré au niveau modèle, avant son codage (ou la génération de son code). Les améliorations les plus courantes consistent à appliquer des patrons de conception (design pattern). Un patron représente une solution à un problème de conception courant et sous une forme permettant sa mise en œuvre dans un système existant. De manière pratique, appliquer un patron de conception consiste à transformer un modèle, il est donc possible de spécifier des transformations qui automatisent l’application des patrons de conception [France’03]. L’intérêt de l’IDM réside donc en grande partie sur les transformations de modèles [Sendall’03]. Le gain de l’IDM ne réside pas seulement dans l’abstraction fournie par les modèles. L’automatisation des transformations de modèles permet d’exploiter les traitements complexes et répétés des modèles.

Table des matières

1 Introduction
2 Contexte et état de l’art
2.1 Ingénierie Dirigée par les Modèles
2.1.1 Modèles, méta-modèles, méta-méta-modèles, méta-modélisation
2.1.2 Mise en application de développement logiciel dans l’IDM
2.2 Transformation de modèles
2.2.1 Principe de la transformation de modèles
2.2.2 Un exemple de transformation de modèles class2rdbms
2.2.3 Langages et outils de transformations de modèles
2.3 Test de logiciel
2.3.1 Principe et principales problématiques du test de logiciel
2.3.2 Analyse de mutation
2.3.3 Oracle de test de logiciel
2.4 Contraintes et composants
2.4.1 Conception par contrat
2.4.2 Exploitation des contraintes pour le test
2.4.3 Composant dans l’IDM
2.5 Test de transformations de modèles
2.5.1 Travaux sur le test de transformations de modèles
2.5.2 Comparaison de modèles pour l’oracle
3 Analyse de mutation
3.1 Adaptation de l’analyse de mutation à l’ingénierie dirigée par les modèles
3.1.1 Une technique pour la qualification et l’amélioration des modèles de test
3.1.2 Limitations des opérateurs de mutation classiques
3.1.3 Les transformations de modèles d’un point de vue sémantique pour l’analyse de mutation
3.2 Opérateurs de mutation dédiés aux transformations de modèles
3.2.1 Opérateurs de mutation concernant la navigation
3.2.2 Opérateurs de mutation concernant le filtrage
3.2.3 Opérateur de mutation concernant la création
3.3 Simplification des activités non automatisables
3.3.1 Simplification de l’amélioration des modèles de test
3.3.2 Réduction du nombre de modèles de test
3.4 Application de l’analyse de mutation adaptée au test d’une transformation
3.4.1 Un ensemble initial de modèles de test
3.4.2 Création des mutants
3.4.3 Évaluation du score de mutation initial
3.4.4 Amélioration des modèles de test en exploitant le point de vue sémantique
3.4.5 Minimisation du nombre de modèles de test
3.5 Conclusion
4 Oracles de transformations de modèles
4.1 La problématique de la construction d’oracles pour le test de transformations de modèles
4.2 Construction de six fonctions d’oracle sur la base de trois techniques d’analyse de modèles
4.2.1 Trois techniques pour analyser les modèles
4.2.2 Six fonctions d’oracle pour le test de transformations de modèles
4.3 Construction de données d’oracle
4.3.1 Illustration de la vérification de la transformation d’un modèle de test
4.3.2 Vérification complète de la transformation sous test
4.4 Permettre de qualifier les fonctions d’oracle
4.4.1 Deux qualités pour l’oracle de transformation de modèles
4.4.2 Cinq propriétés d’oracle
4.4.3 Influence des propriétés d’un oracle sur sa qualification
4.5 Qualification de chaque fonction d’oracle
4.5.1 Propriétés d’oracle
4.5.2 Qualités des fonctions d’oracle
4.6 Conclusion
5 Mise en œuvre et qualification de composants de transformation de modèles
5.1 Construction de composants de transformation de modèles de confiance
5.1.1 Formation de composants de transformation de modèles
5.1.2 Qualification des composants de transformations de modèles
5.1.3 Augmentation du niveau de confiance
5.2 Développements pour la définition, la qualification et l’amélioration de composants de confiance
5.2.1 Utilisation du langage Kermeta
5.2.2 Intégration d’un support des contraintes dans Kermeta
5.2.3 Harnais de test supportant les différentes fonctions d’oracle
5.2.4 Plate-forme pour l’application de l’analyse de mutation
5.3 Expérimentations pour le développement d’un composant de confiance
5.3.1 Étape 1 : Qualification et amélioration des modèles de test
5.3.2 Étape 2 : Test et correction d’erreur
5.3.3 Seconde itération
5.3.4 Étape 3: Améliorer les contrats
5.3.5 Conclusion des expérimentations
5.3.6 Une adaptation de la méthodologie pour l’utilisation d’un générateur de modèles
5.4 L’analyse de mutation pour l’expérimentation de critères fonctionnels
5.4.1 Critères de couverture du domaine d’entrée
5.4.2 Mise à l’épreuve de modèles satisfaisant les critères
5.4.3 Validation des critères proposés
5.5 Conclusion
6 Conclusions et perspectives
6.1 Contributions
6.1.1 Analyse de mutation pour le test de transformations de modèles
6.1.2 Oracles pour le test de transformations de modèles
6.1.3 Qualification de composants de transformations de modèles
6.2 Perspectives
Annexe A
A.1 Six modèles de test
A.2 Six modèles attendus
A.3 Contrats
A.4 Assertions de patterns de model snippets
A.5 Assertions OCL
Annexe B
Annexe C
Annexe D
Annexe E
Glossaire
Bibliographie

Lire le rapport complet