Recherche
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
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.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.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.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.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 […]
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 […]
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 […]
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
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.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.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.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.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.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.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.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.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.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.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.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.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.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.2 Documentation partielle du métamodèle « Migration Platform »
La documentation qui suit est directement extraite des informations présentes dans le modeleur UML MagicDraw sur les classes du méta-modèle « Migration Platform ». Page suivante : 7.2.1 CoreRetour au menu : Stratégie de test au sein du processus d’évolution d’architecture de Sodifrance
7.2.1 Core
Composition (Figure 43) · NamedElement – A named element represents elements with names. · Element – An element is an atomic constituent of a model. Element is an abstract element. Page suivante : 7.2.2 CodeItemsRetour au menu : Stratégie de test au sein du processus d’évolution d’architecture de Sodifrance
7.2.2 CodeItems
Composition (Figure 44) · CodeItem – CodeItem class represents the named elements determined by the programming language. · Module – The Module class is a generic modeling element that represents an entire software module or a component, as determined by the programming language and the software development environment. A module is a discrete and identifiable […]
7.2.3 Test Architecture
Composition (Figure 45) An individual line of a Test Case. Each Test Step should include instructions and an expected result. · TestItem – The TestItem is the superclass of TestUserEvent and TestExecutionNode. It represents a test step. · TestUserEvent – The TestUserEvent is used to capture user actions on the application. · TestExecutionNode – The […]
7.2.4 Test Data
Composition (Figure 46) · UIState – An UIState represents the state of a screen at the beginning (stateIn) or the end (stateOut) of an event. It’s composed by a set of UIProperty. · UIProperty – An UIProperty represents a property of an UIField. It allows capturing the value of all properties of an UI component […]
7.2.5 Traceability
Composition (Figure 47) · TraceDependency – A TraceDependency indicates that the target CodeItem is the result of the transformation of the source CodeItem. Figure 48 : Copie d’écran du logiciel MIA Transformation en mode développement Figure 49 : Copie d’écran du logiciel MIA Transformation en mode trace Page suivante : 7.3 MIA TransformationRetour au menu […]
7.3 MIA Transformation
MIA Transformation est un environnement de développement permettant l’écriture de scripts et l’exécution de ces scripts afin d’effectuer des transformations de modèles. Ces modèles doivent respecter un métamodèle supporté par l’outil afin de pouvoir être lus. Ensuite, il faut définir des règles de transformation par le biais de script écrits soit en Java, soit en […]