Recherche
admin
7.1.6 Conclusion
Le respect des préconisations du MDA (séparation entre les exigences métier d’une application et son implémentation sur une plate-forme donnée, le respect de l’architecture MDA à quatre niveaux, utilisation des transformations automatisées) permet d’obtenir un haut niveau de qualité des applications ainsi produites. La maturité atteinte par le MDA en fait un des modes de […]
7.1.5 L’avenir du MDA ?
Aujourd’hui, les réflexions évoluent pour définir ce que M. Bézivin nomme les mégamodèles (Bézivin et al. 2004). Il s’agit de monter encore en niveau d’abstraction et de voir les modèles, les métamodèles et les transformations qui composent le MDA comme les éléments d’un modèle. Ce modèle serait bien sûr conforme à un métamodèle : le […]
7.1.4.3 XMI
Les modèles ne disposant pas de représentation concrète, l’OMG a décidé de standardise XML Metadata Interchange (XMI)(Object Management Group 2007). Ce format permet de représenter un modèle sous forme de document XML. De même qu’en MDA un modèle est conforme à un métamodèle, en XML, un document peut être conforme à une DTD(30) ou à […]
7.1.4.2 Query Views Transformations (QVT)
QVT devait répondre aux propositions de l’OMG QVT Request For Proposal (Object Management Group 2002b) dont voici les principales exigences (Combemale et al. 2007) : · normaliser un moyen d’exprimer des correspondances (transformations) entre langages définis avec MOF. · exprimer des requêtes (Query) pour filtrer et sélectionner des éléments d’un modèle (y compris sélectionner les […]
7.1.4.1 Les transformations de modèles
Le passage entre les différents modèles présentés auparavant se fait par le biais de l’exécution de transformations. La Figure 38 illustre les différentes transformations que l’on peut trouver généralement dans MDA. La transformation ou projection et la retro-ingénierie peuvent être des transformations entre deux modèles conformes à un même métamodèle, on parle alors de transformation […]
7.1.4 Les transformations
Page suivante : 7.1.4.1 Les transformations de modèlesRetour au menu : Stratégie de test au sein du processus d’évolution d’architecture de Sodifrance
7.1.3.2 L’architecture du MDA
MDA définit son formalisme de modélisation, c’est-à-dire qu’il décrit la façon dont un modèle doit être structuré. Pour cela il utilise encore un modèle, qui sera le métamodèle du modèle à définir. Cela pose inévitablement la question : peut-on remonter indéfiniment dans la hiérarchie des modèles ? La réponse est non. Dans MDA, le métamétamodèle, […]
7.1.3.1 Les principaux modèles du MDA
Les principaux modèles du MDA sont : · Le modèle des exigences (Computational Independent Model, CIM) Il s’agit d’un modèle de haut niveau qui représente l’application et qui permet de définir les services qu’elle va offrir et les relations qu’elle aura avec les autres entités. Ces modèles ont pour objectif d’être pérennes et de refléter […]
7.1.3 Architecture du MDA
Page suivante : 7.1.3.1 Les principaux modèles du MDARetour au menu : Stratégie de test au sein du processus d’évolution d’architecture de Sodifrance
7.1.2.2 Domaine d’application du MDA
Figure 35 : Model Driven Architecture (Projet ACCORD 2011) Mais quel est le domaine d’application du MDA ? Les outils proposant de plus en plus d’opérations sur les modèles (générations, tests, validations, etc.), où commence et où s’arrête le MDA ? Comme on va le détailler un peu plus loin, MDA n’a d’autre préconisations que […]
7.1.2.1 Les avantages du MDA
Les avantages attendus de MDA étaient alors : · De pérenniser les savoirs faires. Les métiers des entreprises n’évoluent que très peu en comparaison des technologies informatiques utilisées pour concevoir les applications. Il est donc évident que le fait de séparer les spécifications métier des spécifications techniques va dans la bonne direction. · De gagner […]
7.1.2 Philosophie du MDA
Page suivante : 7.1.2.1 Les avantages du MDARetour au menu : Stratégie de test au sein du processus d’évolution d’architecture de Sodifrance
7.1.1 Introduction
L’initiative d’architecture dirigée par les modèles de l’OMG « Model Driven Architecture » (MDA) est motivée par les besoins de réduction des coûts de reconception et de maintenance des applications informatiques. Dans les années 1990, CORBA, spécification de l’OMG, devait fournir un environnement standard et ouvert permettant à tout type d’application d’interopérer avec les autres. […]
7.1 L’architecture dirigée par les modèles (Model Driven Architecture, MDA)
Page suivante : 7.1.1 IntroductionRetour au menu : Stratégie de test au sein du processus d’évolution d’architecture de Sodifrance
7 ANNEXES
Page suivante : 7.1 L’architecture dirigée par les modèles (Model Driven Architecture, MDA)Retour au menu : Stratégie de test au sein du processus d’évolution d’architecture de Sodifrance
6 BIBLIOGRAPHIE
Blanc, X., 2005. MDA en action 1er éd., Eyrolles. Bézivin, J., 2004. Sur les principes de base de l’ingénierie des modèles. RSTI-L’Objet, 10(4), p.145–157. Bézivin, J., Barbero, M. & Jouault, F., 2007. On the applicability scope of model driven engineering. Available at: http://atlanmod.emn.fr/www/papers/MDEApplicabilityScope.pdf. Bézivin, J., Jouault, F. & Valduriez, P., 2004. On the need for […]
5 CONCLUSION
Ce sujet de mémoire, de prime abord assez complexe dans sa réalisation, a abouti à la production d’une suite d’outils qui s’intègrent dans le processus d’évolution d’architecture. Actuellement, tous les projets de migration utilisent la cartographie des applications, des tests ou le suivi de l’intégration. Il a fallu inventer un certain nombre de solutions, jongler […]
4.3 Partenariat avec la société Kalios
Même si nous en avons la possibilité, notre but n’est pas de générer des scripts pour tous les outils de rejeu de test du marché. La réalisation de maquettes a permis de valider la viabilité de ce concept (maquette VB6 vers Java/Flex, outil de rejeu FlexMonkey). Cependant, c’est avec la société Kalios(25), qui développe le […]
4.2.2 Cartographie dynamique, état des composants graphiques
La cartographie dynamique est basée sur l’ajout d’appels à des fonctions de trace en début et en fin de méthode. L’ensemble des méthodes de l’application source étant instrumentées, cela permet d’obtenir un graphe des appels entre méthodes et donc de résoudre les appels dynamiques (cf. § 3.2.2.1). A noter que les méthodes évènementielles, produiront en […]
4.2.1 Taux de couverture
Le taux de couverture des tests de références est calculé de la manière suivante : · On ajoute un appel à une méthode de comptage pour chaque ligne de code. Chaque appel prend en paramètre un compteur qui devient son identifiant. Dans le même temps, on insère dans une table de base de données une […]
4.2 Instrumentation
J’ai réalisé une suite d’outils permettant d’injecter du code dans des applications Visual Basic. L’objectif de ces injections est de produire des traces au format XML qui seront interprétées puis insérées dans la base de cartographie. Page suivante : 4.2.1 Taux de couvertureRetour au menu : Stratégie de test au sein du processus d’évolution d’architecture […]
4.1 Réalisation d’un plugin Eclipse
Durant la réalisation de ce mémoire, j’ai eu à encadrer le stage en entreprise d’un étudiant en Master 2 en Informatique, spécialité architecture logicielle de l’université de Nantes. L’objectif de son stage était la réalisation d’un plugin Eclipse permettant de suivre l’avancement de l’intégration des projets de migration. Cet outil de suivi est centré sur […]
4 LES TRAVAUX CONNEXES
Page suivante : 4.1 Réalisation d’un plugin EclipseRetour au menu : Stratégie de test au sein du processus d’évolution d’architecture de Sodifrance
3.2.3.1 Génération des scripts de test
La génération des scripts de test se fait alors en parcourant les enregistrements de test, qui pointent sur des composants sources, et pour chaque composant, en cherchant le composant cible qui lui est associé. Pour chaque événement en base, on retrouvera trois actions de génération : · Positionner les propriétés qui n’auront pas été changées […]
3.2.3 Objectif 2 : automatisation des tests
Les tests sur les applications cibles se font à l’aide d’outils de rejeu de test, comme FlexMonkey(22) pour une application Flash par exemple. Habituellement, il faut jouer les scénarios de test sur l’application à tester afin que l’outil enregistre les actions qui sont effectuées sur l’interface graphique. L’idée de l’automatisation des tests, c’est de mettre […]
3.2.2.2 Représentation graphique de la cartographie des tests
J’ai étudié et maquetté sous forme de services Java plusieurs types de représentations graphiques. A partir des données de la cartographie d’application, j’ai produit un modèle UML qui exporté au format XMI puis importé dans MagicDraw, permet d’obtenir un diagramme de classe et de visualiser les relations entre les opérations (cf. Figure 22). Figure 23 […]
3.2.2.1 Vision statique et dynamique de la cartographie
Avant l’insertion des tests, la base de donnée ne contient que ce que l’analyseur syntaxique a pu lui fournir. Pour garder le langage Visual Basic en exemple, l’instruction : Public Function getCustomer() as clsCustomer sera interprétée comme une fonction renvoyant une instance de la classe « clsCustomer ». Dans le modèle, il en résulte la […]
3.2.2 Objectif 1 : cartographie des tests
L’instrumentation du code source, détaillé au § 4.2, doit fournir, à la suite du passage des tests de références, deux types de flux XML. Dans le premier, on va chercher à ajouter du code pour chaque méthode, juste après l’entrée et juste avant chaque instruction de sortie. On obtient ainsi une arborescence des appels de […]
3.2.1 La cartographie des applications
Avant d’approfondir les deux principaux objectifs de ce mémoire, se pose le problème essentiel de la cartographie des applications. En effet, pour pouvoir indiquer quels composants sont utilisés par un scénario de test, il faut déjà pouvoir lister de manière exhaustive l’ensemble des composants de l’application et les identifier de manière unique. Comme indiqué dans […]
3.2 Plate-forme de migration (« Migration Platform »)
La Figure 15 représente les principaux cas d’utilisation du système « Migration Platform ». Ils sont répartis de la manière suivante : · La cartographie de l’application représente la base de l’ensemble et contiendra tous les composants applicatifs du projet (fenêtres, composants graphiques, classes, fonctions). · La cartographie des tests intègre les différentes données propres […]