Modélisation des systèmes temps-réel répartis embarqués pour la ...

More documents

Recommendations

Info

Modélisation des systèmes temps-réel répartis embarqués – flux ; – annexes (bibliothèques et sous-clauses). La structure de l’arbre d’instance reprend la plupart des constructions de l’arbre de modèle, en y introduisant quelques modifications. L’une des différences fondamentales entre le modèle et l’instance est que cette dernière décrit une hiérarchie complète de composants alors que le modèle ne décrit en définitive qu’un arbre de profondeur 2 dont les feuilles sont les déclarations de composants. Les entités présentes dans l’arbre d’instance sont plus restreintes : – espaces de nom (paquetages) ; – instances de composants ; – instances de sous-clauses : – instances d’éléments d’interface, – instances de sous-composants, – instances de séquences d’appels et appels de sous-programmes, – instances de connexions, – instances de modes, – instances de flux ; – associations de propriétés. Les définitions de propriétés n’apparaissent pas dans l’arbre d’instance : seul les associations sont représentées. Les types et implantations de composants sont agrégés au niveau des instances. Les sous-composants sont des simples liens entre les instances de composant et leurs sous-instances. Par convention, les instances de composants sont détachées de leur éventuel paquetage de déclaration et sont insérés dans la hiérarchie ; l’espace de nom anonyme devient donc implicite. L’utilisation de deux représentations distinctes pour les déclarations et les instances permet la création de multiples instanciations d’architectures, correspondant à différents systèmes, au sein d’une même exécution d’Ocarina. Cette séparation permet également de préserver l’ensemble des déclarations, et ainsi d’effectuer des traitements séparés sur les déclarations et les instances. Nous en illustrerons l’intérêt en section VIII-1.4. VIII-1.3 Organisation d’Ocarina Ocarina est constitué d’un cœur sur lequel sont branchés différents modules. Ces modules se comportent comme des applications faisant appel aux services et à l’API du cœur. Il en existe trois types, dont l’agencement est décrit sur la figure VIII.1 : – modules d’entrée/sortie ; – modules de transformation ; – générateurs. Les modules d’entrée/sortie permettent de parser des fichiers AADL ou d’afficher l’arbre du cœur selon une différentes syntaxes (textuelle, graphique, représentation XML. . .). Ocarina fournit actuellement un parseur/afficheur pour la syntaxe textuelle d’AADL ainsi qu’un module pour les fichiers de l’éditeur de diagramme Dia. Les modules de transformation peuvent permettre l’expansion de l’arbre du cœur pour mettre en place des transformations d’architecture que nous avons décrites en section VI-3, page 107. Les générateurs permettent de produire différentes représentations – en l’occurrence du code source ou des réseaux de Petri – à partir de la représentation AADL. Nous avons développé un générateur appelé Gaia [Vergnaud et Zalila, 2006] qui prend en charge les différentes générations que nous avons décrites dans les chapitres V et VII, et un autre générateur appelé PN permettant 152 c○ 2007 Thomas Vergnaud
parseurs/afficheurs Chapitre VIII – Mise en pratique application tierce cœur transformateur générateur FIG. VIII.1 – Organisation des modules d’Ocarina de produire des réseaux de Petri selon les règles que nous avons présentées au chapitre VII. Ocarina [Vergnaud et Zalila, 2006] est une application autonome utilisable en ligne de commande permettant de produire du code exécutable, un réseau de Petri, de passer d’une représentation AADL à une autre ou simplement de vérifier la validité d’une description AADL. Tous les modules ainsi que le cœur d’Ocarina peuvent également être utilisés comme des bibliothèques logicielles, intégrées dans une application tierce afin de permettre à des outils existants de manipuler une description AADL. VIII-1.3.1 Organisation du cœur Le cœur permet de manipuler les deux niveaux d’une description AADL : le modèle et l’instance d’architecture. Il fournit un ensemble de fonctions pour manipuler l’arbre de modèle AADL pour le construire, le vérifier ou le consulter. D’autres fonctions permettent de manipuler l’arbre d’instance. De la même façon que pour le modèle, il est possible de construire, vérifier et consulter l’arbre d’instance. Cependant, l’arbre d’instance ne peut pas être construit directement : il est calculé à partir de l’arbre de modèle par instanciation des déclarations de composants. L’utilisation typique des fonctions du cœur est la suivante : 1. appel des fonctions de construction de l’arbre de modèle par les parseurs ou l’éventuelle application tierce ; 2. vérification de l’arbre de modèle ; 3. transformations éventuelles dans l’arbre de modèle ; 4. éventuelle instanciation de l’arbre de modèle ; 5. exploitation de l’arbre d’instance par un générateur ou une application tierce. L’arbre de modèle permet de recueillir les informations décrites dans les différentes syntaxes AADL. La phase de vérification consiste à s’assurer que tous les composants référencés par les sous-composants et les éléments d’interface ont bien été déclarés, que les associations de propriétés sont cohérentes avec leur définitions, etc. La racine de l’arborescence des instances de composants est le système racine décrit dans le modèle, c’est-à-dire une implantation de système dont le type n’a aucune interface. Les composants de données associés aux éléments d’interface demeurent dans leur paquetage de déclaration dans la mesure où ils ne font pas partie de la hiérarchie d’instance. Les déclarations c○ 2007 Thomas Vergnaud 153
Page 1 and 2:
École doctorale d’informatique,
Page 3:
Telle est la nature de l’esprit h
Page 6 and 7:
To validate this design process, we
Page 8 and 9:
Modélisation des systèmes temps-r
Page 10 and 11:
Page 12 and 13:
Page 14 and 15:
Page 16 and 17:
Page 18 and 19:
Page 20 and 21:
Page 22 and 23:
II-2.2.2 CORBA Modélisation des sy
Page 24 and 25:
II-2.2.3 RMI Modélisation des syst
Page 26 and 27:
Page 28 and 29:
Page 30 and 31:
Page 32 and 33:
II-4.4 Discussion Modélisation des
Page 34 and 35:
II-5.2.2 Connecteurs Modélisation
Page 36 and 37:
18 } Modélisation des systèmes te
Page 38 and 39:
Page 40 and 41:
Page 42 and 43:
Page 44 and 45:
11 end i486.AMD; 12 Modélisation d
Page 46 and 47:
Page 48 and 49:
Page 50 and 51:
Page 52 and 53:
1 system global 2 end global; 3 Mod
Page 54 and 55:
Page 56 and 57:
Page 58 and 59:
Page 60 and 61:
Page 62 and 63:
16 Modélisation des systèmes temp
Page 64 and 65:
Page 66 and 67:
Page 68 and 69:
Page 70 and 71:
Page 72 and 73:
phase 1 phase 2 Modélisation des s
Page 74 and 75:
Page 76 and 77:
Page 78 and 79:
Page 80 and 81:
Page 82 and 83:
Page 84 and 85:
descriptions comportementales Modé
Page 86 and 87:
Page 88 and 89:
Page 90 and 91:
17 end sp.impl; Modélisation des s
Page 92 and 93:
Page 94 and 95:
Page 96 and 97:
Page 98 and 99:
Page 100 and 101:
Page 102 and 103:
13 Modélisation des systèmes temp
Page 104 and 105:
Page 106 and 107:
Page 108 and 109:
Page 110 and 111:
Page 112 and 113:
Page 114 and 115: Modélisation des systèmes temps-r
Page 116 and 117: autre nœud Modélisation des syst
Page 124 and 125: 10 features Modélisation des syst
Page 126 and 127: VI-3.4.6 Activation Modélisation d
Page 138 and 139: donnee (a) donnée Modélisation de
Page 144 and 145: 53 end global.impl; Modélisation d
Page 154 and 155: 15 end sspg_b; Modélisation des sy
Page 156 and 157: 1 data donnee 2 end donnee; 3 4 thr
Page 172 and 173: 19 use Partition; 20 Modélisation
Page 174 and 175: 23 begin Modélisation des système
Page 178 and 179: VIII-3.1 Motifs AADL de base Modél
show all

Modélisation des systèmes temps-réel répartis embarqués pour la ...

Create successful ePaper yourself

Delete template?

Save as template?