Contribution à la considération explicite des plates-formes d

UNIVERSITÉ DE NANTES

ÉCOLE DOCTORALE STIM

« Sciences et Technologies de l’Information et de Mathématiques »

Année 2010

THÈSE DE DOCTORAT DE L ’U NIVERSITÉ DE NANTES

Spécialité : AUTOMATIQUE ET I NFORMATIQUE APPLIQUÉE

Présentée et soutenue publiquement par :

Matthias BRUN

le 18 octobre 2010

à l’École Centrale de Nantes

Contribution à la considération explicitedes plates-formes d’exécution logicielles

lors d’un processus de déploiement d’application

JURY :

Rapporteurs : Laurence DUCHIEN Professeur, Université Lille 1 - LIFL

Jean-Philippe BABAU Professeur, Université Bretagne Occidentale - LISyC

Examinateurs : Joël CHAMPEAU Enseignant Chercheur, ENSIETA - LISyC

Sébastien GÉRARD Docteur Ingénieur, CEA Saclay - LISE

Yvon TRINQUET Professeur, Université de Nantes - IRCCyN

Jérôme DELATOUR Enseignant Chercheur, Groupe ESEO - LRA

Directeur de thèse :Yvon TRINQUET

Laboratoire : Institut de Recherche en Communications et Cybernétique de NantesCo-encadrant :Jérôme DELATOUR

Laboratoire : Laboratoire de Recherche Appliquée à l’ESEOComposante de rattachement du directeur de thèse :Université de Nantes

No ED : 503-099

Remerciements

Je tiens tout d’abord à remercier Jérôme Delatour qui a co-encadré cettethèse. Jérômem’a donné l’opportunité d’effectuer un travail de recherche et a su créer un contexte idéalpour ce travail. En plus de son soutien, de ses conseils et du savoir qu’ilm’a transmis, jetiens à saluer son enthousiasme contagieux et sa générosité. Merci Jérôme.

Je suis également extrêmement reconnaissant envers mon directeur de thèse, Yvon Trin-quet, pour son accompagnement amical, ses conseils avisés, ses remarques pertinentes etl’exemplarité de sa rigueur scientifique.

J’adresse mes remerciements à Laurence Duchien et à Jean-Philippe Babau qui m’ontfait l’honneur d’évaluer mon travail de thèse et d’en être les rapporteurs. Je les remerciepour leurs remarques toujours très constructives. Je remercie également Joël Champeau etSébastien Gérard d’avoir accepté de faire partie des membres du jury.

Le travail présenté dans ce mémoire a été financé par le projet TOPCASED du pôle decompétitivité Aérospace Valley. J’adresse donc mes remerciements aux responsables de ceprojet pour leur soutien.

Ce travail de recherche a été effectué au Centre d’Étude et de Recherche du groupeESEO, en collaboration avec l’Institut de Recherche en Communications et Cybernétiquede Nantes (IRCCyN). Aussi, je tiens à remercier Patrick Plainchault, directeur de la re-cherche du groupe ESEO, et Jean-François Lafay et Michel Malabre, directeurs successifsde l’IRCCyN, de m’avoir accueilli dans leurs laboratoires. Je remercie également JackyCharruault, directeur général du groupe ESEO, de m’avoir engagé à l’issue de cette thèse.

Je remercie les membres de l’équipe TRAME de l’ESEO, Guillaume et Jonathan,pour leur accueil, leurs échanges et l’amitié que nous avons tissée. Mes remerciementss’adressent également aux membres du département AII et du département GRI de l’ESEOavec lesquels j’ai eu la chance d’enseigner durant ces années de doctorat et avec lesquels jesuis ravi de continuer. Je remercie aussi plus largement l’ensemble des membres de l’ESEOavec lesquels j’ai eu et j’aurai toujours plaisir à travailler.

Je remercie l’ensemble des membres de l’équipe Systèmes Temps Réel de l’IRCCyN ettout particulièrement Sébastien et Pierre pour leurs échanges toujours très instructifs.

Je remercie également l’ensemble de la communauté IDM pour son accueil et laconvi-vialité de ses rencontres.

Je profite de ces remerciements pour saluer Charlotte, Frédéric, Arnaud, Sébastien,Vincent, Samir, Marcelle, Mathieu, Camille, Cédric et Benoît qui ont connu,connaissentencore ou vont connaître les joies d’un doctorat. Je remercie également Christophe pour sescontributions aux développements des éditeurs de modèles évoqués dans ce mémoire.

Enfin, je remercie chaleureusement mes parents, ma sœur, mon beau-frère et ma belle-famille pour leur confiance et leur soutien sans faille. Et pour terminer, un merci tout parti-culier – exceptionnel et très personnel – à Joëlle.

A Ismaël et Alix.

Table des matières

Introduction vii

I Contexte et état de l’art 1

1 Contexte 31.1 Les systèmes embarqués temps réel . . . . . . . . . . . . . . . . . . . . . 51.2 L’ingénierie dirigée par les modèles . . . . . . . . . . . . . . . . . . . . . 81.3 Positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2 État de l’art 152.1 Les plates-formes d’exécution . . . . . . . . . . . . . . . . . . . . . . . . 172.2 Les représentations des plates-formes d’exécution . . . . . . . . . . . .. . 182.3 Les déploiements sur des plates-formes d’exécution . . . . . . . . . . . . .242.4 Comparaison des mises en œuvre . . . . . . . . . . . . . . . . . . . . . . . 422.5 Positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

II Considération explicite d’une plate-forme d’exécution 55

3 Un langage de description de plate-forme d’exécution 573.1 Le modèle de domaine dupackageSRM d’UML -MARTE . . . . . . . . . . 593.2 Implantation du modèle de domaine dans un DSML . . . . . . . . . . . . . 633.3 Artefacts de modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 683.4 Exemple d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723.5 Synthèse et résultats sur le langage proposé . . . . . . . . . . . . . . . . .74

4 Un processus de déploiement sur une plate-forme explicitement décrite 774.1 Intégration d’applications sur une plate-forme . . . . . . . . . . . . . . . . 794.2 Principe d’un déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . 804.3 Transformations de déploiement . . . . . . . . . . . . . . . . . . . . . . . 854.4 Développement d’une transformation de déploiement . . . . . . . . . . . . 1104.5 Choix de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1184.6 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

5 Évaluation 1295.1 Expérimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1315.2 Critères de comparaison . . . . . . . . . . . . . . . . . . . . . . . . . . . 1345.3 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1355.4 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Conclusion 143

vi Table des matières

III Annexes 149

A Métamodèle de RTEPML 151

B Extraits de transformations ATL 161

C Technologies de modélisation explicite des plates-formes d’exécution 191

Abréviations 199

Listes des figures, tableaux, algorithmes et listings 204

Bibliographie 218

Introduction

Contexte

Depuis plusieurs années, les systèmes électroniques et informatiques embarqués tendentà remplacer les systèmes de contrôles/commandes mécaniques ou électriques de nombreuxproduits [59]. Le potentiel de ces systèmes, qualifiés de temps réel [118], motive non seule-ment la prise en charge ou l’apport de fonctionnalités dans des produits existants (automo-biles, multimédia, etc.), mais également la création de nouveaux produits (cartesà puces,satellites, domotique, etc.). Les systèmes embarqués temps réel intègrent aujourd’hui deséquipements de plus en plus diversifiés, sophistiqués et présents dans nos environnements.

Cette diversité, cette sophistication et cette omniprésence ont inévitablement complexi-fié les systèmes et leurs cycles de développement [60]. Face à cette complexité et depuis denombreuses années, différentes couches d’abstractions logicielles ont été introduites (telsque les systèmes d’exploitations ou les intergiciels). Ces couches facilitent, d’une part,l’adaptation des applications logicielles aux différents supports matériels et fournissent,d’autre part, des composantes logicielles communes à de nombreuses applications. Ellesconstituent des plates-formes d’exécution logicielles pour les applications.

Mais aujourd’hui ces plates-formes tendent elles-aussi à évoluer et àse diversifier. Lesbesoins de réutilisation et de capacité de portage des applications sur différents supportsd’exécution (motivés entre autres par la réduction des temps de développement) oriententdonc le développement logiciel vers des conceptions indépendantes de toute plate-formed’exécution. Cette séparation se retrouve de plus en plus dans les pratiques métiers et lesformalismes utilisés dans le domaine de l’embarqué. Par exemple, dans la norme AUTO-SAR [7], norme automobile pour la conception de l’électronique et l’informatique embar-quées, la modélisation de l’application est clairement séparée et indépendante du supportd’exécution (support qui lui aussi a été normé, successivement OSEK/VDX-OS [93] etAUTOSAR-OS [8]).

En outre, les préoccupations inhérentes aux systèmes embarqués temps réel (respect descontraintes temporelles, limitation des ressources, etc.) dépendent étroitement du supportd’exécution. La plate-forme d’exécution joue un rôle depuis l’analyse des propriétés fonc-tionnelles et temporelles d’une application, tôt dans le cycle de développement, jusqu’audéploiement de l’application sur la plate-forme. Dans une vision idéale, une applicationdoit donc être conçue indépendamment de tout support d’exécution, touten garantissant,dès la phase de conception, son déploiement sur les supports envisagés(dans le respect deses contraintes d’exécution). Le support d’exécution doit donc être représenté à la fois ex-plicitement, pour pouvoir être pris en compte dès la phase de conception, et séparément del’application, pour ne pas en dénaturer les représentations successives durant cette phase.

L’ingénierie dirigée par les modèles (IDM) [43], une discipline informatique émergente,vise justement à faciliter la représentation et l’agencement des systèmes dans un cycle dedéveloppement. Elle prône pour cela l’utilisation de modèles et de transformations de mo-dèles. Les modèles décrivent les systèmes, les transformations automatisent la manipulationet l’évolution de ces modèles.

viii Introduction

Problématiques et objectifs

Dans l’IDM, l’approche MDA (Model Driven Architecture) [84], initié par l’OMG (Ob-ject Management Group), définit en particulier un cadre méthodologique pour différencierles modèles indépendants des plates-formes (PIM , Platform Independant Model) de ceuxqui en dépendent (PSM, Platform Specific Model). Des transformations de modèles, plus oumoins automatiques, spécialisent alors des PIM en PSM.

Cependant, le MDA ne précise pas comment renseigner les informations relatives auxplates-formes dans ces transformations. La notion de description de plate-forme est évoquée(PDM, Platform Description Model), mais aucune précision n’est donnée sur sa forme ousur sa prise en compte dans un processus de déploiement.

Dans de nombreux travaux, la notion de PDM se retrouve alors sous différentes formes.Un PDM peut par exemple être décrit dans un modèle qu’il est envisageable de transmettrecomme paramètre à une transformation. Un PDM peut également être intégré dans une trans-formation ou encore implicitement décrit dans un langage de modélisation (ou métamo-dèle). Dans ce cas, une transformation de déploiement consiste à générer une descriptiond’application conforme à ce langage.

Nous constatons donc que chaque forme que prend un PDM influence la mise en œuvred’un déploiement. La répartition des connaissances relatives à l’application, à la plate-formeet à notre domaine d’intérêt (l’embarqué temps réel) diffère par exemple d’une approche àl’autre. L’investissement nécessaire au développement des modèles, des métamodèles et destransformations impliqués dans un déploiement n’est donc pas le même. Mais, aucune étuden’a été identifiée qui recense et qui compare ces approches et leurs répercussions.

Deux questions successives se posent alors :

– Quelle représentation d’une plate-forme d’exécution est préférable pour un déploie-ment d’application ?

– Comment mettre en œuvre ce déploiement pour un système embarqué temps réel?

Cette thèse vise à répondre à ces deux questions. La première réponse est de recenseret de comparer les approches IDM de modélisation des plates-formes d’exécution dans unobjectif de déploiement d’applications. La seconde réponse est de proposer un processus dedéploiement concret, basé sur l’approche la plus appropriée au contexte d’utilisation prévu :le déploiement d’applications sur des plates-formes d’exécution temps réelembarquées.

Contributions

Cette thèse contribue en trois points à la considération des plates-formes d’exécutionlors d’un processus de déploiement.

Une étude comparative des approches IDM de déploiementest présentée. Cette étudecouvre les différentes modélisations envisageables d’une plate-forme d’exécution et les ré-percussions de ces modélisations sur un processus de déploiement d’applications.

Elle identifie les pratiques existantes et les pratiques qu’il reste à explorer, avant de sta-tuer sur l’approche la plus adaptée à notre domaine d’intérêt (les plates-formes d’exécutiontemps réel embarquées).

Un langage de modélisation des plates-formes d’exécution temps réel embarquéesest défini sous le nom de RTEPML (Real-Time Embedded Platform Modeling Language).Ce langage s’appuie sur les concepts qu’identifie lepackageSRM (Software Resource Mo-deling) du profil UML -MARTE (UML profile for Modeling and Analysis of Real Time and

Introduction ix

Embedded systems) [89]. RTEPML permet de décrire des plates-formes d’exécution dansun contexte de développement utilisant des DSML (Domaine Specific Modeling Language)comme alternative aux langages de modélisation généralistes (Generic Purpose ModelingLanguage, dont UML est un représentant, y compris dans ses formes profilés).

Un processus de déploiement d’applicationbasé sur RTEPML est finalement proposé.Ce processus repose sur des transformations de modèles. L’originalité de ce processus ré-side dans son articulation autour de règles de transformations génériquesou générées. Ils’accompagne d’un langage dédié à l’expression des déploiements.

Plan

Ce rapport s’organise en deux parties. La première partie précise la portée de cette thèseet présente une étude prospective sur les pratiques de déploiements dans l’I DM. La secondepartie se focalise sur la solution que nous proposons pour mettre en œuvreun déploiementd’application sur une plate-forme d’exécution temps réel embarquée.

La première partie se divise en deux chapitres.

Le premier chapitre détaille le contexte et la portée de cette étude. Les domainesdessystèmes embarqués temps réel et de l’IDM y sont successivement abordés.

Le second chapitre présente les approches de modélisation des plates-formes d’exécu-tion dans l’IDM et les processus de déploiement d’applications qui en résultent. Dans unétat de l’art prospectif, trois approches de modélisation sont identifiées :enfouie, impliciteet explicite, selon que les informations relatives à une plate-forme sont capturées dans unetransformation, un métamodèle ou un modèle. A chacune de ces approches correspondentune ou plusieurs pratiques de déploiement d’applications. Ces pratiques sont présentées etévaluées sur des critères de séparation des préoccupations, de temps de développement, deréutilisation et de prise en compte des choix de déploiement. A l’issue de cette évaluation,l’une des pratiques est privilégiée.

La seconde partie se compose des trois derniers chapitres.

Le troisième chapitre présente le langage de description de plate-forme d’exécutionRTEPML que nous avons développé dans le cadre de cette thèse. Ce langage implante, d’unepart, le modèle de domaine dupackageSRM d’UML -MARTE et, d’autre part, un certainnombre d’artefacts de modélisation utiles à la description de modèles de plates-formes.

Le quatrième chapitre propose un processus de déploiement d’applications temps réelembarquées. Le processus proposé se concrétise par un algorithme detransformations demodèles. Ces transformations prennent comme paramètres des modèles d’applications etdes modèles de plates-formes d’exécution décrits avec RTEPML. Elles se composent derègles génériques ou générées. Leurs mises en œuvre s’appuient sur un langage de déploie-ment que nous définissons également dans ce chapitre.

Le cinquième chapitre évalue finalement le processus de déploiement que nous propo-sons. Cette évaluation repose sur une comparaison avec d’autres approches de déploiementidentifiées lors de la prospection du second chapitre. Elle vise à confirmer les résultats quiont motivé le développement du processus.

Première partie

Contexte et état de l’art

1Contexte

Sommaire1.1 Les systèmes embarqués temps réel . . . . . . . . . . . . . . . . . . 5

1.1.1 Introduction aux systèmes embarqués temps réel . . . . .. . . 51.1.2 Mise en œuvre . . . . . . . . . . . . . . . . . . . . . . . . . . 51.1.3 Portée de l’étude . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.2 L’ingénierie dirigée par les modèles . . . . . . . . . . . . . . . .. . 81.2.1 Introduction à l’ingénierie dirigée par les modèles .. . . . . . . 81.2.2 Mise en œuvre d’une ingénierie dirigée par les modèles. . . . . 11

1.3 Positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Ce chapitre présente le contexte et la portée de cette étude. Il introduit en particulier levocabulaire employé et les concepts mis à contribution.

Ce chapitre s’organise en deux sections. La première définit le domaine d’applicationde l’étude, qui concerne le développement de systèmes embarqués temps réel. Cette sectiondécrit les principes de mise en œuvre de ces systèmes. La seconde sectionintroduit l’ingé-nierie dirigée par les modèles (IDM). Elle présente en particulier les concepts de l’IDM misà contribution dans la suite de cette étude.

1.1. Les systèmes embarqués temps réel 5

1.1 Les systèmes embarqués temps réel

1.1.1 Introduction aux systèmes embarqués temps réel

Un système embarqué(embedded system) est un système électronique et informatiqueintrinsèquement lié à un équipement (industriel ou bien de consommation) pourlequel il estconçu et dans lequel il est intégré. Il est entièrement dédié à une ou plusieurs fonctionnalitésattendues de cet équipement [59] et n’a pas de raison d’être en dehors de celui-ci [45].

Les activités identifiées d’un tel système concernent les traitements liés au fonction-nement de l’équipement, les interactions avec l’équipement, les interactions avec d’autreséquipements et les interactions avec l’environnement physique ou humain [106]. Le terme« système enfoui » souligne parfois la capacité limitée ou l’absence d’interaction directeavec un utilisateur.

Un système embarqué temps réel(real-time embedded system) est un système em-barqué dans un équipement (ou procédé) dont il doit contrôler et commander le compor-tement [118]. Le qualificatif « temps réel » du système est dû à l’évolution dynamique duprocédé auquel il est connecté et qu’il doit piloter [38]. Il reflète une capacité de réaction àl’échelle de temps du procédé1.

Les interactions entre un système embarqué temps réel et le procédé qu’il piloteprennent généralement la forme : de mesures prélevées par le système sur le procédé, d’évè-nements que le procédé signale au système et de signaux de commande adressés au procédépar le système [116].

1.1.2 Mise en œuvre

Un système embarqué temps réel se compose principalement : (a) d’une applicationchargée de piloter le procédé, (b) d’un support d’exécution matériel et/ou logiciel et (c) depériphériques, tels que des actionneurs répondant aux ordres de l’application ou des capteurstransmettant les mesures et les évènements issus du procédé.

1.1.2.1 Architecture matérielle

Qu’ils soient embarqués ou plus généralistes, les supports d’exécution matériels s’ar-ticulent aujourd’hui autour de quatre types d’architectures : (a) monoprocesseur, (b) mul-tiprocesseur, (c) multicœur et (d) distribuée [110]. Les architectures multiprocesseurs oumulticœurs enrichissent l’approche monoprocesseur d’un parallélisme matériel pour le trai-tement des données. Ce parallélisme s’étend géographiquement avec unearchitecture dis-tribuée.

Orthogonalement, la mise en œuvre d’une application embarquée peut suivre une ap-proche logicielle, matérielle ou mixte. En effet, tout traitement de l’application peut êtreeffectué soit par un programme logiciel s’exécutant sur un processeur, soit par un circuitmatériel personnalisé, tel que les ASIC (Application Specific Integrated Circuit) et les FPGA

(Field Programmable Gate Array). Une approche mixte consiste à mettre en œuvre conjoin-tement (co-design) la configuration matérielle et la programmation logicielle [125].

Positionnement Nos travaux se restreindront aux architectures monoprocesseurs. Tou-tefois, nous envisageons de mettre en œuvre des applications logicielles indépendammentde l’architecture matérielle. Aucune attention particulière ne sera donc portée sur la concep-tion ou la configuration du support matériel (processeurs, mémoires, capteurs, actionneurs,etc.). Nous nous focalisons sur les aspects logiciels des systèmes.

1Le terme « système réactif » est pour cela parfois utilisé.

6 Chapitre 1. Contexte

1.1.2.2 Support d’exécution logiciel

La réalisation d’un logiciel embarqué se concrétise par un programme dontl’exécutionest soit autonome sur le support d’exécution matériel, soit dépendante d’un support d’exé-cution logiciel intermédiaire (un système d’exploitation).

En contrepartie d’une occupation mémoire accrue, l’utilisation d’un système d’exploi-tation présente l’avantage de fournir aux programmes utilisateurs une interface simplifiéeavec le matériel et, parfois, des logiciels annexes tels que des pilotes de périphériques stan-dards2 et des accès à des protocoles de communication [111].

Dans un contexte temps réel, les systèmes d’exploitation offrent de plus uneinterfacesimplifiée pour : (a) aiguiller le traitement des évènements issus du procédé contrôlé, (b)suivre l’écoulement du temps d’une horloge matérielle temps réel et (c) gérer des actionsdans le temps (via, par exemple, des alarmes) [117].

On notera que certaines approches orientent leur solution vers un développementconjoint des applications et des systèmes d’exploitation [42] [72]. Ces approches consistenthabituellement à générer les systèmes d’exploitation.

Enfin, des couches d’abstraction logicielles peuvent s’intercaler entreles systèmes d’ex-ploitations et les applications, tels que les machines virtuelles ou les intergiciels.

Positionnement Nous nous intéressons à mettre en œuvre des applications logiciellesdont l’exécution repose sur un système d’exploitation. Toutefois, aucunsystème d’exploi-tation ne sera imposé. Nous ne projetons pas non plus de développer ou degénérer dessystèmes d’exploitation. Les systèmes d’exploitation envisagés sont supposés disponibles.L’utilisation d’un support d’exécution logiciel intermédiaire ne sera pas non plus envisagé.

1.1.2.3 Synchrone ou asynchrone

La mise en œuvre d’un système temps réel requiert d’établir un lien entre l’occurrenced’un évènement et l’activation d’une action associée. Deux principes fondamentaux per-mettent de régir ce lien : l’approche « synchrone » et l’approche « asynchrone » [100].

L’approche synchrone repose sur (1) l’hypothèse de réalisation des actions en tempsnul vis-à-vis de la dynamique du procédé contrôlé et (2) la considérationd’occurrencesd’évènement simultanées. Les occurrences des évènements mémorisés durant l’exécutiond’une action sont considérées comme survenues au même instant. Cette approche s’affran-chit implicitement d’une concurrence entre les actions durant leurs exécutions. En pratique,les systèmes synchrones sont programmés sous la forme de systèmes échantillonnés danslesquels la durée d’exécution des actions est inférieure à la période d’échantillonnage [21].

L’approche asynchroneconsiste à observer en permanence les occurrences d’évène-ment. Cette approche s’accorde avec l’asynchronisme d’un environnement naturel. Cepen-dant, durant l’exécution d’une action, la considération d’une occurrence d’évènement dé-clenche l’activation d’une action concurrente. Le problème de la concurrence entre plusieursactions doit alors être adressé.

Positionnement Les systèmes que nous souhaitons mettre en œuvre suivent une ap-proche asynchrone.

2Dans la majorité des cas, un système embarqué nécessite cependant des périphériques spécifiques.

1.1. Les systèmes embarqués temps réel 7

1.1.2.4 Systèmes d’exploitation multitâches

Les systèmes d’exploitation multitâches permettent d’exécuter de façon concurrente dif-férentes actions prévues par une application (les tâches3). Pour adresser les problèmes deconcurrences entre les tâches, ces systèmes d’exploitation fournissent des mécanismes desynchronisation, de communication et d’accès à des ressources partagées4.

Dans un système multitâches, les accès concurrents concernent en particulier les res-sources d’exécution. Une politique d’ordonnancement consiste alors adéterminer l’alloca-tion de ces ressources entre différentes tâches concurrentes. Cette politique est appliquéepar un ordonnanceur5. Elle peut être définie « en ligne » ou « hors ligne ».

Une politique d’ordonnancement « en ligne » s’appuie habituellement sur unmécanismede priorité [100]. Son principe consiste à exécuter la tâche de plus forte priorité parmi cellesen concurrence. Les priorités peuvent être définies statiquement ou dynamiquement, sur labase de critères liés à l’ensemble des tâches concurrentes, tels que leurséchéances ou leurspériodes d’exécution [71]. Ce type de politique peut être préemptive, non-préemptive oumixte, selon qu’une tâche peut ou ne peut pas être interrompue au profit d’une autre.

Une politique d’ordonnancement « hors ligne » impose un cycle prédéfini d’exécutiondes tâches. Le rôle de l’ordonnanceur est alors réduit à celui d’un séquenceur.

Parallèlement, dans un système multitâche, l’observation des occurrences d’évènementest soit continue, soit régie par le temps.

Dans le premier cas, toute occurrence d’évènement se manifeste par un appel à l’exécu-tif. Le système est dit « cadencé par les évènements » (event triggered). Les exécutifs tempsréel OSEK/VDX-OS [93], ARINC-653 [2] et VxWORKS [124] en sont des exemples.

Dans le second cas, un seul évènement externe, provenant d’une horloge périodique, semanifeste par un appel à l’exécutif. Au rythme de ces appels, le procédé est contrôlé parscrutation. La périodicité systématique de tout traitement permet de planifier lestâches del’application « hors ligne ». Le système est, dans ce cas, « cadencé par le temps » (time trig-gered). Les exécutifs temps réel MARS [61] et OASIS [27] mettent en œuvre cette approche.

Positionnement Les systèmes d’exploitation envisagés dans cette étude sont multi-tâches. Ils peuvent être cadencés par le temps ou par des évènements. Dans ce dernier cas,nous supposons que l’ordonnancement des tâches s’appuie sur despriorités (statiques oudynamiques). L’ordonnancement peut être préemptif, non-préemptif oumixte.

1.1.2.5 Sûreté de fonctionnement

La confiance accordée dans la mise en œuvre d’un système embarqué tempsréel relèvede sa sûreté de fonctionnement [67]. Le domaine de la sûreté de fonctionnement consisteà : (1) étudier et améliorer l’aptitude d’un système à satisfaire les fonctionnalités pour les-quelles il est conçu (en terme, par exemple, de fiabilité ou de disponibilité), et(2) cerner lesconséquences d’une défaillance (non-satisfaction d’une fonctionnalité attendue).

Les conséquences possibles d’une défaillance (d’un point de vue, par exemple, écono-mique ou de danger pour l’environnement ou les humains) classent les systèmes en dif-férentes catégories (telles que les définit, par exemple, la norme DO-178B pour l’aviationcivile [123]). Ainsi, les catégories vont des moins critiques (voir non-critiques) aux pluscritiques et se voient imposées des probabilités de défaillances décroissantes.

3Les tâches sont des unités, ou fils, d’exécution séquentielle.4L’exécutif est la partie du système d’exploitation qui gère ces mécanismes (entre autres).5L’ordonnanceur est un composant de l’exécutif.


Pour garantir des taux de défaillances acceptables, et apporter une confiance maximaledans les systèmes réalisés, leurs mises en œuvre sont généralement guidées et contraintestout au long du cycle de développement [9].

Positionnement Les systèmes envisagés dans cette étude peuvent être étendus à dessystèmes critiques. Toutefois, nous n’aborderons pas les exigences de sûreté de fonctionne-ment qui pourraient les accompagner, tant sur le processus de développement, que sur lesmécanismes mis en œuvre (tels que la gestion des erreurs ou les modes de fonctionnements).

1.1.3 Portée de l’étude

Les travaux de cette thèse portent sur le développement d’applications logicielles dontl’exécution repose sur un système d’exploitation temps réel embarqué.

Les systèmes d’exploitation visés sont multitâches, cadencés par le temps ou par lesévènements dans une approche asynchrone. Ces systèmes peuvent ordonnancer les tâchespar priorités statiques ou dynamiques. La politique d’ordonnancement n’est pas imposée.

La phase de développement concernée suppose que les tâches des applications sontidentifiées, issues d’une phase amont de conception. Leurs échéances et leurs priorités sont,par exemple, connues.

La section suivante présente l’ingénierie avec laquelle nous projetons demettre enœuvre les applications et, plus particulièrement, de les déployer sur des systèmes d’ex-ploitations.

1.2 L’ingénierie dirigée par les modèles

1.2.1 Introduction à l’ingénierie dirigée par les modèles

1.2.1.1 Modèles et métamodèles

Un modèle de système est une représentation (ou abstraction) d’un système, décrit dansune intention particulière [43] [76].

L’ingénierie dirigée par les modèles (IDM, ou MDE, Model Driven Engineering) placeles modèles au centre de l’activité de développement. Toute activité s’articuleautour d’unou de plusieurs modèles (conception, implantation, test, documentation, etc.). Le potentielde traitement automatique des modèles (telles que la simulation [30], l’analyse [40] [49] etla transformation [55]) est mis en exergue dans cette ingénierie. Les modèlessont « pro-ductifs », en opposition à une utilisation « contemplative », dans laquelle les modèles serestreignent à des supports de communication et de compréhension [12].

Métamodèle L’exploitation informatique des modèles implique de les exprimer dansdes langages « interprétables » (ou « manipulables ») par des outils informatiques [58]. Pourcela, l’IDM propose de définir des langages de modélisationvia des métamodèles.

Un métamodèle est une abstraction d’un langage permettant de décrire des mo-dèles [13]. Il définit les concepts et les relations entre ces concepts qui caractérisent lelangage.

Relation de conformité La relation entre un métamodèle et les modèles qu’il permetde décrire, est nommée « relation de conformité ». Un modèle se conforme à unmétamodèle.Cette relation permet d’assurer qu’un modèle est correctement construit,dans l’objectifde lui appliquer des traitements automatisés. Elle est généralement notéeχ (ou c2, pour« conform to», en anglais).

1.2. L’ingénierie dirigée par les modèles 9

Espace technique La particularité de l’IDM réside dans l’utilisation systématiquede métamodèles. L’abstraction des concepts d’un langage qu’offre un métamodèle lui vautparfois le terme de « syntaxe abstraite », en opposition aux « syntaxes concrètes » que four-nissent les grammaires ou les chartes graphiques permettant d’exprimer lesmodèles dansdes formats textuels ou graphiques.

Des « passerelles » sont néanmoins nécessaires entre ces différentesreprésentations.Pour cela, la notion d’espaces technologiques [64] (ou espaces techniques [14]) permetà différents contextes de cohabiter, en instaurant des analogies entre les concepts de cescontextes. Dans l’espace technique des modèles qu’incarne l’IDM, la relation de conformitéentre un modèle et un métamodèle reflète, par exemple, les relations entre :

– un document XML et un schéma ou une DTD, dans l’espace technique XML ;– un texte et une grammaire, dans l’espace technique des grammaires ;– un objet et une classe, dans l’espace technique orienté-objet.

Chacune de ces analogies est à la base d’un processus d’échange entre ces espaces tech-niques, telles que la sérialisation des modèles dans des formats XML , la création de syntaxestextuelles de langages de modélisation et la mise en œuvre deframeworkde modélisationen langage objet.

Méta-modélisation En réponse à une utilisation systématique de métamodèles, denombreuses plates-formes de développement, telles que openArchitectureWare [37], TOP-CASED [41], GME [53] ou MetaCase+ [74], supportent des outils à métamodèles « va-riables » [12]. Pour cela, ces outils s’appuient sur des langages permettant de décrire desmétamodèles (ou langages de méta-modélisation).

A l’instar du rôle que joue un métamodèle vis-à-vis d’un langage de modélisation, unméta-métamodèle est une abstraction d’un langage de méta-modélisation. Les plates-formesde développement intègrent alors des méta-métamodèles issus de projet en lien direct avecdes outils, tels que MetaGME [68] du projet GME (Generic Modeling Environment) ouEcore [36] du projet EMF (Eclipse Modeling Framework). Généralement, ces plates-formesse placent également dans un contexte normatif, tel que le standard MOF (Meta ObjectFacility) [86] de l’OMG (Object Management Group).

1.2.1.2 Transformation de modèles

La notion de transformation de modèle est un concept essentiel pour rendre un modèleproductif [44]. Une transformation de modèle est un processus automatique de modificationd’un ou de plusieurs modèles. Elle consiste généralement à générer un ensemble de modèles« cibles » à partir d’un ensemble de modèles « sources » (figure 1.1, page suivante).

Trois générations de langages de transformations se distinguent par l’organisation (oula structure) des éléments qu’ils manipulent [11] :

1. Les langages de transformation de structures séquentielles d’enregistrement, tel queAWK (du nom de ses concepteurs, Aho, Kernighan et Weinberger) [1], s’emploientgénéralement dans l’espace technique des grammaires ;

2. Les langages de transformation d’arbres, tel que XSLT (Extensible Stylesheet Lan-guage Transformations) [122], sont d’usage dans l’espace technique XML ;

3. Les langages de transformation de graphes (généralement, orientés étiquetés),tels que ATL (ATLAS Transformation Language) [55] ou QVT (Query-View-Transformation) [91], se prêtent à l’espace technique des modèles.

Aujourd’hui, les transformations de modèles s’appuient essentiellement sur des lan-gages de transformation de graphes.


Modèle de transformation Une transformation de modèle s’appuie sur des règles detraduction qui font correspondre les concepts des métamodèles sources et cibles. Ces règlessont décrites dans des modèles de transformation (conformes au métamodèlequi définit lelangage de transformation). On notera que deux types de règles se distinguent : impérativeset déclaratives, selon que l’ordre de leurs exécutions est imposé ou non.

Un moteur de transformation applique les règles de traduction pour générerles élé-ments des modèles cibles à partir de ceux des modèles sources. Il s’appuiepour cela sur lesrelations de conformité entre les éléments des modèles et les concepts des métamodèles.

FIG. 1.1:Principe de mise en œuvre d’une transformation de modèle dans l’IDM.

Remarque : Par abus de langage, le terme « transformation » se réfère également auxmodèles de transformation.

Modèle vers texte Les transformations de modèles génèrent habituellement des mo-dèles destinés à des outils IDM et donc sérialisés dans des formats spécifiques à l’IDM, telsque le XMI (XML Metadata Interchange) [88]. Or, le développement d’un système visehabituellement la production de fichiers dans des formats textuels différents, tels que de ladocumentation HTML ou du code source dans un langage de programmation donné.

Pour répondre à ce besoin de transformation d’un modèle vers du texte, plusieurs caté-gories de langages peuvent être mis à contribution :

1. Les langages de transformation de modèle qui gèrent des chaînes de caractère ensortie, comme le permet ATL ;

2. Les langages detemplatequi acceptent des modèles en entrée, tels que Acceleo [79]et XPand [121] ;

3. Les langages de générateurs d’extracteurs (du modèle vers le texte)et d’injecteurs(ou parseurs, du texte vers le modèle), tels que TCS [57] et SinTaks [78].

Remarque : Un fichier detemplateest composé de blocs de texte dont une partie desinformations doit être complétée à partir de données externes. Dans le cadre de l’IDM, cesdonnées sont transmises à un moteur detemplatesous la forme de modèles.


1.2.2 Mise en œuvre d’une ingénierie dirigée par les modèles

1.2.2.1 Approches centrées sur les modèles

Différentes approches centrées sur les modèles se déclinent au sein del’I DM. Quatre deces approches se distinguent par la maturité des outils qui les accompagnent : les approchesCASE (Computer Aided Software Engineering), M IC (Model-Integrated Computing), Usinelogicielle (Software Factories) et MDA (Model Driven Architecture) [52].

CASE Dans les années 80, l’approche CASE (Computer Aided Software Engineering)spécialise pour le domaine du logiciel, l’approche CAD (Computer Aided Design) pratiquéenotamment pour la conception des systèmes mécaniques. L’approche CASE se destine alorsà supporter les activités de génie logiciel dans un processus de développement, sans définirprécisément ces activités et la nature du support qui en est fait [16].Ainsi les premiersoutils CASE automatisent principalement des activités isolées de développement, telles quela production de la documentation ou la gestion de version. Puis, dans les années 90, cesdifférents outils sont intégrés dans des environnements de type CASE, autour de supportsméthodologiques de conception et de réalisation, pour former de véritablesplates-formesde développement [77].

M IC Depuis le milieu des années 90, l’approche MIC (Model-Integrated Computing)fonde son développement logiciel sur des modèles spécifiques à des domaines d’applica-tion [108]. Cette approche se décompose en deux phases. La première consiste à spécifierles concepts utiles pour modéliser le domaine d’application. Le résultat de cetteétape seconcrétise par la définition d’un métamodèle et la génération d’un environnement de mo-délisation dédié au domaine. La seconde phase consiste alors à modéliser les applicationsavec cet environnement. GME (Generic Modeling Environment) [28] est un exemple deplate-forme de développement associée à cette approche.

Usine logicielle Depuis les années 2000, l’approche « usine logicielle » (SoftwareFactories) s’inspire des principes des lignes d’assemblage dans l’industrie [51].Une usinelogicielle est un ensemble d’outils et de langages (par exemple, de modélisation, de pro-grammation ou de transformation) spécialisés pour le développement d’un certain typed’application. Cette approche encourage l’utilisation de « composants sur étagère »6 pourun développement rapide de logiciels. Visual Studio .NET est un exemple d’environnementde développement adapté à cette approche.

M DA Depuis novembre 2000, l’approche MDA (Model Driven Architecture) [84],initiée par l’OMG, standardise une architecture qui repose sur un niveau (M0) des systèmesà concevoir (ou « monde réel ») et trois niveaux de modélisation (M1, M2 etM3) pour ledéveloppement des modèles, métamodèles et méta-métamodèles7. Dans cette architecture,un méta-métamodèle du niveauM3 est réflexif, c’est-à-dire qu’il se décrit lui-même. LeMOF (Meta Object Facility) [86], standardisé dans le cadre du MDA, et Ecore (du projetEMF) [36] sont des exemples de méta-métamodèles.

L’un des objectif du MDA est de faciliter la mise en œuvre de modèles de fonctionnalités(ou modèles métiers) sur différents supports technologiques. Pour cela,cette approche pro-pose de générer, par transformation, des modèles dédiés à des plates-formes technologiques(PSM, Platform Specific Model), à partir de descriptions indépendantes de toute plate-forme(PIM , Platform Independant Model). Au sens du MDA, les technologies et les plates-formes

6Un composant sur étagère est un composant disponible pour être assemblé avec d’autres composants.7L’architecture « 3+1 niveaux » du MDA standardise ainsi ce que l’approche MIC et certains outils CASE

pratiquent depuis plusieurs années.


englobent aussi bien l’environnement de développement que le support d’exécution d’uneapplication.

En pratique, l’indépendance d’un modèle vis-à-vis d’une plate-forme peut se concréti-ser par une montée en abstraction progressive. Un PIM peut être raffiné en plusieurs PSM

successifs. Cet enchaînement de transformations, pratiquées dans l’«espace de modélisa-tion », aboutit à une implantation, dans l’« espace de codage », compilable ou interprétablesur une plate-forme technologique précise.

Cependant, comme cela fut mentionné en introduction, le MDA ne précise pas commentrenseigner les informations relatives aux plates-formes dans les transformations. La notionde description de plate-forme est évoquée (PDM : Platform Description Model), mais au-cune précision n’est donnée sur sa forme et sur sa prise en compte dans le processus degénération. Un PDM peut, par exemple, faire partie intégrante d’un modèle de transforma-tion (d’un PIM vers un PSM) ou être passé en paramètre de cette transformation.

La figure 1.2 illustre un processus de transformation de modèles dans le MDA.

FIG. 1.2:Considération progressive des plates-formes dans le MDA.

Positionnement Dans cette étude, le déploiement d’une application sur le supportd’exécution (ou plate-forme d’exécution) qu’incarne le système d’exploitation est abordéeselon l’approche MDA. Ce déploiement est donc mis en œuvre par transformation d’unmodèle de l’application en un modèle de cette même application déployée sur la plate-forme. Pour cela, cette étude se doit d’adresser la question laissée ouverte par le MDA surla considération de la plate-forme d’exécution dans le processus de transformation.

1.2.2.2 Langages de modélisation généralistes ou dédiés

Deux courants majeurs se distinguent actuellement dans l’IDM. Le premier tend à uni-fier les moyens d’expression de modélisation dans un seul langage. Le second sépare cesmoyens dans différents langages dédiés à des domaines métiers. Ces deuxapproches sontsimilaires à ce qui distingue les langages généralistes de programmation (tels que Java ouC) et les langages de programmation dédiés (tels que SQL ou LATEX).


Un langage de modélisation généraliste(GPML, Generic Purpose Modeling Lan-guage) vise à identifier des concepts génériques à plusieurs contextes de développement. Lelangage UML (Unified Modeling Language) [90], standardisé par l’OMG, est aujourd’hui leplus représentatif des langages de modélisation généralistes.

La définition des concepts de modélisation et la standardisation de leurs représentationsdans un seul langage favorisent l’homogénéité des outils, la réutilisation des modèles etles échanges entre les utilisateurs. Le consensus à maxima nécessaire à l’adoption d’un tellangage peut toutefois engendrer une profusion de concepts. Cette profusion complexifiealors, d’une part, la prise en charge du langage dans les outils et, d’autre part, la localisationdu concept le plus pertinent pour un problème donné.

Pour palier à l’absence de considérations métiers, des mécanismes d’extension peuventégalement être nécessaires. L’OMG propose ainsi deux mécanismes d’extensions du langageUML . Une extension dite « lourde » intervient directement sur le métamodèle du langagepour y ajouter, supprimer ou modifier des concepts [17]. Ce type d’extension comprometalors fortement la généricité du langage. Une extension dite « légère » raffine le métamodèledu langage pour introduire des concepts métiers. L’OMG standardise ce type d’extension parla notion de profil [90] [47].

Une extension de GPML, tel qu’un profil UML , permet donc d’identifier un ensemblede concepts spécialisés pour un domaine métier. Les experts du domaine sont alors plus àmême de comprendre les modèles et de les valider. Les développeurs et les experts s’ac-cordent autour d’un champ lexical commun.

Un langage de modélisation dédié à un domaine(DSML, Domain Specific ModelingLanguage), à l’image des profils UML , vise à identifier les concepts d’un domaine métier.A l’inverse des profils UML , les DSML ne se basent pas sur le métamodéle UML (noyaucommun de concepts) mais définissent entièrement des langages plus restreints, limités audomaine métier. Il se conforment pour cela à des méta-métamodèles (tels que le MOF del’O MG ou Ecore du projet EMF). Le langage de description d’architecture AADL (Archi-tecture Analysis & Design Language) [103], standardisé par la SAE (Society of AutomotiveEngineer), est un exemple de DSML du domaine de l’embarqué et du temps réel critique.

La restriction des concepts à un domaine métier encourage l’expression concise de mo-dèles pour des objectifs précis. Cependant, les outils associés à un DSML sont économique-ment plus difficiles à maintenir, car destinés à un public restreint de spécialistes. Toutefois,dans le cadre de l’IDM, leurs développements sont de plus en plus assistés par différentsprojets consacrés à la génération automatique d’outils. GME (Generic Modeling Environ-ment) [28], EMP (Eclipse Modeling Project, incluant EMF, GEF et GMF) [35] et TOPCA-SED [41] en sont des exemples.

Positionnement Les approches par DSML et GPML présentent chacune des avantageset des inconvénients qui, à notre sens, ne permettent pas de trancher, sur l’utilisation de l’uneou de l’autre dans l’absolu. Nous considérons en effet que le choix d’une de ces approchesdépend du contexte de développement (domaines abordés, intervenants, collaborateurs, ou-tillage, etc.). Ce choix appartient,in fine, aux utilisateurs (chef de projets, concepteurs,développeurs, testeurs).

De ce point de vue, les travaux de recherche se doivent d’investir chacune des approches.Cette étude s’inscrit donc dans une démarche d’investigation pour les deux approches.

Toutefois, une seule étude couvrant les DSML et les GPML serait ambitieuse. Seulel’étude prospective sur la modélisation des plates-formes d’exécution et ses répercussionssur un processus de déploiement sera donc abordée pour les deux approches. La propositionde processus de déploiement d’application qui suivra sera présentéepour un contexte demodélisation utilisant des DSML.


1.3 Positionnement

Comme cela fut mentionné en introduction, les travaux de cette thèse portent sur ledéploiement d’applications logicielles sur des systèmes d’exploitation temps réel embar-qués. Pour cela, les technologies de modélisation et de transformation de modèles, issuesde l’IDM, sont mises à contribution.

Dans une première section, nous venons de préciser la nature des systèmes sur lesquelsnous envisageons de déployer les applications. Les systèmes visés sontmultitâches, caden-cés par le temps ou par les évènements dans une approche asynchrone.

Dans une deuxième section, nous avons précisé la méthodologie de déploiement quenous adopterons au travers des principes de l’IDM et plus particulièrement de l’approcheMDA. Les applications seront décrites dans des modèles indépendants de toutsupport d’exé-cution. Un déploiement sera ensuite mis en œuvre par transformation de modèles, à l’issuduquel un modèle de l’application déployée sera généré.

Cependant, l’approche MDA ne précise pas comment renseigner les informations re-latives aux plates-formes lors du déploiement. Le chapitre suivant propose donc un étatde l’art prospectif sur les différentes formes que peuvent prendre ces informations et leursrépercussions sur un processus de déploiement.

Cette prospection est menée dans des contextes de modélisation basés sur des langagesde modélisation génériques (GPML) et sur des langages de modélisation dédiés à des do-maines métiers (DSML).

2État de l’art

Sommaire2.1 Les plates-formes d’exécution . . . . . . . . . . . . . . . . . . . . .. 17

2.1.1 Définition du concept de plate-forme d’exécution . . . .. . . . 172.1.2 Caractérisation des plates-formes d’exécution . . . .. . . . . . 172.1.3 Positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2 Les représentations des plates-formes d’exécution . . .. . . . . . . 182.2.1 Représentations enfouies . . . . . . . . . . . . . . . . . . . . . 182.2.2 Représentations implicites . . . . . . . . . . . . . . . . . . . . 192.2.3 Représentations explicites . . . . . . . . . . . . . . . . . . . . 21

2.3 Les déploiements sur des plates-formes d’exécution . . .. . . . . . 242.3.1 Plate-forme enfouie dans la technologie de déploiement . . . . 242.3.2 Déploiement sur une plate-forme implicitement décrite . . . . . 262.3.3 Déploiement sur une plate-forme explicitement décrite . . . . . 30

2.4 Comparaison des mises en œuvre . . . . . . . . . . . . . . . . . . . . 422.4.1 Génération d’un modèle de code source . . . . . . . . . . . . . 432.4.2 Génération d’un modèle d’application . . . . . . . . . . . . .. 45

2.5 Positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Ce chapitre présente une étude prospective des considérations possibles des plates-formes d’exécution au sein d’un processus de déploiement d’applications. Pour cela,

ce chapitre s’organise en cinq sections.

La première section définit, dans le cadre de l’IDM, le concept de plate-forme d’exécu-tion et recense les besoins de modélisation d’une telle plate-forme. La seconde section iden-tifie trois approches majeures de modélisation d’une plate-forme d’exécution, approchesqualifiées de représentationsenfouies, implicites ou explicites. La troisième section pré-sente ensuite les processus de déploiement d’application conditionnés parces différentesapproches de modélisation. Puis, la quatrième section compare les mises en œuvre de cesprocessus. La cinquième et dernière section positionne finalement les travaux de cette étudeen fonction de l’évaluation des processus.

2.1. Les plates-formes d’exécution 17

2.1 Les plates-formes d’exécution

2.1.1 Définition du concept de plate-forme d’exécution

Le concept de plate-forme d’exécution se réfère aux systèmes, supports logiciels et ma-tériels, nécessaires à l’exécution d’autres systèmes qualifiés d’applications. Une plate-formed’exécution offre un contexte pour l’interprétation de ce que spécifie l’application [73]. Ellefournit pour cela des concepts et des services pour satisfaire aux besoins de l’application.

La représentation en couches successives d’infrastructure matérielle, de système d’ex-ploitation, de machine virtuelle et d’intergiciel illustre une hiérarchie typique des plates-formes d’exécution [5]. Chacune de ces couches présente une abstraction des plates-formessous-jacentes[96].

En pratique, toute plate-forme peut-être considérée comme une application pour uneplate-forme de plus bas niveau d’abstraction [73]. Un système d’exploitation peut être vu,par exemple, comme une application du point de vue d’un fournisseur de support matériel, etcomme une plate-forme d’exécution du point de vue d’un développeur logiciel. Un systèmesera donc considéré en tant que plate-forme, non pas en raison de sa nature, mais en fonctiondu rôle qui lui est attribué dans le système global [33].

Orthogonalement, deux types de plates-formes se distinguent : les plates-formes abs-traites et les plates-formes concrètes [3]. Une plate-forme abstraite offre des concepts théo-riques, pour les besoins de développement d’une application à un instantdonné. L’implan-tation de ces concepts relève ultérieurement d’une ou de plusieurs plates-formes concrètes,pour les besoins de mise en œuvre effective. La différence entre plates-formes d’exécu-tion abstraites et concrètes réside donc dans la mise à disposition d’un support fonctionnelpermettant l’exécution d’une application.

Une étude détaillée de la notion de plate-forme d’exécution a fait l’objet d’unétat del’art, au sein de l’équipe, lors de recherches antérieures [114]. Desprécisions y sont donnéessur les apports successifs des travaux référencés dans cette partie.

2.1.2 Caractérisation des plates-formes d’exécution

Dans le contexte d’une ingénierie dirigée par les modèles, le MDA spécifie qu’une plate-forme fournit un ensemble de fonctionnalités, au travers d’interfaces, et des patrons d’utili-sation de ces fonctionnalités [84].

Atkinson et Kühne [5] identifient quatre aspects à travers lesquels les informations surles fonctionnalités d’une plate-forme sont communiquées : (a) un langage,qui décrit lesconcepts avec lesquels les applications destinées à une plate-forme peuvent être conçues,(b) des types prédéfinis, qui enrichissent les fonctionnalités du langage avec des servicesadditionnels (tel que le typepthread_tdes tâches logicielles, suggéré par la spécificationPOSIX), (c) des instances prédéfinies directement utilisables par l’application (tels que lesflux d’entrée et de sortiestdin et stdoutde la librairie standard du langage C) et (d) lesmotifs, ou patrons, qui représentent les règles nécessaires à l’utilisationdes concepts mis àdisposition par les trois précédents aspects.

En se focalisant sur les plates-formes d’exécution logicielles, Marvieet al. [73] pro-posent d’organiser leurs fonctionnalités dans trois modèles distincts : (a)le modèle statiquedes ressources manipulées par la plate-forme (telles que les tâches logicielles pour un sys-tème d’exploitation multitâche), (b) le modèle dynamique des traitements réalisés parlaplate-forme (telles que la création et l’activation d’une tâche) et (c) le modèle d’évolution(ou cycle de vie) des ressources sous l’influence des traitements qui leurs sont appliqués (lecycle de vie d’une tâche est, par exemple, borné par sa création et sa destruction).

18 Chapitre 2. État de l’art

Ces deux approches témoignent d’une volonté de modélisation structurelle et compor-tementale d’une plate-forme d’exécution au travers de ce que Selic [98] [99] qualifie deressources et de services offerts par la plate-forme.

L’approche MDA précise que l’utilisateur d’une plate-forme n’est pas concerné par l’im-plantation des ressources et des services de la plate-forme. Dans un contexte logiciel, Tho-maset al. [115] soulignent qu’un modèle de plate-forme d’exécution peut se restreindre àla description des ressources, des signatures des services et de leurs comportements visiblesdepuis l’interface de programmation (ou API, Application Programming Interface).

Dans le respect de l’approche MDA et dans la lignée des travaux mentionnés précé-demment, Thomaset al. [115] identifient alors quatre axes pour modéliser l’interface deprogrammation d’une plate-forme d’exécution : (1) la caractérisation des concepts (les res-sources et les instances de ressources offertes par la plate-forme),(2) la caractérisation destraitements (les services associés aux ressources), (3) la caractérisation des règles d’utili-sation (les contraintes et les patrons d’utilisation des ressources et des services) et (4) lacaractérisation du comportement observable des ressources et des services (la descriptionde l’évolution dynamique des ressources sous l’influence des services).

2.1.3 Positionnement

Les représentations (ou modélisations) des plates-formes d’exécution envisagées danscette étude se focalisent sur les deux premiers axes définis par Thomaset al. : la descriptiondes ressources et des services offerts par les plates-formes d’exécution. Nous nous limitonspour cela à la description structurelle des ressources et des services,ce qui se traduit parla définition de leurs signatures visibles depuis l’interface de programmation et une clas-sification selon leurs rôles, c’est-à-dire leurs effets sur l’application. Les descriptions descomportements observables (ou sémantiques d’exécution) des ressources et des services neseront pas abordées. Ces descriptions faisant l’objet d’une étude menée en parallèle, nousles supposerons connues et accessibles, par exemple, dans des modèles annexes.

2.2 Les représentations des plates-formes d’exécution

Dans le contexte de l’IDM, plusieurs travaux se sont intéressés à décrire des plates-formes d’exécution logicielles ou matérielles. Bien que ces travaux divergent dans leursobjectifs (analyses de performance, déploiements, simulations matérielles, etc.), trois re-présentations majeures des plates-formes se distinguent. Cette section présente chacune deces représentations respectivement qualifiées d’enfouie, d’implicite et d’explicite.

2.2.1 Représentations enfouies

La première pratique identifiée consiste à décrire la plate-forme dans un modèle, ou unprogramme, dédié à un traitement précis en lien avec la plate-forme [18] [69][112] [119].Nous parlons alors de description ou de représentation enfouie, car le formalisme utilisépour décrire la plate-forme se destine principalement à ce traitement. Les informations re-latives à la plate-forme sont alors indissociables des informations de traitement capturéesdans le modèle ou le programme.

Dans le cadre d’un déploiement d’application, les informations relatives à laplate-formepeuvent, par exemple, être capturées dans un programme qui met en œuvre ce déploiement.L’outil de génération de code Ocarina [120] capture ainsi les informations relatives à l’inter-giciel PolyORB [95] (auquel se destine le code généré) au sein du code Ada de son généra-

2.2. Les représentations des plates-formes d’exécution 19

teur Gaia [119]. De même, les générateurs de code qui mettent à contributiondestemplates,tels que celui de Ptolemy II [69] ou l’outil RTW (Real-Time Workshop) [112] associé à Si-mulink [113], capturent généralement les informations relatives aux plates-formes dans lestemplatesqui structurent le code source à générer.

Dans la lignée de ces pratiques, la section suivante présente, page 24, un exemple dedescription de plate-forme d’exécution enfouie dans une transformation de modèles.

2.2.2 Représentations implicites

La seconde pratique identifiée consiste à décrire la plate-forme dans un métamo-dèle [18] [63] [107] [109]. Ce métamodèle prend généralement la forme d’un langage dédiéà la description d’applications destinées à une plate-forme. Nous parlons alors de descrip-tion implicite ou de plate-forme implicite, car les informations relatives à la plate-formesontcapturées dans un métamodèle dont les concepts concernent principalement l’application.Le langage que définit le métamodèle est implicitement lié à la plate-forme.

2.2.2.1 Approche UML

Dans une approche UML , la description implicite d’une plate-forme d’exécution peutprendre la forme d’une extension légère du métamodèle UML (un profil UML ). Les élémentsprofilés du métamodèle sont alors spécialisés par des stéréotypes.

La figure 2.1 est un exemple de profil UML dédié à la description d’applicationOSEK/VDX. Ce profil définit les stéréotypesTask, Alarm et Counterpermettant de décrirerespectivement des tâches, des alarmes et des compteurs OSEK/VDX.

Une tâche fournit un contexte pour l’exécution d’un traitement spécifié par l’utilisateursous la forme d’un point d’entrée. Une alarme permet de gérer des actions dans le temps(telle que l’activation d’une tâche). Elle se déclenche sur une valeur de référence fourniepar un compteur.

L’interface de programmation d’OSEK/VDX définit également un ensemble normaliséde services et de propriétés associés aux ressources de la plate-forme. Les propriétés spé-cifiées dans l’exemple de la figure 2.1 concernent par exemple : (a) l’unitéde temps d’uncompteur, en nombre de ticks (ticksperbase), (b) la taille de la pile et la priorité statiqued’une tâche (stacksizeet priority), et (c) la première expiration et le cycle d’une alarme(alarmtimeetcycletime).

FIG. 2.1:Un profil UML d’applications spécifiques à la plate-forme OSEK/VDX.

Les stéréotypes définis par ce profil étendent la métaclasseClassifierd’UML . Ils per-mettent ainsi de spécifier des classes de modèles UML .

Dans l’exemple de la figure 2.2, page suivante, le profil est appliqué à unmodèle decontrôleur de robot (RobotController). Certaines entités de l’application sont alors identi-fiées par le profil. La classeMotionControllerest par exemple stéréotypéeTask, une tâche


de la plate-forme OSEK/VDX est ainsi dédiée au contrôle de mouvements. Les attributs desstéréotypes sont également renseignés dans des notes attachées aux classes. L’attributprio-rity du stéréotypeTaskest ainsi renseigné dans le but d’accorder une priorité10 à la tâcheresponsable du contrôle du mouvement. De même, l’attributentrypointde ce même stéréo-type stipule que le point d’entrée de la tâche correspond à la méthodetrajectoryControlducontrôleur.

FIG. 2.2:Description UML d’une application spécifique à la plate-forme OSEK/VDX.

Dans la littérature actuelle, les profils UML dédiés à des plates-formes d’exécutionconcrètes, tant logicielles que matérielles, sont rarement utilisés. Les profils UML dispo-nibles pour des représentations implicites de plates-formes d’exécution s’apparentent prin-cipalement à des plates-formes abstraites [63] [109].

2.2.2.2 Approche DSML

Une approche alternative au profilage UML capture implicitement les informations re-latives à la plate-forme d’exécution dans un DSML. Le métamodèle du DSML est alorsimplanté conformément à un langage de méta-modélisation (tels que le MOF ou Ecore)dans le but de décrire des applications destinées à cette plate-forme.

La figure 2.3 est un exemple de DSML dédié à la description d’applications OSEK/VDX.Cet exemple définit les concepts de tâche, d’alarme et de compteur OSEK/VDX introduitsdans l’exemple précédent (figure 2.1). Il inclut de plus : (a) une communication par variableglobale (GlobalData), (b) un contexte pour l’exécution d’un traitement spécifié par l’utili-sateur sous la forme d’une routine (une routine ne représente qu’un bloc de code dans cetteexemple) et (c) la notion de type de donnée supporté par la plate-forme (PlatformType).

FIG. 2.3:Un métamodèle d’applications spécifiques à la plate-forme OSEK/VDX.


La réalisation d’un DSML s’accompagne généralement d’une syntaxe concrète pourl’expression des modèles. La figure 2.4 illustre dans une syntaxe graphique un modèleconforme au métamodèle que nous venons d’introduire. Ce modèle représente l’applica-tion de contrôleur de robot introduite dans l’exemple précédent (figure 2.2). La syntaxegraphique employée nous semble suffisamment simple pour ne pas être détaillée.

FIG. 2.4:Description avec un DSML d’une application spécifique à la plate-forme OSEK/VDX.

Dans la littérature actuelle, les langages OIL [92] et AADL [103] sont des exemples deDSML décrivant implicitement une plate-forme d’exécution logicielle. AADL a toutefois laparticularité de fournir des composants logiciels dont les sémantiques d’exécution sont pré-cisément définies, mais auxquels aucune plate-forme d’exécution concrète n’est associée.

2.2.3 Représentations explicites

La troisième et dernière pratique identifiée consiste à décrire la plate-forme dans un mo-dèle conforme à un métamodèle de plates-formes [22] [29] [94] [107] [114]. Nous parlonsalors de description explicite ou de plate-forme explicite, car un tel modèle estentièrementdédié à la représentation d’une plate-forme. Cette modélisation se destine à expliciter ulté-rieurement les relations entre les plates-formes et les applications qu’elles accueillent.

2.2.3.1 Approche UML

Dans une approche UML , la description explicite d’une plate-forme d’exécution peut seconformer à un profil UML dédié aux concepts des plates-formes d’exécution. Ces conceptssont alors identifiés par des stéréotypes.

La figure 2.5 est un exemple de profil UML dédié à la description de plates-formesd’exécution temps réel embarquées. Ce profil définit les stéréotypesSchedulableResource,AlarmResourceet TimerResourcepermettant d’identifier les ressources d’une plate-formedédiées respectivement aux contextes d’exécutions gérés par un ordonnanceur, aux alarmeset aux compteurs. Un stéréotype permet également d’identifier les points d’entrée des trai-tements associés aux ressources d’exécution (EntryPoint).

FIG. 2.5:Un profil UML de description de plates-formes d’exécution.


La figure 2.6 illustre l’utilisation de ce profil pour la modélisation des concepts de tâche,d’alarme et de compteur OSEK/VDX. Une tâche est par exemple identifiée comme uneressource ordonnançable (SchedulableResource), car son activation et son exécution sontgérées par un ordonnanceur. Les propriétés des ressources sont également identifiées enrenseignant les attributs du stéréotype. La propriété nomméepriority permet d’exprimer lapriorité d’une tâche. Cette propriété est référencée par l’attributpriorityElt du stéréotypeSchedulableResource.

FIG. 2.6:Description explicite d’une plate-forme OSEK/VDX avec un profil UML .

Dans un contexte UML , différentes technologies sont actuellement disponibles pour dé-crire explicitement des plates-formes d’exécution matérielles ou logicielles. Parmi celles-ci, PML (Platform Modeling Language) [107] se destine à la description de plates-formesd’exécution et de plates-formes d’analyse1. PML permet, entre autre, de modéliser les res-sources et les signatures des services qu’offre une plate-forme logicielle ainsi que leurscontraintes d’utilisation. Dans le même esprit, TUT-Profile (Tampere University of Techno-logy - UML Profile) [63], initialement prévu pour la modélisation d’applications temps réelembarquées et de plates-formes d’exécution matérielles, a été étendu pourla description deplates-formes logicielles [4]. Enfin, issu des travaux les plus récents, le profil UML -MARTE

(UML profile for Modeling and Analysis of Real Time and Enbedded systems) [89], stan-dardisé par l’OMG pour la modélisation et l’analyse de systèmes embarqués temps réel,identifie précisément les concepts relatifs aux plates-formes d’exécution matérielles et lo-gicielles. Au sein de ce profil, lepackageSRM (Software Resource Modeling) propose enparticulier des artefacts de modélisation des plates-formes logicielles. Pour cela, SRM spé-cialise, pour le domaine du temps réel et de l’embarqué, les concepts généraux de ressourceet de service dupackageGRM (Generic Resource Modeling). Ces concepts de ressource etservice étaient déjà présents dans le profil SPT de l’OMG (Schedulability, Performance andTime) [85], que UML -MARTE tend à supplanter.

2.2.3.2 Approche DSML

Une approche alternative aux profils UML consiste à décrire explicitement les plates-formes d’exécution avec des DSML. A l’instar des profils UML que nous venons de présen-ter, un tel DSML identifie les concepts du domaine, propres aux plates-formes d’exécution.

La figure 2.7, page ci-contre, est un exemple de langage dédié à la description deplates-formes d’exécution temps réel embarquées. Ce DSML définit les concepts introduitsdans l’exemple du profil UML précédent (SchedulableResource, AlarmResourceet Timer-Resource). Chacun de ces concepts hérite d’un concept abstrait de ressource, auquel unensemble de propriétés peut être attribué. Dans cet exemple, les propriétés des ressourcessont d’un type natif à la plate-forme (DataType).

1PML a été implanté sous la forme d’une extension lourde d’UML (PML -UML ) et intégré dans GME [53]


FIG. 2.7:Un DSML de description de plates-formes d’exécution.

L’exemple de la figure 2.8 illustre l’utilisation de ce DSML pour la modélisation desconcepts de tâche, d’alarme et de compteur OSEK/VDX. Le type entier (Integer, 32 bits)nécessaire au typage des propriétés est défini et lié aux propriétés (par une flèche en poin-tillé, suivant la convention graphique adoptée). La syntaxe graphique employée nous semblesuffisamment intuitive pour ne pas être plus détaillée.

FIG. 2.8:Description explicite d’une plate-forme OSEK/VDX avec un DSML.

Dans la littérature actuelle, peu de DSML de description de plates-forme d’exécutionlogicielles ont été identifiés. Les DSML offrant un support pour la description de plates-formes d’exécution concernent principalement la modélisation des supports matériels. Parexemple, le langage AADL , précédemment cité, fournit un ensemble de composants pourmodéliser à un haut niveau d’abstraction les processeurs, les bus de communication et lespériphériques impliqués dans un système temps réel. Ces composants offrent alors un sup-port pour la représentation explicite du support d’exécution matériel (contrairement auxcomposants logiciels du langage). Parmi les DSML qui offrent un support à la descriptionexplicite des plates-formes d’exécution, tant logicielles que matérielles, la méthodologiede conception Metropolis [94], basée sur les modèles de plates-formes (ou Platform BasedDesign[97]), propose au sein de son métamodèle des concepts d’activité concurrente et decommunication entre ces activités [75]. Cependant, la généricité de ces concepts ne permetpas d’identifier les composantes métiers des plates-formes dédiées à un domaine particu-lier [26]. Aucun aspect métier du domaine du temps réel et de l’embarqué n’est identifié.Plus axé sur ce domaine, le projet CoSMIC (Component Synthesis using Model IntegratedComputing) [50] offre un support pour la modélisation de supports d’exécution logicielsbasés sur le standard CCM (CORBA Component Model) [87] spécialisé pour les domainesde l’embarqué, du temps réel et de la qualité de service (QoS). Cette approche permet doncde décrire explicitement des intergiciels développés dans le respect du standard CORBA.Elle se prête ainsi à la modélisation explicite de certaines plates-formes d’exécution, maisne permet pas de modéliser les ressources et les services de systèmes d’exploitation. Enfin,si le projet Ptolemy propose au sein de son atelier Ptolemy II [69] un support pour la des-cription explicite de modèles d’exécution [70], les concepts de représentations structurellesdu support d’exécution se destinent uniquement à la modélisation des applications.


2.3 Les déploiements sur des plates-formes d’exécution

Parmi les utilisations prévues des descriptions de plates-formes d’exécution, cette étudese concentre sur leurs manipulations lors d’une phase de déploiement d’applications. Cettesection présente donc les considérations possibles des modèles de plates-formes d’exécu-tion et, d’une façon plus générale, des informations relatives aux plates-formes d’exécutiondurant cette phase.

A l’image des pratiques de description de plates-formes que nous venons de présenter,trois familles d’approches se distinguent pour la mise en œuvre (ou déploiement) d’uneapplication sur une plate-forme (figure 2.9)2.

La première approche génère un modèle de l’application, via une technologie dans la-quelle les informations relatives à la plate-forme sont enfouies. La seconde approche s’ap-puie sur une description implicite de la plate-forme dans un métamodèle. Les applicationsdevant s’exécuter sur cette plate-forme sont alors transformées conformément à ce méta-modèle. La troisième approche s’appuie sur une description explicite de la plate-forme,conforme à un métamodèle de plate-forme d’exécution. Le modèle d’une application et lemodèle de la plate-forme peuvent alors être mis en relation par des associations. Ils peuventégalement être transformés pour générer un modèle de l’application.

FIG. 2.9:Trois approches de déploiement d’une application sur une plate-forme.

Nous proposons d’illustrer ces approches en nous appuyant sur lesdescriptions de laplate-forme OSEK/VDX de la section précédente. Pour chacune, nous détaillons le principede déploiement d’une application et donnons un exemple de transformation.Les mises enœuvre illustrées concernent des générations de modèles. L’utilisation detemplatespour lagénération de code source sera évoquée, mais ne sera pas illustrée.

2.3.1 Plate-forme enfouie dans la technologie de déploiement

La première approche consiste à générer un modèle de l’application (ou directement lecode source de l’application), via une technologie dans laquelle les informations relatives àla plate-forme sont enfouies.

2Les angles grisés de la figure 2.9 représentent des alternatives de mise en œuvre.

2.3. Les déploiements sur des plates-formes d’exécution 25

La figure 2.10 illustre la transformation d’un modèle d’application de robotiqueen unmodèle de code dédié à la plate-forme OSEK/VDX3. La transformation développée génèreun modèle de code C (conforme à un métamodèle du langage C). Le passage au code sourcese concrétise, dans une seconde étape, par un extracteur (transformation modèle vers texte)dans l’espace de codage.

La transformation de l’exemple (implantée en ATL) se contente de générer un appelà une fonction de déclaration de tâche pour chaque activité de contrôle oud’affichage dumodèle d’entrée. Le nom d’une tâche, passé en paramètre de l’appel, correspond au nom del’activité qui lui correspond.

FIG. 2.10:Plate-forme enfouie dans une transformation.

Dans cette approche, les informations relatives à la plate-forme cible sont capturéesdans la transformation (cf. figure 2.10, la référence à la fonctionDeclareTaskde l’API

d’OSEK/VDX, dans le code ATL). La plate-forme est ainsi enfouie dans la transformation.Le modèle dans lequel les concepts de la plate-forme sont introduits n’est pas conforme àun métamodèle de plate-forme d’exécution, ni à un méta-métamodèle, mais conformeaumétamodèle d’un langage de transformation.

Remarque : L’utilisation d’untemplatede génération de code suit le même principe. Lesinformations relatives à la plate-forme et au langage de programmation sont alors capturéesdans letemplate[69] [112].

3Les syntaxes concrètes de l’exemple ne sont pas détaillées. Les métamodèles sont exprimés avec des di-grammes de classes. Le modèle de l’application générée utilise une syntaxe similaire à celles des éditeursarborescents de modèles (tel que celui d’EMF).


2.3.2 Déploiement sur une plate-forme implicitement décrite

2.3.2.1 Contexte UML

Dans un contexte UML , le déploiement d’une application sur une plate-forme d’exécu-tion consiste à stéréotyper les éléments du modèle de l’application, telles que les classes etles relations, avec les concepts qu’identifie le profil associé à la plate-forme. L’exemple dela figure 2.11 illustre le résultat de cette opération4.

FIG. 2.11:Déploiement d’une application sur une plate-forme OSEK/VDX (UML ).

L’automatisation d’un tel déploiement est envisageable à partir d’un modèle d’applica-tion dont les éléments sont stéréotypés pour le domaine de l’application. Dansl’exemplede la figure 2.11, si la classeMotionControlleravait été identifiée par un stéréotype« Ac-tivity » (défini dans un profil dédié aux applications de robotique), le marquagede cetteclasse avec le stéréotype« Task », dans le modèle de l’application déployée, aurait pu êtredéduit à partir de règles de correspondance. Une telle règle aurait alors exprimé que touteclasse identifiée comme une activité se concrétise par une tâche sur la plate-forme.

Les règles de correspondance se matérialisent généralement sous la forme de règles detransformation, à l’image de celles que nous présentons dans la suite de cettesection.

2.3.2.2 Contexte DSML

Dans un contexte DSML, le déploiement automatique d’une application sur une plate-forme d’exécution consiste à transformer un modèle de l’application (indépendant de laplate-forme) en un modèle conforme au métamodèle dans lequel la plate-forme est implici-tement décrite.

Ce type de métamodèle peut se destiner à différents usages. Nous présentons dans cettepartie trois cas différents. Le premier illustre l’utilisation d’une description implicite deplate-forme dans un métamodèle de langage de programmation. Le second s’appuie sur lemétamodèle d’applications OSEK/VDX introduit dans la section précédente. Le troisièmeenrichit le processus de déploiement d’un métamodèle pivot.

Utilisation d’un métamodèle de langage de programmation

Les informations relatives à une plate-forme d’exécution peuvent être capturées dans unmétamodèle de langage de programmation. Cette pratique consiste à étendre le métamodèled’un langage pour y intégrer l’API de la plate-forme (ce qui revient à considérer l’interfacede programmation de la plate-forme dans une librairie du langage). La plate-forme est alorsimplicitement décrite dans le métamodèle du langage.

4La figure 2.11 reprend l’exemple de la figure 2.2, page 20


La figure 2.12 illustre le métamodèle du langage C et la transformation de modèles del’exemple précédent (figure 2.10, page 25) ainsi modifiés.

FIG. 2.12:Plate-forme implicitement décrite dans un métamodèle de langage de programmation.

Cette approche extrait de la transformation de l’exemple de la figure 2.10 les conceptspropres à la plate-forme. Elle permet d’identifier individuellement les ressources et les ap-pels aux services de la plate-forme dans les modèles générés. Le code dela transformationse trouve également légèrement réduit.

Utilisation d’un métamodèle d’application spécifique à une plate-forme

Dans un contexte DSML, une plate-forme d’exécution peut être implicitement décritedans un métamodèle d’application indépendant de tout langage de programmation.

La figure 2.13 illustre un déploiement d’application sur une plate-forme OSEK/VDX

ainsi décrite dans un DSML. L’application se compose de deux activités périodiques, l’unepour le contrôle et l’autre pour l’affichage. L’activité de contrôle communique à l’activitéd’affichage une donnée de type entier.

Le déploiement de l’application répartit ces deux activités entre deux tâches. Le modèlede l’application est alors transformé en un modèle conforme au métamodèle d’applicationOSEK/VDX introduit précédemment (figure 2.3, page 20). L’application résultante secom-pose de deux tâches OSEK/VDX périodiquement activées par des alarmes. Ces alarmes sedéclenchent sur des valeurs de référence fournies par un même compteur. La communica-tion entre les tâches est assurée par écriture et lecture dans une variable globale5.

FIG. 2.13:Déploiement d’une application sur une plate-forme OSEK/VDX implicitement décrite.

5La concordance des sémantiques d’exécution attendues pour les deuxmodèles est supposée vérifiée pourles besoins de l’application.


Des règles de transformations établissent les correspondances entre les éléments dumodèle source et ceux du modèle cible. Le code ATL extrait de la transformation RO-BOT2OSEK/VDX (listing 2.1) décrit certaines correspondances appliquées dans l’exemplede la figure 2.13.

-- Create a task, a routine and an alarm from a periodic activityrule PeriodicActivity2PeriodicTask {

fromactivity : ROBOT!Activity ( activity.isPeriodic() )

totask : OSEKVDX!Task (

name <- activity.name,priority <- activity.getPriority(),stacksize <- activity.getStackSize(),entrypoint <- routine

),routine : OSEKVDX!Routine (

name <- activity.getEntryPoint().getName(),code <- activity.getEntryPoint().getCode()

),alarm : OSEKVDX!Alarm (

name <- activity.name + ’Alarm’,alarmtime <- 1,cycletime <- activity.getPeriod(),counter <- thisModule.CreateOneCounter(),activate <- task

)}

-- Create a counter for all alarmsunique lazy rule CreateOneCounter {

fromactivity : ROBOT!Activity ( activity.isPeriodic() )

tocounter : OSEKVDX!Counter (

name <- ’SysCounter’,ticksperbase <- 1

)}

Listing 2.1:Extrait de la transformation ROBOT2OSEK/VDX (en ATL)

La règlePeriodicActivity2PeriodicTaskdu listing 2.1 stipule que toute instance d’acti-vité périodique du modèle source est transformée en :

– une tâche OSEK/VDX,– une routine (qui constitue le point d’entrée de la tâche) et– une alarme (dont l’action consiste à activer périodiquement la tâche).

Un compteur unique pour toutes les alarmes est également créé par un appel à une règleimpérative (CreateOneCounter). Ce type de règle (unique lazy) permet de créer un élémentau premier appel et d’en retourner la référence aux appels suivants[6].

Les valeurs des propriétés de chaque tâche, de chaque routine et de chaque alarme sontrenvoyées par des fonctions (ouhelpers, en ATL), telle quegetPriority() pour la valeur depriorité d’une tâche. Nous ne détaillerons pas les implantations possibles de ces fonctionsqui peuvent, par exemple, déduire leurs valeurs de retour par calcul (à partir de donnéesdisponibles dans le modèle source) ou retransmettre des valeurs passéesen paramètre de latransformation (valeurs issues, par exemple, d’un outil externe d’analyse d’ordonnançabi-lité [24] [101]).


Introduction d’un métamodèle pivot

Principe

L’utilisation d’une description implicite de plate-forme d’exécution peut être affinée parla considération d’un métamodèle décrivant les concepts et les services offerts par la plupartdes plates-formes d’exécution d’un domaine particulier [33] [63] [109]. Ce type de méta-modèle s’apparente à une description de plate-forme abstraite. Son intérêtréside dans sacapacité à cibler de multiples plates-formes concrètes susceptibles d’exécuter une applica-tion. La plate-forme abstraite joue alors le rôle de pivot entre des descriptions indépendantesde toute plate-forme et leurs mises en œuvre sur des plates-formes concrètes.

La figure 2.14 illustre l’introduction, dans un processus de transformation, d’un méta-modèle pivot de plate-forme d’exécution. Le déploiement de l’application sescinde alorsen deux étapes. Une première transformation (X2Pivot) spécifie l’application avec lestechnologies qui permettent son exécution. Une seconde transformation (par exemple Pi-vot2OSEK/VDX ou Pivot2ARINC-653) déploie ensuite l’application sur une plate-formeconcrète qui implante les technologies nécessaires à son exécution.

FIG. 2.14:Introduction d’un métamodèle pivot de plate-forme d’exécution.

Cette approche offre un potentiel de capitalisation des transformations de part et d’autredu pivot. Pour un même métamodèle source, la transformation de la première étape estcommune à toutes les plates-formes concrètes envisageables. Parallèlement,quelque soitle métamodèle source, une transformation de la seconde étape est commune à tous les dé-ploiements sur la plate-forme cible. Un changement de technologie, de modélisation oud’exécution, ne nécessite la refonte que d’une partie du processus dedéploiement.

Métamodèle pivot

Un métamodèle pivot se doit d’offrir une abstraction des concepts métiers que four-nissent les plates-formes d’exécution envisagées. Ces concepts s’apparentent à ceux qu’ilest nécessaire d’identifier pour la conception d’un métamodèle de plate-forme d’exécution(cf. Représentation explicite d’une plate-forme d’exécution, page 21).

La figure 2.15, page suivante, est un exemple de métamodèle pivot. Ce pivot définitune application comme étant composée d’entités. La notion d’entité ordonnançable (Sche-dulableEntity) représente un contexte pour l’exécution d’un traitement (spécifié par uneroutine dans cet exemple). L’activation d’une entité ordonnançable peut être périodique,apériodique ou sporadique. La notion deSharedDataComEntitydéfinit un média de com-munication par variable partagée. Dans cet exemple, les services de lecture et d’écritured’une variable partagée sont accessibles depuis une ressource ordonnançable.


FIG. 2.15:Extrait d’un métamodèle pivot.

Déploiement via un pivot

Le déploiement via un pivot consiste à déployer l’application sur la plate-forme pivotdans une première étape. Le modèle résultant est ensuite transformé selondes règles decorrespondances entre les concepts du pivot et ceux de la plate-forme concrète ciblée. Lafigure 2.16 détaille l’introduction du pivot que nous venons de définir (figure 2.15), dans leprocessus de déploiement d’une application de robotique sur une plate-forme OSEK/VDX

(exemple de la figure 2.13, page 27).

FIG. 2.16:Déploiement d’une application sur une plate-forme OSEK/VDX via un pivot.

La première étape de déploiement traduit les activités de contrôle et d’affichage en en-tités ordonnançables périodiques, et la connexion via des ports de données en une commu-nication par variable partagée. La seconde étape crée les mécanismes de mise en œuvre deces concepts sur la plate-forme OSEK/VDX. La variable de communication se concrétisepar une variable globale et les ressources ordonnançables périodiques par des tâches dontles activations sont régies par des alarmes.

2.3.3 Déploiement sur une plate-forme explicitement décrite

La dernière pratique identifiée consiste à déployer une application sur uneplate-formeexplicitement décrite. Cette pratique peut suivre quatre approches en fonction des relationsentre les métamodèles de l’application (PIM ), de la plate-forme d’exécution (PDM) et del’application spécifique à la plate-forme (PSM) (figure 2.17, page suivante).

La première approche concerne les technologies qui fournissent un même métamo-dèle pour décrire la plate-forme et l’application. Ces technologies offrent généralement desconcepts de mise en relation des éléments de l’application avec ceux de la plate-forme. Lemodèle de l’application déployée correspond alors à l’union des modèles del’application etde la plate-forme, enrichi des relations entre leurs éléments.


Les approches suivantes concernent les déploiements à partir de métamodèles différentspour l’application et la plate-forme d’exécution. La considération explicite d’une plate-forme se décline alors en trois approches qui aboutissent à trois types dePSM.

Le premier type de PSM est conforme à un métamodèle généré à partir du modèle dela plate-forme d’exécution. Cette approche, hybride entre les descriptions explicites et im-plicites d’une plate-forme, consiste à promouvoir le modèle de la plate-forme enun mé-tamodèle. Le métamodèle résultant offre alors les concepts nécessaires à lamodélisationd’applications spécifiques à la plate-forme6.

Le second type de PSM est conforme à un métamodèle différent et indépendant desmétamodèles sources utilisés pour décrire l’application et la plate-forme d’exécution. Cemétamodèle peut couvrir différents domaines (programmation, analyse, etc.).

Enfin, le troisième type de PSM est conforme au métamodèle de plate-forme d’exé-cution. L’idée sous-jacente est de considérer la plate-forme d’exécution « enrichie » d’uneapplication s’exécutant sur la plate-forme. L’enrichissement auquel nous faisons référencecorrespond à une instanciation des ressources de la plate-forme pour les besoins d’une ap-plication. Le PSM représente alors la plate-forme d’exécution et l’utilisation qui est faite deses ressources pour l’exécution des traitements spécifiés par une application.

FIG. 2.17:Quatre approches de déploiement d’une application sur une plate-forme explicitement décrite.

La suite de cette section détaille la mise en œuvre de chacune de ces approches.

2.3.3.1 Contexte UML

Dans un contexte UML le déploiement d’une application sur une plate-forme explici-tement décrite relève de la première approche. Les modèles se conformenttous à UML

(enrichi dans notre cas par des profils). Deux principes de déploiement se distinguent toute-fois dans ce contexte. Le premier, que nous qualifierons d’«allocation», consiste à mettreen relation les concepts applicatif avec ceux de l’exécutif. Le second, que nous qualifieronsd’« instanciation», consiste à instancier, dans un premier temps, les ressources de la plate-

6Le principe d’une promotion de modèle sera détaillé dans la suite de cette section.


forme pour les besoins de l’application, et à associer, dans un second temps, les instancesde ressources de la plate-forme aux instances des éléments de l’application.

Le principe d’allocation est principalement utilisé pour mettre en relation le logicielet le matériel. La notion de déploiement (deployment) définie dans le standard UML [90]permet, par exemple, d’exprimer la répartition spatiale du logiciel sur le matériel.

Certains profils UML raffinent néanmoins des concepts d’association entre desclassi-fierset desinstance classifiersUML (comme par exemple des classes ou des composants)pour identifier des relations de déploiement qui concernent également lesplates-formeslogicielles. TUT-Profile définit, par exemple dans ce but, le conceptPlatformMapping[62]qu’il étend à la notion de déploiement sur un support d’exécution logiciel. UML -MARTE dé-finit également, dans lepackageAlloc (Allocation Modeling) [89], le concept d’allocation(allocate) spatiale ou temporelle des fonctionnalités d’une application sur les ressources dusupport d’exécution.

Le principe alternatif d’instanciationmodélise explicitement les entités du supportd’exécution mises à contribution lors de l’exécution de l’application. Ces entités sont alorsagencées (ou mises en relation) avec les entités du modèle logique de l’application. Nousnous focalisons, dans cette partie, sur ce principe d’instanciation des ressources d’une plate-forme.

La figure 2.18 illustre ce principe pour le déploiement, sur une plate-forme OSEK/VDX,de l’application de robotique introduite précédemment. L’application est modélisée en UML

dans lepackageRobotController. Le modèle de l’application déployée sur la plate-forme(OSEK/VDX Application) importe alors la description de la plate-forme7. Deux tâches (t1et t2) responsables de l’exécution des activités de contrôle et d’affichagede l’application(Controller et Monitor) sont instanciées. Les propriétés de chacune des tâches ainsi queleurs points d’entrée sont renseignés dans le modèle. Deux instances d’alarme (a1 et a2)ainsi qu’une instance de compteur (c0) sont également crées pour la mise en œuvre desactivations périodiques des tâches.

FIG. 2.18:Déploiement d’une application sur une plate-forme OSEK/VDX décrite avec un profil UML .

7La modèle de la plate-forme OSEK/VDX de l’exemple reprend le modèle introduit dans la section précé-dente (figure 2.6, page 22).


Automatisation d’un déploiement

A l’image d’un déploiement d’application sur une plate-forme implicitement décrite,l’automatisation du déploiement que nous venons de présenter est envisageable. L’identifi-cation par stéréotypage des éléments du modèle source de l’application offre, par exemple,un support à cette automatisation. Dans le modèle de la figure 2.18, les instances des res-sources de la plate-forme OSEK/VDX pourraient ainsi être générées par des règles de trans-formations. Ces règles exprimeraient, dans ce cas, les correspondances entre les conceptsde l’applicatif (identifiés par les stéréotypes utilisés dans le modèle de l’application) et lesconcepts de la plate-forme d’exécution.

La figure 2.19 illustre la mise en œuvre de cette approche. Pour cela, le modèle del’application de robotique introduit précédemment est stéréotypé à l’aide d’un profil UML

dédié à son domaine d’application. Le pseudo code ATL de la figure 2.19 donne le principed’une transformation de déploiement associée. Dans cet exemple, une instance de ressourceordonnançable activée périodiquement par une alarme est générée pour toute instance d’élé-ment identifié comme une activité dans le modèle source.

FIG. 2.19:Principe d’une transformation de déploiement sur une plate-forme décrite avec un profil UML .

Remarque : Aucune mention ou implantation d’une telle transformation n’ont été iden-tifiées dans les outils actuellement disponibles ou publiée avec des profils UML existants.

Automatisation d’un portage

Une autre approche, proposée lors de travaux qui ont précédés cette étude [114], consisteà automatiser une partie du portage d’une application, d’une plate-forme à une autre. Leportage à pour principe de s’appuyer sur un déploiement existant pourgénérer un modèlede l’application déployée sur une autre plate-forme d’exécution.

L’algorithme 2.1, page suivante, est une version simplifiée de transformation génériqueissue de ces travaux (la transformation est qualifiée de « transformation deportage »). Sonprincipe consiste à reproduire un déploiement existant en faisant une analogie entre lesressources offertes par les différentes plates-formes, via leurs stéréotypes.

Dans cette version simplifiée, pour chaque instance du modèle dont le type8 est stéréo-typé dans la plate-forme source (la plate-forme sur laquelle l’application estdéjà déployée),s’il existe une ressource stéréotypée de la même façon dans la plate-formecible (la nou-velle plate-forme considérée), cette ressource est instanciée. Le nom de l’instance « cible »

8Les types auxquels nous faisons référence dans l’algorithme correspondent à des ressources de la plate-forme.


(l’instance générée) correspond alors, dans cette version, au nom de l’instance « source ».Enfin, les valeurs des propriétés de l’instance source sont traduites etrenseignées dans lespropriétés de l’instance générée.

Algorithme 2.1 :Principe d’un portage générique (basé sur le profilage UML ) [115]

Entrée :Is : l’ensemble des instances d’un modèle d’application déployée sur une plate-formePs

Ms : le modèle de la plate-formePs

Mc : le modèle de la plate-formePc

Sp : l’ensemble des stéréotypes du profil UML

Résultat :It : l’ensemble des instances d’un modèle de l’application déployée sur une plate-formePc

Notations :type(i) : la classe du modèle de la plate-forme qui type l’instanceiχ(c) : le stéréotype auquel se conforme la classecprop(s) : l’ensemble des propriétés du stéréotypesprop(c) : l’ensemble des propriétés de la classec

débutpour chaqueis ∈ Is tel queχ(type(is)) ∈ Sp faire

si ∃ classec ∈Mc tel queχ(c) = χ(type(is)) alorsCréeric une instance de la classecnom deic← nom deisdépendances deic← dépendances deispour chaquepropriétép ∈ prop(type(is)) tel queχ(type(is)) référencepfaire

si ∃ propriétép′ ∈ prop(χ(c)) tel quep′ = p alorsvaleurp′← conversion de la valeur dep pourPc

fin

Cette version de l’algorithme, ici présentée, se limite à des correspondances 1-1 et n’as-sure pas la cohérence des valeurs des propriétés. Précisons qu’une version améliorée estdisponible et implantée pour le profil UML -MARTE [114].

2.3.3.2 Contexte DSML

Dans un contexte DSML, les modèles de l’application et de la plate-forme d’exécutionne sont pas forcément conformes à un même métamodèle. Comme cela a été mentionnéen introduction de cette section, les pratiques de déploiement sont donc conditionnées parles relations entre les métamodèles de l’application (PIM ), de la plate-forme d’exécution(PDM) et de l’application spécifique à la plate-forme (PSM).

Mise en relation des éléments d’un système

A l’image de ce que nous venons de présenter dans un contexte UML , une première pra-tique de déploiement concerne les technologies qui fournissent un même métamodèle pourdécrire l’application et la plate-forme d’exécution (approche 1 de la figure 2.17, page 31).Ces technologies offrent généralement des concepts de mise en relation des éléments del’application et de la plate-forme d’exécution.

Selon ce principe le métamodèle de plate-forme d’exécution introduit dans la sectionprécédente (figure 2.7, page 23) peut prendre la forme de celui de la figure 2.20, page ci-contre. Ce métamodèle fournit alors, en plus des concepts d’une plate-forme d’exécution,


ceux d’une application de robotique (dans la lignée des exemples précédents) et un conceptde mise en relation des éléments applicatifs et des éléments exécutifs (Mapping).

FIG. 2.20:Un DSML de description de système (application + plates-formes d’exécution).

A l’image de ce qui se pratique dans un contexte UML , cette approche se retrouve prin-cipalement dans les technologies de modélisation conjointe des applications et des supportsd’exécution matériels. Les déploiements décrivent alors la répartition spatiale du logicielsur le matériel. Par exemple, AADL fournit des mécanismes de mise en relation des com-posants logiciels et matériels [103]. Il est ainsi possible de déclarer les déploiements auto-risés (Allowed Binding) ou imposés (Actual Binding) du logiciel sur le matériel. Metropolisintègre également dans son métamodèle un concept de déploiement de l’applicatif sur lesupport d’exécution (Mapping) [75]. Ce concept met en relation les services que requièreun composant applicatif avec ceux que fournit un composant exécutif. Dans cette approche,le composant du support d’exécution peut être matériel ou logiciel.

L’utilisation de relations internes à un métamodèle pour déployer une applicationrestecependant cloisonnée dans une technologie. Aucune intégration de modèles d’applicationsconformes à d’autres métamodèles n’est généralement possible.

Promotion du modèle de la plate-forme

L’utilisation de technologies ne permettant pas de décrire conjointement l’application etle support d’exécution nécessite de mettre en œuvre des déploiements baséssur des méta-modèles différents pour l’application et la plate-forme d’exécution. Comme cela a été men-tionné en introduction de cette partie, la considération explicite d’une plate-forme d’exécu-tion se décline alors en trois approches de déploiement (approche 2, 3 et4 de la figure 2.17,page 31). A chacune de ces approches correspond alors un type demodèle d’applicationspécifique à une plate-forme d’exécution (ou PSM).

Le premier type de PSM, auquel nous nous intéressons dans cette partie, est conformeà un métamodèle généré à partir de la description explicite de la plate-forme d’exécution(approche 2 de la figure 2.17, page 31). Cette approche est une approche hybride qui metà contribution des descriptions explicites et implicites de plates-formes d’exécution. Elleconsiste à promouvoir le modèle de la plate-forme en un métamodèle. Le métamodèle ré-sultant offre alors les concepts nécessaires à la modélisation d’applications spécifiques àcette plate-forme d’exécution.

Deux transformations sont impliquées dans cette approche. La première génère le méta-modèle du PSM à partir d’une description explicite de la plate-forme d’exécution (transfor-mation qualifiée de « promotion »). La seconde se charge du déploiement desapplicationssur la plate-forme. Cette dernière transformation s’appuie sur le métamodèle issu de la pre-mière transformation et celui de l’application.


La figure 2.21 illustre le principe d’une promotion de modèle de plate-forme d’exécu-tion. Cet exemple reprend le métamodèle de plate-forme d’exécution et le modèlede laplate-forme OSEK/VDX des exemples précédents (figure 2.7 et 2.8, page 23). Un extraitsimplifié de méta-métamodèle est également introduit sous le nom deMMM.

FIG. 2.21:Promotion d’un modèle de la plate-forme OSEK/VDX en un métamodèle d’application.

Les règles du listing 2.2 issues de la transformationPlatform2Meta, illustrent la miseen œuvre d’une promotion. Dans cet extrait, tout élément du modèle sourceconforme à uneressource est transformé en une (méta)classe (lignes 2 à 13). Cette (méta)classe est munied’un attribut de nommage (lignes 9 à 12) et d’un attribut pour chacune despropriétés del’élément source (lignes 15 à 22). Le code complet de la transformationPlatform2Metadel’exemple est donné en annexe (page 163).

1 -- Create meta-class from resource concept2 rule Resource2Class {3 from resource : Platform!Resource4 to5 class : MMM!Class (6 name <- resource.name,7 attributes <- Sequence{ name, resource.properties }8 ),9 name : MMM!Attribute (

10 name <- ’name’,11 type <- #String12 )13 }14 -- Create attribute of meta-class from property of resource15 rule Property2Attribute {16 from property : Platform!Property17 to18 attribute : MMM!Attribute (19 name <- property.name,20 type <- property.getType()21 )22 }

Listing 2.2:Extrait de la transformation de promotionPlatform2Meta(en ATL)


Le métamodèle généré par cette transformation est similaire à celui d’une descriptionimplicite de plate-forme d’exécution (figure 2.3, page 20). Les transformations de déploie-ment associées à cette approche sont donc identiques à celles de la sous-section précédente(cf. Utilisation d’un métamodèle d’application spécifique à une plate-forme, page 27).

Cependant, les concepts qu’identifient les métamodèles de PSM, ainsi générés, sont tousliés au métamodèle de plate-forme d’exécution. Ces concepts sont en effetissus de modèlesconformes au métamodèle de plate-forme d’exécution. Les liens entre les concepts de dif-férents métamodèles générés et les concepts du métamodèle de plates-formespeuvent doncêtre exploités pour automatiser le portage d’applications (à l’image du portagegénériqueprésenté précédemment dans un contexte UML , page 34). L’automatisation d’un tel portageprend ici la forme d’une génération de transformations (figure 2.22).

FIG. 2.22:Principe d’une génération de transformation de portage.

L’algorithme simplifié 2.2 donne les grands principes d’une telle génération. Apartir dedeux modèles de plates-formes d’exécution, cet algorithme identifie les éléments conformesà un même concept. Il génère ensuite les règles de correspondance entre les classes quirésultent de la promotion de ces éléments.

Algorithme 2.2 :Principe d’une génération de transformation de portage

Entrée :MMp : un métamodèle de plate-forme d’exécution (ressources/propriétés)Ms : le modèle de la plate-formePs

Mc : le modèle de la plate-formePc

La transformation de promotion d’un modèle en un métamodèleest supposée connue.

Résultat :Ts2c : l’ensemble des règles de transformation d’un portage dePs versPc

Notations :promo(c) : la (méta)classe issu de la promotion de la classecprop(c) : l’ensemble des propriétés que renseigne la classecχ : la relation de conformité

débutpour chaqueressourcer ∈MMp faire

si ∃ classecs ∈Ms tel quecsχr ∧ ∃ classecc ∈Mc tel queccχr alorsCréer la règleRcs2cc de correspondance entrepromo(cs) etpromo(cc)pour chaquepropriétép ∈ prop(cs) faire

si p ∈ prop(cc) alorsCréer, dansRcs2cc, la traduction :p dans promo(cc)← p dans promo(cs)

fin


Cette version de l’algorithme se limite à la génération de règles de correspondance 1-1 et n’assure pas la cohérence des valeurs des propriétés au sein des règles. Comme celasera évoqué dans la suite de ce manuscrit, des versions améliorées de cetalgorithme ont étédéveloppées et implantées lors de cette étude.

Aucune autre mise en œuvre de cette approche n’a été identifiée dans les travaux quenous avons recensés. L’atelier GME propose néanmoins une approche en quelques pointssimilaires [53]. Cette approche est, d’une part, hybride : la modélisation desplates-formesd’exécution peut être implicite ou explicite. Pour cela, des transformations demodèles,en GReaT (Graph Rewriting and Transformation) [54], sont disponibles pour passer d’unmétamodèle à un modèle conforme à PML 9 [107]. L’outillage associé à PML et intégré dansGME permet, d’autre part, de générer automatiquement une partie des règles deportaged’une application. Cette génération s’appuie sur un concept fourni par PML pour exprimerdes règles de transformation entre les composants de différentes plates-formes. L’expressionde ces règles et la modélisation des plates-formes ne sont pas clairement séparées danscette approche. Les descriptions des règles de transformation se confondent avec celles desressources et des services des plates-formes d’exécution.

Déploiement vers un métamodèle tierce

Dans ce même contexte de considération explicite d’une plate-forme d’exécution, ladeuxième approche identifiée implique un PSM conforme à un métamodèle différent etindépendant des métamodèles de l’application et de la plate-forme d’exécution (approche 3de la figure 2.17, page 31). Ce métamodèle est alors porteur de concepts métiers propres àl’utilisation prévue du modèle de l’application déployée.

Cette approche peut, en particulier, s’appliquer à la génération d’un modèle de codesource conforme à un métamodèle de langage de programmation. Le modèle généré s’appa-rente alors à ceux des approches présentées précédemment, qui concernent les descriptionsde plates-formes enfouies dans une transformation (page 24) ou les descriptions implicitesdans un métamodèle de langage de programmation (page 26).

La figure 2.23, page suivante, illustre la transformation d’un modèle d’application derobotique en un modèle de code dédié à la plate-forme OSEK/VDX (exemple introduit dansla figure 2.10, page 25). La transformation de l’exemple se contente de générer : (a) un appelà une fonction de déclaration de tâche, pour chaque activité de contrôle ou d’affichage dumodèle d’entrée, et (b) un appel à une fonction de déclaration d’alarme,pour les activationspériodiques des tâches.

Remarque : Les métamodèles de plate-forme des exemples précédents fournissaient leconcept depropriétéd’une ressource. Celui de cet exemple n’identifie plus ce concept, maisfournit celui deserviceoffert par une ressource. Ces différents métamodèles sont donnésà titre indicatif. Un métamodèle plus complet, comme nous l’aborderons dans la suitedece rapport, se doit d’identifier les deux concepts, en réponse à la caractérisation des plates-formes d’exécution que nous avons présentées en première partie de cechapitre.

La transformation de déploiement de l’exemple (Robot & PDM to C) établit la corres-pondance entre les éléments des modèles sources (PIM et PDM) et les éléments du modèlecible (PSM). La règlePeriodicActivity2PeriodicSchedulableResourcedu listing 2.3, pageci-contre, stipule, par exemple, que toute activité périodique est transformée en un appelà une fonction de déclaration de tâche et un appel à une fonction de déclaration d’alarme(lignes 7 et 16). Le nom de l’activité est passé en paramètre du premier appel (ligne 13).Ce même nom, concaténé au terme « Alarm », est passé en paramètre du second (ligne 22).

9Dans GME, l’implantation de PML par une extension lourde d’UML (UML -PML ) s’apparente ici à uneapproche DSML, en opposition à l’approche par profil UML .


Pour des raisons didactiques, la transformation du listing 2.3 ne comporte pastout le codeATL. Certaines parties ont été volontairement omises.

FIG. 2.23:Génération d’un modèle de code spécifique à une plate-forme OSEK/VDX décrite avec un DSML.

Remarque : Le principe de cette approche peut être appliqué à l’utilisation d’un templatede génération de code. Les modèles de l’application et de la plate-forme sont alors transmiscomme paramètres dutemplate.

1 -- Create declare functions of schedulable resource and alarm2 -- from a periodic activity3 rule PeriodicActivity2PeriodicSchedulableResource {4 from5 activity : ROBOT!Activity ( activity.isPeriodic() )6 to7 schedres : C!APIFunctionCall (8 name <- Platform!SchedulableResource9 .getDeclareService(),

10 parameters <- Sequence{ shedresparam }11 ),12 shedresparam : C!APISlot (13 name <- activity.name14 ),1516 alarm : C!APIFunctionCall (17 name <- Platform!AlarmResource18 .getDeclareService(),19 parameters <- Sequence{ alarmparam }20 ),21 alarmparam : C!APISlot (22 name <- activity.name + ’Alarm’23 )24 }

Listing 2.3:Extrait de la transformationRobot & PDM to C(en ATL)


Bien que la transformation présentée soit très liée à la plate-forme OSEK/VDX dans lamise en œuvre qu’elle propose10, seuls les concepts du métamodèle de plate-forme sontnécessaires à l’expression de ses règles. Cette caractéristique offredes perspectives de gé-néricité vis-à-vis des plates-formes qu’il conviendrait de préciser. Cependant, actuellement,aucune étude identifiée ne concrétise de telles transformations.

Intégration d’une application dans la plate-forme

Le dernier type de PSM, auquel nous nous intéressons dans cette partie, est conforme aumétamodèle de plate-forme d’exécution (approche 4 de la figure 2.17, page31).

Ce principe consiste à introduire dans le métamodèle de plate-forme d’exécution, nonpas les concepts métiers de l’applicatif, comme le proposent les approches de modélisa-tions conjointes de l’applicatif et de l’exécutif, mais un mécanisme générique d’intégrationd’applications sur les plates-formes d’exécution.

La figure 2.24 illustre l’insertion d’un tel mécanisme dans le métamodèle de plate-forme d’exécution introduit précédement (figure 2.7, page 23). Ce mécanisme repose surun principe d’instanciation des ressources de la plate-forme, en vue d’exécuter l’applica-tion. L’application s’intègre alors via des instances de ressource (ResourceInstance) misesà contribution pour son exécution11.

Dans l’exemple proposé (figure 2.24), les instances de ressource peuvent être mises enrelation (relatedTo). Les propriétés des ressources qui les typent sont de plus renseignéespour chacune d’elles. Les instances possèdent ainsi des propriétés(InstanceProperty) dontl’attribut valuedonne la valeur (ce DSML se contente d’une valeur littérale exprimée dansune chaîne de caractère).

FIG. 2.24:Un DSML de description de plate-forme pouvant intégrer des applications.

La figure 2.25, page suivante, reprend l’exemple précédent d’application de robotiquedéployée sur une plate-forme OSEK/VDX. La plate-forme d’exécution OSEK/VDX est iciexplicitement modélisée avec le DSML (le modèle de la plate-forme correspond à celui de lafigure 2.8, page 23). Les modèles de l’application et de la plate-forme sontensuite transfor-més en un modèle de système spécifique à la plate-forme. Ce modèle est conforme au méta-modèle qui définit le DSML de description de plate-forme d’exécution. Le système résultantcorrespond à la plate-forme d’exécution ciblée dont certaines ressources sont instanciéesen vue d’exécuter l’application. Deux tâches sont, par exemple, instanciées pour offrir uncontexte d’exécution aux activités de contrôle et d’affichage (Controller etMonitor).

10L’activation périodique d’une ressource ordonnançable n’est pasforcément mise en œuvre par une alarmesur d’autres plates-formes d’exécution.

11Le concept d’instance de ressource sera détaillé et discuté dans la suitede ce rapport.


FIG. 2.25:Déploiement d’une application sur une plate-forme OSEK/VDX décrite avec un DSML.

La transformation de déploiement (Robot2Platform) établit la correspondance entre leséléments des modèles sources (PIM et PDM) et les éléments du modèle cible (PSM). Unepartie de la transformation consiste à dupliquer le modèle de la plate-forme d’exécution.Une autre partie traite des correspondances entre les éléments du modèle de l’application etdes instances de ressources de la plate-forme.

La règle PeriodicActivity2PeriodicSchedulableResourcedu listing 2.4 stipule parexemple que tout élément conforme à une activité périodique est transforméen un élé-ment conforme à une instance de ressource ordonnançable, activée périodiquement par uneinstance d’alarme (cf. lignes 7 et 18).

1 -- Create a schedulable resource and an alarm2 -- from a periodic activity3 rule PeriodicActivity2PeriodicSchedulableResource {4 from5 activity : ROBOT!Activity ( activity.isPeriodic() )6 to7 schedres : Platform!ResourceInstance (8 name <- activity.name,9 type <- ... Platform!SchedulableResource ...,

10 properties <- Sequence{ priority, stacksize }11 ),12 priority : Platform!InstanceProperty (13 value <- activity.getPriority(),14 property <- schedres.type.properties15 ->select( p | p.isPriority() )16 ),1718 alarm : Platform!ResourceInstance ( (19 name <- activity.name + ’Alarm’,20 type <- ... Platform!Alarm ...,21 properties <- Sequence{ cycletime }22 ),23 cycletime : Platform!InstanceProperty (24 value <- activity.getPeriod(),25 property <- schedres.type.properties26 ->select( p | p.isCycletime() )27 )2829 }

Listing 2.4:Extrait de la transformation ROBOT2PLATFORM (en ATL)


Au sein des règles de transformation, les instances de ressources sontassociées auxressources de la plate-forme qui les typent (lignes 9 et 20)12. De même, les valeurs depropriétés affectées dans une instance sont associées aux propriétés de la ressource qui typel’instance (lignes 14-15 et 25-26). La valeur 2 de l’instance de tâcheController (figure 2.25)est, par exemple, ainsi affectée à la propriétépriority issue de la ressourceTask.

La mise en œuvre de cette transformation diffère de celle de l’approche précédente parles concepts cibles impliqués. Les accès aux informations des modèles de l’application et dela plate-forme restent cependant les mêmes. Ainsi, comme pour l’exemple précédent, bienque la transformation présentée soit très liée à la plate-forme OSEK/VDX13, aucun conceptpropre à cette plate-forme n’intervient dans l’expression des règles detransformation. Cettecaractéristique offre donc des perspectives de généricité qu’il conviendrait de préciser. Ce-pendant, comme pour l’approche précédente, aucune étude identifiée neconcrétise actuel-lement de telles transformations.

2.4 Comparaison des mises en œuvre

Nous venons d’identifier huit approches pour mettre en œuvre un déploiement d’ap-plication sur une plate-forme d’exécution. Ces approches reposent sur des représentationsenfouies, implicites ou explicites des plates-formes. Elles se répartissent, d’autre part, endeux grandes pratiques, selon que le modèle généré est conforme à un métamodèle de lan-gage de programmation ou à un métamodèle d’application (offrant des concepts de plushaut niveau que ceux d’un langage de programmation). Nous proposons dans cette partiede comparer ces différentes approches, au sein de chacune de ces pratiques qui consistent àgénérer un modèle de code source ou un modèle de plus haut niveau d’abstraction.

L’évaluation que nous présentons se base sur des expérimentations réalisées dans descontextes UML et DSML [19]. Ces expérimentations ont été menées sur des applications derobotiques décrites avec des DSML ou des profils UML « maisons ». Les concepts identifiéspar ces DSML et ces profils sont proches de ceux que nous avons mis à contribution dansles exemples précédents. L’objectif des langages et des applications développés se restreintà cette évaluation, aucun cas d’étude industriel n’y est associé.

Les applications déployées lors des expérimentations se constituaient de traitementsconcurrents périodiques ou apériodiques, identifiés comme des tâches communicant entreelles ou avec l’environnement. Les plates-formes d’exécution visées étaient OSEK/VDX,ARINC-653 ou VxWORKS. Les transformations ont été développées en ATL.

Les résultats que nous présentons se focalisent sur le développement des composantesimpliquées dans le processus de déploiement. Ces composantes sont les transformations,les modèles et les métamodèles. L’évaluation ne tient pas compte du développement desmétamodèles et des modèles des applications sources (PIM ).

Pour cette évaluation, notre attention s’est portée sur les critères suivants :

– La capacité de l’approche àrépartir les connaissancesentre les composantes. Lesconnaissances identifiées dans cette étude concernent l’application source, la plate-forme d’exécution cible et le domaine plus général du temps réel et de l’embarqué ;

12Comme pour l’exemple précédent, pour des raisons didactiques, la transformation de l’exemple ne com-porte pas tout le code ATL. Certaines parties ont été volontairement omises.

13L’activation périodique d’une ressource ordonnançable n’est pasforcément mise en œuvre par une alarmesur d’autres plates-formes d’exécution.

2.4. Comparaison des mises en œuvre 43

– Le temps de développementdes différentes composantes etleur taille . L’échelle detemps est estimée pour un ingénieur familier des concepts de l’IDM. Les tailles sontestimées en nombre de lignes pour les transformations et en nombre de classes pourles modèles et les métamodèles ;

– La capacité deréutilisation des composantes, si une nouvelle plate-forme d’exécu-tion est envisagée ou si la technologie de modélisation de l’application change;

– La capacité deprendre en compte des choix de déploiement, lorsque plusieursmises en œuvre sont possibles pour un même concept (ou mécanisme) applicatif.

2.4.1 Génération d’un modèle de code source

Trois approches de déploiement par génération d’un modèle de code source ont été pré-sentées dans ce chapitre (page 24, page 27 et page 39). Ces approches s’inscrivent dansun contexte DSML. Chacune s’appuie sur un métamodèle de langage de programmation.La première capture les informations relatives à la plate-forme dans la transformation dedéploiement (descriptionenfouie). La seconde capture ces informations dans le métamo-dèle du langage de programmation (descriptionimplicite). La troisième les capture dans unmodèle conforme à un métamodèle de plate-forme d’exécution (descriptionexplicite).

Le tableau 2.1, de la présente page, résume l’évaluation de chacune de ces pratiques.Cette évaluation repose sur des expérimentations menées avec le langage C.

Description enfouieDescription implicite

Description explicitedans un langage

Ts2c MMl Ts2c MMl Ts2c MMp Mp MMl

Connaissances −− + −− − + ? ++ + +

Temps + + + + − − ++ +

Taille −− − − −− −−? − ? ++ −

Réutilisation −− + −− − + ? ++ + +

Choix −− − + ?

Ts2c : transformation d’un modèle d’application en un modèle de code ;MMp : métamodèle de plate-forme d’exécution ;Mp : modèle d’une plate-forme d’exécution ;MMl : métamodèle d’un langage de programmation (le langage C dans les expérimentations) ;

Temps de développement: − (∼mois),+ (∼ semaines),++ (∼ jours) ;Taille (en lignes): −− (∼ 5.103),− (∼ 103), + (∼ 5.102), ++ (∼ 102) ;Taille (en classes): −− (∼ 70),− (∼ 50),+ (∼ 40),++ (∼ 30) ;Autres : −− (très mauvais),++ (très bon), ? (l’investigation nécessite un approfondissement) ;

TAB . 2.1:Approches de déploiement (génération d’un modèle de code de l’application déployée).

La première approche (descriptionenfouie) capture les informations relatives à la plate-forme d’exécution dans la transformation. Celle-ci est ainsi figée sur lesconcepts de cha-cune des technologies impliquées (l’application, la plate-forme cible et le langage de pro-grammation). Le développement, la maintenance et l’optimisation d’une telle transforma-tion sont alors réservés à des spécialistes à la fois de IDM et de ces technologies. De plus,le changement de l’une de ces technologies compromet fortement sa réutilisation.


Parallèlement, la prise en compte des choix de déploiement14 au sein des transforma-tions se fait par un mécanisme qui conditionne l’application des règles de transformations.Dans cette approche, l’expression des décisions relatifs aux choix ne bénéficie d’aucun sup-port pour se référer aux ressources de la plate-forme. Les termes dans lesquels les décisionssont exprimés dépendent de ce qui est implanté dans la transformation.

La seconde approche (descriptionimplicite dans un langage de programmation) facilitel’identification des éléments liés à la plate-forme dans la transformation et dans lemodèlegénéré. Ceux-ci sont en effet conformes à des concepts identifiés dans le métamodèle cible.Cette conformité permet de décrire les transformations avec des règles plusconcises etd’exprimer des décisions vis-à-vis des choix de déploiements directement sur ces concepts.

Cependant, l’introduction des concepts relatifs à la plate-forme dans le métamodèle dulangage de programmation ne tend ni à séparer les connaissances dans ce métamodèle, ni àfavoriser sa réutilisation. Celui-ci est en effet spécialisé pour une plate-forme précise. Vis-à-vis de l’approche précédente, les transformations restent également figées sur les conceptsdes domaines impliqués. Leurs développements sont donc également réservés à des expertsde l’IDM et de tous ces domaines.

La troisième approche (descriptionexplicite) investit dans le développement d’un mé-tamodèle de plate-forme d’exécution. Une description explicite capture alorsles connais-sances relatives à la plate-forme dans un modèle dédié. Ces connaissances ne se confondentplus dans la transformation et n’interfèrent plus avec celles du langage de programmation.Un modèle ou un métamodèle est associé à chaque domaine impliqué dans le processus dedéploiement (application, plate-forme d’exécution, langage de programmation et domainedu temps réel et de l’embarqué). Chacune de ces composantes est exploitable, donc réutili-sable, dans différents projets.

Les transformations de cette approche présentent de plus une faculté degénéricité vis-à-vis des plates-formes d’exécution. L’expression de leurs règles est indépendante des plates-formes cibles. Seuls les concepts identifiés par le métamodèle de plate-forme d’exécutiony sont référencés. Les règles (ou des parties de règles) s’appliquent donc potentiellementpour tout déploiement, quelque soit la plate-forme d’exécution envisagée.

L’expression des décisions vis-à-vis des choix de déploiement peut également portersur des concepts du domaine des plates-formes d’exécution, en plus de ceux de la plate-forme cible. Des mécanismes génériques sont donc là aussi envisageables pour la gestiondes choix.

La généricité qu’apporte cette approche nécessite cependant, pour certains cas, des mé-canismes de transformation et des artefacts de modélisation qu’il reste à préciser. Enfin,l’indépendance à une plate-forme ne peut pas être totale, il conviendra donc d’affiner laplace des informations relatives à celle-ci dans le processus de déploiement. Pour cela,au terme de ces premières expérimentations, des investigations supplémentairesse doiventd’être menées.

Au bilan, les deux premières approches se sont avérées les plus rapides à mettre enœuvre. Elles présentent cependant certaines limites, que la troisième approche semble pal-lier. L’utilisation d’un métamodèle de plate-forme d’exécution offre en effetune meilleureséparation des connaissances, un plus grand potentiel de réutilisation des composantes et unmeilleur support pour l’intégration des décisions relatives aux choix de déploiement. Cetteapproche nécessite toutefois un investissement conséquent dans le développement d’un mé-tamodèle de plate-forme d’exécution et dans celui des transformations associées.

14Les choix de déploiement concernent les mises en œuvre d’un même concept (ou mécanisme) de l’appli-cation avec différentes ressources de la plate-forme d’exécution.


A ce stade, les expérimentations menées révèlent uniquement un potentiel. Une investi-gation supplémentaire se doit donc d’être menée pour développer des composantes maturesà cette approche et confirmer ces résultats.

Remarque sur la génération d’un modèle de code source

L’intérêt d’une génération de modèle de code source réside dans la mise àdispositiond’un modèle de code entièrement compatible avec un outillage IDM. En contrepartie, lestransformations doivent décrire le code source à générer. L’expression des règles de trans-formations consiste alors à énoncer la structure de ce code. Les exemplesde règles de trans-formations (figures 2.10, 2.12 et listing 2.3, pages 25, 27 et 39 respectivement) déclarentainsi la génération d’un appel de fonction et la génération du paramètre de cet appel. Uneentrée de règle est dédiée à chacune de ces générations. Si une entrée de règle correspond àune ligne de transformation, la génération d’un appel àn paramètres nécessite alors l’écri-ture d’une transformation den+1 lignes. En comparaison, untemplatese contentera d’uneseule ligne pour générer le code d’un appel de fonction et de ses paramètres. Une transfor-mation, d’un modèle vers un modèle de code, est donc plus longue à écrire,plus difficile àlire et donc à maintenir qu’untemplatedu même code à générer.

La génération d’un modèle de code ne semble donc présenter aucun avantage par rapportà une utilisation conjointe d’untemplateet d’un injecteur15. Un templatede code offre deplus, à notre sens, un meilleur support pour l’expression des règles decodage. Dans unobjectif de génération de codes source, ou, du moins, dans une phase de développementdédié à cet objectif, l’utilisation d’une technologie partemplatesera donc privilégiée àl’utilisation d’une technologie de génération de modèles.

Néanmoins, l’utilisation d’une technologie partemplaten’exclut pas la considérationexplicite des plates-formes d’exécution (comme cela à été signalé dans ce chapitre, page 39).Le modèle de la plate-forme est, dans ce cas, passé comme paramètre dutemplate, à l’imagede la transmission qui est faite de ce même modèle aux transformations que nousavonsabordées.

2.4.2 Génération d’un modèle d’application

Une alternative à la génération d’un code source, ou d’un modèle de code source,consiste à générer un modèle de l’application à un niveau d’abstraction plus élevé (parabus de langage nous parlerons dans ce cas demodèle d’applicationdans la suite de cerapport). Suivant ce type de génération, lors du processus de déploiement, la considérationde la plate-forme d’exécution peut se faire à partir de descriptionsimplicites ou explicitesde celle-ci. Nous détaillons, dans la suite de cette section, l’évaluation des approches iden-tifiées précédemment, au sein de chacune de ces considérations.

2.4.2.1 Utilisation d’une description implicite de la plate-forme d’exécution

Dans un contexte de génération d’un modèle d’application, deux approches impliquantune description implicite de la plate-forme d’exécution ont été présentées dans ce chapitre(page 27 et page 29). La première pratique une transformation directe, uniquement baséesur les concepts de l’application source et de la plate-forme d’exécution cible. La secondeintroduit dans un pivot des concepts plus abstraits, liés à un domaine communentre toutesles plates-formes d’exécution envisagées (le domaine de l’embarqué et dutemps réel pour

15Un injecteur permet de générer un modèle du code à partir d’un code source. Des outils tel que TCS [57]offrent, par exemple, un support à la génération automatique d’extracteurs et d’injecteurs à partir de métamo-dèles et de syntaxes textuelles concrètes.


ce qui nous concerne). Cette approche conduit à une scission du processus de déploiementen deux transformations.

Le tableau 2.2, de la présente page, résume l’évaluation de chacune de ces pratiques. Lescontextes UML et DSML ne sont pas distingués dans cette évaluation, car les mécanismesde déploiement mis en œuvre pour chacune des approches y sont similaires.

Description implicite

sans pivot avec pivot

Ts2c MMc Ts2pi Tpi2c MMpi MMc

Séparation des connaissances+ + + + + +

Temps de développement + + + ++ − +

Taille − + − + − +

Réutilisation − − + + ++ −

Prise en compte de choix − +/− ?

Ts2c : transformation d’un PIM en un PSM ;MMc : métamodèle cible (décrivant implicitement la plate-forme) ;Ts2pi : transformation d’un PIM en un modèle pivot ;Tpi2c : transformation d’un modèle pivot en un PSM (dépendant de la plate-forme cible) ;MMpi : métamodèle pivot ;

Temps de développement: − (∼mois),+ (∼ semaines),++ (∼ jours) ;Taille (en lignes): −− (∼ 5.103),− (∼ 103), + (∼ 5.102), ++ (∼ 102) ;Taille (en classes): −− (∼ 70),− (∼ 50),+ (∼ 40),++ (∼ 30) ;Autres : −− (très mauvais),++ (très bon), ? (nécessite un approfondissement) ;

TAB . 2.2:Approches de déploiement sur des plates-formes implicitement décrites.

La première approcheimplicite, sans pivot intermédiaire, capture les informations re-latives à la plate-forme d’exécution dans un métamodèle. Cette approche implique que lestransformations soient figées autour de la plate-forme cible. Bien que les concepts relatifs àun langage de programmation soient écartés, vis-à-vis des approches précédentes, la mise enœuvre, la maintenance et l’optimisation des transformations restent réservées à des expertsde l’IDM, du domaine applicatif et des plates-formes d’exécution envisagées.

Toute considération d’une plate-forme d’exécution alternative nécessitede plus le déve-loppement complet d’une nouvelle transformation. Pour ce qui nous concerne, il n’y a paseu ou très peu de réutilisation possible des transformations développées durant nos expéri-mentations. La réutilisation s’est essentiellement limitée à prendre exemple sur cequi avaitété fait dans de précédentes transformations.

Parallèlement, à l’image de l’approche par descriptionimplicite dans un langage deprogrammation, l’expression des décisions relatives aux choix de déploiement peuvent s’ap-puyer sur les concepts qu’identifie le métamodèle cible. Ces décisions se restreignent ce-pendant à une plate-forme d’exécution précise, aucune perspectived’expression à un niveaud’abstraction plus élevé n’est ici envisageable.

La seconde approcheimplicite introduit une plate-forme pivot (abstraite). Cette plate-forme intermédiaire, elle-même implicitement décrite, permet de scinder le processus dedéploiement en deux étapes de transformation. Cette scission améliore la réutilisation dechacune des transformations. En effet, si les concepts du domaine métier interviennent danstoutes les transformations, aucune compétence sur la plates-forme d’exécution ciblée n’est


mise à contribution dans celles de la première étape. De même, aucune compétence sur ledomaine applicatif n’est mise à contribution dans celles de la seconde étape. Les transfor-mations de chacune des étapes sont ainsi utilisables (et donc réutilisables)indépendammentdes plates-formes concrètes envisagées ou des applications à déployer.

La taille et le temps de développement des transformations de la première étape restentdu même ordre que dans l’approche sans pivot (le nombre de concepts àmanipuler étant luiaussi du même ordre). La taille moyenne et les temps de développement des transformationsde la seconde étape sont, eux, nettement inférieurs (quelques centainesde lignes et quelquesjours respectivement). Cette simplicité de développement est due à la nature des relationsentre le pivot et les plates-formes cibles. Seules les correspondances entre les conceptsdu pivot et leurs implantations dans les plates-formes concrètes sont exprimées par cestransformations. Les relations sont alors majoritairement 1-1, par opposition aux relations1-N des transformations impliquant le métamodèle de l’application.

Cependant, la conception et le développement du pivot a nécessité un temps supplémen-taire pour la sélection des concepts qu’il offre. Il nous a fallu plusieursmois pour étudier,classer et organiser dans un métamodèle les différents concepts qu’offrent les plates-formesd’exécution de notre domaine d’intérêt (les systèmes d’exploitation temps réel embarqués).Ce métamodèle fut néanmoins réutilisé dans tous les projets axés sur cette approche.

L’introduction d’un métamodèle pivot offre également un support pour l’expression desdécisions relatives aux choix de déploiement à un niveau d’abstraction plus élevé. Desdécisions prises indépendamment des plates-formes concrètes, en ne considérant que desconcepts, peuvent ainsi s’ajouter, voir se mêler, à des décisions propres à une plate-formeprécise. Dans cette optique, la décomposition d’une transformation de déploiement en deuxtransformations (l’une concentrée sur les concepts du domaine, l’autre sur une plate-formeconcrète) offre la perspective de pouvoir séparer les décisions de déploiements « concep-tuelles » des décisions propres à une plate-forme. Cependant, l’existence de liens entre cesdécisions complexifient leurs considérations, leurs intégrations et leurs optimisations dansles transformations. Une décision appliquée dans la première transformationest-elle perti-nente et optimale sur toutes les plates-formes envisageables ? Cette considération mériteraitune investigation supplémentaire.

2.4.2.2 Utilisation d’une description explicite de la plate-forme d’exécution

Dans ce même contexte de génération d’un modèle d’application, quatre approches im-pliquant une description explicite de la plate-forme d’exécution ont été présentées dans cechapitre (page 31, page 35, page 36 et page 40). Chacune de ces approches introduit lesconcepts communs aux plates-formes d’exécution dans un DSML ou un profil UML . Letableau 2.3, page suivante, résume leurs évaluations.

Les contextes UML et DSML sont ici distingués. UML fournit en effet un contexte unifiépour la modélisation de l’application, de la plate-forme et du déploiement de l’applicationsur la plate-forme. Or, bien qu’une pratique similaire soit envisageable pour les DSML dé-diés à la modélisation conjointe de l’application et de la plate-forme d’exécution (pratiquequalifiée de « mise en relations internes » dans le tableau 2.3), lorsque cette modélisationest disjointe, car pratiquée avec des langages différents, d’autres approches de déploiementdoivent être considérées. Parmi ces approches, l’une, qualifiée de« promotion » dans letableau 2.3, consiste à promouvoir le modèle de la plate-forme en un métamodèle d’ap-plication. Cette approche se ramène alors à un déploiement sur une plate-forme implicite-ment décrite. L’autre, qualifiée d’« intégration d’application », consiste à générer un modèle


conforme au métamodèle de plate-forme d’exécution. Ce dernier fournit alors des conceptspour intégrer une représentation de l’application au modèle de la plate-forme.

Description explicite

UML (1)DSML

relations internes promotion intégration appli.

Tp MMp(2) Mp Md

(3) MMp Mp Td MMp Tpr Mp Td MMp Mp

Sép. ++ ++ + + −− +/− + ++ + + + ? ++ +

Tps. − ? − ++ + − ++(4) + − + ++ − ? − ++

Tai. − ? ++ ++ ++ −− ++(4) − − − ++ − ? −? ++

Réu. + ? ++ + −− +/− +/− − ++ ++ + + ? ++ +

Chx. + ? Ø − + ?

(1) Les expérimentations se sont appuyées sur des travaux qui ont précédé cette étude [114].(2) Profil UML dédié aux concepts des plates-formes d’exécution.(3) Seules les associations de déploiement, au sein du modèle du système, sont considérées.(4) Seule la description de la plate-forme est comptabilisée.

Tp : transformation de portage ;MMp : métamodèle de plate-forme d’exécution ;Mp : modèle d’une plate-forme d’exécution ;

Md : modèle de déploiement ;Td : transformation de déploiement ;Tpr : transformation de promotion ;

Temps de développement: − (∼mois),+ (∼ semaines),++ (∼ jours) ;Taille (en lignes): −− (∼ 5.103),− (∼ 103), + (∼ 5.102), ++ (∼ 102) ;Taille (en classes): −− (∼ 70),− (∼ 50),+ (∼ 40),++ (∼ 30) ;Autres : −− (très mauvais),++ (très bon), ? (l’investigation nécessite un approfondissement) ;

TAB . 2.3:Approches de déploiement sur des plates-formes explicitement décrites.

La première approche, dans un contexte UML , a été expérimentée lors de travaux quiont précédé cette étude [114]. Ces travaux se sont intéressés à définir un profil UML 16 pourla description de plates-formes d’exécution logicielles embarquées temps réel. Dans cetteapproche, les connaissances relatives aux plates-formes d’exécution sont ainsi explicitementdécrites et identifiées par stéréotypage dans des modèles UML .

A l’instar du travail effectué pour la définition d’un pivot, la conception etle dévelop-pement du profil a nécessité du temps pour la sélection et l’organisation desconcepts qu’ilidentifie. Cependant, la taille de ce profil reste modeste car le contexte de modélisation danslequel il s’applique bénéficie de l’ensemble du langage UML . Seuls les concepts propresaux plates-formes d’exécution y sont donc spécifiés.

Dans cette approche, les transformations mises en œuvre s’appuient surdes déploie-ments existants pour automatiser les portages des applications d’une plate-forme à uneautre. Ces transformations, qualifiées de transformations de portage, sont en grande partiegénériques vis-à-vis des plates-formes d’exécution (leur principe repose sur l’algorithme 2.1présenté dans ce chapitre, page 34). Cette généricité permet de les utiliser(et donc réutili-ser) dans tous les projets, quelque soit le portage envisagé. Cependant, l’indépendance à uneplate-forme ne pouvant être totale, des expérimentations supplémentaires sedoivent encored’être menées pour affiner la place des informations relatives aux plates-formes dans leprocessus de déploiement.

16Ce profil, intégré dans le profil UML -MARTE, sera détaillé dans la suite de ce document.


L’identification des concepts par le profil offre également un support pour l’expressiondes décisions relatives aux choix de déploiement (ou choix de portage dans ce cas précis).Comme pour l’approche par pivot, des décisions « conceptuelles », indépendantes d’uneplate-forme précise, peuvent s’ajouter, voir se mêler, à des décisions propres à une plate-forme d’exécution donnée. La centralisation de ces informations dans uneseule transfor-mation semble néanmoins simplifier l’intégration et la possibilité d’optimiser ces décisions.Les investigations qui ont été menées dans ce sens doivent être approfondies.

La première approche dans un contexte DSML, qualifiée de « relations internes » dansle tableau 2.3, s’appuie sur une description conjointe de l’application et de laplate-forme d’exécution. Le métamodèle auquel se conforme cette description regroupe donc lesconnaissances relatives à l’application et au support d’exécution. Iloffre de plus les conceptsnécessaires à l’expression du déploiement de l’application sur le support d’exécution.

Cette approche s’apparente à ce qui se pratique dans un contexte UML , dans lequeltout modèle s’exprime avec un seul langage de modélisation. Cependant, le métamodèleutilisé ici se différencie par son caractère dédié aux domaines de l’applicatif et de l’exécutif.La taille du métamodèle est donc fortement impactée par l’ensemble des conceptsqu’ildoit identifier. L’organisation de ces concepts, issus de différents domaines, peut égalementaffecter les capacités de réutilisation de chacune des composantes (les parties du modèle quiconcernent l’application, la plate-forme d’exécution et les associations de déploiement).

La réutilisation de ces différentes composantes reste toutefois envisageable si desconventions et des règles de bonnes pratiques sont respectées pourla conception et le déve-loppement du métamodèle [32]. Un agencement des concepts de l’exécutif indépendant desconcepts de l’applicatif favorise, par exemple, la réutilisation de chacune des composantes.De même, une interface structurelle « normalisée » entre les concepts de l’applicatif et ceuxde l’exécutif permet d’uniformiser leurs intégrations dans différents modèles.

Lors des expérimentations, la prise en compte des choix de déploiement n’a pas été inté-grée dans les transformations (contrairement à leurs introductions dans les transformationsdes approches précédentes). Les déploiements d’applications sur desplates-formes d’exé-cution ont été manuels. A l’image de la modélisation UML de l’approche précédente, oùseuls les portages ont été automatisés, une automatisation du portage des applications d’uneplate-forme à une autre est toutefois envisageable. Pour cela, une adaptation de l’algorithmede portage générique (mis à contribution dans le contexte UML ) est encore à expérimenter.

En pratique, la principale limite de cette approche repose sur son rapport au métamodèlede l’application (PIM ). Si ce dernier ne permet pas de décrire les plates-formes d’exécution,la possibilité de le modifier est indispensable à cette approche. Dans ce cas,il est en effetnécessaire de pouvoir l’« étendre » à la description des plates-formes d’exécution. Or, lemétamodèle de l’application est parfois imposé et issu d’une technologie qui ne permet oune prévoit pas ce genre d’extension.

La seconde approche dans un contexte DSML, qualifiée de « promotion » dans le ta-bleau 2.3, consiste à promouvoir un modèle de plate-forme d’exécution en unmétamodèle.Une application est alors déployée par génération d’un modèle conforme àce dernier. Cetteapproche se ramène à l’utilisation d’une description implicite de plate-forme d’exécution.

A l’instar des définitions du métamodèle pivot ou du profil UML de description deplates-formes d’exécution, la conception et le développement du métamodèlede plate-forme d’exécution a nécessité un investissement significatif pour la sélectionet l’organi-sation des concepts du domaine. Ce métamodèle s’est avéré fortement réutilisable, puisqueimpliqué dans tous les processus de déploiement pratiqués. Sa taille est cependant nettementsupérieur à celle d’un profil UML car l’ensemble des artefacts de modélisation nécessaires à


la description d’une plate-forme doit y être intégré (un profil UML enrichit le langage UML ,il bénéficie donc implicitement de tous les artefacts de modélisation UML ).

Le mécanisme de promotion d’un modèle de plate-forme d’exécution en un métamodèlea été mis en œuvre par transformation de modèles. Une transformation générique a pour celaété développée (à l’image de la transformation de promotion présentée dans lelisting 2.2,page 36). Cette transformation s’est également révélée fortement réutilisable, car mise àcontribution pour toutes les promotions.

Dans cette approche, les transformations de déploiement sont de même nature que dansl’approche utilisant une description implicite de plate-forme d’exécution. Leur évaluationcoïncide donc avec celle de l’approcheimplicite présentée précédemment (tableau 2.2,page 46). Cependant, une investigation supplémentaire (non reportée dans le tableau 2.3,page 48) nous a permis de mettre en œuvre un processus de génération detransformationsde portage. Ce processus, en grande partie générique, s’appuyaitsur l’algorithme 2.2 pré-senté dans ce chapitre, page 37. Cette approche a toutefois été abandonnée en raison de lacomplexité des générateurs de transformations et de la difficulté à les maintenir.

La troisième et dernière approche dans un contexte DSML, qualifiée d’« intégrationd’applications » dans le tableau 2.3, page 48, consiste à transformer les modèles de l’appli-cation et de la plate-forme d’exécution en un modèle de la plate-forme dont lesressourcessont instanciées en vue d’exécuter l’application. Le métamodèle de plate-forme d’exécu-tion, en partie analogue à celui de l’approche précédente, fournit pour cela des mécanismespermettant d’intégrer, dans un modèle de plate-forme, une représentationde l’utilisation deses ressources par une application.

Cette forme d’intégration de l’application dans le modèle de la plate-forme ne consi-dère aucun aspect métier de l’application, contrairement à la modélisation conjointe del’applicatif et de l’exécutif présentée précédemment. La taille du métamodèle n’est doncpas impactée par la considération d’un domaine métier propre à l’application. Il est de plusutilisable en tant que tel pour tout type d’application.

Cependant, à ce premier stade d’investigation, l’ensemble des artefacts demodélisa-tion nécessaires à cette approche reste encore à identifier. Seuls les artefacts d’intégrationprésentés dans ce chapitre, page 40, ont été implantés dans le métamodèle. Cette premièreversion laisse toutefois présager que la taille du métamodèle de plate-forme d’exécutiondépasse significativement celle du métamodèle de l’approche « par promotion».

Une première version d’un tel métamodèle nous a permis de développer une transfor-mation de déploiement en partie générique (à l’image de la transformation présentée dansle listing 2.3, page 39). Au bilan, chacune des composantes impliquées dans leprocessus dedéploiement présente donc un fort potentiel de réutilisation. Le métamodèle deplate-formeest utilisé dans tous les déploiements, à la fois pour modéliser les plates-formescibles etpour offrir un support aux transformations. Les modèles de plates-formes d’exécution sontutilisables (et donc réutilisables) quelques soit la technologie source. Enfin, une uniquetransformation est mise à contribution dans tous les déploiements. Dès lors, déployer uneapplication sur une nouvelle plate-forme consiste à fournir, d’une part, lemodèle de cettenouvelle plate-forme et, d’autre part, les éléments de traduction manquants à latransforma-tion. Cette transformation centralise de plus la prise en compte des choix de déploiement,qu’ils soient « conceptuels » (relatifs au domaine) ou propres aux plate-formes.

Cependant, comme pour toute approche mettant à contribution des mécanismes géné-riques de transformations, la considération, au sein du processus de déploiement, des infor-mations propres aux plates-formes doit encore être précisée. A ce staded’investigation, desétudes supplémentaires s’imposent donc pour confirmer les capacités prometteuses de cetteapproche en terme de réutilisation et de prise en compte des choix de déploiement.

2.5. Positionnement 51

2.5 Positionnement

Vers une description explicite des plates-formes d’exécution

Que l’on souhaite générer un modèle du code source de l’application ou unmodèlede plus haut niveau de l’application déployée sur une plate-forme d’exécution, l’utilisa-tion d’une description implicite de plate-forme d’exécution ne semble intéressante quelorsque très peu de plates-formes cibles sont envisagées. En effet, bien que ce type d’ap-proche s’avère plus simple et plus rapide à mettre en œuvre, la prise en compte de chaqueplate-forme d’exécution nécessite le développement complet d’une transformation de dé-ploiement. La réutilisation est donc très limitée. De plus, la conception, l’optimisationet lamaintenance de ces transformations mettent à contribution des compétences dudomaine ap-plicatif et du domaine des plates-formes d’exécution envisagées. Les connaissances métiersne sont pas clairement séparées dans les différentes composantes du processus de déploie-ment. Enfin, dans ce type d’approche, les choix de déploiement se limitent à des méca-nismes internes à une plate-forme donnée. Aucune considération ne peutêtre portée à unniveau d’abstraction plus élevé, tels que des choix sur différents concepts du domaine desplates-formes d’exécution.

Si plusieurs plates-formes cibles sont envisageables, il semble plus intéressant de mettreen œuvre une approche par description explicite de ces plates-formes. En effet, dans le casd’une génération d’un modèle du code source de l’application, ce type d’approche offreun support pour la mise en œuvre de transformations en partie génériquesvis-à-vis desplates-formes d’exécution. De même, dans le cas d’une génération d’un modèle de plus hautniveau de l’application, la définition d’un pivot ou la définition d’un métamodèle de plate-forme d’exécution sont de la même complexité et prennent des temps de développementéquivalents. Mais, la considération explicite de la plate-forme d’exécution permet, là aussi,de mettre en œuvre des transformations plus génériques. Enfin, les transformations de cetype d’approche centralisent les décisions relatives aux choix de déploiements dans uneseule transformation, que ces choix portent sur des mécanismes internes àune plate-formed’exécution précise ou sur des concepts de plus haut niveau relatifs au domaine des plates-formes d’exécution.

Ce premier constat concerne des démarches de développement dans des contextesGPML et DSML. Cependant, les expérimentations menées jusqu’à présent révèlent unique-ment le potentiel des approches qui décrivent explicitement les plates-formes d’exécution.Une étude plus approfondie se doit donc d’être menée pour développerdes composantesmatures à ces approches et confirmer ces résultats.

Nous proposons de mener cette étude dans un contexte DSML.

Vers un modèle d’application de haut niveau d’abstraction

Les approches qu’il est nécessaire d’approfondir se répartissent en deux pratiques, selonqu’elles génèrent un modèle de code source ou un modèle de l’application àun niveaud’abstraction plus élevé. Or, la considération de la plate-forme d’exécution intervient dansune phase que nous avons qualifiée dephase de déploiement. Cette phase, telle que nousl’envisageons, s’exerce en amont de laphase d’implantationdans laquelle interviennent lestechniques ou les technologies de codage.

Nous nous intéresserons donc, dans la suite de cette étude, à la génération de mo-dèles d’applications, certes dépendants d’une plate-forme d’exécution, mais indépendantsde toute technique ou de toute technologie de codage. Les modèles générés, à l’issue de


la prise en compte de la plate-forme d’exécution, visent donc un niveau d’abstraction plusélevé que celui des codes source ou des modèles de codes source.

Vers une intégration de l’application dans le modèle de la plate-forme

Parmi les approches qui permettent de générer des modèles d’applications à un hautniveau d’abstraction, celle que nous avons qualifiée d’« intégration d’application » semblela plus intéressante. En effet, cette approche ne manipule que des représentations explicites,contrairement à l’utilisation d’un mécanisme de promotion qui se ramène à la considéra-tion implicite de la plate-forme. Elle s’adapte, de plus, à tout métamodèle d’applicationen séparant les domaines de l’application et du support d’exécution, contrairement à unedescription conjointe de l’application et de la plate-forme qui regroupe les concepts de cesdomaines dans un seul métamodèle.

Dans la suite de cette étude, nous nous intéressons donc, en particulier, àcette approchequalifiée d’« intégration d’application ».

Vers un DSML de description de plates-formes d’exécution

L’approfondissement de cette approche nécessite de mettre en œuvre unlangage dédiéà la description des plates-formes d’exécution de notre domaine d’intérêt (les systèmesd’exploitation temps réel embarqués). Or, les modèles de plates-formes envisagés dans cetteétude se focalisent sur la description structurelle des ressources et des services offerts parles plates-formes. Le métamodèle du langage à mettre en œuvre se doit donc d’identifier lesressources et les services communs aux différentes plates-formes du domaine.

Dans cet objectif, parmi les technologies actuellement disponibles, toutes approchesconfondues (GPML et DSML), le profil UML -MARTE, au travers dupackageSRM (Soft-ware Resource Modeling), définit l’ensemble le plus adapté de concepts métiers pour lamodélisation de plates-formes d’exécution logicielles embarquées temps réel17.

Le modèle de domaine d’UML -MARTE offre de plus, au delà d’un contexte UML , unsupport pour la définition et l’implantation de DSML. En effet, bien que l’implantation stan-dard d’UML -MARTE soit un profil UML , sa conception a été conduite sur la base d’unmodèle de domaine qui spécifie les concepts utiles pour modéliser le domaine métier(lessystèmes embarqués temps réel). Le profil UML -MARTE est une implantation de ce modèlede domaine. Une implantation alternative, dans un DSML, est donc également envisageable.

Nous proposons donc, dans la suite de cette étude, de nous appuyer sur le packageSRM

du profil UML -MARTE pour concevoir et implanter un DSML de description de plates-formes d’exécution temps réel embarquées.

Ainsi, dans la suite de cette étude nous approfondirons la mise en œuvre d’un déploie-ment d’application dans lequel la plate-forme d’exécution est explicitement décrite. Ce pro-cessus suivra l’approche par « intégration d’application ». Les applications déployées serontmodélisées à un niveau d’abstraction plus élevé que celui d’un code source ou d’un modèlede code source, indépendamment de toute technique ou de toute technologiede codage.L’étude se focalisera sur un contexte de modélisation DSML. Un DSML de description deplates-formes d’exécution temps réel embarquées sera donc proposé,inspiré du modèle dedomaine dupackageSRM du profil UML -MARTE.

17Ce constat s’appuie sur un état de l’art établi lors de travaux qui ont précédé cette étude [114]. Les diffé-rentes technologies existantes de modélisation des plates-formes d’exécution, identifiées lors de cet état de l’artet mentionnées dans ce chapitre, sont présentées plus en détails en annexe (Annexe C, page 191).

2.5. Positionnement 53

Pour cela, la partie suivante de ce rapport présente, dans un premier chapitre, l’implanta-tion de ce DSML, avant d’introduire, dans le second chapitre, un processus de déploiementsd’applications axé sur ce DSML. Ce second chapitre se concentre en particulier sur l’intro-duction, dans le DSML, de concepts nécessaires à une approche par « intégration d’applica-tion » dans un modèle de plate-forme, puis à la prise en compte des choix de déploiementlors de ce type d’intégration. Un dernier chapitre présente finalement les résultats que nousavons obtenus avec cette approche en la comparant à nouveau aux approches par descriptionimplicite des plates-formes.

Deuxième partie

Considération explicite d’uneplate-forme d’exécution

3Un langage de description de plate-forme

d’exécution

Sommaire3.1 Le modèle de domaine dupackageSRM d’U ML -M ARTE . . . . . . 59

3.1.1 Le motif ressource/service appliqué au logiciel . . . .. . . . . 593.1.2 Les ressources et les services de SRM . . . . . . . . . . . . . . 60

3.2 Implantation du modèle de domaine dans un DSML . . . . . . . . . 633.2.1 Modélisation des ressources et des services . . . . . . . .. . . 633.2.2 Les ressources logicielles . . . . . . . . . . . . . . . . . . . . . 643.2.3 Les éléments typés . . . . . . . . . . . . . . . . . . . . . . . . 643.2.4 Les types de données . . . . . . . . . . . . . . . . . . . . . . . 653.2.5 Les instances de ressources . . . . . . . . . . . . . . . . . . . . 653.2.6 Les routines et les points d’entrée . . . . . . . . . . . . . . . .67

3.3 Artefacts de modélisation . . . . . . . . . . . . . . . . . . . . . . . . 683.3.1 L’héritage de ressource . . . . . . . . . . . . . . . . . . . . . . 683.3.2 La composition de services . . . . . . . . . . . . . . . . . . . . 693.3.3 Prototypes de conception . . . . . . . . . . . . . . . . . . . . . 69

3.4 Exemple d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 723.5 Synthèse et résultats sur le langage proposé . . . . . . . . . .. . . . 74

Dans le domaine du temps réel et de l’embarqué, le profil UML -MARTE identifie, autravers de sonpackageSRM, un ensemble de concepts utiles à la description de plates-

formes d’exécution logicielles. LepackageSRM spécifie ces concepts et leurs relations dansun modèle de domaine qu’il implante ensuite dans un profil UML .

Nous proposons dans ce chapitre une implantation alternative du modèle de domaine deSRM dans un DSML. Ce langage, présenté sous le nom de RTEPML (Real Time EmbeddedPlatform Modeling Language), identifie, d’une part, les concepts du domaine (telles queles notions d’exécution concurrente ou d’alarme) et fournit, d’autre part, des artefacts demodélisation utiles à la description des modèles (tels que l’héritage ou la composition).

Les deux premières sections de ce chapitre présentent successivement le modèle dedomaine de SRM et son implantation dans RTEPML. La troisième section se focalise sur lesartefacts de modélisation qu’offre le langage. Un exemple de modélisation de plate-formeavec RTEPML est ensuite donné dans la quatrième section avant de conclure sur le langageproposé dans la dernière section.

3.1. Le modèle de domaine dupackageSRM d’UML -MARTE 59

3.1 Le modèle de domaine dupackageSRM d’U ML -M ARTE

3.1.1 Le motif ressource/service appliqué au logiciel

Dans le cadre des profils standards SPT (Schedulability, Performance and Time) [85]puis UML -MARTE [89] dédiés à la conception d’applications temps réel, l’OMG proposeun motif de modélisation des ressources d’un système (figure 3.1) : les ressources sont ins-tanciables, elles offrent des services paramétrables et peuvent être quantifiées ou qualifiéespar des propriétés non-fonctionnelles.

FIG. 3.1:Extrait du motif ressource/service du profil UML -MARTE [89].

Dans le contexte d’une modélisation de plate-forme d’exécution, la notion de ressourcereprésente les types de la plate-forme. Ces types interfacent des mécanismes fournis par laplate-forme. Leurs capacités d’exécution et d’instanciation sont généralement limitées. Lesservices des ressources sont les traitements offerts par la plate-forme.

Sur la base du motif « ressource/service », lepackageSRM du profil UML -MARTE spé-cialise pour le domaine du logiciel1 le concept de ressource (figure 3.2). Les ressources logi-cielles sont munies de propriétés et fournissent des services spécifiques pour, par exemple,la création, l’initialisation et la destruction d’une ressource (createServices, initializeSer-vices, deleteServices).

FIG. 3.2:Extrait du modèle de domaine de SRM : les ressources logicielles [89].

L’identification des rôles des services et des propriétés d’une ressource se fait au tra-vers d’associations (ou références), telles que les associations entrela classeSwResourceetles classesResourcePropertyet ResourceServicede la figure 3.2. Leur cardinalité multiple(0..*) permet d’associer à plusieurs services ou plusieurs propriétés le même rôle.

Vis-à-vis d’une identification par classe, l’identification par référence offre l’avantagede limiter le nombre de classe et la redondance d’information dans le modèle de do-maine [114]. Ce mécanisme permet également d’associer un rôle à une propriété ou à unservice externe à une ressource.

1Le profil UML -MARTE se destine à la modélisation des composants logiciels et matériels d’un système.

60 Chapitre 3. Un langage de description de plate-forme d’exécution

3.1.2 Les ressources et les services de SRM

Le packageSRM identifie trois familles de ressources logicielles pour décrire une plate-forme d’exécution temps réel embarquée. Les ressources d’exécutions concurrentes, lesressources d’interaction et les ressources de gestion. Cette partie présente succinctementles deux premières familles dont les concepts sont implantés dans RTEPML. La dernière fa-mille ne sera pas mise à contribution dans cette étude. Les ressources de gestion offrent desservices pour la gestion d’autres ressources. Leurs champs d’application couvrent essentiel-lement l’allocation des ressources matérielles (tels que le processeur ou la mémoire) et lagestion des périphériques. La description détaillée de chacune des famillesest disponibledans le standard [89] et dans l’étude qui a conduit à la définition de SRM [114].

Les ressources d’exécution concurrentes2 (SwConcurrentResource) spécialisent leconcept de ressource logicielle (figure 3.3). Ces ressources fournissent un contexte pourl’exécution d’un ou de plusieurs traitements accessibles par des points d’entrée (Entry-Point). Deux catégories de ressources concurrentes sont identifiées : celles activées parun ordonnanceur ou par une autre ressource de la plate-forme (SwSchedulableResource) etcelles activées suite à une interruption (InterruptResource). Parmi ces dernières, les alarmesse distinguent par leur activation sur une valeur de référence fourniepar un compteur (Sw-TimerResource).

L’activation d’une ressource concurrente peut être périodique, apériodique ou spora-dique. Une ressource concurrente offre des services pour activer, suspendre, reprendre etterminer une exécution. Elle peut également être caractérisée par une priorité d’exécution,une période d’activation et la taille de sa pile. Une interruption peut être d’origine matérielle(capteurs ou processeurs - suite à une exception) ou logicielle.

Les propriétés et les services propres aux ressources ordonnançables et aux ressourcesd’interruption ne sont pas représentés sur la figure 3.3. Certains sontintroduits dans lasuite de ce rapport ou présents dans l’implantion du modèle de domaine disponible en an-nexe (page 151).

FIG. 3.3:Extrait du modèle de domaine de SRM : les ressources d’exécution concurrentes [89].

2Par abus de langage, les ressources d’exécution concurrentes sont parfois qualifiées de « ressources concur-rentes » dans la suite de ce rapport.

3.1. Le modèle de domaine dupackageSRM d’UML -MARTE 61

Les ressources d’exécution concurrentes peuvent être confinéesdans un espace mé-moire. Dans SRM, cet espace mémoire est qualifié de partition mémoire (MemoryPartition,figure 3.4). Une partition mémoire représente un espace d’adressage affecté à des ressourcesconcurrentes. Il restreint l’espace mémoire accessible en lecture et enécriture à ces res-sources. Une partition mémoire peut offrir des services de duplication ou de libération del’espace mémoire (forkServices, exitServices).

FIG. 3.4:Extrait du modèle de domaine de SRM : les partitions mémoires [89].

Les ressources d’interaction (SwInteractionResource) spécialisent également leconcept de ressource logicielle (figure 3.5). Ces ressources fournissent aux exécutionsconcurrentes des mécanismes pour synchroniser leurs actions et communiquer leurs don-nées. Deux catégories de ressources d’interaction sont donc identifiées : les ressources desynchronisation (SwSynchronizationResource), qui contrôlent les flots d’exécution, et lesressources de communication (SwCommunicationResource), qui gèrent les flots de données.

Le champ d’action d’une ressource d’interaction peut se restreindre àune partition demémoire. Elle impose également une politique de mise en attente des exécutions ou des don-nées dont le flot est suspendu (waiting policy). Les entités suspendues sont ainsi organiséesen file, en pile ou par valeurs de priorité.

FIG. 3.5:Extrait du modèle de domaine de SRM : les ressources d’interaction [89].

Les ressources de synchronisation(SwSynchronizationResource, figure 3.6, page sui-vante) identifient deux types de mécanismes : l’exclusion mutuelle (SwMutualExclusionRe-source) et la notification (NotificationResource).

Une ressource d’exclusion mutuelle offre des services pour prendreou libérer la zonequ’elle protège. L’accès à cette zone peut se faire par mutex, sémaphore booléen ou séma-phore à compte. Un protocole d’accès tels que PIP, PCP ou l’absence de préemption peutégalement y être associé.

Une notification prend la forme d’une barrière ou d’un évènement qui est signalé, at-tendu ou effacé. Ses occurrences peuvent incrémenter la valeur d’un compteur ou être mé-morisées.


FIG. 3.6:Extrait du modèle de domaine de SRM : les ressources de synchronisation [89].

Les ressources de communication(SwCommunicationResource, figure 3.7) identifientdeux types de mécanismes : l’échange de donnée par variable partagée (ShareDataComRe-source) et par message (MessageComResource).

Une variable partagée offre des services de lecture et d’écriture dans un espace mémoirepartagé entre plusieurs ressources d’exécution concurrentes.

La communication par message se fait par envoi et réception de messages.Un messagepeut être mémorisé dans une file d’attente, déposé dans unbuffer (ou tableau noir,black-board) ou transmis via un mécanisme similaire aupipe POSIX. Les messages mémoriséssont organisés en file, en pile ou par valeurs de priorité.

FIG. 3.7:Extrait du modèle de domaine de SRM : les ressources de communication [89].

Les ressources d’interaction sont finalement rendues accessibles depuis les ressourcesd’exécution concurrentes (figure 3.8).

FIG. 3.8:Extrait du modèle de domaine de SRM : les interactions des ressources concurrentes [89].

3.2. Implantation du modèle de domaine dans unDSML 63

3.2 Implantation du modèle de domaine dans un DSML

L’implantation d’un modèle de domaine dans un DSML consiste à développer un méta-modèle, avec une technologie de méta-métamodélisation, dont les concepts et les relationsentre ces concepts correspondent au modèle de domaine. Cette partie présente l’implanta-tion du modèle de domaine de SRM dans RTEPML.

LepackageSRM s’intègre toutefois dans un contexte de modélisation UML . Son modèlede domaine se réfère donc à des concepts externes à SRM, issus du langage UML ou d’autrespackagesdu profil UML -MARTE. Or, dans un contexte DSML, la nature même du langagenécessite de définir tous les concepts dans un même métamodèle. L’implantation dumodèlede domaine de SRM, sous la forme d’un DSML, nécessite donc d’introduire dans le DSML

les concepts de SRM et les concepts « externes » auxquels SRM se réfère.

Les deux premières parties de cette section présentent les principes d’implantation dumodèle de domaine de SRM dans RTEPML. Les points particuliers concernant l’introductionde concepts supplémentaires sont abordés dans les parties suivantes.

3.2.1 Modélisation des ressources et des services

Le motif ressource/service

A l’instar du modèle de domaine de SRM, RTEPML fonde la description d’une plate-forme d’exécution sur le motif ressource/service (cf. Le motif ressource/service appliquéau logiciel, page 59). Un modèle de plate-forme d’exécution se compose de ressources quioffrent des services paramétrables et peuvent être quantifiées ou qualifiées par des propriétés(figure 3.9).

FIG. 3.9:Extrait du DSML RTEPML : fondation de la modélisation des ressources et des services.

Identification des éléments

En pratique, un nom identifie systématiquement les ressources, les propriétés et les ser-vices d’une plate-forme d’exécution. Ce nom peut être défini dans un standard, une docu-mentation ou une implantation de l’exécutif. L’attributnamede modélisation de ces élé-ments (alors qualifiés d’éléments nommés [32], figure 3.10) permet de les identifier dansles modèles. C’est par cet attribut que les éléments d’une plate-forme sontassociés auxconcepts métiers du langage.

FIG. 3.10:Extrait du DSML RTEPML : les éléments nommés.


3.2.2 Les ressources logicielles

RTEPML reprend la hiérarchie des ressources logicielles du modèle de domaine de SRM

(figure 3.11). N’ayant aucune vocation à représenter d’autres types de ressource, telles quedes ressources matérielles, le préfixeSwn’est pas retranscrit dans cette implantation.

FIG. 3.11:Extrait du DSML RTEPML : hiérarchie des ressources.

L’identification des rôles affectés aux services et aux propriétés d’une ressource, parréférence, est également conservée dans RTEPML. La figure 3.12 illustre ce mécanisme parles associations d’une ressource à ses services de création, d’initialisation et de destruction.

FIG. 3.12:Extrait du DSML RTEPML : affectation des rôles.

3.2.3 Les éléments typés

Dans le modèle de domaine de SRM, les notions de propriété d’une ressource et deparamètre d’un service spécialisent la notion d’élément typé UML (TypedElement) [89].Parallèlement, le concept de ressource spécialise celui de type. Ces concepts de typage,bien qu’externes à SRM, nécessitent d’être retranscrits dans l’implantation qui en est faitedans RTEPML.

Un nouveau concept de « type » aurait pu être introduit dans le DSML. Cependant, leconcept de ressource correspond déjà à la notion de type pour une plate-forme d’exécution.Tout type mis à contribution par une application est censé être fourni par laplate-formed’exécution. L’introduction d’un concept de type, en abstraction du concept de ressource,nous semble donc redondant et inutile. Dans RTEPML, un élément typé est donc typé parune ressource de la plate-forme. La figure 3.13 illustre par exemple le typage des propriétésd’une ressource et des paramètres d’un service.

FIG. 3.13:Extrait du DSML RTEPML : les éléments typés.


3.2.4 Les types de données

L’analogie entre type et ressource nous conduit à la considération destypes de don-nées natifs à une plate-forme d’exécution. Les types de données définissent les genres decontenu des données et donc l’interprétation qui est faite de ces données sur une plate-formed’exécution [111]. Dans le but de renseigner les types de données natifs à une plate-forme,RTEPML intègre ce concept comme une ressource de la plate-forme (figure 3.14).

Les types retenus pour le langage sont issus des types de base qui peuvent être traitésdirectement par les processeurs (tels que les booléens, les caractères, les entiers et les réelsà virgule flottante). La taille (ou format de stockage mémoire) de chacun de ces types estrenseignée dans un attribut (size) dont l’unité est le bit. Les caractères (Char) et les entiers(Integer) peuvent de plus être signés ou non-signés.

Le typeStringest également fourni par le langage pour l’expression de chaînes de ca-ractères. D’autres types de données pourraient éventuellement être considérés, tels que destypes énumérés ou composés. Cette version du langage se contente de l’approche la plussimple que nous ayons identifiée.

FIG. 3.14:Extrait du DSML RTEPML : les types de données.

3.2.5 Les instances de ressources

Outre les concepts de ressource, de propriété et de service, le motif ressource/service,sur lequel s’appuie SRM, inclut également la notion d’instance de ressource. Dans RTEPML,la représentation d’instances de ressources prédéfinies dans une plate-forme d’exécutions’appuie sur cette notion (figure 3.15).

L’introduction dans le métamodèle d’un concept abstrait d’instance de ressource anti-cipe l’utilisation de ce concept au delà du cadre des instances prédéfiniesdans une plate-forme. La notion d’instance de ressource est, par exemple, également miseà contributionpour exprimer des prototypes de conception et pour intégrer des applications aux plates-formes. Ces concepts seront présentés dans la suite de ce rapport.

FIG. 3.15:Extrait du DSML RTEPML : les instances de ressources prédéfinies dans une plate-forme.


Remarque : Les concepts de ressource et d’instance de ressource s’apparentent ici auxnotions de type et d’élément typé. La relation entre une instance et la ressource qui latype diffère de la relation d’instanciation de l’espace technique orienté-objet. Dans le cadreorienté-objet cette relation est une incarnation de la notion de conformité de l’espace tech-nique des modèles (un objet est conforme à sa classe) [15]. Cette analogie fonde la miseen œuvre deframeworkde modélisation en langage objet. Les modeleurs actuels, tels queceux basés sur leframework EMF, associent par exemple l’opération de création des élé-ments d’un modèle à une opération d’instanciation des concepts du métamodèle auquel il seconforme. Dans RTEPML la notion d’instance de ressource est interne à l’espace techniquedes modèles. Une instance de ressource est une entité de la plate-forme utilisable en tantque telle par une application (au sens de Atkinson et Kühne [5]).

Le renseignement des propriétés

RTEPML précise la notion d’instance de ressource pour pouvoir exprimer les valeurs despropriétés associées aux ressources qui les typent (figure 3.16). Pour cela, les instances deressources possèdent des propriétés (ResourceInstanceProperty) qui renseignent ces valeurssous forme d’un littéral (pour les types de données natifs à la plate-forme)ou sous formed’une référence vers une instance de ressource.

FIG. 3.16:Extrait du DSML RTEPML : les instances de ressources et leurs propriétés.

Les appels de services

RTEPML précise également la notion d’instance de ressource pour pouvoir modéliserdes appels de services (figure 3.17). Pour cela, une instance de ressource peut faire appelà des services paramétrés (CallService). Les paramètres (CallParameter) sont fournis sousforme de littéraux (pour les types de données natifs à la plate-forme) ou sous forme deréférences vers des instances de ressources. Les paramètres d’un appel sont associés auxparamètres du service appelé.

FIG. 3.17:Extrait du DSML RTEPML : les instances de ressources et les appels de services.


L’utilisation de cette représentation des appels de services sera mise en avant dans lechapitre suivant, consacré à l’intégration d’une application dans une plate-forme (cette in-tégration s’appuie également sur le concept d’instance de ressource). La modélisation d’unappel de service reste néanmoins accessible au travers de toute représentation d’instance deressource, y compris celles qui sont prédéfinies dans une plate-formed’exécution.

Remarque : Le choix d’une représentation des appels de services accessibles à touteinstance de ressource est motivé par une volonté d’uniformisation du langage autour desconcepts de ressource, de service et d’instance de ressource. Eneffet, les appels de servicessont principalement mis à contribution dans des routines (le concepts de routine est intro-duit, dans la partie suivante, en tant que ressource d’une plate-forme). Mais, une prise encompte des appels de service restreinte à ce type de ressource aurait contraint le langageà considérer les instances de routine différemment des autres instances de ressources. Pouréviter cette différenciation, nous avons préféré introduire les appels deservice au niveau desinstances de ressources.

3.2.6 Les routines et les points d’entrée

Comme cela vient d’être mentionné, la notion de routine est introduite dans RTEPML entant que ressource d’une plate-forme d’exécution (figure 3.18). Ce type de ressource offreun ou des services d’appel permettant d’invoquer les routines (callRoutineServices) .

Cependant, contrairement à la modélisation proposée par SRM, dans RTEPML un pointd’entrée d’une ressource d’exécution n’est pas une relation directeentre une ressourced’exécution et un traitement fourni sous forme de routine. Le rôle de point d’entrée estici affecté à une propriété dont le type renseigne le traitement. Ce traitement peut alorscorrespondre à une routine.

FIG. 3.18:Extrait du DSML RTEPML : les routines et les points d’entrée.

La représentation des points d’entrée d’une ressource concurrenteest permissive dansRTEPML. En effet, toute ressource peut, en pratique, représenter un traitementassocié à unpoint d’entrée. Toutefois, cette permissivité peut être limitée par l’expression de contraintessur le métamodèle (par exemple des contraintes OCL).

Le choix d’une représentation des points d’entrée sous forme de propriétés trouve sonorigine dans l’utilisation qui est faite des ressources d’une plate-forme.En effet, l’utilisa-tion des ressources se fait au travers des instances de ressources,pour lesquelles les valeursdes propriétés peuvent être renseignées. Cependant, l’utilisation d’une relation directe entredeux ressources ne permet pas de renseigner ces valeurs au niveau des instances. Pour celaun mécanisme similaire à celui mis en place pour les propriétés devrait être instauré. Pourpermettre aux instances des ressources concurrentes de renseignerleurs points d’entrée sansintroduire de mécanisme supplémentaire, nous avons choisi de nous appuyer sur le méca-nisme de renseignement des valeurs des propriétés.


3.3 Artefacts de modélisation

Un DSML identifie, d’une part, les concepts d’un domaine, tels que ceux que nous ve-nons d’introduire dans la partie précédente, et fournit, d’autre part, des artefacts de modéli-sation utiles à la description des modèles.

Certains artefacts de modélisation sont propres à l’activité de modélisation. Ils se des-tinent, par exemple, à faciliter la modélisation ou l’utilisation des modèles. Par contre,d’autres artefacts sont liés au domaine considéré. Ils sont généralement nécessaires pourdécrire les systèmes du domaine.

Cette section introduit, dans une première sous-section, un concept d’héritage propre àl’activité de modélisation. Les sous-sections suivantes présentent des artefacts que nousavons jugés nécessaires à la modélisation des plates-formes d’exécution.Ces artefactsconcernent les services composés d’autres services et les prototypes de conception.

3.3.1 L’héritage de ressource

Parmi les artefacts de modélisation couramment employés, l’héritage consiste àfac-toriser les caractéristiques communes à plusieurs éléments modélisés. Cette pratique demodélisation autorise, par exemple, le polymorphisme.

Conjointement à cette notion, le concept d’abstraction permet de modéliser desélé-ments, qualifiés d’« abstraits », sans en autoriser la réalisation (ou l’instanciation).

Dans un soucis de confort de modélisation et de potentiel d’utilisation des modèles,RTEPML intègre des artefacts d’abstraction et d’héritage pour décrire les ressources d’uneplate-forme (figure 3.19). Une ressource peut être abstraite (isAbstract) et/ou hériter d’uneautre ressource (supertype).

FIG. 3.19:Extrait du DSML RTEPML : l’héritage de ressource.

Deux notions d’héritages sont distinguées en informatique : l’héritage de type (sub-typing) et l’héritage de classe (sub-classing) [23] [31].

L’héritage de type concerne les aspects sémantiques et impose une conformité des com-portements des éléments en relation de sous-typage. Hériter d’un type signifie supportertoutes les actions pouvant être effectuées sur les éléments de ce type. Tandis que l’héritagede classe est vu comme un mécanisme syntaxique destiné à la réutilisation de classes préa-lablement développées pour permettre une conception plus rapide de nouvelles classes. Cethéritage définit la notion d’enrichissement et d’extension des classes.

L’héritage introduit dans RTEPML est un héritage de classe. Il introduit un mécanismesyntaxique de modélisation, dans le but de réutiliser des ressources préalablement décrites.

La question de l’héritage de type ne sera pas abordée dans ce rapport.Comme cela futmentionné précédemment, les descriptions des comportements feront l’objet d’une étude àpart entière.

D’un point de vue pratique, l’héritage est transitif, les définitions des propriétés et desservices d’une ressource complètent les définitions des propriétés et des services des res-sources dont elle hérite.

3.3. Artefacts de modélisation 69

3.3.2 La composition de services

RTEPML introduit également la notion de composition de services. Cette notion cor-respond à la description du mécanisme interne d’un service par la compositiond’autresservices.

Le serviceChainTaskd’une tâche OSEK/VDX illustre l’intérêt d’une telle notion. Dansune séquence atomique, ce service active une tâche et termine l’exécutionde la tâche invo-catrice. Dans le respect du modèle de domaine de SRM, ce service se compose des servicesactivateServiceet terminateServiceofferts par une ressource ordonnançable (SwSchedula-bleResource, cf. Les ressources et les services de SRM, page 60).

Une modélisation possible de ce service consisterait à lui affecter les rôlesactivateSer-viceet terminateService. Cependant, contrairement à ce que stipule la norme OSEK/VDX,l’ordre d’exécution de l’activation et de la terminaison ne serait alors plusprécisé et l’ato-micité du service ne serait plus assuré.

Pour cela, il a été préféré de définir la notion de service composé, alors ordonné etatomique (figure 3.20).

FIG. 3.20:Extrait du DSML RTEPML : la composition de services.

Remarque : Les services qui composent un « service composé » n’étantpas restreints àce service, la composition de service se définit dans le métamodèle par une simple associa-tion (et non par une composition).

3.3.3 Prototypes de conception

Les ressources métiers qu’identifie RTEPML (issues de SRM, cf. Le modèle de domainedu packageSRM d’UML -MARTE, page 59) couvrent un ensemble de concepts que lesplates-formes d’exécution peuvent fournir sous la forme d’une ressource unique ou sousla forme d’un agencement de plusieurs ressources.

Une ressource unique (ou dédiée) se modélise conformément au concept qui lui corres-pond dans le langage. La description de la ressource « alarme » d’OSEK/VDX se conforme,par exemple, au concept d’alarme de RTEPML (cf. Les ressources et les services de SRM,page 60). Cependant, dans une plate-forme d’exécution, une ressource unique n’implantepas forcément chaque concept identifié. L’absence de ressource dédiée à un concept nesignifie pas pour autant que la plate-forme ne permet pas de le mettre en œuvre. Un agen-cement de ressources est parfois possible pour cela. Par exemple, OSEK/VDX ne fournitpas de ressource dédiée à l’exécution périodique d’un traitement. Une tâche périodiqueOSEK/VDX peut néanmoins se concrétiser par l’agencement d’une tâche, d’une alarme etd’un compteur. Un modèle de plate-forme d’exécution doit donc pouvoir décrire ce typede mise en œuvre « métier ». Pour cette raison, la notion de prototype de conception a étéintroduite dans RTEPML.

Décrire un agencement de ressources

Le terme de prototype fait référence au patron de conception éponyme (Design PatternPrototype) [48]. Ce patron de conception vise à faciliter la création d’instances complexes


en programmation objet. Plutôt que de créer plusieurs instances d’une classe, une premièreinstance est créée puis clonée. Les clones de l’instance sont modifiés defaçon appropriée.Un prototype sert de modèle pour la création de nouvelles copies.

Comme cela sera présenté dans le chapitre suivant, cette idée de clonage etd’adaptationsera reprise lors d’un déploiement d’application. Pour ce qui concerne la description desplates-formes d’exécution, l’idée principale est de modéliser un agencement de ressourcesqui met en œuvre un concept du domaine, identifié par RTEPML.

Un agencement d’instances de ressources

Pour décrire un prototype de conception, une première approche consiste à décrire unagencement de ressources, ou plus précisément de références vers des ressources. Cepen-dant, cette approche ne permet pas de préciser d’information sur ces ressources. Or, il peutêtre nécessaire de préciser, au sein d’un prototype, la valeur de certaines propriétés atten-dues pour ces ressources. Par exemple, un prototype qui décrit l’agencement d’une tâcheOSEK/VDX, d’une alarme et d’un compteur doit pouvoir spécifier que l’alarme est connec-tée au compteur via une propriété de l’alarme.

Une seconde approche consiste alors à décrire un agencement d’instances de ressourcestelles qu’elles seront mises en œuvre lors de l’utilisation de la plate-forme3. Toute précisionque l’on souhaite apporter sur les propriétés des ressources s’exprime alors directementsur les instances du prototype. Cette solution s’apparente à l’utilisation des diagrammesde collaboration ou des classes structurées qui décrivent également des instances mises enrelation, dans un contexte UML [114].

La figure 3.21 représente le mécanisme de description des prototypes de conceptionintroduit dans RTEPML.

FIG. 3.21:Extrait du DSML RTEPML : les prototypes de conception.

Un prototype se compose d’instances de ressources (PrototypeResourceInstance) dontl’une d’elles joue le rôle d’instance maîtresse. Toute référence à un élément mis en œuvrepar un prototype se réfère à l’instance du prototype qui a ce rôle d’instance maîtresse.

Les instances de ressources d’un prototype peuvent être typées pardes ressources dela plate-forme ou représenter des instances de ressources prédéfinies dans la plate-forme(match). Une instance « typée » représente une instance de la ressource qui latype. Uneinstance « associée » à une instance prédéfinie de la plate-forme représente cette instance.L’agencement des instances dans le prototype peut également être décrit par des associationsbinaires (PrototypeResourceInstanceAssociation).

3La mise en œuvre d’une ressource par instanciation sera détaillée dans lechapitre suivant

3.3. Artefacts de modélisation 71

Par héritage du concept abstrait d’instance de ressource (ResourceInstance), une ins-tance de ressource dans un prototype bénéficie du mécanisme d’affectation des valeurs auxpropriétés (cf. Les instances de ressources, page 65). Il est ainsi possible de fixer dans unprototype les valeurs de certaines propriétés des instances impliquées. Lemécanisme d’ap-pel de service est accessible de façon similaire.

La considération des instances de ressources d’un prototype de conception est différentede celle des instances de ressources prédéfinies dans la plate-forme ou, plus généralement,de toute instance qui « réalise » une ressource4 (cf. Les instances de ressources, page 65).Les instances de ressources d’un prototype ne sont pas des entités directement utilisables parune application, mais symbolisent des entités nécessaires à la mise en œuvre d’un concept.La mise en œuvre d’une tâche périodique OSEK/VDX nécessite, par exemple, une instanced’alarme. Cette instance d’alarme est bien entendu utilisable par l’application,mais elle estdifférente de l’instance de ressource dans le prototype, qui ne fait que la représenter.

D’un point de vue pratique, la description d’un prototype de conception,pour une res-source, surcharge les prototypes de conception des ressources dont elle hérite.

Distribution des rôles dans un prototype

L’utilisation d’un prototype de conception nécessite d’associer les rôles attendus pourles propriétés et les services d’un concept, aux propriétés et aux services des élémentsqui constituent le prototype. Dans l’exemple d’un prototype qui décrit l’agencementd’une tâche, d’une alarme et d’un compteur pour mettre en œuvre une tâche périodiqueOSEK/VDX, la tâche possède des propriétés dont les rôles correspondent, entre autres, à sapriorité et à sa période d’activation. Ces rôles doivent donc être reportés (ou distribués) surles propriétés des éléments du prototype.

RTEPML propose d’exprimer cette distribution par de nouveaux rôles attribués auxins-tances de ressources qui composent un prototype de conception. Pour cela, toute associationsymbolisant un rôle, à destination d’une propriété ou d’un service, est dupliquée en une as-sociation à destination d’un élément de prototype (PrototypeResourceInstance).

La figure 3.22 illustre ce principe pour le concept de ressource d’exécution concurrente.Dans cette extrait, les associationsprototypePriorityElementset prototypePeriodElementspermettent de transmettre les rôles de priorité et de période à des propriétésd’instances deressources d’un prototype. De même, les associationsprototypeActivateServicesetprototy-peSuspendServicespermettent de transmettre des rôles de service.

FIG. 3.22:Extrait du DSML RTEPML : exemple de distribution des rôles dans un prototype de conception.

L’interprétation des associations introduites est la suivante : une association prototy-peXElements(ou prototypeXServices), entre un concept et une instance de ressource dansun prototype, accorde le rôleX, du point de vue du concept mis en œuvre par le prototype,à la propriété (ou au service) dont le rôle est reconnu comme tel pour la ressource qui typel’instance. Un exemple de distribution des rôles est donné dans la section suivante.

4La notion d’instance de ressource dans une application est introduite dans le chapitre suivant.


3.4 Exemple d’utilisation

Le listing 3.1, page suivante, présente un extrait simplifié d’une descriptionde la plate-forme d’exécutionNXTOSEK [82] avec RTEPML. La plate-formeNXTOSEK implante unepartie du standard OSEK/VDX.

L’exemple proposé ne décrit pas la plate-forme dans son ensemble. Son objectif estd’illustrer l’utilisation du langage RTEPML que nous venons d’introduire.

Remarque : L’exemple de cette section s’appuie sur une syntaxe textuelle associée àRTEPML. Cette syntaxe nous semble suffisamment simple pour ne pas être plus détaillée.Une syntaxe concrète graphique sera introduite dans le chapitre suivant. Bien qu’indispen-sables à l’expression des modèles, les syntaxes concrètes ne font pasl’objet d’une attentionparticulière dans ce rapport. Celles-ci sont considérées interchangeables en fonction desbesoins et de la culture des utilisateurs. De plus, seule la syntaxe abstraite est réellementmise à contribution pour la considération explicite des plates-formes d’exécution dans leprocessus de déploiement que vise cette étude.

L’exemple du listing 3.1 modélise quatre concepts définis par le standard OSEK/VDX :les concepts de compteur (Counter), d’alarme (OsekAlarm), de tâche (Task) et de ressource(Resource). Un type entier codé sur 16 bits, prédéfini sur la plate-formeNXTOSEK, estégalement précisé (ligne 5).

Une ressourceCounterest modélisée conformément à un compteur RTEPML (Timer,ligne 8). Cette ressource possède une propriététicksPerBasede type entier. Le rôle de cettepropriété correspond à une opération de pré-division par rapport aux « tics » d’une source(par exemple, une horloge matérielle). AticksPerBaseimpulsions de la source correspondune impulsion d’avancement du compteur.

La plate-formeNXTOSEK fournit un compteur prédéfiniSysTimerCnt. Ce compteur estalors modélisé par une instance de la ressourceCounter(ligne 14). La valeur de la propriététicksPerBaseest fixée dans le respect des caractéristiques de la plate-forme.

Une ressourceOsekAlarmest décrite conformément à une alarme RTEPML (Alarm,ligne 20). Cette ressource possède une propriétécycletimede type entier. Le rôle de cettepropriété correspond au cycle de déclenchement de l’alarme (Period). Un compteur fournitune valeur de référence à une alarme OSEK/VDX. Une propriété de la ressource permetdonc de référencer ce compteur (counter).

Les activations et les exécutions d’une tâche OSEK/VDX étant gérées par un ordonnan-ceur, une tâche OSEK/VDX est identifiée comme une ressource ordonnançable (Shedulable-Resource). Tout type de tâche OSEK/VDX (AperiodicTask, PeriodicTask) est donc modéliséconformément à uneShedulableResource. Dans cet exemple, les concepts de tâches apério-diques et périodiques (lignes 37 et 42) héritent d’un concept abstraitde tâche pour lequelles propriétés et les services que précise le standard OSEK/VDX sont identifiés (ligne 27).

Une tâche possède, dans l’exemple, une priorité et une échéance (priority, deadline).Elle offre des services pour son activation et sa terminaison (ActivateTask, TerminateTask).

La périodicité d’une tâche OSEK/VDX (PeriodicTask) n’est pas gérée de façon transpa-rente par la plate-forme. Un prototype de conception modélise sa mise en œuvre (Prototype,ligne 43). Ce prototype décrit : (a) une instance de ressource typée par une tâche OSEK/VDX

(T1 de typeTask, dont le type d’activation n’est pas défini), (b) une instance de ressourcetypée par une alarme (A1 de typeOsekAlarm, dont le compteur de référence est précisé),(c) une référence vers l’instance de compteur prédéfinie sur la plate-formeNXTOSEK (C1qui référenceSysTimerCnt) et (d) une relation entre les instances de tâche et d’alarme (As-sociation). Finalement l’instance maîtresse du prototype est précisée (Master).

3.4. Exemple d’utilisation 73

1 -- RTEPML model of the NXT-OSEK platform2 Platform nxtOSEK {34 -- Integer native type5 IntegerType Integer [ 16 ]67 -- OSEK/VDX Counter resource8 Timer Counter (9 Property Duration ticksPerBase : Integer

10 ...11 )1213 -- NXT-OSEK SysTimerCnt predefined counter14 Counter SysTimerCnt (15 ticksPerBase = ’1’16 ...17 )1819 -- OSEK/VDX Alarm20 Alarm OsekAlarm (21 Property Period cycletime : Integer22 Property ConnectedTimer counter : Counter23 ...24 )2526 -- OSEK/VDX Task27 SchedulableResource Task [ preemptable ] abstract (28 Property Priority priority : Integer29 Property Deadline deadline : Integer30 ...31 Service Activate ActivateTask32 Service Terminate TerminateTask33 ...34 )3536 -- OSEK/VDX Aperiodic Task37 SchedulableResource AperiodicTask [ Aperiodic ] extends Task (38 ...39 )4041 -- OSEk/VDX Periodic Task42 SchedulableResource PeriodicTask [ Periodic ] extends Task (43 Prototype {44 Task T145 OsekAlarm A1 ( counter = C1 )46 Instance SysTimerCnt C147 Association A1 -[ activate ]- T148 Master T149 }50 -- Priority InPrototype T1 :: priority51 Priority InPrototype T152 -- Period InPrototype A1 :: cycletime53 Period InPrototype A154 ...55 )5657 -- Synchronization Resource58 MutualExclusion Resource [ ImediatePCP ] (59 Service Acquire GetResource60 Service Release ReleaseResource61 ...62 )6364 -- OSEK/VDX predefined resource for processor65 Resource RES_SCHEDULER (66 )67 }

Listing 3.1:Description de la plate-formeNXTOSEK avec RTEPML (extrait)


Les rôles des propriétés sont ensuite distribués dans le prototype. Le modèle spécifie,par exemple, que le rôle de priorité pour une tâche périodique revient à la propriété quipossède ce même rôle pour l’instance de tâche du prototype (T1 dans l’exemple, ligne 51).La priorité d’une tâche périodique est donc la priorité de la tâche activée périodiquement.En suivant ce même principe, la période d’une tâche périodique correspond à la période dedéclenchement de l’alarme qui active la tâche (ligne 53).

Remarque : L’utilisation des rôles à destination d’instance de ressource dans un proto-type peut être complétée par l’interprétation de rôles exprimés à destination des propriétésou des services (rôles initiaux, issus de SRM). Le modèle du listing 3.1 spécifie par exemple,dans des commentaires (lignes 50 et 52), les expressions équivalentes aux distributions desrôles qu’ils précèdent, en stipulant les propriétés visées. Ce mécanisme permet d’affecterun rôle, dans un prototype, à une propriété ou à un service pour lequelce rôle n’est pasidentifié à l’identique.

Enfin, une ressourceResource(au sens OSEK/VDX) est modélisée conformément à uneressource d’exclusion mutuelle RTEPML (MutualExclusion, ligne 58). Une ressource (ausens OSEK/VDX) permet de coordonner les accès concurrents. Elle offre des services pourprendre ou pour libérer la zone qu’elle protège (GetResourceetReleaseResource). Les accèssont régis par le protocole PCP que prévoit le standard (ImmediatPCP).

Le standard OSEK/VDX spécifie, en particulier, une ressource prédéfinie sur les plates-formes (RES_SHEDULER, ligne 65). Cette ressource symbolise le processeur. Toute tâche quila prend ne peut pas être préemptée.

3.5 Synthèse et résultats sur le langage proposé

Nous venons de présenter un langage dédié à la modélisation des plates-formes d’exé-cution du domaine du temps réel et de l’embarqué. Ce langage, présenté sous le nom deRTEPML, implante le modèle de domaine dupackageSRM du profil UML -MARTE. Ce mo-dèle de domaine, issu de travaux qui ont précédés cette étude, offre unensemble de conceptsmétiers pour la modélisation des plates-formes d’exécution temps réel embarquées.

A l’instar du modèle de domaine de SRM, RTEPML s’appuie sur le motif ressource/-service pour la description des ressources, des propriétés et des services offerts par uneplate-forme. La hiérarchie des ressources logicielles de RTEPML reprend celle de SRM.

En raison de la nature même d’un DSML, RTEPML définit toutefois des concepts supplé-mentaires, « externes » à SRM, nécessaires à la modélisation des plates-formes d’exécution.Ces concepts concernent les types de données natifs à la plate-forme etles instances deressources, au sein desquelles des propriétés et des appels de services peuvent être définis.Les routines et les points d’entrés ont également été précisés dans le langage.

Des artefacts de modélisation ont également été introduit dans le langage. Des méca-nismes d’héritage, de composition de services et d’expression de prototypes de conceptionsont ainsi disponibles.

La description de prototypes de conception repose sur un agencement d’instances deressources. Cette agencement décrit la mise en œuvre d’un concept avec des instances deressources typées par d’autres concepts. Dans cette version du langage, la mise en relationdes instances, au sein d’un prototype, peuvent s’appuyer sur les propriétés des instances oudes appels de services. Des associations binaires identifiées par un nomont également étéintroduites. Dans des versions plus élaborées, des cardinalités ou des nuances sémantiquesdans les types d’associations pourront être précisées. Ces versionsne seront pas abordées

3.5. Synthèse et résultats sur le langage proposé 75

dans ce rapport. Une étude doit encore être menée pour précisé la partiedu langage dédié àla description de prototype ou mettre en relation des langages existants.

Comme nous venons de l’évoquer, la version du langage RTEPML introduit dans ce cha-pitre n’est pas définitive. Néanmoins, des modèles de plates-formes ont été développés pourvalider les concepts retenus dans cette première version. La suite de cette section présenteles résultats issus de ces modélisations.

Résultats sur l’utilisation du modèle de domaine

Chacune des implantations du modèle de domaine (le profil UML du packageSRM etRTEPML) a été appliquée pour décrire les librairies OSEK/VDX et ARINC-653 (l’utilisationdupackageSRM a été évalué dans le cadre des travaux qui ont conduit à sa définition [114]).Dans le cadre du profil UML , les librairies ont d’abord été modélisées par des diagrammesde classes. Leurs éléments (classes, méthodes, attributs et relations) ontensuite été stéréo-typés par les concepts de SRM. Dans le cadre de cette étude, ces mêmes librairies ont étédécrites avec RTEPML.

Le profil UML et RTEPML ont ainsi permis de décrire 70% des ressources offertes parla plate-forme OSEK/VDX et 80% de celles offertes par la plate-forme ARINC-653. Cesrésultats sont dûs à la non-exhaustivité du modèle de domaine. En effet, des concepts liés àla gestion du temps, des modes de fonctionnement et des gestions d’erreurs ne sont actuel-lement pas pris en compte dans le modèle de domaine. Si nous excluons les ressources etservices des librairies directement liés à ces concepts absents du modèle du domaine, nousparvenons à une couverture exhaustive. Ce constat incite à valider la pertinence du modèlede domaine quant à son pouvoir d’expression. Afin d’obtenir une meilleure couverture, unenrichissement du modèle du domaine est toutefois à poursuivre.

Cet enrichissement pourrait se faire en s’appuyant sur différents modèles de domaine(ou leurs implantations dans un profil UML ou un DSML), chacun étant, par exemple, dédié àune considération donnée. Ainsi, dans UML -MARTE, unpackageest dédié aux mécanismesde temps. Cette pluralité permet notamment de réutiliser ces éléments dans d’autres profilsou dans d’autres DSML. La problématique de réutilisation de parties de métamodéles, quirejoint celle des bonnes pratiques d’écriture des métamodèles [32] reste toutefois à étudier.

Résultats sur l’implantation du modèle de domaine dans un DSML

Nous avons identifié deux grands types de différences dans l’implantation du modèle dedomaine entre l’approche par profil UML et par DSML.

Le premier type de différence vient de la nature même des DSML : tous les conceptset les artefacts de modélisation du langage doivent être définis. Par exemple, dans le cadred’une modélisation de plate-forme d’exécution, la description des types de données natifs àla plate-forme ou l’expression de prototypes de conception sont requis.Pour cela, dans uncontexte UML , la modélisation bénéficie de l’ensemble du langage, alors qu’un DSML sedoit d’offrir chacun de ces concepts. Cette différence est tout de mêmeà nuancer, il seraiten effet possible de réutiliser certains concepts ou certains artefacts présents dans d’autresDSML. La réutilisation de partie de métamodèle reste ici aussi à étudier.

Le second type de différence est plus en rapport avec le mécanisme d’extension parstéréotypage d’UML . Ce mécanisme permet en effet d’identifier un élément en lui appli-quant plusieurs stéréotypes. La relation de conformité, entre éléments et concepts définispar les stéréotypes, est alors multiple. L’identification des éléments avec un DSML reposepar contre sur une relation de conformité implantée actuellement, dans les outils tel qu’EMF,par la relation d’instanciation Java. La relation de conformité est alors simple.


La modélisation d’une partition ARINC-653 permet d’illustrer cette différence. Les par-titions ARINC-653 sont des unités de ségrégations spatiales (espaces mémoires distincts)et temporelles (partage d’une ressource processeur). Dans le respect du modèle de domaineinitial, une partition peut être identifiée via deux stéréotypes du profil UML . L’un pour l’as-pect temporel (tel queSchedulableResource), l’autre pour l’aspect spatial (tel queMemory-Partition qui décrit une partition mémoire). Parallèlement, la modélisation d’une partitionARINC-653, avec RTEPML, ne peut se conformer à l’équivalent de ces stéréotypes dans leDSML. Cette modélisation nécessite donc d’introduire dans le DSML, soit un concept mixtede partition mémoire ordonnançable, soit des notions de ségrégations temporelles au seindu concept de partition mémoire existant5.

Ces différences nous permettent de constater que la traduction du modèle dedomainedans un profil ou dans un DSML n’est pas facilement automatisables et ne fait pas systéma-tiquement appel aux mêmes règles. Des travaux complémentaires devront être menés pourmieux identifier ces différences.

5Cette deuxième solution a été privilégiée dans une seconde version du langage, succédant à celle qui a étéprésentée dans ce chapitre.

4Un processus de déploiement sur une

plate-forme explicitement décrite

Sommaire4.1 Intégration d’applications sur une plate-forme . . . . . . . . . . . . 794.2 Principe d’un déploiement . . . . . . . . . . . . . . . . . . . . . . . 80

4.2.1 Un cas simple de transformation de déploiement . . . . . .. . 804.2.2 Première synthèse . . . . . . . . . . . . . . . . . . . . . . . . 84

4.3 Transformations de déploiement . . . . . . . . . . . . . . . . . . . . 854.3.1 Affiner les critères sur les concepts . . . . . . . . . . . . . . .. 854.3.2 Relations de correspondance entre les concepts . . . . .. . . . 874.3.3 Mise à disposition de ressources par une plate-forme .. . . . . 904.3.4 Une mise en œuvre est-elle possible ? . . . . . . . . . . . . . . 914.3.5 Avec ou sans prototype de conception . . . . . . . . . . . . . . 934.3.6 Renseigner les propriétés . . . . . . . . . . . . . . . . . . . . . 974.3.7 Gestion des appels de services . . . . . . . . . . . . . . . . . . 105

4.4 Développement d’une transformation de déploiement . . .. . . . . 1104.4.1 Organisation d’une transformation de déploiement . .. . . . . 1104.4.2 Contraintes sur la technologie de transformation . . .. . . . . 1134.4.3 Génération des règles de déploiement . . . . . . . . . . . . . .1144.4.4 Assistance au développement des fonctions . . . . . . . . .. . 117

4.5 Choix de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . 1184.5.1 Identification des choix . . . . . . . . . . . . . . . . . . . . . . 1184.5.2 Prise de décision . . . . . . . . . . . . . . . . . . . . . . . . . 1194.5.3 Modélisation des décisions . . . . . . . . . . . . . . . . . . . . 120

4.6 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Ce chapitre propose un processus de déploiement d’applications sur desplates-formesd’exécution explicitement décrites. Le processus proposé se concrétise par des trans-

formations de modèles qui prennent comme paramètres des modèles d’applications et desmodèles de plates-formes décrits avec RTEPML.

Ce chapitre s’organise en six sections. Les deux premières introduisentsuccessivementle principe d’une intégration d’application dans une plate-forme d’exécution et le principed’un déploiement basé sur cette intégration. La troisième section présente ensuite un algo-rithme de transformation de déploiement. Puis, la quatrième section propose un processuspour le développement d’une telle transformation. Enfin, la cinquième sectionadapte le pro-cessus pour intégrer des décisions relatives à des choix de déploiement.La dernière sectionconclue sur le processus de déploiement proposé.

4.1. Intégration d’applications sur une plate-forme 79

4.1 Intégration d’applications sur une plate-forme

Dans le second chapitre de ce mémoire, consacré à l’état de l’art (page 24), plusieursapproches ont été identifiées pour mettre en œuvre un processus de déploiement d’applica-tions. En particulier, parmi les approches qui s’articulent autour d’unedescription explicitede plate-forme d’exécution (figure 2.17, page 31), celle qualifiée d’« intégration d’applica-tions » offre des perspectives de transformations de déploiement génériques. Pour confirmerce potentiel, ce chapitre propose d’approfondir cette approche avec lelangage RTEPML dé-fini dans le chapitre 3.

L’idée sous-jacente d’une « intégration d’applications » consiste à générer un modèlede la plate-forme enrichi des instances de ressources qui mettent en œuvre l’application.L’application est alors modélisée, ou intégrée dans le modèle de la plate-forme, au traversdes instances de ressources mises à contribution pour son exécution. Comme le modèlegénéré représente la plate-forme d’exécutionet l’utilisation qui est faite de ses ressourcespour exécuter l’application, le processus de déploiement aboutit à un modèle d’applicationspécifique à une plate-forme (ou PSM, Platform Specific Model) conforme au métamodèlede plate-forme d’exécution (figure 4.1).

FIG. 4.1:Approche proposée pour le déploiement d’une application sur une plate-forme d’exécution.

La mise en œuvre de cette approche nécessite un mécanisme d’intégration d’applica-tions dans le métamodèle de plate-forme d’exécution. Comme cela vient d’être évoqué, cemécanisme repose sur le principe d’instanciation des ressources d’une plate-forme. Aucunconcept métier propre à l’application n’a donc besoin d’être introduit dans le métamodèle.

La figure 4.2 illustre le mécanisme d’intégration d’applications implanté dans RTEPML.Ce mécanisme repose sur le concept d’instance de ressource présentédans le chapitre pré-cédent. Les instances de ressources introduites dans le métamodèle (ApplicationResour-ceInstance) sont les instances mises à contribution pour exécuter l’application. Un conceptd’association accompagne ces instances (ResourceInstanceAssociation), pour les mettre enrelation, entre elles ou avec des instances de ressources prédéfinies sur une plate-forme.

FIG. 4.2:Extrait du DSML RTEPML : intégration d’une application sur la plate-forme.

80 Chapitre 4. Un processus de déploiement sur une plate-forme explicitement décrite

4.2 Principe d’un déploiement

4.2.1 Un cas simple de transformation de déploiement

La figure 4.3 illustre le principe d’un déploiement par « intégration d’application » avecle cas le plus simple que nous pouvons rencontrer. Dans cet exemple, uneapplication derobotique constituée d’une seuleactivité est déployée par transformation de modèle surune plate-forme OSEK/VDX. Cette plate-forme est explicitement décrite avec RTEPML. Lesmodèles de l’application (PIM ) et de la plate-forme (PDM) sont alors transformés en unmodèle de système spécifique à la plate-forme (PSM). Le modèle résultant correspond à laplate-forme d’exécution cible dont certaines ressources sont instanciées en vue d’exécuterl’application. Dans cet exemple, une tâche OSEK/VDX de priorité2 (nomméeHelloWorld)est instanciée pour offrir un contexte d’exécution sur la plate-forme.

FIG. 4.3:Déploiement d’une application de robotique sur une plate-forme OSEK/VDX.

La transformation de déploiementRobot2RTEPML de la figure 4.3 établit la correspon-dance entre les éléments des modèles sources (PIM et PDM) et les éléments du modèlecible (PSM). Pour cela, une partie de la transformation consiste à dupliquer le modèle dela plate-forme d’exécution. Une autre partie traite des correspondancesentre les élémentsdu modèle de l’application et les instances de ressources de la plate-forme d’exécution. Parexemple, la règle ATL Activity2SchedulableResourceInstance, du listing 4.1, stipule quetout élément conforme à uneactivité, dans le modèle de l’application, est transformé en unélément conforme à une instance de ressource ordonnançable RTEPML.

1 rule Activity2SchedulableResourceInstance {2 from s : ROBOT!Activity3 to4 t : RTEPML!ApplicationResourceInstance (5 name <- s.name,6 type <- getResource(RTEPML!SchedulableResource),7 properties <- Sequence{priority, stacksize}8 ),9 priority : RTEPML!ResourceInstanceProperty (

10 val <- s.getValue(’Priority’),11 property <- t.type.getProperty(’Priority’)12 ),13 stacksize : RTEPML!ResourceInstanceProperty (14 val <- s.getValue(’StackSize’),15 property <- t.type.getProperty(’StackSize’)16 )17 }

Listing 4.1:Transformation de déploiement Robot2RTEPML (cas simple, en ATL)

4.2. Principe d’un déploiement 81

Au sein des règles de transformation (ou règles de déploiement), les instances de res-sources générées sont associées aux ressources de la plate-formequi les typent. La ligne 6du listing 4.1 déclare, par exemple, que la ressource qui type l’instance générée est conformeà uneSchedulableResource. L’instance générée sera donc associée à l’élément de la plate-forme qui se conforme à ce concept. Comme l’illustre la figure 4.3 l’instance detâcheHelloWorld est ainsi associée à la ressourceTask(ce qui se matérialise par une flèche enpointillé, suivant la convention graphique adoptée).

De même, les valeurs de propriétés affectées à une instance de ressource sont associéesaux propriétés de la ressource qui type l’instance. La ligne 11 du listing 4.1précise, parexemple, que la valeur affectée se réfère à la propriété dont le rôle concerne lapriorité.La valeur2 de l’instance de tâcheHelloWorld, dans la figure 4.3, est ainsi associée à lapropriétépriority de la ressourceTask(ce qui se matérialise également par une flèche enpointillé, suivant la convention graphique adoptée).

Pour des raisons didactiques, le listing de l’exemple ne comporte pas tout le code dela transformation. La partie chargée de dupliquer le modèle de la plate-forme n’est, parexemple, pas présentée. Sa mise en œuvre peut être assurée par une fonctionnalité intégréedans la technologie de transformation ou, comme nous allons l’aborder, parun ensemble derègles de transformation1.

Dans la suite de ce rapport, nous nous efforcerons d’abstraire les principes de trans-formation de toute technologie de transformation.Toutefois, pour mieux cerner la mise enpratique de ces principes, une implantation en ATL sera également disponible en annexe.

Le principe de mise en œuvre de la transformation de déploiement que nous venonsd’introduire peut se résumer par l’algorithme 4.1.

Algorithme 4.1 :Principe d’une transformation de déploiement

Métamodèles sources:MMa : le métamodèle de l’applicationMMp : le métamodèle de plate-forme d’exécution(RTEPML)

Métamodèle cible:MMp : le métamodèle de plate-forme d’exécution(RTEPML)

début// Dupliquer le modèle de la plate-formepour chaqueclassemp ∈MMp faire

correspondance avecmp // (identité)

// Intégrer l’applicationpour chaqueclassema ∈MMa faire

ruleConcept2ResourceInstance(ma,mp)avec une classemp ∈MMp

fin

L’algorithme 4.1 se déroule en deux phases. La première consiste à dupliquer le modèlede la plate-forme cible. Elle se compose de règles qui mettent en correspondance les classesdu métamodèle de plate-forme d’exécution avec elles-mêmes (identité). La seconde faitcorrespondre chaque concept « applicatif » avec un concept « exécutif ». Ces concepts sontrespectivement identifiés par une classema dans le métamodèle de l’application et uneclassemp dans le métamodèle de plate-forme d’exécution (RTEPML).

1Si la technologie de transformation permet de modifier un modèle passé en paramètre, l’application peutégalement être intégrée dans le modèle de la plate-forme sans que ce dernier soit dupliqué.


Les correspondances de la seconde phase sont exprimées au travers d’une règle detransformationruleConcept2ResourceInstance(également qualifiée de règle de correspon-dance). L’algorithme 4.2 en donne le principe.

Une règleruleConcept2ResourceInstanceprend comme paramètres un concept appli-catif et le concept exécutif mis en correspondance (respectivement identifiés par les classesma et mp). Pour chaque élément du modèle de l’application conforme àma, cette règlegénère alors une instance de ressource (ApplicationResourceInstance) typée par une res-source de la plate-forme conforme àmp. La classema constitue le « concept source » (oula « classe source ») de la règle2.

Les propriétés associées à la ressource qui type l’instance sont également renseignéesau sein de la règle. Pour cela, une propriété d’instance de ressource (ResourceInstance-Property) est générée pour chaque propriété associée à la classemp (les propriétés sontidentifiées par le rôle qui leur est attribué).

Algorithme 4.2 :Règle de correspondance (ruleConcept2ResourceInstance)



Concept source:ma : une classe deMMa

Concept impliqué :mp : une classe deMMp

Notation :propertyRoles(mp) : l’ensemble des rôles attribués aux propriétés demp

début// Générer une instance de ressource typée par une ressourceconforme àmp

correspondance avecApplicationResourceInstance∈ RTEPMLtype← getResource(mp)Renseigner les propriétés

// Générer les propriétés de l’instancepour chaquerôle r ∈ propertyRoles(mp) faire

correspondance avecResourceInstanceProperty∈ RTEPMLval← getValue(ma, r)property ← getProperty(type, r)

fin

Dans un contexte déclaratif, la règleActivity2SchedulableResourceInstanceintroduitedans le listing 4.1, page 80, offre un exemple d’implantation de l’algorithme 4.2. Dans cetexemple, les conceptsActivity et SchedulableResourcecorrespondent respectivement auxparamètresma etmp de l’algorithme 4.2. Les propriétés renseignées, au sein de la règle,concernent la priorité et la taille de la pile d’une ressource ordonnançable (respectivementidentifiés par les rôlesPriority etStackSize).

2Le « concept source » d’une règle de transformation correspond auconcept auquel se conforme les élémentstransformés par la règle. Dans un contexte déclaratif, chaque élémentconforme au concept source déclenche,par exemple, l’application de la règle. Ce concept sera à nouveau abordé dans ce chapitre, lorsque nous aborde-rons le cas des relations N-M entre concepts applicatif et concepts exécutif.

4.2. Principe d’un déploiement 83

L’algorithme 4.2, que nous venons d’introduire, s’appuie sur une fonction getResourcepour localiser, dans la plate-forme cible, la ressource qui type l’instanceà générer (cettefonction se matérialise par unhelperéponyme dans l’exemple du listing 4.1, ligne 6).

Cette fonction identifie une ressource via sa relation de conformité avec un concept deRTEPML. Son principe est précisé dans l’algorithme 4.3.

Algorithme 4.3 :Localisation d’une ressource (getResource)

Entrée :mp : une classe deRTEPML

Modèle impliqué :Mp : un modèle de plate-forme d’exécution conforme àRTEPML

Résultat :rp : une ressource deMp conforme àmp

débutretourner rp ∈Mp tel querpχmp

fin

En suivant le même principe, l’algorithme 4.2 s’appuie sur une fonctiongetPropertypour localiser les propriétés à renseigner (cette fonction se matérialise parun helperépo-nyme dans l’exemple du listing 4.1, ligne 15). Pour une ressource de la plate-forme cible(type, retournée par la fonctiongetResourcedans l’algorithme 4.2), cette fonction identifieles propriétés à renseigner par leur rôle.

Le principe de la fonctiongetPropertyest précisé dans l’algorithme 4.4.

Algorithme 4.4 :Localisation d’une propriété dans la plate-forme (getProperty)

Entrées:rp : une ressource de la plate-forme d’exécutionrole : un rôle attribué à une propriété identifiée parRTEPML

Résultat :une propriété derp dont le rôle correspond àrole

débutretourner rp.role

fin

Enfin, dans l’algorithme 4.2, les traductions et les affectations des valeursdes propriétéssont assurées par la fonctiongetValue(cette fonction se matérialise par unhelperéponymedans l’exemple du listing 4.1, ligne 14). A l’image de la fonctiongetPropertyque nousvenons d’introduire, la fonctiongetValueidentifie les propriétés par leur rôle.

Les implantations des algorithmes 4.3 et 4.4, dans deshelpersATL, sont données enannexe pages 164 et 165.

Nous ne détaillerons pas les implantations possibles de la fonctiongetValuequi peuvent,par exemple, déduire les valeurs de retour par calcul (à partir des données disponibles dansle modèle source, comme le suggère l’algorithme présenté) ou retransmettre des valeurspassées en paramètres à la transformation (solution non abordée dans l’algorithme pré-senté). Nous considérerons pour l’instant que nous disposons d’une fonction qui retourneune valeur appropriée pour renseigner une propriété dont le rôle estpassé en paramètre.


4.2.2 Première synthèse

Le principe de déploiement que nous venons d’introduire se matérialise pardes trans-formations uniquement basées sur les concepts du métamodèle source et dumétamodèle deplate-forme d’exécution. Aucun concept propre à une plate-forme donnée n’intervient doncdans celles-ci. Les transformations implantent, d’autre part, un mécanisme d’instanciationdes ressources générique à toutes les plates-formes. Une application est mise en œuvre vial’utilisation qu’elle fait des ressources d’une plate-forme. Sur ces points, ces transforma-tions sont par conséquent indépendantes des plates-formes cibles. Laconsidération d’uneplate-forme se résume à son modèle transmis comme paramètre à une transformation.

Le renseignement des valeurs des propriétés se réfère toutefois à desfonctions (ouhel-pers) dépendantes de la technologie source et de la plate-forme cible. La fonction getValue,introduite précédemment, extrait par exemple des valeurs du modèle source pour les conver-tir en valeurs adaptées à la plate-forme cible. Une transformation de déploiement, dans sonensemble, se compose donc d’un noyau générique complété par des bibliothèques de tra-ductions des valeurs des propriétés (figure 4.4).

FIG. 4.4:Principe de déploiement d’une application via RTEPML.

Pour ce qui concerne le noyau générique de la transformation, la solutionque nousvenons de présenter se situe toutefois dans un contexte simplifié, dans lequel :

1. Les règles de déploiement portent sur des concepts identifiés par desnoms de classes,sans nuances sur leurs attributs ou leurs relations avec d’autres classes ;

2. Chaque mécanisme de l’application est mis en œuvre avec un unique concept exécutifidentifié par RTEPML ;

3. La plate-forme d’exécution envisagée offre une et une seule ressource conforme à unconcept identifié par RTEPML.

Dans ce contexte, chaque règle de déploiement exprime alors une correspondance entreune classe du métamodèle de l’application et une classe du métamodèle de plate-formed’exécution (RTEPML). Ces classes (incarnées parma et mp dans les algorithmes 4.1 et4.2), identifient respectivement un concept applicatif et un concept exécutif3. Les relationsenvisagées entre les concepts sont alors uniquement 1-1. Elles se restreignent de plus auxconcepts identifiés par les noms des classes, sans aucune autre distinctionpossible.

3Dans l’algorithme proposé la correspondance avec un concept exécutif se fait au travers de la ressource quitype l’instance générée.

4.3. Transformations de déploiement 85

Dans un contexte plus réaliste, des précisions sur les concepts impliqués dans les trans-formations et d’autres types de relations entre ces concepts doivent être considérés.

Ainsi, le principe d’un déploiement par « intégration d’applications » montre une ca-pacité de généricité qu’il est nécessaire de confirmer pour l’ensemble des déploiementsenvisageables. Pour cela, la section suivante aborde, dans un premiertemps, les précisionsqu’il est possible d’apporter sur les concepts mis à contribution dans les transformations, enplus des noms des classes qui les identifient. Puis elle cerne, dans un second temps, les typesde relations que les transformations de déploiement sont susceptibles d’implanter, avant dedétailler leur mise en œuvre.

4.3 Transformations de déploiement

4.3.1 Affiner les critères sur les concepts

Comme cela vient d’être évoqué, les règles de déploiement envisagées jusqu’à présentmettent en correspondance des concepts identifiés par des noms de classes dans les métamo-dèles. Or, ces concepts peuvent être précisés, au sein même des classes, via leurs attributsou via leurs associations avec d’autres concepts.

Le concept de ressource ordonnançable illustre ce principe. En effet, RTEPML identifieune ressource ordonnançable via la classeSchedulableResource. RTEPML distingue toute-fois plusieurs catégories de ressources ordonnançables : périodique, apériodique ou spora-dique. Comme l’illustre la figure 3.3, page 60, ces catégories sont elles-mêmesidentifiéespar un attribut (type) de la classeSchedulableResource. Différents concepts de ressourcesordonnançables (périodique, apériodique ou sporadique) se déclinent alors du concept ini-tial, en fonction de la valeur de cet attribut.

Cependant, les correspondances entre concepts applicatif et concepts exécutif, envi-sagées dans les algorithmes 4.1, 4.2 et 4.3, ne prennent pas en compte cesdéclinaisonsde concepts. Pour cela, les règles de correspondances (ruleConcept2ResourceInstance) etla fonction de localisation de ressources (getResource) devraient pouvoir distinguer lesconcepts au delà de ce qu’identifient les noms des classes.

Dans cet objectif, les algorithmes 4.5, 4.6 et 4.7, page suivante, enrichissent les algo-rithmes précédents de critères sur les classes (le symbole➤ localise les modifications ap-portées4). Ces critères permettent de préciser (ou de catégoriser) les conceptsqu’identifientles classes.

En pratique, un tel critère (que l’on peut qualifier de critère de « précision » ou de « ca-tégorisation ») s’exprime sous la forme d’un prédicat. Par exemple, le concept de ressourceordonnançable périodique est une association du concept de ressource ordonnançable (iden-tifié par la classeSchedulableResourcedans RTEPML) et d’un prédicatisPeriodic(tel que,∀rpχShedulableResource, rpisPeriodic ⇐⇒ rp.type = periodic).

Deux types de critères interviennent alors dans les algorithmes 4.5, 4.6 et 4.7. Le pre-mier,ϕma , permet de préciser un concept applicatif identifié par une classema du métamo-dèle de l’application. Le second,ψmp , permet de préciser un concept exécutif identifié parune classemp du métamodèle de plate-forme d’exécution (RTEPML).

Remarque : Une absence de critère signifie que le concept concerné est celui qu’identifie« directement » la classe.

4La partie de l’algorithme 4.1 qui concerne la duplication du modèle de la plate-forme cible n’a pas étéretranscrite dans l’algorithme 4.5, cette partie n’étant pas concernée par les critères associés aux concepts.De même, la partie de l’algorithme 4.2 qui concerne la génération des propriétés n’a pas été retranscrite dansl’algorithme 4.6. La gestion des propriétés sera abordée en détail dansla suite de ce chapitre.


Algorithme 4.5 :Principe d’une transformation de déploiement (➤concept/critère)



Notations :➤ γa : un concept(ma, ϕma

) tel quema ∈MMa etϕmaprécisema

➤ γp[γa] : un concept(mp, ψmp) relatif àγa tel quemp ∈MMp etψmp

précisemp

début// Dupliquer le modèle de la plate-forme...// Intégrer l’application

➤ pour chaqueconceptγa faire➤ ruleConcept2ResourceInstance(γa, γp[γa])

fin

Algorithme 4.6 :Règle de correspondance (ruleConcept2ResourceInstance) (➤concept/critère)



Concept source:➤ γa : un concept(ma, ϕma


Concept impliqué :➤ γp : un concept(mp, ψmp

) tel quemp ∈MMp etψmpprécisemp

début// Générer une instance de ressource typée par une ressourceconforme àγp

correspondance avecApplicationResourceInstance∈ RTEPML➤ type← getResource(γp)

Renseigner les propriétés

// Générer les propriétés de l’instance...

fin

Algorithme 4.7 :Localisation d’une ressource (getResource) (➤concept/critère)

Entrée :➤ γp : un concept(mp, ψmp

) tel quemp ∈RTEPML etψmpprécisemp

Modèle impliqué :Mp : un modèle de plate-forme d’exécution conforme àRTEPML

Résultat :➤ rp : une ressource deMp conforme àmp, dans le respect deψmp

début➤ retourner rp ∈Mp tel querpχmp et rpψmp

fin


4.3.2 Relations de correspondance entre les concepts

Le second point qu’aborde cette section concerne les relations de correspondance sus-ceptibles d’être mises en œuvre entre les concepts applicatif et les conceptsexécutif5.

Par essence, une transformation de modèle met en relation un ou plusieurs conceptssourcesavec un ou plusieurs conceptscibles. Les relations implantées dans une transforma-tion peuvent donc être de types 1-1, 1-N, N-1 ou N-M, selon qu’un ou plusieurs conceptssources ou cibles sont impliqués par la correspondance.

Dans cette étude, les relations de correspondances expriment les mises enœuvre demécanismes applicatif avec des ressources que sontsusceptiblesde fournir les supportsd’exécution. Nous nous intéressons donc, dans un premier temps, aux relations entre lesconcepts d’un métamodèle d’application et ceux du métamodèle de plate-forme d’exécution(RTEPML). La figure 4.5 illustre ces relations6. Les mises à disposition, par les plates-formesd’exécution, de ressources conformes aux concepts impliqués dans lestransformations se-ront abordées dans la sous-section suivante.

FIG. 4.5:Relations identifiées entre les concepts applicatif et exécutif.

Relation 1-0 : Une relation 1-0 révèle l’absence de concept exécutif pour traduire unconcept applicatif. Dans le contexte de cette étude, deux cas peuvent alors se présenter, selonque le concept applicatif présente ou non un intérêt pour le déploiement d’une application.

Dans le premier cas, l’absence de correspondance révèle un problèmede déploiement.Aucun concept du domaine des plates-formes d’exécution ne permet alors de mettre enœuvre un mécanisme de l’application. Un tel constat nécessite d’enrichir le métamodèle deplate-forme d’exécution.

Dans le second cas, certains éléments du modèle source ne sont pas jugésutiles aumodèle de l’application déployée (par exemple, des informations nécessaires à des outils

5Que ces concepts soient ou non précisés par des critères.6Une règle (Rule) de la formeCx2RxInstance exprime une correspondance entre un conceptCx du mé-

tamodèle source et un conceptRx de RTEPML (RxI est une instance de ressource typée parRx).


d’analyse ou de gestion de version). Les concepts auxquels se conforment ces éléments neseront donc pas traduits en concepts exécutif.

Trois stratégies sont alors envisageables face à une relation 1-0. La première consiste àignorer silencieusement les éléments qui ne sont pas pris en charge par latransformation.Seuls les éléments conformes à des concepts explicitement gérés par les règles sont traités.Cette stratégie place toute sa confiance dans la transformation. Elle n’offreaucun supportpour valider la sélection des éléments ignorés.

La seconde stratégie repose sur des mécanismes fournis par les technologies de trans-formation. Une alerte peut, par exemple, être levée pour tout élément non-transformé. Mais,cette stratégie présume que la technologie de transformation offre un tel service. De plus,la gestion d’une alerte est alors dépendante de cette technologie (une interaction peut, parexemple, être possible durant l’exécution d’une transformation).

Enfin, la troisième stratégie consiste à déclarer une règle de correspondance pour chaqueconcept du métamodèle source. Par défaut, une règle génère, par exemple, un élément dansun modèle de trace (indépendant du métamodèle de plate-forme d’exécution). Les règlesdont les concepts sources sont utiles au déploiement de l’application sontensuite rempla-cées ou complétées par des règles de mise en correspondance avec desconcepts exécutif.

Cette troisième approche offre un support pour valider la sélection des concepts non-traités. Elle présente de plus l’avantage d’être indépendante de la technologie de transfor-mation. L’algorithme 4.8 illustre l’introduction d’un tel mécanisme.

Algorithme 4.8 :Principe d’une transformation de déploiement (➤relations 1-0)


Métamodèles cibles:MMp : le métamodèle de plate-forme d’exécution(RTEPML)

➤ MMt : un métamodèle de trace(non précisé dans cette étude)

Notations :➤ Γa : l’ensemble{(ma, ϕma

)|ma ∈MMa etϕmaprécisema} utile au déploiement

γp[γa] : un couple(mp, ψmp) relatif àγa ∈ Γa tel quemp ∈MMp etψmp

précisemp

début// Dupliquer le modèle de la plate-forme...// Intégrer l’application

➤ pour chaqueγa ∈ Γa faireruleConcept2ResourceInstance(γa, γp[γa])

// Tracer les éléments non mis à contribution➤ pour chaqueγa ∈ ∁Γa faire➤ traceUnusedConcept(γa)

fin

L’algorithme 4.8 répartit les concepts entre deux types de règles, selon qu’ils présententou non un intérêt pour le déploiement de l’application. En particulier, ceux qui ne présententpas d’intérêt sont mis en relation avec des concepts d’un métamodèle de trace (traceUnu-sedConcept). Toutefois, dans la suite de ce rapport, nous ne détaillerons ni ces misesenrelations (assurées par des règles de correspondances), ni les métamodèles de traces envisa-geables (qui identifient, par exemple, un concept pour chaque type de trace générée).


Relation 1-1 : Une relation 1-1 traduit un concept applicatif en un concept exécutif.La mise en œuvre d’un mécanisme de l’application ne nécessite alors qu’un seul conceptidentifié par le métamodèle de plate-forme d’exécution. Les algorithmes proposés jusqu’àprésent reposent sur des relations 1-1.

Relation 1-N : Une relation 1-N traduit un concept applicatif en plusieurs concepts exé-cutif. La mise en œuvre d’un mécanisme de l’application nécessite alors différents conceptsidentifiés par le métamodèle de plate-forme d’exécution.

L’implantation d’une relation 1-N dans une règle de correspondance suitle même prin-cipe que pour une relation 1-1, en impliquant toutefois plusieurs instances.L’algorithme 4.9définit ainsi la règleruleConcept2MultiResourceInstances, pour étendre le principe de larègleruleConcept2ResourceInstance7 aux relations 1-N.

Algorithme 4.9 :Règle de correspondance (ruleConcept2MultiResourceInstances)



Concept source:γa : un concept(ma, ϕma


Concepts impliqués:Γp : un ensemble{(mp, ψmp

)|mp ∈MMp etψmpprécisemp}

débutpour chaqueγp ∈ Γp faire

// Générer une instance de ressource typée par une ressourceconforme àγp

ruleConcept2ResourceInstance(γa, γp)

fin

La règleruleConcept2MultiResourceInstancesvise à générer plusieurs instances de res-sources à partir d’un unique concept source. Pour cela, elle encapsule la portion de l’algo-rithme responsable de la génération d’une instance (ruleConcept2ResourceInstance) dansune boucle qui détermine l’ensemble des instances à générer. Cet ensemble est lui-mêmedéduit de l’ensemble des concepts exécutif impliqués dans la correspondance (Γp).

Comme nous le verrons par la suite, la règleruleConcept2MultiResourceInstancespeutse substituer à la règleruleConcept2ResourceInstancedans l’algorithme 4.8 qui décrit leprincipe d’une transformation de déploiement (tel que dans l’algorithme 4.10, page 92).

Relations N-0, N-1 et N-M: Les relations N-x (où x = 0, 1 ou M) impliquent plusieursconcepts applicatif. Les relations N-1 et N-M visent, par exemple, à mettre enœuvre unmécanisme de l’application, dans lequel plusieurs concepts applicatif sont impliqués, avecun ou plusieurs concepts exécutif.

Actuellement, les technologies de transformations de modèles, tant déclaratives qu’im-pératives, implantent les relations N-x dans des règles de correspondances « attachées » àun concept source (à la manière des relations 1-1 ou 1-N). Ce concept,que l’on peut quali-fié de « principal », constitue le « point d’entrée » d’une règle. Dans un contexte déclaratif,seuls les éléments conformes au concept principal déclenchent, par exemple, l’application

7La règleruleConcept2ResourceInstanceest décrite par l’algorithme 4.6, page 86.


de la règle. Les accès aux autres concepts, impliqués dans le mécanisme à traduire, sontimplantés au sein de la règle, via les associations qui les « relient » à ce concept.

Au sein de l’algorithme proposé, tout accès à un concept différent du principal se ma-nifeste uniquement dans la fonctiongetValue. L’algorithme, tel qu’il est présenté, n’est pasimpacté. Cette version permet donc d’implanter des relations N-1 et N-M au mêmetitreque les relations 1-1 et 1-N. De même, le mécanisme introduit pour la considération desrelations 1-0 s’applique aux relations N-0.

4.3.3 Mise à disposition de ressources par une plate-forme

L’algorithme de déploiement que nous venons de présenter couvre l’ensemble des re-lations de correspondances identifiées entre les concepts applicatif et lesconcepts exécutif.In fine, ces concepts sont toutefois incarnés par des ressources que les plates-formes sontsusceptiblesde fournir. La généricité des transformations que nous voulons mettre en œuvrenécessite donc d’anticiper la mise à disposition, par les plates-formes d’exécution, de res-sources conformes aux concepts impliqués dans les transformations.

La figure 4.6 illustre les différentes mises à disposition de ressources envisageables (surla base de relations 1-1 entre concepts applicatif et concepts exécutif, la transposition auxrelations 1-N étant immédiate).

FIG. 4.6:Mise à disposition, par une plate-forme, de ressources conformes à des concepts de RTEPML.

Disponibilité 0 ou 1 : Les deux premières mises à dispositions envisagées, qualifiéesrespectivement de « disponibilité 0 » et « disponibilité 1 », distinguent l’absence ou la pré-sence, dans la plate-forme cible, d’une ressource conforme à un concept mis à contributiondans une règle de correspondance. Une « disponibilité 0 » ne permet pasde mettre en œuvreun mécanisme applicatif tel que la transformation le prévoit. Parallèlement, une « disponi-bilité 1 » offre une possibilité de mise en œuvre.

Disponibilité N : La troisième et dernière mise à disposition identifiée, qualifiée de« disponibilité N » dans la figure 4.6, concerne la présence, sur la plate-forme d’exécutioncible, de plusieurs ressources conformes à un même concept exécutif. Cette situation révèleun choix de mise en œuvre d’un mécanisme applicatif. Cette question sera traitéedansl’avant-dernière section de ce chapitre consacrée aux choix de déploiement.

La suite de cette section se focalise sur les deux premières disponibilités identifiées. Lasous-section suivante traite de l’absence, dans la plate-forme cible, de ressources conformesà un concept mis à contribution dans une règle (disponibilité 0).

Les sous-sections d’après traitent de la situation dans laquelle une ressource est dis-ponible (disponibilité 1). L’algorithme de déploiement sera alors étendu à la gestion des


prototypes de conception qui peuvent accompagner les descriptions des ressources (cf. Pro-totypes de conception, page 69). Nous détaillerons également les mécanismes introduitsdans l’algorithme pour renseigner les propriétés des instances de ressources et générer desappels de services.

4.3.4 Une mise en œuvre est-elle possible ?

Nous venons de distinguer deux situations majeures dans lesquelles une plate-formed’exécution dispose ou ne dispose pas d’une ressource conforme à un concept impliquédans une règle de déploiement (situations respectivement qualifiées de « disponibilité 1 »et de « disponibilité 0 »). Pour répondre à l’éventualité d’une indisponibilité de ressource,il convient donc d’enrichir la transformation d’un mécanisme de détection decette indis-ponibilité. Pour cela, dans la lignée des approches évoquées pour les relations 1-0 (entreconcepts applicatif et exécutif), plusieurs voies sont envisageables.

La première repose sur des fonctionnalités fournies par la technologie detransforma-tion. Celle-ci peut, par exemple, signaler automatiquement l’absence d’élément conformeà un concept impliqué dans une règle. La réaction face à cette éventualité etla gestion quis’ensuit dépendent alors entièrement des moyens mis à disposition par la technologie detransformation.

La seconde approche vise à implanter dans la transformation un mécanisme dedétec-tion d’indisponibilités indépendant de la technologie de transformation. Le principe d’untel mécanisme consiste à vérifier la présence de ressources conformes aux concepts im-pliqués dans les correspondances, avant de les appliquer. Si une correspondance n’est pasapplicable, une trace du problème est générée.

Deux approches de mise en œuvre sont alors possibles :

– conditionner l’applicationdes règles de correspondance avant leur exécution (sousforme, par exemple, de pré-conditions) ;

– orienter le déroulementdes règles de correspondance durant leur exécution (sousforme de conditions, au sein des règles).

Dans le premier cas, une règle est appliquée si toutes les ressources impliquées danscette règle sont disponibles. Dans le second cas, une règle ne génère que les éléments qui seréfèrent à des ressources disponibles.

Les algorithmes 4.10 et 4.11, page suivante, détaillent chacune de ces mises en œuvre.Le premier conditionne l’application des règles au plus haut niveau de la transformation. Lesecond influence le déroulement d’une règle.

La première solution, qu’apporte l’algorithme 4.10 ne déclenche aucune règle dont lerésultat n’est pas « complet » (dans le sens où tous les éléments prévus sont générés). Parcontre, si une règle n’est pas appliquée, la trace générée ne distinguepas les ressourcesindisponibles dans l’ensemble des ressources impliquées.

A l’inverse, la seconde solution, qu’apporte l’algorithme 4.11, est susceptible de dé-clencher des règles dont le résultat est « partiel » (dans le sens où certains éléments prévusne seront pas générés). Par contre, toute ressource indisponible est précisément identifiée.

La localisation d’un manque étant, selon nous, plus pertinente qu’un résultat de transfor-mation théoriquement peu exploitable, car insatisfait sur le plan des ressources disponibles,la seconde solution qu’apporte l’algorithme 4.11 sera privilégiée. Dans la suite de ce rap-port, les modifications qu’apporte l’algorithme 4.10 ne seront donc pas reconduites.


Algorithme 4.10 :Principe d’une transformation de déploiement (➤disponibilité)




Notations :Γa : l’ensemble{(ma, ϕma

)|ma ∈MMa etϕmaprécisema} utile au déploiement

Γp[γa] : un ensemble{(mp, ψmp)|mp ∈MMp etψmp

précisemp} relatif àγa ∈ Γa

début// Dupliquer le modèle de la plate-forme...// Intégrer l’applicationpour chaqueγa ∈ Γa faire

➤ si ∀γp ∈ Γp[γa], getResource(γp) 6= ∅ alorsruleConcept2MultiResourceInstances(γa,Γp[γa])

➤ sinon➤ // Tracer les problèmes de mise en œuvre➤ traceLackOfResource(γa,Γp[γa])

// Tracer les éléments non mis à contribution...

fin

Algorithme 4.11 :Règle de correspondance (ruleConcept2MultiResourceInstances) (➤disponibilité)









➤ si getResource(γp) 6= ∅ alors// Générer une instance de ressource typée par une ressourceconforme àγp

➤ ruleConcept2ResourceInstance(γa, γp)

➤ sinon➤ // Générer la trace d’un problème de mise en œuvre➤ traceLackOfResource(γa, γp)

fin

Remarque : L’algorithme 4.11 introduit un mécanisme de détection d’indisponibilité de ressource dans

la règleruleConcept2MultiResourceInstances. Ce mécanisme aurait également pu être introduit dans la règle

ruleConcept2ResourceInstanceprésentée précédemment, ou dans une règle intermédiaire entre ces règles.


4.3.5 Avec ou sans prototype de conception

Nous venons d’intégrer, dans l’algorithme de déploiement, une gestion d’indisponibi-lité de ressources sur les plates-formes d’exécution. Cependant, la mise en œuvre de mé-canismes applicatif avec des ressources disponibles, telle que nous l’avons abordée jusqu’àprésent, nécessite encore quelques précisions.

En particulier, comme cela fut mentionné dans le chapitre précédent (cf. Prototypes deconception, page 69), RTEPML identifie des concepts que les plates-formes d’exécution sontsusceptibles de fournir sous la forme d’une ressource unique(directement instanciable) ousous la forme d’un agencement de plusieurs ressources. L’expression d’un tel agencementse fait alors, avec RTEPML, par le biais de prototypes de conception.

La mise à disposition, par une plate-forme d’exécution, d’une ressourceconforme à unconcept se décline alors en deux situations, selon que cette ressource présente ou ne présentepas de prototype de conception. La figure 4.7 raffine ainsi la mise à disposition que nousavons qualifiée précédemment de « disponibilité 1 » (figure 4.6, page 90), en :

– une « disponibilité1′ », lorsque la ressource est instanciable ;

– une « disponibilité1′′ », lorsque plusieurs ressources doivent être instanciées, les ins-tances de ressources étant décrites par un prototype de conception8.

FIG. 4.7:Mise à disposition, par une plate-forme, de ressources avec ou sans prototype de conception.

A l’image des mécanismes présentés dans la sous-section précédente, deux approchessont envisageables pour adapter l’algorithme de déploiement à ces situations. La premièreapprocheconditionne l’applicationdes règles, selon qu’un prototype est précisé ou non (unerègle est alors dédiée à chaque cas identifié). La seconde approcheoriente le déroulementdes règles (sur des conditions similaires).

Cependant, lorsque plusieurs concepts exécutif sont impliqués dans unerègle (dansle cas des relations 1-N ou N-M), chacun peut être fourni par la plate-forme cible avecou sans prototype de conception. La première approche nécessite alorsautant de règlesde correspondances que de cas identifiés (soit2n pourn concepts impliqués). Alors quela seconde approche permet d’orienter, selon deux possibilités (avec ou sans prototype),chaque correspondance sous-jacente (ce qui nécessite au plus2n règles pourn conceptsimpliqués).

La seconde approche sera donc privilégiée. L’algorithme 4.12, page suivante, en détaillela mise en œuvre.

L’algorithme 4.12 discerne les concepts pour lesquels un prototype de conceptionest fourni par la plate-forme. S’il n’y a pas de prototype, une unique instance estgénérée (à l’image de ce qui a été pratiqué jusqu’à présent dans la règleruleCon-cept2MultiResourceInstances). Par contre, lorsqu’un prototype est stipulé, un ensembled’instances de ressources est généré conformément à ce que décritle prototype (le proto-type est cloné). Cette génération (ou clonage) est capturée dans la règle ruleClonePrototypedont l’algorithme 4.13, page suivante, donne le principe.

8PB

′′ représente un prototype de conception dans la figure 4.7.


Algorithme 4.12 :Règle de correspondance (ruleConcept2MultiResourceInstances) (➤prototypes)








si getResource(γp) 6= ∅ alors➤ si getResource(γp).prototype = ∅ alors

// Générer une instance de ressource typée par une ressourceconforme àγp

ruleConcept2ResourceInstance(γa, γp)

➤ sinon➤ // Générer des instances de ressources à partir du prototype➤ ruleClonePrototype(γa, getResource(γp).prototype)

sinon...

fin

Algorithme 4.13 :Règle d’application d’un prototype (ruleClonePrototype)





Élement impliqué :ω : un prototype de conception (conforme au conceptPrototypedeRTEPML)

début// Générer les instances à partir de celles que précise le prototypepour chaque instancei ∈ ω.instances faire

si i.match = ∅ alors// L’instance ne correspond pas à une instance prédéfinie surla plate-formesi getResource(i.type).prototype 6= ∅ alors

// Appliquer une hiérarchie de prototypes (par appels récursifs)ruleClonePrototype(γa, i.type.prototype)

sinon// Générer une instance à partir d’une instance du prototyperuleCreateResourceInstanceFromPrototype(γa, i)

// Générer les associations entre les instances que précisele prototypepour chaqueassociationa ∈ ω.associations faire

ruleCreateAssociationFromPrototype(γa, a)

fin


L’algorithme 4.13 se déroule en deux étapes. La première génère les instances de res-sources et la seconde les associe (à l’image de ce que décrit le prototype).

Lors de la première étape, seuls certains éléments du prototype engendrent la créationd’instances. En effet, les éléments d’un prototype de conception représentent soit des ins-tances de ressources propres au prototype, soit des instances de ressource prédéfinies surla plate-forme d’exécution (cf. Prototypes de conception, page 69). Les instances prédéfi-nies sur la plate-forme étant par définition déjà disponibles, seules les instances propres auprototype suscitent une génération (d’où la conditioni.match = ∅ qui vérifie qu’aucuneinstance prédéfinie n’est associée à l’instance considérée).

La modélisation des prototypes de conception proposée dans RTEPML s’expose égale-ment à une utilisation hiérarchique des prototypes de conception. Une instance de ressourcedans un prototype peut elle-même être mise en œuvre par un prototype. L’application hié-rarchique des prototypes, lors de la transformation, est alors assuréepar appels récursifs àla règleruleClonePrototype. Enfin, si l’instance de ressource ne nécessite pas de prototypepour sa mise en œuvre, une instance est générée à son image. Cette génération est capturéedans la règleruleCreateResourceInstanceFromPrototypeque nous détaillerons par la suite.

Finalement, lors de la seconde étape, les instances générées sont mises enrelation. Pourcela, une association est générée à l’image de chaque association précisée dans le prototype.Cette génération est capturée dans la règleruleCreateAssociationFromPrototype.

Les algorithmes suivants, 4.14 et 4.15, décrivent les principes respectifs des règlesru-leCreateResourceInstanceFromPrototypeet createAssociationFromPrototypechargées degénérer les instances et leurs associations.

L’algorithme 4.14 génère une instance de ressource dont le type correspond à celuide l’instance du prototype (le renseignement des propriétés et des appels de services seraabordé dans la suite de cette section). En complément, l’algorithme 4.15 génèreune as-sociation entre les « images » des éléments concernés par chaque association que décrit leprototype. Ces images (src et dst) correspondent aux instances de ressources générées parla règleruleCreateResourceInstanceFromPrototypeà partir de ces éléments.

Algorithme 4.14 :Génération d’une instance (ruleCreateResourceInstanceFromPrototype)





Élement impliqué :ι : une instance de ressource d’un prototype

(conforme àPrototypeResourceInstance∈ RTEPML)

début// Générer une instance de ressource// typée par la ressource qui type l’instance du prototypecorrespondance avecApplicationResourceInstance∈ RTEPML

type← ι.type...

...fin


Algorithme 4.15 :Génération des associations (ruleCreateAssociationFromPrototype)





Élement impliqué :α : une association (conforme àPrototypeResourceInstanceAssociation∈ RTEPML)

début// Générer une association entre deux instances de ressourcescorrespondance avecResourceInstanceAssociation∈ RTEPML

src← getInstance(α.src)dst← getInstance(α.dst)...

fin

On remarquera que les images des éléments décrits par un prototype sont localisées parla fonctiongetInstance. Nous ne détaillerons pas cette fonction dans ce rapport. Une miseen œuvre de celle-ci peut, par exemple, s’appuyer sur une liste qui mémorise les instancesgénérées à partir d’un prototype. Ces instances sont ensuite localiséesau sein de cette liste.Une solution d’implantation ATL disponible en annexe, et à laquelle nous ferons référencedans la section suivante, repose sur cette solution de localisation d’instances.

Remarque : La prise en compte d’un prototype de conception repose sur deux parcoursde celui-ci. Le premier couvre les instances qu’il décrit. Sa complexité est enO(n) (pourninstances décrites). Le second couvre les associations. Sa complexité est également enO(n)(pour n associations décrites) en considérant que la localisation des instances générées,assurée par la fonctiongetInstance, soit enO(1) (pourn instances générées).

Exemple

La figure 4.8, page suivante, illustre un déploiement dans lequel intervient un prototypede conception. Dans cet exemple, une application de robotique constituée d’uneactivité decontrôle périodique est déployée sur une plate-forme OSEK/VDX9.

Dans l’exemple proposé, la transformation Robot2RTEPML met en correspondance leconcept d’activité périodique avec celui de ressource ordonnançable périodique10.

Or, comme cela fut évoqué dans le chapitre précédent, la plate-forme OSEK/VDX meten œuvre un traitement périodique par une tâche périodiquement activée par une alarme. Lemodèle de la plate-forme décrit alors ce principe dans un prototype de conception de tâchepériodique (PeriodicTask) conforme au concept de ressource ordonnançable (la syntaxe gra-phique de la figure 4.8 nous semble suffisamment intuitive pour ne pas être détaillée).

La ressourcePeriodicTaskde la plate-forme d’exécution possédant un prototype deconception, lors de la transformation, la règleruleConcept2MultiResourceInstances(adap-tée aux concepts d’activité et de ressource ordonnançable périodiques) oriente son exécution

9Cet exemple s’appuie sur les métamodèles de robotique et de la plate-forme d’exécution OSEK/VDX pré-sentés dans les chapitres 2 et 3. Pour des raisons didactiques, l’exemple ne mentionne pas le compteur auquelest connecté l’alarme.

10Nous admettons que le comportement attendu de l’activité est vérifié pour la mise en œuvre envisagée.


vers la règleruleClonePrototype(algorithmes 4.12 et 4.13). Cette dernière génère alors : (a)une instance de ressource pour chaque instance stipulée dans le prototype et (b) les associa-tions entre ces instances (algorithmes 4.14 et 4.15). Les instances de ressourcesControl_TetControl_T-A1sont ainsi créées et associées par la relationalarm.

FIG. 4.8:Déploiement d’une application de robotique sur une plate-forme OSEK/VDX (prototype).

Remarque : Le prototype de l’exemple s’appuie sur l’association de deux ressources quefournit la plate-forme d’exécution. Mais, d’autres prototypes peuventégalement préciserles valeurs de certaines propriétés ou faire appel à des services de ressources. La prise encompte, lors d’un déploiement, des propriétés et des appels de services précisés dans unprototype sera abordée dans les sous-sections suivantes.

4.3.6 Renseigner les propriétés

La gestion des propriétés des ressources, et plus particulièrement despropriétés atta-chées aux instances de ressources, a été évoquée dans la section précédente, mais laissée ensuspend jusqu’à présent. Cette sous-section se consacre à la préciser.

Pour cela, deux contextes sont à considérer, selon que l’instance générée, concernée parune propriété, est issue ou non d’un prototype de conception. Deux raisons motivent cettedistinction. Un prototype de conception est d’une part susceptible d’introduire des infor-mations utiles au renseignement des propriétés, en plus de celles que fournit le modèle del’application. Il introduit d’autre part un mécanisme de distribution des rôlesqui influencel’identification des propriétés (cf. Prototypes de conception, page 69).Les sources d’in-formation et les mécanismes d’identification des propriétés seront donc différents dans lesdeux contextes.


Orthogonalement, comme cela fut précisé lors de la présentation du langage RTEPML,les instances de ressources possèdent des propriétés renseignéessous forme de littéraux(pour un type natif à la plate-forme) ou sous forme de références vers d’autres instancesde ressources (cf.ResourceInstanceProperty, figure 3.16, page 66). Au sein de chacun descontextes (avec ou sans prototype de conception), deux types de gestion sont donc à prévoir :la gestion des valeurs littérales et la gestion des références.

Cette sous-section introduit donc dans un premier temps ces deux gestions dans chacundes contextes. L’implantation de la gestion des références sera ensuite discutée, avant deprésenter un exemple de déploiement dans lequel des propriétés sont renseignées.

Sans prototype de conception

Dans un contexte qui ne met pas à contribution de prototype de conception,le rensei-gnement des propriétés se fait au sein de la règleruleConcept2ResourceInstance. L’algo-rithme 4.16, page suivante, en détaille le principe.

L’algorithme 4.16 parcourt l’ensemble des propriétés associées au concept exécutif (γp)mis à contribution par la règle (les propriétés sont identifiées par les rôles que retourne lafonctiongetPropertyRoles).

Durant ce parcours, chaque propriété est renseignée sous deux conditions :

1. La ressource qui type l’instance générée sur la plate-forme cible doitdisposer de cettepropriété (ce dont nous informe la fonctiongetPropertyqui la localise) ;

2. L’élément source (conforme àγa) doit fournir des informations utiles au renseigne-ment de la propriété (ce dont nous informe la fonctionhasPropertyInformation).

Le renseignement d’une propriété consiste alors à générer une propriété d’instance deressource (ResourceInstanceProperty) qui lui est associée (property) et dont la valeur oula référence est déduite des informations disponibles dans le modèle de l’application. Lesinformations relatives à chacune de ces formes, par valeur ou par référence, sont successive-ment collectées et traitées (via les fonctionsgetPropertyValuesetgetPropertyReferences).

On remarquera qu’une propriété d’instance de ressource est générée pour chaque in-formation présente dans le modèle de l’application. Une même propriété peut donc êtrerenseignée plusieurs fois. La modélisation des points d’entrée d’une tâche souligne l’intérêtde cette approche. En effet, différents points d’entrée peuvent être associés à une tâche, parexemple, selon des modes de fonctionnement (test, nominal, dégradé, etc.).Chaque pointd’entrée est alors stipulé dans une propriété dont le rôle correspond au point d’entrée d’uneressource ordonnançable11.

Enfin, l’algorithme prévoit de générer une trace lorsqu’une propriété susceptible d’êtrerenseignée est ignorée lors du déploiement.

Remarque : Les deux causes que sont l’absence d’information dans le modèle de l’ap-plication et l’absence de considération de la propriété par la plate-forme d’exécution ne sontpas distinguées dans cette version. Une séparation des conditions sur le déroulement de larègle permettrait d’affiner cette distinction.

Les fonctions mises à contribution dans l’algorithme 4.16 ainsi que la gestion des réfé-rences vers des instances de ressources seront présentées et discutées dans la suite de cettesous-section. Mais, avant cela, nous allons introduire les mécanismes analogues à cette ges-tion des propriétés au sein d’un prototype de conception.

11L’utilisation de différents points d’entrés dans le cadre d’une gestion desmodes de fonctionnement ne serapas plus abordée dans la suite de ce rapport.


Algorithme 4.16 :Sans prototype (ruleConcept2ResourceInstance) (➤propriétés)






Concept impliqué :γp : un concept(mp, ψmp



correspondance avecApplicationResourceInstance∈ RTEPMLtype← getResource(γp)...

// Générer les propriétés de l’instance➤ pour chaquerôle r ∈ getPropertyRoles(γp) faire➤ si getProperty(type, r) 6= ∅➤ et hasPropertyInformation(γa, r) alors

// La ressource qui type l’instance possède une propriété dont le rôle estr// et l’élément source fournit une ou des informations pour cette propriété

// Générer les propriétés d’instances renseignées par des valeurs➤ pour chaquevalue ∈ getPropertyValues(γa, r) faire➤ correspondance avecResourceInstanceProperty∈ RTEPML➤ val← value➤ property ← getProperty(type, r)

// Générer les propriétés d’instances renseignées par des références➤ pour chaquereference ∈ getPropertyReferences(γa, r) faire➤ correspondance avecResourceInstanceProperty∈ RTEPML➤ ref ← reference➤ property ← getProperty(type, r)

➤ sinon➤ // Générer la trace d’une absence d’information pour un rôlede propriété➤ traceLackOfProperty(γa, type, r)

fin

Avec prototype de conception

Lorsqu’un prototype de conception est mis à contribution, les propriétés des instancespeuvent se déduire du modèle de l’application, mais aussi du prototype lui-même (un pro-totype pouvant préciser les propriétés de ses instances).

Deux gestions sont donc prévues, l’une pour les informations issues dumodèle de l’ap-plication, l’autre pour les informations issues du prototype.

La gestion des propriétés renseignées à partir du modèle de l’application se fait ausein de la règleruleCreateResourceInstanceFromPrototype. L’algorithme 4.17, page sui-vante, en détaille le principe.


Algorithme 4.17 :Avec prototype (ruleCreateResourceInstanceFromPrototype) (➤propriétés)






Concept impliqué :➤ γp : un concept(mp, ψmp


Élement impliqué :ι : une instance de ressource d’un prototype (conforme àPrototypeResourceInstance∈RTEPML)

début// Générer une instance de ressource typée par la ressource qui type l’instance duprototypecorrespondance avecApplicationResourceInstance∈ RTEPML

type← ι.type...

// Générer les propriétés à partir d’informations issues dumodèle de l’application➤ pour chaquerôle r ∈ getPropertyRoles(γp) faire➤ si getPrototypeProperty(γp, ι, r) 6= ∅➤ et hasPropertyInformation(γa, r) alors

// Si l’instance du prototype est concernée par le rôler// et que l’élément source fournit une ou des informations pour cette propriété

// Générer les propriétés d’instances renseignées par des valeurs➤ pour chaquevalue ∈ getPropertyValues(γa, r) faire➤ correspondance avecResourceInstanceProperty∈ RTEPML➤ val← value➤ property ← getPrototypeProperty(γp, ι, r)

// Générer les propriétés d’instances renseignées par des références➤ pour chaquereference ∈ getPropertyReferences(γa, r) faire➤ correspondance avecResourceInstanceProperty∈ RTEPML➤ ref ← reference➤ property ← getPrototypeProperty(γp, ι, r)

➤ sinon➤ // Générer la trace d’une absence d’information pour un rôlede propriété➤ traceLackOfProperty(γa, type, r)

fin

Cette gestion est similaire à celle que nous venons de présenter (sans prototype deconception). Seule la localisation des propriétés à renseigner diffère. En effet, les rôlesdes propriétés associées aux ressources sont « distribués » aux instances des prototypes deconception (cf. Prototypes de conception, page 69). Les instances d’un prototype, ou plusprécisément les propriétés des ressources qui les typent, se voient ainsi attribuer les rôlesdes propriétés associées à la ressource mise en œuvre par le prototype.Lors de la généra-tion d’une instance à partir d’un prototype, les propriétés susceptibles d’être renseignéessont donc celles dont le rôle a été attribué à l’instance du prototype à l’origine de sa géné-ration (celle dont elle se fait l’image - ou le clone).


L’algorithme 4.17 parcourt donc l’ensemble des propriétés associées auconcept exécutif(γp) mis en œuvre par le prototype de conception (comme précédemment, les propriétés sontidentifiées par les rôles que retourne la fonctiongetPropertyRoles).

Durant ce parcours, chaque propriété est renseignée sous deux conditions :

1. Le rôle de la propriété doit être attribué à une propriété de l’instance du prototypeconcernée par la règle (ce dont nous informe la fonctiongetPrototypePropertyquilocalise cette propriété dans la plate-forme cible) ;

2. L’élément source (conforme àγa) doit fournir des informations utiles au renseigne-ment de la propriété (ce dont nous informe la fonctionhasPropertyInformation).

Comme précédemment, le renseignement d’une propriété consiste alors à générer unepropriété d’instance de ressource (ResourceInstanceProperty) qui lui est associée (property)et dont la valeur ou la référence est déduite des informations disponibles dans le modèlede l’application. Les informations relatives aux valeurs ou aux références sont ici aussisuccessivement collectées et traitées. Enfin, l’algorithme prévoit également de générer unetrace lorsqu’une propriété susceptible d’être renseignée est ignoréelors du déploiement.

Parallèlement, comme cela fut mentionné précédemment, lorsqu’un prototype deconception est mis à contribution, les propriétés des instances peuvent également se déduiredu prototype lui-même.

La gestion des propriétés renseignées à partir du prototypese fait alors au sein dela règleruleClonePrototype. L’algorithme 4.18 en détail le principe.

La gestion des propriétés stipulées dans un prototype consiste à générerdes proprié-tés d’instances de ressources (ResourceInstanceProperty) à l’image de celles que précisele prototype. Cette génération est assurée par la règleruleCreatePropertiesFromPrototypedont l’algorithme 4.19, page suivante, détaille le principe.

Algorithme 4.18 :Règle d’application d’un prototype (ruleClonePrototype) (➤propriétés)





Élement impliqué :ω : un prototype de conception (conforme au conceptPrototypedeRTEPML)

début// Générer les instances à partir de celles que précise le prototype...

// Générer les propriétés des instances que précise le prototype➤ pour chaque instancei ∈ ω.instances faire➤ ruleCreatePropertiesFromPrototype(γa, i)

// Générer les associations entre les instances que précisele prototype...

fin


Algorithme 4.19 :Génération des propriétés (ruleCreatePropertiesFromPrototype)





Élement impliqué :ι : une instance de ressource d’un prototype (conforme àPrototypeResourceInstance∈RTEPML)

début// Générer les propriétés précisées pour l’instance du prototypepour chaqueproperty ∈ ι.properties faire

// Créer une propriété à l’image d’une propriété de l’instance du prototypecorrespondance avecResourceInstanceProperty∈ RTEPML

val← property.valref ← getInstance(property.ref)property ← property.property

fin

On remarquera la mise à contribution de la fonctiongetInstanceintroduite précédem-ment (pour la génération des associations précisés dans un prototype dans l’algorithme 4.15,page 96). Cette fonction permet de localiser une instance de ressource qui a été générée àpartir d’un élément du prototype.

On remarquera également que les propriétés précisées dans un prototype sont géréesaprèsla génération des instances, et non pendant, comme c’est le cas lors de la prise encompte des informations présentes dans le modèle de l’application. Cette distinction estmotivée par le besoin de se référer à des instances issues du prototype,lorsqu’elles sontréférencées par des propriétés. La gestion des références dans les propriétés est discutée etapprofondie dans la sous-section suivante.

Enfin, un ordre de considération pourrait être instauré entre les deux sources d’informa-tion que sont le modèle de l’application et le prototype de conception. En effet, si les deuxsources fournissent une information pour la même propriété, deux propriétés d’instancessont créées, renseignant alors deux fois la propriété. L’interprétation des deux valeurs (oudes deux références) est donc actuellement à la charge de l’utilisateur.Une trace peut tou-tefois être mise en place pour automatiser la détection de cette situation.

Les références

Nous venons de voir qu’une propriété pouvait être renseignée par une valeur littérale oupar une référence vers une instance de ressource.

Dans le cas d’un renseignement par valeur littérale, la propriété de l’instance est direc-tement créée et associée à la propriété de la ressource qui type l’instance.

Dans le cas d’un renseignement par référence, l’implication d’un élémentgénéré aucours de la transformation (l’instance référencée) soulève la question de l’existence de cetélément, dans le modèle généré, au moment du référencement.

Un parallèle peut être fait avec l’application d’un prototype de conceptionque nousavons présenté dans la sous-section précédente. Lors de l’applicationd’un prototype, la


génération des associations entre les instances repose également sur des références versdes éléments générés. Cependant, les éléments concernés sont soit mis à disposition par laplate-forme, soit générés par une règle dont l’exécution précède, par construction, celle quigénère les associations. L’existence des instances référencées estdonc systématiquementgarantie.

Ce même principe a été appliqué dans cette sous-section pour renseigner des propriétésà partir de ce que précise un prototype de conception.

Ce principe de création d’élémentsavant leur référencement est d’ailleurs communé-ment employé dans les technologies de transformation déclarative. La résolution des réfé-rences est alors transparente pour l’utilisateur.

Cependant, certaines parties de l’algorithme que nous proposons, qui concernent lagénération des instances de ressources, nécessitent un contexte impératif12. Ces partiesconcernent en particulier le clonage des prototypes de conception qui mettent, par exemple,à contribution des appels récursifs. Or, les éléments générés dans un contexte impératif nebénéficient pas d’une génération « anticipée ». Et, ils ne peuvent être référencés qu’aprèsavoir été générés. La gestion des références qui impliquent des élémentspotentiellementgénérés dans un contexte impératif, telles que les instances issues d’un prototype de concep-tion, doit donc être intégrée dans les algorithmes.

La gestion des propriétés renseignées à partir de ce que précise un prototype de concep-tion étant assurée « par construction », nous nous intéressons plus particulièrement à lagestion des propriétés renseignées à partir des informations présentes dans le modèle del’application (algorithmes 4.16 et 4.17 de cette sous-section).

Pour cela, nous proposons d’intégrer à la gestion de ces propriétés unmécanisme quiconsiste à renseigner une référence si l’instance à laquelle elle se réfère a déjà été géné-rée. Dans le cas contraire, la propriété concernée et l’élément du modèle de l’application àl’origine de la création de l’instance manquante sont mémorisés dans une liste.

Enfin, pour garantir le renseignement de toutes les propriétés, les propriétés incom-plètes, mémorisées dans cette liste, sont complétées ultérieurement, lors de la générationdes instances manquantes13.

Ce mécanisme concerne les règlesruleConcept2ResourceInstanceetruleCreateResour-ceInstanceFromPrototypechargées de générer les instances de ressources et de renseignerleurs propriétés. L’algorithme 4.20, page suivante, illustre son intégrationen se concentrantsur les parties communes à ces règles.

L’algorithme 4.20 introduit les fonctionsgetIfExistInstanceet completePropertyRefe-rences. La première localise une instance référencée, si cette instance a déjà étégénérée,sinon mémorise la propriété à compléter et l’élément source impliqué. La seconde parcourtles propriétés à compléter après chaque création d’instance. Ce parcours vise à compléterles propriétés qui se réfèrent à l’instance qui vient d’être générée.

Ces fonctions ne seront pas détaillées dans ce rapport. On notera toutefois que leur miseen œuvre s’appuie sur une structure qui mémorise des couples (propriété d’instance, élémentsource), pour ce qui concerne les propriétés incomplètes, et peut nécessiter une structurequi mémorise l’ensemble des traductions effectuées au cours de la transformation (pourdiscerner les instances disponibles lors d’un référencement). Une solution d’implantationATL disponible en annexe repose sur ce mécanisme.

12Nous détaillerons, dans la section suivante, les contraintes d’implantation qu’impose l’algorithme proposé.13La mémorisation de l’élément source à l’origine de la génération de l’instance manquante permet de détec-

ter qu’une propriété doit être complétée lors du traitement de cet élément.


Algorithme 4.20 :Renseignement des propriétés (avec ou sans prototype) (➤référence)







début// Générer une instance de ressource...

// Générer les propriétés de l’instancepour chaquerôle r ∈ getPropertyRoles(γp) faire

si // conditions de générationalors

// Générer les propriétés d’instances renseignées par des valeurs...

// Générer les propriétés d’instances renseignées par des référencespour chaquereference ∈ getPropertyReferences(γa, r) faire

correspondance avecResourceInstanceProperty∈ RTEPML➤ ref ← getIfExistInstance(reference)

property ← ...

sinon// Générer la trace d’une absence d’information pour un rôlede propriété...

// Compléter les références en attente➤ completePropertyReferences(γa)

fin

Exemple

La figure 4.9, page suivante, complète l’exemple introduit dans la sous-section précé-dente (figure 4.8, page 97) pour illustrer le renseignement des propriétés.

Dans cet exemple, l’activitéde contrôle périodique (Control_T) est enrichie d’un sous-programme (Control). Ce sous-programme est une unité séquentielle d’exécution qui consti-tue le point d’entrée de l’activité.

Remarque : La transformationRobot2RTEPML assure la mise en œuvre d’un sous-programme par une correspondance avec le concept de routine14 (dont la plate-forme fournitune ressource qui s’y conforme (Function)).

Au cours de la transformation, les propriétés des instances générées sont renseignéesconformément aux algorithmes 4.17 et 4.20 que nous venons d’introduire.En effet, les ins-tances concernées (Control_T et Control_T-A1) proviennent d’un prototype de conceptionet les informations qui renseignent leurs propriétés sont issues du modèle de l’application.

14Le concept de routine a été introduit dans le chapitre 3 lors de la présentation de RTEPML.


De cette façon, les propriétés dont les rôles correspondent à la priorité, à la taille de lapile et à la période d’activation sont renseignées par valeurs. Ces valeurs sont associées auxpropriétés des instances auxquelles les rôles sont distribués dans le prototype15.

Enfin, la propriété du point d’entrée de la tâche générée référence la fonctionControl(qui correspond au sous-programme homonyme de l’activité de contrôle).

FIG. 4.9:Déploiement d’une application de robotique sur une plate-forme OSEK/VDX (propriétés).

4.3.7 Gestion des appels de services

Le dernier point qu’aborde cette sous-section concerne l’implication desservices asso-ciées aux ressources des plates-formes pour mettre en œuvre un mécanisme applicatif.

De nombreux mécanismes reposent en effet sur les services des ressources. Les accèsaux sections critiques impliquent, par exemple, systématiquement des servicesde prise etde libération d’une ressource d’exclusion mutuelle. De même, les communications entreles entités d’exécution concurrentes sollicitent les services des ressources dédiées à cescommunications.

Cependant, l’utilisation de ces services ne peut pas être décrite dans un modèle indépen-dant du support d’exécution. Les services impliqués dépendent forcément de la plate-formed’exécution. La mise en œuvre de ces mécanismes se concrétise donc par des appels deservices qu’il convient de générer lors du déploiement de l’application.

15Seule la distribution des rôles de périodicité (period) et de point d’entrée (entrypoint) est représentée dansle modèle en guise d’exemple.


La gestion des appels de services que nous proposons d’intégrer dans l’algorithme suitalors le même principe que celui des propriétés déjà présentées : si un élément source àl’origine de la création d’une instance implique des appels de services, cesappels sont gé-nérés lors de la création de l’instance. Pour cela, des fonctions de « détection d’implicationde services » et une interprétation des services impliqués doivent être mises en place.

Comme précédemment, deux contextes se distinguent, selon que l’instance concernéeest issue ou non d’un prototype de conception.

De même, un appel de service peut être généré à partir d’informations présentes dans lemodèle de l’applicationou à partir d’appels de services spécifiés dans un prototype.

Des paramètres peuvent également accompagner les appels de services. A l’image despropriétés, ces paramètres sont renseignés soit par des valeurs littérales, soit par des réfé-rences vers des instances de ressources.

Enfin, la gestion des références doit être étendue aux instances que référencent les appelsde services (instances auxquelles s’adressent les appels de services, cf. figure 3.17, page 66).

Pour mettre en œuvre les appels de services dans des contextes qui impliquent ou n’im-pliquent pas de prototypes de conception, tout en répondant aux problématiques d’exis-tences des instances référencées, la génération de ces appels suit des principes similaires àceux introduits dans la sous-section précédente :

– Sans prototype de conception, un appel de service est généré si :

1. L’élément source à l’origine de la création d’une instance procure des informa-tions à destination de cet appel de service ;

2. La ressource qui type l’instance dont le service est sollicité fournit ce service ;

– Avec prototype de conception, un appel de service est généré si ;

1. L’élément source à l’origine de la création d’une instance procure des informa-tions à destination de cet appel de service ;

2. Le rôle du service attendu est attribué à un service du prototype concerné ;

– Les appels de services précisés dans un prototype sont générés après la création detoutes les instances du prototype ;

– Avec ou sans prototype de conception :

– Les paramètres des appels renseignés par valeurs littérales et par références d’ins-tances sont générés successivement ;

– Les appels qui ne disposent pas de l’instance concernée par le service, ou d’uneinstance concernée par l’un des paramètres, sont mémorisés ;

– Les appels incomplets sont complétés après chaque génération d’instance.

Dans le respect de ces principes, l’algorithme 4.21, page ci-contre, illustre l’introduc-tion d’une gestion d’appels de services, dans la règleruleConcept2ResourceInstance(quin’implique pas de prototype de conception).

A l’image de ce que nous avons proposé pour la gestion des propriétés, l’algorithme 4.21s’appuie sur des fonctions de collecte d’informations associées aux concepts du métamo-dèle de l’application16. Ces fonctions permettent de détecter et de renseigner les servicesimpliqués lors d’un déploiement.

16La répercussion de ces fonctions sur la généricité de l’algorithme sera discutée dans la section suivante.


Algorithme 4.21 :Sans prototype (ruleConcept2ResourceInstance) (➤services)


Métamodèles cibles:MMp : le métamodèle de plate-forme d’exécution(RTEPML)MMt : un métamodèle de trace(non précisé dans cette étude)






correspondance avecApplicationResourceInstance∈ RTEPMLtype← getResource(γp)...

// Générer les propriétés de l’instance...

// Générer les appels de services➤ pour chaque(element, concept, service) ∈ getCallServices(γa) faire

// Pour chaque information fournie par l’élément source pour un appel de service

➤ si getService(concept, service) 6= ∅ alors// Le service est bien fourni par une ressource (χconcept) de la plate-forme

➤ correspondance avecCallService∈ RTEPML➤ ref ← getIfExistInstance(element)➤ service← getService(concept, service)

// Générer les paramètres renseignés par des valeurs➤ pour chaque(p, value) ∈ getParameterValues(service) faire➤ correspondance avecCallParameter∈ RTEPML➤ value← value➤ parameter ← getParameter(p)

// Générer les paramètres renseignés par des références➤ pour chaque(p, ref) ∈ getParameterReferences(service) faire➤ correspondance avecCallParameter∈ RTEPML➤ ref ← getIfExistInstance(ref)➤ parameter ← getParameter(p)

➤ sinon➤ // Générer la trace d’une absence de service pour l’appel➤ traceLackOfService(γa, concept, service)

// Compléter les références en attentecompletePropertyReferences(γa)

➤ completeCallServiceReferences(γa)fin

Les fonctions de collecte retournent en particulier des informations sur :

– une séquence d’appels de services impliqués pour la mise en œuvre d’unmécanismeapplicatif (getCallServices) ;

– un service précis (getService) ;– les paramètres d’un service (getParameterValuesetgetParametersReferences).


L’algorithme prévoit que certaines fonctions retournent des informationssous la formede tuples.

Pour ce qui concerne la séquence de services que parcourt l’algorithme (getCallSer-vices), ce tuple est constitué d’un élément source, d’un concept de RTEPML et d’un ser-vice identifié par son rôle. L’élément source est l’élément qui est à l’origine de la généra-tion de l’instance à laquelle s’adresse le service. Cette instance est typée par une ressourceconforme au concept stipulé17.

Pour ce qui concerne les paramètres (getParameterValuesetgetParametersReferences),le tuple est un couple constitué d’une information de localisation du paramètre et soit d’unevaleur, soit de l’élément à l’origine de l’instance que référence le paramètre.

Enfin, la gestion des références est similaire à celle que nous avons introduite dans lasous-section précédente. La localisation des instances référencées est assurée par la fonctiongetIfExistInstance, tant pour l’instance à laquelle s’adresse le service que pour les instancespassées en paramètre. Et finalement, les appels qui ne disposent pas d’une de ces instancesau moment de leur génération sont complétés au sein d’une fonctioncompleteCallService-References, à l’image de la fonctioncompletePropertyReferencesintroduite précédemment.

Remarque : Cette algorithme montre des similitudes avec ceux que nous avons introduit,dans la sous-section précédente, pour la gestion des propriétés. L’introduction d’une gestiondes services dans un prototype de conception étant également similaire à cequi a déjà étéprésenté (règlesruleCreateResourceInstanceFromPrototypeet ruleClonePrototype), nousn’en détaillerons pas les algorithmes dans cette sous-section.

Exemple

La figure 4.10, page suivante, complète l’exemple de la sous-section précédente (fi-gure 4.9, page 105) pour illustrer la génération d’appels de services.

Dans cet exemple, l’application se compose de deuxactivitéspériodiques. L’une estdédiée au contrôle du procédé (Control_T), l’autre à l’affichage des données contrôlées(Display_T). Chacune des activités est munie d’un sous-programme (Control et Display)qui constitue son point d’entrée.

Il est prévu que l’activité de contrôle transmette des données à l’activité d’affichage.Pour cela, une communication entre les deux activités est décrite par des ports de données(symboleH) et une connexion entre ces ports (Com).

Remarque : Dans cette version, la transformationRobot2RTEPML assure la mise enœuvre d’une connexion par une correspondance avec le concept de variable partagée18 (dontla plate-forme cible fournit une ressource qui s’y conforme (SharedData)).

Au cours de la transformation, lors de la génération des fonctions de contrôle et d’affi-chage (ControletDisplay, qui correspondent aux sous-programmes homonymes du modèlede l’application), unhelpergetCallSequencerenseigne la transformation sur le fait que lesports de données engendrent la création d’appels de services. L’algorithme 4.22, page ci-contre, détaille le principe de cehelper.

L’échange de donnée décrit par les ports d’entrée et de sortie se concrétise alors par desappels aux services de lecture et d’écriture (read et write) de la ressourceSharedData(en

17L’introduction du concept dans le tuple est motivée par le besoin de vérifier que la ressource de la plate-forme qui type l’instance à laquelle s’adresse le service, fournit bien ce service.

18Le concept de variable partagée (SharedDataComResource) a été introduit dans le chapitre 3 lors de laprésentation de RTEPML. Nous considérons que le comportement attendu de la communication modélisée estvérifié pour la mise en œuvre proposée.


fonction de l’orientation du port). Chacun de ces appels s’adresse à l’instance de ressourcepartagée (Com), qui correspond à la connexion homonyme, dans le modèle de l’application.

FIG. 4.10:Déploiement d’une application de robotique sur une plate-forme OSEK/VDX (avec services).

Algorithme 4.22 :Exemple d’une déclaration d’appels de services (getCallServices)

Entrée :sp : un élément de l’application conforme à unSubprogram du métamodèle Robot

Résultat :seq : une séquence de tuples{element, concept, role}

débutseq ← ∅

// Pour chaque port de donnée de sortiepour chaque output ∈ sp.outputDataPorts faire

// appel du service d’écriture sur une connexion par variable partagéeseq ← {output.connection, RTEPML !SharedDataComResource, ’write’}

// Pour chaque port de donnée d’entréepour chaque input ∈ sp.inputDataPorts faire

// appel du service de lecture sur une connexion par variablepartagéeseq ← {input.connection, RTEPML !SharedDataComResource, ’read’}

retourner seqfin


4.4 Développement d’une transformation de déploiement

4.4.1 Organisation d’une transformation de déploiement

L’algorithme de déploiement que nous venons de définir se décompose en une hiérarchiede règles de correspondance. La figure 4.11 résume cette hiérarchie.

La première sous-figure (4.11a) se focalise sur les règles de déploiements que nousavons détaillées dans la section précédente. La seconde (4.11b) introduit les règles de tracesque nous avons évoquées. Dans ce schéma, une relation orientée entredeux règles,ra → rb,signifie que la règlera appelle la règlerb ou « intègre » la correspondance que décrit la règlerb (selon que le contexte de transformation est impératif ou déclaratif19).

(a) Règles de déploiements

(b) Règles de traces

FIG. 4.11:Composition d’une transformation de déploiement basée sur RTEPML.

Au sein des règles de correspondances, le parcours des modèles et letraitement deleurs données sont délégués à des fonctions (ouhelpers). Les règles et les fonctions quicomposent une transformation sont alors plus ou moins dépendantes des technologies im-pliquées lors du déploiement.

19On notera toutefois que les règles qui complètent les références et celles qui gèrent les prototypes deconception ont été conçues pour une approche impérative.

4.4. Développement d’une transformation de déploiement 111

Le tableau 4.1 résume les dépendances des règles et des fonctions définies dans la sec-tion précédente, avec :

– la technologie de modélisation de l’application source (MMa),– le métamodèle de plate-forme d’exécution (RTEPML),– la plate-forme d’exécution cible (PDM) et– un métamodèle de trace (MMt).

MMa RTEPML PDM MMt

Règ

les

deco

rres

pond

ance

s

ruleConcept2MultiResourceInstances ✓(1) ✓

ruleConcept2ResourceInstance ✓(2) ✓

ruleClonePrototype ✓(1) ✓

ruleCreateResourceInstanceFromPrototype ✓(2) ✓

ruleCreateAssociationFromPrototype ✓(2) ✓

ruleCreatePropertiesFromPrototype ✓(2) ✓

ruleCreateCallServicesFromPrototype ✓(2) ✓

completePropertyReferences ✓(2) ✓

completeCallServiceReferences ✓(2) ✓

traceUnusedConcept ✓(3) ✓(3) ✓

traceLackOfResource ✓(3) ✓(3) ✓

traceLackOfProperty ✓(3) ✓(3) ✓

traceLackOfService ✓(3) ✓(3) ✓

(1) Les éléments sources sont directement transmis à d’autres règles.(2) Le traitement des éléments sources est entièrement délégué aux fonctions présentées ci-dessous.(3) Le traitement des éléments sources se restreint à leur nom ou à leur référence.

MMa RTEPML PDM MMt

Fon

ctio

ns(o

uhel

pers)

getResource ✓

getInstance ✓

getIfExistInstance ✓

getProperty ✓

getPrototypeProperty ✓

getPropertyRoles ✓

hasPropertyInformation ✓ ✓

getPropertyV alues ✓ ✓ ✓

getPropertyReferences ✓ ✓ ✓

getCallServices ✓ ✓

getService ✓

getParameterV alues ✓ ✓ ✓

getParameterReferences ✓ ✓ ✓

getParameter ✓ ✓

TAB . 4.1:Règles et fonctions mises à contribution dans l’algorithme de déploiement.


La première partie du tableau montre qu’aucun concept propre aux plates-formes d’exé-cution n’est impliqué dans les règles de correspondances. De plus, les règles de traces sontprincipalement dépendantes du métamodèle de trace. Elles se contentent d’accès génériquesaux éléments sources, tels qu’un attribut de nommage ou une référence.

On remarque également que les règles de déploiements transmettent directement leséléments issus du modèle de l’application soit à d’autres règles, soit à des fonctions. Ainsi,seuls les concepts qu’adressent les règles au sommet de la hiérarchie derègles s’exprimentdans les termes du métamodèle de l’application20. En effet, les éléments issus du modèlede l’application peuvent être transmis le long de la hiérarchie, sans stipuler lesconceptsauxquels ils se conforment21. Ces concepts sont uniquement pris en compte,in fine, par lesfonctions auxquelles les règles délèguent le traitement des éléments.

Au bilan, toutes les règles sont indépendantes de la plate-forme cible et seules les règlesau sommet de la hiérarchie dépendent du métamodèle de l’application.

Parallèlement, la seconde partie du tableau distingue trois catégories de fonctions.Celles qui ne dépendent que du métamodèle de plate-forme d’exécution (RTEPML). Cellesqui dépendent également du métamodèle de l’application (MMa). Et celles qui sont propresà la plate-forme cible (PDM). Ces dernières concernent la traduction des valeurs et des ré-férences, à destination des propriétés d’instances ou des paramètres d’appels de services.

Une transformation de déploiement s’organise alors en différentspackages, tel que ledécrit la figure 4.12. Deuxpackagesregroupent les règles et les fonctions génériques auxplates-formes et aux technologies de modélisation des applications sources(rules4rtepmlet helpers4rtepml, propres à RTEPML). Un packagepeut être dédié aux règles de tracespotentiellement génériques à toutes les technologies (si les traces se contentent d’élémentsnommés ou de références) (rules4trace, propre au métamodèle de trace - non représenté surle schéma). Enfin, la transformation (X2RTEPML) se compose de troispackages. Les deuxpremiers concernent les règles et les fonctions propres au métamodèle del’application,mais génériques à toutes les plates-formes (X2rtepmlet X4rtepml). Le troisième regroupeles fonctions qui dépendent de la plate-forme cible (X4platform).

FIG. 4.12:Organisation d’une transformation de déploiement basée sur RTEPML.

20Dans un contexte déclaratif, le sommet de la hiérarchie de règles peut être défini comme étant l’ensembledes règles qui ne sont pas explicitement appelées. Pour ce qui nous concerne, ces règles sont du typeruleCon-cept2MultiResourceInstanceset traceUnusedConcept.

21Ceci suppose que les règles soient paramétrées avec un type générique (du typevoid ouOclAny).


Finalement, en s’appuyant sur les règles et les fonctions que fournissent cespackages,la mise en œuvre d’une transformation de déploiement se restreint à :

– un ensemble de règles de correspondances (ruleConcept2MultiResourceInstances)qui traduisent les concepts applicatif en concepts exécutif identifiés par RTEPML ;

– un ensemble de règles de correspondances (traceUnusedConcept) qui tracent lesconcepts applicatif qui ne sont pas mis à contribution lors d’un déploiement ;

– un ensemble de fonctions de collecte d’informations (hasPropertyInformation, get-CallServiceset getParameter), dans le but d’identifier les éléments de l’applicationqui concernent les propriétés, les services et les paramètres qu’identifient RTEPML ;

– un ensemble de fonctions de traduction de valeurs et de références (getPropertyVa-lues, getPropertyReferences, getParameterValueset getParametersReferences), pourrenseigner les propriétés et les paramètres dans le modèle généré (PSM).

La suite de cette section se focalise sur le développement des deux premiersensembles,avant d’évoquer des perspectives d’assistance au développementdes deux derniers. Maisavant d’approfondir ces principes de développement, nous tenons à signaler certainescontraintes sur la mise en œuvre des transformations.

4.4.2 Contraintes sur la technologie de transformation

L’algorithme proposé dans la section précédente se veut indépendant de toute technolo-gie de transformation. Toutefois, comme cela fut parfois souligné, certainsmécanismes del’algorithme peuvent contraindre le choix d’une technologie.

En effet, pour mettre en œuvre cet algorithme, une transformation nécessite:

– d’exprimer des critères, sous formes de prédicats, sur les éléments desmodèles ;

– d’exprimer des règles impératives ;

– d’invoquer récursivement des règles ;

– de conditionner le déroulement des règles ;

– de déléguer certains traitements (localisation, traduction) à des fonctions.

Enfin, un concept générique (tel quevoid ou OclAny) doit être disponible pour para-métrer les règles. En effet, tout type d’élément applicatif doit pouvoir être transmis auxrègles qui composent le noyau générique des transformations (lepackagerules4rtepml),sans présumer du concept auquel il se conforme.

Parmi les technologies de transformations actuellement disponibles, ATL répond, parexemple, aux contraintes que nous venons de mentionner22. Différentes implantations ATL

des algorithmes introduits dans la section précédente ont donc été développées au cours decette étude (avec différents métamodèles d’application). Une version de ces implantations,pour chaque algorithme présenté jusqu’à présent, est disponible en annexe (page 161).

Le code ATL des transformations présentées concerne les règles et les fonctions géné-riques qui accompagnent RTEPML, ainsi que les règles de correspondance qui traduisentles concepts applicatif en concepts exécutif. Les règles de correspondance sont toutefoisdonnées à titre indicatif (sur un métamodèle d’application « virtuel » qui ne correspond pasà une technologie précise) car, comme nous allons l’aborder dans la sous-section suivante,ces règles peuvent être générées.

22D’autres technologies, tels que Smart-QVT [102] ou Kermetta [46] ou même Java, restent bien sûr envisa-geables.


4.4.3 Génération des règles de déploiement

En dehors du noyau de règles génériques, le premier ensemble de règlesqui composentune transformation de déploiement établit des correspondances entre des concepts applicatifet des concepts exécutif identifiés par RTEPML (packageX2rtepml). Or, lastructurede cesrègles (du typeruleConcept2MultiResourceInstances23) est générique à tous les conceptssources et cibles impliqués. Cette structure offre donc une perspectivede génération desrègles à partir d’un modèle qui capture ces correspondances.

Dans le but de générer cet ensemble de règles, cette sous-section propose de modéliserles correspondances entre concepts applicatif et exécutif dans un modèle dédié, qualifié de« modèle de déploiement».

Modélisation d’un déploiement

La modélisation d’un déploiement nécessite de se conformer à un métamodèle. Or, ausein des règles du typeruleConcept2MultiResourceInstances, les informations nécessairesà l’expression d’un déploiement concernent :

1. les concepts identifiés par le métamodèle de l’application et RTEPML ;

2. les critères qui précisent ces concepts sous formes de prédicats.

Un métamodèle de déploiement doit donc permettre, d’une part, de décrire des cor-respondances entre les classes des métamodèles qui identifient les concepts et d’associer,d’autre part, des critères à ces concepts.

Dans la lignée de travaux sur la modélisation des relations entre les éléments de dif-férents modèles ou métamodèles [10] [34], la figure 4.13 présente le métamodèle le plussimple que nous ayons identifié pour décrire ces correspondances.

FIG. 4.13:Exemple de métamodèle de déploiement (simple)

Un déploiement (Deployment) se compose donc de mises en correspondance (Mapping)de concepts applicatif (ApplicationConcept) avec un ou plusieurs concepts exécutif identi-fiés par RTEPML (RTEPMLConcept).

Dans cette version, chaque concept, source ou cible, est désigné parson nom. Ce nomcorrespond au nom de la classe qui l’identifie dans un métamodèle. Un concept peut êtreprécisé par des critères (cf. Affiner les critères sur les concepts, page 85). Un critère estalors désigné par le nom de la fonction (ouhelper) qui capture son prédicat (Criterion).

Plusieurs améliorations peuvent être apportées à ce métamodèle. Des notionsd’auteur,de date et de motivation peuvent, par exemple, être associées à chaque correspondance(tels que le proposent certains travaux sur la modélisation des décisions [10]). D’autresnotions qui concernent les métamodèles peuvent également être introduitespour préciserles technologies concernées par le déploiement et identifier, par exemple,des notions deversion associées à ces technologies. Enfin, l’identification par nom pourrait être remplacéepar des références vers les classes concernées dans les métamodèles(tels que l’envisagentles travaux relatifs au tissage de modèles [34]).

23Algorithme 4.12, page 94.


Toutefois, nous ne détaillerons pas plus ce métamodèle dans la suite de cette section. Lasolution proposée s’appuie sur la version que nous venons de présenter.

On remarquera que l’approche proposée s’apparente au tissage de modèles [34]. Le tis-sage de modèles (ouweaving) consiste à modéliser des liens entre des éléments de modèlesou de métamodèles distincts. Un tissage peut représenter tout type d’interaction (ou de re-lation) entre les modèles. Différentes sémantiques peuvent être associéesaux liens tissés.Ainsi, lorsque la sémantique des liens concorde avec celle d’une transformation, un modèlede transformation peut être généré à partir d’un modèle de tissage.

Toutefois, dans un objectif de transformation de modèles, les travaux et lesoutils relatifsau tissage de modèles s’appuient sur des relations (ou correspondances) qui reflètent préci-sément les transformations. Dans l’approche que nous proposons, lescorrespondances quedécrivent les modèles de déploiement reflètent uniquement les traductionsde concepts ap-plicatif en concepts exécutif. Les mécanismes de clonage des prototypes oude gestion despropriétés et des appels de services ne sont pas décrits dans les modèlesde déploiement.Ces mécanismes sont capturés dans lestemplatesde génération de règles. L’approche quenous proposons diffère donc sur ce point des approches par tissage existantes.

Le listing 4.2 illustre la modélisation d’un déploiement conforme au métamodèle dedéploiement de la figure 4.13. Ce modèle décrit le déploiement qui conduit à lagénérationdes règles de transformation mises à contribution dans le dernier exemple de lasectionprécédente (figure 4.10, page 109). La syntaxe textuelle et les termes employés dans celisting nous semblent suffisamment explicites pour ne pas être commentés.

1 -- implement application periodic activity2 -- with periodic scheduable resource3 Activity [ categoryIsPeriodic ]4 -> SchedulableResource [ typeIsPeriodic ]56 -- implement application subprogram with routine7 Subprogram8 -> Routine9

10 -- implement connection with shared data11 Connection12 -> SharedDataComResource

Listing 4.2:Exemple de modèle de déploiement

La transformation qui résulte de ce modèle s’appuie sur les fonctionscategoryIsPeriodicet typeIsPeriodicqui capturent les critères de périodicité (lignes 3 et 4). La première fonc-tion, propre au métamodèle de l’application, sera développée au sein dupackageX4rtepml(figure 4.12, page 112). La seconde, propre à RTEPML, sera fournie par lepackagehel-pers4rtepml.

Un exemple detemplatede génération de règles ATL basé sur le métamodèle de dé-ploiement que nous venons d’introduire est disponible en annexe, page186. Le principed’un tel templateconsiste à exprimer une règle de déploiement dans un langage de transfor-mation, sans préciser les noms des concepts impliqués, ni les critères qui leurs sont associés.Ces données sont ensuite complétées, par un moteur detemplate, à partir des informationsdisponibles dans un modèle de déploiement.

Remarque : Une approche de génération de règles par transformation demodèles baséesur ce même métamodèle est également envisageable mais ne sera pas présentée. Dans lasuite de ce rapport, nous considérerons qu’une approche partemplateest pratiquée, maisnous ne présumerons pas de la technologie employée.


Génération des règles de traces

Parallèlement, le second ensemble de règles qui composent une transformation de dé-ploiement concerne les concepts applicatif qui ne sont pas mis à contributionlors du dé-ploiement et pour lesquels une trace doit être générée. A l’image des règles du premierensemble, la structure de ces règles (du typetraceUnusedConcept) peut être générique àtous les concepts applicatif impliqués. Leur génération est donc également envisageable.

Dans cet objectif, la figure 4.14, de la présente page, illustre l’introductionde conceptsde traces dans le métamodèle de déploiement.

FIG. 4.14:Exemple de métamodèle de déploiement (simple, avec trace)

Nous ne détaillerons pas plus cette approche dans la suite de ce rapport. Le templatedegénération de règles qui y est associé dépend du métamodèle de trace employé.

Organisation de la transformation

La figure 4.15 illustre l’organisation d’une transformation dont les règles de déploie-ment sont générées par untemplate24. Ce schéma enrichit la précédente organisation (fi-gure 4.12, page 112) d’un modèle de déploiement (Xdeployment) conforme au métamodèleque nous venons de présenter (Deployment). A partir de ce modèle et detemplatesmis à dis-position dans lepackagetemplates4rtepml, l’ensemble des règles de déploiement propres àl’application est généré (X2rtepml).

FIG. 4.15:Organisation d’une transformation de déploiement basée sur RTEPML (génération de règles).

Remarque : Pour des raisons didactiques, les éléments qui concernent les traces lors dudéploiement ne sont pas représentés dans la figure 4.15. Une vision globale et complète del’organisation d’une transformation de déploiement sera donnée en fin dechapitre.

24Lespackagesgénérés sont grisés sur le schéma.


4.4.4 Assistance au développement des fonctions

Outre les règles de correspondances, deux ensembles de fonctions (ou helpers) com-posent la transformation de déploiement. Le premier (X4rtepml) permet de localiser dans lemodèle de l’application les éléments qui concernent les propriétés, les services et les para-mètres qu’identifient RTEPML. Le second (X4platform) permet de traduire les valeurs et lesréférences extraites de ces éléments à destination de la plate-forme d’exécution cible.

Cependant, les fonctions du premier ensemble, quoique génériques à toutes les plates-formes, dépendent fortement du métamodèle de l’application, puisqu’elles nécessitent deparcourir les modèles. Celles du second ensemble sont de plus spécifiques à la plate-formecible. Une mise en œuvre générique de ces fonctions n’est donc pas envisageable.

Toutefois, le développement de ces fonctions peut être assisté. En effet, la généricitéde la transformation repose sur des conventions de nommage et d’interprétation de cesfonctions. Ces conventions s’appuient sur les rôles attribués aux éléments (propriétés, ser-vices ou paramètres) qu’adressent les fonctions. Par exemple, l’information qui permet derenseigner une priorité (priority) est accessible via un appel à une fonctiongetPropertydont le paramètre correspond au rôle de priorité dans RTEPML (priority). L’implantationde cette fonction consiste alors à appeler une seconde fonction dont le nom est déduit, parconvention, du nom du rôle passé en paramètre (getPriority dans cet exemple). De partcette convention, l’invocation des fonctions est générique. Les fonctions encapsulent d’unecertaine façon les informations contenues dans le modèle de l’application25.

Ainsi, si les conventions de nommage et d’interprétation des fonctions permettent deconcevoir des transformations génériques, et nécessitent donc de cadrer leur développe-ment, elles facilitent également ce cadrage. En effet, le nom et l’interprétation de chaquefonction sont entièrement liés au métamodèle de plate-forme d’exécution (RTEPML) ouplus précisément aux rôles des propriétés, services et paramètres qu’identifie le métamo-dèle. En se basant sur ce métamodèle, une méthodologie ou un outil d’assistance peut doncinciter un utilisateur a renseigner les fonctions associées aux propriétés,aux services ou auxparamètres qu’il est susceptible de mettre à contribution. Les noms des fonctions sont alorsdéterminés par la convention adoptée. Ils ne dépendent que des rôles attribués aux éléments(propriétés, services ou paramètres) qu’adressent les fonctions.

Par exemple, dès que le concept de ressource ordonnançable qu’identifie RTEPML

(SchedulableResource) est impliqué dans une correspondance, les fonctions relatives auxpropriétés associées à ce concept peuvent être demandées (telles quela priorité (priority) etla taille de la pile (stacksize)). Les signatures de ces fonctions, telle quegetPriority() pourla priorité etgetStackSize()pour la taille de la pile, sont alors connues de l’outil car impo-sées par une convention. L’utilisateur n’a donc qu’à renseigner le corps de ces fonctions quidécrit l’accès aux informations dans le modèle de l’application.

On remarquera enfin, que le corps de la fonction qui décrit l’accès auxinformations estformulé dans un langage propre à la technologie de transformation (par exemple, un sous-ensemble du langage OCL pour ATL). Ces accès pourraient également être capturés dans unmodèle indépendant de la technologie de transformation. Les corps des fonctions seraientensuite générés pour la technologie mise à contribution.

Les mises en œuvre des approches que nous venons d’évoquer ne seront pas détailléesdans la suite de ce rapport. Ces approches ouvrent des perspectives d’outillages associés auprocessus de déploiement que nous proposons.

25Il en est de même pour les informations contenues dans le modèle de la plate-forme cible. Mais, dans cecas, l’encapsulation est assurée par des fonctions fournies dans lepackagehelpers4rtepml. Le développementde ces fonctions n’est pas à la charge de l’utilisateur.


4.5 Choix de déploiement

Nous venons de définir un processus de déploiement basé sur des descriptions ex-plicites de plates-formes d’exécution. Ce processus repose sur des correspondances entreles concepts applicatif et les concepts exécutif qu’identifie un métamodèle de plate-formed’exécution (RTEPML). Cependant, la conception de l’algorithme qui a abouti à ce proces-sus de déploiement a été menée, jusqu’à présent, dans un contexte dans lequel :

1. Tout mécanisme applicatif est mis en œuvre avecau plusun concept exécutif (rela-tions 1-1) ou un ensemble de concepts exécutif (relations 1-N) ;

2. La plate-forme cible fournitau plusune ressource, ou un agencement de ressources,conforme à chaque concept (disponibilités 0 ou 1, avec ou sans prototype).

Un second contexte reste donc à explorer dans lequel plusieurs concepts ou plusieursressources sont envisageables pour la mise en œuvre d’un mécanisme applicatif26. Cettesection se focalise sur de tels choix, qualifiés de choix de déploiement.

4.5.1 Identification des choix

Deux ensembles de choix se distinguent lors d’un déploiement d’application. Le pre-mier, qualifié de «choix conceptuels», se réfère aux mises en œuvre d’un même méca-nisme applicatif avec des concepts ou des ensembles de concepts exécutif différents. Parexemple, les variables partagées et les tableaux noirs (blackboard, en anglais) fournissentdes supports différents pour un échange de données entre des tâches. Or, le métamodèle deplate-forme d’exécution RTEPML identifie d’une part chacun de ces concepts (respective-mentSharedDataComResourceet MessageComResource) et les plates-formes d’exécutionfournissent d’autre part des ressources conformes à l’un, à l’autre ou aux deux concepts.

Orthogonalement, une plate-forme d’exécution peut fournir différentesressources,ou agencements de ressources, conformes à un même concept exécutif.Le standardOSEK/VDX discerne par exemple les tâches susceptibles d’attendre un événement (exten-ded task) des tâches qui ne le peuvent pas (basic task). Ces deux types de tâches sont doncconformes au même concept de ressource ordonnançable qu’identifie RTEPML (Schedu-lableResource). Cet exemple implique que pour mettre en œuvre un mécanisme exécutif,certaines plates-formes d’exécution proposent un choix de ressources ou d’agencements deressources. Le second ensemble, qualifié de «choix pratiques», se réfère à ces choix.

La figure 4.16 illustre les deux ensembles de choix, sur la base de relations 1-1 entreconcepts applicatif et concepts exécutif, sans prototype de conception27.

FIG. 4.16:Choix de déploiementconceptuelset pratiques.

26Ou, respectivement, plusieurs ensembles de concepts ou plusieurs agencements de ressources.27L’illustration est transposable aux relations N-1, 1-N et N-M, et à l’intégration de prototypes de conception.

4.5. Choix de déploiement 119

Remarque : Face à un choix conceptuel, nous ne présumerons pas de la mise à dispo-sition par la plate-forme cible d’une ressource conforme à chacun des concepts impliqués.Les relations de conformités sont pour cela mises en pointillés dans la figure 4.16.

Enfin, une situation mixte dans laquelle interviennent des choix conceptuelset pra-tiques est également envisageable. L’introduction d’une gestion pour chacune des situations(conceptuelle et pratique) devra donc également satisfaire une situation mixte.

4.5.2 Prise de décision

La confrontation à un choix nécessite de prendre une décision. La gestion des choixlors d’un déploiement se concrétise donc par la capture et la prise en compte de décisionsrelatives aux choix que nous venons d’identifier. Dans ce but, cette sous-section vise à iden-tifier les différents support disponibles pour capturer ces décisions (que nous qualifieronsde décisions de déploiements), avant de statuer sur le support que nousadopterons.

Un choix conceptuelporte sur des concepts du métamodèle de plate-forme d’exécu-tion. Une décision relative à unchoix conceptuelinfluence donc l’application des règles àdestination de ces concepts (telles queRuleCa2RIa ouRuleCa′2RIa′ dans la figure 4.16).

Parallèlement, unchoix pratiqueporte sur des ressources de la plate-forme cible. Unedécision relative à unchoix pratiqueinfluence donc l’identification de la ressource qui typeune instance générée (B ouB′ dans l’exemple de la figure 4.16).

Ainsi, les décisions de déploiement relatives aux choix conceptuels et pratiques in-fluencent soit l’application, soit le déroulement des règles de transformations. Différentssupports permettent donc de les capturer. Une règle peut en effet êtreguidée à partir :

– dedonnées extraitesdes modèles de l’application et de la plate-forme cible,

– d’annotationsdans le modèle de l’application ou

– d’unmodèle dédiédisjoint des modèles de l’application et de la plate-forme cible.

Orienter l’exécution des règles, à partir de données extraites des modèlesde l’appli-cation et de la plate-forme cible, nécessite toutefois d’introduire dans la transformationdes mécanismes d’aide à la décision. En effet, selon cette approche, les décisions de dé-ploiements ne sont pas capturées mais déduites. Or, les mécanismes d’aide à ladécisionappartiennent à un domaine à part entière qui bénéficie d’algorithmes et d’outils spéciali-sés [20] [80]. Leur intégration dans une technologie de transformation de modèle ne noussemble donc pas pertinente. Cette première solution a donc été écartée. Des informationsissues d’un processus annexe de décision seront explicitement apportées à la transformationpour orienter l’exécution des règles.

Comme cela fut annoncé, un apport d’informations peut alors se matérialiser sous laforme d’annotations dans le modèle de l’application ou sous la forme d’un modèle dédié.

Cependant, l’annotation d’informations de déploiement dans un modèle d’applicationne concernent qu’une utilisation particulière du modèle. De plus, dans notre cas, les an-notations sont liées à une technologie (celle sur laquelle l’application est déployée). Ellesintroduisent donc des informations dépendantes d’une plate-forme dansun modèle vouluindépendant de celle-ci. Selon nous, cette pratique compromet la séparation entre modèlesdépendants et indépendants d’une technologie, que prône le MDA.

Par contre, l’approche qui consiste à isoler les informations propres aux décisions dedéploiements dans un modèle dédié s’accorde davantage avec une approche MDA. L’intro-duction d’un tel modèle, qualifié de «modèle de décisions», sera donc privilégié.


4.5.3 Modélisation des décisions

La modélisation de décisions nécessite de se conformer à un métamodèle. Dansle but decerner ce métamodèle, nous allons, dans un premier temps, identifier les décisions qu’il estnécessaire d’exprimer pour répondre aux choix que nous sommes susceptibles de rencontrer.Puis, nous discuterons de la forme que peuvent prendre ces décisions, avant de définir unmétamodèle à partir duquel les décisions pourront être formulées.

Identification des décisions

Comme cela vient d’être mentionné dans la sous-section précédente, les choix que noussommes susceptibles de rencontrer portent :

– sur les concepts du métamodèle de plate-forme d’exécution (RTEPML) ou– sur les ressources d’une plate-forme d’exécution cible.

Face à un choix, nous pouvons également imaginer que certaines mises en œuvre soientfavorables pour certains éléments de l’application, mais que d’autres mises en œuvre soientplus adaptées à d’autres éléments. Une décision de déploiement peut doncconcerner :

– tout élément conforme à un concept du métamodèle de l’application ou– seulement certains éléments du modèle de l’application.

Au bilan, pour ce qui concerne les relations 1-1, les décisions de déploiement doiventpouvoir refléter quatre types de correspondances :

– entre unconceptapplicatif et unconceptidentifié par RTEPML ;– entre unconceptapplicatif et uneressourcede la plate-forme d’exécution ;– entre certainsélémentsapplicatif et unconceptidentifié par RTEPML ;– entre certainsélémentsapplicatif et uneressourcede la plate-forme d’exécution.

Pour les relations 1-N, les décisions de déploiement doivent, en plus, pouvoir refléterdes correspondances avec plusieursconceptsou ressourcesde la plate-forme d’exécution.

Formulation des décisions

Nous avons vu, dans la sous-section précédente, que les décisions dedéploiement in-fluencent l’application ou le déroulement des règles de transformations. Cette influence sematérialise par des conditions au sein de la transformation, sous la forme, parexemple, depré-conditions d’application des règles ou de structures de contrôles.

Face à un choix, une telle condition évalue la décision qui répond à ce choix. Cettedécision peut alors prendre différentes formes.

La forme la plus simple se matérialise par un terme associé à une décision (décision A,décision B, etc). L’évaluation d’une décision consiste alors à identifier le terme retenu (sidécision =décision Aalors ...). Cette approche présente l’inconvénient de devoir définir unterme pour chaque décision envisageable. Elle compromet de plus la généricité des règlesde transformations (un terme arbitraire n’a rien de générique).

Pour pallier à ces limitations, une convention de définition des termes peut être ins-taurée. Dans le but de couvrir toutes les décisions envisageables, cette convention peut sebaser sur les correspondances que les décisions reflètent et imposerl’usage des termes desmodèles et des métamodèles impliqués. L’expression de décision qui ne concernent quecertains éléments du modèle de l’application n’est toutefois pas facilitée. Cette approchenécessite d’assister la formulation des décisions, pour en faciliter l’usage.


La troisième approche que nous ayons envisagée consiste à décrire explicitement lescorrespondances que reflètent les décisions. Cette approche s’apparente alors à la modéli-sation d’un déploiement, telle que nous l’avons introduite dans la sous-section précédente.L’idée sous-jacente est alors de générer une transformation qui intègre les décisions. Celles-ci ne sont plus évaluées dans la transformation.

Nous proposons donc d’étendre l’usage du métamodèle de déploiements présenté pré-cédemment, pour la modélisation des décisions de déploiement.

Un métamodèle de déploiement qui intègre des décisions

Le métamodèle de déploiement que nous avons introduit dans la sous-sectionprécédente(figure 4.13, page 114) permet de décrire des correspondances entre des concepts applicatifet exécutif auxquels des critères peuvent être associés.

Parallèlement, les décisions de déploiement que nous envisageons d’exprimer reflètentdes correspondances similaires. En effet, ces correspondances concernent soit des concepts,au même titre que pour un déploiement, soit des éléments du modèles de l’applicationoudu modèle de la plate-forme cible. Or, ces éléments peuvent également être discernés pardes critères sur les concepts auxquels ils se conforment. Le métamodèle de déploiement, telque nous l’avons défini, permet donc de décrire des décisions.

Cependant, ce métamodèle ne discerne pas, dans sa version actuelle, les critères quiprécisent des concepts et les critères qui relèvent d’une décision.

De plus, la seule description d’un modèle de décision dans le but de générer une trans-formation ne permet pas de séparer lescorrespondances de déploiement « théoriques »entreles concepts applicatif et les concepts exécutif, et lesdécisions de déploiementpropres àl’application et à la plate-forme cible. Un modèle de décisions peut même omettre certainescorrespondances de déploiement théoriques, si le déploiement visé n’en fait pas l’usage.

Pour pallier à la première limitation, nous proposons d’enrichir le métamodèle de dé-ploiement pour que les critères qui relèvent d’une décisions se distinguent. La figure 4.17illustre un exemple de métamodèle de déploiement ainsi enrichit.

Dans ce métamodèle, deux types de critères sont identifiés. Les premiers (criteria) pré-cises des concepts impliqués dans des correspondances théoriques. Alors que les seconds(decisions) reflètent des décisions prises face à des choix de déploiements. Ces derniers sontpotentiellement propres à l’application déployée et à la plate-forme cible.

On remarquera que, dans cette version, des paramètres peuvent accompagnés les cri-tères. Pour des raisons didactiques, ces paramètres ont été omis dans lesversions précé-dentes du métamodèle de déploiement (figures 4.13 et 4.14, pages 114 et 116). Commenous le verrons dans l’exemple qui suit, les paramètres des critères offrent simplement unefacilité d’implantation des prédicats dans des fonctions.

FIG. 4.17:Exemple de métamodèle de déploiement (simple, avec décisions)


Pour pallier à la seconde limitation, nous proposons de suivre une méthodologie deconception des modèles de déploiements. Cette méthodologie consiste à décriredans unpremier temps un «modèle de déploiement», tel que nous l’envisagions à l’origine. Ce mo-dèle capture les correspondances théoriques entre les concepts applicatif et exécutif (sansaucune décision face aux choix). Unmodèle de décisionraffine ensuite ce modèle en fonc-tion de l’application déployée et de la plate-forme cible.

Un modèle de déploiement décrit ainsi ce que l’onpeut déployer. Alors qu’un modèlede décisions décrit ce que l’onveut déployer.

Les listings 4.3 et 4.4 présentent un exemple de modèle de déploiement et du modèle dedécision qui le raffine.

-- implement application periodic activity-- with periodic scheduable resource

Activity [ categoryIs(’Periodic’) ]-> SchedulableResource [ typeIs(’Periodic’) ]

-- implement application subprogram with routineSubprogram

-> Routine

-- implement connection with shared dataConnection

-> SharedDataComResource

-- implement connection with message communicationConnection

-> MessageComResource

Listing 4.3:Exemple de modèle de déploiement (Robot vers RTEPML)

-- implement application periodic activity-- with periodic scheduable resource

-- refine : display activity -> basic taskActivity [ categoryIs(’Periodic’)] / jobIs(’Display’) /

-> SchedulableResource [ typeIs(’Periodic’) ] / kindIs(’BasicTask’) /

-- refine : control activity -> extended taskActivity [ categoryIs(’Periodic’) ] / jobIs(’Control’) /

-> SchedulableResource [ typeIs(’Periodic’) ] / kindIs(’ExtendedTask’) /

-- implement application subprogram with routineSubprogram

-> Routine

-- implement connection with shared data-- refine : used for the ’Com’ connection

Connection / nameIs(’Com’) /-> SharedDataComResource

-- implement connection with message communication-- refine : not used

Connection / false /-> MessageComResource

Listing 4.4:Exemple de modèle de décision (Robot vers OSEK/VDX)

Le premier modèle décrit les mises en œuvre possibles de mécanismes applicatif (dansles termes du métamodèle de robotique des exemples précédents) avec les concepts qu’iden-tifie RTEPML. Ce modèle reprend la description du listing 4.2, page 115 (la syntaxe stipulemaintenant les critères avec des fonctions et des paramètres).


On notera que ce modèle propose unchoix conceptuelpour la mise en œuvre d’uneconnexion. Une connexion peut en effet être assurée par une variable partagée (SharedDa-taComResource) ou par une communication par message (MessageComResource).

Le second modèle raffine le précédent modèle en y ajoutant des informations propre audéploiement d’une application sur une plate-forme OSEK/VDX.

Nous avons mentionné, en introduction de cette section, qu’une plate-formeOSEK/VDX

distinguait les tâches étendues, susceptibles d’attendre un évènement (extended task), destâches basiques qui ne le peuvent pas (basic task). En supposant que le modèle de la plate-forme OSEK/VDX que nous utilisons modélise deux types de ressources pour cela, le dé-ploiement d’une application de robotique se confronte alors à unchoix pratique. Toute ac-tivité peut en effet s’implanter dans une tâche basique ou étendue.

En réponse à ce choix, la mise en œuvre d’une activité que décrit le modèle de déploie-ment est raffinée. La correspondance initiale est dédoublée, et des critères sont associés auxconcepts applicatif et exécutif. Les activités d’affichages seront implantées par des tâchesbasiques alors que celles de controles le seront par des tâches étendues.

Parallèlement, en réponse au choix conceptuel que soumet le modèle de déploiement,les correspondances qui concernent les connexions sont également raffinées. Un critère per-mettant d’identifier un élément source par son nom est associée à la première. Alors que laseconde est neutralisée par un critère toujours faux. Lors d’un déploiement, seul l’élémentnommé «Com» sera ainsi mis en œuvre par une variable partagée. Aucune autre commu-nication ne sera implantée (ni par variable partagée, ni par échange de message).

Organisation de la transformation

En pratique, l’approche que nous venons de définir suit le processusde génération desrègles de correspondances présenté dans la sous-section précédente. Cette génération reposemaintenant sur un modèle de décisions dans lequel des critères supplémentaires ont étéintroduits, propres à l’application déployée et à la plate-forme considérée. La figure 4.18illustre l’organisation de ce processus de déploiement.

FIG. 4.18:Organisation d’une transformation de déploiement basée sur RTEPML (choix de déploiement).


La figure 4.18 regroupe dans un mêmepackage(X2Platform) les fonctions et le modèlede décision propres à la plate-forme cible (X4platformetApplication2Platform).

Dans ce même soucis de séparation des domaines et des technologies impliqués, unpackagehelpers4Xa été introduit. Cepackageregroupe les fonctions de parcours et de col-lecte d’informations propres au métamodèle de l’application mais indépendant de tout autremétamodèle. Cepackagecomprend, par exemple, les fonctions qui permettent d’exprimerdes critères sur les concepts ou les éléments applicatif.

Un exemple detemplatede génération de règles ATL compatible avec cette approcheest donné en annexe, page 187. Cetemplates’appuie sur le métamodèle de déploiement quenous venons d’étendre aux décisions.

4.6 Synthèse

Nous nous sommes intéressés, dans ce chapitre, à définir un processusde déploiementbasé sur le métamodèle de plate-forme d’exécution RTEPML. Ce processus permet de gé-nérer, par transformation de modèles, une description d’application spécifique à une plate-forme, à partir d’un modèle d’application indépendant de tout support d’exécution et dumodèle de la plate-forme cible.

L’algorithme de transformation au cœur du processus repose sur un mécanisme quenous avons qualifié d’« intégration d’applications ». Son principe consisteà instancier lesressources d’une plate-forme pour les besoins d’une application. Unedescription d’applica-tion spécifique à une plate-forme se concrétise alors par un modèle de la plate-forme enrichides instances de ressources qui mettent en œuvre l’application.

Nous avons constaté, qu’une intégration d’applications dans un modèle deplate-formed’exécution offrait des perspectives de transformations de déploiement en grande partiegénériques vis-à-vis des plates-formes cibles. Dans un premier temps, cechapitre s’est doncfocalisé sur le développement d’un algorithme de transformation qui confirme ce potentiel.

Transformations de déploiements génériques

Une transformation de déploiement par « intégration d’applications » se compose derègles de correspondances entre des concepts applicatif et des concepts exécutif. Ces cor-respondances décrivent les mises en œuvre de mécanismes applicatif avec les ressourcesque sont susceptibles de fournir les plates-formes d’exécution.

La généricité d’une transformation repose donc sur la généricité de ses règles de corres-pondances. Dans le but de concevoir des règles génériques au sein de l’algorithme que nousavons développé, cinq axes ont été abordés.

Le premier axe concernait l’identification des concepts mis en correspondance. Lesconcepts impliqués dans les transformations sont en effet identifiés par des noms de classesdans les métamodèles et peuvent être précisés par des critères. Nous avons alors admis queles critères envisagés se formulaient dans les termes des métamodèles. Leurintroductiondans l’algorithme s’accorde donc avec des règles génériques.

Le second axe concernait les relations de correspondances susceptibles d’être mises enœuvre par les règles. L’algorithme a ainsi été conçu pour répondre auxrelations 1-1, 1-N,N-1 et N-M entre les concepts applicatif et les concepts exécutif.

Un métamodèle de trace a de plus été introduit pour valider la gestion des élémentsquine sont pas mis à contribution lors d’un déploiement (relations 1-0 ou N-0).Ce métamodèlen’a pas été précisé dans ce rapport. Toutefois, nous avons souligné que la généricité d’une

4.6. Synthèse 125

transformation peut être assurée par l’usage d’un métamodèle de trace qui se contente d’ac-cès génériques aux éléments des modèles (par des attributs de nommage ou des références).

La troisième axe, proche du précédent, s’est intéressé à la disponibilité, sur les plates-forme d’exécution, de ressources conformes à des concepts mis à contribution dans lesrègles de correspondances. Un mécanisme générique de détection d’indisponibilités a doncété instauré. Ce mécanisme repose également sur un métamodèle de trace.

Le quatrième axe concernait la gestion des artefacts de modélisation que fournitRTEPML. Des mécanismes génériques de mises en œuvre de prototypes de conception, derenseignements des propriétés et de générations d’appels de servicesont alors été introduitsdans l’algorithme.

Enfin, le dernier axe, transversal aux précédents, a introduit un principe d’encapsula-tion, par des fonctions, des accès aux éléments des modèles qui se destinent à renseignerles propriétés ou les appels de services. La généricité des accès est alors assurée par uneconvention de nommage et d’interprétation des fonctions. Cette convention s’appuie sur lesnoms des rôles attribués aux propriétés et aux services dans RTEPML.

A l’issu de l’exploration de ces cinq axes, trois ensembles de règles et quatre de fonc-tions, qui composent une transformation de déploiement, ont été identifiés, selon leur dé-pendances aux technologies impliquées.

Le tableau 4.2 résume ces dépendances vis-à-vis du métamodèle de l’application(MMa), du métamodèle de plate-forme d’exécution (RTEPML), d’une plate-forme cible(PDM) et d’un métamodèle de trace (MMt).

MMa RTEPML PDM MMt

règles de correspondances ✓ ✓

règles de mises en œuvre des artefacts de RTEPML ✓

règles de générations de traces ✓

expression des critères associés aux concepts exécutif ✓

localisation d’éléments dans un modèle de plate-forme ✓

expression des critères associés aux concepts applicatif ✓

localisation d’éléments dans le modèle de l’application ✓ ✓

traduction des informations d’une technologie à une autre✓ ✓ ✓

TAB . 4.2:Règles et fonctions mises à contribution dans une transformation de déploiement.

Nous avons donc constaté qu’aucune règles de transformation ne dépendait de la plate-forme cible, et que seules les règles de mise en correspondance des concepts applicatif etdes concepts exécutif dépendaient du métamodèle de l’application. Les règles introduitesdans l’algorithme de déploiement sont donc non seulement génériques vis-à-vis des plates-formes d’exécution, mais une partie de celles-ci peut également être partagée entre desprojets qui impliquent différentes technologies de modélisations d’applications.

De même, les fonctions qui concernent les plates-formes d’exécution sont indépen-dantes de ces technologies. Elles s’expriment uniquement dans les termes du métamodèlede plate-forme d’exécution. La considération d’une technologie de modélisation d’appli-cation se concentre alors sur trois ensembles de fonctions, dont l’un sera propre à chaqueplate-forme cible (pour l’interprétation des données d’une technologie à une autre).

Comme cela fut mentionné dans ce chapitre, une assistance au développement de cesfonctions est envisageable.


Un langage dédié au déploiement d’application

A l’issue de cette première phase de développement de l’algorithme, nous avons éga-lement constaté que les structures des règles de correspondances et des règles de tracesétaient constantes. Seules les informations relatives aux concepts impliquéschangent d’unerègle de correspondance ou d’une règle de trace à l’autre. Destemplatesou des transforma-tions de modèles, renseignés par des modèles qui capturent les correspondances entre lesconcepts peuvent donc les générer.

Nous avons donc défini, un métamodèle de déploiement dédié à ces captures. Cettepremière version du métamodèle permettait de décrire, par leur nom, les concepts mis enrelation ainsi que les critères qui les précisent.

Outre la formulation synthétique des correspondances, cette approche al’avantage decapturer les déploiements dans des modèles indépendants des technologiesde transforma-tions mises à contribution. Il est en effet envisageable de changer ces technologies en conser-vant les modèles de déploiement. Ceux-ci permettront toujours de renseigner destemplatesde règles adaptés aux nouvelles technologies.

Cette indépendance vis-à-vis de la technologie est valable dans les limites descontraintes que nous avons soulignées. L’implantation de l’algorithme nécessite en effetque la technologie de transformation permette d’exprimer des prédicats sur les élémentsdes modèles, offre un contexte impératif pour l’exécution de certaines règles et supportedes conditions sur le déroulement des règles.

Prise en compte des choix de déploiement

Enfin, nous sommes intéressés aux choix de déploiement auxquels nous étions suscep-tibles d’être confrontés. Deux ensembles de choix ont alors été identifiés.Le premier, quali-fié de « choix conceptuels », se réfère aux mises en œuvre d’un même mécanisme applicatifavec des concepts ou des ensembles de concepts exécutif différents. Le second, qualifié de« choix pratiques », se réfère à la mise à disposition, par une plate-forme cible, de plusieursressources conformes à un même concept exécutif.

La confrontation à un choix nécessitant de prendre une décision, le métamodèle dedéploiement que nous venions d’introduire a été étendu pour capturer des décisions. Enréponse à un choix, une décision prend alors la forme d’une correspondance entre desconcepts précisés par des critères.

Deux types de modèles de déploiement se distinguent alors. Un « modèle de déploie-ment », tel que nous l’envisagions à l’origine, décrit les correspondances théoriques entreles concepts applicatif et les concepts exécutif, sans aucune décision face aux choix. Des« modèles de décisions » peuvent ensuite raffiner un modèle de décision enprécisant descorrespondances et des critères qui répondent à des choix.

Un modèle de décision est indépendant des modèles de l’application et de la plate-formecible. Il décrit ce que l’on peut déployer. Un modèle de décision dépendde ces modèles. Ildécrit ce que l’on veut déployer.

Un modèle de décision peut maintenant servir de support pour générer une transforma-tion de déploiement. Cette transformation intègre les décisions prises face auxchoix.

Processus de déploiement

La figure 4.19, page ci-contre, illustre le processus de déploiement auquel nous avonsabouti. Ce processus s’appuie sur quatre métamodèles : le métamodèle de plate-forme

4.6. Synthèse 127

d’exécution RTEPML, un métamodèle de trace (Trace), un métamodèle de déploiement (De-ployment) et un métamodèle d’application (X).

A partir d’un modèle d’application (Application) et d’un modèle de plate-forme d’exé-cution (Platform), le processus génère un modèle de l’application déployée sur la plate-forme (Appl.rtepml) et un modèle de trace (Appl.trace).

Pour mieux séparer les préoccupations, les règles de transformations, les fonctions et lestemplatesde génération impliqués dans le processus sont répartis dans différentspackages.

D’un point de vue utilisateur, la transformation au cœur du processus se compose :

– d’un modèle de déploiement (Xdeployment) ;– d’un modèle de décisions (Application2Platforme) ;– d’un ensemble de critères sur les éléments de l’application (helpers4X) ;– d’un ensemble de fonctions de collecte d’informations (X4rtepml) ;– d’un ensemble de fonctions de traduction d’informations (X4platforme).

D’un point de vue pratique, le processus de déploiement proposé fourni :

– un ensemble de règles de transformations pour :– la gestion des artefacts de RTEPML (rules4rtepml) ;– la génération de traces (rules4trace) ;

– un ensemble de fonctions de critère et de collecte d’informations sur les plates-formes(helpers4rtepml) ;

– un ensemble detemplatespour :– la génération des règles de correspondances (templates4rtepml) ;– la génération des règles de traces (templates4trace).

Enfin, à partir destemplateset d’un modèle de décision, le processus génère les règlesde correspondances utiles au déploiement (X2rtepml).

FIG. 4.19:Organisation d’un processus de déploiement d’application basé sur RTEPML.


Conception d’un déploiement

Comme cela fut évoqué dans ce chapitre, un outillage d’aide à la conception de déploie-ments peut accompagner le processus proposé.

Nous avons par exemple mentionné la possibilité d’outiller le développement desfonc-tions, tant pour l’expression des critères (helpers4X) que pour la localisation et la traductiond’informations (X4rtepmletX4platform).

D’autres perspectives d’outillages concernent également la description des déploie-ments (XdeployementetApplication2Platform).

Pour ce qui concerne la forme (ou la syntaxe), ces descriptions se réfèrent en particulierau métamodèle de l’application et au métamodèle de plate-forme d’exécution (RTEPML).Une interface dédiée à la manipulation des éléments des métamodèles peut donc être four-nie aux utilisateurs (telle qu’une interface graphique qui met à disposition lesélémentssusceptibles d’être référencés et qui offre des facilités de mises en correspondance, commele proposent déjà certains travaux [10] [34]).

Pour ce qui concerne le fond, un modèle de décisions peut bien entenduêtre issu d’uneréflexion personnelle de l’utilisateur. Mais, il peut également être issu d’un processus an-nexe d’aide à la décision, lui aussi outillé [20] [66] [80]. Une interfaceavec des outils d’aideà la décision est donc à prévoir. Un échange avec de tels outils nécessite en particulier dedécrire les choix possibles (issus du modèle de déploiement) [25], de formuler des critèressur des ressources identifiées (telle que la minimisation de l’espace mémoire et des tempsd’exécution) [81] [105] et de traduire les décisions prises dans les termes du métamodèlede déploiement. Une étude est actuellement menée pour mettre en œuvre cette approche.

5Évaluation

Sommaire5.1 Expérimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

5.1.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1315.1.2 Outillage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1315.1.3 Processus comparés . . . . . . . . . . . . . . . . . . . . . . . 132

5.2 Critères de comparaison . . . . . . . . . . . . . . . . . . . . . . . . 1345.3 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

5.3.1 Composantes pour l’application . . . . . . . . . . . . . . . . . 1355.3.2 Composantes pour l’exécution . . . . . . . . . . . . . . . . . . 1355.3.3 Composantes pour la transformation . . . . . . . . . . . . . . .1385.3.4 Choix de déploiement . . . . . . . . . . . . . . . . . . . . . . 141

5.4 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Ce chapitre propose une évaluation du processus que nous venons de définir. Cette éva-luation repose sur une comparaison avec d’autres approches de déploiement identifiées

dans l’état de l’art de ce rapport. Ce chapitre vise à compléter la comparaison initiée durantcet état de l’art et confirmer les résultats qui ont motivés cette étude.

Pour cela, une première section introduit le contexte et l’outillage des expérimentationsque nous avons menées, ainsi que les processus de déploiements expérimentés et comparés.Les critères de comparaisons sont ensuite définis. Puis, les résultats quenous avons obtenussont présentés et commentés, avant de conclure.

5.1. Expérimentations 131

5.1 Expérimentations

Le processus de déploiement que nous venons de définir repose sur des descriptions ex-plicites de plates-formes d’exécution. Ce processus offre une alternative aux considérationsimplicites des plates-formes, telles que le pratiquent d’autres approches dedéploiementidentifiées dans l’état de l’art de ce rapport. Plusieurs expérimentations ont donc été menéespour comparer ces différentes approches avec le processus que nous venons de proposer.

5.1.1 Contexte

Les expérimentations menées s’inscrivent dans un processus de génération de codeconforme à des standards du domaine de l’embarqué et du temps réel (tels que OSEK/VDX

ou ARINC-653), à partir de descriptions AADL ou de DSL « maison » d’applications derobotiques. Nous abordons, dans cette partie, la première phase de ce processus (figure 5.1).Cette phase est consacrée à la transformation d’un modèle d’application indépendant dusupport d’exécution, en un modèle dépendant de ce support. La seconde phase, que nous nedétaillerons pas, fut assurée par des technologies de génération de code partemplates.

FIG. 5.1:Processus de déploiement sur une plate-forme d’exécution : expérimentations.

Les applications développées durant ces expérimentations se constituaient de traite-ments concurrents périodiques ou apériodiques, identifiés comme des tâches communicantentre elles ou avec l’environnement.

5.1.2 Outillage

Les expérimentations autour de descriptions AADL ont été menées sur des modèlesconformes au métamodèle standard d’AADL (métamodèle au format Ecore, intégré dansl’outil O SATE [104]). Ce métamodèle se compose de sept packages (core, component, fea-ture, connection, flow, propertyet instance) qui totalisent 198 classes.

Les DSL « maison », ainsi que les métamodèles propres à chacune des approches (méta-modèles des plates-formes d’exécution, RTEPML, métamodèle de déploiement et métamo-dèle de trace) ont été développés avec les outils AMMA (ATLAS Model Management Archi-tecture) [65] tels que KM3 (Kernel Meta Meta Model) [56] pour les syntaxes abstraites etTCS (Textual Concret Syntax) [57] pour les syntaxes textuelles concrètes.

L’atelier TOPCASED(The Open-Source Toolkit for Critical Systems) [41] a été mis àcontribution pour la génération de syntaxes graphiques et l’intégration des différents outilsdans un atelier commun (figure 5.2, page suivante).

Les transformations de toutes les expérimentations ont été développées en ATL. Le lan-gage Acceleo, ainsi que l’outil éponyme associé [83], ont été utilisés pour développer etappliquer lestemplatesde génération de règles ATL et de génération des codes source desapplications (durant la seconde phase du processus).

132 Chapitre 5. Évaluation

FIG. 5.2:Éditeurs développés et intégrés à l’atelier TOPCASEDpour mener les expérimentations.

5.1.3 Processus comparés

Comme cela fut mentionné en introduction de cette section, le processus de déploiementproposé dans cette étude s’appuie sur des descriptionsexplicitesde plates-formes d’exécu-tion. Les informations relatives aux plates-formes sont capturées dans des modèles.

Parallèlement, d’autres approches de déploiement, identifiées dans l’état de l’art, re-posent sur des représentationsimplicites des plates-formes. Ces approches capturent lesinformations relatives aux plates-formes dans des métamodèles. Leur principe de déploie-ment consiste alors à générer un modèle de l’application conforme au métamodèle de laplate-forme à laquelle l’application se destine.

La figure 5.3, page ci-contre, illustre les processus de déploiement associés à ces ap-proches. Les deux premières sous-figures (5.3a et 5.3b) décrivent les processus basés surdes descriptions implicites de plates-formes. Le premier processus génèredirectement unmodèle d’application. Le second se scinde en deux étapes qui s’articulent autour d’uneplate-forme abstraite pivot. Le principe de ces deux approches a été présenté dans le chapitrede l’état de l’art. Enfin, la troisième sous-figure (5.3c) reprend le processus de déploiementque nous avons proposé à l’issue de cette étude.

5.1. Expérimentations 133

(a) Plate-forme implicitement décrite.

(b) Plate-forme implicitement décrite, avec pivot.

(c) Plate-forme explicitement décrite, avec RTEPML.

FIG. 5.3:Processus de déploiements d’applications sur des plates-formes d’exécution.


Chacune des approches de déploiement implique un certain nombre de « composantes »(oupackages) que l’on peut répartir en trois familles :

– Les composantes liées à latechnologie de l’application, telles que les métamodèleset les modèles d’applications, et les fonctions (ouhelpers) facilitant l’accès aux in-formations de ces modèles et l’expression de critères sur leurs éléments ;

– Les composantes liées à latechnologie d’exécution, telles que les métamodèles desplates-formes d’exécution ou du pivot, le métamodèle RTEPML, les modèles deplates-formes d’exécution et les fonctions facilitant l’accès aux informations des mo-dèles et l’expression de critères sur leurs éléments ;

– Les composantes liées auxtransformations, telles que les règles de correspondances,les modèles de déploiements, les librairies de règles, lestemplatesde génération derègles et les fonctions de traduction des valeurs d’une technologie à uneautre.

Au sein de cette dernière famille nous pouvons également discerner les composantesdédiées à un ou plusieurs déploiements. La figure 5.3 regroupe ces composantes dans despackagesestampillés «transformation».

Nous proposons donc dans la suite de ce chapitre de comparer les trois approches iden-tifiées en nous appuyant sur le développement des composantes au sein de chaque famille.

5.2 Critères de comparaison

Pour cette évaluation, notre attention se porte sur cinq critères : (1) les connaissancesrequises pour le développement des composantes, (2) leurs temps de développement, (3)leurs tailles, (4) leurs maintenances et (5) leurs réutilisations possibles.

L’estimation des connaissances requises impacte le public d’ingénieurs susceptibles dedévelopper les composantes et la capacité à répartir ces développements entre des ingénieursspécialisés. La séparation des connaissances entre les différentes composantes est l’un desobjectifs affichés d’une ingénierie dirigée par les modèles. Les connaissances identifiéesdans cette étude se répartissent entre le domaine de l’application, la plate-forme d’exécutioncible et le domaine plus général du temps réel et de l’embarqué.

Le temps de développement impacte l’aspect économique de la mise en œuvre d’un pro-jet. Ce temps doit toutefois être relativisé par la réutilisation possible des composantes. Uneactivité dont le temps de développement et la réutilisation sont élevés classe,par exemple,cette activité dans une approche d’investissement dont le profit est mesuré sur le long terme.

La réutilisation des différentes composantes porte dans cette étude sur l’utilisation quipeut être faite d’une même composante pour le déploiement d’une application si l’une destechnologies change (pour l’applicatif ou l’exécutif). Le changement auquel nous faisonsréférence concerne un changement radical de technologie. L’adaptation des composantessuite à une évolution de l’une des technologies ne sera pas abordée dansce rapport. L’effortà fournir pour une telle évolution est impacté par la capacité de maintenance des compo-santes, si les modifications à apporter sont manuelles. La considération etl’automatisationde l’évolution de certaines composantes, telles que les transformations, font l’objet d’étudesà part entière qui n’ont pas été mises en relation avec les travaux présentés dans ce rapport.

La taille des composantes impacte la lisibilité, la capacité de manipulation et le risqued’introduction de fautes. La taille est généralement corrélée avec le temps de développementet la facilité de maintenance.

Enfin, la prise en compte de décisions face à des choix de déploiement sera égalementabordée pour ce qui concerne les transformations.

5.3. Résultats 135

5.3 Résultats

Comme cela fut annoncé précédemment, cette partie présente successivement les ré-sultats sur le développement des composantes propres aux applications, aux technologiesd’exécution et aux transformations impliquées dans un déploiement.

5.3.1 Composantes pour l’application

Dans chacune des approches identifiées, les composantes propres aux applications im-pliquées dans un déploiement sont :

– le métamodèle de l’application (notéX, dans les processus de la figure 5.3) ;– le modèle de l’application à déployer (Application) ;– les fonctions qui facilitent le parcours de ces modèles et précisent descritères sur

leurs éléments (helpers4X).

Du point de vue du déploiement, le métamodèle et le modèle de l’application sont consi-dérés fournis et identiques pour chaque approche. Nous avons en effet écarté la possibilitéd’introduire des informations relatives aux déploiements dans ceux-ci.

Par contre, les fonctions de parcours des modèles et d’expressions des critères ont étédéveloppées dans le cadre des déploiements. Cependant, aucune différence n’a été constatéeentre ces fonctions d’une approche à une autre. Dans tous les cas, lesbesoins de parcoursdes modèles ou d’expression des critères ont été identiques. Quelque soit l’approche, laconsidération des éléments du modèle de l’application fut la même.

Ainsi, les développements des composantes relatives au domaine de l’application sontidentiques dans les approches que nous avons identifiées.

5.3.2 Composantes pour l’exécution

Toutes approches confondues, les composantes propres aux supports d’exécution impli-quées dans un déploiement sont :

– les métamodèles des plates-formes (Platform, dans les approches implicites) ;– le métamodèle d’un pivot (Pivot) ;– le métamodèle de plate-forme d’exécution (RTEPML) ;– les modèles des plates-formes (Platform, dans l’approche explicite) ;– les fonctions qui facilitent le parcours des modèles conformes aux métamodèles que

nous venons de mentionner et qui précisent des critères sur leurs éléments (hel-pers4platform, helpers4pivotethelpers4rtepml).

Les tableaux 5.1 et 5.2, page suivante, résument les résultats relatifs auxdéveloppementsde ces composantes pour chacune des approches.

Le tableau 5.1 se focalise sur le développement des modèles et des métamodèles1.Ceux-ci concernent les plates-formes d’exécution cibles ou plus généralement le domainedu temps réel et de l’embarqué.

Ce tableau rappelle que les approches qui décrivent implicitement les plates-formesd’exécution nécessitent le développement d’un métamodèle pour chaque plate-forme envi-sagée. L’approche par pivot introduit de plus un second métamodèle pour la description desapplications déployées sur la plate-forme abstraite intermédiaire qui joue le rôle de pivot.

1Dans ce tableau,MM se réfère à un métamodèle,M à un modèle et la plate-forme est qualifiée decible.


Parallèlement, l’approche que nous proposons s’appuie sur un seul métamodèle(RTEPML) pour décrire explicitement les plates-formes d’exécution. La considération dechacune se concrétise alors par le développement d’un modèle conformeà ce métamodèle.

Description impliciteDescription explicite


MMcible MMpivot MMcible RTEPML Mcible

Domaine cible ETR cible ETR cible

Temps + − + − ++

Taille + − + − ++

Maintenance + + + + ++

Réutilisation − + − ++ −

Domaine: cible (plate-forme cible),ETR(embarqué temps réel) ;Temps de développement: − (∼mois),+ (∼ semaines),++ (∼ jours) ;Taille (en classes): − (∼ 50),+ (∼ 40),++ (∼ 30) ;Maintenance, Réutilisation: − (mauvaise),+ (bonne),++ (très bonne) ;

TAB . 5.1:Développement des métamodèles et des modèles.

Les résultats qui concernent les deux premières approches ont été présentés et commen-tés dans l’état de l’art de ce rapport. Nous y avons souligné que, lors d’un changement deplate-forme cible, seule quelques parties du métamodèle qui décrit implicitement laplate-forme d’origine peuvent être réutilisées (par exemple, celles qui traitent des notions defonction et d’appel de fonctions, communes à différentes plates-formes). Par contre, la se-conde approche investit dans le développement d’un pivot mis à contribution dans tous lesdéploiements, quelque soit l’application ou la plate-forme envisagée. L’intérêt de cet inves-tissement sera souligné dans la sous-section suivante qui présente les transformations dedéploiement associées à chacune des approches.

La mise en œuvre d’un métamodèle pivot a toutefois nécessité plusieurs mois pour étu-dier, classer et organiser, dans ce métamodèle, les différents conceptsqu’offrent les plates-formes d’exécution du domaine du temps réel et de l’embarqué.

La troisième approche, que nous proposons, investit dans le développement d’un méta-modèle de plate-forme d’exécution (RTEPML). Le temps consacré au développement de cemétamodèle fut équivalent à celui du développement du pivot de l’approche précédente.

Cependant, RTEPML permet de décrire les plates-formes d’exécutionet les applicationsdéployées sur ces plates-formes. Il est donc sollicité en amont du processus de déploie-ment, pour modéliser les plates-formes cibles, et pendant le processus, pour déployer lesapplications. Tout déploiement d’application s’appuie donc essentiellementsur celui-ci.

Enfin, comme cela vient d’être mentionné, cette approche décrit explicitementlesplates-formes dans des modèles. Le développement, la taille et la maintenance deces mo-dèles sont alors beaucoup plus avantageux qu’une description dans un métamodèle. Ce bé-néfice est essentiellement dû à l’absence de mécanismes (ou d’artefacts)de modélisation àinclure dans un modèle de plate-forme. Ce dernier capture uniquement les informations quiconcernent la plate-forme, alors qu’un métamodèle qui capture implicitement ces informa-tions se destine avant tout à décrire des applications.

5.3. Résultats 137

Les deux dernières approches offrent donc une meilleure considération de plates-formesalternatives, sous réserve d’un investissement relativement conséquent, de l’ordre de plu-sieurs mois, pour le développement d’un métamodèle pivot ou d’un métamodèlede plate-forme d’exécution. L’approche proposée dans cette étude montre toutefois de meilleurs per-formances en termes de réutilisation et de réactivité sur un changement de plate-forme cible.

Le tableau 5.2 résume les résultats relatifs aux développements des fonctionsd’accèsaux informations des modèles2. Ces fonctions servent pour collecter des données et pourexprimer des critères sur les éléments des modèles. Elles s’appuient pour cela sur les méta-modèles que nous venons d’évoquer. Elles trouvent leur utilité lors des transformations etsont donc à la jonction entre les préoccupations de modélisation et de transformation.



Fcible Fpivot Fcible Frtepml

Domaine cible ETR cible ETR

Temps ++ + ++ −

Taille + + + +

Maintenance + + + +

Réutilisation − ++ − ++

Domaine: cible (plate-forme cible),ETR(embarqué temps réel) ;Temps de développement: − (∼mois),+ (∼ semaines),++ (∼ jours) ;Taille (en lignes): − (∼ 5.103), + (∼ 103), ++ (∼ 5.102) ;Maintenance, Réutilisation: − (mauvaise),+ (bonne),++ (très bonne) ;

TAB . 5.2:Développement des fonctions d’accès aux informations des modèles.

En prenant comme référence le développement des fonctions de la première approche,nous constatons que l’investissement dans un pivot, de la seconde approche, nécessite undéveloppement supplémentaire pour associer des fonctions à ce pivot. Cet investissementreste toutefois modeste (comparé à l’étude et au développement du pivot) et rentable enraison de la forte réutilisation de ces fonctions. Quelque soient la technologie source et laplate-forme cible, ces fonctions sont conservées.

Le développement de fonctions associées à RTEPML fut quant à lui beaucoup plus long.La présence d’artefacts de modélisation, tels que l’héritage ou la gestion des prototypesde conception, a nécessité plus de réflexion et de compétences techniques pour la mise enœuvre des accès que nous souhaitions fournir. Cette approche nous épargne cependant ledéveloppement de nouvelles fonctions dans le cas d’un changement de plate-forme cible.Les fonctions associées à RTEPML sont génériques à toute technologie de modélisation del’application sourceet toute plate-forme cible.

L’approche par pivot nécessite donc un développement supplémentaire de fonctionspour accéder aux informations d’un pivot, alors que l’approche proposée dans cette étudeinvestit dans un ensemble de fonctions génériques pour accéder aux informations de toutesles plates-formes cibles.

2Dans ce tableau,F se réfère à un ensemble de fonctions. L’indice associé rappelle la technologie concernée.


5.3.3 Composantes pour la transformation

Toutes approches confondues, les composantes propres aux transformations impliquéesdans un déploiement d’application sont :

– les règles de correspondances (X2platform, X2pivotetpivot2platform) ;– les librairies de règles (rules4rtepmlet rules4trace, pour l’approche explicite) ;– lestemplatesde génération de règles (templates4rtepmlet template4trace) ;– les modèles de déploiements (XdeploymentetApplication2Platform) ;– les fonctions de traduction de valeurs d’une technologie à une autre (X4platform,

X4pivot, pivot4platformetX4rtepml).

Le tableau 5.3, page ci-contre, résume les résultats relatifs aux développements de cescomposantes pour chacune des approches. Le premier sous-tableau se focalise sur le déve-loppement des règles de correspondances, des modèles de déploiementet destemplatesdegénération de règles. Le second traite des fonctions de traduction de valeurs3.

Les transformations mises en œuvre dans les différentes approches s’appuient toutes surle même principe de développement : des règles de correspondances associent des conceptsidentifiés par les métamodèles sources et cibles impliqués, et des fonctions traduisent lesvaleurs manipulées par chacune des technologies associées.

La première approche pratique une correspondance directe entre les concepts de l’ap-plication et ceux de la plate-forme d’exécution. Les approches suivantes introduisent desconcepts plus abstraits liés à un domaine commun entre toutes les plates-formes.

Dans la seconde approche, ces concepts sont capturés dans un pivot. Cette approcheconduit à une scission du processus de déploiement en deux transformations. Un ensemblede fonctions de traduction de valeurs est alors associé à chacune des transformations.

Dans la troisième approche, ces mêmes concepts sont capturés dans un métamodèle(RTEPML). Cette approche nous a permis de répartir les règles de correspondances entredeux ensembles de règles. Le premier offre des règles génériques à toutes les plates-formeset toutes les applications. Le second se compose de règles générées à partir de templates.

Un déploiement d’application consiste alors à renseigner cestemplates, à partir de mo-dèles de correspondances. Un modèle de déploiement, indépendant de laplate-forme cible,décrit les correspondances entre les concepts applicatif et les concepts que sont susceptiblesde fournir les plates-formes d’exécution. Un modèle de décision raffine ensuite un modèlede déploiement pour une application et une plate-forme cible précises.

Une transformation se compose donc de deux modèles qui capturent des correspon-dances et d’une librairie de règles et detemplatespour appliquer ces modèles.

Enfin, cette troisième approche introduit un ensemble de fonctions chargées de localiserles informations dans le modèle de l’application avant que d’autres fonctionsles traduisent.

Les résultats qui concernent les règles de transformations des deux première approchesont été justifiés et commentés dans l’état de l’art de ce rapport. Nous y avons conclu que lapremière approche ne semble intéressante que lorsque très peu de plates-formes d’exécutioncibles sont envisagées. Dans le cas contraire, l’investissement dans le développement d’unpivot peut s’avérer rentable.

En effet, les transformations de la première approche sont figées sur le domaine ap-plicatif et sur la plate-forme d’exécution traitée. Toute considération d’uneplate-forme al-ternative nécessite le développement complet d’une nouvelle transformation. De plus, leur

3Dans ces tableaux,R se réfère à un ensemble de règles,M à un modèle de déploiement etF à un ensemblede fonctions. Les indices associés rappellent les traductions concernées.

5.3. Résultats 139

développement et leur maintenance sont réservés à des experts du domaine applicatif etdes plates-formes d’exécution ciblées. Alors que l’introduction d’un pivot répartit ces com-pétences de part et d’autre du pivot, ce qui facilite non seulement la réutilisation de cha-cune des transformations, mais également leur développement et leur maintenance, tout enconservant des temps de développement du même ordre que pour l’approche précédente.



Rapp2cible Rapp2pivot Rpivot2cible M(1)app2rtepml M

(2)app2cible R

(3)lib

Dom.application application ETR application application

RTEPML

cible ETR cible ETR cible

Tps. + + ++ ++ ++ −

Tai. − − + ++ ++ −

Mnt. − + + ++ ++ +

Réu. − + + + −− ++

(1) Modèle de déploiement (conforme au métamodèle de déploiement).(2) Modèle de décisions (conforme au métamodèle de déploiement).(3) Concerne les librairies de règles génériques et lestemplatesde génération de règles.



Fapp2cible Fapp2pivot Fpivot2cible F(1)app2rtepml F

(2)app2cible

Domaineapplication application ETR application application

cible ETR cible ETR cible

Temps + + ++ + ++

Taille + + + + +

Maintenance − + + + +

Réutilisation − + + + −

(1) Fonction de localisation d’informations (pour les propriétés et les appels de services).(2) Fonction de traduction d’informations (pour les propriétés et les appels de services).

Domaine: cible (plate-forme cible),ETR(embarqué temps réel) ;Temps de développement: − (∼mois),+ (∼ semaines),++ (∼ jours) ;Taille (en lignes): − (∼ 103), + (∼ 5.102), ++ (∼ 102) ;Maintenance, Réutilisation: −− (très mauvaise) à++ (très bonne) ;

TAB . 5.3:Développement des composantes de transformations.

La troisième approche, que nous avons développée durant cette étude,investit dans unensemble de règles génériques à toutes les plates-formes d’exécution et toutes les applica-tions. Son développement, relativement long, a accompagné la mise en œuvredu métamo-dèle de plate-forme d’exécution sur lequel il s’appuie.


La généricité de ces règles leur confère une capacité de réutilisation très élevée. Toutdéploiement d’application s’y réfère, quelque soient la technologie source et la plate-formed’exécution cible. De plus, la taille, en nombre de lignes, de ces règles n’altère pas leurmaintenance, qui ne dépend que du métamodèle de plate-forme d’exécution (RTEPML).

L’ensemble de règles, que nous venons de mentionner, s’accompagne de templatesdegénération de règles. Cestemplatessont impliqués dans tous les déploiements. Ils per-mettent de réduire l’expression des correspondances, entre les concepts applicatif et lesconcepts exécutif, nécessaires aux déploiements.

L’élaboration d’un déploiement se concrétise alors, dans un premier temps, par le dé-veloppement d’un modèle de déploiement et d’un ensemble de fonctions de localisationd’information. Un modèle de déploiement exprime des correspondances entre les conceptsdu domaine de l’application et ceux qu’identifie RTEPML (indépendamment de toute plate-forme d’exécution). Les fonctions de localisation identifient les éléments du modèle del’application susceptibles de renseigner des propriétés ou des appels deservices.

Un modèle de correspondance est concis sur l’expression des règles, ce qui favoriseles temps de développement et la maintenance. De plus, l’absence de concepts propres auxplates-formes cibles lui confère une capacité de réutilisation relativement élevée. Un modèlede déploiement est générique à toutes les plates-formes cibles.

Pour les mêmes raisons, les fonctions de localisation développées en parallèle bénéfi-cient également d’un fort taux de réutilisation. De plus, comme cela fut mentionné dans cerapport, une assistance à leur développement est envisageable. Leurtemps de développe-ment et leur maintenance en serait alors améliorés.

L’élaboration d’un déploiement est ensuite complétée, dans un second temps, par ledéveloppement d’un modèle de décision et d’un ensemble de règles de traduction de va-leurs. Un modèle de décision raffine un modèle de déploiement pour une application et uneplate-forme précises. Il permet en particulier de trancher parmi des choix de déploiement.Parallèlement, les fonctions de traduction adaptent les valeurs du modèle de l’applicationpour la plate-forme d’exécution cible.

Comme pour un modèle de déploiement, l’expression des décisions est concise, ce quifavorise leur temps de développement et leur maintenance. Durant les expérimentations, letemps passé pour l’élaboration des modèles de décisions a plus été consacré à la prise dedécision qu’à la formulation des décisions. Toutefois, un modèle de décisionn’est valableque pour un seul déploiement. La réutilisation d’un tel modèle n’est donc pas envisageable.

Les fonctions de traduction sont également affectées par leur dépendances au métamo-dèle de l’application et à la plate-forme d’exécution cible. Elles sont toutefoisutilisablespour toutes les applications du domaine. Contrairement au modèle de décision qui n’estparfois valable que pour une application donnée.

Au bilan, l’approche que nous proposons nous a permis de simplifier l’expression desdéploiements, d’en réduire les temps de développement et d’en faciliter la maintenance.Cette approche s’est donc montrée plus rentable qu’un pivot et, bien que la conception desfonctions qui l’accompagne nécessite plus de temps et de réflexion, elle semble égalementplus efficace qu’une approche de déploiement directe sans pivot.

Enfin, le développement des déploiements n’est plus réservé à des expert d’une techno-logie de transformation. En effet, l’expression d’un déploiement se restreint aux concepts dudomaine de l’application et des plates-formes d’exécution. La technologie de transformationne concerne que les règles génériques et lestemplatesde génération de règles « cachées »à l’utilisateur. Le seul lien persistant avec la technologie de transformation concerne le dé-veloppement des fonctions. Mais, d’une part, ces fonctions reposentsur des technologies

5.3. Résultats 141

dédiées au parcours des modèles ou à l’expression de contraintes (tel qu’OCL) et, d’autrepart, des perspectives d’assistances à leur développement permettront certainement à termede s’abstraire également de ces technologies.

5.3.4 Choix de déploiement

La gestion des choix de déploiement n’a pas été évaluée au même titre que les critèresprécédemment abordés. En effet, chacune des approches possèdeses spécificités et ses pro-blématiques en ce qui concerne ces choix. Cette sous-section présente donc un retour sur lagestion des choix que nous avons mise en œuvre pour les deux première approches, avantd’évaluer la gestion qui accompagne notre approche.

La première approche (enfouie) s’appuie sur une transformation propre à la plate-formed’exécution cible. Seules des choix pratiques sont donc susceptibles desurvenir. Commecette approche concentre les informations relatives à un déploiement dans une seule trans-formation, ces choix sont capturés dans la transformation.

Pour répondre à ces choix, des modèles de décisions ont été expérimentés. Ces modèlesexprimaient simplement des décisions codifiées que les transformations venaient évaluer.Les limites de cette pratique, que nous avons évoquées dans ce rapport, concernent l’ex-pression des décisions ou, plus précisément, des termes qui codent cesdécisions. Aucuneinvestigation supplémentaire n’a toutefois été menée pour pallier à ces limites.

L’approche par pivot distingue deux niveaux de déploiement, « théorique » et « pra-tique », selon que l’on considère les concepts de la plate-forme pivot ou ceux de la plate-forme cible. Des choix conceptuelset pratiques sont donc susceptibles de survenir. Or,les deux niveaux de considération sont séquentiels dans le processusde transformation decette approche. Un premier déploiement théorique est effectué, à partir duquel un déploie-ment pratique s’enchaîne. Cette agencement nécessite donc d’exprimer des décisions surles choix conceptuels dès le premier déploiement. Ces prises de décisions soulèvent alorsla problématique d’une validité de décision dans un contexte qui n’a pas toutes les informa-tions, en l’occurrence celles qui concernent la plate-forme cible.

Cette problématique n’a pas été traitée durant cette étude. Des modèles de décisionsont été expérimentés en réponse à certains choix, mais aucune solution satisfaisante n’a étéidentifiée. Une investigation supplémentaire serait nécessaire pour cela.

L’approche que nous proposons distingue également deux niveaux de déploiement,théorique et pratique, selon que l’on considère les concepts qu’identifiele métamodèle deplate-forme d’exécution ou ceux de la plate-forme cible. Des choix conceptuelset pratiquessont donc également susceptibles de survenir. Mais, cette approche nese confronte pas à laproblématique de l’approche par pivot. En effet, les deux niveaux de considération ne sontpas séquentiels dans une transformation, mais séquentiels dans le processus deconstructiond’une transformation ou, plus précisément, dans le processus de modélisation du déploie-ment. Les décisions se concentrent alors dans un seul modèle (le modèle de décisions) quiraffine un modèle de déploiement « théorique » dans lequel aucune décision n’est capturée.

Enfin, dans cette approche, l’expression des décisions se fait dans les termes des do-maines impliqués (application, plate-forme d’exécution cible ou plus généralement domainedes plates-formes d’exécution temps réel embarquées). Ces décisions prennent la forme decorrespondances qui décrivent un déploiement.

L’approche que nous proposons apporte donc une solution à la gestiondes choix quicouvre les choix conceptuels et pratiques. Cette solution à l’avantage de concentrer lesdécisions dans un modèle dédié, sans introduire de codification.


5.4 Bilan

Les résultats qui ont motivés cette étude, et que nous avons présentés dans le chapitre del’état de l’art, incitaient à mettre en œuvre un déploiement basé sur des descriptions expli-cites de plates-formes d’exécution, si plusieurs plates-formes cibles étaient envisageables.Les résultats que nous venons de présenter le confirment.

En effet, la définition d’un pivot ou la définition d’un métamodèle de plate-forme d’exé-cution sont de la même complexité et prennent des temps de développement équivalents.Mais, le métamodèle de plate-forme d’exécution que nous avons développé durant cetteétude nous a permis de mettre en œuvre un processus de déploiement basé sur des règlesgénériques ou générées à partir de modèles de déploiement concis, rapides à développer,faciles à maintenir et indépendants de la technologie de transformation sous-jacente. Cesmodèles intègrent de plus une gestion des choix de déploiements qu’il est difficile de mettreen œuvre dans les approches concurrentes.

Les expérimentations que nous avons menées révèlent également que cetteapprochepeut s’avérer plus efficace qu’une description implicite lorsqu’une seule plate-forme estenvisagée. En effet, la plate-forme est décrite dans un modèle beaucoupplus simple à déve-lopper qu’un métamodèle et l’expression d’un déploiement se concrétise par des modèlesbeaucoup plus concis qu’un ensemble de règles de transformation.

Quelque soit le contexte, l’investissement que nécessite l’approche que nous proposonspeut donc s’avérer rentable sur le long terme.

Les prototypes développés durant cette étude ont été mis à disposition en logiciel libre4.L’outillage se compose en particulier :

– du métamodèle de RTEPML (aux formats KM3 et Ecore) ;– d’éditeurs RTEPML textuels et graphiques, compatibles avec Eclipse, développés

dans l’atelier TOPCASED;– d’un métamodèle et d’un éditeur textuel de déploiements ;– de templatesAcceleo de génération de règles ATL ainsi que des bibliothèques de

règles ATL qui les accompagnent ;– dehelpersATL de localisation d’informations dans des modèles de plates-formes ;– dehelpersATL de localisation d’informations dans des descriptions AADL .

4http://trame.eseo.fr

http://trame.eseo.fr

Conclusion

Synthèse

Les travaux de cette thèse avaient pour objectif d’étudier la considérationdes plates-formes d’exécution logicielles lors d’un processus de déploiement d’application. Plus par-ticulièrement, ils devaient contribuer à : (1) recenser et comparer les approches IDM demodélisation des plates-formes d’exécution dans un objectif de déploiement d’applicationset (2) proposer un processus de déploiement concret, basé sur l’approche la plus appro-priée au contexte d’utilisation prévu : le déploiement d’applications sur des plates-formesd’exécution temps réel embarquées.

Pour cela, le champs d’application de l’étude a été centré sur les systèmes d’exploita-tion temps réel embarqués multitâches, cadencés par le temps ou par les évènements, dansune approche asynchrone. L’approche MDA a été adoptée comme méthodologie de déploie-ment. Nous visions à générer, par transformation, des modèles d’applications déployées surdes systèmes d’exploitations temps réel embarqués à partir de modèles d’applications indé-pendants de tout support d’exécution.

L’étude a ensuite été menée en deux parties.

La première partie s’est attachée à recenser, d’une part, les représentations possibles desplates-formes de notre domaine d’intérêt (les systèmes d’exploitation temps réel embarqués)et, d’autres part, les intégrations de ces représentations dans des processus de déploiementd’applications (chapitre 2). Cet état de l’art a été mené dans des contextes de modélisationbasés sur des DSML et sur des GPML (et plus particulièrement UML ). Les déploiementsabordés couvraient la génération de modèles de codes source et la génération de modèlesd’applications indépendants de toute technologie de codage.

Trois approches de représentation des plates-formes d’exécution dans l’I DM ont étéidentifiées au cours de cette étude. Ces approches se basent respectivement sur des repré-sentations enfouies, implicites et explicites des plates-formes d’exécution, selon que lesinformations relatives aux plates-formes sont capturées dans des transformations, des mé-tamodèles ou des modèles. Pour chacune de ces approches, une ou plusieurs pratiques dedéploiement ont été présentées. Ces pratiques étaient issues de travauxexistants ou ont étéproposées en complément. Elles ont ensuite été évaluées pour orienter notre investigation.

La seconde partie de l’étude s’est focalisée sur la mise en œuvre d’un déploiement d’ap-plications basé sur des descriptions explicites de plates-formes d’exécution. Cette parties’est concentrée sur la génération de modèles d’applications indépendants de toute techno-logie de codage, dans un contexte de modélisation DSML.

Un langage de modélisation de systèmes d’exploitation temps réel embarqués a été dé-fini (chapitre 3). Puis, un processus de déploiement d’application basésur ce langage a étédéveloppé (chapitre 4). Ce processus a finalement été évalué dans le but de confirmer lesrésultats, issus de l’état de l’art, qui avaient motivé cette étude (chapitre 5).

144 Conclusion

Contributions

Les travaux de cette thèse ont contribué en trois points à la considération des plates-formes d’exécution lors d’un processus de déploiement d’applications.

Différents processus de déploiements basés sur des représentations enfouies, im-plicites ou explicites des plates-formes d’exécution ont été recensés et évalués. En par-ticulier, les processus de déploiement basés sur des descriptions implicites se déclinent endeux approches, selon qu’une transformation génère directement l’application déployée ouqu’un pivot intermédiaire est introduit. Parallèlement, les processus de déploiement baséssur des descriptions explicites se déclinent en quatre approches, en fonction des relationsentre les métamodèles de l’application, de la plate-forme d’exécution et de l’applicationdéployée. Ainsi, le modèle de l’application déployée peut être conforme au même méta-modèle que celui de la plate-forme d’exécution (approches par « mise en relation », ou par« intégration »). Il peut également être conforme à un métamodèle issu d’unepromotion dumodèle de la plate-forme ou conforme à un métamodèle différent et indépendant de celuide la plate-forme (par exemple, dans le cas d’une génération d’un modèle de code source).

Une première étude a montré qu’une description implicite de plate-forme d’exécu-tion, sans pivot intermédiaire, convient pour des projets dans lesquels peu de plates-formescibles sont envisagées. Sinon, une approche par description explicite de ces plates-formes,à l’exception de l’approche par promotion, est plus intéressante à mettre enœuvre, notam-ment, plus intéressante qu’une approche par pivot. Ces résultats ont étéconstatés pour descontextes de modélisation UML et DSML, que l’on souhaite générer un modèle de codesource ou un modèle indépendant de toute technologie de codage.

L’approfondissement que nous avons mené dans un contexte DSML a montré que lareprésentation explicite des plates-formes d’exécution, couplée avec une approche par in-tégration d’application, s’avère également rentable sur plusieurs projetsdans lesquels uneseule plate-forme d’exécution est envisagée.

Un langage de modélisation de plates-formes d’exécution temps réel embarquéesa été défini.Ce langage, présenté sous le nom de RTEPML (Real-Time Embedded PlatformModeling Language), s’appuie sur le motif ressource/service et les concepts du domaine dutemps réel et de l’embarqué qu’identifie lepackageSRM du profil UML -MARTE. RTEPML

permet de modéliser des plates-formes d’exécution dans un contexte de développementutilisant des DSML comme alternative aux GPML (tel qu’UML ).

RTEPML permet de décrire les ressources qu’offre un système d’exploitation temps réelembarqué ainsi que l’API des services associés à ces ressources. Des prototypes de miseen œuvre de mécanismes exécutifs peuvent être précisés. RTEPML fournit également unsupport pour intégrer des applications sur les plates-formes d’exécution.

Bien que RTEPML soit encore incomplet (il ne couvre pas les aspects comportemen-taux et n’identifie pas, par exemple, les mécanismes de gestion des erreursou des modesde fonctionnement), son utilisation a montré qu’il était d’ors et déjà fonctionnel pour dé-crire des systèmes d’exploitation existants dans le but de les prendre en compte lors d’undéploiement d’applications.

Un processus de déploiement d’applications basé sur RTEPML a été développé. Ceprocessus se concrétise par des transformations de modèles. Il repose sur le mécanismed’intégration d’applications introduit dans RTEPML. L’originalité de ce processus résidedans son articulation autour de règles de transformations génériques ou générées. Il s’ac-compagne d’un langage de description de déploiements qui, couplé à destemplates, permet

Conclusion 145

de générer des règles. Ce langage se focalise sur l’expression des mises en œuvre de méca-nismes applicatifs avec des concepts exécutifs. Il permet également de préciser des décisionsqui répondent à des choix de déploiement (ces choix peuvent concerner toutes ou une seuleapplication et toutes ou une seule plate-forme d’exécution).

Une transformation de déploiement s’organise alors en trois ensembles :

1. un noyau générique de règles et de fonctions, commun à tout déploiement d’applica-tion quelque soit la plate-forme d’exécution ;

2. un modèle de déploiement théorique et un ensemble de fonctions de localisation d’in-formations, pour les applications d’un domaine particulier ;

3. un modèle de déploiement, qui raffine le précédent modèle de déploiement,et un en-semble de fonctions de traduction, pour une plate-forme donnée (et, potentiellement,pour une application précise).

Bien que des contraintes existent sur la technologie susceptible de le mettre enœuvre,le processus de déploiement proposé a été conçu indépendamment de toutetechnologie detransformations.

Une implantation ATL a été développée pour outiller l’approche et l’expérimenter. Al’issue des expérimentations, les transformations développées ont montré une nette sépara-tion des considérations de l’application, de la plate-forme d’exécution et, plus généralement,du domaine applicatif et du domaine du temps réel et de l’embarqué dans différents modèleset ensembles de fonctions. L’introduction d’un langage dédié au déploiement aboutit à desdescriptions concises, rapides à développer et faciles à maintenir. Enfin, la construction in-crémentale que propose le processus, en fonction des technologies impliquées, permet decapitaliser sur les modèles et les fonctions qui composent les transformations.

Perspectives

Les suites à donner à cette étude se répartissent en trois axes. Le premiervise à améliorerla modélisation des plates-formes d’exécution et le processus de déploiement proposés. Lesecond et le troisième axes visent à étendre ces principes de modélisation etde déploiementà d’autres domaines d’applications et à un contexte de modélisation GPML.

Approfondir l’approche

Nous nous sommes restreints dans cette étude à des modèles structurels qui se limitentà l’interface de programmation des plates-formes d’exécution. Pour donner les moyens auxconcepteurs des déploiements de vérifier que les règles de transformations produisent dessystèmes conformes aux modèles de départ, il conviendra d’enrichir les modèles des plates-formes pour qu’ils capturent également le comportement de ces plates-formes. Ce point faitactuellement l’objet d’une étude à part entière.

Le métamodèle de plates-formes d’exécution que nous avons proposé identifie un en-semble de concepts issus dupackageSRM d’UML -MARTE. Ces concepts ne sont toutefoispas suffisants. Ils devront être complétés pour couvrir des mécanismes supplémentaires quesont susceptibles de fournir les systèmes d’exploitation temps réel embarqués (telle que lagestion des erreurs ou des modes de fonctionnement). De même, certains concepts déjà pré-sents dans le métamodèle devront être étendus (un concept de structure de données sera, parexemple, envisagé pour enrichir l’usage des données natives à une plate-forme).

146 Conclusion

Un métamodèle de plates-formes d’exécution est également susceptible d’évoluer aurythme des avancés technologiques des systèmes d’exploitation existants (contrairement àun métamodèle de langage de programmation). Son maintien nécessitera une veilleperma-nente. Son évolution soulèvera également la question de l’évolution des outilsqui l’accom-pagnent et des déploiements déjà formulés.

Les futurs travaux envisagés concernent aussi le processus de déploiement proposé.Comme cela fut mentionné dans ce rapport, une assistance au développement des fonctionsqui accompagnent les règles de transformations est, par exemple, prévue.

Des phases amont et aval au processus devront également être considérées. Nous avonsévoqué une phase amont consacrée aux décisions de déploiements. Cettephase devra êtrecouplée à des outils existants et traduite automatiquement en modèles de déploiements. Uneétude est actuellement menée pour mettre en œuvre une telle approche.

De même, une phase de génération de code peut succéder à la générationd’un modèled’application indépendant de toute technologie de codage. Bien que des expérimentationsaient permis de générer des codes source, les mises en œuvre possiblespour cette phasen’ont pas été recensées et évaluées. A l’image de la considération d’une plate-forme d’exé-cution, la considération d’un langage de programmation mérite une investigationà partentière. En particulier, les relations entre les plates-formes d’exécution etles langages deprogrammation doivent être précisées.

Enfin, l’utilisation d’un métamodèle de plates-formes d’exécution offre la perspectived’unifier les représentations explicites des plates-formes d’exécution etd’en faciliter ainsileurs prises en compte dans différents outils (par exemple, destinés à l’analyse ou la gé-nération de code). L’échange et la capitalisation des modèles sont alors des motivations àl’unification autour de tels métamodèles.

Nous avons proposé et mis à disposition dans cette étude un métamodèle dédié àladescription des plates-formes d’exécution du domaine de l’embarqué et dutemps réel. Cettedémarche vise à fournir une base commune pour capitaliser les efforts de développementd’un tel métamodèle. Des collaborations autour d’un même métamodèle de plate-formed’exécution, dans la lignée de ce que propose le profil UML -MARTE dans un contexte UML ,seraient également bénéfiques dans un contexte de modélisation DSML.

Étendre l’approche à d’autres domaines

Nous nous sommes intéressés, dans cette étude, aux déploiements d’application sur desplates-formes d’exécution logicielles embarquées temps réel. Or, bien que nous n’ayons pasidentifié de points particuliers qui pourraient limiter l’application de l’approche proposée àd’autres domaines que l’embarqué et le temps réel, d’autres expérimentations devront êtremenées sur des domaines d’études différents.

Pour faciliter la production des métamodèles de plates-formes dans différents domaines,la réutilisation de métamodèles existants devra alors être envisagée (par exemple, par com-position de sous-ensembles communs ou par spécialisation de métamodèles abstraits).

Plus généralement, les avantages d’une approche de déploiement baséesur des repré-sentations explicites des plates-formes, vis-à-vis d’une approche par pivot, pourront êtreconfirmés dans d’autres domaines dans lesquels une approche par pivot est souvent utilisée.Au delà du domaine des logiciels ou des considérations d’exécution, deux études sont, parexemple, actuellement en cours pour adapter l’approche proposée au plates-formes maté-rielles ou aux plates-formes d’analyse d’ordonnancement.

Conclusion 147

Étendre l’approche à un contexte de modélisation GPML

Les travaux de cette étude ont été menés dans un contexte de modélisation basésur desDSML. En complément des travaux existants sur le portage d’applications dans uncontexteUML , basés notamment sur le profil UML -MARTE, l’approche de déploiement que nousavons proposée pourra être généralisée à ce contexte. Des travaux sont actuellement menéssur ce sujet.

Troisième partie

Annexes

AMétamodèle de RTEPML

153

Le métamodèle du langage RTEPML a été introduit dans le chapitre 3, page 57.

Listing A.1: Métamodèle du langage RTEPML (en KM3 [56])

-- @name RTEPML-- @version 1.0-- @authors [email protected] (@irccyn.ec-nantes.fr)-- @description Real Time Embedded Platform Modeling Language-- @nsURI RTEPML-- @nsPrefix RTEPML

package RTEPML {

----------------------------------------------------------------- + -- Located and Named Elements---------------------------------------------------------------

abstract class LocatedElement {attribute location[0-1] : String;attribute commentsBefore[*] ordered : String;attribute commentsAfter[*] ordered : String;

}

abstract class NamedElement extends LocatedElement {attribute name : String;

}

----------------------------------------------------------------- 1 -- Platform Model---------------------------------------------------------------

class PlatformModel extends NamedElement {reference resources[*] container : Resource;reference resourceInstances[*] container : PlatformResourceInstance;

-- add application conceptreference applications[*] container : Application;

}

----------------------------------------------------------------- 1.1 -- Resource and Resource Property---------------------------------------------------------------

abstract class Resource extends NamedElement {reference properties[*] container : ResourceProperty;reference services[*] container : ResourceService;

-- add abstract and inheritance conceptsattribute isAbstract : Boolean;reference supertype : Resource;

-- add prototype conceptreference prototype[0-1] container : Prototype;

-- add platform native resource instance conceptreference instances[*] : ResourceInstance;

reference createServices[*] : ResourceService;reference prototypeCreateServices[*] : PrototypeResourceInstance;

reference deleteServices[*] : ResourceService;reference prototypeDeleteServices[*] : PrototypeResourceInstance;

reference initializeServices[*] : ResourceService;reference prototypeInitializeServices[*] : PrototypeResourceInstance;

}

class ResourceProperty extends NamedElement {reference type : Resource;

}

154 Annexe A. Métamodèle deRTEPML

----------------------------------------------------------------- 1.2 -- Resource Instance and Resource Instance Property---------------------------------------------------------------

class ResourceInstance extends NamedElement {reference type : Resource;reference properties[*] container : ResourceInstanceProperty;reference call[*] ordered container : CallService;

}

class ResourceInstanceProperty extends LocatedElement {reference property : ResourceProperty;reference ref : ResourceInstance;attribute val : String;

}

class PlatformResourceInstance extends ResourceInstance {}

----------------------------------------------------------------- 1.3 -- Resource Service and Call Service---------------------------------------------------------------

class ResourceService extends NamedElement {reference ownedServices[*] ordered : ResourceService;reference parameters[*] ordered container : ServiceParameter;

}

class ServiceParameter extends NamedElement {reference type : Resource;

}

class CallService extends LocatedElement {reference parameters[*] ordered container : CallParameter;reference service : ResourceService;reference ref : ResourceInstance;

}

class CallParameter extends LocatedElement {reference parameter : ServiceParameter;attribute val : String;reference ref : ResourceInstance;

}

----------------------------------------------------------------- 1.4 -- Data Type---------------------------------------------------------------

abstract class DataType extends Resource {}

class StringType extends DataType {}

abstract class BasicType extends DataType {attribute size : Integer;attribute isSigned : Boolean;

}

class BooleanType extends BasicType {}

class CharType extends BasicType {}

class IntegerType extends BasicType {}

class RealType extends BasicType {}

----------------------------------------------------------------- 1.5 -- Routine---------------------------------------------------------------

class Routine extends Resource {attribute isReentrant : Boolean;

155

reference callRoutineServices[*] : ResourceService;reference prototypeCallRoutineServices[*] : PrototypeResourceInstance;

}

----------------------------------------------------------------- 2 -- Artefacts---------------------------------------------------------------

----------------------------------------------------------------- 2.1 -- Prototype---------------------------------------------------------------

class Prototype extends LocatedElement {reference masterInstance : PrototypeResourceInstance;reference instances[*] container : PrototypeResourceInstance;reference associations[*] container :

PrototypeResourceInstanceAssociation;}

class PrototypeResourceInstance extends ResourceInstance {reference match[0-1] : PlatformResourceInstance;

}

class PrototypeResourceInstanceAssociation extends NamedElement {reference src : PrototypeResourceInstance;reference dst : PrototypeResourceInstance;

}

----------------------------------------------------------------- 2.2 -- Application---------------------------------------------------------------

class Application extends NamedElement {reference instances[*] container : ApplicationResourceInstance;reference associations[*] container : ResourceInstanceAssociation;

}

class ApplicationResourceInstance extends ResourceInstance {}

----------------------------------------------------------------- 3 -- Resources---------------------------------------------------------------

----------------------------------------------------------------- 3.1 -- Concurrent Resource---------------------------------------------------------------

enumeration ArrivalPattern {literal Undefined;literal Periodic;literal Aperiodic;literal Sporadic;

}

abstract class ConcurrentResource extends Resource {attribute type : ArrivalPattern;attribute activationCapacity : Integer;

reference periodElements[*] : ResourceProperty;reference prototypePeriodElements[*] : PrototypeResourceInstance;

reference priorityElements[*] : ResourceProperty;reference prototypePriorityElements[*] : PrototypeResourceInstance;

reference stackSizeElements[*] : ResourceProperty;reference prototypeStackSizeElements[*] : PrototypeResourceInstance;

reference activateServices[*] : ResourceService;reference prototypeActivateServices[*] : PrototypeResourceInstance;


reference resumeServices[*] : ResourceService;reference prototypeResumeServices[*] : PrototypeResourceInstance;

reference suspendServices[*] : ResourceService;reference prototypeSuspendServices[*] : PrototypeResourceInstance;

reference terminateServices[*] : ResourceService;reference prototypeTerminateServices[*] : PrototypeResourceInstance;

reference enableConcurrencyServices[*] : ResourceService;reference prototypeEnableConcurrencyServices[*] :

PrototypeResourceInstance;

reference disableConcurrencyServices[*] : ResourceService;reference prototypeDisableConcurrencyServices[*] :


reference sharedDataComResources[*] : SharedDataComResource;reference messageComResources[*] : MessageComResource;reference mutualExclusionResources[*] : MutualExclusionResource;reference notificationResources[*] : NotificationResource;

-- add entrypoint conceptreference entryPointElements[*] : ResourceProperty;reference prototypeEntryPointElement : PrototypeResourceInstance;

reference addressSpace : MemoryPartition oppositeOfconcurrentResources;

}

----------------------------------------------------------------- 3.1.1 -- Interrupt Resource---------------------------------------------------------------

enumeration InterruptKind {literal HardwareInterruption;literal ProcessorDetectedException;literal ProgrammedException;

}

abstract class InterruptResource extends ConcurrentResource {attribute isMaskable : Boolean;

reference vectorElements[*] : ResourceProperty;reference prototypeVectorElements[*] : PrototypeResourceInstance;

reference maskElements[*] : ResourceProperty;reference prototypeMaskElements[*] : PrototypeResourceInstance;

reference routineConnectServices[*] : ResourceService;reference prototypeRoutineConnectServices[*] :


reference routineDisconnectServices[*] : ResourceService;reference prototypeRoutineDisconnectServices[*] :

PrototypeResourceInstance;}

class Interrupt extends InterruptResource {attribute kind : InterruptKind;

}

class Alarm extends InterruptResource {attribute isWatchdog : Boolean;

reference timers[*] : TimerResource;reference prototypeTimers[*] : PrototypeResourceInstance;

}

157

----------------------------------------------------------------- 3.1.2 -- Schedulable Resource---------------------------------------------------------------

class SchedulableResource extends ConcurrentResource {attribute isStaticSchedulingFeature : Boolean;attribute isPreemptable : Boolean;

reference deadlineElements[*] : ResourceProperty;reference prototypeDeadlineElements[*] : PrototypeResourceInstance;

reference deadlineTypeElements[*] : ResourceProperty;reference prototypeDeadlineTypeElements[*] :


reference timeSliceElements[*] : ResourceProperty;reference prototypeTimeSliceElements[*] : PrototypeResourceInstance;

reference joinServices[*] : ResourceService;reference prototypeJoinServices[*] : PrototypeResourceInstance;

reference yieldServices[*] : ResourceService;reference prototypeYieldServices[*] : PrototypeResourceInstance;

reference delayService[*] : ResourceService;reference prototypeDelayService[*] : PrototypeResourceInstance;

}

----------------------------------------------------------------- 3.2 -- Memory Partition---------------------------------------------------------------

class MemoryPartition extends Resource {reference concurrentResources[*] : ConcurrentResource oppositeOf

addressSpace;

reference memorySpaceElements[*] : ResourceProperty;reference prototypeMemorySpaceElements[*] : PrototypeResourceInstance;

reference forkService : ResourceService;reference prototypeForkService : PrototypeResourceInstance;

reference exitService : ResourceService;reference prototypeExitService : PrototypeResourceInstance;

}

----------------------------------------------------------------- 3.3 -- Interaction Resource---------------------------------------------------------------

enumeration QueuePolicyKind {literal Undefined;literal FIFO;literal LIFO;literal Priority;

}

abstract class InteractionResource extends Resource {attribute isIntraMemoryPartition : Boolean;attribute waitingQueuePolicy[0-1] : QueuePolicyKind;attribute waitingQueueCapacity[0-1] : Integer;

reference waintingPolicyElements[*] : ResourceProperty;reference prototypeWaintingPolicyElements[*] :

PrototypeResourceInstance;}

----------------------------------------------------------------- 3.3.1 -- Synchronisation Resource---------------------------------------------------------------


abstract class SynchronisationResource extends InteractionResource {}

----------------------------------------------------------------- 3.3.1.1 -- Mutual Exclusion Resource---------------------------------------------------------------

enumeration MutualExclusionResourceKind {literal BooleanSemaphore;literal CountSemaphore;literal Mutex;

}

enumeration ConcurrentAccessProtocolKind {literal PIP;literal PCP;literal ImediatePCP;literal NoPreemption;

}

class MutualExclusionResource extends SynchronisationResource {attribute concurrentAccessProtocol : ConcurrentAccessProtocolKind;attribute mechanism : MutualExclusionResourceKind;

reference accessTokenElements[*] : ResourceProperty;reference prototypeAccessTokenElements[*] : PrototypeResourceInstance;

reference acquireServices[*] : ResourceService;reference prototypeAcquireServices[*] : PrototypeResourceInstance;

reference releaseServices[*] : ResourceService;reference prototypeReleaseServices[*] : PrototypeResourceInstance;

}

----------------------------------------------------------------- 3.3.1.2 -- Notification Resource---------------------------------------------------------------

enumeration NotificationResourceKind {literal Barrier;literal Event;

}

enumeration OccurencePolicyKind {literal Memorized;literal Bounded;literal Memoryless;

}

class NotificationResource extends SynchronisationResource {attribute policy : OccurencePolicyKind;attribute mechanism : NotificationResourceKind;

reference occurenceCountElements[*] : ResourceProperty;reference prototypeOccurenceCountElements[*] :


reference maskElements[*] : ResourceProperty;reference prototypeMaskElements[*] : PrototypeResourceInstance;

reference flushServices[*] : ResourceService;reference prototypeFlushServices[*] : PrototypeResourceInstance;

reference signalServices[*] : ResourceService;reference prototypeSignalServices[*] : PrototypeResourceInstance;

reference waitServices[*] : ResourceService;reference prototypeWaitServices[*] : PrototypeResourceInstance;

reference clearServices[*] : ResourceService;reference prototypeClearServices[*] : PrototypeResourceInstance;

}

159

----------------------------------------------------------------- 3.3.2 -- Communication Resource---------------------------------------------------------------

abstract class CommunicationResource extends InteractionResource {}

----------------------------------------------------------------- 3.3.2.1 -- Message Com Resource---------------------------------------------------------------

enumeration MessageResourceKind {literal MessageQueue;literal Pipe;literal Blackboard;

}

class MessageComResource extends CommunicationResource {attribute isFixedMessageSize : Boolean;attribute mechanism : MessageResourceKind;attribute messageQueuePolicy[0-1] : QueuePolicyKind;

reference messageSizeElements[*] : ResourceProperty;reference prototypeMessageSizeElements[*] : PrototypeResourceInstance;

reference messageQueueCapacityElements[*] : ResourceProperty;reference prototypeMessageQueueCapacityElements[*] :


reference sendServices[*] : ResourceService;reference prototypeSendServices[*] : PrototypeResourceInstance;

reference receiveServices[*] : ResourceService;reference prototypeReceiveServices[*] : PrototypeResourceInstance;

}

----------------------------------------------------------------- 3.3.2.2 -- Shared Data Com Resource---------------------------------------------------------------

class SharedDataComResource extends CommunicationResource {reference readServices[*] : ResourceService;reference prototypeReadServices[*] : PrototypeResourceInstance;

reference writeServices[*] : ResourceService;reference prototypeWriteServices[*] : PrototypeResourceInstance;

}

----------------------------------------------------------------- 4 -- Timer Resource---------------------------------------------------------------

class TimerResource extends Resource {reference durationElements[*] : ResourceProperty;reference prototypeDurationElements[*] : PrototypeResourceInstance;

}}

BExtraits de transformations ATL

163

Transformation de promotion

La transformationPlatform2Metadu listing B.1 sert à promouvoir un modèle de plate-forme d’exécution en un métamodèle d’application (passage d’une description explicite àune description implicite).

Cette transformation est utilisée dans l’exemple de la figure 2.21 du chapitre 2,page 36.

Listing B.1:Extrait de la transformationPlatform2Meta(en ATL)

1 -- Transformation Platform2Meta2 --3 -- Promote a platform model into an application metamodel.4 --5 module Platform2Meta;6 create OUT : MMM from IN : Platform;78 -- Rule Platform2Metamodel9 --

10 -- Create a metamodel of application from a platform description.11 --12 rule Platform2Metamodel {13 from platform : Platform!Platform14 to15 metamodel : MMM!Metamodel (16 classes <- Sequence{application}->union(platform.resources)17 ),18 application : MMM!Class (19 name <- ’Application’,20 ref <- platform.resources21 )22 }2324 -- Rule Resource2Class25 --26 -- Create a metaclass for each resource. Create first a reference to that27 -- metaclass, in order to reference the created metaclass in the application.28 --29 rule Resource2Class {30 from resource : Platform!Resource31 to32 reference : MMM!Reference (33 contain <- true,34 cardinal <- ’-1’.toInteger(),35 class <- class36 ),37 class : MMM!Class (38 name <- resource.name,39 attributes <- Sequence{resource.properties}40 ),41 name : MMM!Attribute (42 name <- ’name’,43 type <- #String44 )45 }4647 -- Rule Property2Attribute48 --49 -- Create attribute of meta-class from property of resource.50 --51 rule Property2Attribute {52 from property : Platform!Property53 to54 attribute : MMM!Attribute (55 name <- property.name,56 type <- property.getType()57 )58 }

164 Annexe B. Extraits de transformationsATL

Transformations de déploiements basées sur RTEPML

Helper getResource(version simple)

Le listing B.2 présente une implantation simplifiée d’unhelperATL (getResource) per-mettant de localiser, dans un modèle de plate-forme d’exécution, une ressource conformeà une classe de RTEPML. Un exemple d’utilisation de cehelperest donné à la suite de sadéfinition, au sein d’une règleActivity2SchedulableResourceInstance1.

Ce listing se réfère aux algorithmes 4.2 et 4.3, introduits dans le chapitre 4, page 82.

Listing B.2:getResource: localisation d’une ressource (version simple, en ATL)

1 -- Helper getResource2 --3 -- Parameter : A metaclass of metamodel conform to MOF.4 -- Return : The first class of a model that conforms to5 -- the metaclass parameter passed to the helper.6 -- RTEPML use : Return a platform resource conforms to7 -- an executive concept identified by a metaclasse.8 --9 helper def: getResource(metaclass : MOF!EClass) : MOF!EClass =

10 metaclass.allInstances()->first();1112 -- Rule Activity2SchedulableResourceInstance13 --14 -- Generate an RTEPML instance resource typed by a15 -- schedulable resource from a ROBOT activity.16 --17 rule Activity2SchedulableResourceInstance {18 from s : ROBOT!Activity19 to20 t : RTEPML!ApplicationResourceInstance (21 ...22 type <-23 thisModule.getResource(RTEPML!SchedulableResource),24 ...25 ),26 ...27 }

Le helpergetResourcedu listing B.2 s’appuie sur l’opération OCL allInstancesfourniepar ATL. Cette opération retourne l’ensemble des classes conformes à la classe à laquelleelle s’adresse.

Dans cette version duhelper, le premier élément de cet ensemble est retourné (first).La sélection d’un élément de cet ensemble, sur d’autres critères, est abordée dans la sous-section suivante.

Remarque : L’utilisation duhelpergetResource, tel que nous l’avons défini, se fait autravers du contexte global du module ATL de la transformation (thisModule, ligne 23).

Helper getResource(considération de critères)

Le listing B.3, page suivante, présente une implantation duhelperATL getResource(in-troduit dans la sous-section précédente) permettant de prendre en considération des critèresassociés à des classes. Cehelperpermet ainsi de localiser, dans un modèle de plate-formed’exécution, une ressource conforme à une classe de RTEPML, dans le respect du critère quil’accompagne.

1Cet exemple d’utilisation précise le code du listing 4.1, page 80, qui concerne cette même règle.

165

Ce listing se réfère à l’algorithme 4.7, introduit dans le chapitre 4, page 86.

Listing B.3:getResource: localisation d’une ressource (avec critères, en ATL)

1 -- Helper getResource2 --3 -- Parameters : A metaclass of metamodel conform to MOF,4 -- a criterion that correspond to an operation (helper) and5 -- a sequence of parameters associated to the criterion helper.6 -- Return : The first class of a model that conforms to7 -- the metaclass respecting the criterion.8 -- RTEPML use : Return a platform resource conforms to an executive9 -- concept identified by a metaclasse and a criterion.

10 --11 helper def: getResource( metaclass : MOF!EClass,12 criterion : String,13 parameters : Sequence(String) ) : MOF!EClass =1415 thisModule.getResources(metaclass, criterion, parameters)->first();1617 -- Helper getResources18 --19 -- Parameters : A metaclass of metamodel conform to MOF,20 -- a criterion that correspond to an operation (helper) and21 -- a sequence of parameters associated to the criterion helper.22 -- Return : A set of class of a model that conforms to23 -- the metaclass respecting the criterion.24 --25 helper def: getResources( metaclass : MOF!EClass,26 criterion : String,27 parameters : Sequence(String) ) : Set(MOF!EClass) =2829 let resources : Set(MOF!EClass) =30 metaclass.allInstances()->asSequence() in3132 if criterion.oclIsUndefined()33 then resources34 else resources35 ->select(r|r.refInvokeOperation(criterion, parameters))36 endif;

La partie duhelpergetResourcechargée de récolter l’ensemble des ressources est fac-torisée dans unhelpergetResourcesdéfini à la suite. Cehelperse charge alors de localiserles ressources en s’appuyant, dans un premier temps, sur l’opération OCL allInstances, quenous avons évoquée dans la version simple, et en appliquant, dans un second temps, si uncritère est stipulé, une sélection (select) sur l’ensemble retourné.

Au sein de cette sélection, l’opération OCL refInvokeOperation, également fournie parATL, est mise à contribution pour évoquer lehelperdu critère dont le nom est passé en pa-ramètre (sous forme d’une chaîne de caractères). L’appel à cehelperpeut être accompagnéde paramètres transmis dans une séquence.

Un exemple d’utilisation de cehelperest donné dans la suite de cette annexe, au seind’une règleXConcept2XResourceInstance, page 168.

Helper getProperty(version simple)

Cette sous-section présente deux implantations simplifiées duhelperATL getPropertypermettant de localiser, dans un modèle de plate-forme d’exécution, une propriété de res-source à partir de son rôle. La première implantation met à contribution un ensemble dehelpersdédiés à chaque propriété. Ceshelperssont alors évoqués à partir duhelpergetPro-perty. La seconde implantation propose unhelpergetPropertygénérique, qui ne nécessiteplus d’appels à deshelpersdédiés.


Chacune de ces implantations se réfère aux algorithmes 4.2 et 4.4, introduits dans lechapitre 4, page 82.

Utilisation de plusieurshelpers dédiés

Le listing B.4 présente une implantation simplifiée d’unhelper ATL getPropertyquimet à contribution un ensemble dehelpersdédiés à la localisation de chaque propriété.

Listing B.4:getProperty: localisation d’une propriété (version simple, multi-helpers, en ATL)

1 -- Helper getProperty (multi helpers)2 --3 -- Parameter : An name of a property role.4 -- Return : A resource property in the platform model which role5 -- corresponds to the role parameter passed to the helper.6 -- Use : Some helpers constructed like ’getXXXElement’7 -- where XXX is a name of property role.8 --9 helper context RTEPML!Resource

10 def: getProperty(property : String) : RTEPML!ResourceProperty =11 self.refInvokeOperation(’get’ + property + ’Element’, Sequence{});1213 -- Helper getPriorityElement14 --15 -- Return : An element which the role corresponds to16 -- ’Priority’ as defined in RTEPML.17 -- Use : helper getPriorityElements18 --19 helper context RTEPML!Resource20 def: getPriorityElement() : RTEPML!ResourceProperty =21 if (self.oclIsKindOf(RTEPML!ConcurrentResource))22 then self.getPriorityElements()->first()23 else OclUndefined24 endif;2526 -- Helper getPriorityElements27 --28 -- Return : A set of elements whose the roles correspond to29 -- ’Priority’ as defined in RTEPML.30 --31 helper context RTEPML!Resource32 def: getPriorityElements() : Set(RTEPML!ResourceProperty) =33 self.supertype->asSequence()34 ->iterate( e; acc : Set(RTEPML!ResourceProperty) =35 self.priorityElement.asSequence()36 | acc->union(e.getPriorityElements()) );

Le helpergetPropertyde cette approche s’appuie sur l’opération OCL refInvokeOpe-ration fournie par ATL. Comme cela fut évoqué précédemment, cette opération permetd’invoquer une autre opération dont le nom est transmis, sous forme d’une chaîne de ca-ractères, dans le premier paramètre. Un ensemble d’arguments peut également être passé àl’opération invoquée, via le second paramètre (cet ensemble est vide dans notre cas).

Dans l’approche proposée, les opérations invoquées sont deshelpers de la formegetXXXElementoù XXX est un nom de rôle attribué à une propriété. Lehelper getPrio-rityElement, ligne 19, retourne par exemple la propriété correspondant à lapriorité d’uneressource concurrente. Cehelperpeut alors être invoqué via l’appelgetProperty(’Priority’).

On remarquera l’utilisation d’unhelperrécursifgetPriorityElementschargé de récolterles propriétés dont le rôle correspond à unepriorité dans l’ensemble des classes dont héritele concept concerné.

167

Cette approche présente l’avantage de pouvoir vérifier la légitimité d’un accès à une pro-priété, comme cela est pratiqué ligne 21. Il est toutefois nécessaire d’implanter deshelpersdédiés pour chaque rôle identifié pour les propriétés.

Utilisation d’un helper générique

Le listing B.5 présente une implantation simplifiée d’unhelperATL getPropertygéné-rique.

Listing B.5:getProperty: localisation d’une propriété (version simple, générique, en ATL)

1 -- Helper getProperty (generic)2 --3 -- Parameter : An name of a property role.4 -- Return : A resource property in the platform model which role5 -- corresponds to the role parameter passed to the helper.6 -- Use : helper getPropertyElements7 --8 helper context RTEPML!Resource9 def: getProperty(property : String) : RTEPML!ResourceProperty =

10 self.getPropertyElements(property + ’Element’)->first();1112 -- Helper getPropertyElements13 --14 -- Parameter : An name of a property role.15 -- Return : A set of elements whose the roles correspond to16 -- which is passed to the helper, as defined in RTEPML.17 --18 helper context RTEPML!Resource19 def: getPropertyElements(property : String) : Set(RTEPML!ResourceProperty) =20 self.supertype->asSequence()21 ->iterate( e; acc : Set(RTEPML!ResourceProperty) =22 self.refGetValue(property).asSequence()23 | acc->union(e.getPropertyElements(property)) );

Le helper getPropertyde cette approche, ou plus précisément lehelper getProper-tyElementsmis à contribution, s’appuie sur l’opération OCL refGetValuefournie par ATL

(ligne 22). Cette opération permet d’accéder à une caractéristique (feature) de l’élément au-quel elle s’adresse. L’accès est assuré par le nom de la caractéristique, passé en paramètrede l’opération.

Cette opération permet ainsi de se référer, par son nom, à une association du métamo-dèle de RTEPML. Dans l’approche proposée, les associations visées sont les associationsporteuses des rôles attribués aux propriétés. Au sein duhelpergetProperty, les noms desassociations sont reconstitués sous la formeXXXElement, où XXX est le nom du rôle. Cehelperpeut donc, par exemple, être invoqué via l’appelgetProperty(’priority’). L’accès àla propriété concernée se fera alors via l’associationpriorityElementqui identifie le rôle depriorité pour une propriété.

On remarquera l’utilisation, dans cette version également, d’unhelperrécursifgetPro-pertyElementschargé de récolter les propriétés dans l’ensemble des classes dont hérite leconcept concerné. Le rôle de la propriété recherchée est passée en paramètre à cehelper.

Cette approche présente l’avantage d’être rapide à implanter, puisqu’ellene nécessitepas d’autreshelpers. Il n’est cependant pas possible de vérifier la légitimité d’un accès àune propriété.

Remarque : Une approche hybride entre les deux implantations est également envisa-geable, en remplaçant leshelpersrécursifs de la version précédente (multi-helpers) par lehelperrécursif générique de cette version.


RègleXConcept2XResourceInstance(prise en compte de critères)

Le listing B.6 illustre la prise en compte de critères associés à des classes, dans une règleATL déclarative. Cette règle traduit un concept applicatif en une instance de ressource (Ap-plicationResourceInstance) typée par un concept de RTEPML. Chacun des concepts applica-tif et exécutif est identifié par une classe (respectivementXConceptet XResource) préciséepar un critère (XConceptCriterionetXResourceCriterion).

La considération de critères associés à des classes pour identifier des concepts a étéintroduite dans les algorithmes 4.5, 4.6 et 4.7, du chapitre 4, page 85.

Listing B.6:XConcept2XResourceInstance: exemple générique (avec critères, en ATL)

1 -- Rule XConcept2XResourceInstance2 --3 -- Translate an application XConcept into a platforme resource instance4 -- typed by XResource. Both XConcept and XResource have criterion.5 --6 rule XConcept2XResourceInstance {78 from s : Application!XConcept (9 s.XConceptCriterion()

10 )1112 to t : RTEPML!ApplicationResourceInstance13 type <- thisModule.getResource(14 RTEPML!XResource, ’XResourceCriterion’, Sequence{}15 ),16 ...17 ),18 ...19 }

Dans l’exemple proposé, les critères sont exprimés par deshelpersATL. L’implantationde ceshelpers, que nous ne détaillerons pas, se fait en OCL.

Le critère sur le concept applicatif est pris en compte au sein d’une pré-conditiond’application (ou d’exécution) de la règle (ligne 9). Le critère sur le concept exécutif estpassé comme paramètre auhelpergetResource, via le nom duhelperqui capture ce critère(ligne 14). Remarque : Un ensemble de paramètres peut accompagner lehelperdu critère.Ceux-ci sont alors transmis par une séquence (vide dans l’exemple) dans le dernier para-mètre duhelpergetResource.

Le helpergetResourcepermettant de prendre en compte des critères associés aux classesest présenté dans cette annexe page 164.

RègleXConcept2XResourceInstance(disponibilité 0/1)

Cette sous-section présente deux mises en œuvre possibles d’une détection de dis-ponibilité de ressources dans une transformation de déploiement. Les mécanismes im-plantés consistent à vérifier la présence de ressources conformes aux concepts impliquésdans les correspondances, avant de les appliquer. La première mise enœuvre conditionnel’ application d’une règleau plus haut niveau de la transformation. La seconde influe sur ledéroulement d’une règle, au sein de cette règle.

Les mécanismes de détections de mise à disposition de ressources par les plates-formescibles sont introduits dans les algorithmes 4.10 et 4.11, du chapitre 4, page 92.

169

Utilisation des conditions d’applications des règles

Le listing B.7 illustre l’implantation d’une détection de mise à disposition de ressourcesavec des règles ATL déclaratives (la règle d’origineXConcept2XResourceInstanceest pré-sentée dans la sous-section précédente).

Cette implantation se compose de deux règles complémentaires, dédiées à chaque situa-tion (avec ou sans ressource disponible). Ce mécanisme est présenté dans l’algorithme 4.10du chapitre 4, page 92.

Listing B.7:XConcept2XResourceInstance: exemple générique (disponibilité 0/1 (a), en ATL)

1 -- Rule XConcept2XResourceInstance2 --3 -- Translate an application XConcept into a platforme resource instance4 -- typed by XResource. Both XConcept and XResource have criterion.5 --6 rule XConcept2XResourceInstance {78 from s : Application!XConcept (9 s.XConceptCriterion()

10 and11 thisModule.getResources(12 RTEPML!XResource, ’XResourceCriterion’, Sequence{}13 )->notEmpty()14 )1516 to t : RTEPML!ApplicationResourceInstance17 type <- thisModule.getResource(18 RTEPML!XResource, ’XResourceCriterion’, Sequence{}19 ),20 ...21 ),22 ...23 }2425 -- Rule XConcept2notXResourceInstance26 --27 -- Trace the lack of XResource (with XResourceCriterion)28 -- in the target execution platform.29 --30 rule XConcept2notXResourceInstance {3132 from s : Application!XConcept (33 s.XConceptCriterion()34 and35 thisModule.getResources(36 RTEPML!XResource, ’XResourceCriterion’, Sequence{}37 )->isEmpty()38 )3940 -- TRACE : Can’t reach previous translation.41 to t : Trace!LackOfResource (42 ...43 ),44 ...45 }

Dans un contexte déclaratif, l’exécution d’une des règles est guidée par des pré-conditions d’application des règles. Concrètement, une telle pré-condition est une formule(une propriété) qui accompagne la définition d’une règle. Cette formule doit être vérifiéepour que la règle puisse être appliquée (exécutée).

Dans la solution proposée, les conditions d’application des règles, exprimées dans lesinstructions de contrôle (Si, Sinon) de l’algorithme 4.10, sont ainsi implantées comme pré-condition d’application dans les définitions des règles (lignes 11 à 13, et 35à 37).


Ces pré-conditions s’appuient sur lehelpergetRessourcespour évaluer l’ensemble deséléments conformes au concept envisagé dans le modèle de la plate-forme (modèle transmiscomme paramètre à la transformation). Si cet ensemble n’est pas vide (not empty), la miseen œuvre du mécanisme applicatif est effectuée. Dans le cas contraire, une trace est générée.

Le helpergetResourcesmis à contribution est présenté dans cette annexe page 164.

Utilisation de conditions sur le déroulement d’une règle

Le listing B.8 illustre l’implantation d’une détection de mise à disposition de ressourcesau sein d’une règle ATL.

Cette implantation oriente l’exécution de la règle, selon que la plate-forme fournit oune fournit pas de ressource conforme au concept attendu. Ce mécanisme est présenté dansl’algorithme 4.11 du chapitre 4, page 92.

Listing B.8:XConcept2XResourceInstance: exemple générique (disponibilité 0/1 (b), en ATL)

1 -- Rule XConcept2XResourceInstance2 --3 -- Translate an application XConcept into a platforme resource instance4 -- typed by XResource. Both XConcept and XResource have criterion.5 --6 -- Trace the lack of XResource (with criterion) in the target platform.7 --8 rule XConcept2XResourceInstance {9

10 from s : Application!XConcept (11 s.XConceptCriterion()12 )13 using {14 resource : RTEPML!Resource =15 thisModule.getResource(16 RTEPML!XResource, ’XResourceCriterion’, Sequence{})17 }18 do {19 if ( not resource.oclIsUndefined() ) {20 -- Create a resource instance typed by resource21 thisModule.CreateResourceInstance(s, resource);22 } else {23 -- Trace the lack of resource24 thisModule.TraceLackOfResource(s, resource);25 }26 }27 }2829 -- Rule CreateResourceInstance30 --31 -- Called rule that generate an application resource instance typed by32 -- the resource passed to the rule in the second parameter, from the33 -- source element passed to the rule in the first parameter.34 --35 -- Parameters : A source application element and a platform resource.36 --37 rule CreateResourceInstance (38 source : OclAny, -- application element39 resource : RTEPML!Resource -- platform resource40 ) {41 to42 t : RTEPML!ApplicationResourceInstance (43 ...44 type <- resource,45 ...46 ),47 ...48 }

171

L’orientation du déroulement de la règleXConcept2XResourceInstanceest implantéepar un branchement conditionnel dans un contexte impératif (blocdo des lignes 18 à 26).En effet, la technologie ATL ne permet pas d’exprimer des conditions sur la génération d’unensemble d’éléments, au sein d’une règle, dans un contexte déclaratif.

Dans ce contexte, deux règles sont explicitement appelées (CreateResourceInstanceetTraceLackOfResource), selon qu’une ressource conforme au concept envisagé est fournieou n’est pas fournie par la plate-forme cible.

La règle appelée (called rule) CreateResourceInstance(ligne 37) génère, entre autres,une instance de ressource typée par la ressource passée en paramètre (nous aborderons lagénération des propriétés et des appels de services dans la suite de cetteannexe).

Parallèlement, la règleTraceLackOfResourcegénère une trace si la plate-forme ciblene fournit pas de ressource conforme au concept impliqué dans la règle. L’implantation decette règle ne sera pas présentée dans ce rapport.

Enfin, on remarquera que la localisation de la ressource est effectuée dans un bloc dedéfinition de variable (using, ligne 13 à 17). Cette localisation s’appuie sur lehelpergetRe-sourceprésenté dans cette annexe, page 164.

RègleXConcept2XResourceInstance(prototypes de conception)

Le listing B.9, page suivante, illustre l’introduction d’une prise en compte desprototypes de conception dans une règle ATL (ce listing reprend la règleXCon-cept2XResourceInstanceprésentée dans le listing B.8 de la sous-section précédente).

A l’image d’une détection de mise à disposition de ressources présentés précédemment,deux approches sont envisageables pour orienter la transformation enfonction de la pré-sence d’un prototype de conception. La première approche consiste à créer une règle décla-rative dédiée à chaque cas identifié (avec ou sans prototype). L’exécution d’une des règlesest alors guidée par des pré-conditions. La seconde approche consiste à orienter l’exécutiond’une unique règle, par un branchement conditionnel, dans un contexteimpératif.

Le premier mécanisme à l’inconvénient d’être coûteux en nombre de règles et donc pluslong à implanter. La solution présentée implante donc le second mécanisme. Ce mécanismea été introduit dans l’algorithme 4.12 du chapitre 4, page 94.

En fonction de la mise à disposition, par la plate-forme cible, d’un prototype deconcep-tion pour mettre en œuvre un concept donné, la règleXConcept2XResourceInstanceinvoqueexplicitement une règle appropriée.

Ainsi, lorsque la ressource impliquée dans la règle est directement instanciable (aucunprototype n’est présent), la règleCreateResourceInstanceest invoquée (ligne 25). Cetterègle a été introduite dans le listing B.8 de la sous-section précédente. Son principe consisteà générer une instance de ressource dont le type est passé en paramètre.

Parallèlement, si un prototype de conception est précisé, la règleClonePrototypeestinvoquée (ligne 33). Cette règle génère alors un ensemble d’instances deressources confor-mément à ce que précise le prototype. La règleClonePrototypeest présentée dans la sous-section suivante.

On remarquera qu’une séquence (variable) nomméeSetOfInstancesest initialisée avantl’appel de la règleClonePrototype(ligne 31). Cette structure y sera utilisée pour mémoriserles instances générées à partir du prototype. Son rôle sera détaillée dansla suite de cetteannexe. On remarquera également qu’un chaîne vide est passée en second paramètre de larègleClonePrototype. Le rôle de ce paramètre est souligné dans la sous-section suivante.


Listing B.9:XConcept2XResourceInstance: exemple générique (prototypes de conception, en ATL)

1 -- Rule XConcept2XResourceInstance2 --3 -- Translate an application XConcept into a platforme resource instance4 -- typed by XResource. Both XConcept and XResource have criterion.5 -- A resource provided by the target platform conform to the XResource6 -- may be described with a design prototype.7 --8 -- Trace the lack of XResource (with criterion) in the target platform.9 --

10 rule XConcept2XResourceInstance {1112 from s : Application!XConcept (13 s.XConceptCriterion()14 )15 using {16 resource : RTEPML!Resource =17 thisModule.getResource(18 RTEPML!XResource, ’XResourceCriterion’, Sequence{})19 }20 do {21 if ( not resource.oclIsUndefined() ) {22 if (resource.prototype.oclIsUndefined()) {23 -- without prototype :24 -- create a resource instance typed by resource25 thisModule.CreateResourceInstance(s, resource);2627 } else {28 -- with prototype :29 -- create resource instances according to the prototype,30 -- (1) initialize a SetOfInstances structure31 thisModule.initSequence(’SetOfInstances’);32 -- (2) create the elements33 thisModule.ClonePrototype(s, ’’, resource);34 }35 } else {36 -- Trace the lack of resource37 thisModule.TraceLackOfResource(s, resource);38 }39 }40 }

RègleClonePrototype

Le listing B.10, page suivante, illustre la génération d’un ensemble d’instances de res-sources, conformément à ce que précise un prototype de conception. La règleCloneProto-typede ce listing est mise à contribution dans le listing B.9 de la sous-section précédente.Son principe est introduit dans l’algorithme 4.13 du chapitre 4, page 94.

La règleClonePrototypeest une règle ATL explicitement appelée (called rule). Lesparamètres de cette règle concernent :

– l’élément applicatif à mettre en œuvre (source),– un préfixe utile au nommage des instances à générer si une hiérarchie deprototypes

est impliquée (nous détaillons ce principe dans la suite de cette sous-section)et– la ressource de la plate-forme qui fournit le prototype de conception (resource).

Cette règle se déroule en deux temps. Dans un premier temps, l’ensemble des instancesreprésentées dans le prototype est générée pour l’application (lignes 17 à 36). Dans unsecond temps, ces instances sont mises en relation, à l’image des associations spécifiéesdans le prototype (lignes 39 à 42).

173

Listing B.10:ClonePrototype: appliquer un prototype de conception (en ATL)

1 -- Rule ClonePrototype2 --3 -- Called rule that generate application resource instances4 -- and their associations according to a design prototype.5 --6 -- Parameters : A source application element, a prefix (used to identifie7 -- instances when hierachic prototypes are used), and8 -- a platform resource that provides a design prototype.9 --

10 rule ClonePrototype(11 source : OclAny, -- application element12 prefix : String, -- prefix for the instance names13 resource : RTEPML!Resource -- platform resource14 ) {15 do {16 -- Create resource instances according to the prototype17 for (i in resource.prototype.instances) {1819 if ( i.isNotPlatformResourceInstance() ) {2021 -- the considered instance within the prototype22 -- is not a platform native one (predefined)2324 if ( i.type.prototype.oclIsUndefined() ) {25 -- without prototype :26 -- generate an application resource instance27 thisModule.CreateResourceInstanceFromPrototype(28 source, prefix, resource, i );29 } else {30 -- with prototype :31 -- recursive call32 thisModule.ClonePrototype(33 source, prefix + i.name, i.type );34 }35 }36 }3738 -- Create resource instance associations according to the prototype39 for (a in resource.prototype.associations) {40 thisModule.CreateAssociationFromPrototype(41 source, prefix, resource, a );42 }43 }44 }

Les éléments d’un prototype de conception peuvent représenter des instances de res-sources propres au prototype ou des instances de ressource prédéfinies sur la plate-formed’exécution. Seule les instances propres au prototype engendre une génération d’instancepour l’application (ligne 19). Les instances prédéfinies sont mises à disposition par la plate-forme, elles sont donc accessibles dans le modèle de la plate-forme.

Lors de la génération des instances, deux situations peuvent se présenter, selon quel’instance à générer est typée par une ressource unique, directementinstanciable, ou parune ressource dont la mise en œuvre relève (elle aussi) d’un prototype deconception.

Dans le premier cas, une instance est générée via un appel à la règleCreateResourceIns-tanceFromPrototype(ligne 27). Cette règle est présentée dans la sous-section suivante.

Dans le second cas, l’ensemble des instances du prototype est généré par un appel ré-cursive à la règleClonePrototype(ligne 32), avec comme paramètres l’élément applicatif àmettre en œuvre, le préfixe enrichi du nom de l’instance considérée (l’instance dont la miseen œuvre se conforme également à un prototype) et la ressource qui type cette instance(ressource qui fournit le prototype nouvellement considéré).


Lors d’appels récursifs, l’unicité des noms des instances générées est ainsi garantie, enpréfixant le nom des instances par le nom du chemin de progression à travers la hiérarchiede prototypes (le nom du chemin est donné par la concaténation des nom successifs desinstances concernées dans les prototypes).

Finalement, les associations entre les instances qui viennent d’être générées sont égale-ment générées, conformément à ce que précise le prototype. Pour cela,la règleCreateAsso-ciationFromPrototypeest appelée (ligne 40). Cette règle est présentée dans la suite de cetteannexe, page 175.

RègleCreateResourceInstanceFromPrototype

Le listing B.11 illustre la génération d’une instance de ressource à partir d’une instancede ressource stipulée dans un prototype de conception. La règleCreateResourceInstance-FromPrototypede ce listing est mise à contribution dans le listing B.10 de la sous-sectionprécédente. Son principe est introduit dans l’algorithme 4.14 du chapitre 4, page 95.

La règleCreateResourceInstanceFromPrototypeest une règle ATL explicitement appe-lée (called rule). Les paramètres de cette règle concernent :

– l’élément applicatif à mettre en œuvre (source),– un préfixe utile au nommage de l’instance à générer (son rôle a été présenté dans la

sous-section précédente),– la ressource de la plate-forme qui fournit le prototype de conception (resource),– l’instance de ressource concernée, issue de ce prototype.

Listing B.11:CreateResourceInstanceFromPrototype: générer une instance à partir d’un prototype (en ATL)

1 -- Rule CreateResourceInstanceFromPrototype2 --3 -- Called rule that create an application resource instance4 -- from an instance represented in a resourcedesign prototype.5 --6 -- Parameters : A source application element, a prefix (used to identifie7 -- instance when hierachic prototypes are used), a platform8 -- resource that provides the design prototype, and the9 -- considered instance.

10 --11 rule CreateResourceInstanceFromPrototype(12 source : OclAny, -- application element13 prefix : String, -- prefix for the instance name14 resource : RTEPML!Resource, -- platform resource15 instance : RTEPML!PrototypeResourceInstance,16 ) {17 to18 t : RTEPML!ApplicationResourceInstance (19 ...20 name <- source.name + prefix + instance.name,21 type <- instance.type,22 ...23 )24 do {25 -- Add created element into the SetOfInstances structure26 thisModule.addSequence(’SetOfInstances’, t);27 }28 }

La règleCreateResourceInstanceFromPrototypegénère une instance de ressource dontle type est déduit de celui de l’instance spécifiée dans le prototype (ligne 21). On remarqueral’utilisation du préfixe dans la convention de nommage d’une instance générée (ligne 20).

175

Chaque instance générée de la sorte est référencée dans une structure de données (Se-tOfInstances, ligne 26). Cette structure est consultée, par la suite, pour la génération desassociations entre les instances (dans la règleCreateAssociationFromPrototypeintroduitedans la sous-section précédente et présentée dans la sous-section suivante).

Leshelpersrelatifs à la structureSetOfInstancessont présentées dans la suite de cetteannexe (page 177).

RègleCreateAssociationFromPrototype

Le listing B.12, page suivante, illustre la génération d’une association, dans le modèle del’application déployée, à partir d’une association stipulée dans un prototype de conception.La règleCreateAssociationFromPrototypede ce listing est mise à contribution lorsqu’unprototype est appliqué pour générer un ensemble d’instances (listing B.10, page 173). Sonprincipe est introduit dans l’algorithme 4.15 du chapitre 4, page 96.

La règleCreateAssociationFromPrototypeest une règle ATL explicitement appelée (cal-led rule). Les paramètres de cette règle concernent :

– l’élément applicatif dont la mise en œuvre suit le prototype de conception (source),– le préfixe impliqué dans le nommage des instances de ressources concernées par l’as-

sociation (le rôle de ce préfixe a été présenté dans la sous-section précédente),– la ressource de la plate-forme qui fournit le prototype de conception (resource),– l’association concernée, issue de ce prototype.

La règleCreateAssociationFromPrototypegénère une association dont les extrémités(srcetdst) sont déduites des extrémités de l’association stipulée dans le prototype (lignes 22et 23). Pour cela unhelpergetInstanceest introduit.

Le helper getInstance(défini ligne 34) localise, dans le modèle du système généré,l’instance qui correspond à ce que représente l’élément du prototype auquel il s’applique.Or comme cela a été rappelé précédemment, les éléments d’un prototype représentent soitune instance de ressource propre à l’application, soit une instance de ressource prédéfiniesur la plate-forme d’exécution. Deux situations se présentent alors.

Si l’instance concernée est une instance de ressource prédéfinie sur la plate-forme, celle-ci est directement accessible dans le modèle du système généré (puisque ce modèle com-prend le modèle de la plate-forme d’exécution cible). L’accès à cette instance se fait alors autravers de l’associationmatchqui relie l’élément du prototype à l’instance de la plate-formequ’elle représente (ligne 49).

Si l’instance concernée est propre à l’application, la localisation de cette instance s’ap-puie sur la structure de donnéesSetOfInstances. Cette structure mémorise l’ensemble desinstances qui ont été générées à partir des éléments du prototype (ce principe a été introduitdans la sous-section précédente). L’instance concernée est alors localisée dans la structureSetOfInstancesà partir de son nom. Les informations impliquées dans le nommage de l’ins-tance sont fournies auhelper, via le paramètreinfoname.

Cependant, l’instance concernée a pu être générée à partir d’un élément du prototypedont le type (la ressource) est directement instanciable, ou à partir d’unautre prototype deconception (cf.ClonePrototype, page 172). Dans le premier cas, les informations de nom-mage fournies suffisent pour la localisation (ligne 42). Dans le second cas, la localisationde l’instance s’appuie sur lehelpergetMasterNamepour identifier l’instance « maîtresse »qui ressort de la hiérarchie de prototypes (cf. Motifs de conception, page 69). Le nom decette instance maîtresse permet alors de référencer l’instance concernée par l’association,en suivant le protocole de nommage utilisé (ligne 44).


Remarque : En pratique, le protocole de nommage peut être capturé dans des helpers.

Listing B.12:CreateAssociationFromPrototype: générer les associations (en ATL)

1 -- Rule CreateAssociationFromPrototype2 --3 --4 -- Called rule that create an application resource instance association from5 -- an association between prototype resource instance in a design prototype.6 --7 -- Parameters : A source application element, a prefix (used to identifie8 -- instance when hierachic prototypes are used), a platform9 -- resource that provides the design prototype, and the

10 -- considered association.11 --12 rule CreateAssociationFromPrototype(13 source : OclAny, -- application element14 prefix : String, -- prefix for the instance name15 resource : RTEPML!Resource, -- platform resource16 association : RTEPML!PrototypeResourceInstanceAssociation17 ) {18 to19 t : RTEPML!ResourceInstanceAssociation (20 ...21 name <- source.name + prefix + association.name,22 src <- association.src.getInstance(source.name + prefix),23 dst <- association.dst.getInstance(source.name + prefix)24 )25 }2627 -- Helper getInstance28 --29 -- Parameter : An information about an application resource instance that was30 -- genereted from the ’self’ prototype resource instance.31 -- Return : The application instance that was generated from the32 -- ’self’ prototype resource instance.33 --34 helper context RTEPML!PrototypeResourceInstance35 def : getInstance(infoname : String) : RTEPML!ResourceInstance =3637 if (self.isNotPlatformResourceInstance())38 then39 -- select the correct generated instance,40 -- into the SetOfInstances structure41 if (self.type.prototype.oclIsUndefined())42 then thisModule.selectSequence(’SetOfInstances’,43 infoname + self.name)44 else thisModule.selectSequence(’SetOfInstances’,45 infoname + self.name + self.getMasterName())46 endif4748 else -- use platform resource instance49 self.match5051 endif;5253 -- Helper getMasterName54 --55 -- Return : The name of the prototype resource instance whith ’master’ role.56 --57 helper context RTEPML!PrototypeResourceInstance58 def: getMasterName() : String =5960 self.type.prototype.masterInstance.name +61 if (not self.type.prototype.masterInstance62 .type.prototype.oclIsUndefined())63 then self.type.prototype.masterInstance.getMasterName()64 else ’’65 endif;

177

Structure SetOfInstances

Le listing B.13 présente la structureSetOfInstancesmise à contribution pour mémori-ser et localiser les instances de ressources générées à partir des prototypes de conception.Cette structure et les opérations qui l’accompagnent sont utilisées au seindes règles quiconcernent les prototypes de conception, dans les sous-sections précédentes.

Listing B.13:SetOfInstances: une structure de mémorisation d’instances de ressources (en ATL)

1 -- Helper SetOfInstance2 --3 -- A sequence of resource instances.4 --5 helper def : SetOfInstance : Sequence(RTEPML!ResourceInstance) =6 Sequence{};78 -- Helper initSequence9 --

10 -- Initialize an empty sequence.11 --12 -- Parameter : The name of the sequence to initialize.13 --14 helper def : initSequence(structure : String) : OclAny =15 thisModule.refSetValue(structure, Sequence{});1617 -- Helper addSequence18 --19 -- Add an element into a sequence.20 --21 -- Parameters : The name of the sequence and the element to add.22 --23 helper def : addSequence(structure : String, element : OclAny) : OclAny =24 thisModule.refSetValue(25 structure,26 thisModule.refGetValue(structure)->including(element) );2728 -- Helper selectSequence29 --30 -- Select an element into the sequence, by its name.31 --32 -- Parameters : The name of the sequence and33 -- the name of the element to select.34 -- Return : The selected element.35 --36 helper def : selectSequence(structure : String, name : String) : OclAny =37 thisModule.refGetValue(structure)38 ->select(e | e.name = name)39 ->first();

La structureSetOfInstancesest une séquence d’instances de ressources définie par unhelper(ligne 5).

Trois opérations sur les séquences sont définies pour en faciliter l’utilisation :

– initSequence: Initialise une séquence vide dont le nom est passé en paramètre ;– addSequence: Ajoute un élément passé en paramètre, à une séquence dont le nom

est également passé en paramètre ;– selectSequence: Retourne un élément dont le nom est passé en paramètre, à partir

d’une séquence dont le nom est également passé en paramètre.

Ces opérations s’appuient leshelpersrefGetValueet refSetValuefournis par ATL.

Remarque : La sélection d’une instance dans la structureSetOfInstancess’appuie surle nom de l’instance pour la localiser. Une solution basée sur une comparaison d’élémentest également envisageable. L’utilisation d’une telle sélection nécessite alors de modifierl’utilisation qui en est faite dans les algorithmes concernés.


RègleCreateResourceInstance(renseignement des propriétés)

Le listing B.14, page suivante, illustre l’implantation d’un mécanisme de renseignementdes propriétés lors d’une génération d’instance, sans prototype de conception.

Le renseignement des propriétés, dans un contexte qui ne met pas à contribution deprototype de conception, est présenté dans l’algorithme 4.16, du chapitre4, page 99.

La règleCreateResourceInstancea été introduite dans le listing B.8, page 170. Son prin-cipe consiste à générer une instance de ressource dont le type est passé en paramètre. Elleest explicitement appelée par la règleXConcept2XResourceInstance(listing B.8 et B.9).

La gestion des propriétés se fait au sein de cette règle dans un contexte impératif(lignes 24 à 67). Cette gestion se déroule en trois grandes étapes.

La première étape mémorise dans une structure (InstancesMemory) l’instance généréepar la règle et l’élément source à l’origine de sa création (ligne 28). Cette structure serautilisée pour localiser les instances qui ont été générées, dans le but de les référencer. Leréférencement des instances au cours de la transformation a été présenté et discuté dans lasous-section qui concerne le renseignement des propriétés du chapitre 4, page 102.

La seconde étape renseigne les propriétés de l’instance. Elle parcourtpour cela l’en-semble des propriétés associées au concept auquel se conforme la ressource qui type l’ins-tance. Cet ensemble est retourné par lehelpergetPropertyRoles(ligne 31). Cehelpernesera pas détaillé dans cette annexe. Son implantation se restreint à retourner une séquencede noms de rôles (définis « en dur » dans lehelper).

Les propriétés renseignées sont celles dont dispose la ressource qui type l’instance surla plate-forme cible, et pour lesquelles le modèle de l’application fournit des informations(conditions des lignes 32 et 33).

Le renseignement des propriétés s’effectue alors en deux phases successives. La pre-mière concerne les propriétés renseignées par une valeur littérale (lignes39 à 47). La se-conde concerne les propriétés renseignées par une référence vers une instance de ressource(lignes 49 à 57). LeshelpersgetPropertyValueset getPropertyReferencesse chargent decollecter les valeurs ou les références. Leurs implantations, propres aumétamodèle de l’ap-plication, ne seront pas détaillées dans cette annexe.

Dans chacune de ces phases, la création des propriétés de l’instance est déléguée à larègle CreateResourceInstanceProperty. Cette règle, explicitement appelée, prend commeparamètre la propriété concernée et soit la valeur littérale, soit la référence, qui lui est affec-tée. La propriété concernée est localisée par lehelpergetPropertyque nous avons introduitprécédemment dans cette annexe (page 165). Une implantation de la règleCreateResour-ceInstancePropertyest présentée dans la sous-section suivante.

L’implantation proposée pour cette seconde phase génère finalement unetrace lors-qu’une propriété susceptible d’être renseignée est ignorée lors du déploiement (ligne 61).

Enfin, la troisième et dernière phase vise à compléter les propriétés d’instances exis-tantes dont la référence concerne l’instance que la règle vient de générer. Cette phase estdéléguée à la règleCompletePropertyReferences(ligne 66). Une implantation de cette règleest présentée dans la suite de cette annexe (page 181).

Le mécanisme de mémorisation des propriétés à compléter (celles qui référencent uneinstance qui n’a pas encore été générée) est présenté dans ce rapport, dans la sous-sectionqui concerne le renseignement des propriétés (chapitre 4, page 102). Dans l’implantationproposée, la détection et la mémorisation des propriétés à compléter se fait ausein de larègleCreateResourceInstanceProperty. Ce mécanisme est donc abordé plus en détail dansla sous-section suivante.

179

Listing B.14:CreateResourceInstance: règle générique (gestion des propriétés, en ATL)

1 -- Rule CreateResourceInstance2 --3 -- Called rule that generate an application resource instance typed by4 -- the resource passed to the rule in the second parameter, from the5 -- source element passed to the rule in the first parameter.6 --7 -- This rule is called by XConcept2XResourceInstance rule.8 --9 -- Parameters : A source application element and a platform resource.

10 --11 rule CreateResourceInstance (12 source : OclAny, -- application element13 resource : RTEPML!Resource -- platform resource14 ) {15 to16 t : RTEPML!ApplicationResourceInstance (17 ...18 type <- resource,19 properties <- Sequence{},20 ...21 ),22 ...2324 do {25 -- memorize correspondance between source element and26 -- generated instance (useful to locate which instances27 -- have been already generated, in order to reference them)28 thisModule.addSequence(’InstancesMemory’, Sequence{source, t});2930 -- fill in properties31 for ( role in resource.getPropertyRoles() ) {32 if ( not t.type.getProperty(role).oclIsUndefined()33 and source.hasPropertyInformation(role)34 ) {35 -- the type of the target element accept a property and36 -- a property information exists in the source element3738 -- generate properties with value39 for ( value in source.getPropertyValues(role) ) {40 t.properties.append(41 thisModule.CreateResourceInstanceProperty(42 t.type.getProperty(role),43 value,44 OclUndefined45 )46 );47 }48 -- generate properties with reference49 for ( reference in source.getPropertyReferences(role) ) {50 t.properties.append(51 thisModule.CreateResourceInstanceProperty(52 t.type.getProperty(role),53 OclUndefined,54 reference55 )56 );57 }5859 } else {60 -- Trace the lack of property61 thisModule.TraceLackOfProperty(source, resource, role);62 }63 }6465 -- fill in incomplete properties66 thisModule.CompletePropertyReferences(source, t);67 }68 }


RègleCreateResourceInstanceProperty

Le listing B.15 illustre l’implantation d’une règle ATL dédiée à la création des propriétésd’instances de ressources (ResourceInstanceProperty).

Cette règle,CreateResourceInstanceProperty, est mise à contribution pour renseignerles propriétés, dans la règleCreateResourceInstancede la sous-section précédente.

Listing B.15:CreateResourceInstanceProperty: création d’une propriété (en ATL)

1 -- Rule CreateResourceInstanceProperty2 --3 -- Called rule that generate an application resource instance property4 -- fill in with either a value or a reference to a resource instance.5 --6 -- This rule is called by the CreateResourceInstance rule.7 --8 -- Parameters : The property to fill in, the value and the reference.9 --

10 rule CreateResourceInstanceProperty (11 property : RTEPML!ResourceProperty,12 value : String,13 reference : OclAny14 ) {15 to16 t : RTEPML!ResourceInstanceProperty (17 property <- property,18 val <- value,19 ref <- thisModule.getInstance(reference)20 )21 do {22 if ( not reference.oclIsUndefined()23 and t.ref.oclIsUndefined()24 ) {25 thisModule.addSequence(26 ’SetOfPropertyToComplete’, Sequence{reference, t} );27 }28 }29 }3031 -- Helper getInstance32 --33 -- Parameter : A source application element.34 -- Return : A resource instance generated from the source application35 -- element passed to the helper (if that instance has already36 -- been generated).37 -- Use : Locate target element into the InstancesMemory structure.38 --39 helper def : getInstance(reference : OclAny) : RTEPML!ResourceInstance =4041 let memory : Sequence(OclAny) =42 thisModule.refGetValue(’InstancesMemory’)43 ->select(e | e.first() = reference) in4445 if memory.oclIsUndefined()46 then OclUndefined47 else memory.last()48 endif;

La règleCreateResourceInstancePropertyest une règle explicitement appelée (calledrule). Les paramètres de cette règle concernent :

– une propriété à renseigner ;– une valeur littérale, lorsque la propriété est renseignée par une valeur;– une instance de ressource, lorsque la propriété est renseignée parune référence.

181

Remarque : Bien qu’une valeur littérale et une référence puisse renseignées une pro-priété, en pratique les deux formes ne sont pas utilisées conjointement.

La règleCreateResourceInstancePropertygénère une propriété d’instance de ressource(ResourceInstanceProperty) associée à la propriété passée en paramètre. La valeur (val) decette propriété d’instance est renseignée par le second paramètre. Sa référence vers uneinstance de ressource (ref) est déduite du troisième paramètre. Cette déduction repose surle helpergetInstancedéfini dans le même listing (ligne 39).

Le helpergetInstances’appuie sur la structureInstancesMemoryévoquée dans la sous-section précédente. Cette structure mémorise les instances de ressourcesqui sont générées,ainsi que les éléments source à l’origine de leur génération (cette mémorisationest effectuéelors de la création des instances, au fur et à mesure de l’exécution de la transformation).

Le helpergetInstancelocalise donc, au sein de cette structure, l’instance qui a été gé-nérée à partir de l’élément source désigné pour renseigner la propriété. Si cette instance n’apas encore été générée (i.e. si le couple formé de l’élément source et de l’instance généréen’est pas présent dans la structure), lehelperne retourne pas d’instance (OclUndefined).

Au sein de la règleCreateResourceInstancePropertyl’absence d’instance retournéepar lehelpergetInstance, bien qu’une référence soit stipulée pour renseigner la propriété,conduit à mémoriser la propriété (alors incomplète) et l’élément source dontl’instance cor-respondante n’est pas encore disponible dans le modèle généré (lignes22 à 26). Cette mé-morisation se fait dans une structure (SetOfPropertyToComplete) dont les principes de ma-nipulation s’apparentent a ce qui a été présenté pour la structureSetOfInstances(page 177).

Comme cela fut abordé dans la sous-section précédente, les références des propriétés àcompléter sont résolues lors de la création des instances manquantes (quand les élémentssources à l’origine de la génération de ces instances sont transformés). Cette résolution estassurée par la règleCompletePropertyReferencesprésentée dans la sous-section suivante.

RègleCompletePropertyReferences

Le listing B.16, page suivante, illustre l’implantation d’une règle ATL qui se destine àrenseigner des propriétés d’instances encore incomplètes.

Cette règle,CompletePropertyReferences, est mise à contribution pour renseigner lespropriétés, dans la règleCreateResourceInstanceprésentée dans cette annexe, page 178.

La règleCompletePropertyReferencesest une règle explicitement appelée (called rule).Les paramètres de cette règle concernent :

– un élément source à l’origine de la création de l’instance de ressource passée dansl’autre paramètre ;

– l’instance de ressource que nous venons de mentionner (susceptible de renseigner desréférences dans des propriétés d’instances encore incomplètes).

La règle s’appuie sur la structureSetOfPropertyToCompleteque nous avons introduitdans la sous-section précédente. Cette structure mémorise des couples composés d’un élé-ment source et d’une propriété à compléter par une référence vers l’instance de ressourcegénérée à partir de cet élément source.

Dans un unique bloc impératif, la règle parcourt l’ensemble des propriétésà compléterconcernées par l’élément source passé en paramètre (ligne 18). Chacune de ces propriétésest alors renseignée par une référence vers l’instance de ressource passée en second pa-ramètre (ligne 23). Les propriétés ainsi complétées sont finalement retirées de la liste despropriétés à compléter (ligne 26).


Listing B.16:CompletePropertyReferences: résolution des références pour les propriétés (en ATL)

1 -- Rule CompletePropertyReferences2 --3 -- Called rule that complete resource instance properties whose4 -- referenced element was not generated when they are created.5 --6 -- That rule is called by the CreateResourceInstance rule.7 --8 -- Parameter : A source element and its corresponding generated resource9 -- instance that is perhaps referenced by incomplete properties.

10 --11 rule CompletePropertyReferences (12 source : OclAny,13 instance : RTEPML!ResourceInstance14 ) {15 do {16 -- for each property that must refer to the instance17 -- generated from the source element18 for (property in19 thisModule.refGetValue(’SetOfPropertyToComplete’)20 ->select(e | e.first() = source) ) {2122 -- resolve the reference with the correponding instance23 property.last().ref <- instance;2425 -- delete the property from the set of property to complete26 thisModule.delSequence(’SetOfPropertyToComplete’, property);27 }28 }29 }

Remarque : Nous ne détaillerons pas, dans la suite de cette annexe, plus derègles pource qui concerne la gestion des propriétés. La gestion des propriétés que nous venons de pré-senter dans les trois dernières sous-sections de cette annexe, ne concerne que la générationd’instances de ressources sans mise à contribution de prototypes de conception. Il convientdonc de préciser que la prise en compte de prototypes de conception nécessite de modifierd’une part les règlesClonePrototype(page 172) etCreateResourceInstanceFromPrototype(page 174) dans le respect des algorithmes 4.17 et 4.18 présentés dansle chapitre 4. Maiségalement de modifier les structures de mémorisation, leurs accès et les règles que nousvenons de présenter pour s’adapter aux prototypes, à leur hiérarchie d’application et surtoutà la prise en compte des instances issues des prototypes (instances potentiellement mises àcontribution dans toutes les règles qui se réfèrent à des instances de ressources).

RègleCreateResourceInstance(génération d’appels de services)

Le listing B.17, page suivante, illustre l’implantation d’une gestion d’appels deservices,lors d’une génération d’instance, sans prototype de conception.

La gestion des services associés aux ressources que fournit une plate-forme d’exécution,dans un contexte qui ne met pas à contribution de prototype de conception,est présentéedans l’algorithme 4.21, du chapitre 4, page 107.

La règleCreateResourceInstancea été introduite dans le listing B.8, page 170, et com-plétée pour la gestion des propriétés dans le listing B.14, page 179. Son principe consiste àgénérer une instance de ressource dont le type est passé en paramètre. Elle est explicitementappelée par la règleXConcept2XResourceInstance(listing B.8 et B.9).

La génération des appels de services se fait au sein de cette règle dans un contexteimpératif (lignes 24 à 59). Cette gestion se déroule en trois grandes étapes.

183

La première étape mémorise dans une structure (InstancesMemory) l’instance généréepar la règle et l’élément source à l’origine de sa création (ligne 28). Cette étape a été in-troduite et présentée précédemment pour la gestion des propriétés (page178). La structureInstancesMemoryest utilisée par lehelpergetInstance(listing B.15, page 180) pour locali-ser les instances qui ont été générées, dans le but de les référencer.

Listing B.17:CreateResourceInstance: règle générique (génération d’appels de service, en ATL)

1 -- Rule CreateResourceInstance2 --3 -- Called rule that generate an application resource instance typed by4 -- the resource passed to the rule in the second parameter, from the5 -- source element passed to the rule in the first parameter.6 --7 -- This rule is called by XConcept2XResourceInstance rule.8 --9 -- Parameters : A source application element and a platform resource.

10 --11 rule CreateResourceInstance (12 source : OclAny, -- application element13 resource : RTEPML!Resource -- platform resource14 ) {15 to16 t : RTEPML!ApplicationResourceInstance (17 ...18 type <- resource,19 call <- Sequence{},20 ...21 ),22 ...2324 do {25 -- memorize correspondance between source element and26 -- generated instance (useful to locate which instances27 -- have been already generated, in order to reference them)28 thisModule.addSequence(’InstancesMemory’, Sequence{source, t});29 ...3031 -- generate call services32 for ( service in source.getCallServices() ) {33 -- for each information provided by the source34 -- element in order to call a service3536 if ( not service.get(’concept’)37 .getService(service.get(’role’))38 .oclIsUndefined()39 ) {40 -- the type of the element that is concerned41 -- by the service provide it4243 t.call.append(44 thisModule.CreateCallService(45 service.get(’element’),46 service.get(’concept’),47 service.get(’role’)48 )49 );5051 } else {52 -- Trace the lack of call service53 thisModule.TraceLackOfService(source, resource, service);54 }55 }5657 -- fill in incomplete call service58 thisModule.CompleteCallServiceReferences(source, t);59 }60 }


La seconde étape génère les appels de services. Elle parcourt pour cela une séquencede tuples (élément, concept, rôle) associés à l’élément source. Cette séquence est retournéepar lehelpergetCallServices(ligne 32).

Un tuple (élément, concept, rôle) correspond à un appel au service identifié par unrôle, adressé à une instance générée à partir d’unélément, conformément à unconcept.Remarque : Les accès aux champs du tuple se font avec l’opération OCL getsur uneMap).

Le helpergetCallServicesne sera pas détaillé dans cette annexe. Son implantation estpropre à la technologie de modélisation de l’application source. Un exemple d’algorithmeest donné page 109.

Les appels générés sont ceux dont le service appelé est fournit parla ressource qui typel’instance à laquelle s’adresse le service (condition des lignes 36 à 38).

La création de l’appel de service est déléguée à la règleCreateCallService(ligne 44).Cette règle, explicitement appelée, prend comme paramètres les différentes informationsassociées au service (élément, concept et rôle) que nous venons d’évoquer. Une implantationde la règleCreateResourceInstanceCallServiceest présentée dans la sous-section suivante.

L’implantation proposée pour cette seconde phase génère finalement unetrace lorsqu’unservice susceptible d’être appelé est ignoré lors du déploiement (ligne 53).

Enfin, la troisième et dernière phase vise à compléter les appels de servicesincompletsdont l’une des références concerne l’instance que la règle vient de générer (soit l’instanceà laquelle s’adresse le service, soit une instance passée en paramètre). Cette phase est délé-guée à la règleCompleteCallServiceReferences(ligne 58). Cette règle ne sera pas détailléedans cette annexe. Son implantation s’apparente à celle de la règleCompletePropertyRefe-renceprésentée précédemment (page 181).

RègleCreateCallService

Le listing B.18, page ci-contre, illustre l’implantation d’une règle ATL dédiée à la créa-tion des appels de services (CallService).

Cette règle,CreateCallService, est mise à contribution pour générer les appels de ser-vices, lors de la création d’une instance de ressource, dans la règleCreateResourceInstancede la sous-section précédente.

La règleCreateCallServiceest une règle explicitement appelée (called rule). Les para-mètres de cette règle concernent :

– un élément source à l’origine de l’instance à laquelle s’adresse un service ;– le concept auquel se conforme la ressource qui type cette instance ;– le rôle du service.

La règleCreateCallServicegénère un appel (CallService) associé à un service et adresséà une instance de ressource (ref). Le service est localisé par lehelpergetService. Nous nedétaillerons pas cehelperdans la suite de ce rapport. Son implantation s’apparente à celledu helpergetPropertyintroduit précédemment dans cette annexe (page 165). L’instance deressource à laquelle s’adresse le service est déduite du premier paramètre. Cette déduc-tion repose sur lehelpergetInstanceque nous avons introduit précédemment (listing B.15,page 180, ligne 39).

Le helpergetInstancelocalise, au sein de la structureInstancesMemoryévoquée dansla sous-section précédente, l’instance qui a été générée à partir de l’élément source passé enparamètre. Si cette instance n’a pas encore été générée (i.e. si le couple formé de l’élémentsource et de l’instance générée n’est pas présent dans la structure), le helperne retourne pasd’instance (OclUndefined).

185

Au sein de la règleCreateCallServicel’absence d’instance retournée par lehelperge-tInstanceconduit à mémoriser l’appel de service (alors incomplet) et l’élément source dontl’instance correspondante n’est pas encore disponible (ligne 22). Cette mémorisation se faitdans une structure (SetOfCallServiceToComplete) dont la manipulation s’apparente a ce quia été présenté pour la structureSetOfInstances(page 177).

Comme cela fut abordé dans la sous-section précédente, les références des appels deservices à compléter sont résolues lors de la création des instances manquantes (quand leséléments sources à l’origine de la génération de ces instances sont transformés). Cette ré-solution est assurée par la règleCompleteCallServiceReferencesque nous avons évoquéeprécédemment.

Listing B.18:CreateCallService: création d’un appel de service (en ATL)

1 -- Rule CreateCallService2 --3 -- Called rule that generate a call service.4 --5 -- This rule is called by the CreateResourceInstance rule.6 --7 -- Parameters : The instance adressed by the service and the service.8 --9 rule CreateCallService (

10 element : OclAny,11 concept : RTEPML!Resource,12 role : String13 ) {14 to15 t : RTEPML!CallService (16 ref <- thisModule.getInstance(element),17 service <- concept.getService(role),18 parameters <- Sequence{}19 )20 do {21 -- detect service to complete22 if ( t.ref.oclIsUndefined() ) {23 thisModule.addSequence(24 ’SetOfCallServiceToComplete’, Sequence{element, t} );25 }2627 -- fill in parameters with value28 for ( val in reference.getParameterValues(role) ) {29 t.parameters.append(30 thisModule.CreateCallServiceParameter(val, OclUndefined)31 );32 }3334 --fill in parameters with reference35 for ( ref in reference.getParameterReferences(role) ) {36 t.parameters.append(37 thisModule.CreateCallServiceParameter(OclUndefind, ref)38 );39 }40 }41 }

Enfin, le renseignement des paramètres qui peuvent accompagner l’appel de services’effectue en deux phases successives. La première concerne lesparamètres renseignés parune valeur littérale (ligne 28). La seconde concerne les paramètres renseignés par une réfé-rence vers une instance de ressource (ligne 35). LeshelpersgetParameterValueset getPa-rameterReferencesse chargent de collecter les valeurs ou les références. Leur implantation,propre au métamodèle de l’application, ne sera pas détaillée dans cette annexe.


Dans chacune de ces phases, la création des appels de services est déléguée à la règleCreateCallServiceParameter. Cette règle, explicitement appelée, prend comme paramètresoit une valeur littérale, soit une référence. Nous ne la détaillerons pas dans la suite de cetteannexe. Son implantation s’apparente à celle de la règleCreateResourceInstancePropertyprésentée précédemment (page 180).

Templatesde génération de règles de transformations

Template Concept2ResourceInstance(simple)

Le listing B.19 illustre le principe d’untemplatede génération de règle du typeXCon-cept2XResourceInstance(présentée dans le listing B.9, page 172).

L’utilisation detemplatespour générer les règles de correspondances d’une transforma-tion de déploiement a été introduite dans la section 4.4.3, du chapitre 4, page 114.

Listing B.19:Templatede génération d’une règle ATL de déploiement (version simple)

1 /-- Template Concept2ResourceInstance2 --3 -- Generate an ATL transformation rule that make a correspondance4 -- between an application concept and an RTEPML resource.5 --6 -- Parameters : the application concept and the RTEPML ressource.7 --/8 template Concept2ResourceInstance(concept, resource) :9

10 -- Rule <concept><concept.criteria>2<resource>Instance<resource.criteria>11 --12 -- Generated13 --14 -- That rule translate an application <concept> with the <concept.criteria>15 -- criteria into a platforme resource instance typed by a <resource> with16 -- the <resource.criteria> criteria.17 --18 rule <concept><concept.criteria>2<resource>Instance<resource.criteria> {1920 from s : Application!<concept.name> (2122 /-- considere criteria that precise the concept --/23 <foreach criterion in concept.criteria>24 s.<criterion.name>(25 <foreach parameter in criterion.parameters>26 <parameter>27 <end foreach>28 )29 <end foreach>30 )31 using {32 resource : RTEPML!Resource = thisModule.getResource(33 RTEPML!<resource.name>,3435 /-- considere criteria that precise the resource --/36 ’<resource.criteria.name>’,37 Sequence{38 <foreach parameter in resource.criteria.parameters>39 <parameter>40 <end foreach>41 }42 )43 }44 do {45 ...46 }47 }

187

L’exemple proposé dans le listing B.19 ne s’appuie pas sur un langage detemplateprécis, mais reprend une syntaxe proche de langages existants (tel qu’Acceleo [79]).

Le principe d’untemplateest de fournir un code source dont une partie sera complétéesoit par un simple remplacement, soit par une construction plus complexe guidée par desstructures de contrôles. La génération d’un code source ainsi complétéet construit émaned’un moteur detemplate. Ce moteur prend en entrée letemplateet les informations néces-saires à la complétion de celui-ci. Ces informations peuvent provenir de différentes sources,tels que des bases de données ou des modèles.

Le templateprésenté dans le listing B.19 est censé prendre sa source d’information dansun modèle de déploiement conforme au métamodèle que nous avons introduit dans la sous-section 4.4.3 du chapitre 4, page 114 (figure 4.13). Un exemple de modèle associé à ce typedetemplateest disponible dans le listing 4.2 de cette même section, page 115.

Le templateproposé prend comme paramètres les « références » des concepts appli-catif et exécutif mis en correspondance (ces références sont respectivement conformes àApplicationConceptet àRTEPMLConceptdans le métamodèle de déploiement).

Les parties dutemplateà remplacer ou à construire se distinguent par des balises (engras dans le listing). La balise de la ligne 20 se destine par exemple à un remplacement.Alors que celle de la ligne 23 décrit un parcours sur un ensemble d’élémentsdu modèle dedéploiement. Remarque : La notion de paramètre associé à un critère est introduite dans lemétamodèle de déploiement présenté dans la sous-section 4.5.3, page 120 (figure 4.17).

Enfin, le code du bloc impératif (lignes 44 à 46) est identique à celui de la règle XCon-cept2XResourceInstanceprésentée dans le listing B.9, page 172. Ce code est générique àtout concept impliqué par la règle. Pour des raisons didactiques nous ne l’avons donc pasretranscrit dans cette exemple qui se concentre sur les parties qu’influence letemplate.

L’utilisation de cetemplatedans untemplatede génération de transformation est pré-sentée dans la suite de cette section (page 189).

Template Concept2ResourceInstance(décisions)

Le listing B.20, page suivante, illustre l’introduction de décision de déploiement dans untemplatede génération de règle du typeXConcept2XResourceInstance. Ce listing enrichitle code du listing B.19 présenté dans la sous-section précédente.

La considération de décisions de déploiement en réponse à des choix de déploiement aété introduite dans la section 4.5, du chapitre 4, page 118.

Le templateprésenté dans le listing B.20 prend sa source d’information dans un modèlede déploiement conforme au métamodèle que nous avons introduit dans la section 4.5 duchapitre 4, page 121 (figure 4.17). Un exemple de modèle associé à ce typede templateestdisponible dans le listing 4.4 de cette même section, page 122.

La règle générée par cetemplateconsidère successivement, dans ses pré-conditionsd’application, les critères qui précisent le concept applicatif qu’adresse cette règle(ligne 23), et les critères qui relèvent d’une décision face à un choix (ligne 32).

Cette considération est également implantée dans le code qui localise la ressource quitype l’instance de ressource générée par la règle (lignes 45 et 53). Onremarquera que pourcela, lehelpergetResourcea été modifiée pour prendre en compte un critère supplémentaire.Les modifications apportées à cehelper(initialement présenté dans cette annexe, page 164)ne seront pas détaillées dans ce rapport. Celles-ci n’introduisent aucun mécanisme d’im-plantation que nous n’ayons déjà abordé.


Listing B.20:Templatede génération d’une règle ATL de déploiement (décisions)

1 /-- Template Concept2ResourceInstance2 --3 -- Generate an ATL transformation rule that make a correspondance4 -- between an application concept and an RTEPML resource.5 --6 -- Parameters : the application concept and the RTEPML ressource.7 --/8 template Concept2ResourceInstance(concept, resource) :9

10 -- Rule <concept><concept.criteria>2<resource>Instance<resource.criteria>11 --12 -- Generated13 --14 -- That rule translate an application <concept> with <concept.criteria> and15 -- <concept.decisions> criteria into a platforme resource instance typed by16 -- a <resource> with <resource.criteria> and <resource.decisions> criteria.17 --18 rule <concept><concept.criteria>2<resource>Instance<resource.criteria> {1920 from s : Application!<concept.name> (2122 /-- considere criteria that precise the concept --/23 <foreach criterion in concept.criteria>24 s.<criterion.name>(25 <foreach parameter in criterion.parameters>26 <parameter>27 <end foreach>28 )29 <end foreach>3031 /-- considere decisions related to concept choice --/32 <foreach decision in concept.decisions>33 s.<decisions.name>(34 <foreach parameter in decisions.parameters>35 <parameter>36 <end foreach>37 )38 <end foreach>39 )40 using {41 resource : RTEPML!Resource = thisModule.getResource(42 RTEPML!<resource.name>,4344 /-- considere criteria that precise the resource --/45 ’<resource.criteria.name>’,46 Sequence{47 <foreach parameter in resource.criteria.parameters>48 <parameter>49 <end foreach>50 },5152 /-- considere decisions related to a resource choice --/53 ’<resource.decisions.name>’,54 Sequence{55 <foreach parameter in resource.decisions.parameters>56 <parameter>57 <end foreach>58 }59 )60 }61 do {62 ...63 }64 }

L’utilisation de cetemplatedans untemplatede génération de transformation est pré-sentée dans la sous-section suivante.

189

Template GenerateTransformation

Le listing B.21 illustre le principe d’une génération de transformation ATL de déploie-ment. Letemplatede ce listing fait appel autemplatede génération de règles présenté dansle listing B.20, de la sous-section précédente.

Listing B.21:Templatede génération d’une transformation ATL de déploiement

1 /-- Template GenerateTransformation2 --3 -- Generate an ATL transformation using a template that4 -- generate the deployment rules (Concet2ResourceInstance).5 --6 -- Parameter : the root of the deployment model.7 --8 --/9 template GenerateTransformation(deployment) :

1011 -- Transformation : Application to RTEPML12 --13 -- Generated14 --15 -- Allow to deploy an application on an execution platform.16 --17 module Application2RTEPML;18 create OUT : RTEPML from IN1 : Application, IN2 : RTEPML;1920 /-- Generate the matching rules according to the deployment model --/21 <foreach mapping in deployment.mapping>22 Concept2ResourceInstance( mapping.source, mapping.target )23 <end foreach>

Le principe de cetemplateest de générer chaque règle de correspondance (ou règle dedéploiement) d’après ce que décrit le modèle de déploiement qui le renseigne. Le modèlede déploiement et lestemplatessont transmis en entrée d’un moteur detemplate.

CTechnologies de modélisation explicite des

plates-formes d’exécution

193

Cette annexe propose un aperçu non exhaustif des technologies qui offrent des solu-tions de descriptions explicites des plates-formes d’exécution. Cet aperçu vise à recenserles potentielles de modélisation des plates-formes de notre domaine d’intérêt (les systèmesembarqués temps réel), au travers des métamodèles associés à ces technologies et des utili-sations qui en sont faites.

Cette annexe s’appuie sur des résultats énoncés dans l’état de l’art d’une étude an-térieure [114]. Elle aborde, dans deux parties distinctes, les technologies identifiées danschacune des approches UML et DSML.

C.0.1 Approche UML

PML (Platform Modeling Language) [107] est un métamodèle dédié à la descriptionde plate-forme au sens large (telles que des plates-formes d’exécution oud’analyse). Cemétamodèle définit les concepts de composants (ComponentModel) et de règles de trans-formation entre les composants des plates-formes sources et cibles (Pattern, Match). Il aété implanté sous la forme d’une extension lourde d’UML (PML -UML , dans la version 1.4d’UML ) 1 et intégré dans GME. PML -UML permet, entre autre, de modéliser les ressourceset les signatures des services qu’offre la plate-forme ainsi que leurs contraintes d’utilisation.

Dans cette approche, la modélisation des plates-formes d’exécution peut être impliciteou explicite. Pour cela, des transformations de modèles, en GReaT (Graph Rewriting andTransformation) [54], sont disponibles pour passer d’un métamodèle à un modèle conformeà PML . L’outillage associé à PML , et intégré dans GME, offre également la génération auto-matique d’une partie des règles de portage d’une application d’une plate-forme à une autre.

Le mécanisme de génération automatique s’appuie cependant sur une approche de mo-délisation dans laquelle les considérations ne sont pas clairement séparées. La descriptiondes règles de transformation se confond avec les descriptions des ressources et des servicesdes plates-formes d’exécution.

TUT-Profile (Tampere University of Technology -UML Profile) [63] est un profil UML

(dans la version 2.0 d’UML ) initialement prévu pour la modélisation d’applications tempsréel embarquées et de plates-formes d’exécution matérielles. Ce Profil aété étendu parl’introduction de concepts liés aux plates-formes d’exécution logicielle [4].Ces conceptsconcernent les packages dédiés à la description de plates-formes logicielles (SwPlatformLi-brary), les composants de plates-formes logicielles (SwPlatformComponent) et les élémentstypés par ces composants (SwPlatformProcess).

Cette approche permet, dans une modélisation UML , d’identifier explicitement les pa-ckages et les entités décrivant la plate-forme d’exécution, mais aucun concept n’est dédiéau domaine du temps réel et de l’embarqué dans ce profil.

Le profil U ML -M ARTE (UML profile for Modeling and Analysis of Real Time andEnbedded systems) [89], standardisé par l’OMG, est dédié à la modélisation et à l’ana-lyse de systèmes embarqués temps réel. UML -MARTE concerne les applications logicielles,les supports d’exécution (matériels et logiciels) et les propriétés fonctionnelles et non-fonctionnelles des systèmes.

Le package SRM (Software Resource Modeling) propose en particulier des artefactsde modélisation des plates-formes d’exécution logicielles pour le domaine du temps réelet de l’embarqué. Pour cela, SRM spécialise pour son domaine d’application les concepts

1L’utilisation d’une extension lourde d’UML pourrait s’apparenter à une approche DSML, en opposition àl’approche par profil UML .

194 Annexe C. Technologies de modélisation explicite des plates-formes d’exécution

généraux de ressources et de services du package GRM (Generic Resource Modeling) déjàprésents dans le profil SPT (Schedulability, Performance and Time) [85] que MARTE sedestine à remplacer.

Les ressources identifiées par SRM concernent trois familles de concepts :

1. Les ressources concurrentes, qui offrent des contextes d’exécution concurrents (parexemple les tâches et les interruptions) ;

2. Les ressources d’interaction, qui proposent des mécanismes de communication etde synchronisation (par exemple les sémaphores, les évènements ou les boîtes auxlettres) ;

3. Les ressources de gestion, qui fournissent des services pour lagestion d’autres res-sources (par exemple les ordonnanceurs et les pilotes).

Le profil UML -MARTE permet, au travers du package SRM, d’identifier finement lesaspects métiers de modèles de plates-formes d’exécution logicielles embarquées temps réel.Les expérimentations de ce profil ont mis en évidence une couverture efficace des ressourceset des services mis à disposition par les exécutifs du domaine présents sur lemarché (telsque ARINC-653, OSEK/VDX-OS ou RTLinux) [114].

C.0.2 Approche DSML

AADL (Architecture Analysis & Design Language) [103] est un langage de descrip-tion d’architecture (ou ADL, Architecture Description Language) standardisé par la SAE

(Society of Automotive Engineer) pour le domaine des systèmes temps réel embarqués cri-tiques. Le métamodèle d’AADL définit l’ensemble des composants et des connecteurs deson domaine d’application. Les composants sont partitionnés entre composants logiciels(data, subprogram, thread, process), matériels (device, bus, memory, processor) et compo-sites (system). Dans une description complète d’un système en AADL , les différents com-posants logiciels sont liés aux composants matériels offrant les ressources nécessaires àleur exécution. À partir d’une telle description, il est possible d’instancierle modèle, puisd’invoquer des outils d’analyse (fiabilité, ordonnançabilité, etc.) et de génération de code.

Cette approche s’oriente vers une modélisation explicite de l’application logicielleet dusupport d’exécution matériel. Bien que le standard n’adresse pas la description d’un supportd’exécution logiciel, des composants logiciels spécifiques aux plates-formes pourraient êtredécrits et mis en relation avec les composants de l’application, via les mécanismesd’héri-tage ou d’implémentation que propose le langage. Cette façon de procéder est néanmoinslimitée, d’une part, par l’impossibilité de spécialiser les connecteurs pour desplates-formesd’exécution données et, d’autres part, par la sémantique d’exécution associée à chaque com-posant logiciel dans le standard (par exemple, pour lesthreads). Le support d’exécution,ainsi figé par ce que spécifie le standard, fait office de plate-forme d’exécution abstraite.AADL ne se prétend donc pas être un langage de description de plate-forme d’exécutionlogicielle.

THINK (THink Is Not a Kernel) [42] est une implantation d’un modèle de compo-sants de typeFractal [39] pour le développement de systèmes d’exploitation embarqués.THINK se compose d’outils de gestion de composants et d’une bibliothèque de composants(KORTEX) qui implante une abstraction des couches matérielles et les principaux servicesd’un système d’exploitation embarqué.

Au travers de KORTEX, THINK permet de concevoir des plates-formes d’exécution em-barquée par assemblage de composants. THINK montre ainsi la capacité de Fractal à décrire

195

des plates-formes d’exécution. Néanmoins, le métamodèle de Fractal définitdes conceptsde haut niveau d’abstraction pour modéliser des composants et leurs interfaces. Il n’iden-tifie pas de notions métiers (pour le domaine du temps réel et de l’embarqué), et THINK

n’enrichit pas Fractal de ces notions. Les composants de KORTEX sont simplement prédé-finis, décrits conformément aux concepts de Fractal et implantés en langage C. THINK sedestine donc essentiellement à la réalisation flexible de systèmes d’exploitation et non pasà la description de plates-formes d’exécution existantes.

Metropolis [94] est une méthodologie de conception basée sur les modèles de plates-formes (ouPlatform Based Design[97]). Le métamodèle de Metropolis (Metropolis MetaModel [75]) définit des concepts d’un haut niveau d’abstraction pour la modélisation desystèmes hétérogènes. Cette modélisation se fonde sur les notions d’activités concurrentes(Process) et de communication entre les activités (Media) pour décrire des plates-formesd’exécution (matérielles et logicielles) et les applications qui s’y destinent. Le déploiementd’une application sur une plate-forme se concrétise par des relations entre leurs composants(Mapping).

L’outil de modélisation Metropolis intègre, en complément, des langages formels, telsque LTL (Linear Temporal Logic) ou LOC (Logic Of Constraints), pour la vérification depropriétés fonctionnelles et non-fonctionnelles des systèmes modélisés.

La modélisation des systèmes embarqués temps réel est encouragée par l’utilisationconjointe de langages de modélisation et de langages de logique temporelle. Cetteapprocheoffre, de plus, les artefacts nécessaires à la modélisation explicite de plates-formes d’exé-cution logicielles de tous domaines. Néanmoins, la généricité du métamodèle de cetteap-proche ne facilite pas la description de plates-formes dédiées à un domaine métier particu-lier [26]. Le haut niveau d’abstraction de ses concepts n’identifie, par exemple, aucun aspectmétier du domaine du temps réel et de l’embarqué.

Le projet CoSMIC (Component Synthesis using Model Integrated Computing) [50]développe une chaîne d’outils de modélisation et d’analyse de systèmes embarqués tempsréel distribués. La modélisation des supports d’exécutions visés s’articule autour de com-posants basés sur le standard CCM (CORBA Component Model) [87] et spécialisés pour lesdomaines de l’embarqué, du temps réel et de la qualité de service (QoS).

Cette approche permet donc de décrire les concepts des intergiciels développés dansle respect du standard CORBA. Elle se prête ainsi à la modélisation explicite de certainesplates-formes d’exécution, mais ne permet pas de modéliser les ressources et les servicesde systèmes d’exploitation.

Le projet Ptolemy propose au travers de son atelier (Ptolemy II [69]) un ensembled’outils de modélisation et de simulation de systèmes embarqués temps réel, hétérogènes etconcurrents. Les métamodèles disponibles dans Ptolemy, en lien avec le support d’exécutiondes systèmes, se focalisent sur la description de modèles d’exécution (lesreprésentationdes lois qui gouvernent les interactions entre les composants d’un système). La plupart deces modèles supportent la conception orientée acteur (actor-oriented design) axée sur laconcurrence et la communication entre les composants.

Ptolemy concentre la considération du support d’exécution dans les modèles d’exécu-tion. Il offre pour cela un large support de modélisation des sémantiques d’exécution [70].Néanmoins, les concepts de représentation structurelle, issus d’une approche orientée ac-teur, se destinent uniquement à la modélisation des applications.

196 Annexe C. Technologies de modélisation explicite des plates-formes d’exécution

C.0.3 Synthèse

Le tableau C.1, de la présente page, présente une évaluation synthétique de chacunedes technologies évoquées. Cette évaluation porte sur leur capacité d’utilisation dans le do-maine du temps réel et de l’embarqué au travers, notamment, du nombre et de laprécisiondes concepts qu’offrent ces technologies pour ce domaine. Les résultats affichés sont prin-cipalement issus d’une analyse faite lors de travaux précédents cette étude [114].

Les composantes du système que visent les technologies sont également mentionnées.Ces composantes concernent l’application et les plates-formes d’exécution logicielles etmatérielles. L’utilisation envisagée de chacune des technologies est finalement abordée.

Approches DSML Approches UML

AADL THINK Metropolis CoSMIC Ptolemy PML TUT MARTE

Dom

aine Emb.T.R ++ ++ + ++ ++ − + ++

Concepts ++ + − +(1) + − − + + +

Mod

élis

atio

n

P.mat. ✓ ✓ ✓ ✓ ✓

P.log. ✓ ✓ ✓(1) ✓(2) ✓ ✓ ✓

Appl. ✓ ✓ ✓ ✓ ✓ ✓ ✓

Util

isat

ion

(pré

vue)

Conçoit ✓(3) ✓(4) ✓(3) ✓(3) ✓(3) ✓ ✓ ✓

Analyse ✓ ✓ ✓ ✓ ✓ ✓ ✓

Simule ✓ ✓ ✓ ✓

Déploie ✓(5) ✓ ✓(6) ✓(7) ✓ ✓ ✓

(1) Ne concerne que les intergiciels conformes à CORBA.(2) Restreint aux modèles d’exécution, pas de modélisation explicite de la structure.(3) Conception de l’application uniquement.(4) Conception de la plate-forme d’exécution.(5) Déploiement sur une plate-forme matérielle.(6) Déploiement par construction.(7) Utilisation d’un représentation implicite de la plate-forme d’exécution.

Emb.T.R: peu adapté (−), conseillé (+) ou conçu (++) pour le temps réel embarqué ;Concepts: génériques (−), adaptés (+) ou spécialisés (++, + + +) pour le domaine ;Modélisation: Plate-forme matérielle (P.mat.), logicielle (P.log.), application (Appl.) ;

TAB . C.1:Technologies de modélisation explicite des plates-formes d’exécution.

Parmi les DSML, le langage AADL offre un ensemble assez complet de concepts dudomaine. Ce langage se focalise toutefois sur la description des supports matérielles et desapplications. Bien que les concepts relatifs aux applications soient étroitement liés avec ceuxdes plates-formes logicielles, les artefacts de modélisation proposés par AADL limitent ladescription de ces plates-formes.

Parmi les technologies évaluées, DSML et UML confondus, le profil UML -MARTE offreactuellement l’ensemble le plus complet de concepts métiers pour modéliser des plate-formes d’exécution temps réel embarquées. La conception de ce profil ade plus été conduitesur la base d’un modèle de domaine qui spécifie ces concepts. Le profil UML -MARTE est

197

une implantation de ce modèle de domaine. Une implantation alternative dans un DSML estégalement envisageable. Le langage RTEPML présenté dans ce rapport est par exemple uneimplantation, dans un DSML, dupackageSRM d’UML -MARTE.

Abréviations

AADL Architecture Analysis & Design Language

ADL Architecture Description Language

AMMA ATLAS Model Management Architecture

API Application Programming Interface

ARINC Aeronautical Radio Incorporated

ASIC Application Specific Integrated Circuit

ATL ATLAS Transformation Language

ATLAS Atlantic Data Systems

AUTOSAR AUTomotive Open System ARchitecture

AWK Aho, Kernighan et Weinberger

CAD Computer Aided Design

CASE Computer Aided Software Engineering

CCM CORBA Component Model

CORBA Common Object Request Broker Architecture

CoSMIC Component Synthesis using Model Integrated Computing

DSML Domain Specific Modeling Language

DTD Document Type Definition

EMF Eclipse Modeling Framework

EMP Eclipse Modeling Project

FPGA Field Programmable Gate Array

GEF Graphical Editing Framework

GME Generic Modeling Environment

GMF Graphical Modeling. Framework

GPML Generic Purpose Modeling Language

GReaT Graph Rewriting and Transformation

GRM Generic Resource Modeling

HRM Hardware Resource Modeling

200 Abréviations

IDM Ingénierie Dirigée par les Modèles

KM3 Kernel Meta Meta Model

L INA Laboratoire d’Informatique de Nantes Atlantique

LOC Logic Of Constraints

LTL Linear Temporal Logic

MARS Maintainable Real-Time System

MARTE UML profile for Modeling and Analysis of Real Time and Embedded systems

MDA Model Driven Architecture

MDE Model Driven Engineering

M IC Model-Integrated Computing

MOF Meta Object Facility

NFP Non Functional Property

OASIS Objects Actifs Synchrones Isochrones pour la Sûreté

OCL Object Contraint Language

OIL OSEK/VDX Implementation Language

OMG Object Management Group

OSATE Open Source AADL Tool Environment

OSEK Offene Systeme und deren schnittstellen für die Elektronik im Kraftfahrzeug

PCP Priority Ceiling Protocol

PDM Platform Description Model

PIM Platform Independant Model

PIP Priority Inheritance Protocol

PML Platform Modeling Language

POSIX Portable Operating System Interface

PSM Platform Specific Model

QoS Quality of Service

QVT Query View Transformation

RTES Real-time Embedded System

RTLinux Real-Time Linux

RTW Real-Time Workshop

SAE Society of Automotive Engineer

SPT Schedulability, Performance and Time

SQL Structured Query Language

Abréviations 201

SRM Software Resource Modeling

TCS Textual Concrete Syntax

THINK THink Is Not a Kernel

TOPCASED The Open-Source Toolkit for Critical Systems

TUT-Profile Tampere University of Technology - UML Profile

UML Unified Modeling Language

VDX Vehicle Distributed eXecutive

XMI XML Metadata Interchange

XML eXtensible Markup Language

XSLT eXtensible Stylesheet Language Transformations

Table des figures

1.1 Principe de mise en œuvre d’une transformation de modèle dans l’IDM. . . . . . . . . . 101.2 Considération progressive des plates-formes dans le MDA. . . . . . . . . . . . . . . . 12

2.1 Un profil UML d’applications spécifiques à la plate-forme OSEK/VDX. . . . . . . . . . 192.2 Description UML d’une application spécifique à la plate-forme OSEK/VDX. . . . . . . . 202.3 Un métamodèle d’applications spécifiques à la plate-forme OSEK/VDX. . . . . . . . . . 202.4 Description avec un DSML d’une application spécifique à la plate-forme OSEK/VDX. . . . 212.5 Un profil UML de description de plates-formes d’exécution.. . . . . . . . . . . . . . 212.6 Description explicite d’une plate-forme OSEK/VDX avec un profil UML . . . . . . . . . . 222.7 Un DSML de description de plates-formes d’exécution.. . . . . . . . . . . . . . . . 232.8 Description explicite d’une plate-forme OSEK/VDX avec un DSML. . . . . . . . . . . . 232.9 Trois approches de déploiement d’une application sur une plate-forme. . . . . . . . . . 242.10 Plate-forme enfouie dans une transformation.. . . . . . . . . . . . . . . . . . . . . 252.11 Déploiement d’une application sur une plate-forme OSEK/VDX (UML ). . . . . . . . . . 262.12 Plate-forme implicitement décrite dans un métamodèle de langage de programmation. . . . 272.13 Déploiement d’une application sur une plate-forme OSEK/VDX implicitement décrite.. . . 272.14 Introduction d’un métamodèle pivot de plate-forme d’exécution.. . . . . . . . . . . . 292.15 Extrait d’un métamodèle pivot.. . . . . . . . . . . . . . . . . . . . . . . . . . . 302.16 Déploiement d’une application sur une plate-forme OSEK/VDX via un pivot. . . . . . . . 302.17 Quatre approches de déploiement d’une application sur une plate-forme explicitement décrite.312.18 Déploiement d’une application sur une plate-forme OSEK/VDX décrite avec un profil UML . 322.19 Principe d’une transformation de déploiement sur une plate-forme décrite avec un profil UML . 332.20 Un DSML de description de système (application + plates-formes d’exécution).. . . . . . 352.21 Promotion d’un modèle de la plate-forme OSEK/VDX en un métamodèle d’application.. . 362.22 Principe d’une génération de transformation de portage.. . . . . . . . . . . . . . . . 372.23 Génération d’un modèle de code spécifique à une plate-forme OSEK/VDX décrite avec un DSML. 392.24 Un DSML de description de plate-forme pouvant intégrer des applications.. . . . . . . . 402.25 Déploiement d’une application sur une plate-forme OSEK/VDX décrite avec un DSML. . . 41

3.1 Extrait du motif ressource/service du profil UML -MARTE [89]. . . . . . . . . . . . . . 593.2 Extrait du modèle de domaine de SRM : les ressources logicielles [89].. . . . . . . . . 593.3 Extrait du modèle de domaine de SRM : les ressources d’exécution concurrentes [89].. . . 603.4 Extrait du modèle de domaine de SRM : les partitions mémoires [89].. . . . . . . . . . 613.5 Extrait du modèle de domaine de SRM : les ressources d’interaction [89].. . . . . . . . 613.6 Extrait du modèle de domaine de SRM : les ressources de synchronisation [89].. . . . . . 623.7 Extrait du modèle de domaine de SRM : les ressources de communication [89].. . . . . . 623.8 Extrait du modèle de domaine de SRM : les interactions des ressources concurrentes [89].. 623.9 Extrait du DSML RTEPML : fondation de la modélisation des ressources et des services.. . 633.10 Extrait du DSML RTEPML : les éléments nommés.. . . . . . . . . . . . . . . . . . 633.11 Extrait du DSML RTEPML : hiérarchie des ressources.. . . . . . . . . . . . . . . . . 643.12 Extrait du DSML RTEPML : affectation des rôles.. . . . . . . . . . . . . . . . . . . 643.13 Extrait du DSML RTEPML : les éléments typés.. . . . . . . . . . . . . . . . . . . . 64

204 Table des figures

3.14 Extrait du DSML RTEPML : les types de données.. . . . . . . . . . . . . . . . . . . 653.15 Extrait du DSML RTEPML : les instances de ressources prédéfinies dans une plate-forme.. 653.16 Extrait du DSML RTEPML : les instances de ressources et leurs propriétés.. . . . . . . . 663.17 Extrait du DSML RTEPML : les instances de ressources et les appels de services.. . . . . 663.18 Extrait du DSML RTEPML : les routines et les points d’entrée.. . . . . . . . . . . . . 673.19 Extrait du DSML RTEPML : l’héritage de ressource.. . . . . . . . . . . . . . . . . . 683.20 Extrait du DSML RTEPML : la composition de services.. . . . . . . . . . . . . . . . 693.21 Extrait du DSML RTEPML : les prototypes de conception.. . . . . . . . . . . . . . . 703.22 Extrait du DSML RTEPML : exemple de distribution des rôles dans un prototype de conception.71

4.1 Approche proposée pour le déploiement d’une application sur une plate-forme d’exécution. 794.2 Extrait du DSML RTEPML : intégration d’une application sur la plate-forme.. . . . . . . 794.3 Déploiement d’une application de robotique sur une plate-forme OSEK/VDX. . . . . . . 804.4 Principe de déploiement d’une application via RTEPML. . . . . . . . . . . . . . . . . 844.5 Relations identifiées entre les concepts applicatif et exécutif.. . . . . . . . . . . . . . 874.6 Mise à disposition, par une plate-forme, de ressources conformes à des concepts de RTEPML. 904.7 Mise à disposition, par une plate-forme, de ressources avec ou sans prototype de conception. 934.8 Déploiement d’une application de robotique sur une plate-forme OSEK/VDX (prototype). . 974.9 Déploiement d’une application de robotique sur une plate-forme OSEK/VDX (propriétés). . 1054.10 Déploiement d’une application de robotique sur une plate-forme OSEK/VDX (avec services).1094.11 Composition d’une transformation de déploiement basée sur RTEPML. . . . . . . . . . . 1104.12 Organisation d’une transformation de déploiement basée sur RTEPML. . . . . . . . . . . 1124.13 Exemple de métamodèle de déploiement (simple). . . . . . . . . . . . . . . . . . . 1144.14 Exemple de métamodèle de déploiement (simple, avec trace). . . . . . . . . . . . . . 1164.15 Organisation d’une transformation de déploiement basée sur RTEPML (génération de règles).1164.16 Choix de déploiementconceptuelsetpratiques. . . . . . . . . . . . . . . . . . . . . 1184.17 Exemple de métamodèle de déploiement (simple, avec décisions). . . . . . . . . . . . 1214.18 Organisation d’une transformation de déploiement basée sur RTEPML (choix de déploiement).1234.19 Organisation d’un processus de déploiement d’application basé sur RTEPML. . . . . . . . 127

5.1 Processus de déploiement sur une plate-forme d’exécution : expérimentations. . . . . . . 1315.2 Éditeurs développés et intégrés à l’atelier TOPCASEDpour mener les expérimentations.. . 1325.3 Processus de déploiements d’applications sur des plates-formes d’exécution. . . . . . . . 133

Liste des tableaux

2.1 Approches de déploiement (génération d’un modèle de code de l’application déployée). . . 432.2 Approches de déploiement sur des plates-formes implicitement décrites. . . . . . . . . . 462.3 Approches de déploiement sur des plates-formes explicitement décrites. . . . . . . . . . 48

4.1 Règles et fonctions mises à contribution dans l’algorithme de déploiement.. . . . . . . . 1114.2 Règles et fonctions mises à contribution dans une transformation de déploiement. . . . . . 125

5.1 Développement des métamodèles et des modèles.. . . . . . . . . . . . . . . . . . . 1365.2 Développement des fonctions d’accès aux informations des modèles.. . . . . . . . . . 1375.3 Développement des composantes de transformations.. . . . . . . . . . . . . . . . . 139

C.1 Technologies de modélisation explicite des plates-formes d’exécution.. . . . . . . . . . 196

Liste des Algorithmes

2.1 Principe d’un portage générique (basé sur le profilage UML ) [115] . . . . . . 342.2 Principe d’une génération de transformation de portage . . . . . . . . . .. . 374.1 Principe d’une transformation de déploiement . . . . . . . . . . . . . . . . . 814.2 Règle de correspondance (ruleConcept2ResourceInstance) . . . . . . . . . . 824.3 Localisation d’une ressource (getResource) . . . . . . . . . . . . . . . . . . 834.4 Localisation d’une propriété dans la plate-forme (getProperty) . . . . . . . . 834.5 Principe d’une transformation de déploiement(➤concept/critère) . . . . . . . . 864.6 Règle de correspondance (ruleConcept2ResourceInstance) (➤concept/critère) . 864.7 Localisation d’une ressource (getResource) (➤concept/critère) . . . . . . . . . 864.8 Principe d’une transformation de déploiement(➤relations 1-0) . . . . . . . . . 884.9 Règle de correspondance (ruleConcept2MultiResourceInstances) . . . . . . 894.10 Principe d’une transformation de déploiement(➤disponibilité) . . . . . . . . . 924.11 Règle de correspondance (ruleConcept2MultiResourceInstances) (➤disponibilité) 924.12 Règle de correspondance (ruleConcept2MultiResourceInstances) (➤prototypes) 944.13 Règle d’application d’un prototype (ruleClonePrototype) . . . . . . . . . . . 944.14 Génération d’une instance (ruleCreateResourceInstanceFromPrototype) . . . 954.15 Génération des associations (ruleCreateAssociationFromPrototype) . . . . . 964.16 Sans prototype (ruleConcept2ResourceInstance) (➤propriétés) . . . . . . . . . 994.17 Avec prototype (ruleCreateResourceInstanceFromPrototype) (➤propriétés) . . 1004.18 Règle d’application d’un prototype (ruleClonePrototype) (➤propriétés) . . . . 1014.19 Génération des propriétés (ruleCreatePropertiesFromPrototype) . . . . . . . 1024.20 Renseignement des propriétés (avec ou sans prototype)(➤référence). . . . . . 1044.21 Sans prototype (ruleConcept2ResourceInstance) (➤services). . . . . . . . . . 1074.22 Exemple d’une déclaration d’appels de services (getCallServices) . . . . . . 109

Listings

2.1 Extrait de la transformation ROBOT2OSEK/VDX (en ATL) . . . . . . . . . . . . . . . 282.2 Extrait de la transformation de promotionPlatform2Meta(en ATL) . . . . . . . . . . . 362.3 Extrait de la transformationRobot & PDM to C(en ATL) . . . . . . . . . . . . . . . 392.4 Extrait de la transformation ROBOT2PLATFORM (en ATL) . . . . . . . . . . . . . . . 413.1 Description de la plate-formeNXTOSEK avec RTEPML (extrait) . . . . . . . . . . . . . 734.1 Transformation de déploiement Robot2RTEPML (cas simple, en ATL) . . . . . . . . . . 804.2 Exemple de modèle de déploiement. . . . . . . . . . . . . . . . . . . . . . . . . 1154.3 Exemple de modèle de déploiement (Robot vers RTEPML) . . . . . . . . . . . . . . . 1224.4 Exemple de modèle de décision (Robot vers OSEK/VDX) . . . . . . . . . . . . . . . 122A.1 Métamodèle du langage RTEPML (en KM3 [56]) . . . . . . . . . . . . . . . . . . . 153B.1 Extrait de la transformationPlatform2Meta(en ATL) . . . . . . . . . . . . . . . . . 163B.2 getResource: localisation d’une ressource (version simple, en ATL) . . . . . . . . . . . 164B.3 getResource: localisation d’une ressource (avec critères, en ATL) . . . . . . . . . . . . 165B.4 getProperty: localisation d’une propriété (version simple, multi-helpers, en ATL) . . . . . 166B.5 getProperty: localisation d’une propriété (version simple, générique, en ATL) . . . . . . 167B.6 XConcept2XResourceInstance: exemple générique (avec critères, en ATL) . . . . . . . 168B.7 XConcept2XResourceInstance: exemple générique (disponibilité 0/1 (a), en ATL) . . . . 169B.8 XConcept2XResourceInstance: exemple générique (disponibilité 0/1 (b), en ATL) . . . . 170B.9 XConcept2XResourceInstance: exemple générique (prototypes de conception, en ATL) . . 172B.10 ClonePrototype: appliquer un prototype de conception (en ATL) . . . . . . . . . . . . 173B.11 CreateResourceInstanceFromPrototype: générer une instance à partir d’un prototype (en ATL)174B.12 CreateAssociationFromPrototype: générer les associations (en ATL) . . . . . . . . . . 176B.13 SetOfInstances: une structure de mémorisation d’instances de ressources (en ATL) . . . . 177B.14 CreateResourceInstance: règle générique (gestion des propriétés, en ATL) . . . . . . . . 179B.15 CreateResourceInstanceProperty: création d’une propriété (en ATL) . . . . . . . . . . 180B.16 CompletePropertyReferences: résolution des références pour les propriétés (en ATL) . . . 182B.17 CreateResourceInstance: règle générique (génération d’appels de service, en ATL) . . . . 183B.18 CreateCallService: création d’un appel de service (en ATL) . . . . . . . . . . . . . . 185B.19 Templatede génération d’une règle ATL de déploiement (version simple). . . . . . . . 186B.20 Templatede génération d’une règle ATL de déploiement (décisions). . . . . . . . . . . 188B.21 Templatede génération d’une transformation ATL de déploiement . . . . . . . . . . . 189

Bibliographie

[1] Alfred V. Aho, Brian W. Kernighan, and Peter Weinberger.TheAWK programminglanguage. Addison-Wesley, 1988.

[2] Airlines Electronic Engineering Committee.Avionics Application Software StandardInterface, ARINC Specification 653-1, October 2003. Aeronautical radio INC., An-napolis, Maryland, USA.

[3] Joäo Paulo Andrade Almeida.Model-Driven Design of Distributed Applications.Computer science, Telematica Instituut Fundamental Research Series, Enschede, TheNetherlands„ 2006.

[4] Tero Arpinen, Mikko Setälä, Erno Salminen, Marko Hännikäinen, andTimo D.Hämäläinen. Modeling embedded software platform with a UML profile. In Fo-rum on specification and Design Languages, FDL’07, Barcelona, Spain, September2007.

[5] Colin Atkinson and Thomas Kühne. A generalized notion of platforms formodel-driven development. pages 119–136. 2005.

[6] ATLAS group. ATL : ATLAS Transformation Language,ATL User Manual, version0.7. LINA & INRIA, Nantes, France, February 2006.

[7] AUTomotive Open Source ARchitecture. AUTOSAR, release 3.1, 2008.http ://www.autosar.org.

[8] AUTomotive Open Source ARchitecture. AUTOSAR, Specification of Operating Sys-tem, v3.1.1, February 2009. http ://www.autosar.org/.

[9] Jean-Philippe Babau.Formalisation et structuration des architectures opération-nelles pour les systèmes embarqués temps réel. Thèse d’Habilitation à Diriger lesRecherches, Institut National des Sciences Appliquées de Lyon, université ClaudeBernard de Lyon - Lyon 1, Décembre 2005.

[10] Abdessamad Belangour, Jean Bézivin, and Mounia Fredj. The design decision as-sistant tool : A contribution to the MDA approach. InActes des 1ère Journées surl’Ingénierie Dirirgée par les Modèles, IDM05, Paris, France, juin 2005.

[11] Jean Bézivin. La transformation de modèles. InÉcole d’Été d’Informatique CEAEDF INRIA cours numéro 6, Juin 2003.

[12] Jean Bézivin, Mireille Blay, Mokrane Bouzhegoub, Jacky Estublier, Jean-MarieFavre, Sébastien Gérard, and Jean-Marc Jézéquel.Rapport de Synthèse de l’AS

CNRS sur leMDA. Novembre 2004.

[13] Jean Bézivin, Sébastion Gérard, Pierre-Alain Muller, and Laurent Rioux. MDA Com-ponents : Challenges and Opportunities. InMetamodelling for MDA, First Interna-tional Workshop, York, UK, November 2003.

[14] Jean Bézivin and Ivan Kurtev. Model-based technology integration with the techni-cal space concept. InIn Proceedings of the Metainformatics Symposium. Springer-Verlag, 2005.

212 Bibliographie

[15] Mireille Blay-Fornarino and Paul Franchi. Espace technologique langages et IDM.Technical report, Novembre 2004.

[16] A. W. Brown, D. J. Carney, E. J. Morris, D. B. Smith, and P. F. Zarrella. Principles ofCASE tool integration. Oxford University Press, Inc., New York, NY, USA, 1994.

[17] James Bruck and Kenn Hussey. Customizing UML : Wich technique is right for you ?Technical report, International Business Machines Corporation, 2007.

[18] Matthias Brun. Utilisation des techniques développées dans le cadre de l’ingénieriedirigée par les modèles pour la réalisation d’un outil de génération de code conformeOSEK/VDX á partir d’une description AADL , Septembre 2006. Rapport de Master.

[19] Matthias Brun, Jérôme Delatour, Yvon Trinquet, Frédérique Thomas, and SébastienGérard. Etude comparative pour la modélisation de plates-formes d’exécution, 2010.

[20] Ken Butts, Dave Bostic, Alongkrit Chutinan, Jeffrey Cook, Bill Milam,and YanxinWang. Usage scenarios for an automated model compiler. InEMSOFT ’01 : Pro-ceedings of the First International Workshop on Embedded Software, pages 66–79,London, UK, 2001. Springer-Verlag.

[21] Paul Caspi, Grégoire Hamon, and Marc Pouzet.Systèmes Temps-réel : Techniquesde Description et de Vérification – Théorie et Outils, volume 1, chapter Lucid Syn-chrone, un langage de programmation des systèmes réactifs, pages 217–260. Hermes,2006.

[22] Rong Chen, Marco Sgroi, Grant Martin, Luciano Lavagno, Alberto Sangiovanni-Vincentelli, and Jan Rabaey. UML and Platform-Based Design, volume UML forReal : Design of Embedded Real-Time Systems, chapter 5. Kluwer Academic Publi-shers, May 2003.

[23] William R. Cook, Walter Hill, and Peter S. Canning. Inheritance is not subtyping. InPOPL ’90 : Proceedings of the 17th ACM SIGPLAN-SIGACT symposium on Prin-ciples of programming languages, pages 125–135, New York, NY, USA, 1990. ACMPress.

[24] Francis Cottet and Anne-Marie Déplanche.Encylcopédie de l’informatique et dessystèmes d’information, chapter Ordonnancement temps réel et ordonnançabilitéd’une application, pages 740–760. Vuibert, 2006.

[25] K. Czarnecki and U.W. Eisenecker.Generative programming : methods, tools, andapplications. ACM Press/Addison-Wesley Publishing Co. New York, NY, USA,2000.

[26] Abhijit Davare, Douglas Densmore, Trevor Meyerowitz, Alessandro Pinto, AlbertoSangiovanni-Vincentelli, Guang Yang, Haibo Zeng, and Qi Zhu. A next-generationdesign framework for platform-based design. InConference on Using HardwareDesign and Verification Languages (DVCon), February 2007.

[27] Vincent. David, Christophe. Aussaguès, Stéphane. Louise, Philippe Hilsenkopf, Ber-trand. Ortolo, and Christophe. Hessler. The OASIS based qualified display system.In Lecture Notes in Computer Science, 17th International Conf. on Computer Sa-fety, Reliability and Security Fourth American Nuclear Society International TopicalMeeting on Nuclear Plant Instrumentation, Controls and Human-Machine InterfaceTechnologies (NPIC&HMIT 2004), Columbus, Ohio. September, 2004., September2004.

[28] James Davis. GME : the Generic Modeling Environment. InOOPSLA ’03 : Compa-nion of the 18th annual ACM SIGPLAN conference on Object-oriented programming,

Bibliographie 213

systems, languages, and applications, pages 82–83, New York, NY, USA, 2003.ACM.

[29] Julien DeAntoni. SAIA : un style architectural pour assurer l’indépendance vis-à-vis d’entrées/sorties soumises à des contraintes temporelles. PhD thesis, InstitutNational des Sciences Appliquées de Lyon, France, Octobre 2007.

[30] Julien DeAntoni and Jean-Philippe Babau. A mda-based approachfor real time em-bedded systems simulation. InDS-RT ’05 : Proceedings of the 9th IEEE Internatio-nal Symposium on Distributed Simulation and Real-Time Applications, pages 257–264, Washington, DC, USA, 2005. IEEE Computer Society.

[31] Jérôme Delatour.Contribution á la spécification des systèmes temps réel : l’approcheUML /PNO. PhD thesis, Université Paul Sabatier, Toulouse, France, Septembre 2003.

[32] Jérôme Delatour, Raphaël Marvie, and Guillaume Savaton. Workshop on MetamodelPattern, MP2006. In2èmes Journées sur l’Ingénierie Dirigée par les Modèles, Lille,Juin 2006.

[33] Jérôme Delatour, Frédéric Thomas, Guillaume Savaton, and SébastienFaucou. Mo-dèle de plate-forme pour l’embarqué : première expérimentation sur les noyauxtemps réel. InActes des 1ère Journées sur l’Ingénierie Dirirgée par les Modèles,IDM05, pages 209–216, Paris, France, juin 2005.

[34] M. Didonet Del Fabro, J. Bézivin, F. Jouault, E. Breton, and G.Gueltas. AMW : ageneric model weaver. InIn proceedings of 1ères Journées sur l’Ingénierie Dirigéepar les Modèles, pages 105–114, Paris, France, 2005.

[35] Eclipse. Eclipse Modeling Project. http ://www.eclipse.org/modeling/.

[36] Eclispe Modeling Framework. EMF Core. http ://www.eclipse.org/modeling/emf/.

[37] Sven Efftinge, Peter Friese, Arno Haase, Clemens Kadura, Bernd Kolb, Dieter Mo-roff, Karsten Thoms, and Markus Völter.openArchitectureWare User Guide, version4.2, September 2007. http ://www.openarchitectureware.org.

[38] Jean-Pierre Elloy.Le temps réel. Rapport établi par le Groupe de réflexion du CNRS-SPI, TSI 7(5), Hermes, 1988.

[39] Jean-Bernard Stefani Eric Bruneton, Thierry Coupaye. The Fractal Component Mo-del, version 2.0. Technical report, September 2003. http ://fractal.ow2.org/.

[40] Huscar D. Espinoza Ortiz.An Integrated Model-Driven Framwork for Specifying andAnalyzing Non-Functional Properties of Real-Time Systems. PhD thesis, Universitéd’Evry, Sarclay, France, Septembre 2007.

[41] Pierre Farail and Patrick Gaufillet. TOPCASED: un environnement de développementopen source pour les systèmes embarqués. InJournée de travailNEPTUNE, numéro2, Paris , France, pages 16–20. Génie logiciel, GL & IS, Meudon, France, Mai 2005.

[42] Jean-Philippe Fassino. THINK : vers une architecture de systèmes flexibles. PhDthesis, Ecole Nationale Supérieure des télécommunications, Paris, France,Décembre2001.

[43] Jean-Marie Favre. Towards a basic theory to model model drivenengineering. InInWorkshop on Software Model Engineering, WISME 2004, joint event with UML2004,Lisbon, Portugal, October 2004.

[44] Jean-Marie Favre and Jacky Estublier. Concepts et relations de base pour l’ingénieriedirigée par les modèles. Technical report, Novembre 2004.

[45] Pierre Ficheux.Linux Embarqué. édition Eyrolles, 2002.

214 Bibliographie

[46] Franck Fleurey.Langage et méthode pour une ingénierie des modèles fiable. PhDthesis, Université de Rennes 1, octobre 2006.

[47] L. Fuentes-Fernández and A. Vallecillo-Moreno. An introduction touml profiles.UPGRADE, European Journal for the Informatics Professional, 5(2) :5–13, April2004.

[48] Erich Gamma, Richard Helm, Ralf Johnson, and John Vlissides.Design patterns :Elements of reusable object-oriented software. Addison Wesley, Boston, MA, 1994.

[49] Sébastien Gérard and Jean-Philippe Babau.Model Driven Schedulability Analysis,chapter Model Driven Engineering for Distributed Real-Time Embedded Systems,pages 197–204. Hermes, 2005.

[50] A. Gokhale, B. Natarajan, D. C. Schmidt, A. Nechypurenko, J. Gray, N. Wang,S. Neema, T. Bapty, and J. Parsons. CoSMIC : An MDA generative tool for distributedreal-time and embdedded component middleware and applications. InIn Proceedingsof the OOPSLA 2002 Workshop on Generative Techniques in the Context of ModelDriven Architecture. ACM, 2002.

[51] J. Greenfield, K. Short, S. Cook, and S. Kent.Software Factories : Assembling Ap-plications with Patterns, Models, Frameworks, and Tools. Wiley & Sons, 2004.

[52] Cécile Hardebolle.Composition de modèles pour la modélisation multi-paradigmedu comportement des systèmes. PhD thesis, Université Paris-Sud XI, Paris, France,Novembre 2008.

[53] Institute for Software Integrated System (ISIS). GME : Generic Modeling Environ-ment, 2008. http ://www.isis.vanderbilt.edu/projects/gme/.

[54] Institute for Software Integrated Systems. Graph Rewriting and Transformation(GReaT). http ://www.isis.vanderbilt.edu/tools/GReaT.

[55] Frédéric Jouault.Contribution à l’étude des langages de transformation de modèles.PhD thesis, Université de Nantes, Nantes, France, 2006.

[56] Frédéric Jouault and Jean Bézivin.KM 3 : a DSL for Metamodel Specification. InPro-ceedings of 8th IFIP International Conference on Formal Methods for Open Object-Based Distributed Systems, LNCS 4037, pages 171–185, Bologna, Italy, 2006.

[57] Frédéric Jouault, Jean Bézivin, and Ivan Kurtev. TCS : a DSL for the specificationof textual concrete sysntaxes in model engineering. InIn GPCE’06 : Proceedings ofthe 5th international conference on Generative programming and component engi-neering, pages 249–254, New York, NY, USA, 2006. ACM.

[58] Anneke Kleppe, Jos Warmer, and Wim Bast.MDA Explained : The Model DrivenArchitecture–Practice and Promise. Addison-Wesley Professional, April 2003.

[59] Herman Kopetz.Real-Time Systems, Design Principles for Distributed EmbeddedApplications. Kluwer Academic Publishers, 1997.

[60] Hermann Kopetz. The complexity challenge in embedded system design.In 11thIEEE International Symposium on Object-Oriented Real-Time Distributed Compu-ting (ISORC 2008), pages 3–12, Orlando, Florida, USA, May 2008. IEEE ComputerSociety.

[61] Hermann Kopetz, Andreas Damm, Christian Koza, Marco Mulazzani, WolfgangSchwabl, Christoph Senft, and Ralph Zainlinger. Distributed fault-tolerantreal-timesystems : The MARS approach.IEEE Micro, 9(1) :25–40, 1989.

[62] Petri Kukkala, Marko Hännikäinen, and Timo D. Hämäläinen. Design and imple-mentation of a WLAN terminal using UML 2.0 based design flow. InSAMOS, pages404–413, 2005.

Bibliographie 215

[63] Petri Kukkala, Jouni Riihimâki, Marko Hännikäinen, Timo D.Hämäläinen,and KlausKronlöf. UML 2.0 profile for embedded system design. InDesign, Automation andTest in Europe (DATE’05), Vol.2, pages 710–715., Los Alamitos, CA, USA, March2005. IEEE Computer Society.

[64] I. Kurtev, J. Bézivin, and M. Aksit. Technological spaces : Aninitial appraisal. InInternational Conference on Cooperative Information Systems (CoopIS), DOA’2002Federated Conferences, Industrial Track, Irvine, USA, pages 1–6, October 2002.

[65] Laboratoire d’Informatique de Nantes Atlantique (LINA ). The AMMA Home Page.http ://atlanmod.emn.fr/.

[66] François Laburthe. CHOCO : implementing a cp kernel. InIn : Proceedings of TRICS2000, pages 71–85, Singapore, 2000.

[67] J.-C. Laprie, J. Arlat, J.-P. Blanquart, A. Costes, Y. Crouzet, Y.Deswarte, J.-C. Fabre,H. Guillermain, M. Kaaniche, K. Kanoun, C. Mazet, D. Powell, C. Rabejac,andP. Thevenodothers.Guide de la sûreté de fonctionnement. Cépaduès Editions, 1995.

[68] A. Ledeczi, M. Maroti, A. Bakay, G. Karsai, Garrett J., C. Thomason, G. Nordstrom,Sprinkle J., and P Volgyesi. The generic modeling environment. InIn Workshop onIntelligent Signal Processing, Budapest, Hungary, May 2001.

[69] Edward A. Lee. Overview of the Ptolemy project. Technical ReportUCB/ERLM03/25, EECS Department, University of California, Berkeley, July 2003.

[70] Edward A. Lee and Alberto Sangiovanni-Vincentelli. A framework for comparingmodels of computation.IEEE Transactions on Computer-Aided Design of IntegratedCircuits and Systems, 17 :1217–1229, 1998.

[71] C.-L. Liu and James W. Layland. Scheduling algorithms for multiprogramming in ahard-real-time environment.J. ACM, 20(1) :46–61, 1973.

[72] Frédérique Loiret.Tinap : Modèle et infrastructure d’exécution orienté composantpour applications multi-tâches á contraintes temps réel souples et embarquées. PhDthesis, Université des Sciences et Technologies de Lille, Lille, France, Mai 2008.

[73] Raphaël Marvie, Laurence Duchien, and Mireille Blay-Fornarino. Les plates-formesd’exécution et l’IDM, chapter 4, pages 71–86. Number ISBN : 2-7462-1213-7.Hermes, January 2006.

[74] MetaCase. MetaEdit+ metaCASE tool. http ://www.metacase.com.

[75] Metropolis Project Team. The Metropolis meta model, version 0.4. Technical report.UCB/ERL M04/38.

[76] Marvin L. Minsky. Semantics Information Processing, chapter Matter, Mind andModels, pages 227–270. MIT Press, 1968.

[77] S. L. Montgomery.AD/Cycle :IBM ’s Framework for Application Development andCase. Van Nostrand Reinhold, 1991.

[78] Pierre-Alain Muller, Frédéric Fondement, Franck Fleurey, MichelHassenforder,Rémi Schnekenburger, Sébastien Gérard, and Jean-Marc Jézéquel. Model-drivenanalysis and synthesis of textual concrete syntax.Software and Systems Modeling,7(4) :423–441, October 2008.

[79] Jonathan Musset, Etienne Juliot, and Stéphane Lacrampe.Acceleo 2.2 : guide utili-sateur, Avril 2008. Obeo, http ://www.acceleo.org.

[80] Sandeep Neema. Design space representation and management formodel-based em-bedded system synthesis, 2001.

216 Bibliographie

[81] Nicholas Nethercote, Peter J. Stuckey, Ralph Becket, Sebastian Brand, Gregory J.Duck, and Guido Tack. Minizinc : Towards a standard cp modelling language. InIn : Proc. of 13th International Conference on Principles and Practice of ConstraintProgramming, pages 529–543. Springer, 2007.

[82] nxtOSEK. NXTOSEK Operating System, version 2.10, May 2009. http ://lejos-osek.sourceforge.net/.

[83] Obeo.Acceleo Guide Utilisateur, version 2.6, 2009. http ://www.acceleo.org/.

[84] Object Management Group (OMG). Model Driven Architecture (MDA) Guide, ver-sion 1.0.1, March 2001. http ://www.omg.org/mda/.

[85] Object Management Group (OMG). Response to theOMG RFP for Schedulability,Performance and Time, June 2001. OMG Document ad/2001-06-14.

[86] Object Management Group (OMG). Meta Object Facility (MOF) Core Specification,version 2.0, January 2006. http ://www.omg.org/mof/.

[87] Object Management Group (OMG). CORBA Component Model, version 4.0,April 2006. http ://www.omg.org/technology/documents/formal/components.htm,formal/2006-04-01.

[88] Object Management Group (OMG). MOF 2.0 XMI Mapping Specification, version2.1.1, December 2007. http ://www.omg.org/technology/documents/formal/xmi.htm.

[89] Object Management Group (OMG). UML Profile for Modeling and Analysis ofReal Time and Embbeded systems (MARTE), second revision submission, June 2007.http ://www.omg.org/marte/.

[90] Object Management Group (OMG). Unified Modeling Language (UML ) : Super-structure, version 2.1.2, November 2007. http ://www.omg.org/mda/.

[91] Object Management Group (OMG). Meta Object Facility (MOF)Query/View/Transformation Specification, version 1.0, April 2008.http ://www.omg.org/spec/QVT/1.0/.

[92] OSEK/VDX Group. OSEK/VDX System GenerationOIL : OSEK ImplementationLanguage, version 2.5, July 2004. http ://www.osek-vdx.org/.

[93] OSEK/VDX Group. OSEK/VDX Operating System Specification, version 2.2.3, Fe-bruary 2005. http ://www.osek-vdx.org/.

[94] A. Pinto. Metropolis design guidelines. Technical report, University of California,Berkeley, USA, November 2004.

[95] T. Quinot. Conception et réalisation d’un intergiciel schizophrène pour la mise enoeuvre de systèmes répartis interopérables. PhD thesis, Ecole Nationale Supérieuredes télécommunications, Paris, France, Mars 2003.

[96] Alberto Sangiovanni-Vincentelli, Luca Carloni, Fernando De Bernardinis, and MarcoSgroi. Benefits and challenges for platform-based design. InDAC ’04 : Proceedingsof the 41st annual conference on Design automation, pages 409–414. ACM Press,May 2004.

[97] Alberto Sangiovanni-Vincentelli and Grant Martin. Platform-based design and soft-ware design methodology for embedded systems.IEEE Des. Test, 18(6) :23–33,2001.

[98] Bran Selic. A generic framework for modeling resources with UML . Computer,33(6) :64–69, 2000.

Bibliographie 217

[99] Bran Selic. On software platforms, their modeling with UML 2, and platform-independent design. InISORC ’05 : Proceedings of the Eighth IEEE Internatio-nal Symposium on Object-Oriented Real-Time Distributed Computing (ISORC’05),pages 15–21, Washington, DC, USA, 2005. IEEE Computer Society.

[100] Françoise Simonot-Lion and Yvon Trinquet.Encylcopédie de l’informatique et dessystèmes d’information, chapter Exemple de systèmes temps réel et choix d’implé-mentation, pages 723–732. Vuibert, 2006.

[101] Frank Singhoff, Alain Plantec, Pierre Dissaux, and Jérôme Legrand. Investigating theusability of real-time scheduling theory with the cheddar project.Real-Time Syst.,43(3) :259–295, 2009.

[102] Smart-(QVT). Smart-(QVT) manual, 2007. http ://smartqvt.elibel.tm.fr.

[103] Society of Automotive Engineer (SAE). Architecture Analysis & Design Language(AADL ) AS5506, version 1.0, 2004.

[104] Software Engineering Institute (SEI). OSATE Open-SourceAADL Tool Environment,version 2.0, 2009. http ://www.aadl.info/aadl/currentsite/tool/osate.html.

[105] Peter J. Stuckey, Maria J. García de la Banda, Michael J. Maher, Kim Marriott,John K. Slaney, Zoltan Somogyi, Mark Wallace, and Toby Walsh. The g12 pro-ject : Mapping solver independent models to efficient solutions. InCP, pages 13–16,2005.

[106] Syntec Informatique, RNT Logiciel.Livre Blanc des premières Assises Françaisesdu Logiciel Embarqué. Number 6. Collection ThémaTIC, Mars 2007.

[107] Tivadar Szemethy.Domain-specific models, model analysis, model transformation.PhD thesis, Vanderbilt University, Nashville, Tennessee, USA, May 2006.

[108] Janos Sztipanovits and Gabor Karsai. Model-integrated computing.Computer,30(4) :110–111, 1997.

[109] S. Taha, A. Radermacher, S. Gérard, and J-L. Dekeyzer. An open framework forhardware detailed modeling. InIEEE proceedings SIES’2007, number 1-4244-0840-7, pages 118–125, Lisbon, Portugal, July 2007. IEEE.

[110] Andrew S. Tanenbaum.Structured Computer Organization, 5th edition. Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 2005.

[111] Andrew S. Tanenbaum.Modern Operating Systems, 3rd edition. Prentice Hall Press,Upper Saddle River, NJ, USA, 2007.

[112] The MathWorks.Real-Time Workshop User’s Guide. The MathWorks Inc., Natick,MA, USA, September 2007.

[113] The MathWorks.Using Simulink. The MathWorks Inc., Natick, MA, USA, Septem-ber 2007.

[114] Frédéric Thomas.Contribution à la prise en compte des plates-formes logiciellesd’exécution dans une ingénierie générative dirigée par les modéles. PhD thesis,Université d’Evry, Sarclay, France, Novembre 2008.

[115] Frédéric Thomas, Jérôme Delatour, François Terrier, Matthias Brun, and SébastienGérard. Contribution á la modélisation explicite des plates-formes d’exécutionpourl’I DM. L’Objet, 13(4) :9–32, 2007.

[116] Yvon Trinquet.Encylcopédie de l’informatique et des systèmes d’information, chap-ter Systèmes temps réel - Introduction, pages 719–722. Vuibert, 2006.

[117] Yvon Trinquet.Encylcopédie de l’informatique et des systèmes d’information, chap-ter Noyaux d’exécutif temps réel, pages 733–739. Vuibert, 2006.

218 Bibliographie

[118] Yvon Trinquet and Jean-Pierre Elloy. Systèmes d’exploitation tempsréel.Techniquesde l’ingénieur, Traité Contrôle et Mesures, Mars 1999.

[119] T. Vergnaud and B. Zalila. Ocarina, a compiler for the AADL . Technical report, Paris,France, 2006. http ://ocarina.enst.fr.

[120] Thomas Vergnaud.Modélisation des systèmes temps-réel répartis embarqués pourla génération automatique d’applications formellement vérifiées. PhD thesis, EcoleNationale Supérieure des télécommunications, Paris, France, Décembre 2006.

[121] Markus Völter and Thomas Stahl.Model-driven Software Devlopment : Technology,Engineering, Management. Wiley & Sons, June 2006.

[122] W3C. XSL Transformations (XSLT) Version 1.0, November 1999.

[123] Axel Wabenhorst and Brenton Atchison. A survey of international safety standards.Technical Report 99-30, Software Verification Research Centre, School of Informa-tion Technology, The University of Queensland, Brisbane 4072, Australia, November1999.

[124] WindRiver.VxWORKS Programmer’s Guide, 5.4. Edition 1, Mars 1999.

[125] Wayne Wolf and Jorgen Staunstrup.Hardware/Software CO-Design : Principles andPractice. Kluwer Academic Publishers, Norwell, MA, USA, 1997.

Contribution à la considération explicite des plates-formes d’exécution logicielleslors d’un processus de déploiement d’application

Résumé Les préoccupations inhérentes au domaine de l’embarqué et du temps réel,telleque la maîtrise du temps et des ressources impliquées, dépendent étroitementdu supportd’exécution. En outre, les besoins de réutilisation des applications sur différents supportsd’exécution orientent le développement logiciel vers des conceptions indépendantes de toutsupport d’exécution. Pour faciliter l’adaptation des applications à ces supports, l’ingénieriedirigée par les modèles (IDM) propose alors une approche qui vise à spécialiser successive-ment le modèle d’une application pour des technologies précises (identifiéessous le termede plate-forme), via des processus de transformations de modèles. Toutefois, peu de travauxont été menés pour préciser comment considérer les plates-formes durant ces processus.Dans un premier temps, les travaux de cette thèse comparent donc différents processus detransformation d’un modèle d’application indépendant du support d’exécution en un mo-dèle dépendant de ce support. Ce comparatif s’articule autour de la considération impliciteou explicite des plates-formes d’exécution de notre domaine d’intérêt (les systèmes d’ex-ploitation temps réel embarqués). Dans un second temps, cette thèse explore une voie danslaquelle la plate-forme d’exécution est explicitement modélisée. Pour cela, unlangage dédiéà la modélisation des systèmes d’exploitation temps réel embarqués est proposé. Puis, unprocessus de déploiement d’applications basé sur ce langage est présenté et évalué. L’ori-ginalité de ce processus réside dans son articulation autour de règles de transformationsgénériques ou générées, et d’un langage dédié au déploiement d’applications.

Mots-clés Plate-forme d’exécution, Temps réel, Ingénierie Dirigée par les Modèles(IDM), Transformation de modèles, Métamodèle de plate-forme, Modèle de plate-forme,UML -MARTE, Langage de modélisation dédié.

Contribution to the software execution platform integration during an applicationdeployment process

Abstract Real-time and embedded software concerns, such as time and resource usage,are closely related to the execution platform. But the need for reuse leads todesign platform-independent software. In order to ease platform integration of the application software,model-driven engeneering (MDE) aims at specializing application model using model trans-formations. But few works specify how to consider a platform within a transformation. Onthe one hand, this study compares several processes that transform aplatform-independentmodel of an application into a platform-dependent model. This comparative work focuseson implicit or explicit consideration of real-time and embedded operating systems. On theother hand, this study explores a modeling method where platforms are explicitlydescribed.A domain-specific modeling language (DSML) dedicated to the description of executionplatforms is proposed. Then an application deployment process based onthis language isintroduced and evaluated. The process uses generic or generated transformation rules and aDSML dedicated to the description of application deployment.

Keywords Execution platform, Real-Time, Model-Driven Engineering (MDE), Modeltransformation, Platform metamodel, Platform model, UML -MARTE, Domain-specific mo-deling language (DSML).

Documents

Contribution à la considération explicite des plates-formes d