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