Master 2 Pro ALMA Université de Nantes, 2 rue de la Houssinière UFR des Sciences et des Techniques. - Rapport de Stage -

Transcription

1 Master 2 Pro ALMA Université de Nantes, 2 rue de la Houssinière UFR des Sciences et des Techniques - Rapport de Stage - Gestions de Systèmes de Systèmes Albin Jossic sous la responsabilité de Jean Bézivin Version Date Description 0. 24/08/06 Création du document / 09/ 06 Relecture et corrections / 42

2 Albin Jossic Master 2 Professionnel ALMA, promotion 2006 Stage «Gestion de Systèmes de Systèmes» 42 pages 2 / 42

3 Résumé Dans le domaine de l ingénierie des systèmes informatiques, nous avons besoin de maintenir un certain contrôle durant le cycle de vie des systèmes. Ceci est particulièrement vrai pour les Systèmes de Systèmes qui ont une nature dynamique et complexe. Dans un souci de management global de ces systèmes, la terminologie définie par le IEEE [] introduit les concepts de Vue et de Point de vue afin de décomposer les descriptions d architecture. Une Vue, conforme à un Point de Vue, représente une perspective sur le système en capturant les aspects en accord avec les intérêts des personnes pour lesquelles cette vue est destinée. DoDAF (Department of Defense Architecture Framework) [49] est basé sur ces concepts. Ce framework propose plusieurs points de vue pour définir une vue sur une architecture de système. Il est possible de définir dans une vue DoDAF une matrice de traçabilité. Celle-ci est calculée à partir de deux autres vues. Le but est de générer la matrice avec un processus automatisé. En reposant sur les principes du MDE (Model Driven Engineering) [], il est possible de représenter les vues DoDAF par des métamodèles. Le processus utilisé crée un modèle de tissage entre les métamodèles et, à partir de ce résultat, génère les transformations entre les modèles. Ce processus permet de produire l intégration de données entre les modèles. Les transformations nécessaires à ce processus ainsi que les modèles et métamodèles sont définis sur la plateforme AMMA [73]. Cette plateforme propose un langage de transformation ATL [25] et un langage de définition de métamodèles KM3 [24]. 3 / 42

4 Table des matières Introduction Plateforme AMMA Architecture MDA proposée par l'omg Présentation de la plateforme AMMA Systèmes de Systèmes Concepts de l ingénierie des Systèmes informatiques Systèmes Informatiques Systèmes Complexes Systèmes de Systèmes Vue et Point de Vue Présentation d Architecture Frameworks C4ISR DoDAF MoDAF AGATE SysML MARTE SDM Transformation IEEE vers MoDAF Processus d intégration de modèle Cadre des travaux Cas d étude Solutions envisagées Chevauchements entre les vues DoDAF Model Integration Représentation des vues DoDAF avec une approche MDE Matching Modèle de tissage Calcul des Equivalences Class-to-Class Equivalence StructuralFeature-to-StructuralFeature Equivalence Filtrage des résultats Génération des Transformations Fusion de Transformations Transformation de SV-5 vers SV Conclusion Remerciements Bibliographie et références Annexes Glossaire / 42

5 Introduction A l heure actuelle, l Architecture des systèmes informatiques croît en complexité. Un système informatique est un ensemble des composant mis en interaction afin de produire des fonctionnalités. Il existe deux raisons principales à cette évolution. La première cause est la distributivité des composants. En effet, un système informatique est le plus souvent partagé sur plusieurs ordinateurs et donc réparti entre plusieurs lieux. La deuxième cause se traduit par le fait que le nombre des composants est grandissant et qu il faut prendre en compte l interopérabilité entre eux. Un composant d un système informatique peut être un logiciel, un matériel physique ou bien encore un autre système informatique. C est cette dernière possibilité qui nous dirige vers le concept de Système de Systèmes. Dans l industrie du génie logiciel, les phases de conception, de déploiement, de maintenance et de révision, du cycle de vie d un système, requièrent de plus en plus de ressources humaines et temporelles pour les entreprises. Il devient nécessaire d explorer les moyens de décroître le coût de gestion des systèmes informatiques. Une des approches possibles est l ingénierie dirigée par les modèles. Le but de cette approche est de lier l architecture du système au modèle qui le représente. Il est ainsi plus aisé de manipuler le modèle plutôt que le système faisant partie du monde réel. Dans cette optique, un modèle de système doit être capable de capturer la structure ainsi que les caractéristiques propres au système. La complexité des Systèmes de Systèmes implique que chaque individu agissant durant le cycle de vie désire une perspective personnalisée. En effet, les personnes concernées par un système ont besoin d une représentation en accord avec leurs intérêts et leurs compétences vis-à-vis du système. Ceci dans le but de faciliter la gestion de chaque aspect d un système. La terminologie du IEEE [] définit les concepts de Vue et de Point de Vue. Un Point de Vue décrit les moyens et les méthodes pour définir une Vue sur un système. Une Vue représente une perspective sur le système. La majorité des frameworks d architecture sont inspirés de cette terminologie. Dans une politique de management global de Systèmes de Systèmes, il est possible de montrer qu il existe des interactions et des relations entre les vues d un système. Entre autres, certaines vues sont calculées à partir d autres. Le framework d architecture DoDAF [2][3] sera utilisé comme cas pratique. Dans DoDAF, il existe une vue dédiée aux matrices de traçabilité. Cette dernière peut être calculée à partir d une vue dédiée aux fonctionnalités du système et d une vue dédiée aux capacités opérationnelles. Le but est de définir un moyen d aboutir à la génération d une matrice de traçabilité par un processus automatisé. Afin de réaliser ce travail, nous nous appuyons sur le socle technique définit par l équipe de recherche ATLAS [4] de l INRIA [5]. Cette équipe a réalisé la plateforme AMMA [6][7] reposant sur les principes de l ingénierie dirigée par les modèles. La partie 2 décrit les principes de l ingénierie dirigée par les modèles et présente la plateforme AMMA. La partie 3 définit les concepts du domaine de l Architecture des systèmes et présente un ensemble de frameworks majeurs d architecture. La partie 4 présente un cas pratique mettant en évidence le lien entre la terminologie IEEE et les frameworks d architecture. La partie 5 décrit le processus suivit afin de générer une matrice de traçabilité pour DoDAF. La partie 6 relate le travail réalisé et sur les techniques mises en œuvre durant ce stage. 5 / 42

6 2 Plateforme AMMA Le but de ce chapitre est de définir les principes dans lesquels s inscrit la plateforme AMMA et le socle technique proposé par cette plateforme. Ainsi, ce chapitre se compose de deux sous-parties. La partie 2. décrit les principes généraux proposés par l ingénierie dirigée par les modèles. La partie 2.2 présente l ensemble des outils et langages fournis par la plateforme AMMA. 2. Architecture MDA proposée par l'omg Le Model Driven Architecture (MDA) [8][9] est un framework pour le développement des logiciels informatiques. Il a été proposé par l Object Management Group (OMG) [0]en 200. Le concept général de cette approche est que tout système appartenant à n importe quel domaine d application, peut être modélisé avec suffisamment d abstraction. Ceci dans le but de produire des modèles pouvant être mis en œuvre de manière relativement automatisée sur le plus grand nombre possible de plateformes technologiquement différentes. Figure La vision du MDA par l OMG Le concept de l ingénierie dirigée par les modèles ou Model Driven Engineering (MDE) [] peut être vue comme une généralisation du MDA. Cette approche introduit les concepts de modèle, métamodèle, langage de modélisation et de transformation de modèles. Elle propose aussi une classification des modèles. Le MDA définit deux classes de modèles : Platform Idenpendant Models (PIMs) and Platform Specific Models (PSMs). Les PIMs représentent une vue sur un système avec un point de vue indépendant de la plateforme. Les PSMs représentent une vue sur un système avec un point de vue dépendant de la plateforme. Le MDA fourni la définition suivante au concept de plateforme dans le guide du MDA [9] : A platform is a set of subsystems and technologies that provide a coherent set of functionality through interfaces and specified usage patterns. Which any application supported by that platform can use without concern for the details of how the functionality provided by the platform is implemented. 6 / 42

7 La vision MDE est donc basée sur les modèles. En particulier sur les notions de modèle et métamodèle. Elle organise ces concepts selon une hiérarchie représentée dans la Figure 2. Dans le MDE, les modèles sont les entités racines et sont classés en trois catégories différentes : les modèles terminaux, les métamodèles et les métamétamodèles. Chaque modèle est conforme à son modèle de référence, i.e. un métamodèle ou un métamétamodèle. Il faut noté que le modèle de référence d un métamétamodèle est toujours lui-même ; c est-à-dire qu un métamétamodèle est réflexif. Un modèle terminal est conforme à un métamodèle et représente un système du monde réel. Modeling World Real World conformsto (c2) MetaMetaModel 0.. ReferenceModel MetaModel Model TerminalModel Figure 2 Theoretical aspects of our MDE approach representationof (repof) System Les définitions suivantes sont des définitions conceptuelles. Elles proviennent des articles [2], [3] et [4] : Definition. A system is a delimited part of the world (the real world ) considered as a set of elements in interaction. It can be represented in terminal models. Definition 2. A model is a representation of a given system. For each question of a given set of questions, the model will provide exactly the same answer that the system would have provided in answering the same question. Definition 3. A terminal model (M) is a model such that its reference model is a metamodel, i.e. it conforms to its reference metamodel. It is a representation of a real world system. Definition 4. A metamodel (M2) is a model such that its reference model is a metametamodel, i.e. it conforms to its reference metametamodel. Definition 5. A metametamodel (M3) is a model that is its own reference model, i.e. it conforms to itself. Il existe entre l ensemble des concepts définit précédemment des propriétés. Celles-ci peuvent s exprimer à l aide de contraintes OCL (Object Constraint Language de l OMG) [5]. La Figure 3 présente l ensemble des contraintes entre les concepts de la Figure 2. 7 / 42

8 Modeling World 0.. Model conformsto (c2) ReferenceModel TerminalModel MetaMetaModel MetaModel -- A TerminalModel conforms to a MetaModel context TerminalModel inv: self.conformsto.ocliskindof(metamodel) -- A MetaMetaModel conforms to itself context MetaMetaModel inv: self.conformsto = self -- A MetaModel conforms to a MetaMetaModel context MetaModel inv: self.conformsto.ocliskindof(metametamodel) Figure 3 OCL constraints on some MDE general concepts Dans cette partie, nous avons décrit l approche MDE avec ses concepts généraux. Dans la suivante sous-partie, nous présentons la plateforme AMMA de l équipe ATLAS proposant des outils et des langages suivant l approche MDE. 2.2 Présentation de la plateforme AMMA La plateforme AMMA (ATLAS Model Management Architecture) [72][73] s inscrit dans le domaine du MDE. Elle a été conçue par l équipe ATLAS (ATLantique data Systems) [4] de l INRIA (Institut National de Recherche en Informatique et en Automatique) [5]. Cette plateforme est matérialisée par trois projets. Le premier projet est AM3 (ATLAS MegaModel Management) [4][6]. Le but de ce projet est de fournir un environnement de management global des modèles tels qu ils sont vus dans le MDE. Cette approche est définit dans l article [7]. Le second projet est ATL [8] (ATLAS Transformation Language). Ce projet fourni des facilités et un langage (nommé aussi ATL) pour transformer les modèles. Le troisième projet est AMW (ATLAS Model Weaving). Le projet AMW (ATLAS Model Weaver) [9][20] est conçu pour fournir des facilités pour représenter des correspondances entre des modèles. Ces correspondances sont stockées dans un modèle de tissage (Weaving Model) conforme à un métamodèle de tissage (Weaving Metamodel). AM3 pour «ATLAS Megamodel Management» ATL pour «ATLAS Transformation Language» AMW pour «ATLAS Model Weaver» L ensemble de ces outils est conçu au-dessus du plugin Eclipse Modeling Framework (EMF) [2] de la plateforme Eclipse. Ils font partie du sous-projet Eclipse GMT (Generative Modeling Tools) [22] et sont aussi des plugin Eclipse. En plus de ces outils, la plateforme AMMA fournit trois DSLs (Domain Specific Languages) [23]. Les DSLs : KM3, ATL et TCS forment le noyau de AMMA. Le langage 8 / 42

9 KM3 (Kernel MetaMetaModel) [24] est un langage de définition de métamodèles. Ce DSL propose une syntaxe textuelle simple et courte afin de créer et modifier facilement des métamodèles. Le langage ATL [25], comme dit précédemment, est un langage de transformation. Il a la particularité d être déclaratif, i.e. une transformation ATL est écrite sous forme de règles. Ce DSL de transformation de modèles est similaire au langage QVT (Query View Transformation) [26] proposé par l OMG. Le langage TCS (Textual Concrete Syntax) [27] est un autre DSL utilisé pour spécifier des syntaxes textuelles indépendantes du contexte (en anglais : Context-free Textual Syntaxe). A partir de grammaires spécifiées en TCS, un modèle peut être sérialisé sous la forme textuelle équivalente et inversement un texte peut être parcouru pour être stocké sous la forme d un modèle. Il est alors possible de générer des injecteurs et projecteurs entre les espaces techniques des grammaires et des modèles. Dans le but de pouvoir faire plusieurs actions à la suite de manière automatique, la plateforme AMMA possède différentes Ant Tasks [28]. Elle sont spécifiques à la plateforme et sont nommées AM3 Ant Tasks [29] car elles sont considérées comme faisant partie du plugin AM3. Elles permettent de charger un modèle, d injecter une ressource sous forme de modèle, de sérialiser un modèle sous forme textuelle. De plus, une Ant Task permet de définir les paramètres et d exécuter une transformation ATL. L ensemble des outils et des DSLs proposé dans la plateforme AMMA, définit le socle technique de l approche suivie. En effet, le fait d appliquer une approche MDE au domaine des frameworks d architecture de Systèmes de Systèmes implique le besoin de moyens techniques. Le chapitre 3, dans sa première partie, introduit les concepts de référence du domaine de l ingénierie des systèmes informatiques. Dans une deuxième partie, ce chapitre définit les concepts de Vue et de Point de Vue sur système. De plus, dans une troisième partie, ce chapitre relate un ensemble représentatif de frameworks d architecture. 3 Systèmes de Systèmes Le domaine des systèmes informatiques définit plusieurs classes de systèmes. Les Systèmes de Systèmes représentent une de ces classes. Ces systèmes informatiques ont la particularité de pouvoir être composés de sous-systèmes. Les Systèmes de Systèmes sont généralement utilisés pour répondre à des problématiques de distributivité et d hétérogénéité et qui peuvent être organisées en réseaux. Les Systèmes de Systèmes sont généralement utilisés par des organisations conséquentes telle que l armée. Dans une approche MDE et dans le but de modéliser de tels types de systèmes, la terminologie IEEE pose un certain nombre de concepts. Les concepts majeurs sont les notions de Vue (en anglais : View) et de Point de Vue (en anglais : Viewpoint) possibles sur un système. Chaque Point de Vue sur un système permet de définir une Vue, pour un type de personnes selon leurs intérêts envers le système. Il existe un ensemble conséquent de frameworks d architecture (en anglais : Architecture Framework ou AF) tel que Zachman Framework [30], MoDAF [3], DoDAF [32], ToGAF [33], AGATE [34], RM-ODP [35]. La majeure partie d entre eux est inspirée de la terminologie du IEEE et leurs spécifications sont décomposées selon le principe de Viewpoint. Ce chapitre est organisé de la manière suivante. La section 3. décrit un ensemble de définitions conceptuelles du domaine des systèmes informatiques. La section 3.2 présente les concepts de View et de Viewpoint tels qu ils sont définis dans la terminologie du IEEE 47-9 / 42

10 2000 ainsi qu un ensemble d autres concepts qui leur sont associés. La section 3.3 contient un ensemble de descriptions de AFs étudiés durant ce travail. 3. Concepts de l ingénierie des Systèmes informatiques Le but de ce sous-chapitre est de préciser la classification des systèmes informatiques. Afin de donner une description des caractéristiques principales des Systèmes de Systèmes, il nous faut définir le concept de Système. De plus, les Systèmes de Systèmes sont généralement admis comme faisant partie de la classe des systèmes dits complexes (en anglais : Complex Systems). En effet, les Systèmes de Systèmes sont, le plus souvent, composés d autres systèmes qui peuvent être eux-mêmes des systèmes complexes. Nous avons donc besoin de préciser les trois notions suivantes : Système, Système Complexe et Système de Systèmes. 3.. Systèmes Informatiques Un Système informatique est une combinaison de plusieurs entités où chaque composant à une relation avec au moins un autre. Un système a une interface pour interagir avec son environnement extérieur. En cela, un système peut être vu comme une seule entité par rapport à son environnement. Dans ce sens, un système prend en entrée un flux d informations, effectue des opérations et retourne des valeurs en sortie. A l intérieur du système, chaque composant a une interface afin d échanger des flux d informations. Ainsi, un système informatique est un ensemble de composants mis en interaction selon une organisation qui définit son architecture afin de produire des fonctionnalités Systèmes Complexes Dans les systèmes, de manière générale, les fonctionnalités produites par des interactions, caractérisées de linéaires, ont des effets proportionnels à leur cause. Ainsi, les Systèmes Linéaires correspondent à la somme de leurs parties car ils sont soumis au principe de Superposition. La Superposition correspond à la configuration où les comportements des composants du système sont mis bout à bout dans le but de rendre une fonctionnalité donnée. En opposition aux Systèmes Linéaires, les Systèmes Complexes [36] sont non-linéaires dans le sens où ils sont plus que la somme de leur parties. Ceci est dû au fait qu il existe des interactions non-linéaires entre les composants des Systèmes Complexes. Une interaction non-linéaire signifie qu il n est pas possible d en prédire l effet exact à partir de la cause. De plus, les Systèmes Complexes sont dynamiques car leur comportement peut évoluer au court du temps, i.e. leurs comportements peuvent différents à différents moments. Mais il est le plus souvent possible d extraire des propriétés émergentes du comportement global de ce type de systèmes. Les Systèmes Complexes sont le plus souvent associés à des problèmes tels que les fourmilières, les systèmes nerveux ou bien des organisations économiques. Généralement, ce type de systèmes est modélisé par des techniques mathématiques telles que les équations différentielles, les méthodes de Markov (méthodes stochastiques) [39] et la théorie des graphes. Les Systèmes Complexes ne sont pas généralement utilisés pour représenter des systèmes informatiques à cause de l incertitude qui peut y exister. En contrepartie, les systèmes 0 / 42

11 informatiques d une grande complexité peuvent certainement être considérés comme des Systèmes Complexes Systèmes de Systèmes Les Systèmes de Systèmes (en anglais : Systems of Systems) ou SoSs [37][38] sont des Systèmes Complexes qui sont composés d autres Systèmes Complexes. Les SoSs ont des propriétés communes. Chaque composant des SoSs est indépendant vis-à-vis de leur fonctionnement et de leur gestion. Les systèmes de type SoS sont dynamiques et peuvent évoluer au cours du temps. Ils sont généralement distribués géographiquement et organisés en réseaux. Les composants des SoSs sont hétérogènes et posent donc des problèmes d interopérabilité. Comme les Systèmes Complexes, les SoSs sont interdisciplinaires. Ils sont le plus souvent utilisés pour des systèmes militaires, pour des systèmes de transport ou bien encore pour des systèmes d informations d entreprises privées. Le but de l ingénierie des systèmes informatiques est de pouvoir concevoir, déployer, faire évoluer et maintenir ce type de systèmes. Dans ce but, la propriété d émergence doit être minimisée. Le plus souvent, elle n existe ou n est pas prise en compte dans la représentation des systèmes informatiques. Dans le domaine de l architecture logiciel, il existe des Architecture Frameworks (AFs) permettant de modéliser les SoSs. La complexité de ces systèmes implique la complexité des modèles. Le IEEE introduit les concepts de Vue et de Point de Vue afin de palier ce problème. Ainsi un système est représenté par plusieurs modèles donnant chacun une perspective sur le système, i.e. chaque modèle ou vue sur le système ne prend en compte qu un certain nombre de caractéristiques qui ont un intérêt commun. Le sous-chapitre 3.2 a pour but d introduire ces notions car la majorité des AFs proposant un métamodèle des SoSs utilisent ces concepts tels qu ils sont définis dans le IEEE Vue et Point de Vue Le but de ce sous-chapitre est d introduire les concepts de Vue et de Point de Vue provenant du domaine des descriptions d architecture de systèmes informatiques. Ces notions sont souvent mentionnées dans la littérature ([4] [42] [43] [44] [66]) mais leurs définitions ne semblent pas encore être figées. Par exemple, dans l article [40], Kruchten utilise le terme de Vue à la place du terme Point de Vue car il n utilise pas le terme de Vue de la terminologie du IEEE []. Le IEEE s Architecture Working Group (AWG) a développé cette terminologie pour le domaine des descriptions d architecture. Cette approche se retrouve dans plusieurs AFs tels que RM-ODP, MoDAF et DoDAF. Dans le document de référence [], le IEEE s AWG a voulu formaliser un moyen pour la création, l analyse et le développement des systèmes informatiques. Le but est de pouvoir fournir des frameworks de descriptions d architecture. Le IEEE introduit plusieurs concepts et formalise leurs définitions conceptuelles. Le point central de cette terminologie est les concepts de View et de Viewpoint. Ceux-ci sont en relation avec d autres tels que Architecture Description (AD), Software-Intensive System (SIS), Architecture, Stakeholder, Concerns et Rationale. Le IEEE fournit les deux définitions suivantes pour les concepts de View et de Viewpoint : / 42

12 View: a representation of a whole system from a perspective of a related set of concerns. Concerns are those interests which any aspect that are important for system stakeholder. Viewpoint: a specification of the convention for constructing and using a view. A pattern or template from which to develop individual view by establishing the purposes and audience for a view and the techniques for its creation and analysis. Afin de mieux comprendre ces concepts, nous avons voulu reformuler ces définitions conceptuelles. Pour cela, notre point de départ est la terminologie IEEE [] plus une partie des recherches R. Hilliard décrit dans les articles [4], [42] et [44]. Pour une approche plus générale, nous nous sommes inspirés de RM-ODP [35] et du travail de Kruchten [40]. Les termes définis, ici, sont les mêmes que ceux du IEEE : Definition 6. An architecture is the organization of a system, in a given environment, which defines all the system components and their relationship. Definition 7. A stakeholder is a person or a group of persons who has at least one interest about the system during its lifecycle. A stakeholder could design, develop, maintain or operate systems. Definition 8. A concern is the formalization of a stakeholder interest. A set of concerns can identify a possible viewpoint on the system architecture. Definition 9. A view represents the knowledge of a stakeholder about a system trough its architecture and conforms to one viewpoint (i.e. a view is a perspective of a system). A view is generally a set of documents and models. Definition 0. A viewpoint provides a method and/or a language to specify a stakeholder view on an architecture description in according to a set of concerns. A viewpoint is not in connection with a particular architectural description. Definition. An architectural description is the whole of stakeholder views conforms to the viewpoints selected by a rationale. An architectural description may be not encompassing all aspects of the described architecture. Definition 2. A rationale provides the organization of the selected viewpoints for an architectural description. L ensemble de ces concepts clés du domaine des descriptions d architecture et leurs relations sont représentés dans la Figure 4. Dans celle-ci, un System et son Architecture sont identifiés pour un Environment donné. Un système est capable de fournir des fonctionnalités représentées par des Missions. Une classe de System Stakeholders définit les Concerns en mettant en évidence les aspects les plus importants du système pour cette classe. Selon les intérêts (i.e. les Concerns) des personnes, il est possible de leur assigner le point de vue (i.e. le Viewpoint) le plus approprié dans le but de concevoir une description architecturale (i.e. Architectural Description). Une Architectural Description est un ensemble de Models organisé selon les vues (i.e. Views). L organisation des vues est le résultat du raisonnement (i.e. Rationale) suivi pour aboutir à l Architectural Description. 2 / 42

13 Mission.. Environment System Architecture has identifies.. Stakeholder Concern Viewpoint View LibraryViewpoint inhabits influences isimportantto.... usedtocover fulfills has.... hassource hasan.. isadressedto selects ArchitecturalDescription Model Rationale conformst.. participatein consistof establishesmethodsfor organizedby.. describedby.. aggregates Figure 4 IEEE 47, Conceptual model of Architectural Description.. provides Selon la vision du IEEE , les concepts de View et de Viewpoint sont en relation par un lien de conformance. Ceci est dû au fait qu une Vue sur un système est obtenue aux moyens des méthodes, des techniques et des langages décrits par un Point de vue. Cela implique qu une vue est conforme à un seul Point de vue. Il est d ailleurs possible de comparer les concepts de Vue et Point de Vue, du domaine des descriptions d architecture, avec les concepts de Modèle et de Métamodèle du domaine du MDE. Il est à noter que le lien de conformance dans les deux différents domaines n ont pas la même signification bien qu elle soit proche. Une vue définie à partir d un point de vue est liée à une description d architecture. Tandis que le point de vue, ayant permis d aboutir à une perspective sur un système n est pas lié à ce dernier. Les Viewpoints peuvent être formulés et définis indépendamment des descriptions d architecture pour lesquelles ils sont utilisés. A partir de là, il est possible de définir une librairie de points de vue généraux. Dans cette optique, Kruchten dans l article [40] met en évidence un ensemble de points de vue possibles sur un système. Par exemple, il formule un point de vue sur l architecture physique d un système. Ce point de vue prend en compte les contraintes non fonctionnelles telles que la tolérance aux fautes, la scapabilité et la performance. Il a pour but de décrire la répartition physique du système sur ces nœuds... Les notions de Vue et de Point de Vue, dans le domaine de l ingénierie de systèmes informatiques, permettent de factoriser la représentation des systèmes. De cette manière, un modèle d un système ne prend en compte qu un certain nombre d aspects. Une grande partie des Architecture Frameworks, utilisés pour la représentation des systèmes informatiques, ont été spécifiés en plusieurs points de vue qui ont chacun leur propre métamodèle. Une traduction de la terminologie du IEEE , sous la forme de métamodèle exprimé en KM3, est disponible dans l Atlantic Zoo sous le nom de Conceptual Model IEEE [45]. 3 / 42

14 Le sous-chapitre 3.3 suivant contient un ensemble de présentations de AFs. Certains proviennent du domaine militaire tels que MoDAF et AGATE, d autres proviennent du monde industriel comme SDM (Microsoft) et ToGAF (The Open Group). 3.3 Présentation d Architecture Frameworks Le sous-chapitre 3.3 présente un ensemble représentatif de AFs présents dans le monde militaire et dans le monde de l industrie. Dans le domaine de l ingénierie des systèmes informatiques, les AFs [46] ont pour but de proposer des spécifications afin de définir des descriptions d architecture. Ils sont généralement organisés en point de vue et proposent, pour chaque, des méthodes et des langages permettant de définir des vues sur les systèmes. Avec une approche MDE, les points de vue peuvent être représentés par des métamodèles C4ISR Le C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance) [47][48] est un AF défini par le AWG. Sa version actuelle est 2.0. Le C4ISR est utilisé pour décrire des systèmes militaires. Le but est de fournir une approche MDE pour la planification, la prise de décision et l exécution de simulations de combat. Ce framework d architecture sert de base à DoDAF (cf ) et s appui sur la terminologie du IEEE Le C4ISR fournit trois types de Viewpoints pour modéliser les architectures de système. Le premier type est les Operational Views. Ils ont pour but de représenter les fonctionnalités rendues par les composants et le système lui-même. Le deuxième type est les System Architecture Views. Ils ont pour but de représenter l étendu géographique du système et l interconnexion entre les noeuds. Le troisième type est les Technology Views. Ils ont pour but de définir les contraintes et l interopérabilité entre les composants du système. La Figure 5 représente un métamodèle simplifié du CADM (Core Architecture DataModel) du C4ISR. Le point de vue décrit ici prend en compte les entités de haut niveau dans la hiérarchie du C4ISR. Ces entités ne représentent que dix pourcents de l ensemble des entités utilisées dans les points de vue du C4ISR. Le but de ce point de vue est de représenter d une manière globale l architecture d un système. Un certain nombre de ces entités est commun au framework DoDAF tels que ActivityModel, Capability, InformationAsset et Task. 4 / 42

15 isspecifiedusing Guidance Document isspecifiedin Agreement Requirement iscitedby appliesto ExchangeNeedLineReq System performsto InfoExchRequirement uses DoDAF EquipmentType isfocusof Capability MaterielItem Mission FunctionalArea SoftwareItem performsto citedin Architecture Organization uses has MissionArea supports Standard Task hasservicesprovidedby Figure 5 C4ISR CADM Facility owns ConceptualDataModel Node 0.. Action InformationAsset ActivityModel isparticipatedin involvedin Network involvedin DoDAF (Department of Defense Architecture Framework) [2][32] a été développeé par le département de la défense américaine. Sa version actuelle DoDAF.0 date du 30 Août Cet AF est utilisé pour décrire des architectures militaires et est destiné au centre de commandement. Il prend son origine du C4ISR (cf. 3.3.) et est donc basé sur la terminologie du IEEE DoDAF est décomposé en plusieurs points de vue. Il en existe quatre types : Operational View (OV), Structural View (SV), Technical Standards Views et All Views. Les métamodèles représentés par les diagrammes suivants sont spécifiés des Viewpoints décrit dans le Volume I des spécifications de DoDAF [49]. System SystemRoleInterface terminatesat originatefrom fulfills SystemRole performs SystemFunction ServiceDependency ServiceProvider Service ServiceMediator ServiceBroker ServiceLocator ServiceRegistry Figure 6 Node Transparent SV- 5 / 42

16 SystemsNode terminatesat SystemRoleInterface originatefrom groups SystemAtNode references System Figure 7 Internodal SV- L exemple de la Structural View (Figure 6 et Figure 7) représente la structure des noeuds d un système. Dans DoDAF, SV- est représentée par plusieurs métamodèles même si elle ne représente qu un seul point de vue. WSV missionid : String weaponsystemid : String videotype : String iscontainedin 0.. ResultsData sourceid : String timestamp : String CombatReport friendlyunitsinvolved : String combatlocation : String resultsassessment : String duration : String MIDB holds Target MISREP missionid : String missionobjectives : String missionassessment : String TargetMaterialsAnalysis targetid : String 0.. Imagery imagetype : String spectraldata : String geospatiallocation : String imagesize : Integer describes 0.. BDAReport targetid : String reportsourceid : String assessmentsummary : String damageobjective : String validityduration : String MunitionsEffectsAssessment TargetNomination CollectionRequirement sourceid : String collectiontargetid : String tobedonebytime : String specialneeds : String ATO timeperiod : String 0.. Figure 8 OV-7 Logical Data Model & SV- Physical Schema 0.. RestrikeRecommendation Dans DoDAF, l exemple des points de vue OV-7 Logical Data Model et SV- Physical Schema (Figure 8) montre que plusieurs points de vue peuvent être représentés par un seul métamodèle. Les deux exemples, ici, montrent qu il n existe pas de règle pour modéliser un point de vue. Mais le plus souvent un point de vue est représenté par un seul métamodèle. C est le cas pour la majorité des autres points de vue de DoDAF. 6 / 42

17 3.3.3 MoDAF MoDAF (Ministry of Defense) [50] a été développé par le Ministère de la Défense britannique. Bien qu il soit basé sur DoDAF (cf ), cet AF est dédié aux descriptions d architecture des entreprises. La Figure 9 représente l organisation des descriptions d architecture dans le framework MoDAF. Ce diagramme représente un point de vue haut niveau de MoDAF. MoDAFElement Taxonomy.. uses ArchictecturalDescription compriseasetof.. ArchitecturalProduct appliedto.. appliedto.... conformsto.. conformsto Figure 9 MoDAF All View MetaData ArchitectureMetaData ArchitecturalFramework ArchitectureMetaData La Figure 0 représente le point de vue architectural dans MoDAF. Ce métamodèle montre l implémentation dans MoDAF de la terminologie du IEEE bien qu il existe des différences. Dans MoDAF, Enterprise représente le même concept que l entité System dans le IEEE En effet, Enterprise évolue dans un certain Environment et produit des fonctionnalités représentées par Missions. L entité Enterprise a une architecture dans le monde réel. Dans MoDAF, Une Architectural Description est un ensemble de Documents représentant une architecture de systèmes. Le concept de Stakeholder est similaire à celui du IEEE Une classe de Stakeholder peut représenter une personne, une équipe ou bien une organisation. Le concept de Concerns représente les intérêts des personnes concernées par le système. Les Concerns sont des aspects du système telles que la distributivité ou la sécurité. Architectural Product définit le même concept que View du IEEE et View dans MoDAF représente celui de Viewpoint. La relation entre Architectural Product et View dans MoDAF est la même que celle qui lie les concepts de View et de Viewpoint. Ainsi l organisation et les concepts dans l Architectural View de MoDAF sont très proches de la terminologie du IEEE Il est ainsi possible d implémenter une transformation entre leurs métamodèles. Ce travail est décrit dans le chapitre 4. definesasetof.. 7 / 42

18 IEEE47::System influences inhabits Environment Enterprise fulfills.. OperationalMission Architecture describedby ArchitecturalDescription approvalauthority : String architect : String assumptionsandconstraints : String creatingorganisation : String datecompleted : String purpose : String recommendations : String summaryoffindings : String toolsused : String viewpoint : String referred ArchitecturalReference referrer AGATE IEEE47::View.. products Stakeholder ArchitecturalFramework ArchitecturalProduct description : String MetaData StakeholderHasConcern definingframework dublincoreelement : String definingview modmetadataelement : String name : String View ownedmember framework : String usedtocover frameworkwebsite : String Concern viewcode : String.. viewdescription : String.. viewname : String IEEE47::Viewpoint Figure 0 MoDAF Architecture View annotatedarchitecture ArchitectureMetaData AGATE (Atelier de Gestion de l'architecture des Systèmes d'information) [5][52] a été conçu par la DGA française (Délégation Générale pour l Armement). Le but, à travers ce framework, est de pouvoir modéliser et gérer les architectures des systèmes informatiques. La version actuelle de ce framework est AGATE 3.0. Il existe plusieurs points de vue possibles dans AGATE. Il sont au nombre de six : Héritage, Métier, Service, Logique, Technique et Optionnel. Ce framework est généralement dédié pour la conception d organisations militaires. Le diagramme dans la Figure représente le métamodèle du point de vue de l héritage dans AGATE. Seul ce diagramme est présenté car il contient l ensemble des entités et des concepts existants dans le AF AGATE. client supplier 8 / 42

19 Object ID : String AGATEObject notice : String description : String sensitivity : Integer name : String comment : String ReferenceObject name : String description : String Process MADIOSObject Activity ReferenceTechnicalComponent ReferenceLogicalComponent Procedure Operation ReferenceService isvalidin Objective OperationalContext Means DomainRelation ArchitectureObject Project Standard Threat TrafficClass InterfaceCharacteristic SysML ContextProjectElement Requirement Stake Risk Event DataClass Process HierarchicalRelation FunctionalRelation Site Procedure deployedobjects OrganizationObject Operation Activity ReusableObject Figure AGATE Heritage View Package Service TechnicalComponent LogicalComponent OperationalFunction Interface Interconnection groupedobjects CommunicationObject conficialitylevel : Integer InformationFlow Traffic Information SysML (Systems Modeling Language) [53][54] a été défini comme standard de l OMG [0] le 3 Mai Il défini un framework d architecture dédié à la conception de systèmes complexes. SysML étend les spécifications de UML [55], il est d ailleurs devenu un profil UML. Figure 2 SysML an extension of UML (taken from Le framework SysML utilise la terminologie du IEEE concernant les principes de Vue et de Point de Vue. La figure suivante Figure 3 représente le métamodèle du package Model Elements qui est le noyau de SysML. 9 / 42

20 Entity NamedElement name : String Dependency Package Class Comment Conform MARTE View conformsto : Viewpoint source Viewpoint stakeholders[] : String purpose[] : String concerns[] : String languages[] : String methods[] : String traget Rationale Figure 3 SysML package ModelElements Problem MARTE (Modeling and Analysis of Real-Time and Embedded systems) [56][57] est un AF dédié aux systèmes embarqués nécessitant des contraintes de temps réel. La spécification de ProMARTE [58] est devenu par la suite un profil UML le 4 Novembre MARTE est décomposé en plusieurs points de vue et sous points de vue. Les principaux sont : Time Models, Non-Fonctional Properties, Core Resource Model, Hardware Execution Platform et Quantitative Analysis Modeling. La Figure 4 présente le métamodèle du point de vue concernant les entités métiers d un système décrit dans MARTE. ModelElement ownes modeledsystem describedby owner dimension System Quantity BasicQuantity Model relevantquantity ModelingConcern.. measurementquantity conformsto DerivedQuantity AnalysisConcern DesignConcern annotatedmodel referto AnnotatedModelElement AnnotatedModel NFPLibrary annotatedelement annotates import storedby ownes NFPCategory owner0.. annotation NFP usednfp setof.. groupedby Figure 4 MARTE Domain Model 20 / 42

21 3.3.7 SDM Le SDM (System Definition Model) [60] a été développé par Microsoft. Il est le cœur du DSI (Dynamic Systems Initiative) [59] de Microsoft qui représente la volonté de cette entreprise dans le domaine de l ingénierie des systèmes informatiques. Le SDM est implémenté en XSchema [64] et les modèles de systèmes sont donc en XML [63]. La notion de Point de vue ne transparaît pas directement dans le métamodèle SDM. En fait Microsoft, dans sa plateforme de développement Visual Studio 2005 Team System [6], propose trois outils différents. Chacun de ces outils correspond à un point de vue. La Figure 5 illustre la décomposition du framework d architecture de Microsoft : Class Designer Class Definitions Application Definitions Application Designer System Designer System Definitions Distributed System Designers Deployment Designer Figure 5 DSDs Overview in VSTS Logical Datacenter Designer Logical Datacenter Definitions L Application Designer est dédié aux développeurs des fonctionnalités du système. L outil System Designer permet de définir l architecture du système logique. Le Logical Datacenter Designer permet de spécifier le matériel physique sur lequel le système sera hébergé. Le dernier outil Deployment Designer permet de définir les contraintes de déploiement. Chacune des représentations du système construites par ces outils est sérialisée par des modèles conformes au schéma SDM. La figure suivante Figure 6 présente la structure globale du SDM. Il faut noter que dans les spécifications du SDM, il est possible d importer des informations d autres modèles. De cette manière il est possible de réutiliser des définitions déjà existantes de systèmes ou de ressources. De plus un système peut contenir des ressources, des connecteurs ainsi que d autres systèmes. Par contre une ressource ne peut contenir que d autres ressources. Il existe deux types de ressources : les ressources logicielles et les ressources matérielles. 2 / 42

22 0.. SDM Import Member Term Containment Hosting Object Flow Constraint Setting Communication between Reference System Resource Endpoint Relationship Delegation 0.. Figure 6 SDM global structure Les AFs présentés précédemment sont un ensemble représentatif de frameworks de descriptions d architecture existant dans le domaine de l ingénierie des systèmes informatiques. Certains peuvent être dédiés à un type particulier de systèmes comme MARTE ou à un domaine métier particulier comme le domaine militaire. Mais ils sont pratiquement tous basés sur les concepts de vue et de point de vue tels qu ils sont définis dans la terminologie du IEEE L ensemble des métamodèles présentés durant ce sous chapitre ont été traduit dans le langage KM3 et sont disponibles dans l Atlantic Zoo [65]. Le chapitre 4 suivant présente une démonstration simple que ces frameworks sont en général très proches des concepts du IEEE L implémentation d une transformation entre le métamodèle du IEEE et celui de la vue architecturale dans MoDAF permet de mettre en évidence la relation qui existe entre la terminologie et le framework d architecture. 4 Transformation IEEE vers MoDAF Le but de ce cas pratique est de montrer le lien fort qui existe entre la terminologie définie par le IEEE et les Architecture Frameworks qui s en inspirent. La transformation implémentée dans cet exemple peut être caractérisée de conceptuelle dans le sens où les métamodèles utilisés représentent une vue globale sur le IEEE et sur MoDAF. Il est à noter que, dans le domaine de l ingénierie des systèmes informatiques, le métamodèle du IEEE n est pas usuellement utilisé pour définir des modèles d architecture de systèmes. Les modèles de descriptions d architecture sont définis via les AFs utilisant les concepts de cette terminologie / 42

23 La Figure 7 présente visuellement la transformation implémentée par rapport aux modèles d entrée et de sortie : KM3 IEEE47 MoDAF ModelIEEE IEEE-2-MoDAF.atl transformation conformsto ModelMoDAF Figure 7 Transformation IEEE47 to MoDAF Pour implémenter cette transformation, nous avons besoin des métamodèles du IEEE et de MoDAF. Le métamodèle du IEEE47 [45] a été traduit en KM3 et correspond à la Figure 4. Le métamodèle de MoDAF utilisé est la vue architecturale [66] et correspond à la Figure 0. Le code présenté (Figure 8) est un exemple d entité du modèle conceptuel du IEEE défini en KM3 : --@begin System entity class System extends Element { reference fulfills[-] : Mission; reference inhabits : Environment oppositeof influences; reference hasan : Architecture; reference has[-] : Stakeholder; } --@end System entity Figure 8 Viewpoint entity from IEEE47 metamodel in KM3 Cet exemple spécifie la classe System qui hérite de la classe Element. Un System est en relation avec un Environment. La relation est exprimée de la manière suivante : - Un System vit (i.e. inhabits) dans un Environment ; - Un Environment influence (i.e. influences) le System. De plus, un System est capable de fournir (i.e. fulfills) une ou plusieurs Missions. La cardinalité de cette relation est exprimée par [-]. Afin d utiliser, dans la plateforme AMMA, les métamodèles et d implémenter un modèle d entrée conforme au IEEE47, les métamodèles sont injectés au format Ecore du framework EMF. Le modèle d entrée sera défini directement dans ce format. La transformation IEEE47 vers MoDAF est implémentée en ATL. Dans la Figure 9, l exemple est une règle ATL simple : 23 / 42

24 Concern 2 Concern rule Concern2Concern { from efrom : IEEE47!Concern to eto : MoDAF!Concern( name <- efrom.name, content <- efrom.content ) } --@end Concern 2 Concern Figure 9 Concern2Concern Rule from IEEE47_2_MoDAF ATL transformation La règle ATL prend en entrée tout les élément du type Concern du métamodèle IEEE47. Elle crée pour chaque, en élément de sortie, un élément du type Concern du métamodèle MoDAF. L attribut name de l élément de sortie prend pour valeur l attribut name de l élément d entrée. Le code présenté dans la Figure 20 correspond au AM3 Ant Tasks utilisée afin d exécuter la transformation : <target name="iiee47_2_modaf"> <am3.loadmodel modelhandler="emf" name="modaf" metamodel="mof" path="modaf.ecore"/> <am3.loadmodel modelhandler="emf" name="ieee47" metamodel="mof" path="ieee47.ecore"/> <am3.loadmodel modelhandler="emf" name="source" metamodel="ieee47" path="model-ieee47.ecore"/> <am3.atl path="ieee47_2_modaf.atl"> <inmodel name="in" model="source" /> <inmodel name="ieee47" model="ieee47" /> <inmodel name="modaf" model="modaf" /> <outmodel name="out" model="target" metamodel="modaf"/> </am3.atl> <am3.savemodel model="target" path="model-modaf.ecore"/> </target> Figure 20 AM3 Ant Tasks for IEEE47_2_MoDAF transforation Les trois premières Ant Tasks permettent de charger les deux métamodèles ainsi que le modèle d entrée conforme au métamodèle du IEEE47. La quatrième tâche Ant permet d exécuter la transformation ATL. Elle prend comme paramètre d entrée les deux métamodèles ainsi que le modèle qui doit être transformé. En sortie, la transformation crée un modèle conforme au métamodèle MoDAF. La dernière tâche permet de sérialiser le modèle de sortie en tant que fichier au format Ecore. Une transformation de modèles implique des choix d implémentation. Dans la majorité des cas, malgré le fait que les concepts soient proches, ils ne sont pas spécifiés de la même manière dans les métamodèles source et cible. Dans le cas pratique, une des difficultés est la transformation d une relation entre des concepts existants dans les deux métamodèles. Dans le métamodèle source IEEE47, la relation en question est binaire avec une cardinalité pouvant 24 / 42

25 être nulle. Dans le cas du métamodèle cible MoDAF, cette relation existe sous la forme d une composition. Ainsi, tous les éléments doivent être contenus par une entité. Dans notre cas : - Un Viewpoint peut provenir d un Library (dans IEEE47) ; - Une View doit être définie dans un Architectural Framework (dans MoDAF). Cet exemple est illustré par la Figure 2. La solution d implémentation choisie est de créer, dans MoDAF, un Architectural Framework défaut qui contiendra l ensemble des Viewpoints qui ne sont pas en relation avec une Library de Viewpoints. Dans le cas de la transformation inverse (i.e. MoDAF vers IEEE47), ce cas précis n aurait posé aucune difficulté. La raison est que pour chaque View contenu par un Architectural Description, dans un modèle MoDAF, il est possible de créer un Viewpoint prenant sa source d une Library. IEEE47 Viewpoint hassource LibraryViewpoint MoDAF View ownedmember.. definingframework ArchitecturalFramework Figure 2 A relationship transformation between IEEE47 and MoDAF Un autre exemple est la transformation du concept de Rationale qui existe sous la forme d une classe dans le IEEE47. Ce concept existe aussi dans MoDAF mais il est sous la forme d un attribut, nommé Purpose, dans la classe Architectural Description. Les différences majeures entre les métamodèles IEEE47 et MoDAF sont représentées dans la Figure 0. Dans une approche MDE, la problématique d une transformation de modèles est de pouvoir garder le maximum d informations du modèle source sans pour autant en créer de nouvelles dans le modèle cible. En générale, si les métamodèles sont différents, il n est pas possible d implémenter une transformation équivalente entre eux. Le but ce travail est de montrer la relation qui existe entre la terminologie du domaine des descriptions d architecture et des frameworks basés sur celle-ci. Cette démonstration par une transformation de modèles pourrait être présentée sous la forme d un modèle de tissage représentant les correspondances entre les deux métamodèles. A partir de ce modèle de tissage, il serait possible de générer partiellement la transformation IEEE47 vers MoDAF et la transformation inverse. La méthode utilisée serait similaire au processus décrit dans le chapitre 5. Ce dernier décrit une technique de génération de modèles de tissage entre deux métamodèles et le moyen de produire des transformations à partir du tissage. 5 Processus d intégration de modèle Les Architecture Frameworks proposent généralement plusieurs Viewpoints pour définir des modèles de systèmes informatiques. Ceci dans le but de fournir des perspectives sur les systèmes en fonction de groupes d aspects. Pendant le cycle de vie d un système et en 25 / 42

26 particulier lors de la conception et du développement, un des aspects les plus importants est la traçabilité. Dans ce sens le framework DoDAF propose un point de vue permettant de définir une matrice de traçabilité des fonctionnalités supportées par le système modélisé. Ce point de vue est calculé à partir d autres. Le but de ce travail est de montrer qu il est possible de générer automatiquement une matrice de traçabilité au moyen d une approche MDE. Pour se faire, les techniques employées sont la transformation de modèles et le tissage entre des modèles. 5. Cadre des travaux Le plus souvent, les métamodèles complexes sont décomposés en plusieurs points de vue, en particulier dans le cas des Architecture Frameworks tel que DoDAF. Concevoir des modèles qui sont conformes à ces métamodèles implique des problèmes d intégration de données entre les différentes vues. Généralement, les métamodèles représentant les points de vue partagent un noyau commun. C est la raison pour laquelle, les points de vues sont entrelacés. Il est donc possible de créer des liens de correspondance entre les métamodèles. Avec une approche MDE, ces liens peuvent être capturés par des modèles de tissage ou Weaving Models. En utilisant les principes du MDE, il est possible d automatiser le processus d intégration de données entre les vues en appliquant des transformations de modèles. Ces transformations peuvent être générées à partir des modèles de tissages. Ces derniers peuvent être aussi générés en utilisant des heuristiques de création de liens de correspondance entre les métamodèles. Ce processus a été appliqué au cas de DoDAF. Dans ce framework d architecture, SV-5 (une vue structurelle ou Structural View) est en relation avec OV-5 (une vue fonctionnelle ou Operational View) et SV-4 (une autre vue structurelle) dans le but de fournir une matrice de traçabilité vis-à-vis d architectures de systèmes. 5.2 Cas d étude DoDAF (cf ) est un framework dédié au développement d architecture de systèmes pour des organisations militaires le plus souvent et parfois pour des entreprises. Cet Architecture Framework permet de spécifier ces architectures à l aide de trois types de point de vue : Operational Views (OV), Structural Views (SV) et Technical Standards Views (TV). Il existe des relations entre les concepts de ces points de vues et certains concepts sont même partagés entre plusieurs vues. Par exemple, la Traceability Matrix dans SV-5 est utilisé pour capturer les relations entre les Operation Activities contenues dans OV-5 et les System Functions contenus dans SV-4. Chacun de ces points de vue est construit autour d un ensemble commun d entités architecturelles. Ce noyau d entités est appelé CADM (Cor Architecture Data Model). A l aide des relations existantes entre les points de vues proposés dans DoDAF, il est possible d implémenter un processus permettant de calculer la matrice de traçabilité d une vue SV-5 (i.e. une vue conforme au métamodèle SV-5). 26 / 42

27 5.2. Solutions envisagées En utilisant les principes du MDE, il existe au moins deux choix possibles pour générer la matrice de traçabilité d une vue SV-5 à partir d une vue OV-5 et d une vue SV-4. La première possibilité est d implémenter une transformation des métamodèles OV-5 et SV-4 vers SV-5. Cette transformation doit importer les données nécessaires des modèles d entrée dans le modèle de sortie et lier les entités créées par les relations n existant que dans le modèle de sortie. Par rapport au cas d étude, ces relations permettent de définir la matrice de traçabilité. Cette possibilité implique que la transformation soit implémentée manuellement. Etant donné le nombre d entité de chaque métamodèle, cette possibilité semble trop complexe. Le processus doit être alors automatisé. La seconde possibilité est d automatiser l intégration des données des modèles SV-4 et OV-5, dans le modèle SV-5. Pour cela, il est possible de créer un modèle de tissage entre les métamodèles SV-4 et SV-5, et entre OV-5 et SV-5. A partir des modèles de tissage, nous pouvons générer les transformations permettant d intégrer les données de SV-4 vers SV5 et de OV-5 vers SV-5. Les modèles de transformation peuvent alors être fusionnés afin de n obtenir qu une seule transformation implémentant le processus d intégration de donnée de modèles SV-4 et OV-5 vers SV-5. Dans un dernier temps, nous implémentons une transformation du métamodèle SV-5 vers lui-même dans le but de calculer l ensemble des relations devant exister entre les Operational Capabilities de OV-5 et les System Functions de SV-4. L ensemble des relations ainsi créées représente la matrice de traçabilité dans le métamodèle SV-5. La seconde possibilité a été choisie car le processus d intégration de données entre les modèles est réutilisable pour d autres couples de métamodèles Chevauchements entre les vues DoDAF Pour construire une matrice de traçabilité dans SV-5, nous avons besoin des vues connexes OV-5 et SV-4. La raison est que l Operational Activity to Systems Function Traceability Matrix (i.e. SV-5) contient des relations entre les Operational Capabilities de Operational Activity Model (i.e. OV-5) et les Systems Functions de Systems Functionality Description (i.e. SV-4). A cause du fait qu une vue SV-5, pour une description d architecture, capture plusieurs parties des vues SV-4 et OV-5, il existe, dans les métamodèles, un nombre conséquent d entités communes ainsi que de relations entre ces entités. De plus, par rapport à l arbre d héritage, il existe des entités parents en commun entre les métamodèles tel que Document. Certains groupes d entités assez restreints se retrouvent dans ces trois métamodèles de DoDAF. Tel que l ensemble qui est composé des éléments Activity Model, Activity Model Process Activity et Process Activity, ainsi que des relations liant ces éléments. Le diagramme suivant (Figure 22) représente le noyau commun sur lequel sont basés ces trois points de vue : 27 / 42

28 maybea Gestion de Systèmes de Systèmes isdescribedby ArchitectureDocument InformationAssetDocument iscitedin cites InformationAsset ActivityModel 0.. includes records Document describes isassociatedwith InformationElement ActivityModelInformationElementRole defines 0.. isthereferencefor ActivityModelProcessActivity isordinateof 0.. issubordinateof SystemDocument isordinateof issubordinateof isdesignedtoprovide istheprimaryreferencefor ProcessActivity isparentfor isassignedto istheproducerfor isincludedin iscitedby System SystemProcessActivity correspondsto ischildfor istheconsumerfor SystemFunction ProcessActivityExchangeRequirement Figure 22 Common core between OV-5, Sv-4 and SV-5 DoDAF Views OperationalCapabilityTask Task correspondsto ProcessActivityTask Plus précisément, le diagramme précédent représente l union des deux intersections entre SV-4 et SV-5, et entre OV-5 et SV-5. L élément racine de ce noyau est l entité Document et chaque élément racine des métamodèles OV-5, SV-4 et SV-5 hérite de cette même entité. Il est à noter que les Operational Activities sont aussi nommées Tasks dans les trois vues. Le diagramme suivant (Figure 23) représente un sous-ensemble du CADM de DoDAF. Le but de ce diagramme est de montrer qu il existe aussi des relations parfois directes entre les vues de DoDAF. En particulier, dans notre cas d étude, une vue SV-4 contient des Functional Specifications qui peuvent être des vues SV-5. De plus, ce diagramme montre comment sont liés les concepts des vues SV-4 et OV-5 afin de définir la matrice de traçabilité d une vue SV SystemDocument 0.. maybea FunctionalSpecification describes Document SystemFunctionTraceabilityMatrix (SV5) isdefinedeby ActivityModelSpecification (OV5) SystemFunctionalityDescription (SV4) SystemFunctionTraceabillityMatrixElement specifies maybecitedfor maybecitedfor 0.. maybecitedfor isspecifiedusing ActivityModel 0.. includes isusedtodescribe ActivityModelProcessActivity iscitedby SystemProcessActivity isassignedto isincludedin ProcessActivity SystemFunction Task correspondsto correspondsto ProcessActivityTask ActivityModelSpecificationElement isthesubjectof 0.. ProcessActivityExchangeRequirement Figure 23 High level relationships between OV-5, SV-4 and SV-5 DoDAF Views 28 / 42

29 En moyenne, les trois métamodèles des vues de notre cas pratique contiennent une centaine d entités. Il existe approximativement trente pour-cent d entités et de relations communes entre OV-5 et SV-5, et entre SV-4 et SV-5. Etant donné le chevauchement entre les métamodèles de SV-4, OV-5 etsv-5 de DoDAF, il est intéressant de pouvoir créer des modèles de tissage entre ces vues. Il est ainsi possible de générer les transformations entre ces vues. De ce sens, nous pouvons automatiser l intégration de données entre des vues SV-4 et SV-5, et entre OV-5 et SV-5. La matrice de traçabilité est alors calculée dans un second temps par une transformation du métamodèle SV-5 vers luimême. Cette transformation prendra en entrée le modèle généré par le processus d intégration de modèle. Dans ce but, les techniques employées sont celles décrites dans le sous-chapitre 5.3. Ces techniques s appuient sur la plateforme AMMA. 5.3 Model Integration Cette partie décrit avec plus de précision les phases nécessaires pour automatiser l intégration de données sur les vues DoDAF. En premier, nous montrons comment sont représentées les vues de DoDAF avec une approche MDE. En second, nous définissons le processus créant les modèles de tissage entre les métamodèles de ces vues. Ce processus est appelé matching. En trois, nous décrivons comment générer les transformations générées à partir des Weaving Models et implémentant l intégration de données Représentation des vues DoDAF avec une approche MDE Les points de vue DoDAF SV-5, OV-5 et SV-4 ont été traduits en métamodèles. Dans le but d utiliser la plateforme AMMA pour implémenter des transformations et utiliser des modèles de tissage, les métamodèles ont été définis en KM3. Pour cela, nous sommes partis du CADM existant pour chaque DoDAF Views [67]. Le CADM spécifie une représentation structurée des entités d architecture en utilisant la notation IDEFX [68]. Cette représentation des modèles de données de vues de DoDAF sont des diagrammes d entité-relation et sont donc dépourvus de la notion de relation de composition. Afin de donner plus d expressivité aux métamodèles des vues DoDAF, nous avons traduit certaines relations entre entités en composition dans les métamodèles exprimés en KM3. Par exemple, la relation includes entre Activity Model et Process Activities a été traduite en composition. Cet exemple existe dans les trois métamodèles Matching Le processus matching identifie les liens de correspondance entre deux différents métamodèles. Ce processus est encapsulé dans une opération, sur les modèles, nommée Match [69]. Une opération Match prend en entrée deux modèles Ma et Mb et produit en sortie une Mapping Map (i.e. une carte de correspondance) entre les éléments des deux métamodèles : Map = Match(Ma,Mb) 29 / 42

30 Généralement, avec l opération Match, il n est pas possible d automatiquement définir les liens d exactitude entre chaque élément des modèles. Pour cet exemple d intégration de donnée dans SV-5 de SV-4 et OV-5, nous voulons définir les liens d équivalence entre les entités des différents métamodèles. Notre but étant d extraire le plus possible de liens d équivalence entre les entités de SV-4 et SV-5, et entre OV-5 et SV-5. L ensemble des liens trouvé doit représenter l intersection entre les couples de métamodèles. Pour définir les équivalences entre les entités, nous assignons une valeur de similarité. Elle peut être égal à un () si les Class ou les Structural Features dans les deux métamodèles concernés sont exactement les mêmes. Cette valeur de similarité est égale à zéro (0) dans le cas contraire. Finalement, nous choisissons les liens qui ont une similarité évaluée à un. Ces liens de correspondance sont alors stockés dans un modèle de tissage. Ce modèle de tissage est conforme à un métamodèle de tissage qui est une extension du Core Weaving Metamodel [70] Modèle de tissage Un Weaving Model (Mw) supportant plusieurs types de liens est créé par une opération sur les modèles nommé CreateWeaving. Celle-ci est définie de la manière suivante : Mw = CreateWeaving(Ma, Mb) Cette opération prend deux modèles en entrée (Ma et Mb) et produit un modèle de tissage en sortie. Nous proposons d implémenter cette opération par l utilisation de transformations de modèles. En conséquence, nous pouvons dire que les deux modèles d entrée sont transformés en un modèle de sortie qui contient les liens de correspondance entre les modèles d entrée. Cette transformation ne produit pas les liens représentant l exacte intersection entre les modèles Ma et Mb. En fait, elle parcourt tous les éléments de Ma et de Mb et crée les liens d égalité pour chaque couple d élément. Les liens d égalité contiennent la valeur de similarité. Cette transformation fait en quelque sorte le produit cartésien entre Ma et Mb. Elle produit en sortie un modèle de tissage conforme à l extension en KM3 contenant la définition du lien d égalité (Equal). Cette extension est illustrée dans la Figure 24 : class Equal extends Equivalent { attribute similarity : Double; } class Equivalent extends WLink { reference left container subsets end: Element; reference right container subsets end: Element; } class Element extends WLinkEnd { } Figure 24 Weaving metamodel extension 30 / 42

31 La Figure 25 décrit une règle de transformation en ATL. Cette règle prend en entrée toutes les classes des modèles de gauche et de droite (conformes à KM3) et produit un lien Equal entre l élément de gauche et celui de droite. La partie from prend en entrée toutes les classes du modèle de gauche avec toutes les classes du modèle de droite. La partie to crée en élément de sortie un lien Equal conformément à l extension du métamodèle de tissage de la Figure 24. rule EqualityMapping { from left : KM3L!Class, right : KM3R!Class to anode : AMW!Equal ( left <- <the left element> right <- <the right element> ) } Calcul des Equivalences Figure 25 Matching rule in ATL Pour créer un modèle de tissage qui capture tous les liens d équivalence entre les éléments, nous devons calculer la valeur de similarité entre chaque entité des deux modèles. Dans notre cas, nous avons seulement deux valeurs de similarité. En effet, la similarité est mise à un si les deux éléments sont les mêmes selon certains critères. Autrement, la similarité est mise à la valeur de défaut (i.e. zéro). L algorithme de similarité est illustré dans la Figure 26. Celui-ci est implémenté pour les types suivants d entités de métamodèles : Class, Attribute et Reference. Il est à noter que Attribute et Reference sont des Structural Features des Class dans le MDE. L algorithme de similarité présenté est implémenté pour des modèles conformes au métamétamodèle MOF [7]. 3 / 42

32 helper context MOF!EModelElement def: similarity(right : MOF!EModelElement) : Integer = if self.similarityname(right) and self.similaritytype(right) then if (self.oclistypeof(mof!eattribute) and right.oclistypeof(mof!eattribute)) then if self.econtainingclass.similarity(right.econtainingclass) = and self.eattributetype.similarity(right.eattributetype) = and self.similarityupper(right) and self.similaritylower(right) then else 0 endif else if (self.oclistypeof(mof!ereference) and right.oclistypeof(mof!ereference)) then if self.econtainingclass.similarity(right.econtainingclass) = and self.ereferencetype.similarity(right.ereferencetype) = and self.similarityupper(right) and self.similaritylower(right) then else 0 endif else endif endif else 0 endif; Figure 26 Similarity algorithm in ATL Nous utilisons une transformation ATL pour générer le modèle de tissage entre deux modèles. Dans cette transformation, nous générons, dans un premier temps, le produit cartésien entre toutes les entités des métamodèles et ensuite nous assignons la valeur de similarité avec l algorithme précédent. Le produit cartésien contient plusieurs liens imprécis. Ces liens ont une similarité différente de un. Pour raffiner le produit cartésien, nous filtrons alors les liens en fonction des types des entités et de leur valeur de similarité. En effet, le produit cartésien doit être fait seulement entre les entités des modèles qui sont de même type. Dans notre cas, ceci empêche la création de liens inutiles car nous souhaitons définir la correspondance exacte entre deux modèles. Nous obtenons au final des liens de correspondance de nature : Class-to-Class, Attribute-to-Attribute et Reference-to-Reference. Les deux dernières peuvent être généralisées par StructuralFeature-to-StructuralFeature. La règle créant le produit cartésien est présentée dans la Figure 27. Cette règle applique trois actions : elle crée un nouveau nœud dans le modèle défini par la concaténation des noms des entités gauche et droite ; elle sauvegarde la référence des entités de chaque modèle ; et elle assigne au nœud la valeur de similarité entre les deux éléments 32 / 42

33 rule PairWise { from left : KM3L!ModelElement, right : KM3R!ModelElement ( (left.oclistypeof(km3l!class) and right.oclistypeof(km3r!class)) or (left.oclistypeof(km3l!attribute) and right.oclistypeof(km3r!attribute)) or (left.oclistypeof(km3l!reference) and right.oclistypeof(km3r!reference)) ) to anode : prop_g!node ( name <- left.name + '_' + right.name, model <- thismodule.amodel, similarity <- left.similarity(right), leftref <- left, rightref <- right ) } Figure 27 ATL Rule for the cross product Les deux sous-sections suivantes présentent plus précisément l algorithme de similarité pour les liens de type Class-to-Class et les liens de type StructuralFeature-to- StructuralFeature. En particulier, nous y définissons les critères qui spécifient la nature équivalente des liens de correspondance Class-to-Class Equivalence En accord avec l algorithme de similarité (Figure 26), la similarité, pour les liens de type Class-toClass, est calculée en prenant une classe du modèle de gauche et une classe du modèle de droite et en analysant leur données internes. Nous appliquons deux méthodes pour calculer la similarité : String similarity : les noms des éléments sont considérés comme des String. Ils sont comparés par une String comparison (similarityname ATL helper) ; Type similarity : les types des éléments sont extrait avec la fonction OCL ocltype et sont comparés (similaritytype ATL helper). Il existe d autres méthodes possibles pour calculer la similarité entre deux classes. Par exemple, il est possible de vérifier si les éléments des modèles contenant les classes comparées sont aussi jugés équivalent par l algorithme. Une autre méthode possible est de comparer l arbre d héritage des classes. Les heuristiques décrites déterminent la force du concept d équivalence que nous voulons appliquer. Le lien de correspondance est considéré comme une équivalence seulement si toutes les conditions sont satisfaites. Dans ce cas, la similarité est égale à un. 33 / 42

34 StructuralFeature-to-StructuralFeature Equivalence Une Structural Feature est une donnée interne à une classe. Elle peut être de deux natures : Attribute ou Reference. La similarité d un lien de type StructuralFeature-to- StructuralFeature est calculée en prenant une donnée interne d une classe du modèle de gauche et une du modèle de droite. Dans les faits, nous ne traitons que les liens de type Attribute-to-Attribute et Reference-to-Reference car nous ne caractérisons pas un lien d équivalence si les éléments sont de types hétérogènes. Pour calculer la similarité entre deux structural features, nous utilisons l algorithme de similarité pour les liens de type Class-to- Class et ajoutons trois méthodes spécifiques : Owner entity similarity : les classes contenants les structural features sont comparées avec l algorithme de similarité ; Structural Feature Type similarity : les types des éléments référencés par les structural features sont comparés avec l algorithme de similarité ; Cardinality similarity : les cardinalités (i.e. upper et lower) sont comparées. Nous considérons les cardinalités sont les mêmes si les caractéristiques upper et lower sont les mêmes (similaritylower et similarityupper ATL helper). Pour calculer les similarités entre des Structural Features, nous prenons avantage de la connaissance que nous avons du métamétamodèle utilisé. En ce sens, nous pourrions aussi regarder si, dans le cas d un lien de type Reference-to-Reference, les deux structural features sont des compositions ou non Filtrage des résultats Dans une dernière étape, nous filtrons le modèle de tissage obtenu précédemment par autre transformation. Le but est de garder seulement les liens d équivalence autrement dit les liens avec une similarité égale à un. Cette transformation génère un modèle de tissage conforme au métamodèle décrit dans la Figure 24. Les liens conservés sont réorganisés de la manière suivante. Un lien est enfant d un autre lien si c est un lien de type StructuralFeature-to-StructuralFeature et si les structural features appartiennent symétriquement aux classes caractérisées d équivalentes par le lien parent. Un lien est enfant d un autre lien si c est un lien de type Class-to-Class et si les classes héritent symétriquement des classes caractérisées d équivalentes par le lien parent. Cette organisation est possible grâce l existence de la relation parent/enfant dans le Core Weaving Metamodel [70]. Il est possible générer plus facilement les transformations grâce à cette organisation car elle permet d assigner les règles de transformation des données internes d une classe à la règle concernant cette classe. De plus cela nous permet aussi d utiliser l héritage de règles de transformation. Ainsi, une règle de transformation, pour un lien Class-to-Class, hérite d une autre s il a un lien parent Class-to-Class Génération des Transformations A cette étape du processus, nous voulons générer les transformations implémentant l intégration de données entre des modèles à partir des modèles de tissages. Selon notre cas d étude, nous voulons produire les transformations OV-5 vers SV-5 et SV-4 vers SV-5. Nous avons implémenté une transformation ATL permettant de générer les modèles de transformation conforme au métamodèle ATL. Elle prend entrée le modèle de tissage et les métamodèles gauche et droit. Le modèle de transformation généré est ensuite sérialisé comme programme conforme à la syntaxe ATL. 34 / 42

35 Dans la Figure 28, nous montrons que la transformation AMW2ATL produit une transformation MML2MMR. AMW2ATL est une Higher Order Transformation (HOT). Une transformation HOT prend en entrée un modèle de transformation et/ou produit un modèle de transformation. conformsto ATL transformation projector MDE technical space KM3 Grammar technical space EBNF MML in MMW MMATL ATLgrammar MW in MMR in AMW2ATL_HOT out MML2MMR Figure 28 Producing MML2MMR transformation MML2MMR Dans notre cas d étude, MML est le métamodèle OV-5 ou SV-4 et MMR est le métamodèle SV-5. A partir de là, nous sommes donc capables de générer les transformations OV-5 vers SV-5 et SV-4 vers SV-5. En inversant MML et MMR, nous sommes aussi capables de produire les transformations inverses. 5.4 Fusion de Transformations Nous avons obtenu les modèles des transformations OV-5 vers SV-5 et SV-4 vers SV-5, à partir des étapes précédentes. Etant donné que nous ne voulons obtenir qu un seul modèle SV-5. Nous avons implémenté une autre transformation ATL permettant de fusionner deux modèles de transformation. Cette transformation prend en entrée les deux modèles de transformation générés et produit en sortie un seul modèle de transformation. Cette transformation, nommée MergeATL, est aussi une HOT. Après exécution de cette transformation, nous obtenons une transformation ATL prenant entrée deux modèles conformes à OV-5 et SV-4 et produisant un modèle SV-5. Cette transformation est capable d intégrer les données des deux modèles d entrée dans le modèle de sortie. 5.5 Transformation de SV-5 vers SV-5 En appliquant la transformation fusionnée, nous intégrons les données provenant de modèles OV-5 et SV-4 dans un modèle SV-5. Ce modèle SV-5 n est pas complet, même s il est conforme à son métamodèle, car il ne fait pas la relation entre les Operational Activities (ou Tasks) provenant de OV-5 et les System Functions provenant de SV-4. Le diagramme, présent dans la Figure 29, représente un sous-ensemble de SV-5. Ce diagramme nous montre comment les éléments de la matrice de traçabilité sont représentés et 35 / 42

36 comment ils sont liés aux données provenant des vues OV-5 et SV-4. La matrice présente dans une vue SV-5 est une matrice creuse, c'est-à-dire que seul les nœuds non-vides sont représentés. Un nœud non-vide est un élément qui est en relation avec au moins une Task et une System Function. SystemFunctionTraceabilityMatrix (SV5) isdefinedeby SystemFunctionTraceabillityMatrixElement 0.. maybecitedfor 0.. maybecitedfor 0.. maybecitedfor ActivityModelProcessActivity includes ActivityModel SystemProcessActivity 0.. isassignedto isincludedin ProcessActivity ProcessActivityTask correspondsto iscitedby SystemFunction Figure 29 Focus on the Tracability Matrix in SV-5 DoDAF View Task correspondsto Le but de la transformation de SV-5 vers SV-5 est de raffiner le modèle d entrée en calculant l ensemble des relations qu il existe entre les System Functions et les Tasks. En suite, elle doit générer l ensemble des éléments correspondant aux nœuds de la matrice par rapport aux relations mises en évidence. Dans ce chapitre, nous avons présenté un processus d intégration de données entre des modèles. Celui-ci est basé sur des techniques de transformation de modèles et de tissage entre des modèles appliquant les principes du MDE. Ce processus a été implémenté sur la plateforme AMMA. Il se déroule en plusieurs étapes. Une transformation génère le produit cartésien entre les deux métamodèles d entrée et calcule une valeur de similarité entre chaque couple d éléments. Le calcul de similarité est réalisé selon des critères qui peuvent être changés afin d affiner le calcul ou bien de rendre plus permissif l algorithme. En suite, une autre transformation génère un modèle de tissage où seul les liens d équivalence sont gardés et sont réorganisés. Une dernière transformation crée un modèle de transformation entre les deux métamodèles d entrée. Dans le cas de DoDAF, nous avons voulu générer une vue SV-5 à partir des vues SV-4 et OV-5 d une description d architecture. Nous avons appliqué le processus d intégration de modèles sur le couple OV-5 et SV-5 et sur le couple SV-4 et SV-5. Une transformation nous permet de fusionner les deux modèles de transformation générés afin de n obtenir qu un seul modèle SV-5 en sortie. Enfin, nous avons montré le moyen d implémenter une transformation qui calcule la matrice de traçabilité d un modèle SV-5. Le processus d intégration de modèles peut être appliqué à différents couples de métamodèles. Il est particulièrement adapté aux frameworks se basant sur les concepts de Vue et de Point de vue. Un test intéressant serait d appliquer ce processus entre un métamodèle de profile UML et le métamodèle de UML lui-même. Ce test permettrait de définir l intersection qu il existe entre UML et son profil. 36 / 42

37 6 Conclusion Dans le domaine de l ingénierie des systèmes informatiques, les Architectures Frameworks permettent de représenter par des modèles des descriptions d architecture. Les systèmes informatiques représentant des organisations militaires ou des systèmes d informations de grandes entreprises sont le plus souvent distribués et séparés en plusieurs composants. Les Systèmes de Systèmes correspondent à ce type de systèmes et ont la particularité de pouvoir être composés d autres systèmes. La complexité des SoSs est telle qu il est difficile d avoir une politique de gestion globale sur cette catégorie de systèmes informatiques. Les concepts de Vue et de Points de Vue de la terminologie IEEE définissent le moyen de décomposer les descriptions d architecture en proposant de définir des perspectives sur un système en accord avec les intérêts des personnes concernées par ce système. Ainsi une description d architecture est un ensemble de modèles chacun étant conforme à un point de vue possible sur le système. Certains points de vue définis dans un AF peuvent être calculés à partir d autres. C est le cas pour DoDAF où il est possible de définir une matrice de traçabilité dans une vue SV-5 à partir d une vue contenant les Operational Capabilities (OV-5) et d une vue contenant les System Functions (SV-4). En appliquant les principes tirés du MDE, nous avons proposé un processus permettant d automatiser la génération d une matrice de traçabilité d une vue SV-5 de DoDAF. Ce processus met en pratique des techniques de transformation de modèles et de tissage entre les modèles. Il permet de faire l intégration des données d un modèle vers un autre. A travers ce processus, nous générons un modèle de tissage entre deux métamodèles et dans une deuxième étape la transformation entre les deux métamodèles à partir du modèle de tissage. Ce processus a été implémenté sur la plateforme AMMA qui propose plusieurs DSLs dédiés aux principes du MDE. KM3 nous a permis de représenter les métamodèles DoDAF. ATL nous a permis d implémenter les transformations de modèles. Ce processus d intégration de modèle peut être réutilisé avec d autres couples de métamodèles car il n est pas spécifique au cas pratique DoDAF. Il est particulièrement adapté pour la migration de données entre des modèles conformes à des métamodèles partageant le même noyau. Par exemple, il pourrait être testé entre deux profils UML. 37 / 42

38 7 Remerciements Je tiens à remercier toute l équipe ATLAS, et plus particulièrement Jean Bézivin de m avoir encadré durant ce stage. Je remercie aussi Marcos Didonet Del Fabro pour son aide précieuse dans la réalisation du processus d intégration de modèles et ses connaissances dans le domaine du tissage de modèles. Je veux également remercier Davide Di Ruscio pour sa collaboration dans la réalisation du Zoo AsmL. 8 Bibliographie et références [] IEEE Std , IEEE Recommended Practice For Architectural Description of Software-Intensive System. [2] DoDAF online definition from Wikipedia website: [3] DoDAF Volume II: Product Decsription, 4/2/2004. Official site: [4] ATLAS Home page: [5] INRIA Official site: [6] Bézivin, J, Jouault, F, and Touzet, D: An Introduction to the ATLAS Model Management Architecture. Research Report LINA, (05-0) [7] Bézivin, J, Jouault, F, Kurtev, I, and Valduriez, P: Model-based DSL Frameworks. In: Companion to the 2st Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications, OOPSLA 2006, October 22-26, 2006, Portland, OR, USA. ACM To appear. [8] MDA Architecture, Official site : [9] OMG MDA Guide V.0., 2th June Accessible by this link: [0] OMG Official webpage: [] Schmidt, D.C., Model-Driven Engineering, IEEE Computer, February Accessible by this link: [2] Bézivin, J., Jouault, F., KM3: a DSL for Metamodel Specification. In: Proceedings of 8 th IFIP International Conference on Formal Methods for Open Object-Based Distributed Systems, Bologna, Italy. [3] Bézivin, J., Jouault, F., Kurtev, I., and Valduriez, P., Model-Based DSL Frameworks. Submitted for Publication. [4] Allilaire, F., Bézivin, J., Brunelière, H., Jouault, F, Global Model Management in Eclipse GMT/AM3. In ext workshop, ECOOP, Nantes, [5] OCL 2.0 Specification : [6] AM3 ATLAS MegaModel Management official site (Eclipse/GMT subproject): [7] Bézivin, J, Jouault, F, Rosenthal, P, and Valduriez, P: Modeling in the Large and Modeling in the Small. In: Proceedings of the European MDA Workshops: Foundations and Applications, MDAFA 2003 and MDAFA 2004, LNCS 3599, edited by Uwe Aßmann, Mehmet Aksit, Arend Rensink. Springer-Verlag GmbH, pages [8] ATL ATLAS Transformation Language official site (Eclipse/GMT subproject): [9] AMW ATLAS Model Weaver official site (Eclipse/GMT subproject): [20] Didonet Del Fabro, M, and Jouault, F: Model Transformation and Weaving in the AMMA Platform. In: Preproceedings of the Generative and Transformational Techniques in Software Engineering (GTTSE'05), Workshop. Centro de Ciências e Tecnologias de Computação, Departemento de Informatica, Universidade do Minho, Braga, Portugal, pages [2] EMF, Eclipse Project Official webpage: [22] GMT, Eclipse Subproject Official webpage: [23] DSL definition from Wikipedia website: [24] Bézivin, J, Jouault, F: KM3: a DSL for Metamodel Specification. In: Proceedings of 8th IFIP International Conference on Formal Methods for Open Object-Based Distributed Systems, Bologna, Italy. [25] Jouault, F, and Kurtev, I: Transforming Models with ATL. In: Satellite Events at the MoDELS 2005 Conference: MoDELS 2005 International Workshops OCLWS, MoDeVA, MARTES, AOM, MTiP, WiSME, MODAUI, NfC, MDD, WUsCAM, Montego Bay, Jamaica, October 2-7, 2005, Revised Selected Papers, LNCS 3844, edited by Jean- Michel Bruel. Springer Berlin / Heidelberg, pages / 42

39 [26] Jouault, F, Kurtev, I. On the Architectural Alignment of ATL and QVT. In: Proceedings of ACM Symposium on Applied Computing (SAC 06), Model Transformation Track, Dijon, Bourgogne, France, April [27] Jouault, F, Bézivin, J, and Kurtev, I : TCS: a DSL for the Specification of Textual Concrete Syntaxes in Model Engineering. In: GPCE'06: Proceedings of the fifth international conference on Generative programming and Component Engineering To appear. [28] Ant Tasks Overview webpage: [29] AM3 Ant Tasks Wiki page: [30] Zachman Framework Website: [3] MoDAF, official site: [32] DoDAF, official site: [33] ToGAF, official page: [34] AGATE official webpage: [35] RM-ODP, official site: [36] Complex System, a definition from Wikipedia, [37] System of Systems, a definition from Wikipedia, [38] Maier, M. W., Architecting Principles for Systems-of-Systems, Systems Engineering, Vol., No. 4, 998, pp [39] P-E E. Bergner, Dynamics of Markovian Particles; A kinetics of macroscopic particles in open heterogeneous systems, (2005). Accessible from this website: [40] Kruchten, P, The 4+ View Model of Software Architecture. In IEEE Software 2 (6) 995. [4] Maier, M. W., Emery, D., Hilliard, R., ANSI/IEEE 47 and Systems Engineering, Systems Engineering, Vol. 4, No. 3, 2004, pp [42] Hilliard, R., IEEE Std 47 and beyond, SEI Workshop Software Architecture Requirement, January 6-7, 200, Software Engineering Institute Special Report CMU/SEI-200-SR-00 [43] Kandé, M. M., Cretaaz, V., Strohmeier, A., Sendall, S., Bridging the Gap between IEEE 47, Architecture Description Languages and UML. In Journal on Software and Systems Modeling, Vol., No. 2 (2002), p. 3-29, Springer Verlag, [44] Hilliard, R., Views and Viewpoints in Software System Architecture. In First Working IFIP Conference on Software Architecture, San Antonio, 999. [45] Metamodel of leee in the Atlantic Zoo: ConceptualModel.km3 [46] Architecture Framework, a definition from Wikipedia website: [47] C4ISR Architecture Framework Version 2.0 (Architecture Working Group): [48] C4ISR Journal: [49] DoDAF v Deskbook: [50] MoDAF official site: [5] AGATE official site: [52] AGATE Documentation Version 3: [53] SysML,Open Source Specification Project: [54] OMG Systems Modeling Language Specification: [55] UML website: [56] MARTE omg specification : [57] MARTE Workshop, October , in Montego Bay, Jamaica : [58] ProMARTE official site: [59] DSI Home page, Microsoft Reference site: [60] Microsoft, SDM Overview, official white paper, April Accessible by this link: [6] Visual Studio Team System, official site, [62] W3C, official site: [63] XML, official site: [64] XSchema, official site: 39 / 42

40 [65] Atlantic Zoo from GMT website: [66] MoDAF Architectural View metamodel in KM3 from Atlantic Zoo: AV.km3 [67] DoDAF Volume II: Product Decsription, 4/2/2004. Official site: [68] IDEFX, Integration Definition For Information Modeling, Federal Information Processing Standards Publication 84, 2/2/993 [69] Bernstein P A. Applying Model Management to Classical Meta Data Problems. In proc. of the st Biennial Conf. on Innovative Data Systems Research (CIDR 2003), pp [70] Didonet Del Fabro M, Bézivin J, Jouault F, Valduriez P. Applying Generic Model Management to Data Mapping. In proc. of Base de Données Avancées (BDA 2005), 7-20/0/2005, Saint-Malo, France [7] MOF, OMG oficcial webpage: [72] Bézivin, J, Jouault, F, and Touzet, D : An Introduction to the ATLAS Model Management Architecture. Research Report LINA, (05-0) [73] Bézivin, J, Jouault, F, Kurtev, I, and Valduriez, P : Model-based DSL Frameworks. In: Companion to the 2st Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications, OOPSLA 2006, October 22-26, 2006, Portland, OR, USA. ACM To appear 40 / 42

41 9 Annexes Les annexes regroupent un ensemble de documents relatifs au travail réalisé pendant ce stage. L annexe 9. est un glossaire regroupant l ensemble des termes utilisés dans ce rapport. 9. Glossaire Le glossaire suivant regroupe l ensemble des termes et des acronymes utilisés dans ce rapport. AD AF AGATE AM3 AMMA (plateforme) AMW ATL ATLAS AWG C4ISR CADM DGA DoDAF DSI DSL Ecore EMF HOT IDEFX IEEE INRIA KM3 M2 M3 MARTE MDA MDE MétaMétamodèle Métamodèle MML MMR MoDAF MOF.4 Architecture Description Architecture Framework Atelier de Gestion de l'architecture des Systèmes d'information, AF crée par la DGA ATLAS MegaModel Management, outil de management globale pour les modèles, développé par l'équipe ATLAS ATLAS Model Management Architecture, plateforme MDA développée par l'équipe ATLAS ATLAS Model Weaving, outil de "tissage" de modèles développé par l'équipe ATLAS ATLAS Transformation Langage, outil de transformation de modèles développé par l'équipe ATLAS ATLantique data Systems, équipe de recherche de l'inria Architecture Working Group Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance, AF du domaine militaire Core Architecture DataModel Délégation Générale pour l Armement (France) Department of Defense Architecture Framework Dynamic Systems Initiative, projet Microsoft pour le développement d'un AF Domain Specific Language Modèles dans le framework EMF utilisant le format XMI, sous-ensemble des concepts du MOF,4 Eclipse Modeling Framework Higher Order Transformation Notation de diagramme E-R utilisée pour la définition des CADM dans les AFs Terminologie portant sur les AD pour les SIS Institut National de Recherche en Informatique et en Automatique Kernel MetaMetaModel, DSL dédié à la définition de métamodèles cf. Métamodèle cf. MétaMétamodèle Modeling and Analysis of Real-Time and Embedded systems AF Model Driven Architecture Model Driven Engineering Modèle décrivant un langage de définition de métamodèles Modèle définissant la structure de modèles terminaux Metamodel Left Metamodel Right Ministry of Defense Architecture Framework Meta-Object Facility, standard de l'omg définissant un M3 pour définir au départ le Métamodèle de UML 4 / 42

42 Mw OCL OMG OO Oriented Object OV-5 PIM Point de vue PSM QVT RM-ODP SDM Sérialisation SIS SoS SV-4 SV-5 SysML TCS ToGAF UML View Viewpoint Vue Weaving Model XML Xschema cf. Weaving Model Object Constraint Language, langage de l'omg dédié à la spécification de contraintes Object Management Group, consortium définissant des standards des Systèmes distribués OO Object Oriented, programation orientée objet méthode de programmation orientée objet Operational View 5, Operational Capabilities view from DoDAF Platform Independent Model cf. Viewpoint Platform Specific Model Query View Transformation, langage de transformation de modèles proposé par l'omg Reference Model for Open Distributed Processing, un AF System Definition Model (AF de Microsoft) Processus d'enregistrement d'une structure de données dans un fichier physique dans un but de sauvegarde ou d'échange Software-Intensive System System of Systems Structural View 4, System Functions view from DoDAF Structural View 5, Traceability Matrix view from DoDAF Systems Modeling Language, AF sous forme de profil UML Textual Concrete Syntax, langage dédié à la définition de syntaxes concrètes de l'équipe ATLAS The Open Group Architecture Framework Unified Modeling Langage de l'omg Vue, perspective sur une architecture de système Point de vue, méthodes et techniques pour définir une Vue cf. View Modèle de tissage, modèle stockant un ensemble de liens entre plusieurs modèles extensible Markup Langage, langage semi-structuré basé sur le concept de balises Schema XML, langage XML pour la défintion de format XML 42 / 42