2010NANT2077 Brun Matthias These

U NIVERSITÉ DE N ANTES
É COLE D OCTORALE STIM

« Sciences et Technologies de l’Information et de Mathématiques »
Année 2010
T HÈSE DE D OCTORAT DE L’U NIVERSITÉ DE N ANTES
Spécialité : AUTOMATIQUE ET I NFORMATIQUE A PPLIQUÉE
Présentée et soutenue publiquement par :
Matthias B RUN
le 18 octobre 2010
à l’École Centrale de Nantes
Contribution à la considération explicite

des plates-formes d’exécution logicielles
lors d’un processus de déploiement d’application
J URY :
Rapporteurs : Laurence D UCHIEN Professeur, Université Lille 1 - LIFL

Jean-Philippe BABAU Professeur, Université Bretagne Occidentale - LISyC
Examinateurs : Joël C HAMPEAU Enseignant Chercheur, ENSIETA - LISyC

Sébastien G ÉRARD Docteur Ingénieur, CEA Saclay - LISE
Yvon T RINQUET Professeur, Université de Nantes - IRCCyN
Jérôme D ELATOUR Enseignant Chercheur, Groupe ESEO - LRA
Directeur de thèse : Yvon T RINQUET

Laboratoire : Institut de Recherche en Communications et Cybernétique de Nantes
Co-encadrant : Jérôme D ELATOUR
Laboratoire : Laboratoire de Recherche Appliquée à l’ESEO
Composante 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é cette thèse. Jérôme
m’a donné l’opportunité d’effectuer un travail de recherche et a su créer un contexte idéal
pour ce travail. En plus de son soutien, de ses conseils et du savoir qu’il m’a transmis, je
tiens à 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 et
l’exemplarité de sa rigueur scientifique.
J’adresse mes remerciements à Laurence Duchien et à Jean-Philippe Babau qui m’ont
fait l’honneur d’évaluer mon travail de thèse et d’en être les rapporteurs. Je les remercie
pour leurs remarques toujours très constructives. Je remercie également Joël Champeau et
Sé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 de
compétitivité Aérospace Valley. J’adresse donc mes remerciements aux responsables de ce
projet pour leur soutien.
Ce travail de recherche a été effectué au Centre d’Étude et de Recherche du groupe
ESEO, en collaboration avec l’Institut de Recherche en Communications et Cybernétique
de 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 successifs
de l’IRCCyN, de m’avoir accueilli dans leurs laboratoires. Je remercie également Jacky
Charruault, 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 remerciements
s’adressent également aux membres du département AII et du département GRI de l’ESEO
avec lesquels j’ai eu la chance d’enseigner durant ces années de doctorat et avec lesquels je
suis ravi de continuer. Je remercie aussi plus largement l’ensemble des membres de l’ESEO
avec 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 et
tout 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 la convi-
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, connaissent
encore ou vont connaître les joies d’un doctorat. Je remercie également Christophe pour ses
contributions 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 3
1.1 Les systèmes embarqués temps réel . . . . . . . . . . . . . . . . . . . . . 5
1.2 L’ingénierie dirigée par les modèles . . . . . . . . . . . . . . . . . . . . . 8
1.3 Positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2 État de l’art 15
2.1 Les plates-formes d’exécution . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Les représentations des plates-formes d’exécution . . . . . . . . . . . . . . 18
2.3 Les déploiements sur des plates-formes d’exécution . . . . . . . . . . . . . 24
2.4 Comparaison des mises en œuvre . . . . . . . . . . . . . . . . . . . . . . . 42
2.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 57

3.1 Le modèle de domaine du package S RM d’U ML -M ARTE . . . . . . . . . . 59
3.2 Implantation du modèle de domaine dans un D SML . . . . . . . . . . . . . 63
3.3 Artefacts de modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.4 Exemple d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.5 Synthèse et résultats sur le langage proposé . . . . . . . . . . . . . . . . . 74
4 Un processus de déploiement sur une plate-forme explicitement décrite 77

4.1 Intégration d’applications sur une plate-forme . . . . . . . . . . . . . . . . 79
4.2 Principe d’un déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.3 Transformations de déploiement . . . . . . . . . . . . . . . . . . . . . . . 85
4.4 Développement d’une transformation de déploiement . . . . . . . . . . . . 110
4.5 Choix de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
4.6 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5 Évaluation 129
5.1 Expérimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
5.2 Critères de comparaison . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
5.3 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.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 nombreux
produits [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 de
nombreuses années, différentes couches d’abstractions logicielles ont été introduites (tels
que 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. Elles
constituent des plates-formes d’exécution logicielles pour les applications.
Mais aujourd’hui ces plates-formes tendent elles-aussi à évoluer et à se diversifier. Les
besoins de réutilisation et de capacité de portage des applications sur différents supports
d’exécution (motivés entre autres par la réduction des temps de développement) orientent
donc le développement logiciel vers des conceptions indépendantes de toute plate-forme
d’exécution. Cette séparation se retrouve de plus en plus dans les pratiques métiers et les
formalismes 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 support
d’exécution (support qui lui aussi a été normé, successivement O SEK /V DX -O S [93] et
AUTOSAR -O S [8]).
En outre, les préoccupations inhérentes aux systèmes embarqués temps réel (respect des
contraintes temporelles, limitation des ressources, etc.) dépendent étroitement du support
d’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’au
déploiement de l’application sur la plate-forme. Dans une vision idéale, une application
doit donc être conçue indépendamment de tout support d’exécution, tout en garantissant,
dès la phase de conception, son déploiement sur les supports envisagés (dans le respect de
ses 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 de
l’application, pour ne pas en dénaturer les représentations successives durant cette phase.
L’ingénierie dirigée par les modèles (I DM) [43], une discipline informatique émergente,
vise justement à faciliter la représentation et l’agencement des systèmes dans un cycle de
dé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 manipulation
et l’évolution de ces modèles.
viii Introduction
Problématiques et objectifs
Dans l’I DM, l’approche M DA (Model Driven Architecture) [84], initié par l’O MG (Ob-
ject Management Group), définit en particulier un cadre méthodologique pour différencier
les modèles indépendants des plates-formes (P IM, Platform Independant Model) de ceux
qui en dépendent (P SM, Platform Specific Model). Des transformations de modèles, plus ou
moins automatiques, spécialisent alors des P IM en P SM.
Cependant, le M DA ne précise pas comment renseigner les informations relatives aux
plates-formes dans ces transformations. La notion de description de plate-forme est évoquée
(P DM, Platform Description Model), mais aucune précision n’est donnée sur sa forme ou
sur sa prise en compte dans un processus de déploiement.
Dans de nombreux travaux, la notion de P DM se retrouve alors sous différentes formes.
Un P DM peut par exemple être décrit dans un modèle qu’il est envisageable de transmettre
comme paramètre à une transformation. Un P DM 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 description
d’application conforme à ce langage.
Nous constatons donc que chaque forme que prend un P DM influence la mise en œuvre
d’un déploiement. La répartition des connaissances relatives à l’application, à la plate-forme
et à 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 des
transformations impliqués dans un déploiement n’est donc pas le même. Mais, aucune étude
n’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 recenser
et de comparer les approches I DM de modélisation des plates-formes d’exécution dans un
objectif de déploiement d’applications. La seconde réponse est de proposer un processus de
dé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éel embarquées.
Contributions
Cette thèse contribue en trois points à la considération des plates-formes d’exécution
lors d’un processus de déploiement.
Une étude comparative des approches I DM de déploiement est présentée. Cette étude
couvre 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écution
temps réel embarquées).
Un langage de modélisation des plates-formes d’exécution temps réel embarquées
est défini sous le nom de RTEPML (Real-Time Embedded Platform Modeling Language).
Ce langage s’appuie sur les concepts qu’identifie le package S RM (Software Resource Mo-
deling) du profil U ML-M ARTE (U ML 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 dans
un contexte de développement utilisant des D SML (Domaine Specific Modeling Language)
comme alternative aux langages de modélisation généralistes (Generic Purpose Modeling
Language, dont U ML est un représentant, y compris dans ses formes profilés).
Un processus de déploiement d’application basé 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ériques ou générées. Il
s’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èse
et présente une étude prospective sur les pratiques de déploiements dans l’I DM. La seconde
partie se focalise sur la solution que nous proposons pour mettre en œuvre un déploiement
d’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 domaines des
systèmes embarqués temps réel et de l’I DM y sont successivement abordés.
Le second chapitre présente les approches de modélisation des plates-formes d’exécu-
tion dans l’I DM 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, implicite
et explicite, selon que les informations relatives à une plate-forme sont capturées dans une
transformation, un métamodèle ou un modèle. A chacune de ces approches correspondent
une 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, de
ré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écution
RTEPML que nous avons développé dans le cadre de cette thèse. Ce langage implante, d’une
part, le modèle de domaine du package S RM d’U ML-M ARTE et, d’autre part, un certain
nombre 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éel
embarquées. Le processus proposé se concrétise par un algorithme de transformations de
modèles. Ces transformations prennent comme paramètres des modèles d’applications et
des modèles de plates-formes d’exécution décrits avec RTEPML. Elles se composent de
rè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éploiement
identifiées lors de la prospection du second chapitre. Elle vise à confirmer les résultats qui
ont motivé le développement du processus.
Première partie
Contexte et état de l’art

Contexte
1
Sommaire
1.1 Les systèmes embarqués temps réel . . . . . . . . . . . . . . . . . . 5
1.1.1 Introduction aux systèmes embarqués temps réel . . . . . . . . 5
1.1.2 Mise en œuvre . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.3 Portée de l’étude . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2 L’ingénierie dirigée par les modèles . . . . . . . . . . . . . . . . . . 8
1.2.1 Introduction à l’ingénierie dirigée par les modèles . . . . . . . . 8
1.2.2 Mise en œuvre d’une ingénierie dirigée par les modèles . . . . . 11
1.3 Positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
e chapitre présente le contexte et la portée de cette étude. Il introduit en particulier le

C vocabulaire employé et les concepts mis à contribution.
Ce chapitre s’organise en deux sections. La première définit le domaine d’application
de l’étude, qui concerne le développement de systèmes embarqués temps réel. Cette section
décrit les principes de mise en œuvre de ces systèmes. La seconde section introduit l’ingé-
nierie dirigée par les modèles (I DM). Elle présente en particulier les concepts de l’I DM 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 informatique
intrinsèquement lié à un équipement (industriel ou bien de consommation) pour lequel il est
conçu et dans lequel il est intégré. Il est entièrement dédié à une ou plusieurs fonctionnalités
attendues 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 directe
avec 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 du
procé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 pilote
prennent 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 application
chargée de piloter le procédé, (b) d’un support d’exécution matériel et/ou logiciel et (c) de
périphériques, tels que des actionneurs répondant aux ordres de l’application ou des capteurs
transmettant 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 ou
multicœ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 une architecture 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 être
effectué soit par un programme logiciel s’exécutant sur un processeur, soit par un circuit
matériel personnalisé, tel que les A SIC (Application Specific Integrated Circuit) et les F PGA
(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épendamment
de 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.
1
Le 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 dont l’exécution

est 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ée
avec 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 une interface
simplifié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 actions
dans le temps (via, par exemple, des alarmes) [117].
On notera que certaines approches orientent leur solution vers un développement
conjoint des applications et des systèmes d’exploitation [42] [72]. Ces approches consistent
habituellement à générer les systèmes d’exploitation.
Enfin, des couches d’abstraction logicielles peuvent s’intercaler entre les 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 logicielles

dont l’exécution repose sur un système d’exploitation. Toutefois, aucun système d’exploi-
tation ne sera imposé. Nous ne projetons pas non plus de développer ou de générer des
systè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’occurrence
d’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 temps
nul vis-à-vis de la dynamique du procédé contrôlé et (2) la considération d’occurrences
d’évènement simultanées. Les occurrences des évènements mémorisés durant l’exécution
d’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 dans
lesquels la durée d’exécution des actions est inférieure à la période d’échantillonnage [21].
L’approche asynchrone consiste à 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 plusieurs
actions doit alors être adressé.
Positionnement Les systèmes que nous souhaitons mettre en œuvre suivent une ap-
proche asynchrone.
2
Dans 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 de
concurrences entre les tâches, ces systèmes d’exploitation fournissent des mécanismes de
synchronisation, 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 a déterminer l’alloca-
tion de ces ressources entre différentes tâches concurrentes. Cette politique est appliquée
par un ordonnanceur5 . Elle peut être définie « en ligne » ou « hors ligne ».
Une politique d’ordonnancement « en ligne » s’appuie habituellement sur un mécanisme
de priorité [100]. Son principe consiste à exécuter la tâche de plus forte priorité parmi celles
en concurrence. Les priorités peuvent être définies statiquement ou dynamiquement, sur la
base de critères liés à l’ensemble des tâches concurrentes, tels que leurs échéances ou leurs
périodes d’exécution [71]. Ce type de politique peut être préemptive, non-préemptive ou
mixte, 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écution
des 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ènement
est 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 temps
réel O SEK /V DX -O S [93], A RINC -653 [2] et VxWORKS [124] en sont des exemples.
Dans le second cas, un seul évènement externe, provenant d’une horloge périodique, se
manifeste par un appel à l’exécutif. Au rythme de ces appels, le procédé est contrôlé par
scrutation. La périodicité systématique de tout traitement permet de planifier les tâches de
l’application « hors ligne ». Le système est, dans ce cas, « cadencé par le temps » (time trig-
gered). Les exécutifs temps réel M ARS [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 des priorités (statiques ou
dynamiques). L’ordonnancement peut être préemptif, non-préemptif ou mixte.
1.1.2.5 Sûreté de fonctionnement

La confiance accordée dans la mise en œuvre d’un système embarqué temps réel relève
de 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 les
consé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’aviation
civile [123]). Ainsi, les catégories vont des moins critiques (voir non-critiques) aux plus
critiques et se voient imposées des probabilités de défaillances décroissantes.
3
Les tâches sont des unités, ou fils, d’exécution séquentielle.
4
L’exécutif est la partie du système d’exploitation qui gère ces mécanismes (entre autres).
5
L’ordonnanceur est un composant de l’exécutif.
Pour garantir des taux de défaillances acceptables, et apporter une confiance maximale
dans les systèmes réalisés, leurs mises en œuvre sont généralement guidées et contraintes
tout au long du cycle de développement [9].
Positionnement Les systèmes envisagés dans cette étude peuvent être étendus à des
systè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 les
mé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 dont
l’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âches
par 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 sont
identifié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 de mettre 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 dans
une intention particulière [43] [76].
L’ingénierie dirigée par les modèles (I DM, ou M DE, Model Driven Engineering) place
les modèles au centre de l’activité de développement. Toute activité s’articule autour d’un
ou de plusieurs modèles (conception, implantation, test, documentation, etc.). Le potentiel
de traitement automatique des modèles (telles que la simulation [30], l’analyse [40] [49] et
la transformation [55]) est mis en exergue dans cette ingénierie. Les modèles sont « pro-
ductifs », en opposition à une utilisation « contemplative », dans laquelle les modèles se
restreignent à des supports de communication et de compréhension [12].
Métamodèle L’exploitation informatique des modèles implique de les exprimer dans
des langages « interprétables » (ou « manipulables ») par des outils informatiques [58]. Pour
cela, l’I DM propose de définir des langages de modélisation via 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 le
langage.
Relation de conformité La relation entre un métamodèle et les modèles qu’il permet
de décrire, est nommée « relation de conformité ». Un modèle se conforme à un métamodèle.
Cette relation permet d’assurer qu’un modèle est correctement construit, dans l’objectif
de 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’I DM réside dans l’utilisation systématique

de métamodèles. L’abstraction des concepts d’un langage qu’offre un métamodèle lui vaut
parfois le terme de « syntaxe abstraite », en opposition aux « syntaxes concrètes » que four-
nissent les grammaires ou les chartes graphiques permettant d’exprimer les modèles dans
des formats textuels ou graphiques.
Des « passerelles » sont néanmoins nécessaires entre ces différentes repré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 ces
contextes. Dans l’espace technique des modèles qu’incarne l’I DM, la relation de conformité
entre un modèle et un métamodèle reflète, par exemple, les relations entre :
– un document X ML et un schéma ou une D TD, dans l’espace technique X ML ;
– 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 X ML, la création de syntaxes
textuelles de langages de modélisation et la mise en œuvre de framework de modélisation
en langage objet.
Méta-modélisation En réponse à une utilisation systématique de métamodèles, de
nombreuses plates-formes de développement, telles que openArchitectureWare [37], T OP -
CASED [41], G ME [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 des
mé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, un
méta-métamodèle est une abstraction d’un langage de méta-modélisation. Les plates-formes
de développement intègrent alors des méta-métamodèles issus de projet en lien direct avec
des outils, tels que MetaG ME [68] du projet G ME (Generic Modeling Environment) ou
Ecore [36] du projet E MF (Eclipse Modeling Framework). Généralement, ces plates-formes
se placent également dans un contexte normatif, tel que le standard M OF (Meta Object
Facility) [86] de l’O MG (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èle
productif [44]. Une transformation de modèle est un processus automatique de modification
d’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 (ou
la structure) des éléments qu’ils manipulent [11] :
1. Les langages de transformation de structures séquentielles d’enregistrement, tel que
AWK (du nom de ses concepteurs, Aho, Kernighan et Weinberger) [1], s’emploient
généralement dans l’espace technique des grammaires ;
2. Les langages de transformation d’arbres, tel que X SLT (Extensible Stylesheet Lan-
guage Transformations) [122], sont d’usage dans l’espace technique X ML ;
3. Les langages de transformation de graphes (généralement, orientés étiquetés),
tels que ATL (ATLAS Transformation Language) [55] ou Q VT (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 de

traduction qui font correspondre les concepts des métamodèles sources et cibles. Ces règles
sont décrites dans des modèles de transformation (conformes au métamodèle qui définit le
langage de transformation). On notera que deux types de règles se distinguent : impératives
et 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érer les élé-
ments des modèles cibles à partir de ceux des modèles sources. Il s’appuie pour cela sur les
relations de conformité entre les éléments des modèles et les concepts des métamodèles.
F IG . 1.1: Principe de mise en œuvre d’une transformation de modèle dans l’I DM.
Remarque : Par abus de langage, le terme « transformation » se réfère également aux

modèles de transformation.
Modèle vers texte Les transformations de modèles génèrent habituellement des mo-
dèles destinés à des outils I DM et donc sérialisés dans des formats spécifiques à l’I DM, tels
que le X MI (XML Metadata Interchange) [88]. Or, le développement d’un système vise
habituellement la production de fichiers dans des formats textuels différents, tels que de la
documentation H TML 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 en
sortie, comme le permet ATL ;
2. Les langages de template qui 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 T CS [57] et SinTaks [78].
Remarque : Un fichier de template est composé de blocs de texte dont une partie des
informations doit être complétée à partir de données externes. Dans le cadre de l’I DM, ces
données sont transmises à un moteur de template sous 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 de l’I DM. Quatre de
ces approches se distinguent par la maturité des outils qui les accompagnent : les approches
C ASE (Computer Aided Software Engineering), M IC (Model-Integrated Computing), Usine
logicielle (Software Factories) et M DA (Model Driven Architecture) [52].
C ASE Dans les années 80, l’approche C ASE (Computer Aided Software Engineering)
spécialise pour le domaine du logiciel, l’approche C AD (Computer Aided Design) pratiquée
notamment pour la conception des systèmes mécaniques. L’approche C ASE se destine alors
à supporter les activités de génie logiciel dans un processus de développement, sans définir
précisément ces activités et la nature du support qui en est fait [16]. Ainsi les premiers
outils C ASE automatisent principalement des activités isolées de développement, telles que
la production de la documentation ou la gestion de version. Puis, dans les années 90, ces
différents outils sont intégrés dans des environnements de type C ASE, autour de supports
méthodologiques de conception et de réalisation, pour former de véritables plates-formes
de développement [77].
M IC Depuis le milieu des années 90, l’approche M IC (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écifier
les concepts utiles pour modéliser le domaine d’application. Le résultat de cette étape se
concré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 applications
avec cet environnement. G ME (Generic Modeling Environment) [28] est un exemple de
plate-forme de développement associée à cette approche.
Usine logicielle Depuis les années 2000, l’approche « usine logicielle » (Software
Factories) s’inspire des principes des lignes d’assemblage dans l’industrie [51]. Une usine
logicielle 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 type
d’application. Cette approche encourage l’utilisation de « composants sur étagère »6 pour
un développement rapide de logiciels. Visual Studio .N ET est un exemple d’environnement
de développement adapté à cette approche.
M DA Depuis novembre 2000, l’approche M DA (Model Driven Architecture) [84],
initiée par l’O MG, standardise une architecture qui repose sur un niveau (M 0) des systèmes
à concevoir (ou « monde réel ») et trois niveaux de modélisation (M 1, M 2 et M 3) pour le
développement des modèles, métamodèles et méta-métamodèles7 . Dans cette architecture,
un méta-métamodèle du niveau M 3 est réflexif, c’est-à-dire qu’il se décrit lui-même. Le
M OF (Meta Object Facility) [86], standardisé dans le cadre du M DA, et Ecore (du projet
E MF) [36] sont des exemples de méta-métamodèles.
L’un des objectif du M DA 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
(P SM, Platform Specific Model), à partir de descriptions indépendantes de toute plate-forme
(P IM, Platform Independant Model). Au sens du M DA, les technologies et les plates-formes
6
Un composant sur étagère est un composant disponible pour être assemblé avec d’autres composants.
7
L’architecture « 3+1 niveaux » du M DA standardise ainsi ce que l’approche M IC et certains outils C ASE
pratiquent depuis plusieurs années.
englobent aussi bien l’environnement de développement que le support d’exécution d’une

application.
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 P IM peut être raffiné en plusieurs P SM
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étable
sur une plate-forme technologique précise.
Cependant, comme cela fut mentionné en introduction, le M DA ne précise pas comment
renseigner les informations relatives aux plates-formes dans les transformations. La notion
de description de plate-forme est évoquée (P DM : Platform Description Model), mais au-
cune précision n’est donnée sur sa forme et sur sa prise en compte dans le processus de
génération. Un P DM peut, par exemple, faire partie intégrante d’un modèle de transforma-
tion (d’un P IM vers un P SM) ou être passé en paramètre de cette transformation.
La figure 1.2 illustre un processus de transformation de modèles dans le M DA.
F IG . 1.2: Considération progressive des plates-formes dans le M DA.
Positionnement Dans cette étude, le déploiement d’une application sur le support

d’exécution (ou plate-forme d’exécution) qu’incarne le système d’exploitation est abordée
selon l’approche M DA. Ce déploiement est donc mis en œuvre par transformation d’un
modè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 M DA sur
la 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’I DM. Le premier tend à uni-
fier les moyens d’expression de modélisation dans un seul langage. Le second sépare ces
moyens dans différents langages dédiés à des domaines métiers. Ces deux approches sont
similaires à ce qui distingue les langages généralistes de programmation (tels que Java ou
C) et les langages de programmation dédiés (tels que S QL ou LATEX).
Un langage de modélisation généraliste (G PML, Generic Purpose Modeling Lan-

guage) vise à identifier des concepts génériques à plusieurs contextes de développement. Le
langage U ML (Unified Modeling Language) [90], standardisé par l’O MG, est aujourd’hui le
plus représentatif des langages de modélisation généralistes.
La définition des concepts de modélisation et la standardisation de leurs représentations
dans un seul langage favorisent l’homogénéité des outils, la réutilisation des modèles et
les échanges entre les utilisateurs. Le consensus à maxima nécessaire à l’adoption d’un tel
langage peut toutefois engendrer une profusion de concepts. Cette profusion complexifie
alors, d’une part, la prise en charge du langage dans les outils et, d’autre part, la localisation
du 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’O MG propose ainsi deux mécanismes d’extensions du langage
U ML. Une extension dite « lourde » intervient directement sur le métamodèle du langage
pour y ajouter, supprimer ou modifier des concepts [17]. Ce type d’extension compromet
alors fortement la généricité du langage. Une extension dite « légère » raffine le métamodèle
du langage pour introduire des concepts métiers. L’O MG standardise ce type d’extension par
la notion de profil [90] [47].
Une extension de G PML, tel qu’un profil U ML, permet donc d’identifier un ensemble
de 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 (D SML, Domain Specific Modeling
Language), à l’image des profils U ML, vise à identifier les concepts d’un domaine métier.
A l’inverse des profils U ML, les D SML ne se basent pas sur le métamodéle U ML (noyau
commun de concepts) mais définissent entièrement des langages plus restreints, limités au
domaine métier. Il se conforment pour cela à des méta-métamodèles (tels que le M OF de
l’O MG ou Ecore du projet E MF). Le langage de description d’architecture A ADL (Archi-
tecture Analysis & Design Language) [103], standardisé par la S AE (Society of Automotive
Engineer), est un exemple de D SML 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 D SML sont économique-
ment plus difficiles à maintenir, car destinés à un public restreint de spécialistes. Toutefois,
dans le cadre de l’I DM, leurs développements sont de plus en plus assistés par différents
projets consacrés à la génération automatique d’outils. G ME (Generic Modeling Environ-
ment) [28], E MP (Eclipse Modeling Project, incluant E MF, G EF et G MF) [35] et T OPCA -
SED [41] en sont des exemples.
Positionnement Les approches par D SML et G PML présentent chacune des avantages
et des inconvénients qui, à notre sens, ne permettent pas de trancher, sur l’utilisation de l’une
ou de l’autre dans l’absolu. Nous considérons en effet que le choix d’une de ces approches
dé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 D SML et les G PML serait ambitieuse. Seule
l’étude prospective sur la modélisation des plates-formes d’exécution et ses répercussions
sur un processus de déploiement sera donc abordée pour les deux approches. La proposition
de processus de déploiement d’application qui suivra sera présentée pour un contexte de
modélisation utilisant des D SML.
1.3 Positionnement
Comme cela fut mentionné en introduction, les travaux de cette thèse portent sur le
dé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, issues
de l’I DM, sont mises à contribution.
Dans une première section, nous venons de préciser la nature des systèmes sur lesquels
nous envisageons de déployer les applications. Les systèmes visés sont multitâ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 que
nous adopterons au travers des principes de l’I DM et plus particulièrement de l’approche
M DA. Les applications seront décrites dans des modèles indépendants de tout support d’exé-
cution. Un déploiement sera ensuite mis en œuvre par transformation de modèles, à l’issu
duquel un modèle de l’application déployée sera généré.
Cependant, l’approche M DA ne précise pas comment renseigner les informations re-
latives aux plates-formes lors du déploiement. Le chapitre suivant propose donc un état
de l’art prospectif sur les différentes formes que peuvent prendre ces informations et leurs
répercussions sur un processus de déploiement.
Cette prospection est menée dans des contextes de modélisation basés sur des langages
de modélisation génériques (G PML) et sur des langages de modélisation dédiés à des do-
maines métiers (D SML).
État de l’art
2
Sommaire
2.1 Les plates-formes d’exécution . . . . . . . . . . . . . . . . . . . . . . 17
2.1.1 Définition du concept de plate-forme d’exécution . . . . . . . . 17
2.1.2 Caractérisation des plates-formes d’exécution . . . . . . . . . . 17
2.1.3 Positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Les représentations des plates-formes d’exécution . . . . . . . . . . 18
2.2.1 Représentations enfouies . . . . . . . . . . . . . . . . . . . . . 18
2.2.2 Représentations implicites . . . . . . . . . . . . . . . . . . . . 19
2.2.3 Représentations explicites . . . . . . . . . . . . . . . . . . . . 21
2.3 Les déploiements sur des plates-formes d’exécution . . . . . . . . . 24
2.3.1 Plate-forme enfouie dans la technologie de déploiement . . . . 24
2.3.2 Déploiement sur une plate-forme implicitement décrite . . . . . 26
2.3.3 Déploiement sur une plate-forme explicitement décrite . . . . . 30
2.4 Comparaison des mises en œuvre . . . . . . . . . . . . . . . . . . . . 42
2.4.1 Génération d’un modèle de code source . . . . . . . . . . . . . 43
2.4.2 Génération d’un modèle d’application . . . . . . . . . . . . . . 45
2.5 Positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
e chapitre présente une étude prospective des considérations possibles des plates-
C 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’I DM, 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, approches
qualifiées de représentations enfouies, implicites ou explicites. La troisième section pré-
sente ensuite les processus de déploiement d’application conditionnés par ces différentes
approches de modélisation. Puis, la quatrième section compare les mises en œuvre de ces
processus. La cinquième et dernière section positionne finalement les travaux de cette étude
en 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-forme
d’exécution offre un contexte pour l’interprétation de ce que spécifie l’application [73]. Elle
fournit 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-formes
sous-jacentes[96].
En pratique, toute plate-forme peut-être considérée comme une application pour une
plate-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, et
comme une plate-forme d’exécution du point de vue d’un développeur logiciel. Un système
sera donc considéré en tant que plate-forme, non pas en raison de sa nature, mais en fonction
du 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 instant donné. 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 fonctionnel
permettant 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 de
l’art, au sein de l’équipe, lors de recherches antérieures [114]. Des précisions y sont données
sur 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 M DA 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 sur
les fonctionnalités d’une plate-forme sont communiquées : (a) un langage, qui décrit les
concepts 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 services
additionnels (tel que le type pthread_t des tâches logicielles, suggéré par la spécification
P OSIX), (c) des instances prédéfinies directement utilisables par l’application (tels que les
flux d’entrée et de sortie stdin et stdout de la librairie standard du langage C) et (d) les
motifs, ou patrons, qui représentent les règles nécessaires à l’utilisation des concepts mis à
disposition par les trois précédents aspects.
En se focalisant sur les plates-formes d’exécution logicielles, Marvie et al. [73] pro-
posent d’organiser leurs fonctionnalités dans trois modèles distincts : (a) le modèle statique
des 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 par la
plate-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 (le
cycle 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 de
ressources et de services offerts par la plate-forme.
L’approche M DA 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-
mas et 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 visibles
depuis l’interface de programmation (ou A PI, Application Programming Interface).
Dans le respect de l’approche M DA et dans la lignée des travaux mentionnés précé-
demment, Thomas et al. [115] identifient alors quatre axes pour modéliser l’interface de
programmation 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 des
traitements (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) la
caractérisation du comportement observable des ressources et des services (la description
de 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 dans
cette étude se focalisent sur les deux premiers axes définis par Thomas et al. : la description
des ressources et des services offerts par les plates-formes d’exécution. Nous nous limitons
pour cela à la description structurelle des ressources et des services, ce qui se traduit par
la 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 des
comportements observables (ou sémantiques d’exécution) des ressources et des services ne
seront pas abordées. Ces descriptions faisant l’objet d’une étude menée en parallèle, nous
les 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’I DM, 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 leurs
objectifs (analyses de performance, déploiements, simulations matérielles, etc.), trois re-
présentations majeures des plates-formes se distinguent. Cette section présente chacune de
ces 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 un
programme, 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ées
dans le modèle ou le programme.
Dans le cadre d’un déploiement d’application, les informations relatives à la plate-forme
peuvent, 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 à contribution des templates ,
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 les
templates qui structurent le code source à générer.
Dans la lignée de ces pratiques, la section suivante présente, page 24, un exemple de
description 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-forme sont
capturé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 U ML
Dans une approche U ML, la description implicite d’une plate-forme d’exécution peut
prendre la forme d’une extension légère du métamodèle U ML (un profil U ML). Les éléments
profilés du métamodèle sont alors spécialisés par des stéréotypes.
La figure 2.1 est un exemple de profil U ML dédié à la description d’application
O SEK /V DX. Ce profil définit les stéréotypes Task, Alarm et Counter permettant de décrire
respectivement des tâches, des alarmes et des compteurs O SEK /V DX.
Une tâche fournit un contexte pour l’exécution d’un traitement spécifié par l’utilisateur
sous 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 fournie
par un compteur.
L’interface de programmation d’O SEK /V DX 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’un
compteur, en nombre de ticks (ticksperbase), (b) la taille de la pile et la priorité statique
d’une tâche (stacksize et priority), et (c) la première expiration et le cycle d’une alarme
(alarmtime et cycletime).
F IG . 2.1: Un profil U ML d’applications spécifiques à la plate-forme O SEK /V DX.
Les stéréotypes définis par ce profil étendent la métaclasse Classifier d’U ML. Ils per-
mettent ainsi de spécifier des classes de modèles U ML.
Dans l’exemple de la figure 2.2, page suivante, le profil est appliqué à un modèle de
contrôleur de robot (RobotController). Certaines entités de l’application sont alors identi-
fiées par le profil. La classe MotionController est par exemple stéréotypée Task, une tâche
de la plate-forme O SEK /V DX est ainsi dédiée au contrôle de mouvements. Les attributs des
stéréotypes sont également renseignés dans des notes attachées aux classes. L’attribut prio-
rity du stéréotype Task est ainsi renseigné dans le but d’accorder une priorité 10 à la tâche
responsable du contrôle du mouvement. De même, l’attribut entrypoint de ce même stéréo-
type stipule que le point d’entrée de la tâche correspond à la méthode trajectoryControl du
contrôleur.
F IG . 2.2: Description U ML d’une application spécifique à la plate-forme O SEK /V DX.
Dans la littérature actuelle, les profils U ML dédiés à des plates-formes d’exécution

concrètes, tant logicielles que matérielles, sont rarement utilisés. Les profils U ML 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 D SML
Une approche alternative au profilage U ML capture implicitement les informations re-

latives à la plate-forme d’exécution dans un D SML. Le métamodèle du D SML est alors
implanté conformément à un langage de méta-modélisation (tels que le M OF ou Ecore)
dans le but de décrire des applications destinées à cette plate-forme.
La figure 2.3 est un exemple de D SML dédié à la description d’applications O SEK /V DX.
Cet exemple définit les concepts de tâche, d’alarme et de compteur O SEK /V DX introduits
dans l’exemple précédent (figure 2.1). Il inclut de plus : (a) une communication par variable
globale (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 cette
exemple) et (c) la notion de type de donnée supporté par la plate-forme (PlatformType).
F IG . 2.3: Un métamodèle d’applications spécifiques à la plate-forme O SEK /V DX.

La réalisation d’un D SML s’accompagne généralement d’une syntaxe concrète pour

l’expression des modèles. La figure 2.4 illustre dans une syntaxe graphique un modèle
conforme 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 syntaxe
graphique employée nous semble suffisamment simple pour ne pas être détaillée.
F IG . 2.4: Description avec un D SML d’une application spécifique à la plate-forme O SEK /V DX.
Dans la littérature actuelle, les langages O IL [92] et A ADL [103] sont des exemples de
D SML décrivant implicitement une plate-forme d’exécution logicielle. A ADL a toutefois la
particularité 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 parlons
alors de description explicite ou de plate-forme explicite, car un tel modèle est entièrement
dé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 U ML
Dans une approche U ML, la description explicite d’une plate-forme d’exécution peut se
conformer à un profil U ML dédié aux concepts des plates-formes d’exécution. Ces concepts
sont alors identifiés par des stéréotypes.
La figure 2.5 est un exemple de profil U ML dédié à la description de plates-formes
d’exécution temps réel embarquées. Ce profil définit les stéréotypes SchedulableResource,
AlarmResource et TimerResource permettant d’identifier les ressources d’une plate-forme
dédiées respectivement aux contextes d’exécutions gérés par un ordonnanceur, aux alarmes
et 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).
F IG . 2.5: Un profil U ML 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 O SEK /V DX. Une tâche est par exemple identifiée comme une
ressource ordonnançable (SchedulableResource), car son activation et son exécution sont
gérées par un ordonnanceur. Les propriétés des ressources sont également identifiées en
renseignant les attributs du stéréotype. La propriété nommée priority permet d’exprimer la
priorité d’une tâche. Cette propriété est référencée par l’attribut priorityElt du stéréotype
SchedulableResource.
F IG . 2.6: Description explicite d’une plate-forme O SEK /V DX avec un profil U ML.
Dans un contexte U ML, différentes technologies sont actuellement disponibles pour dé-
crire explicitement des plates-formes d’exécution matérielles ou logicielles. Parmi celles-
ci, P ML (Platform Modeling Language) [107] se destine à la description de plates-formes
d’exécution et de plates-formes d’analyse1 . P ML permet, entre autre, de modéliser les res-
sources et les signatures des services qu’offre une plate-forme logicielle ainsi que leurs
contraintes d’utilisation. Dans le même esprit, T UT-Profile (Tampere University of Techno-
logy - U ML Profile) [63], initialement prévu pour la modélisation d’applications temps réel
embarquées et de plates-formes d’exécution matérielles, a été étendu pour la description de
plates-formes logicielles [4]. Enfin, issu des travaux les plus récents, le profil U ML-M ARTE
(U ML profile for Modeling and Analysis of Real Time and Enbedded systems) [89], stan-
dardisé par l’O MG 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, le package S RM (Software Resource Modeling) propose en
particulier des artefacts de modélisation des plates-formes logicielles. Pour cela, S RM spé-
cialise, pour le domaine du temps réel et de l’embarqué, les concepts généraux de ressource
et de service du package G RM (Generic Resource Modeling). Ces concepts de ressource et
service étaient déjà présents dans le profil S PT de l’O MG (Schedulability, Performance and
Time) [85], que U ML-M ARTE tend à supplanter.
2.2.3.2 Approche D SML

Une approche alternative aux profils U ML consiste à décrire explicitement les plates-
formes d’exécution avec des D SML. A l’instar des profils U ML que nous venons de présen-
ter, un tel D SML 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 de
plates-formes d’exécution temps réel embarquées. Ce D SML définit les concepts introduits
dans l’exemple du profil U ML précédent (SchedulableResource, AlarmResource et Timer-
Resource). Chacun de ces concepts hérite d’un concept abstrait de ressource, auquel un
ensemble de propriétés peut être attribué. Dans cet exemple, les propriétés des ressources
sont d’un type natif à la plate-forme (DataType).
1
P ML a été implanté sous la forme d’une extension lourde d’U ML (P ML-U ML) et intégré dans G ME [53]
F IG . 2.7: Un D SML de description de plates-formes d’exécution.
L’exemple de la figure 2.8 illustre l’utilisation de ce D SML pour la modélisation des

concepts de tâche, d’alarme et de compteur O SEK /V DX. 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 semble
suffisamment intuitive pour ne pas être plus détaillée.
F IG . 2.8: Description explicite d’une plate-forme O SEK /V DX avec un D SML.
Dans la littérature actuelle, peu de D SML de description de plates-forme d’exécution

logicielles ont été identifiés. Les D SML offrant un support pour la description de plates-
formes d’exécution concernent principalement la modélisation des supports matériels. Par
exemple, le langage A ADL, précédemment cité, fournit un ensemble de composants pour
modéliser à un haut niveau d’abstraction les processeurs, les bus de communication et les
pé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 aux
composants logiciels du langage). Parmi les D SML qui offrent un support à la description
explicite des plates-formes d’exécution, tant logicielles que matérielles, la méthodologie
de conception Metropolis [94], basée sur les modèles de plates-formes (ou Platform Based
Design [97]), propose au sein de son métamodèle des concepts d’activité concurrente et de
communication entre ces activités [75]. Cependant, la généricité de ces concepts ne permet
pas 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 Integrated
Computing) [50] offre un support pour la modélisation de supports d’exécution logiciels
basés sur le standard C CM (C ORBA Component Model) [87] spécialisé pour les domaines
de l’embarqué, du temps réel et de la qualité de service (QoS). Cette approche permet donc
de décrire explicitement des intergiciels développés dans le respect du standard C ORBA.
Elle se prête ainsi à la modélisation explicite de certaines plates-formes d’exécution, mais
ne 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 structurelles
du 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 étude
se concentre sur leurs manipulations lors d’une phase de déploiement d’applications. Cette
section 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écution
durant 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’une
application 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 applications
devant 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 le
modè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.
F IG . 2.9: Trois approches de déploiement d’une application sur une plate-forme.
Nous proposons d’illustrer ces approches en nous appuyant sur les descriptions de la
plate-forme O SEK /V DX de la section précédente. Pour chacune, nous détaillons le principe
de 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 de templates pour la
gé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 le
code source de l’application), via une technologie dans laquelle les informations relatives à
la plate-forme sont enfouies.
2
Les 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 robotique en un

modèle de code dédié à la plate-forme O SEK /V DX3 . La transformation développée génère
un modèle de code C (conforme à un métamodèle du langage C). Le passage au code source
se 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 ou d’affichage du
modèle d’entrée. Le nom d’une tâche, passé en paramètre de l’appel, correspond au nom de
l’activité qui lui correspond.
F IG . 2.10: Plate-forme enfouie dans une transformation.
Dans cette approche, les informations relatives à la plate-forme cible sont capturées
dans la transformation (cf. figure 2.10, la référence à la fonction DeclareTask de l’A PI
d’O SEK /V DX, 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 conforme au
métamodèle d’un langage de transformation.
Remarque : L’utilisation d’un template de génération de code suit le même principe. Les
informations relatives à la plate-forme et au langage de programmation sont alors capturées
dans le template [69] [112].
3
Les 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 éditeurs
arborescents de modèles (tel que celui d’E MF).
2.3.2 Déploiement sur une plate-forme implicitement décrite

2.3.2.1 Contexte U ML
Dans un contexte U ML, 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 et
les relations, avec les concepts qu’identifie le profil associé à la plate-forme. L’exemple de
la figure 2.11 illustre le résultat de cette opération4 .
F IG . 2.11: Déploiement d’une application sur une plate-forme O SEK /V DX (U ML).
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. Dans l’exemple
de la figure 2.11, si la classe MotionController avait été identifiée par un stéréotype « Ac-
tivity » (défini dans un profil dédié aux applications de robotique), le marquage de cette
classe avec le stéréotype « Task » , dans le modèle de l’application déployée, aurait pu être
déduit à partir de règles de correspondance. Une telle règle aurait alors exprimé que toute
classe 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 de
transformation, à l’image de celles que nous présentons dans la suite de cette section.
2.3.2.2 Contexte D SML

Dans un contexte D SML, 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 la
plate-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 cette
partie trois cas différents. Le premier illustre l’utilisation d’une description implicite de
plate-forme dans un métamodèle de langage de programmation. Le second s’appuie sur le
métamodèle d’applications O SEK /V DX introduit dans la section précédente. Le troisième
enrichit 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 un
métamodèle de langage de programmation. Cette pratique consiste à étendre le métamodèle
d’un langage pour y intégrer l’A PI de la plate-forme (ce qui revient à considérer l’interface
de programmation de la plate-forme dans une librairie du langage). La plate-forme est alors
implicitement décrite dans le métamodèle du langage.
4
La 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 de

l’exemple précédent (figure 2.10, page 25) ainsi modifiés.
F IG . 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 concepts

propres à 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 de la transformation
se trouve également légèrement réduit.
Utilisation d’un métamodèle d’application spécifique à une plate-forme
Dans un contexte D SML, une plate-forme d’exécution peut être implicitement décrite
dans 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 O SEK /V DX
ainsi décrite dans un D SML. L’application se compose de deux activités périodiques, l’une
pour 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èle
de l’application est alors transformé en un modèle conforme au métamodèle d’application
O SEK /V DX introduit précédemment (figure 2.3, page 20). L’application résultante se com-
pose de deux tâches O SEK /V DX périodiquement activées par des alarmes. Ces alarmes se
dé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 .
F IG . 2.13: Déploiement d’une application sur une plate-forme O SEK /V DX implicitement décrite.
5
La concordance des sémantiques d’exécution attendues pour les deux modèles est supposée vérifiée pour
les besoins de l’application.
Des règles de transformations établissent les correspondances entre les éléments du

modèle source et ceux du modèle cible. Le code ATL extrait de la transformation RO -
BOT 2O SEK /V DX (listing 2.1) décrit certaines correspondances appliquées dans l’exemple
de la figure 2.13.
-- Create a task, a routine and an alarm from a periodic activity

rule PeriodicActivity2PeriodicTask {
from
activity : ROBOT!Activity ( activity.isPeriodic() )
to
task : 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 alarms

unique lazy rule CreateOneCounter {
from
activity : ROBOT!Activity ( activity.isPeriodic() )
to
counter : OSEKVDX!Counter (
name <- ’SysCounter’,
ticksperbase <- 1
)
}
Listing 2.1: Extrait de la transformation ROBOT 2O SEK /V DX (en ATL)
La règle PeriodicActivity2PeriodicTask du listing 2.1 stipule que toute instance d’acti-

vité périodique du modèle source est transformée en :
– une tâche O SEK /V DX,
– 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ègle
impérative (CreateOneCounter). Ce type de règle (unique lazy) permet de créer un élément
au 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 sont
renvoyées par des fonctions (ou helpers, en ATL), telle que getPriority() pour la valeur de
priorité d’une tâche. Nous ne détaillerons pas les implantations possibles de ces fonctions
qui peuvent, par exemple, déduire leurs valeurs de retour par calcul (à partir de données
disponibles dans le modèle source) ou retransmettre des valeurs passées en paramètre de la
transformation (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 par
la considération d’un métamodèle décrivant les concepts et les services offerts par la plupart
des 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êt réside dans sa
capacité à 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épendantes
de 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 se scinde alors
en deux étapes. Une première transformation (X2Pivot) spécifie l’application avec les
technologies qui permettent son exécution. Une seconde transformation (par exemple Pi-
vot2O SEK /V DX ou Pivot2A RINC-653) déploie ensuite l’application sur une plate-forme
concrète qui implante les technologies nécessaires à son exécution.
F IG . 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’autre

du pivot. Pour un même métamodèle source, la transformation de la première étape est
commune à toutes les plates-formes concrètes envisageables. Parallèlement, quelque soit
le 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 ou
d’exécution, ne nécessite la refonte que d’une partie du processus de dé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’il
est 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éfinit
une 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 une
routine dans cet exemple). L’activation d’une entité ordonnançable peut être périodique,
apériodique ou sporadique. La notion de SharedDataComEntity définit un média de com-
munication par variable partagée. Dans cet exemple, les services de lecture et d’écriture
d’une variable partagée sont accessibles depuis une ressource ordonnançable.
F IG . 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 pivot
dans une première étape. Le modèle résultant est ensuite transformé selon des règles de
correspondances entre les concepts du pivot et ceux de la plate-forme concrète ciblée. La
figure 2.16 détaille l’introduction du pivot que nous venons de définir (figure 2.15), dans le
processus de déploiement d’une application de robotique sur une plate-forme O SEK /V DX
(exemple de la figure 2.13, page 27).
F IG . 2.16: Déploiement d’une application sur une plate-forme O SEK /V DX 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 de
ces concepts sur la plate-forme O SEK /V DX. La variable de communication se concrétise
par une variable globale et les ressources ordonnançables périodiques par des tâches dont
les 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 une plate-forme
explicitement décrite. Cette pratique peut suivre quatre approches en fonction des relations
entre les métamodèles de l’application (P IM), de la plate-forme d’exécution (P DM) et de
l’application spécifique à la plate-forme (P SM) (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 des
concepts de mise en relation des éléments de l’application avec ceux de la plate-forme. Le
modèle de l’application déployée correspond alors à l’union des modèles de l’application et
de la plate-forme, enrichi des relations entre leurs éléments.
Les approches suivantes concernent les déploiements à partir de métamodèles différents

pour 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 de P SM.
Le premier type de P SM est conforme à un métamodèle généré à partir du modèle de
la 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 en un mé-
tamodèle. Le métamodèle résultant offre alors les concepts nécessaires à la modélisation
d’applications spécifiques à la plate-forme6 .
Le second type de P SM est conforme à un métamodèle différent et indépendant des
métamodèles sources utilisés pour décrire l’application et la plate-forme d’exécution. Ce
métamodèle peut couvrir différents domaines (programmation, analyse, etc.).
Enfin, le troisième type de P SM 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’une
application s’exécutant sur la plate-forme. L’enrichissement auquel nous faisons référence
correspond à une instanciation des ressources de la plate-forme pour les besoins d’une ap-
plication. Le P SM représente alors la plate-forme d’exécution et l’utilisation qui est faite de
ses ressources pour l’exécution des traitements spécifiés par une application.
F IG . 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 U ML
Dans un contexte U ML 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 conforment tous à U ML
(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 à mettre
en relation les concepts applicatif avec ceux de l’exécutif. Le second, que nous qualifierons
d’« instanciation », consiste à instancier, dans un premier temps, les ressources de la plate-
6
Le 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 instances
de 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 logiciel
et le matériel. La notion de déploiement (deployment) définie dans le standard U ML [90]
permet, par exemple, d’exprimer la répartition spatiale du logiciel sur le matériel.
Certains profils U ML raffinent néanmoins des concepts d’association entre des classi-
fiers et des instance classifiers U ML (comme par exemple des classes ou des composants)
pour identifier des relations de déploiement qui concernent également les plates-formes
logicielles. T UT-Profile définit, par exemple dans ce but, le concept PlatformMapping [62]
qu’il étend à la notion de déploiement sur un support d’exécution logiciel. U ML-M ARTE dé-
finit également, dans le package Alloc (Allocation Modeling) [89], le concept d’allocation
(allocate) spatiale ou temporelle des fonctionnalités d’une application sur les ressources du
support d’exécution.
Le principe alternatif d’instanciation modélise explicitement les entités du support
d’exécution mises à contribution lors de l’exécution de l’application. Ces entités sont alors
agencées (ou mises en relation) avec les entités du modèle logique de l’application. Nous
nous 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 O SEK /V DX,
de l’application de robotique introduite précédemment. L’application est modélisée en U ML
dans le package RobotController. Le modèle de l’application déployée sur la plate-forme
(O SEK /V DX Application) importe alors la description de la plate-forme7 . Deux tâches (t1
et t2) responsables de l’exécution des activités de contrôle et d’affichage de l’application
(Controller et Monitor) sont instanciées. Les propriétés de chacune des tâches ainsi que
leurs 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 des
activations périodiques des tâches.
F IG . 2.18: Déploiement d’une application sur une plate-forme O SEK /V DX décrite avec un profil U ML.
7
La modèle de la plate-forme O SEK /V DX 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 O SEK /V DX 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 concepts
de l’applicatif (identifiés par les stéréotypes utilisés dans le modèle de l’application) et les
concepts de la plate-forme d’exécution.
La figure 2.19 illustre la mise en œuvre de cette approche. Pour cela, le modèle de
l’application de robotique introduit précédemment est stéréotypé à l’aide d’un profil U ML
dédié à son domaine d’application. Le pseudo code ATL de la figure 2.19 donne le principe
d’une transformation de déploiement associée. Dans cet exemple, une instance de ressource
ordonnanç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.
F IG . 2.19: Principe d’une transformation de déploiement sur une plate-forme décrite avec un profil U ML.
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 U ML 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. Le
portage à pour principe de s’appuyer sur un déploiement existant pour générer un modèle
de 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érique
issue de ces travaux (la transformation est qualifiée de « transformation de portage »). Son
principe consiste à reproduire un déploiement existant en faisant une analogie entre les
ressources 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 est déjà déployée),
s’il existe une ressource stéréotypée de la même façon dans la plate-forme cible (la nou-
velle plate-forme considérée), cette ressource est instanciée. Le nom de l’instance « cible »
8
Les 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 et renseignées dans les
propriétés de l’instance générée.
Algorithme 2.1 : Principe d’un portage générique (basé sur le profilage U ML) [115]
Entrée :
Is : l’ensemble des instances d’un modèle d’application déployée sur une plate-forme Ps
Ms : le modèle de la plate-forme Ps
Mc : le modèle de la plate-forme Pc
Sp : l’ensemble des stéréotypes du profil U ML
Résultat :
It : l’ensemble des instances d’un modèle de l’application déployée sur une plate-forme Pc
Notations :
type(i) : la classe du modèle de la plate-forme qui type l’instance i
χ(c) : le stéréotype auquel se conforme la classe c
prop(s) : l’ensemble des propriétés du stéréotype s
prop(c) : l’ensemble des propriétés de la classe c
début
pour chaque is ∈ Is tel que χ(type(is )) ∈ Sp faire
si ∃ classe c ∈ Mc tel que χ(c) = χ(type(is )) alors
Créer ic une instance de la classe c
nom de ic ← nom de is
dépendances de ic ← dépendances de is
pour chaque propriété p ∈ prop(type(is )) tel que χ(type(is )) référence p
faire
si ∃ propriété p′ ∈ prop(χ(c)) tel que p′ = p alors
valeur p′ ← conversion de la valeur de p pour Pc
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 est
disponible et implantée pour le profil U ML-M ARTE [114].
2.3.3.2 Contexte D SML

Dans un contexte D SML, les modèles de l’application et de la plate-forme d’exécution
ne 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 par
les relations entre les métamodèles de l’application (P IM), de la plate-forme d’exécution
(P DM) et de l’application spécifique à la plate-forme (P SM).
Mise en relation des éléments d’un système
A l’image de ce que nous venons de présenter dans un contexte U ML, une première pra-
tique de déploiement concerne les technologies qui fournissent un même métamodèle pour
dé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 de
l’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 section
pré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 concept
de mise en relation des éléments applicatifs et des éléments exécutifs (Mapping).
F IG . 2.20: Un D SML de description de système (application + plates-formes d’exécution).
A l’image de ce qui se pratique dans un contexte U ML, cette approche se retrouve prin-
cipalement dans les technologies de modélisation conjointe des applications et des supports
d’exécution matériels. Les déploiements décrivent alors la répartition spatiale du logiciel
sur le matériel. Par exemple, A ADL 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. Metropolis
intègre également dans son métamodèle un concept de déploiement de l’applicatif sur le
support d’exécution (Mapping) [75]. Ce concept met en relation les services que requière
un 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 application reste
cependant cloisonnée dans une technologie. Aucune intégration de modèles d’applications
conformes à 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 et
le support d’exécution nécessite de mettre en œuvre des déploiements basés sur 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 et 4 de la figure 2.17,
page 31). A chacune de ces approches correspond alors un type de modèle d’application
spécifique à une plate-forme d’exécution (ou P SM).
Le premier type de P SM, 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. Elle
consiste à 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 P SM à 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 des applications
sur 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èle de la
plate-forme O SEK /V DX des exemples précédents (figure 2.7 et 2.8, page 23). Un extrait
simplifié de méta-métamodèle est également introduit sous le nom de MMM.
F IG . 2.21: Promotion d’un modèle de la plate-forme O SEK /V DX en un métamodèle d’application.
Les règles du listing 2.2 issues de la transformation Platform2Meta, illustrent la mise

en œuvre d’une promotion. Dans cet extrait, tout élément du modèle source conforme à une
ressource est transformé en une (méta)classe (lignes 2 à 13). Cette (méta)classe est munie
d’un attribut de nommage (lignes 9 à 12) et d’un attribut pour chacune des propriétés de
l’élément source (lignes 15 à 22). Le code complet de la transformation Platform2Meta de
l’exemple est donné en annexe (page 163).
1 -- Create meta-class from resource concept

2 rule Resource2Class {
3 from resource : Platform!Resource
4 to
5 class : MMM!Class (
6 name <- resource.name,
7 attributes <- Sequence{ name, resource.properties }
8 ),
9 name : MMM!Attribute (
10 name <- ’name’,
11 type <- #String
12 )
13 }
14 -- Create attribute of meta-class from property of resource
15 rule Property2Attribute {
16 from property : Platform!Property
17 to
18 attribute : MMM!Attribute (
19 name <- property.name,
20 type <- property.getType()
21 )
22 }
Listing 2.2: Extrait de la transformation de promotion Platform2Meta (en ATL)

Le métamodèle généré par cette transformation est similaire à celui d’une description
implicite 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 P SM, ainsi générés, sont tous
liés au métamodèle de plate-forme d’exécution. Ces concepts sont en effet issus de modèles
conformes 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-formes peuvent donc
être exploités pour automatiser le portage d’applications (à l’image du portage générique
présenté précédemment dans un contexte U ML, page 34). L’automatisation d’un tel portage
prend ici la forme d’une génération de transformations (figure 2.22).
F IG . 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. A partir de
deux 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 qui
résultent de la promotion de ces éléments.
Algorithme 2.2 : Principe d’une génération de transformation de portage
Entrée :
M Mp : un métamodèle de plate-forme d’exécution (ressources/propriétés)
Ms : le modèle de la plate-forme Ps
Mc : le modèle de la plate-forme Pc
La transformation de promotion d’un modèle en un métamodèle est supposée connue.
Résultat :
Ts2c : l’ensemble des règles de transformation d’un portage de Ps vers Pc
Notations :
promo(c) : la (méta)classe issu de la promotion de la classe c
prop(c) : l’ensemble des propriétés que renseigne la classe c
χ : la relation de conformité
début
pour chaque ressource r ∈ M Mp faire
si ∃ classe cs ∈ Ms tel que cs χr ∧ ∃ classe cc ∈ Mc tel que cc χr alors
Créer la règle Rcs 2cc de correspondance entre promo(cs ) et promo(cc )
pour chaque propriété p ∈ prop(cs ) faire
si p ∈ prop(cc ) alors
Créer, dans Rcs 2cc , 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 cela
sera évoqué dans la suite de ce manuscrit, des versions améliorées de cet algorithme 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 que
nous avons recensés. L’atelier G ME propose néanmoins une approche en quelques points
similaires [53]. Cette approche est, d’une part, hybride : la modélisation des plates-formes
d’exécution peut être implicite ou explicite. Pour cela, des transformations de modèles,
en G ReaT (Graph Rewriting and Transformation) [54], sont disponibles pour passer d’un
métamodèle à un modèle conforme à P ML9 [107]. L’outillage associé à P ML et intégré dans
G ME permet, d’autre part, de générer automatiquement une partie des règles de portage
d’une application. Cette génération s’appuie sur un concept fourni par P ML pour exprimer
des règles de transformation entre les composants de différentes plates-formes. L’expression
de ces règles et la modélisation des plates-formes ne sont pas clairement séparées dans
cette approche. Les descriptions des règles de transformation se confondent avec celles des
ressources 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, la
deuxième approche identifiée implique un P SM conforme à un métamodèle différent et
indépendant des métamodèles de l’application et de la plate-forme d’exécution (approche 3
de 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 code
source 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 descriptions
de plates-formes enfouies dans une transformation (page 24) ou les descriptions implicites
dans 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 de
robotique en un modèle de code dédié à la plate-forme O SEK /V DX (exemple introduit dans
la 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 du
modèle d’entrée, et (b) un appel à une fonction de déclaration d’alarme, pour les activations
périodiques des tâches.
Remarque : Les métamodèles de plate-forme des exemples précédents fournissaient le
concept de propriété d’une ressource. Celui de cet exemple n’identifie plus ce concept, mais
fournit celui de service offert 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 suite de
ce 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 ce chapitre.
La transformation de déploiement de l’exemple (Robot & PDM to C) établit la corres-
pondance entre les éléments des modèles sources (P IM et P DM) et les éléments du modèle
cible (P SM). La règle PeriodicActivity2PeriodicSchedulableResource du listing 2.3, page
ci-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).
9
Dans G ME, l’implantation de P ML par une extension lourde d’U ML (U ML-P ML) s’apparente ici à une
approche D SML, en opposition à l’approche par profil U ML.
Pour des raisons didactiques, la transformation du listing 2.3 ne comporte pas tout le code
ATL. Certaines parties ont été volontairement omises.
F IG . 2.23: Génération d’un modèle de code spécifique à une plate-forme O SEK /V DX décrite avec un D SML.
Remarque : Le principe de cette approche peut être appliqué à l’utilisation d’un template
de génération de code. Les modèles de l’application et de la plate-forme sont alors transmis
comme paramètres du template .
1 -- Create declare functions of schedulable resource and alarm

2 -- from a periodic activity
3 rule PeriodicActivity2PeriodicSchedulableResource {
4 from
5 activity : ROBOT!Activity ( activity.isPeriodic() )
6 to
7 schedres : C!APIFunctionCall (
8 name <- Platform!SchedulableResource
9 .getDeclareService(),
10 parameters <- Sequence{ shedresparam }
11 ),
12 shedresparam : C!APISlot (
13 name <- activity.name
14 ),
15
16 alarm : C!APIFunctionCall (
17 name <- Platform!AlarmResource
18 .getDeclareService(),
19 parameters <- Sequence{ alarmparam }
20 ),
21 alarmparam : C!APISlot (
22 name <- activity.name + ’Alarm’
23 )
24 }
Listing 2.3: Extrait de la transformation Robot & PDM to C (en ATL)

Bien que la transformation présentée soit très liée à la plate-forme O SEK /V DX dans la
mise en œuvre qu’elle propose10 , seuls les concepts du métamodèle de plate-forme sont
nécessaires à l’expression de ses règles. Cette caractéristique offre des 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 P SM, auquel nous nous intéressons dans cette partie, est conforme au
métamodèle de plate-forme d’exécution (approche 4 de la figure 2.17, page 31).
Ce principe consiste à introduire dans le métamodèle de plate-forme d’exécution, non
pas 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égration
d’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 sur
un 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 en
relation (relatedTo). Les propriétés des ressources qui les typent sont de plus renseignées
pour chacune d’elles. Les instances possèdent ainsi des propriétés (InstanceProperty) dont
l’attribut value donne la valeur (ce D SML se contente d’une valeur littérale exprimée dans
une chaîne de caractère).
F IG . 2.24: Un D SML 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 robotique

déployée sur une plate-forme O SEK /V DX. La plate-forme d’exécution O SEK /V DX est ici
explicitement modélisée avec le D SML (le modèle de la plate-forme correspond à celui de la
figure 2.8, page 23). Les modèles de l’application et de la plate-forme sont ensuite 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 D SML de description de plate-forme d’exécution. Le système résultant
correspond à la plate-forme d’exécution ciblée dont certaines ressources sont instanciées
en vue d’exécuter l’application. Deux tâches sont, par exemple, instanciées pour offrir un
contexte d’exécution aux activités de contrôle et d’affichage (Controller et Monitor).
10
L’activation périodique d’une ressource ordonnançable n’est pas forcément mise en œuvre par une alarme
sur d’autres plates-formes d’exécution.
11
Le concept d’instance de ressource sera détaillé et discuté dans la suite de ce rapport.
F IG . 2.25: Déploiement d’une application sur une plate-forme O SEK /V DX décrite avec un D SML.
La transformation de déploiement (Robot2Platform) établit la correspondance entre les

éléments des modèles sources (P IM et P DM) et les éléments du modèle cible (P SM). Une
partie 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 et
des instances de ressources de la plate-forme.
La règle PeriodicActivity2PeriodicSchedulableResource du listing 2.4 stipule par
exemple 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 une
instance d’alarme (cf. lignes 7 et 18).
1 -- Create a schedulable resource and an alarm

2 -- from a periodic activity
3 rule PeriodicActivity2PeriodicSchedulableResource {
4 from
5 activity : ROBOT!Activity ( activity.isPeriodic() )
6 to
7 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.properties
15 ->select( p | p.isPriority() )
16 ),
17
18 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.properties
26 ->select( p | p.isCycletime() )
27 )
28
29 }
Listing 2.4: Extrait de la transformation ROBOT 2P LATFORM (en ATL)

Au sein des règles de transformation, les instances de ressources sont associées aux
ressources de la plate-forme qui les typent (lignes 9 et 20)12 . De même, les valeurs de
propriétés affectées dans une instance sont associées aux propriétés de la ressource qui type
l’instance (lignes 14-15 et 25-26). La valeur 2 de l’instance de tâche Controller (figure 2.25)
est, par exemple, ainsi affectée à la propriété priority issue de la ressource Task.
La mise en œuvre de cette transformation diffère de celle de l’approche précédente par
les concepts cibles impliqués. Les accès aux informations des modèles de l’application et de
la plate-forme restent cependant les mêmes. Ainsi, comme pour l’exemple précédent, bien
que la transformation présentée soit très liée à la plate-forme O SEK /V DX13 , aucun concept
propre à cette plate-forme n’intervient dans l’expression des règles de transformation. Cette
caracté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 ne concré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ésentations
enfouies, implicites ou explicites des plates-formes. Elles se répartissent, d’autre part, en
deux 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 plus
haut niveau que ceux d’un langage de programmation). Nous proposons dans cette partie
de 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 des
contextes U ML et D SML [19]. Ces expérimentations ont été menées sur des applications de
robotiques décrites avec des D SML ou des profils U ML « maisons ». Les concepts identifiés
par ces D SML et ces profils sont proches de ceux que nous avons mis à contribution dans
les 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 traitements
concurrents périodiques ou apériodiques, identifiés comme des tâches communicant entre
elles ou avec l’environnement. Les plates-formes d’exécution visées étaient O SEK /V DX,
A RINC -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 composantes
impliqué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 des
métamodèles et des modèles des applications sources (P IM).
Pour cette évaluation, notre attention s’est portée sur les critères suivants :
– La capacité de l’approche à répartir les connaissances entre les composantes. Les
connaissances 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é ;
12
Comme 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.
13
L’activation périodique d’une ressource ordonnançable n’est pas forcément mise en œuvre par une alarme
sur d’autres plates-formes d’exécution.
2.4. Comparaison des mises en œuvre 43
– Le temps de développement des différentes composantes et leur taille. L’échelle de

temps est estimée pour un ingénieur familier des concepts de l’I DM. Les tailles sont
estimées en nombre de lignes pour les transformations et en nombre de classes pour
les modèles et les métamodèles ;
– La capacité de ré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é de prendre en compte des choix de déploiement, lorsque plusieurs
mises 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 dans
un contexte D SML. 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 de
déploiement (description enfouie ). La seconde capture ces informations dans le métamo-
dèle du langage de programmation (description implicite ). La troisième les capture dans un
modèle conforme à un métamodèle de plate-forme d’exécution (description explicite ).
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 implicite
Description enfouie Description explicite
dans un langage
Ts2c M Ml Ts2c M Ml Ts2c M Mp Mp M Ml
Connaissances −− + −− − +? ++ + +
Temps + + + + − − ++ +
Taille −− − − −− −− ? −? ++ −
Réutilisation −− + −− − +? ++ + +
Choix −− − +?
Ts2c : transformation d’un modèle d’application en un modèle de code ;
M Mp : métamodèle de plate-forme d’exécution ;
Mp : modèle d’une plate-forme d’exécution ;
M Ml : 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 (description enfouie ) capture les informations relatives à la plate-

forme d’exécution dans la transformation. Celle-ci est ainsi figée sur les concepts 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 I DM 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écisions
sont exprimés dépendent de ce qui est implanté dans la transformation.
La seconde approche (description implicite dans un langage de programmation) facilite
l’identification des éléments liés à la plate-forme dans la transformation et dans le modèle
gé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 plus concises et
d’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 du
langage 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 concepts
des domaines impliqués. Leurs développements sont donc également réservés à des experts
de l’I DM et de tous ces domaines.
La troisième approche (description explicite ) investit dans le développement d’un mé-
tamodèle de plate-forme d’exécution. Une description explicite capture alors les connais-
sances relatives à la plate-forme dans un modèle dédié. Ces connaissances ne se confondent
plus 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 de
déploiement (application, plate-forme d’exécution, langage de programmation et domaine
du 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é de gé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écution
y sont référencés. Les règles (ou des parties de règles) s’appliquent donc potentiellement
pour 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 porter
sur 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 gestion
des 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 la
place des informations relatives à celle-ci dans le processus de déploiement. Pour cela,
au terme de ces premières expérimentations, des investigations supplémentaires se doivent
d’ê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 effet une meilleure
séparation des connaissances, un plus grand potentiel de réutilisation des composantes et un
meilleur support pour l’intégration des décisions relatives aux choix de déploiement. Cette
approche 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.
14
Les 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 à disposition
d’un modèle de code entièrement compatible avec un outillage I DM. En contrepartie, les
transformations 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 exemples de règles de trans-
formations (figures 2.10, 2.12 et listing 2.3, pages 25, 27 et 39 respectivement) déclarent
ainsi la génération d’un appel de fonction et la génération du paramètre de cet appel. Une
entré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 de n + 1 lignes. En comparaison, un template se contentera d’une
seule 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’un template du 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’un template et d’un injecteur15 . Un template de code offre de
plus, à notre sens, un meilleur support pour l’expression des règles de codage. Dans un
objectif de génération de codes source, ou, du moins, dans une phase de développement
dédié à cet objectif, l’utilisation d’une technologie par template sera donc privilégiée à
l’utilisation d’une technologie de génération de modèles.
Néanmoins, l’utilisation d’une technologie par template n’exclut pas la considération
explicite 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 du template , à l’image
de la transmission qui est faite de ce même modèle aux transformations que nous avons
abordé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é (par
abus de langage nous parlerons dans ce cas de modèle d’application dans la suite de ce
rapport). Suivant ce type de génération, lors du processus de déploiement, la considération
de la plate-forme d’exécution peut se faire à partir de descriptions implicites ou explicites
de 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 impliquant
une 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ée
sur les concepts de l’application source et de la plate-forme d’exécution cible. La seconde
introduit dans un pivot des concepts plus abstraits, liés à un domaine commun entre toutes
les plates-formes d’exécution envisagées (le domaine de l’embarqué et du temps réel pour
15
Un injecteur permet de générer un modèle du code à partir d’un code source. Des outils tel que T CS [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éploiement
en deux transformations.
Le tableau 2.2, de la présente page, résume l’évaluation de chacune de ces pratiques. Les
contextes U ML et D SML ne sont pas distingués dans cette évaluation, car les mécanismes
de déploiement mis en œuvre pour chacune des approches y sont similaires.
sans pivot avec pivot
Ts2c M Mc Ts2pi Tpi2c M Mpi M Mc
Séparation des connaissances + + + + + +
Temps de développement + + + ++ − +
Taille − + − + − +
Réutilisation − − + + ++ −
Prise en compte de choix − +/− ?
Ts2c : transformation d’un P IM en un P SM ;
M Mc : métamodèle cible (décrivant implicitement la plate-forme) ;
Ts2pi : transformation d’un P IM en un modèle pivot ;
Tpi2c : transformation d’un modèle pivot en un P SM (dépendant de la plate-forme cible) ;
M Mp i : métamodèle pivot ;

Taille (en lignes) : −− (∼ 5.103 ), − (∼ 103 ), + (∼ 5.102 ), ++ (∼ 102 ) ;
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 approche implicite, sans pivot intermédiaire, capture les informations re-
latives à la plate-forme d’exécution dans un métamodèle. Cette approche implique que les
transformations 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 experts
de l’I DM, du domaine applicatif et des plates-formes d’exécution envisagées.
Toute considération d’une plate-forme d’exécution alternative nécessite de plus le déve-
loppement complet d’une nouvelle transformation. Pour ce qui nous concerne, il n’y a pas
eu 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 ce qui avait
été fait dans de précédentes transformations.
Parallèlement, à l’image de l’approche par description implicite dans un langage de
programmation, 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 perspective d’expression à un niveau
d’abstraction plus élevé n’est ici envisageable.
La seconde approche implicite introduit une plate-forme pivot (abstraite). Cette plate-
forme intermédiaire, elle-même implicitement décrite, permet de scinder le processus de
déploiement en deux étapes de transformation. Cette scission améliore la réutilisation de
chacune des transformations. En effet, si les concepts du domaine métier interviennent dans
toutes 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 le
domaine 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épendamment
des 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 restent
du même ordre que dans l’approche sans pivot (le nombre de concepts à manipuler étant lui
aussi du même ordre). La taille moyenne et les temps de développement des transformations
de la seconde étape sont, eux, nettement inférieurs (quelques centaines de lignes et quelques
jours respectivement). Cette simplicité de développement est due à la nature des relations
entre le pivot et les plates-formes cibles. Seules les correspondances entre les concepts
du pivot et leurs implantations dans les plates-formes concrètes sont exprimées par ces
transformations. Les relations sont alors majoritairement 1-1, par opposition aux relations
1-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 plusieurs mois pour étudier,
classer et organiser dans un métamodèle les différents concepts qu’offrent les plates-formes
d’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 des
décisions relatives aux choix de déploiement à un niveau d’abstraction plus élevé. Des
décisions prises indépendamment des plates-formes concrètes, en ne considérant que des
concepts, peuvent ainsi s’ajouter, voir se mêler, à des décisions propres à une plate-forme
précise. Dans cette optique, la décomposition d’une transformation de déploiement en deux
transformations (l’une concentrée sur les concepts du domaine, l’autre sur une plate-forme
concrè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 ces
décisions complexifient leurs considérations, leurs intégrations et leurs optimisations dans
les transformations. Une décision appliquée dans la première transformation est-elle perti-
nente et optimale sur toutes les plates-formes envisageables ? Cette considération mériterait
une 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 ce
chapitre (page 31, page 35, page 36 et page 40). Chacune de ces approches introduit les
concepts communs aux plates-formes d’exécution dans un D SML ou un profil U ML. Le
tableau 2.3, page suivante, résume leurs évaluations.
Les contextes U ML et D SML sont ici distingués. U ML fournit en effet un contexte unifié
pour la modélisation de l’application, de la plate-forme et du déploiement de l’application
sur la plate-forme. Or, bien qu’une pratique similaire soit envisageable pour les D SML dé-
diés à la modélisation conjointe de l’application et de la plate-forme d’exécution (pratique
qualifiée de « mise en relations internes » dans le tableau 2.3), lorsque cette modélisation
est disjointe, car pratiquée avec des langages différents, d’autres approches de déploiement
doivent être considérées. Parmi ces approches, l’une, qualifiée de « promotion » dans le
tableau 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 concepts

pour intégrer une représentation de l’application au modèle de la plate-forme.
Description explicite
D SML
U ML (1)
relations internes promotion intégration appli.
Tp M Mp (2) Mp Md (3) M Mp Mp Td M Mp Tpr Mp Td M Mp 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 U ML 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 ; Md : modèle de déploiement ;
M Mp : métamodèle de plate-forme d’exécution ; Td : transformation de déploiement ;
Mp : modèle d’une plate-forme d’exécution ; Tpr : transformation de promotion ;

Taille (en lignes) : −− (∼ 5.103 ), − (∼ 103 ), + (∼ 5.102 ), ++ (∼ 102 ) ;
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 U ML, a été expérimentée lors de travaux qui
ont précédé cette étude [114]. Ces travaux se sont intéressés à définir un profil U ML16 pour
la description de plates-formes d’exécution logicielles embarquées temps réel. Dans cette
approche, les connaissances relatives aux plates-formes d’exécution sont ainsi explicitement
décrites et identifiées par stéréotypage dans des modèles U ML.
A l’instar du travail effectué pour la définition d’un pivot, la conception et le dévelop-
pement du profil a nécessité du temps pour la sélection et l’organisation des concepts qu’il
identifie. Cependant, la taille de ce profil reste modeste car le contexte de modélisation dans
lequel il s’applique bénéficie de l’ensemble du langage U ML. Seuls les concepts propres
aux plates-formes d’exécution y sont donc spécifiés.
Dans cette approche, les transformations mises en œuvre s’appuient sur des déploie-
ments existants pour automatiser les portages des applications d’une plate-forme à une
autre. Ces transformations, qualifiées de transformations de portage, sont en grande partie
génériques vis-à-vis des plates-formes d’exécution (leur principe repose sur l’algorithme 2.1
pré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 à une
plate-forme ne pouvant être totale, des expérimentations supplémentaires se doivent encore
d’être menées pour affiner la place des informations relatives aux plates-formes dans le
processus de déploiement.
16
Ce profil, intégré dans le profil U ML-M ARTE, sera détaillé dans la suite de ce document.
L’identification des concepts par le profil offre également un support pour l’expression
des 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’une
plate-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 une seule 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 D SML, qualifiée de « relations internes » dans
le tableau 2.3, s’appuie sur une description conjointe de l’application et de la plate-
forme d’exécution. Le métamodèle auquel se conforme cette description regroupe donc les
connaissances relatives à l’application et au support d’exécution. Il offre de plus les concepts
né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 U ML, dans lequel
tout modèle s’exprime avec un seul langage de modélisation. Cependant, le métamodèle
utilisé 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 concepts qu’il
doit identifier. L’organisation de ces concepts, issus de différents domaines, peut également
affecter les capacités de réutilisation de chacune des composantes (les parties du modèle qui
concernent 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 des
conventions et des règles de bonnes pratiques sont respectées pour la conception et le déve-
loppement du métamodèle [32]. Un agencement des concepts de l’exécutif indépendant des
concepts 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 ceux
de 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 transformations
des approches précédentes). Les déploiements d’applications sur des plates-formes d’exé-
cution ont été manuels. A l’image de la modélisation U ML de l’approche précédente, où
seuls les portages ont été automatisés, une automatisation du portage des applications d’une
plate-forme à une autre est toutefois envisageable. Pour cela, une adaptation de l’algorithme
de portage générique (mis à contribution dans le contexte U ML) est encore à expérimenter.
En pratique, la principale limite de cette approche repose sur son rapport au métamodèle
de l’application (P IM). 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 effet
nécessaire de pouvoir l’« étendre » à la description des plates-formes d’exécution. Or, le
métamodèle de l’application est parfois imposé et issu d’une technologie qui ne permet ou
ne prévoit pas ce genre d’extension.
La seconde approche dans un contexte D SML, qualifiée de « promotion » dans le ta-
bleau 2.3, consiste à promouvoir un modèle de plate-forme d’exécution en un métamodèle.
Une application est alors déployée par génération d’un modèle conforme à ce dernier. Cette
approche 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 U ML de description de
plates-formes d’exécution, la conception et le développement du métamodèle de plate-
forme d’exécution a nécessité un investissement significatif pour la sélection et l’organi-
sation des concepts du domaine. Ce métamodèle s’est avéré fortement réutilisable, puisque
impliqué dans tous les processus de déploiement pratiqués. Sa taille est cependant nettement
supérieur à celle d’un profil U ML car l’ensemble des artefacts de modélisation nécessaires à
la description d’une plate-forme doit y être intégré (un profil U ML enrichit le langage U ML,
il bénéficie donc implicitement de tous les artefacts de modélisation U ML).
Le mécanisme de promotion d’un modèle de plate-forme d’exécution en un métamodèle
a é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 le listing 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 dans
l’approche utilisant une description implicite de plate-forme d’exécution. Leur évaluation
coïncide donc avec celle de l’approche implicite 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 de transformations
de portage. Ce processus, en grande partie générique, s’appuyait sur l’algorithme 2.2 pré-
senté dans ce chapitre, page 37. Cette approche a toutefois été abandonnée en raison de la
complexité des générateurs de transformations et de la difficulté à les maintenir.
La troisième et dernière approche dans un contexte D SML, qualifiée d’« intégration
d’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 les ressources
sont 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écanismes
permettant d’intégrer, dans un modèle de plate-forme, une représentation de l’utilisation de
ses 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 de
l’applicatif et de l’exécutif présentée précédemment. La taille du métamodèle n’est donc
pas impactée par la considération d’un domaine métier propre à l’application. Il est de plus
utilisable en tant que tel pour tout type d’application.
Cependant, à ce premier stade d’investigation, l’ensemble des artefacts de modélisa-
tion nécessaires à cette approche reste encore à identifier. Seuls les artefacts d’intégration
présentés dans ce chapitre, page 40, ont été implantés dans le métamodèle. Cette première
version laisse toutefois présager que la taille du métamodèle de plate-forme d’exécution
dé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 dans
le listing 2.3, page 39). Au bilan, chacune des composantes impliquées dans le processus de
déploiement présente donc un fort potentiel de réutilisation. Le métamodèle de plate-forme
est utilisé dans tous les déploiements, à la fois pour modéliser les plates-formes cibles et
pour offrir un support aux transformations. Les modèles de plates-formes d’exécution sont
utilisables (et donc réutilisables) quelques soit la technologie source. Enfin, une unique
transformation est mise à contribution dans tous les déploiements. Dès lors, déployer une
application sur une nouvelle plate-forme consiste à fournir, d’une part, le modèle de cette
nouvelle plate-forme et, d’autre part, les éléments de traduction manquants à la transforma-
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 stade d’investigation, des
études supplémentaires s’imposent donc pour confirmer les capacités prometteuses de cette
approche 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 un modèle
de 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 que
lorsque 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 chaque
plate-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’optimisation et la
maintenance de ces transformations mettent à contribution des compétences du domaine ap-
plicatif et du domaine des plates-formes d’exécution envisagées. Les connaissances métiers
ne 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 à un
niveau d’abstraction plus élevé, tels que des choix sur différents concepts du domaine des
plates-formes d’exécution.
Si plusieurs plates-formes cibles sont envisageables, il semble plus intéressant de mettre
en œuvre une approche par description explicite de ces plates-formes. En effet, dans le cas
d’une génération d’un modèle du code source de l’application, ce type d’approche offre
un support pour la mise en œuvre de transformations en partie génériques vis-à-vis des
plates-formes d’exécution. De même, dans le cas d’une génération d’un modèle de plus haut
niveau 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 ce
type d’approche centralisent les décisions relatives aux choix de déploiements dans une
seule transformation, que ces choix portent sur des mécanismes internes à une plate-forme
d’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 contextes
G PML et D SML. 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évelopper des composantes
matures à ces approches et confirmer ces résultats.
Nous proposons de mener cette étude dans un contexte D SML.
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, selon
qu’elles génèrent un modèle de code source ou un modèle de l’application à un niveau
d’abstraction plus élevé. Or, la considération de la plate-forme d’exécution intervient dans
une phase que nous avons qualifiée de phase de déploiement. Cette phase, telle que nous
l’envisageons, s’exerce en amont de la phase d’implantation dans laquelle interviennent les
techniques 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épendants
de 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 haut
niveau d’abstraction, celle que nous avons qualifiée d’« intégration d’application » semble
la 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’application
en séparant les domaines de l’application et du support d’exécution, contrairement à une
description conjointe de l’application et de la plate-forme qui regroupe les concepts de ces
domaines dans un seul métamodèle.
Dans la suite de cette étude, nous nous intéressons donc, en particulier, à cette approche
qualifiée d’« intégration d’application ».
Vers un D SML de description de plates-formes d’exécution

L’approfondissement de cette approche nécessite de mettre en œuvre un langage dédié
à la description des plates-formes d’exécution de notre domaine d’intérêt (les systèmes
d’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 par
les plates-formes. Le métamodèle du langage à mettre en œuvre se doit donc d’identifier les
ressources et les services communs aux différentes plates-formes du domaine.
Dans cet objectif, parmi les technologies actuellement disponibles, toutes approches
confondues (G PML et D SML), le profil U ML-M ARTE, au travers du package S RM (Soft-
ware Resource Modeling), définit l’ensemble le plus adapté de concepts métiers pour la
modélisation de plates-formes d’exécution logicielles embarquées temps réel17 .
Le modèle de domaine d’U ML-M ARTE offre de plus, au delà d’un contexte U ML, un
support pour la définition et l’implantation de D SML. En effet, bien que l’implantation stan-
dard d’U ML-M ARTE soit un profil U ML, sa conception a été conduite sur la base d’un
modèle de domaine qui spécifie les concepts utiles pour modéliser le domaine métier (les
systèmes embarqués temps réel). Le profil U ML-M ARTE est une implantation de ce modèle
de domaine. Une implantation alternative, dans un D SML, est donc également envisageable.
Nous proposons donc, dans la suite de cette étude, de nous appuyer sur le package S RM
du profil U ML-M ARTE pour concevoir et implanter un D SML 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 seront
modélisées à un niveau d’abstraction plus élevé que celui d’un code source ou d’un modèle
de code source, indépendamment de toute technique ou de toute technologie de codage.
L’étude se focalisera sur un contexte de modélisation D SML. Un D SML de description de
plates-formes d’exécution temps réel embarquées sera donc proposé, inspiré du modèle de
domaine du package S RM du profil U ML-M ARTE.
17
Ce 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’art
et 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 D SML, avant d’introduire, dans le second chapitre, un processus de déploiements
d’applications axé sur ce D SML. Ce second chapitre se concentre en particulier sur l’intro-
duction, dans le D SML, 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éploiement
lors de ce type d’intégration. Un dernier chapitre présente finalement les résultats que nous
avons obtenus avec cette approche en la comparant à nouveau aux approches par description
implicite des plates-formes.
Deuxième partie
Considération explicite d’une

plate-forme d’exécution
Un langage de description de plate-forme
3
d’exécution
Sommaire
3.1 Le modèle de domaine du package S RM d’U ML -M ARTE . . . . . . 59
3.1.1 Le motif ressource/service appliqué au logiciel . . . . . . . . . 59
3.1.2 Les ressources et les services de S RM . . . . . . . . . . . . . . 60
3.2 Implantation du modèle de domaine dans un D SML . . . . . . . . . 63
3.2.1 Modélisation des ressources et des services . . . . . . . . . . . 63
3.2.2 Les ressources logicielles . . . . . . . . . . . . . . . . . . . . . 64
3.2.3 Les éléments typés . . . . . . . . . . . . . . . . . . . . . . . . 64
3.2.4 Les types de données . . . . . . . . . . . . . . . . . . . . . . . 65
3.2.5 Les instances de ressources . . . . . . . . . . . . . . . . . . . . 65
3.2.6 Les routines et les points d’entrée . . . . . . . . . . . . . . . . 67
3.3 Artefacts de modélisation . . . . . . . . . . . . . . . . . . . . . . . . 68
3.3.1 L’héritage de ressource . . . . . . . . . . . . . . . . . . . . . . 68
3.3.2 La composition de services . . . . . . . . . . . . . . . . . . . . 69
3.3.3 Prototypes de conception . . . . . . . . . . . . . . . . . . . . . 69
3.4 Exemple d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.5 Synthèse et résultats sur le langage proposé . . . . . . . . . . . . . . 74
ans le domaine du temps réel et de l’embarqué, le profil U ML-M ARTE identifie, au

D travers de son package S RM, un ensemble de concepts utiles à la description de plates-
formes d’exécution logicielles. Le package S RM spécifie ces concepts et leurs relations dans
un modèle de domaine qu’il implante ensuite dans un profil U ML.
Nous proposons dans ce chapitre une implantation alternative du modèle de domaine de
S RM dans un D SML. Ce langage, présenté sous le nom de RTEPML (Real Time Embedded
Platform Modeling Language), identifie, d’une part, les concepts du domaine (telles que
les notions d’exécution concurrente ou d’alarme) et fournit, d’autre part, des artefacts de
modé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 de
domaine de S RM et son implantation dans RTEPML. La troisième section se focalise sur les
artefacts de modélisation qu’offre le langage. Un exemple de modélisation de plate-forme
avec RTEPML est ensuite donné dans la quatrième section avant de conclure sur le langage
proposé dans la dernière section.
3.1. Le modèle de domaine du package S RM d’U ML -M ARTE 59
3.1 Le modèle de domaine du package S RM d’U ML -M ARTE

3.1.1 Le motif ressource/service appliqué au logiciel
Dans le cadre des profils standards S PT (Schedulability, Performance and Time) [85]
puis U ML-M ARTE [89] dédiés à la conception d’applications temps réel, l’O MG propose
un 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ées
par des propriétés non-fonctionnelles.
F IG . 3.1: Extrait du motif ressource/service du profil U ML-M ARTE [89].
Dans le contexte d’une modélisation de plate-forme d’exécution, la notion de ressource

représente les types de la plate-forme. Ces types interfacent des mécanismes fournis par la
plate-forme. Leurs capacités d’exécution et d’instanciation sont généralement limitées. Les
services des ressources sont les traitements offerts par la plate-forme.
Sur la base du motif « ressource/service », le package S RM du profil U ML-M ARTE 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).
F IG . 3.2: Extrait du modèle de domaine de S RM : 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 entre la classe SwResource et
les classes ResourceProperty et ResourceService de 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’avantage
de 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 à un
service externe à une ressource.
1
Le profil U ML-M ARTE 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 S RM

Le package S RM 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, les
ressources d’interaction et les ressources de gestion. Cette partie présente succinctement
les 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 des
services 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 la
gestion des périphériques. La description détaillée de chacune des familles est disponible
dans le standard [89] et dans l’étude qui a conduit à la définition de S RM [114].
Les ressources d’exécution concurrentes2 (SwConcurrentResource) spécialisent le

concept de ressource logicielle (figure 3.3). Ces ressources fournissent un contexte pour
l’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 par
un ordonnanceur ou par une autre ressource de la plate-forme (SwSchedulableResource) et
celles activées suite à une interruption (InterruptResource). Parmi ces dernières, les alarmes
se distinguent par leur activation sur une valeur de référence fournie par 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 et
terminer 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 ressources
d’interruption ne sont pas représentés sur la figure 3.3. Certains sont introduits dans la
suite de ce rapport ou présents dans l’implantion du modèle de domaine disponible en an-
nexe (page 151).
F IG . 3.3: Extrait du modèle de domaine de S RM : les ressources d’exécution concurrentes [89].

2
Par 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 du package S RM d’U ML -M ARTE 61
Les ressources d’exécution concurrentes peuvent être confinées dans un espace mé-
moire. Dans S RM, 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 ressources
concurrentes. 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 de
l’espace mémoire (forkServices, exitServices).
F IG . 3.4: Extrait du modèle de domaine de S RM : les partitions mémoires [89].
Les ressources d’interaction (SwInteractionResource) spécialisent également le

concept de ressource logicielle (figure 3.5). Ces ressources fournissent aux exécutions
concurrentes 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 de
synchronisation (SwSynchronizationResource), qui contrôlent les flots d’exécution, et les
ressources 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 de
mé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ées
en file, en pile ou par valeurs de priorité.
F IG . 3.5: Extrait du modèle de domaine de S RM : 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 prendre ou libérer la zone
qu’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 P IP, P CP 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.
F IG . 3.6: Extrait du modèle de domaine de S RM : les ressources de synchronisation [89].
Les ressources de communication (SwCommunicationResource, figure 3.7) identifient

deux 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émoire
partagé entre plusieurs ressources d’exécution concurrentes.
La communication par message se fait par envoi et réception de messages. Un message
peut être mémorisé dans une file d’attente, déposé dans un buffer (ou tableau noir, black-
board) ou transmis via un mécanisme similaire au pipe P OSIX. Les messages mémorisés
sont organisés en file, en pile ou par valeurs de priorité.
F IG . 3.7: Extrait du modèle de domaine de S RM : les ressources de communication [89].
Les ressources d’interaction sont finalement rendues accessibles depuis les ressources
d’exécution concurrentes (figure 3.8).
F IG . 3.8: Extrait du modèle de domaine de S RM : les interactions des ressources concurrentes [89].
3.2. Implantation du modèle de domaine dans un D SML 63
3.2 Implantation du modèle de domaine dans un D SML

L’implantation d’un modèle de domaine dans un D SML consiste à développer un méta-
modèle, avec une technologie de méta-métamodélisation, dont les concepts et les relations
entre ces concepts correspondent au modèle de domaine. Cette partie présente l’implanta-
tion du modèle de domaine de S RM dans RTEPML.
Le package S RM s’intègre toutefois dans un contexte de modélisation U ML. Son modèle
de domaine se réfère donc à des concepts externes à S RM, issus du langage U ML ou d’autres
packages du profil U ML-M ARTE. Or, dans un contexte D SML, la nature même du langage
nécessite de définir tous les concepts dans un même métamodèle. L’implantation du modèle
de domaine de S RM, sous la forme d’un D SML, nécessite donc d’introduire dans le D SML
les concepts de S RM et les concepts « externes » auxquels S RM se réfère.
Les deux premières parties de cette section présentent les principes d’implantation du
modèle de domaine de S RM dans RTEPML. Les points particuliers concernant l’introduction
de 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 S RM, 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 qui
offrent des services paramétrables et peuvent être quantifiées ou qualifiées par des propriétés
(figure 3.9).
F IG . 3.9: Extrait du D SML 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’attribut name de modélisation de ces élé-
ments (alors qualifiés d’éléments nommés [32], figure 3.10) permet de les identifier dans
les modèles. C’est par cet attribut que les éléments d’une plate-forme sont associés aux
concepts métiers du langage.
F IG . 3.10: Extrait du D SML 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 S RM
(figure 3.11). N’ayant aucune vocation à représenter d’autres types de ressource, telles que
des ressources matérielles, le préfixe Sw n’est pas retranscrit dans cette implantation.
F IG . 3.11: Extrait du D SML RTEPML : hiérarchie des ressources.
L’identification des rôles affectés aux services et aux propriétés d’une ressource, par
référence, est également conservée dans RTEPML. La figure 3.12 illustre ce mécanisme par
les associations d’une ressource à ses services de création, d’initialisation et de destruction.
F IG . 3.12: Extrait du D SML RTEPML : affectation des rôles.
3.2.3 Les éléments typés

Dans le modèle de domaine de S RM, les notions de propriété d’une ressource et de
paramètre d’un service spécialisent la notion d’élément typé U ML (TypedElement) [89].
Parallèlement, le concept de ressource spécialise celui de type. Ces concepts de typage,
bien qu’externes à S RM, nécessitent d’être retranscrits dans l’implantation qui en est faite
dans RTEPML.
Un nouveau concept de « type » aurait pu être introduit dans le D SML. Cependant, le
concept 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 la plate-forme
d’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é par
une ressource de la plate-forme. La figure 3.13 illustre par exemple le typage des propriétés
d’une ressource et des paramètres d’un service.
F IG . 3.13: Extrait du D SML 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 des types de don-
nées natifs à une plate-forme d’exécution. Les types de données définissent les genres de
contenu des données et donc l’interprétation qui est faite de ces données sur une plate-forme
d’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és
directement 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 est
renseigné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 type String est é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 des
types énumérés ou composés. Cette version du langage se contente de l’approche la plus
simple que nous ayons identifiée.
F IG . 3.14: Extrait du D SML 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 S RM, 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écution
s’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éfinies dans une plate-
forme. La notion d’instance de ressource est, par exemple, également mise à contribution
pour 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.
F IG . 3.15: Extrait du D SML 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 aux

notions de type et d’élément typé. La relation entre une instance et la ressource qui la
type diffère de la relation d’instanciation de l’espace technique orienté-objet. Dans le cadre
orienté-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 mise
en œuvre de framework de modélisation en langage objet. Les modeleurs actuels, tels que
ceux basés sur le framework E MF, 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 se
conforme. Dans RTEPML la notion d’instance de ressource est interne à l’espace technique
des modèles. Une instance de ressource est une entité de la plate-forme utilisable en tant
que 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 des
propriétés associées aux ressources qui les typent (figure 3.16). Pour cela, les instances de
ressources possèdent des propriétés (ResourceInstanceProperty) qui renseignent ces valeurs
sous forme d’un littéral (pour les types de données natifs à la plate-forme) ou sous forme
d’une référence vers une instance de ressource.
F IG . 3.16: Extrait du D SML 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éliser

des 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 sous
forme de littéraux (pour les types de données natifs à la plate-forme) ou sous forme de
références vers des instances de ressources. Les paramètres d’un appel sont associés aux
paramètres du service appelé.
F IG . 3.17: Extrait du D SML 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 le
chapitre 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’un
appel de service reste néanmoins accessible au travers de toute représentation d’instance de
ressource, y compris celles qui sont prédéfinies dans une plate-forme d’exécution.
Remarque : Le choix d’une représentation des appels de services accessibles à toute
instance de ressource est motivé par une volonté d’uniformisation du langage autour des
concepts de ressource, de service et d’instance de ressource. En effet, les appels de services
sont 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 en
compte 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 de service au niveau des
instances 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 en
tant que ressource d’une plate-forme d’exécution (figure 3.18). Ce type de ressource offre
un ou des services d’appel permettant d’invoquer les routines (callRoutineServices) .
Cependant, contrairement à la modélisation proposée par S RM, dans RTEPML un point
d’entrée d’une ressource d’exécution n’est pas une relation directe entre une ressource
d’exécution et un traitement fourni sous forme de routine. Le rôle de point d’entrée est
ici affecté à une propriété dont le type renseigne le traitement. Ce traitement peut alors
correspondre à une routine.
F IG . 3.18: Extrait du D SML RTEPML : les routines et les points d’entrée.
La représentation des points d’entrée d’une ressource concurrente est permissive dans
RTEPML. En effet, toute ressource peut, en pratique, représenter un traitement associé à un
point d’entrée. Toutefois, cette permissivité peut être limitée par l’expression de contraintes
sur le métamodèle (par exemple des contraintes O CL).
Le choix d’une représentation des points d’entrée sous forme de propriétés trouve son
origine 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 valeurs
des propriétés peuvent être renseignées. Cependant, l’utilisation d’une relation directe entre
deux ressources ne permet pas de renseigner ces valeurs au niveau des instances. Pour cela
un mécanisme similaire à celui mis en place pour les propriétés devrait être instauré. Pour
permettre aux instances des ressources concurrentes de renseigner leurs points d’entrée sans
introduire 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 D SML 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 pour
dé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 nous
avons jugés nécessaires à la modélisation des plates-formes d’exécution. Ces artefacts
concernent 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 de
modé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’une
plate-forme (figure 3.19). Une ressource peut être abstraite (isAbstract) et/ou hériter d’une
autre ressource (supertype).
F IG . 3.19: Extrait du D SML 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 supporter
toutes les actions pouvant être effectuées sur les éléments de ce type. Tandis que l’héritage
de 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. Cet
hé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écanisme
syntaxique 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 fut
mentionné 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 des
services 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 composition d’autres
services.
Le service ChainTask d’une tâche O SEK /V DX illustre l’intérêt d’une telle notion. Dans
une séquence atomique, ce service active une tâche et termine l’exécution de la tâche invo-
catrice. Dans le respect du modèle de domaine de S RM, ce service se compose des services
activateService et terminateService offerts par une ressource ordonnançable (SwSchedula-
bleResource, cf. Les ressources et les services de S RM, page 60).
Une modélisation possible de ce service consisterait à lui affecter les rôles activateSer-
vice et terminateService. Cependant, contrairement à ce que stipule la norme O SEK /V DX,
l’ordre d’exécution de l’activation et de la terminaison ne serait alors plus pré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é et
atomique (figure 3.20).
F IG . 3.20: Extrait du D SML RTEPML : la composition de services.
Remarque : Les services qui composent un « service composé » n’étant pas 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 S RM, cf. Le modèle de domaine
du package S RM d’U ML-M ARTE, page 59) couvrent un ensemble de concepts que les
plates-formes d’exécution peuvent fournir sous la forme d’une ressource unique ou sous
la 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’O SEK /V DX se conforme,
par exemple, au concept d’alarme de RTEPML (cf. Les ressources et les services de S RM,
page 60). Cependant, dans une plate-forme d’exécution, une ressource unique n’implante
pas forcément chaque concept identifié. L’absence de ressource dédiée à un concept ne
signifie 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, O SEK /V DX ne fournit
pas de ressource dédiée à l’exécution périodique d’un traitement. Une tâche périodique
O SEK /V DX peut néanmoins se concrétiser par l’agencement d’une tâche, d’une alarme et
d’un compteur. Un modèle de plate-forme d’exécution doit donc pouvoir décrire ce type
de 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 Pattern
Prototype) [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ère
instance est créée puis clonée. Les clones de l’instance sont modifiés de faç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 et d’adaptation
sera reprise lors d’un déploiement d’application. Pour ce qui concerne la description des
plates-formes d’exécution, l’idée principale est de modéliser un agencement de ressources
qui 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 un
agencement 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âche
O SEK /V DX, 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 ressources
telles qu’elles seront mises en œuvre lors de l’utilisation de la plate-forme3 . Toute précision
que l’on souhaite apporter sur les propriétés des ressources s’exprime alors directement
sur les instances du prototype. Cette solution s’apparente à l’utilisation des diagrammes
de collaboration ou des classes structurées qui décrivent également des instances mises en
relation, dans un contexte U ML [114].
La figure 3.21 représente le mécanisme de description des prototypes de conception
introduit dans RTEPML.
F IG . 3.21: Extrait du D SML RTEPML : les prototypes de conception.
Un prototype se compose d’instances de ressources (PrototypeResourceInstance) dont

l’une d’elles joue le rôle d’instance maîtresse. Toute référence à un élément mis en œuvre
par 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 par des ressources de
la 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 la type. Une
instance « 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 associations
binaires (PrototypeResourceInstanceAssociation).
3
La mise en œuvre d’une ressource par instanciation sera détaillée dans le chapitre 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 aux
propriétés (cf. Les instances de ressources, page 65). Il est ainsi possible de fixer dans un
prototype les valeurs de certaines propriétés des instances impliquées. Le mé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érente
de 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 par
une 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 O SEK /V DX nécessite, par exemple, une instance
d’alarme. Cette instance d’alarme est bien entendu utilisable par l’application, mais elle est
diffé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 pour
les propriétés et les services d’un concept, aux propriétés et aux services des éléments
qui constituent le prototype. Dans l’exemple d’un prototype qui décrit l’agencement
d’une tâche, d’une alarme et d’un compteur pour mettre en œuvre une tâche périodique
O SEK /V DX, la tâche possède des propriétés dont les rôles correspondent, entre autres, à sa
priorité et à sa période d’activation. Ces rôles doivent donc être reportés (ou distribués) sur
les propriétés des éléments du prototype.
RTEPML propose d’exprimer cette distribution par de nouveaux rôles attribués aux ins-
tances de ressources qui composent un prototype de conception. Pour cela, toute association
symbolisant 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 associations prototypePriorityElements et prototypePeriodElements
permettent de transmettre les rôles de priorité et de période à des propriétés d’instances de
ressources d’un prototype. De même, les associations prototypeActivateServices et prototy-
peSuspendServices permettent de transmettre des rôles de service.
F IG . 3.22: Extrait du D SML 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 dans
un prototype, accorde le rôle X, 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 type
l’instance. Un exemple de distribution des rôles est donné dans la section suivante.
4
La 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 description de la plate-
forme d’exécution NXT O SEK [82] avec RTEPML. La plate-forme NXT O SEK implante une
partie du standard O SEK /V DX.
L’exemple proposé ne décrit pas la plate-forme dans son ensemble. Son objectif est
d’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 pas l’objet d’une attention
particulière dans ce rapport. Celles-ci sont considérées interchangeables en fonction des
besoins et de la culture des utilisateurs. De plus, seule la syntaxe abstraite est réellement
mise à contribution pour la considération explicite des plates-formes d’exécution dans le
processus de déploiement que vise cette étude.
L’exemple du listing 3.1 modélise quatre concepts définis par le standard O SEK /V DX :
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-forme NXT O SEK, est
également précisé (ligne 5).
Une ressource Counter est modélisée conformément à un compteur RTEPML (Timer,
ligne 8). Cette ressource possède une propriété ticksPerBase de type entier. Le rôle de cette
propriété correspond à une opération de pré-division par rapport aux « tics » d’une source
(par exemple, une horloge matérielle). A ticksPerBase impulsions de la source correspond
une impulsion d’avancement du compteur.
La plate-forme NXT O SEK fournit un compteur prédéfini SysTimerCnt. Ce compteur est
alors modélisé par une instance de la ressource Counter (ligne 14). La valeur de la propriété
ticksPerBase est fixée dans le respect des caractéristiques de la plate-forme.
Une ressource OsekAlarm est décrite conformément à une alarme RTEPML (Alarm,
ligne 20). Cette ressource possède une propriété cycletime de type entier. Le rôle de cette
propriété correspond au cycle de déclenchement de l’alarme (Period). Un compteur fournit
une valeur de référence à une alarme O SEK /V DX. Une propriété de la ressource permet
donc de référencer ce compteur (counter).
Les activations et les exécutions d’une tâche O SEK /V DX étant gérées par un ordonnan-
ceur, une tâche O SEK /V DX est identifiée comme une ressource ordonnançable (Shedulable-
Resource). Tout type de tâche O SEK /V DX (AperiodicTask, PeriodicTask) est donc modélisé
conformément à une ShedulableResource. Dans cet exemple, les concepts de tâches apério-
diques et périodiques (lignes 37 et 42) héritent d’un concept abstrait de tâche pour lequel
les propriétés et les services que précise le standard O SEK /V DX 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 O SEK /V DX (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 O SEK /V DX
(T1 de type Task, dont le type d’activation n’est pas défini), (b) une instance de ressource
typée par une alarme (A1 de type OsekAlarm, 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-forme NXT O SEK (C1
qui référence SysTimerCnt) 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 platform

2 Platform nxtOSEK {
3
4 -- Integer native type
5 IntegerType Integer [ 16 ]
6
7 -- OSEK/VDX Counter resource
8 Timer Counter (
9 Property Duration ticksPerBase : Integer
10 ...
11 )
12
13 -- NXT-OSEK SysTimerCnt predefined counter
14 Counter SysTimerCnt (
15 ticksPerBase = ’1’
16 ...
17 )
18
19 -- OSEK/VDX Alarm
20 Alarm OsekAlarm (
21 Property Period cycletime : Integer
22 Property ConnectedTimer counter : Counter
23 ...
24 )
25
26 -- OSEK/VDX Task
27 SchedulableResource Task [ preemptable ] abstract (
28 Property Priority priority : Integer
29 Property Deadline deadline : Integer
30 ...
31 Service Activate ActivateTask
32 Service Terminate TerminateTask
33 ...
34 )
35
36 -- OSEK/VDX Aperiodic Task
37 SchedulableResource AperiodicTask [ Aperiodic ] extends Task (
38 ...
39 )
40
41 -- OSEk/VDX Periodic Task
42 SchedulableResource PeriodicTask [ Periodic ] extends Task (
43 Prototype {
44 Task T1
45 OsekAlarm A1 ( counter = C1 )
46 Instance SysTimerCnt C1
47 Association A1 -[ activate ]- T1
48 Master T1
49 }
50 -- Priority InPrototype T1 :: priority
51 Priority InPrototype T1
52 -- Period InPrototype A1 :: cycletime
53 Period InPrototype A1
54 ...
55 )
56
57 -- Synchronization Resource
58 MutualExclusion Resource [ ImediatePCP ] (
59 Service Acquire GetResource
60 Service Release ReleaseResource
61 ...
62 )
63
64 -- OSEK/VDX predefined resource for processor
65 Resource RES_SCHEDULER (
66 )
67 }
Listing 3.1: Description de la plate-forme NXTO SEK 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é qui
possè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 de
dé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és
ou des services (rôles initiaux, issus de S RM). Le modèle du listing 3.1 spécifie par exemple,
dans des commentaires (lignes 50 et 52), les expressions équivalentes aux distributions des
rôles qu’ils précèdent, en stipulant les propriétés visées. Ce mécanisme permet d’affecter
un rôle, dans un prototype, à une propriété ou à un service pour lequel ce rôle n’est pas
identifié à l’identique.
Enfin, une ressource Resource (au sens O SEK /V DX) est modélisée conformément à une
ressource d’exclusion mutuelle RTEPML (MutualExclusion, ligne 58). Une ressource (au
sens O SEK /V DX) permet de coordonner les accès concurrents. Elle offre des services pour
prendre ou pour libérer la zone qu’elle protège (GetResource et ReleaseResource). Les accès
sont régis par le protocole P CP que prévoit le standard (ImmediatPCP).
Le standard O SEK /V DX 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 qui
la 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 de
RTEPML, implante le modèle de domaine du package S RM du profil U ML-M ARTE. Ce mo-
dèle de domaine, issu de travaux qui ont précédés cette étude, offre un ensemble de concepts
mé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 S RM, RTEPML s’appuie sur le motif ressource/-
service pour la description des ressources, des propriétés et des services offerts par une
plate-forme. La hiérarchie des ressources logicielles de RTEPML reprend celle de S RM.
En raison de la nature même d’un D SML, RTEPML définit toutefois des concepts supplé-
mentaires, « externes » à S RM, nécessaires à la modélisation des plates-formes d’exécution.
Ces concepts concernent les types de données natifs à la plate-forme et les instances de
ressources, 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 conception
sont ainsi disponibles.
La description de prototypes de conception repose sur un agencement d’instances de
ressources. Cette agencement décrit la mise en œuvre d’un concept avec des instances de
ressources typées par d’autres concepts. Dans cette version du langage, la mise en relation
des instances, au sein d’un prototype, peuvent s’appuyer sur les propriétés des instances ou
des appels de services. Des associations binaires identifiées par un nom ont également été
introduites. Dans des versions plus élaborées, des cardinalités ou des nuances sémantiques
dans les types d’associations pourront être précisées. Ces versions ne 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 partie du 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 pour
valider les concepts retenus dans cette première version. La suite de cette section présente
les 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 U ML du package S RM et
RTEPML) a été appliquée pour décrire les librairies O SEK /V DX et A RINC -653 (l’utilisation
du package S RM a été évalué dans le cadre des travaux qui ont conduit à sa définition [114]).
Dans le cadre du profil U ML, les librairies ont d’abord été modélisées par des diagrammes
de classes. Leurs éléments (classes, méthodes, attributs et relations) ont ensuite été stéréo-
typés par les concepts de S RM. Dans le cadre de cette étude, ces mêmes librairies ont été
décrites avec RTEPML.
Le profil U ML et RTEPML ont ainsi permis de décrire 70% des ressources offertes par
la plate-forme O SEK /V DX et 80% de celles offertes par la plate-forme A RINC -653. Ces
ré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 et
services des librairies directement liés à ces concepts absents du modèle du domaine, nous
parvenons à une couverture exhaustive. Ce constat incite à valider la pertinence du modèle
de domaine quant à son pouvoir d’expression. Afin d’obtenir une meilleure couverture, un
enrichissement 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 U ML ou un D SML), chacun étant, par exemple, dédié à
une considération donnée. Ainsi, dans U ML-M ARTE, un package est dédié aux mécanismes
de temps. Cette pluralité permet notamment de réutiliser ces éléments dans d’autres profils
ou dans d’autres D SML. La problématique de réutilisation de parties de métamodéles, qui
rejoint 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 D SML

Nous avons identifié deux grands types de différences dans l’implantation du modèle de
domaine entre l’approche par profil U ML et par D SML.
Le premier type de différence vient de la nature même des D SML : tous les concepts
et les artefacts de modélisation du langage doivent être définis. Par exemple, dans le cadre
d’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 un
contexte U ML, la modélisation bénéficie de l’ensemble du langage, alors qu’un D SML se
doit d’offrir chacun de ces concepts. Cette différence est tout de même à nuancer, il serait
en effet possible de réutiliser certains concepts ou certains artefacts présents dans d’autres
D SML. 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 par
stéréotypage d’U ML. 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éfinis
par les stéréotypes, est alors multiple. L’identification des éléments avec un D SML repose
par contre sur une relation de conformité implantée actuellement, dans les outils tel qu’E MF,
par la relation d’instanciation Java. La relation de conformité est alors simple.
La modélisation d’une partition A RINC -653 permet d’illustrer cette différence. Les par-
titions A RINC -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 domaine
initial, une partition peut être identifiée via deux stéréotypes du profil U ML. L’un pour l’as-
pect temporel (tel que SchedulableResource), l’autre pour l’aspect spatial (tel que Memory-
Partition qui décrit une partition mémoire). Parallèlement, la modélisation d’une partition
A RINC -653, avec RTEPML, ne peut se conformer à l’équivalent de ces stéréotypes dans le
D SML. Cette modélisation nécessite donc d’introduire dans le D SML, soit un concept mixte
de partition mémoire ordonnançable, soit des notions de ségrégations temporelles au sein
du concept de partition mémoire existant5 .
Ces différences nous permettent de constater que la traduction du modèle de domaine
dans un profil ou dans un D SML 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 pour
mieux identifier ces différences.
5
Cette 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.
Un processus de déploiement sur une
4
plate-forme explicitement décrite
Sommaire
4.1 Intégration d’applications sur une plate-forme . . . . . . . . . . . . 79
4.2 Principe d’un déploiement . . . . . . . . . . . . . . . . . . . . . . . 80
4.2.1 Un cas simple de transformation de déploiement . . . . . . . . 80
4.2.2 Première synthèse . . . . . . . . . . . . . . . . . . . . . . . . 84
4.3 Transformations de déploiement . . . . . . . . . . . . . . . . . . . . 85
4.3.1 Affiner les critères sur les concepts . . . . . . . . . . . . . . . . 85
4.3.2 Relations de correspondance entre les concepts . . . . . . . . . 87
4.3.3 Mise à disposition de ressources par une plate-forme . . . . . . 90
4.3.4 Une mise en œuvre est-elle possible ? . . . . . . . . . . . . . . 91
4.3.5 Avec ou sans prototype de conception . . . . . . . . . . . . . . 93
4.3.6 Renseigner les propriétés . . . . . . . . . . . . . . . . . . . . . 97
4.3.7 Gestion des appels de services . . . . . . . . . . . . . . . . . . 105
4.4 Développement d’une transformation de déploiement . . . . . . . . 110
4.4.1 Organisation d’une transformation de déploiement . . . . . . . 110
4.4.2 Contraintes sur la technologie de transformation . . . . . . . . 113
4.4.3 Génération des règles de déploiement . . . . . . . . . . . . . . 114
4.4.4 Assistance au développement des fonctions . . . . . . . . . . . 117
4.5 Choix de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . 118
4.5.1 Identification des choix . . . . . . . . . . . . . . . . . . . . . . 118
4.5.2 Prise de décision . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.5.3 Modélisation des décisions . . . . . . . . . . . . . . . . . . . . 120
4.6 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
e chapitre propose un processus de déploiement d’applications sur des plates-formes

C d’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 des
modèles de plates-formes décrits avec RTEPML.
Ce chapitre s’organise en six sections. Les deux premières introduisent successivement
le principe d’une intégration d’application dans une plate-forme d’exécution et le principe
d’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 processus
pour le développement d’une telle transformation. Enfin, la cinquième section adapte le pro-
cessus pour intégrer des décisions relatives à des choix de déploiement. La dernière section
conclue 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), plusieurs
approches 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’une description explicite
de 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 confirmer
ce potentiel, ce chapitre propose d’approfondir cette approche avec le langage RTEPML dé-
fini dans le chapitre 3.
L’idée sous-jacente d’une « intégration d’applications » consiste à générer un modèle
de 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 travers
des instances de ressources mises à contribution pour son exécution. Comme le modèle
généré représente la plate-forme d’exécution et l’utilisation qui est faite de ses ressources
pour exécuter l’application, le processus de déploiement aboutit à un modèle d’application
spécifique à une plate-forme (ou P SM, Platform Specific Model) conforme au métamodèle
de plate-forme d’exécution (figure 4.1).
F IG . 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é, ce
mécanisme repose sur le principe d’instanciation des ressources d’une plate-forme. Aucun
concept 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 concept
d’association accompagne ces instances (ResourceInstanceAssociation), pour les mettre en
relation, entre elles ou avec des instances de ressources prédéfinies sur une plate-forme.
F IG . 4.2: Extrait du D SML 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 » avec
le cas le plus simple que nous pouvons rencontrer. Dans cet exemple, une application de
robotique constituée d’une seule activité est déployée par transformation de modèle sur
une plate-forme O SEK /V DX. Cette plate-forme est explicitement décrite avec RTEPML. Les
modèles de l’application (P IM) et de la plate-forme (P DM) sont alors transformés en un
modèle de système spécifique à la plate-forme (P SM). Le modèle résultant correspond à la
plate-forme d’exécution cible dont certaines ressources sont instanciées en vue d’exécuter
l’application. Dans cet exemple, une tâche O SEK /V DX de priorité 2 (nommée HelloWorld)
est instanciée pour offrir un contexte d’exécution sur la plate-forme.
F IG . 4.3: Déploiement d’une application de robotique sur une plate-forme O SEK /V DX.
La transformation de déploiement Robot2RTEPML de la figure 4.3 établit la correspon-

dance entre les éléments des modèles sources (P IM et P DM) et les éléments du modèle
cible (P SM). Pour cela, une partie 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 et les instances de ressources de la plate-forme d’exécution. Par
exemple, la règle ATL Activity2SchedulableResourceInstance, du listing 4.1, stipule que
tout élément conforme à une activité, 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!Activity
3 to
4 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-forme qui les typent. La ligne 6
du listing 4.1 déclare, par exemple, que la ressource qui type l’instance générée est conforme
à une SchedulableResource. 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 de tâche
HelloWorld est ainsi associée à la ressource Task (ce qui se matérialise par une flèche en
pointillé, suivant la convention graphique adoptée).
De même, les valeurs de propriétés affectées à une instance de ressource sont associées
aux propriétés de la ressource qui type l’instance. La ligne 11 du listing 4.1 précise, par
exemple, que la valeur affectée se réfère à la propriété dont le rôle concerne la priorité.
La valeur 2 de l’instance de tâche HelloWorld, dans la figure 4.3, est ainsi associée à la
propriété priority de la ressource Task (ce qui se matérialise également par une flèche en
pointillé, suivant la convention graphique adoptée).
Pour des raisons didactiques, le listing de l’exemple ne comporte pas tout le code de
la transformation. La partie chargée de dupliquer le modèle de la plate-forme n’est, par
exemple, pas présentée. Sa mise en œuvre peut être assurée par une fonctionnalité intégrée
dans la technologie de transformation ou, comme nous allons l’aborder, par un ensemble de
rè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 en
pratique 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 venons
d’introduire peut se résumer par l’algorithme 4.1.
Algorithme 4.1 : Principe d’une transformation de déploiement
Métamodèles sources :
M Ma : le métamodèle de l’application
M Mp : le métamodèle de plate-forme d’exécution (RTEPML)
Métamodèle cible :
début
// Dupliquer le modèle de la plate-forme
pour chaque classe mp ∈ M Mp faire
correspondance avec mp // (identité)
// Intégrer l’application
pour chaque classe ma ∈ M Ma faire
ruleConcept2ResourceInstance(ma , mp )
avec une classe mp ∈ M Mp
fin
L’algorithme 4.1 se déroule en deux phases. La première consiste à dupliquer le modèle

de la plate-forme cible. Elle se compose de règles qui mettent en correspondance les classes
du métamodèle de plate-forme d’exécution avec elles-mêmes (identité). La seconde fait
correspondre chaque concept « applicatif » avec un concept « exécutif ». Ces concepts sont
respectivement identifiés par une classe ma dans le métamodèle de l’application et une
classe mp dans le métamodèle de plate-forme d’exécution (RTEPML).
1
Si 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 de

transformation ruleConcept2ResourceInstance (également qualifiée de règle de correspon-
dance). L’algorithme 4.2 en donne le principe.
Une règle ruleConcept2ResourceInstance prend comme paramètres un concept appli-
catif et le concept exécutif mis en correspondance (respectivement identifiés par les classes
ma et mp ). Pour chaque élément du modèle de l’application conforme à ma , cette règle
génère alors une instance de ressource (ApplicationResourceInstance) typée par une res-
source de la plate-forme conforme à mp . La classe ma constitue le « concept source » (ou
la « classe source ») de la règle2 .
Les propriétés associées à la ressource qui type l’instance sont également renseignées
au 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 classe mp (les propriétés sont
identifiées par le rôle qui leur est attribué).
Algorithme 4.2 : Règle de correspondance (ruleConcept2ResourceInstance )
Concept source :
ma : une classe de M Ma
Concept impliqué :
mp : une classe de M Mp
Notation :
propertyRoles(mp ) : l’ensemble des rôles attribués aux propriétés de mp
début
// Générer une instance de ressource typée par une ressource conforme à mp
correspondance avec ApplicationResourceInstance ∈ RTEPML
type ← getResource(mp )
Renseigner les propriétés
// Générer les propriétés de l’instance
pour chaque rôle r ∈ propertyRoles(mp ) faire
correspondance avec ResourceInstanceProperty ∈ RTEPML
val ← getValue(ma , r)
property ← getProperty(type, r)
fin
Dans un contexte déclaratif, la règle Activity2SchedulableResourceInstance introduite

dans le listing 4.1, page 80, offre un exemple d’implantation de l’algorithme 4.2. Dans cet
exemple, les concepts Activity et SchedulableResource correspondent respectivement aux
paramètres ma et mp 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 (respectivement
identifiés par les rôles Priority et StackSize).
2
Le « concept source » d’une règle de transformation correspond au concept auquel se conforme les éléments
transformés par la règle. Dans un contexte déclaratif, chaque élément conforme 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 getResource
pour localiser, dans la plate-forme cible, la ressource qui type l’instance à générer (cette
fonction se matérialise par un helper éponyme dans l’exemple du listing 4.1, ligne 6).
Cette fonction identifie une ressource via sa relation de conformité avec un concept de
RTEPML. Son principe est précisé dans l’algorithme 4.3.
Algorithme 4.3 : Localisation d’une ressource (getResource )
Entrée :
mp : une classe de RTEPML
Modèle impliqué :
Mp : un modèle de plate-forme d’exécution conforme à RTEPML
Résultat :
rp : une ressource de Mp conforme à mp
début
retourner rp ∈ Mp tel que rp χmp
fin
En suivant le même principe, l’algorithme 4.2 s’appuie sur une fonction getProperty
pour localiser les propriétés à renseigner (cette fonction se matérialise par un 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 fonction getResource dans l’algorithme 4.2), cette fonction identifie
les propriétés à renseigner par leur rôle.
Le principe de la fonction getProperty est 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écution
role : un rôle attribué à une propriété identifiée par RTEPML
Résultat :
une propriété de rp dont le rôle correspond à role
début
retourner rp .role
fin
Enfin, dans l’algorithme 4.2, les traductions et les affectations des valeurs des propriétés
sont assurées par la fonction getValue (cette fonction se matérialise par un helper éponyme
dans l’exemple du listing 4.1, ligne 14). A l’image de la fonction getProperty que nous
venons d’introduire, la fonction getValue identifie les propriétés par leur rôle.
Les implantations des algorithmes 4.3 et 4.4, dans des helpers ATL, sont données en
annexe pages 164 et 165.
Nous ne détaillerons pas les implantations possibles de la fonction getValue qui peuvent,
par exemple, déduire les valeurs de retour par calcul (à partir des données disponibles dans
le modèle source, comme le suggère l’algorithme présenté) ou retransmettre des valeurs
passé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 retourne
une valeur appropriée pour renseigner une propriété dont le rôle est passé en paramètre.
4.2.2 Première synthèse

Le principe de déploiement que nous venons d’introduire se matérialise par des trans-
formations uniquement basées sur les concepts du métamodèle source et du métamodèle de
plate-forme d’exécution. Aucun concept propre à une plate-forme donnée n’intervient donc
dans celles-ci. Les transformations implantent, d’autre part, un mécanisme d’instanciation
des ressources générique à toutes les plates-formes. Une application est mise en œuvre via
l’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. La considération d’une
plate-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 à des fonctions (ou hel-
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 son
ensemble, 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).
F IG . 4.4: Principe de déploiement d’une application via RTEPML.
Pour ce qui concerne le noyau générique de la transformation, la solution que nous

venons 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 des noms 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écutif
identifié par RTEPML ;
3. La plate-forme d’exécution envisagée offre une et une seule ressource conforme à un
concept identifié par RTEPML.
Dans ce contexte, chaque règle de déploiement exprime alors une correspondance entre
une classe du métamodèle de l’application et une classe du métamodèle de plate-forme
d’exécution (RTEPML). Ces classes (incarnées par ma et mp dans les algorithmes 4.1 et
4.2), identifient respectivement un concept applicatif et un concept exécutif3 . Les relations
envisagées entre les concepts sont alors uniquement 1-1. Elles se restreignent de plus aux
concepts identifiés par les noms des classes, sans aucune autre distinction possible.
3
Dans l’algorithme proposé la correspondance avec un concept exécutif se fait au travers de la ressource qui
type 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éploiements
envisageables. Pour cela, la section suivante aborde, dans un premier temps, les précisions
qu’il est possible d’apporter sur les concepts mis à contribution dans les transformations, en
plus des noms des classes qui les identifient. Puis elle cerne, dans un second temps, les types
de relations que les transformations de déploiement sont susceptibles d’implanter, avant de
dé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ésent
mettent 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 attributs
ou via leurs associations avec d’autres concepts.
Le concept de ressource ordonnançable illustre ce principe. En effet, RTEPML identifie
une ressource ordonnançable via la classe SchedulableResource. 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êmes identifiées
par un attribut (type) de la classe SchedulableResource. Différents concepts de ressources
ordonnanç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 ces déclinaisons
de concepts. Pour cela, les règles de correspondances (ruleConcept2ResourceInstance) et
la fonction de localisation de ressources (getResource) devraient pouvoir distinguer les
concepts 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 concepts qu’identifient
les 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 ressource
ordonnançable périodique est une association du concept de ressource ordonnançable (iden-
tifié par la classe SchedulableResource dans RTEPML) et d’un prédicat isPeriodic (tel que,
∀rp χShedulableResource, rp isP eriodic ⇐⇒ 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 classe ma du métamo-
dèle de l’application. Le second, ψmp , permet de préciser un concept exécutif identifié par
une classe mp 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.
4
La 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 dans
l’algorithme 4.6. La gestion des propriétés sera abordée en détail dans la suite de ce chapitre.
Algorithme 4.5 : Principe d’une transformation de déploiement (➤concept/critère)
Notations :
➤ γa : un concept (ma , ϕma ) tel que ma ∈ M Ma et ϕma précise ma
➤ γp [γa ] : un concept (mp , ψmp ) relatif à γa tel que mp ∈ M Mp et ψmp précise mp
début
...
➤ pour chaque concept γ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 ) tel que ma ∈ M Ma et ϕma précise ma
Concept impliqué :
➤ γp : un concept (mp , ψmp ) tel que mp ∈ M Mp et ψmp précise mp
début
// Générer une instance de ressource typée par une ressource conforme à γp
➤ type ← getResource(γp )
Renseigner les propriétés
...
fin
Algorithme 4.7 : Localisation d’une ressource (getResource ) (➤concept/critère)
Entrée :
➤ γp : un concept (mp , ψmp ) tel que mp ∈RTEPML et ψmp précise mp
Modèle impliqué :
Mp : un modèle de plate-forme d’exécution conforme à RTEPML
Résultat :
➤ rp : une ressource de Mp conforme à mp , dans le respect de ψmp
début
➤ retourner rp ∈ Mp tel que rp χ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 concepts exécutif5 .
Par essence, une transformation de modèle met en relation un ou plusieurs concepts
sources avec un ou plusieurs concepts cibles. 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 concepts
sources ou cibles sont impliqués par la correspondance.
Dans cette étude, les relations de correspondances expriment les mises en œuvre de
mécanismes applicatif avec des ressources que sont susceptibles de fournir les supports
d’exécution. Nous nous intéressons donc, dans un premier temps, aux relations entre les
concepts 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-formes
d’exécution, de ressources conformes aux concepts impliqués dans les transformations se-
ront abordées dans la sous-section suivante.
F IG . 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 un
concept applicatif. Dans le contexte de cette étude, deux cas peuvent alors se présenter, selon
que 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ème de 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 de
plate-forme d’exécution.
Dans le second cas, certains éléments du modèle source ne sont pas jugés utiles au
modèle de l’application déployée (par exemple, des informations nécessaires à des outils
5
Que ces concepts soient ou non précisés par des critères.
6
Une règle (Rule) de la forme Cx 2Rx Instance exprime une correspondance entre un concept Cx du mé-
tamodèle source et un concept Rx de RTEPML (Rx I est une instance de ressource typée par Rx ).
d’analyse ou de gestion de version). Les concepts auxquels se conforment ces éléments ne

seront 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 la transformation.
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’offre aucun support
pour 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, par
exemple, être possible durant l’exécution d’une transformation).
Enfin, la troisième stratégie consiste à déclarer une règle de correspondance pour chaque
concept du métamodèle source. Par défaut, une règle génère, par exemple, un élément dans
un modèle de trace (indépendant du métamodèle de plate-forme d’exécution). Les règles
dont les concepts sources sont utiles au déploiement de l’application sont ensuite rempla-
cées ou complétées par des règles de mise en correspondance avec des concepts 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 :
➤ M Mt : un métamodèle de trace (non précisé dans cette étude)
Notations :
➤ Γa : l’ensemble {(ma , ϕma )|ma ∈ M Ma et ϕma précise ma } utile au déploiement
γp [γa ] : un couple (mp , ψmp ) relatif à γa ∈ Γa tel que mp ∈ M Mp et ψmp précise mp
début
...
➤ pour chaque γa ∈ Γa faire
ruleConcept2ResourceInstance(γ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ésentent
ou non un intérêt pour le déploiement de l’application. En particulier, ceux qui ne présentent
pas 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 mises en
relations (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 concept
identifié 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 concepts
identifié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 suit le même prin-
cipe que pour une relation 1-1, en impliquant toutefois plusieurs instances. L’algorithme 4.9
définit ainsi la règle ruleConcept2MultiResourceInstances, pour étendre le principe de la
règle ruleConcept2ResourceInstance7 aux relations 1-N.
Algorithme 4.9 : Règle de correspondance (ruleConcept2MultiResourceInstances )
Concept source :
γa : un concept (ma , ϕma ) tel que ma ∈ M Ma et ϕma précise ma
Concepts impliqués :
Γp : un ensemble {(mp , ψmp )|mp ∈ M Mp et ψmp précise mp }
début
pour chaque γp ∈ Γp faire
ruleConcept2ResourceInstance(γa , γp )
fin
La règle ruleConcept2MultiResourceInstances vise à 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) dans
une boucle qui détermine l’ensemble des instances à générer. Cet ensemble est lui-même
déduit de l’ensemble des concepts exécutif impliqués dans la correspondance (Γp ).
Comme nous le verrons par la suite, la règle ruleConcept2MultiResourceInstances peut
se substituer à la règle ruleConcept2ResourceInstance dans l’algorithme 4.8 qui décrit le
principe 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 plusieurs
concepts applicatif. Les relations N-1 et N-M visent, par exemple, à mettre en œuvre un
mécanisme de l’application, dans lequel plusieurs concepts applicatif sont impliqués, avec
un 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
7
La règle ruleConcept2ResourceInstance est 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, sont
implanté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 fonction getValue. L’algorithme, tel qu’il est présenté, n’est pas
impacté. Cette version permet donc d’implanter des relations N-1 et N-M au même titre
que les relations 1-1 et 1-N. De même, le mécanisme introduit pour la considération des
relations 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 les concepts exécutif.
In fine, ces concepts sont toutefois incarnés par des ressources que les plates-formes sont
susceptibles de fournir. La généricité des transformations que nous voulons mettre en œuvre
né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 (sur
la base de relations 1-1 entre concepts applicatif et concepts exécutif, la transposition aux
relations 1-N étant immédiate).
F IG . 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ées

respectivement 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 à contribution
dans une règle de correspondance. Une « disponibilité 0 » ne permet pas de mettre en œuvre
un 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écution
cible, de plusieurs ressources conformes à un même concept exécutif. Cette situation révèle
un choix de mise en œuvre d’un mécanisme applicatif. Cette question sera traitée dans
l’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. La
sous-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 introduits
dans l’algorithme pour renseigner les propriétés des instances de ressources et générer des
appels de services.
4.3.4 Une mise en œuvre est-elle possible ?

Nous venons de distinguer deux situations majeures dans lesquelles une plate-forme
d’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 de cette indis-
ponibilité. Pour cela, dans la lignée des approches évoquées pour les relations 1-0 (entre
concepts applicatif et exécutif), plusieurs voies sont envisageables.
La première repose sur des fonctionnalités fournies par la technologie de transforma-
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é et la gestion qui
s’ensuit dépendent alors entièrement des moyens mis à disposition par la technologie de
transformation.
La seconde approche vise à implanter dans la transformation un mécanisme de détec-
tion d’indisponibilités indépendant de la technologie de transformation. Le principe d’un
tel 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 pas
applicable, une trace du problème est générée.
Deux approches de mise en œuvre sont alors possibles :
– conditionner l’application des règles de correspondance avant leur exécution (sous
forme, par exemple, de pré-conditions) ;
– orienter le déroulement des règles de correspondance durant leur exécution (sous
forme de conditions, au sein des règles).
Dans le premier cas, une règle est appliquée si toutes les ressources impliquées dans
cette règle sont disponibles. Dans le second cas, une règle ne génère que les éléments qui se
ré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. Le
second 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 le

résultat n’est pas « complet » (dans le sens où tous les éléments prévus sont générés). Par
contre, si une règle n’est pas appliquée, la trace générée ne distingue pas les ressources
indisponibles 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évus
ne 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 ∈ M Ma et ϕma précise ma } utile au déploiement
Γp [γa ] : un ensemble {(mp , ψmp )|mp ∈ M Mp et ψmp précise mp } relatif à γa ∈ Γa
début
...
pour chaque γa ∈ Γa faire
➤ si ∀γp ∈ Γp [γa ], getResource(γp ) 6= ∅ alors
ruleConcept2MultiResourceInstances(γ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é)
Concept source :
début
➤ si getResource(γp ) 6= ∅ alors
➤ 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ègle ruleConcept2MultiResourceInstances. Ce mécanisme aurait également pu être introduit dans la règle
ruleConcept2ResourceInstance pré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 de
conception, page 69), RTEPML identifie des concepts que les plates-formes d’exécution sont
susceptibles de fournir sous la forme d’une ressource unique (directement instanciable) ou
sous la forme d’un agencement de plusieurs ressources. L’expression d’un tel agencement
se fait alors, avec RTEPML, par le biais de prototypes de conception.
La mise à disposition, par une plate-forme d’exécution, d’une ressource conforme à un
concept se décline alors en deux situations, selon que cette ressource présente ou ne présente
pas de prototype de conception. La figure 4.7 raffine ainsi la mise à disposition que nous
avons 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 .
F IG . 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 approches

sont envisageables pour adapter l’algorithme de déploiement à ces situations. La première
approche conditionne l’application des règles, selon qu’un prototype est précisé ou non (une
règle est alors dédiée à chaque cas identifié). La seconde approche oriente le déroulement
des règles (sur des conditions similaires).
Cependant, lorsque plusieurs concepts exécutif sont impliqués dans une règle (dans
le cas des relations 1-N ou N-M), chacun peut être fourni par la plate-forme cible avec
ou sans prototype de conception. La première approche nécessite alors autant de règles
de correspondances que de cas identifiés (soit 2n pour n concepts impliqués). Alors que
la seconde approche permet d’orienter, selon deux possibilités (avec ou sans prototype),
chaque correspondance sous-jacente (ce qui nécessite au plus 2n règles pour n concepts
impliqués).
La seconde approche sera donc privilégiée. L’algorithme 4.12, page suivante, en détaille
la mise en œuvre.
L’algorithme 4.12 discerne les concepts pour lesquels un prototype de conception
est fourni par la plate-forme. S’il n’y a pas de prototype, une unique instance est
générée (à l’image de ce qui a été pratiqué jusqu’à présent dans la règle ruleCon-
cept2MultiResourceInstances). Par contre, lorsqu’un prototype est stipulé, un ensemble
d’instances de ressources est généré conformément à ce que décrit le prototype (le proto-
type est cloné). Cette génération (ou clonage) est capturée dans la règle ruleClonePrototype
dont l’algorithme 4.13, page suivante, donne le principe.
8
P B ′′ représente un prototype de conception dans la figure 4.7.
Algorithme 4.12 : Règle de correspondance (ruleConcept2MultiResourceInstances ) (➤prototypes)
Concept source :
début
si getResource(γp ) 6= ∅ alors
➤ si getResource(γp ).prototype = ∅ alors
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 )
Concept source :
Élement impliqué :
ω : un prototype de conception (conforme au concept Prototype de RTEPML)
début
// Générer les instances à partir de celles que précise le prototype
pour chaque instance i ∈ ω.instances faire
si i.match = ∅ alors
// L’instance ne correspond pas à une instance prédéfinie sur la plate-forme
si 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 prototype
ruleCreateResourceInstanceFromPrototype(γa , i)
// Générer les associations entre les instances que précise le prototype

pour chaque association a ∈ ω.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éation
d’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 sur
la 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 au
prototype suscitent une génération (d’où la condition i.match = ∅ qui vérifie qu’aucune
instance 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 ressource
dans 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ée par appels récursifs à
la règle ruleClonePrototype. Enfin, si l’instance de ressource ne nécessite pas de prototype
pour sa mise en œuvre, une instance est générée à son image. Cette génération est capturée
dans la règle ruleCreateResourceInstanceFromPrototype que nous détaillerons par la suite.
Finalement, lors de la seconde étape, les instances générées sont mises en relation. Pour
cela, 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ègle ruleCreateAssociationFromPrototype.
Les algorithmes suivants, 4.14 et 4.15, décrivent les principes respectifs des règles ru-
leCreateResourceInstanceFromPrototype et createAssociationFromPrototype chargées de
générer les instances et leurs associations.
L’algorithme 4.14 génère une instance de ressource dont le type correspond à celui
de l’instance du prototype (le renseignement des propriétés et des appels de services sera
abordé dans la suite de cette section). En complément, l’algorithme 4.15 génère une as-
sociation entre les « images » des éléments concernés par chaque association que décrit le
prototype. Ces images (src et dst) correspondent aux instances de ressources générées par
la règle ruleCreateResourceInstanceFromPrototype à partir de ces éléments.
Algorithme 4.14 : Génération d’une instance (ruleCreateResourceInstanceFromPrototype )
Concept source :
ι : 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 prototype
type ← ι.type
...
...
fin
Algorithme 4.15 : Génération des associations (ruleCreateAssociationFromPrototype )
Concept source :
α : une association (conforme à PrototypeResourceInstanceAssociation ∈ RTEPML)
début
// Générer une association entre deux instances de ressources
correspondance avec ResourceInstanceAssociation ∈ RTEPML
src ← getInstance(α.src)
dst ← getInstance(α.dst)
...
fin
On remarquera que les images des éléments décrits par un prototype sont localisées par
la fonction getInstance. Nous ne détaillerons pas cette fonction dans ce rapport. Une mise
en œuvre de celle-ci peut, par exemple, s’appuyer sur une liste qui mémorise les instances
générées à partir d’un prototype. Ces instances sont ensuite localisées au sein de cette liste.
Une solution d’implantation ATL disponible en annexe, et à laquelle nous ferons référence
dans la section suivante, repose sur cette solution de localisation d’instances.
Remarque : La prise en compte d’un prototype de conception repose sur deux parcours
de celui-ci. Le premier couvre les instances qu’il décrit. Sa complexité est en O(n) (pour n
instances décrites). Le second couvre les associations. Sa complexité est également en O(n)
(pour n associations décrites) en considérant que la localisation des instances générées,
assurée par la fonction getInstance, soit en O(1) (pour n instances générées).
Exemple
La figure 4.8, page suivante, illustre un déploiement dans lequel intervient un prototype
de conception. Dans cet exemple, une application de robotique constituée d’une activité de
contrôle périodique est déployée sur une plate-forme O SEK /V DX9 .
Dans l’exemple proposé, la transformation Robot2RTEPML met en correspondance le
concept 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 O SEK /V DX met
en œuvre un traitement périodique par une tâche périodiquement activée par une alarme. Le
modèle de la plate-forme décrit alors ce principe dans un prototype de conception de tâche
pé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 ressource PeriodicTask de la plate-forme d’exécution possédant un prototype de
conception, lors de la transformation, la règle ruleConcept2MultiResourceInstances (adap-
tée aux concepts d’activité et de ressource ordonnançable périodiques) oriente son exécution
9
Cet exemple s’appuie sur les métamodèles de robotique et de la plate-forme d’exécution O SEK /V DX pré-
sentés dans les chapitres 2 et 3. Pour des raisons didactiques, l’exemple ne mentionne pas le compteur auquel
est connecté l’alarme.
10
Nous admettons que le comportement attendu de l’activité est vérifié pour la mise en œuvre envisagée.
vers la règle ruleClonePrototype (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 ressources Control_T
et Control_T-A1 sont ainsi créées et associées par la relation alarm.
F IG . 4.8: Déploiement d’une application de robotique sur une plate-forme O SEK /V DX (prototype).
Remarque : Le prototype de l’exemple s’appuie sur l’association de deux ressources que

fournit la plate-forme d’exécution. Mais, d’autres prototypes peuvent également préciser
les valeurs de certaines propriétés ou faire appel à des services de ressources. La prise en
compte, lors d’un déploiement, des propriétés et des appels de services précisés dans un
prototype 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 des propriétés atta-
chées aux instances de ressources, a été évoquée dans la section précédente, mais laissée en
suspend 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 par
une propriété, est issue ou non d’un prototype de conception. Deux raisons motivent cette
distinction. 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 de
l’application. Il introduit d’autre part un mécanisme de distribution des rôles qui influence
l’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 les
deux 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ées sous forme de littéraux
(pour un type natif à la plate-forme) ou sous forme de références vers d’autres instances
de ressources (cf. ResourceInstanceProperty, figure 3.16, page 66). Au sein de chacun des
contextes (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 chacun
des contextes. L’implantation de la gestion des références sera ensuite discutée, avant de
pré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ègle ruleConcept2ResourceInstance. 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 la
fonction getPropertyRoles).
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 doit disposer de cette
propriété (ce dont nous informe la fonction getProperty qui 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 fonction hasPropertyInformation).
Le renseignement d’une propriété consiste alors à générer une proprié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èle de l’application. Les
informations relatives à chacune de ces formes, par valeur ou par référence, sont successive-
ment collectées et traitées (via les fonctions getPropertyValues et getPropertyReferences).
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 être
renseignée plusieurs fois. La modélisation des points d’entrée d’une tâche souligne l’intérêt
de cette approche. En effet, différents points d’entrée peuvent être associés à une tâche, par
exemple, selon des modes de fonctionnement (test, nominal, dégradé, etc.). Chaque point
d’entrée est alors stipulé dans une propriété dont le rôle correspond au point d’entrée d’une
ressource ordonnançable11 .
Enfin, l’algorithme prévoit de générer une trace lorsqu’une propriété susceptible d’être
renseigné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 sont
pas distinguées dans cette version. Une séparation des conditions sur le déroulement de la
rè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 cette
sous-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.
11
L’utilisation de différents points d’entrés dans le cadre d’une gestion des modes de fonctionnement ne sera
pas plus abordée dans la suite de ce rapport.
Algorithme 4.16 : Sans prototype (ruleConcept2ResourceInstance ) (➤propriétés)
Concept source :
Concept impliqué :
γp : un concept (mp , ψmp ) tel que mp ∈ M Mp et ψmp précise mp
début
type ← getResource(γp )
...
➤ pour chaque rô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 est r
// 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 chaque value ∈ getPropertyValues(γa , r) faire
➤ correspondance avec ResourceInstanceProperty ∈ RTEPML
➤ val ← value
➤ property ← getProperty(type, r)
// Générer les propriétés d’instances renseignées par des références
➤ pour chaque ref erence ∈ getPropertyReferences(γa , r) faire
➤ ref ← ref erence
➤ property ← getProperty(type, r)
➤ sinon
➤ // Générer la trace d’une absence d’information pour un rôle de propriété
➤ traceLackOfProperty(γa , type, r)
fin
Avec prototype de conception
Lorsqu’un prototype de conception est mis à contribution, les propriétés des instances
peuvent 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 du modè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 au

sein de la règle ruleCreateResourceInstanceFromPrototype. L’algorithme 4.17, page sui-
vante, en détaille le principe.
Algorithme 4.17 : Avec prototype (ruleCreateResourceInstanceFromPrototype ) (➤propriétés)
Concept source :
Concept impliqué :
➤ γp : un concept (mp , ψmp ) tel que mp ∈ M Mp et ψmp précise mp
ι : 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
prototype
type ← ι.type
...
// Générer les propriétés à partir d’informations issues du modèle de l’application
➤ pour chaque rô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ôle r
// et que l’élément source fournit une ou des informations pour cette propriété
➤ pour chaque value ∈ getPropertyValues(γa , r) faire
➤ val ← value
➤ property ← getPrototypeProperty(γp , ι, r)
➤ pour chaque ref erence ∈ getPropertyReferences(γa , r) faire
➤ ref ← ref erence
➤ property ← getPrototypeProperty(γp , ι, r)
➤ sinon
➤ // Générer la trace d’une absence d’information pour un rôle de propriété
➤ traceLackOfProperty(γa , type, r)
fin
Cette gestion est similaire à celle que nous venons de présenter (sans prototype de
conception). Seule la localisation des propriétés à renseigner diffère. En effet, les rôles
des propriétés associées aux ressources sont « distribués » aux instances des prototypes de
conception (cf. Prototypes de conception, page 69). Les instances d’un prototype, ou plus
précisément les propriétés des ressources qui les typent, se voient ainsi attribuer les rôles
des 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ées
sont 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 au concept exécutif
(γp ) mis en œuvre par le prototype de conception (comme précédemment, les propriétés sont
identifiées par les rôles que retourne la fonction getPropertyRoles).
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 prototype

concernée par la règle (ce dont nous informe la fonction getPrototypeProperty qui
localise 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 fonction hasPropertyInformation).
Comme précédemment, le renseignement d’une propriété consiste alors à générer une

proprié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èle
de l’application. Les informations relatives aux valeurs ou aux références sont ici aussi
successivement collectées et traitées. Enfin, l’algorithme prévoit également de générer une
trace lorsqu’une propriété susceptible d’être renseignée est ignorée lors du déploiement.
Parallèlement, comme cela fut mentionné précédemment, lorsqu’un prototype de

conception est mis à contribution, les propriétés des instances peuvent également se déduire
du prototype lui-même.
La gestion des propriétés renseignées à partir du prototype se fait alors au sein de
la règle ruleClonePrototype. L’algorithme 4.18 en détail le principe.
La gestion des propriétés stipulées dans un prototype consiste à générer des proprié-
tés d’instances de ressources (ResourceInstanceProperty) à l’image de celles que précise
le prototype. Cette génération est assurée par la règle ruleCreatePropertiesFromPrototype
dont l’algorithme 4.19, page suivante, détaille le principe.
Algorithme 4.18 : Règle d’application d’un prototype (ruleClonePrototype ) (➤propriétés)
Concept source :
ω : un prototype de conception (conforme au concept Prototype de RTEPML)
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 instance i ∈ ω.instances faire
➤ ruleCreatePropertiesFromPrototype(γa , i)
// Générer les associations entre les instances que précise le prototype
...
fin
Algorithme 4.19 : Génération des propriétés (ruleCreatePropertiesFromPrototype )
Concept source :
ι : 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 prototype
pour chaque property ∈ ι.properties faire
// Créer une propriété à l’image d’une propriété de l’instance du prototype
val ← property.val
ref ← getInstance(property.ref )
property ← property.property
fin
On remarquera la mise à contribution de la fonction getInstance introduite 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ées
après la génération des instances, et non pendant, comme c’est le cas lors de la prise en
compte des informations présentes dans le modèle de l’application. Cette distinction est
motivée par le besoin de se référer à des instances issues du prototype, lorsqu’elles sont
référencées par des propriétés. La gestion des références dans les propriétés est discutée et
approfondie 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 deux
sources fournissent une information pour la même propriété, deux propriétés d’instances
sont créées, renseignant alors deux fois la propriété. L’interprétation des deux valeurs (ou
des 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 ou
par 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ément généré au
cours 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 conception que nous
avons présenté dans la sous-section précédente. Lors de l’application d’un prototype, la
génération des associations entre les instances repose également sur des références vers
des éléments générés. Cependant, les éléments concernés sont soit mis à disposition par la
plate-forme, soit générés par une règle dont l’exécution précède, par construction, celle qui
génère les associations. L’existence des instances référencées est donc systématiquement
garantie.
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éments avant 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 la
génération des instances de ressources, nécessitent un contexte impératif12 . Ces parties
concernent 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 ne
bénéficient pas d’une génération « anticipée ». Et, ils ne peuvent être référencés qu’après
avoir été générés. La gestion des références qui impliquent des éléments potentiellement
gé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 à la
gestion des propriétés renseignées à partir des informations présentes dans le modèle de
l’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 un mécanisme qui
consiste à 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ération
des instances manquantes13 .
Ce mécanisme concerne les règles ruleConcept2ResourceInstance et ruleCreateResour-
ceInstanceFromPrototype chargées de générer les instances de ressources et de renseigner
leurs propriétés. L’algorithme 4.20, page suivante, illustre son intégration en se concentrant
sur les parties communes à ces règles.
L’algorithme 4.20 introduit les fonctions getIfExistInstance et 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 parcourt
les propriétés à compléter après chaque création d’instance. Ce parcours vise à compléter
les 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 mise
en œuvre s’appuie sur une structure qui mémorise des couples (propriété d’instance, élément
source), pour ce qui concerne les propriétés incomplètes, et peut nécessiter une structure
qui mémorise l’ensemble des traductions effectuées au cours de la transformation (pour
discerner les instances disponibles lors d’un référencement). Une solution d’implantation
ATL disponible en annexe repose sur ce mécanisme.
12
Nous détaillerons, dans la section suivante, les contraintes d’implantation qu’impose l’algorithme proposé.
13
La 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)
Concept source :
Concept impliqué :
début
// Générer une instance de ressource
...
pour chaque rôle r ∈ getPropertyRoles(γp ) faire
si // conditions de génération
alors
...
pour chaque ref erence ∈ getPropertyReferences(γa , r) faire
➤ ref ← getIfExistInstance(ref erence)
property ← ...
sinon
// Générer la trace d’une absence d’information pour un rôle de 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 transformation Robot2RTEPML assure la mise en œuvre d’un sous-
programme par une correspondance avec le concept de routine14 (dont la plate-forme fournit
une ressource qui s’y conforme (Function)).
Au cours de la transformation, les propriétés des instances générées sont renseignées
conformé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 conception
et les informations qui renseignent leurs propriétés sont issues du modèle de l’application.
14
Le 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 la
pile et à la période d’activation sont renseignées par valeurs. Ces valeurs sont associées aux
proprié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 fonction Control
(qui correspond au sous-programme homonyme de l’activité de contrôle).
F IG . 4.9: Déploiement d’une application de robotique sur une plate-forme O SEK /V DX (propriétés).
4.3.7 Gestion des appels de services

Le dernier point qu’aborde cette sous-section concerne l’implication des services 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ès
aux sections critiques impliquent, par exemple, systématiquement des services de prise et
de libération d’une ressource d’exclusion mutuelle. De même, les communications entre
les entités d’exécution concurrentes sollicitent les services des ressources dédiées à ces
communications.
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-forme
d’exécution. La mise en œuvre de ces mécanismes se concrétise donc par des appels de
services qu’il convient de générer lors du déploiement de l’application.
15
Seule la distribution des rôles de périodicité (period) et de point d’entrée (entrypoint) est représentée dans
le modèle en guise d’exemple.
La gestion des appels de services que nous proposons d’intégrer dans l’algorithme suit
alors 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, ces appels sont gé-
nérés lors de la création de l’instance. Pour cela, des fonctions de « détection d’implication
de 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ée

est 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 le
modèle de l’application ou à partir d’appels de services spécifiés dans un prototype.
Des paramètres peuvent également accompagner les appels de services. A l’image des
proprié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 appels
de 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 de
toutes 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’une
instance 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ègle ruleConcept2ResourceInstance (qui
n’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.21
s’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 services
impliqués lors d’un déploiement.
16
La 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 Mt : un métamodèle de trace (non précisé dans cette étude)
Concept source :
Concept impliqué :
début
type ← getResource(γp )
...
...
// 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 avec CallService ∈ 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 avec CallParameter ∈ 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 avec CallParameter ∈ 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 attente

completePropertyReferences(γ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’un mécanisme
applicatif (getCallServices) ;
– un service précis (getService) ;
– les paramètres d’un service (getParameterValues et getParametersReferences).
L’algorithme prévoit que certaines fonctions retournent des informations sous la forme
de 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 ressource
conforme au concept stipulé17 .
Pour ce qui concerne les paramètres (getParameterValues et getParametersReferences),
le tuple est un couple constitué d’une information de localisation du paramètre et soit d’une
valeur, 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 la
sous-section précédente. La localisation des instances référencées est assurée par la fonction
getIfExistInstance, tant pour l’instance à laquelle s’adresse le service que pour les instances
passées en paramètre. Et finalement, les appels qui ne disposent pas d’une de ces instances
au moment de leur génération sont complétés au sein d’une fonction completeCallService-
References, à l’image de la fonction completePropertyReferences introduite 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 gestion
des services dans un prototype de conception étant également similaire à ce qui a déjà été
présenté (règles ruleCreateResourceInstanceFromPrototype et ruleClonePrototype), nous
n’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 deux activités périodiques. L’une est
dé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
(symbole H) et une connexion entre ces ports (Com).
Remarque : Dans cette version, la transformation Robot2RTEPML assure la mise en
œuvre d’une connexion par une correspondance avec le concept de variable partagée18 (dont
la 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 (Control et Display, qui correspondent aux sous-programmes homonymes du modèle
de l’application), un helper getCallSequence renseigne la transformation sur le fait que les
ports de données engendrent la création d’appels de services. L’algorithme 4.22, page ci-
contre, détaille le principe de ce helper .
L’échange de donnée décrit par les ports d’entrée et de sortie se concrétise alors par des
appels aux services de lecture et d’écriture (read et write) de la ressource SharedData (en
17
L’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.
18
Le concept de variable partagée (SharedDataComResource) a été introduit dans le chapitre 3 lors de la
présentation de RTEPML. Nous considérons que le comportement attendu de la communication modélisée est
vérifié pour la mise en œuvre proposée.
fonction de l’orientation du port). Chacun de ces appels s’adresse à l’instance de ressource

partagée (Com), qui correspond à la connexion homonyme, dans le modèle de l’application.
F IG . 4.10: Déploiement d’une application de robotique sur une plate-forme O SEK /V DX (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 à un Subprogram du métamodèle Robot
Résultat :
seq : une séquence de tuples {element, concept, role}
début
seq ← ∅
// Pour chaque port de donnée de sortie
pour chaque output ∈ sp.outputDataP orts faire
// appel du service d’écriture sur une connexion par variable partagée
seq ← {output.connection, RTEPML !SharedDataComResource, ’write’}
// Pour chaque port de donnée d’entrée
pour chaque input ∈ sp.inputDataP orts faire
// appel du service de lecture sur une connexion par variable partagée
seq ← {input.connection, RTEPML !SharedDataComResource, ’read’}
retourner seq
fin
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érarchie
de 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 nous
avons détaillées dans la section précédente. La seconde (4.11b) introduit les règles de traces
que nous avons évoquées. Dans ce schéma, une relation orientée entre deux règles, ra → rb ,
signifie que la règle ra appelle la règle rb ou « intègre » la correspondance que décrit la règle
rb (selon que le contexte de transformation est impératif ou déclaratif19 ).
(a) Règles de déploiements
(b) Règles de traces
F IG . 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 le traitement de

leurs données sont délégués à des fonctions (ou helpers ). Les règles et les fonctions qui
composent une transformation sont alors plus ou moins dépendantes des technologies im-
pliquées lors du déploiement.
19
On notera toutefois que les règles qui complètent les références et celles qui gèrent les prototypes de
conception 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 (M Ma ),
– le métamodèle de plate-forme d’exécution (RTEPML),
– la plate-forme d’exécution cible (P DM) et
– un métamodèle de trace (M Mt ).
M Ma RTEPML P DM M Mt
ruleConcept2M ultiResourceInstances ✓ (1)
✓
ruleConcept2ResourceInstance ✓(2) ✓
ruleCloneP rototype ✓(1) ✓
✓ ✓
Règles de correspondances
ruleCreateResourceInstanceF romP rototype (2)
ruleCreateAssociationF romP rototype ✓(2) ✓

ruleCreateP ropertiesF romP rototype ✓(2) ✓
ruleCreateCallServicesF romP rototype ✓ (2)
✓
completeP ropertyRef erences ✓(2) ✓
completeCallServiceRef erences ✓(2) ✓
traceU nusedConcept ✓ (3)
✓(3) ✓
traceLackOf Resource ✓(3) ✓(3) ✓
traceLackOf P roperty ✓(3) ✓(3) ✓
traceLackOf Service ✓(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.
getResource ✓
getInstance ✓
getIf ExistInstance ✓
getP roperty ✓
getP rototypeP roperty ✓
Fonctions (ou helpers )
getP ropertyRoles ✓
hasP ropertyInf ormation ✓ ✓
getP ropertyV alues ✓ ✓ ✓
getP ropertyRef erences ✓ ✓ ✓
getCallServices ✓ ✓
getService ✓
getP arameterV alues ✓ ✓ ✓
getP arameterRef erences ✓ ✓ ✓
getP arameter ✓ ✓
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 sont
principalement dépendantes du métamodèle de trace. Elles se contentent d’accès génériques
aux é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 de règles s’expriment
dans les termes du métamodèle de l’application20 . En effet, les éléments issus du modèle
de l’application peuvent être transmis le long de la hiérarchie, sans stipuler les concepts
auxquels ils se conforment21 . Ces concepts sont uniquement pris en compte, in fine, par les
fonctions 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ègles
au 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). Celles
qui dépendent également du métamodèle de l’application (M Ma ). Et celles qui sont propres
à la plate-forme cible (P DM). 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érents packages , tel que le

décrit la figure 4.12. Deux packages regroupent les règles et les fonctions génériques aux
plates-formes et aux technologies de modélisation des applications sources (rules4rtepml
et helpers4rtepml, propres à RTEPML). Un package peut être dédié aux règles de traces
potentiellement génériques à toutes les technologies (si les traces se contentent d’éléments
nommés ou de références) (rules4trace, propre au métamodèle de trace - non représenté sur
le schéma). Enfin, la transformation (X2RTEPML) se compose de trois packages . Les deux
premiers concernent les règles et les fonctions propres au métamodèle de l’application,
mais génériques à toutes les plates-formes (X2rtepml et X4rtepml). Le troisième regroupe
les fonctions qui dépendent de la plate-forme cible (X4platform).
F IG . 4.12: Organisation d’une transformation de déploiement basée sur RTEPML.
20
Dans un contexte déclaratif, le sommet de la hiérarchie de règles peut être défini comme étant l’ensemble
des règles qui ne sont pas explicitement appelées. Pour ce qui nous concerne, ces règles sont du type ruleCon-
cept2MultiResourceInstances et traceUnusedConcept.
21
Ceci suppose que les règles soient paramétrées avec un type générique (du type void ou OclAny).
Finalement, en s’appuyant sur les règles et les fonctions que fournissent ces packages ,
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 les
concepts applicatif qui ne sont pas mis à contribution lors d’un déploiement ;
– un ensemble de fonctions de collecte d’informations (hasPropertyInformation, get-
CallServices et getParameter), dans le but d’identifier les éléments de l’application
qui 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, getParameterValues et getParametersReferences), pour
renseigner les propriétés et les paramètres dans le modèle généré (P SM).
La suite de cette section se focalise sur le développement des deux premiers ensembles,
avant d’évoquer des perspectives d’assistance au développement des deux derniers. Mais
avant d’approfondir ces principes de développement, nous tenons à signaler certaines
contraintes 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é, certains mécanismes de
l’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 des modè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 que void ou OclAny) doit être disponible pour para-
métrer les règles. En effet, tout type d’élément applicatif doit pouvoir être transmis aux
règles qui composent le noyau générique des transformations (le package rules4rtepml),
sans présumer du concept auquel il se conforme.
Parmi les technologies de transformations actuellement disponibles, ATL répond, par
exemple, 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 de
cette é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 traduisent
les concepts applicatif en concepts exécutif. Les règles de correspondance sont toutefois
donné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.
22
D’autres technologies, tels que Smart-Q VT [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ègles qui composent
une transformation de déploiement établit des correspondances entre des concepts applicatif
et des concepts exécutif identifiés par RTEPML (package X2rtepml). Or, la structure de ces
règles (du type ruleConcept2MultiResourceInstances23 ) est générique à tous les concepts
sources et cibles impliqués. Cette structure offre donc une perspective de génération des
rè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éliser
les 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, au
sein des règles du type ruleConcept2MultiResourceInstances, 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 plus
simple que nous ayons identifié pour décrire ces correspondances.
F IG . 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é par son nom. Ce nom
correspond au nom de la classe qui l’identifie dans un métamodèle. Un concept peut être
précisé par des critères (cf. Affiner les critères sur les concepts, page 85). Un critère est
alors désigné par le nom de la fonction (ou helper ) qui capture son prédicat (Criterion).
Plusieurs améliorations peuvent être apportées à ce métamodèle. Des notions d’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’autres
notions qui concernent les métamodèles peuvent également être introduites pour préciser
les technologies concernées par le déploiement et identifier, par exemple, des notions de
version associées à ces technologies. Enfin, l’identification par nom pourrait être remplacée
par des références vers les classes concernées dans les métamodèles (tels que l’envisagent
les travaux relatifs au tissage de modèles [34]).
23
Algorithme 4.12, page 94.
Toutefois, nous ne détaillerons pas plus ce métamodèle dans la suite de cette section. La
solution 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 (ou weaving) consiste à modéliser des liens entre des éléments de modèles
ou 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ées aux liens tissés.
Ainsi, lorsque la sémantique des liens concorde avec celle d’une transformation, un modèle
de 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 les outils relatifs
au 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, les correspondances que
décrivent les modèles de déploiement reflètent uniquement les traductions de concepts ap-
plicatif en concepts exécutif. Les mécanismes de clonage des prototypes ou de gestion des
propriétés et des appels de services ne sont pas décrits dans les modèles de déploiement.
Ces mécanismes sont capturés dans les templates de génération de règles. L’approche que
nous 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 de
déploiement de la figure 4.13. Ce modèle décrit le déploiement qui conduit à la génération
des règles de transformation mises à contribution dans le dernier exemple de la section
précédente (figure 4.10, page 109). La syntaxe textuelle et les termes employés dans ce
listing nous semblent suffisamment explicites pour ne pas être commentés.
1 -- implement application periodic activity

2 -- with periodic scheduable resource
3 Activity [ categoryIsPeriodic ]
4 -> SchedulableResource [ typeIsPeriodic ]
5
6 -- implement application subprogram with routine
7 Subprogram
8 -> Routine
9
10 -- implement connection with shared data
11 Connection
12 -> SharedDataComResource
Listing 4.2: Exemple de modèle de déploiement
La transformation qui résulte de ce modèle s’appuie sur les fonctions categoryIsPeriodic

et typeIsPeriodic qui 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 du package X4rtepml
(figure 4.12, page 112). La seconde, propre à RTEPML, sera fournie par le package hel-
pers4rtepml.
Un exemple de template de 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, page 186. Le principe
d’un tel template consiste à 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 de template , à partir des informations
disponibles dans un modèle de déploiement.
Remarque : Une approche de génération de règles par transformation de modèles basée
sur ce même métamodèle est également envisageable mais ne sera pas présentée. Dans la
suite de ce rapport, nous considérerons qu’une approche par template est pratiquée, mais
nous 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 à contribution lors du dé-
ploiement et pour lesquels une trace doit être générée. A l’image des règles du premier
ensemble, la structure de ces règles (du type traceUnusedConcept) 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’introduction de concepts
de traces dans le métamodèle de déploiement.
F IG . 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 template de
gé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 un template 24 . 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èle
que nous venons de présenter (Deployment). A partir de ce modèle et de templates mis à dis-
position dans le package templates4rtepml, l’ensemble des règles de déploiement propres à
l’application est généré (X2rtepml).
F IG . 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 du
déploiement ne sont pas représentés dans la figure 4.15. Une vision globale et complète de
l’organisation d’une transformation de déploiement sera donnée en fin de chapitre.
24
Les packages gé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 le
modè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 les
ré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 de
parcourir les modèles. Celles du second ensemble sont de plus spécifiques à la plate-forme
cible. 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 ces
fonctions. 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 de
renseigner une priorité (priority) est accessible via un appel à une fonction getProperty
dont le paramètre correspond au rôle de priorité dans RTEPML (priority). L’implantation
de cette fonction consiste alors à appeler une seconde fonction dont le nom est déduit, par
convention, du nom du rôle passé en paramètre (getPriority dans cet exemple). De part
cette convention, l’invocation des fonctions est générique. Les fonctions encapsulent d’une
certaine 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 de
concevoir 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 chaque
fonction sont entièrement liés au métamodèle de plate-forme d’exécution (RTEPML) ou
plus 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 donc
inciter un utilisateur a renseigner les fonctions associées aux propriétés, aux services ou aux
paramètres qu’il est susceptible de mettre à contribution. Les noms des fonctions sont alors
dé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 aux
propriétés associées à ce concept peuvent être demandées (telles que la priorité (priority) et
la taille de la pile (stacksize)). Les signatures de ces fonctions, telle que getPriority() pour
la priorité et getStackSize() 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 qui
dé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 aux informations est
formulé dans un langage propre à la technologie de transformation (par exemple, un sous-
ensemble du langage O CL pour ATL). Ces accès pourraient également être capturés dans un
modèle indépendant de la technologie de transformation. Les corps des fonctions seraient
ensuite 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ées
dans la suite de ce rapport. Ces approches ouvrent des perspectives d’outillages associés au
processus de déploiement que nous proposons.
25
Il en est de même pour les informations contenues dans le modèle de la plate-forme cible. Mais, dans ce
cas, l’encapsulation est assurée par des fonctions fournies dans le package helpers4rtepml. Le développement
de 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 entre
les concepts applicatif et les concepts exécutif qu’identifie un métamodèle de plate-forme
d’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 avec au plus un concept exécutif (rela-
tions 1-1) ou un ensemble de concepts exécutif (relations 1-N) ;
2. La plate-forme cible fournit au plus une 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 plusieurs
ressources sont envisageables pour la mise en œuvre d’un mécanisme applicatif26 . Cette
section 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. Par
exemple, les variables partagées et les tableaux noirs (blackboard, en anglais) fournissent
des supports différents pour un échange de données entre des tâches. Or, le métamodèle de
plate-forme d’exécution RTEPML identifie d’une part chacun de ces concepts (respective-
ment SharedDataComResource et MessageComResource) et les plates-formes d’exécution
fournissent d’autre part des ressources conformes à l’un, à l’autre ou aux deux concepts.
Orthogonalement, une plate-forme d’exécution peut fournir différentes ressources,
ou agencements de ressources, conformes à un même concept exécutif. Le standard
O SEK /V DX 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 donc
conformes 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 de
ressources. 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 entre
concepts applicatif et concepts exécutif, sans prototype de conception27 .
F IG . 4.16: Choix de déploiement conceptuels et pratiques.

26
Ou, respectivement, plusieurs ensembles de concepts ou plusieurs agencements de ressources.
27
L’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 conceptuels et 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 choix
lors d’un déploiement se concrétise donc par la capture et la prise en compte de décisions
relatives 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 qualifierons
de décisions de déploiements), avant de statuer sur le support que nous adopterons.
Un choix conceptuel porte sur des concepts du métamodèle de plate-forme d’exécu-

tion. Une décision relative à un choix conceptuel influence donc l’application des règles à
destination de ces concepts (telles que RuleCa 2RIa ou RuleCa′ 2RIa′ dans la figure 4.16).
Parallèlement, un choix pratique porte sur des ressources de la plate-forme cible. Une
décision relative à un choix pratique influence donc l’identification de la ressource qui type
une instance générée (B ou B ′ 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érents
supports permettent donc de les capturer. Une règle peut en effet être guidée à partir :
– de données extraites des modèles de l’application et de la plate-forme cible,
– d’annotations dans le modèle de l’application ou
– d’un modè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èles de l’appli-
cation et de la plate-forme cible, nécessite toutefois d’introduire dans la transformation
des 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 à la décision
appartiennent à 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 nous
semble donc pas pertinente. Cette première solution a donc été écartée. Des informations
issues d’un processus annexe de décision seront explicitement apportées à la transformation
pour orienter l’exécution des règles.
Comme cela fut annoncé, un apport d’informations peut alors se matérialiser sous la
forme 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’application
ne 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). Elles
introduisent donc des informations dépendantes d’une plate-forme dans un modèle voulu
indépendant de celle-ci. Selon nous, cette pratique compromet la séparation entre modèles
dépendants et indépendants d’une technologie, que prône le M DA.
Par contre, l’approche qui consiste à isoler les informations propres aux décisions de
déploiements dans un modèle dédié s’accorde davantage avec une approche M DA. 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. Dans le but de
cerner ce métamodèle, nous allons, dans un premier temps, identifier les décisions qu’il est
né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 un
mé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 nous
sommes 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 soient
favorables pour certains éléments de l’application, mais que d’autres mises en œuvre soient
plus adaptées à d’autres éléments. Une décision de déploiement peut donc concerner :
– 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 doivent
pouvoir refléter quatre types de correspondances :
– entre un concept applicatif et un concept identifié par RTEPML ;
– entre un concept applicatif et une ressource de la plate-forme d’exécution ;
– entre certains éléments applicatif et un concept identifié par RTEPML ;
– entre certains éléments applicatif et une ressource de la plate-forme d’exécution.
Pour les relations 1-N, les décisions de déploiement doivent, en plus, pouvoir refléter
des correspondances avec plusieurs concepts ou ressources de la plate-forme d’exécution.
Formulation des décisions
Nous avons vu, dans la sous-section précédente, que les décisions de déploiement in-
fluencent l’application ou le déroulement des règles de transformations. Cette influence se
matérialise par des conditions au sein de la transformation, sous la forme, par exemple, de
pré-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. Cette
dé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 (si
décision = décision A alors ...). Cette approche présente l’inconvénient de devoir définir un
terme pour chaque décision envisageable. Elle compromet de plus la généricité des règles
de 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 se
baser sur les correspondances que les décisions reflètent et imposer l’usage des termes des
modèles et des métamodèles impliqués. L’expression de décision qui ne concernent que
certains éléments du modèle de l’application n’est toutefois pas facilitée. Cette approche
né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 les
correspondances 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-section précédente

(figure 4.13, page 114) permet de décrire des correspondances entre des concepts applicatif
et exécutif auxquels des critères peuvent être associés.
Parallèlement, les décisions de déploiement que nous envisageons d’exprimer reflètent
des 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’application ou
du modèle de la plate-forme cible. Or, ces éléments peuvent également être discernés par
des critères sur les concepts auxquels ils se conforment. Le métamodèle de déploiement, tel
que 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 qui
pré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 les correspondances de déploiement « théoriques » entre
les concepts applicatif et les concepts exécutif, et les décisions de déploiement propres à
l’application et à la plate-forme cible. Un modèle de décisions peut même omettre certaines
correspondances 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.17
illustre 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 sont
potentiellement 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 les versions précé-
dentes du métamodèle de déploiement (figures 4.13 et 4.14, pages 114 et 116). Comme
nous le verrons dans l’exemple qui suit, les paramètres des critères offrent simplement une
facilité d’implantation des prédicats dans des fonctions.
F IG . 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 de

conception des modèles de déploiements. Cette méthodologie consiste à décrire dans un
premier 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 (sans
aucune décision face aux choix). Un modèle de décision raffine 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’on peut déployer. Alors qu’un modèle
de décisions décrit ce que l’on veut déployer.
Les listings 4.3 et 4.4 présentent un exemple de modèle de déploiement et du modèle de
décision qui le raffine.
-- implement application periodic activity

-- with periodic scheduable resource
Activity [ categoryIs(’Periodic’) ]
-> SchedulableResource [ typeIs(’Periodic’) ]
-- implement application subprogram with routine

Subprogram
-> Routine
-- implement connection with shared data

Connection
-> SharedDataComResource
-- implement connection with message communication

Connection
-> 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 task

Activity [ categoryIs(’Periodic’)] / jobIs(’Display’) /
-> SchedulableResource [ typeIs(’Periodic’) ] / kindIs(’BasicTask’) /
-- refine : control activity -> extended task

Activity [ categoryIs(’Periodic’) ] / jobIs(’Control’) /
-> SchedulableResource [ typeIs(’Periodic’) ] / kindIs(’ExtendedTask’) /
-- implement application subprogram with routine

Subprogram
-> 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 O SEK /V DX)
Le premier modèle décrit les mises en œuvre possibles de mécanismes applicatif (dans
les 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 stipule
maintenant les critères avec des fonctions et des paramètres).
On notera que ce modèle propose un choix conceptuel pour la mise en œuvre d’une
connexion. 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 au
déploiement d’une application sur une plate-forme O SEK /V DX.
Nous avons mentionné, en introduction de cette section, qu’une plate-forme O SEK /V DX
distinguait les tâches étendues, susceptibles d’attendre un évènement (extended task), des
tâches basiques qui ne le peuvent pas (basic task). En supposant que le modèle de la plate-
forme O SEK /V DX que nous utilisons modélise deux types de ressources pour cela, le dé-
ploiement d’une application de robotique se confronte alors à un choix 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 aux
concepts applicatif et exécutif. Les activités d’affichages seront implantées par des tâches
basiques 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 la
seconde est neutralisée par un critère toujours faux. Lors d’un déploiement, seul l’élément
nommé « 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 processus de génération des
règles de correspondances présenté dans la sous-section précédente. Cette génération repose
maintenant 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.18
illustre l’organisation de ce processus de déploiement.
F IG . 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ême package (X2Platform) les fonctions et le modèle
de décision propres à la plate-forme cible (X4platform et Application2Platform).
Dans ce même soucis de séparation des domaines et des technologies impliqués, un
package helpers4X a été introduit. Ce package regroupe les fonctions de parcours et de col-
lecte d’informations propres au métamodèle de l’application mais indépendant de tout autre
métamodèle. Ce package comprend, par exemple, les fonctions qui permettent d’exprimer
des critères sur les concepts ou les éléments applicatif.
Un exemple de template de génération de règles ATL compatible avec cette approche
est donné en annexe, page 187. Ce template s’appuie sur le métamodèle de déploiement que
nous venons d’étendre aux décisions.
4.6 Synthèse
Nous nous sommes intéressés, dans ce chapitre, à définir un processus de déploiement
basé 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 du
modèle de la plate-forme cible.
L’algorithme de transformation au cœur du processus repose sur un mécanisme que
nous avons qualifié d’« intégration d’applications ». Son principe consiste à instancier les
ressources d’une plate-forme pour les besoins d’une application. Une description d’applica-
tion spécifique à une plate-forme se concrétise alors par un modèle de la plate-forme enrichi
des instances de ressources qui mettent en œuvre l’application.
Nous avons constaté, qu’une intégration d’applications dans un modèle de plate-forme
d’exécution offrait des perspectives de transformations de déploiement en grande partie
génériques vis-à-vis des plates-formes cibles. Dans un premier temps, ce chapitre s’est donc
focalisé 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 de
rè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 ressources
que 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 nous
avons développé, cinq axes ont été abordés.
Le premier axe concernait l’identification des concepts mis en correspondance. Les
concepts impliqués dans les transformations sont en effet identifiés par des noms de classes
dans les métamodèles et peuvent être précisés par des critères. Nous avons alors admis que
les critères envisagés se formulaient dans les termes des métamodèles. Leur introduction
dans 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 aux relations 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éments qui
ne sont pas mis à contribution lors d’un déploiement (relations 1-0 ou N-0). Ce métamodèle
n’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 les
rè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 fournit
RTEPML. Des mécanismes génériques de mises en œuvre de prototypes de conception, de
renseignements des propriétés et de générations d’appels de services ont alors été introduits
dans 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 à renseigner
les propriétés ou les appels de services. La généricité des accès est alors assurée par une
convention de nommage et d’interprétation des fonctions. Cette convention s’appuie sur les
noms 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
(M Ma ), du métamodèle de plate-forme d’exécution (RTEPML), d’une plate-forme cible
(P DM) et d’un métamodèle de trace (M Mt ).
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 et
des concepts exécutif dépendaient du métamodèle de l’application. Les règles introduites
dans 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 des
projets 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èle
de 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 à chaque
plate-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 ces
fonctions 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és changent d’une
règle de correspondance ou d’une règle de trace à l’autre. Des templates ou des transforma-
tions de modèles, renseignés par des modèles qui capturent les correspondances entre les
concepts peuvent donc les générer.
Nous avons donc défini, un métamodèle de déploiement dédié à ces captures. Cette
première version du métamodèle permettait de décrire, par leur nom, les concepts mis en
relation ainsi que les critères qui les précisent.
Outre la formulation synthétique des correspondances, cette approche a l’avantage de
capturer les déploiements dans des modèles indépendants des technologies de 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 des templates
de règles adaptés aux nouvelles technologies.
Cette indépendance vis-à-vis de la technologie est valable dans les limites des
contraintes que nous avons soulignées. L’implantation de l’algorithme nécessite en effet
que la technologie de transformation permette d’exprimer des prédicats sur les éléments
des modèles, offre un contexte impératif pour l’exécution de certaines règles et supporte
des 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 applicatif
avec 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 plusieurs
ressources conformes à un même concept exécutif.
La confrontation à un choix nécessitant de prendre une décision, le métamodèle de
déploiement que nous venions d’introduire a été étendu pour capturer des décisions. En
réponse à un choix, une décision prend alors la forme d’une correspondance entre des
concepts 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 entre
les 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 en précisant des
correspondances 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-forme
cible. Il décrit ce que l’on peut déployer. Un modèle de décision dépend de ces modèles. Il
dé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 aux choix.
Processus de déploiement
La figure 4.19, page ci-contre, illustre le processus de déploiement auquel nous avons
abouti. 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 les
templates de génération impliqués dans le processus sont répartis dans différents packages .
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 de templates pour :
– la génération des règles de correspondances (templates4rtepml) ;
– la génération des règles de traces (templates4trace).
Enfin, à partir des templates et d’un modèle de décision, le processus génère les règles
de correspondances utiles au déploiement (X2rtepml).
F IG . 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 des fonc-
tions, tant pour l’expression des critères (helpers4X) que pour la localisation et la traduction
d’informations (X4rtepml et X4platform).
D’autres perspectives d’outillages concernent également la description des déploie-
ments (Xdeployement et Application2Platform).
Pour ce qui concerne la forme (ou la syntaxe), ces descriptions se réfèrent en particulier
au 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éments
susceptibles d’être référencés et qui offre des facilités de mises en correspondance, comme
le 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’une
ré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 interface avec des outils d’aide
à la décision est donc à prévoir. Un échange avec de tels outils nécessite en particulier de
décrire les choix possibles (issus du modèle de déploiement) [25], de formuler des critères
sur des ressources identifiées (telle que la minimisation de l’espace mémoire et des temps
d’exécution) [81] [105] et de traduire les décisions prises dans les termes du métamodèle
de déploiement. Une étude est actuellement menée pour mettre en œuvre cette approche.
Évaluation
5
Sommaire
5.1 Expérimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
5.1.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
5.1.2 Outillage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
5.1.3 Processus comparés . . . . . . . . . . . . . . . . . . . . . . . 132
5.2 Critères de comparaison . . . . . . . . . . . . . . . . . . . . . . . . 134
5.3 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.3.1 Composantes pour l’application . . . . . . . . . . . . . . . . . 135
5.3.2 Composantes pour l’exécution . . . . . . . . . . . . . . . . . . 135
5.3.3 Composantes pour la transformation . . . . . . . . . . . . . . . 138
5.3.4 Choix de déploiement . . . . . . . . . . . . . . . . . . . . . . 141
5.4 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
e chapitre propose une évaluation du processus que nous venons de définir. Cette éva-
C 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 durant
cet é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érimentations
que 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 que nous avons obtenus
sont 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érations
implicites des plates-formes, telles que le pratiquent d’autres approches de déploiement
identifiées dans l’état de l’art de ce rapport. Plusieurs expérimentations ont donc été menées
pour 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 code
conforme à des standards du domaine de l’embarqué et du temps réel (tels que O SEK /V DX
ou A RINC -653), à partir de descriptions A ADL ou de D SL « maison » d’applications de
robotiques. 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 du
support d’exécution, en un modèle dépendant de ce support. La seconde phase, que nous ne
détaillerons pas, fut assurée par des technologies de génération de code par templates .
F IG . 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 communicant
entre elles ou avec l’environnement.
5.1.2 Outillage
Les expérimentations autour de descriptions A ADL ont été menées sur des modèles
conformes au métamodèle standard d’A ADL (métamodèle au format Ecore, intégré dans
l’outil O SATE [104]). Ce métamodèle se compose de sept packages (core, component, fea-
ture, connection, flow, property et instance) qui totalisent 198 classes.
Les D SL « 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 A MMA (ATLAS Model Management Archi-
tecture) [65] tels que K M 3 (Kernel Meta Meta Model) [56] pour les syntaxes abstraites et
T CS (Textual Concret Syntax) [57] pour les syntaxes textuelles concrètes.
L’atelier T OPCASED (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 outils
dans 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 et
appliquer les templates de génération de règles ATL et de génération des codes source des
applications (durant la seconde phase du processus).
132 Chapitre 5. Évaluation
F IG . 5.2: Éditeurs développés et intégrés à l’atelier TOPCASED pour mener les expérimentations.
5.1.3 Processus comparés

Comme cela fut mentionné en introduction de cette section, le processus de déploiement
proposé dans cette étude s’appuie sur des descriptions explicites de 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ésentations implicites des plates-formes. Ces approches capturent les
informations 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 la
plate-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 sur
des descriptions implicites de plates-formes. Le premier processus génère directement un
modèle d’application. Le second se scinde en deux étapes qui s’articulent autour d’une
plate-forme abstraite pivot. Le principe de ces deux approches a été présenté dans le chapitre
de l’état de l’art. Enfin, la troisième sous-figure (5.3c) reprend le processus de déploiement
que 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.
F IG . 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 »

(ou packages ) que l’on peut répartir en trois familles :
– Les composantes liées à la technologie de l’application, telles que les métamodèles
et les modèles d’applications, et les fonctions (ou helpers ) 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 à la technologie d’exécution, telles que les métamodèles des
plates-formes d’exécution ou du pivot, le métamodèle RTEPML, les modèles de
plates-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 aux transformations, telles que les règles de correspondances,
les modèles de déploiements, les librairies de règles, les templates de génération de
règles et les fonctions de traduction des valeurs d’une technologie à une autre.
Au sein de cette dernière famille nous pouvons également discerner les composantes
dédiées à un ou plusieurs déploiements. La figure 5.3 regroupe ces composantes dans des
packages estampillé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 connaissances
requises 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 de
développer les composantes et la capacité à répartir ces développements entre des ingénieurs
spécialisés. La séparation des connaissances entre les différentes composantes est l’un des
objectifs affichés d’une ingénierie dirigée par les modèles. Les connaissances identifiées
dans cette étude se répartissent entre le domaine de l’application, la plate-forme d’exécution
cible 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. Une
activité 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 qui
peut être faite d’une même composante pour le déploiement d’une application si l’une des
technologies change (pour l’applicatif ou l’exécutif). Le changement auquel nous faisons
référence concerne un changement radical de technologie. L’adaptation des composantes
suite à une évolution de l’une des technologies ne sera pas abordée dans ce 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 et l’automatisation
de 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 risque
d’introduction de fautes. La taille est généralement corrélée avec le temps de développement
et la facilité de maintenance.
Enfin, la prise en compte de décisions face à des choix de déploiement sera également
abordé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 technologies
d’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 des critè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ée
entre ces fonctions d’une approche à une autre. Dans tous les cas, les besoins de parcours
des modèles ou d’expression des critères ont été identiques. Quelque soit l’approche, la
considé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 sont
identiques 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, helpers4pivot et helpers4rtepml).
Les tableaux 5.1 et 5.2, page suivante, résument les résultats relatifs aux développements
de 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 domaine
du temps réel et de l’embarqué.
Ce tableau rappelle que les approches qui décrivent implicitement les plates-formes
d’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 des
applications déployées sur la plate-forme abstraite intermédiaire qui joue le rôle de pivot.
1
Dans ce tableau, M M se réfère à un métamodèle, M à un modèle et la plate-forme est qualifiée de cible.
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 de
chacune se concrétise alors par le développement d’un modèle conforme à ce métamodèle.
M Mcible M Mpivot M Mcible RTEPML Mcible
Domaine cible ETR cible ETR cible
Temps + − + − ++
Taille + − + − ++
Maintenance + + + + ++
Réutilisation − + − ++ −
Domaine : cible (plate-forme cible), ETR (embarqué temps réel) ;
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 de
plate-forme cible, seule quelques parties du métamodèle qui décrit implicitement la plate-
forme d’origine peuvent être réutilisées (par exemple, celles qui traitent des notions de
fonction 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 les
dé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 de
dé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 concepts qu’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 ce
mé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écution et les applications
dé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 les
applications. Tout déploiement d’application s’appuie donc essentiellement sur celui-ci.
Enfin, comme cela vient d’être mentionné, cette approche décrit explicitement les
plates-formes dans des modèles. Le développement, la taille et la maintenance de ces 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 qui
concernent 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-formes
alternatives, 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èle de 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 fonctions d’accès
aux informations des modèles2 . Ces fonctions servent pour collecter des données et pour
exprimer 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 et
sont 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 − ++ − ++
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 un
développement supplémentaire pour associer des fonctions à ce pivot. Cet investissement
reste toutefois modeste (comparé à l’étude et au développement du pivot) et rentable en
raison de la forte réutilisation de ces fonctions. Quelque soient la technologie source et la
plate-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 prototypes
de 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 le
dé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 de
l’application source et toute plate-forme cible.
L’approche par pivot nécessite donc un développement supplémentaire de fonctions
pour accéder aux informations d’un pivot, alors que l’approche proposée dans cette étude
investit dans un ensemble de fonctions génériques pour accéder aux informations de toutes
les plates-formes cibles.
2
Dans 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ées
dans un déploiement d’application sont :
– les règles de correspondances (X2platform, X2pivot et pivot2platform) ;
– les librairies de règles (rules4rtepml et rules4trace, pour l’approche explicite) ;
– les templates de génération de règles (templates4rtepml et template4trace) ;
– les modèles de déploiements (Xdeployment et Application2Platform) ;
– les fonctions de traduction de valeurs d’une technologie à une autre (X4platform,
X4pivot, pivot4platform et X4rtepml).
Le tableau 5.3, page ci-contre, résume les résultats relatifs aux développements de ces
composantes 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éploiement et des templates de
gé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 sur
le même principe de développement : des règles de correspondances associent des concepts
identifiés par les métamodèles sources et cibles impliqués, et des fonctions traduisent les
valeurs 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 des
concepts 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 approche
conduit à une scission du processus de déploiement en deux transformations. Un ensemble
de 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 entre
deux ensembles de règles. Le premier offre des règles génériques à toutes les plates-formes
et 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 ces templates , à partir de mo-
dèles de correspondances. Un modèle de déploiement, indépendant de la plate-forme cible,
décrit les correspondances entre les concepts applicatif et les concepts que sont susceptibles
de fournir les plates-formes d’exécution. Un modèle de décision raffine ensuite un modèle
de 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 de templates pour appliquer ces modèles.
Enfin, cette troisième approche introduit un ensemble de fonctions chargées de localiser
les informations dans le modèle de l’application avant que d’autres fonctions les traduisent.
Les résultats qui concernent les règles de transformations des deux première approches
ont été justifiés et commentés dans l’état de l’art de ce rapport. Nous y avons conclu que la
première approche ne semble intéressante que lorsque très peu de plates-formes d’exécution
cibles sont envisagées. Dans le cas contraire, l’investissement dans le développement d’un
pivot 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’une plate-forme al-
ternative nécessite le développement complet d’une nouvelle transformation. De plus, leur
3
Dans ces tableaux, R se réfère à un ensemble de règles, M à un modèle de déploiement et F à un ensemble
de 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 et

des 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 en
conservant des temps de développement du même ordre que pour l’approche précédente.
(1) (2) (3)
Rapp2cible Rapp2pivot Rpivot2cible Mapp2rtepml Mapp2cible Rlib
application application ETR application application
Dom. 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 les templates de génération de règles.
(1) (2)
Fapp2cible Fapp2pivot Fpivot2cible Fapp2rtepml Fapp2cible
application application ETR application application
Domaine
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).

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 un
ensemble 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 œuvre du 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. Tout
déploiement d’application s’y réfère, quelque soient la technologie source et la plate-forme
d’exécution cible. De plus, la taille, en nombre de lignes, de ces règles n’altère pas leur
maintenance, 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 templates de
génération de règles. Ces templates sont impliqués dans tous les déploiements. Ils per-
mettent de réduire l’expression des correspondances, entre les concepts applicatif et les
concepts 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 localisation
d’information. Un modèle de déploiement exprime des correspondances entre les concepts
du 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 de
l’application susceptibles de renseigner des propriétés ou des appels de services.
Un modèle de correspondance est concis sur l’expression des règles, ce qui favorise
les temps de développement et la maintenance. De plus, l’absence de concepts propres aux
plates-formes cibles lui confère une capacité de réutilisation relativement élevée. Un modèle
de 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 ce
rapport, une assistance à leur développement est envisageable. Leur temps 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 le
dé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 une
plate-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’application
pour la plate-forme d’exécution cible.
Comme pour un modèle de déploiement, l’expression des décisions est concise, ce qui
favorise leur temps de développement et leur maintenance. Durant les expérimentations, le
temps passé pour l’élaboration des modèles de décisions a plus été consacré à la prise de
décision qu’à la formulation des décisions. Toutefois, un modèle de décision n’est valable
que 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 toutefois utilisables
pour toutes les applications du domaine. Contrairement au modèle de décision qui n’est
parfois valable que pour une application donnée.
Au bilan, l’approche que nous proposons nous a permis de simplifier l’expression des
dé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 des
fonctions qui l’accompagne nécessite plus de temps et de réflexion, elle semble également
plus 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 du
domaine de l’application et des plates-formes d’exécution. La technologie de transformation
ne concerne que les règles génériques et les templates de 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 reposent sur des technologies
5.3. Résultats 141
dédiées au parcours des modèles ou à l’expression de contraintes (tel qu’O CL) et, d’autre
part, des perspectives d’assistances à leur développement permettront certainement à terme
de 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ères
précédemment abordés. En effet, chacune des approches possède ses spécificités et ses pro-
blématiques en ce qui concerne ces choix. Cette sous-section présente donc un retour sur la
gestion des choix que nous avons mise en œuvre pour les deux première approches, avant
d’évaluer la gestion qui accompagne notre approche.
La première approche (enfouie) s’appuie sur une transformation propre à la plate-forme
d’exécution cible. Seules des choix pratiques sont donc susceptibles de survenir. Comme
cette 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èles
exprimaient 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 ces décisions. Aucune
investigation 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 conceptuels et pratiques sont donc susceptibles de survenir. Or,
les deux niveaux de considération sont séquentiels dans le processus de transformation de
cette 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 sur
les choix conceptuels dès le premier déploiement. Ces prises de décisions soulèvent alors
la 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écisions
ont é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’identifie le métamodèle de
plate-forme d’exécution ou ceux de la plate-forme cible. Des choix conceptuels et pratiques
sont donc également susceptibles de survenir. Mais, cette approche ne se confronte pas à la
problématique de l’approche par pivot. En effet, les deux niveaux de considération ne sont
pas séquentiels dans une transformation, mais séquentiels dans le processus de construction
d’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) qui
raffine 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 domaine
des plates-formes d’exécution temps réel embarquées). Ces décisions prennent la forme de
correspondances qui décrivent un déploiement.
L’approche que nous proposons apporte donc une solution à la gestion des choix qui
couvre les choix conceptuels et pratiques. Cette solution à l’avantage de concentrer les
dé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 de
l’é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ègles
gé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. Ces
modèles intègrent de plus une gestion des choix de déploiements qu’il est difficile de mettre
en œuvre dans les approches concurrentes.
Les expérimentations que nous avons menées révèlent également que cette approche
peut s’avérer plus efficace qu’une description implicite lorsqu’une seule plate-forme est
envisagée. En effet, la plate-forme est décrite dans un modèle beaucoup plus simple à déve-
lopper qu’un métamodèle et l’expression d’un déploiement se concrétise par des modèles
beaucoup plus concis qu’un ensemble de règles de transformation.
Quelque soit le contexte, l’investissement que nécessite l’approche que nous proposons
peut 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 K M 3 et Ecore) ;
– d’éditeurs RTEPML textuels et graphiques, compatibles avec Eclipse, développés
dans l’atelier T OPCASED ;
– d’un métamodèle et d’un éditeur textuel de déploiements ;
– de templates Acceleo de génération de règles ATL ainsi que des bibliothèques de
règles ATL qui les accompagnent ;
– de helpers ATL de localisation d’informations dans des modèles de plates-formes ;
– de helpers ATL de localisation d’informations dans des descriptions A ADL.
4
http://trame.eseo.fr
Conclusion
Synthèse
Les travaux de cette thèse avaient pour objectif d’étudier la considération des 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 I DM de
modélisation des plates-formes d’exécution dans un objectif de déploiement d’applications
et (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-formes
d’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, dans
une approche asynchrone. L’approche M DA 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 sur
des 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 des
plates-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éploiement
d’applications (chapitre 2). Cet état de l’art a été mené dans des contextes de modélisation
basés sur des D SML et sur des G PML (et plus particulièrement U ML). Les déploiements
abordés couvraient la génération de modèles de codes source et la génération de modèles
d’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 les
informations 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 de
déploiement ont été présentées. Ces pratiques étaient issues de travaux existants 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 partie
s’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 D SML.
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 les
ré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 en
deux approches, selon qu’une transformation génère directement l’application déployée ou
qu’un pivot intermédiaire est introduit. Parallèlement, les processus de déploiement basés
sur des descriptions explicites se déclinent en quatre approches, en fonction des relations
entre les métamodèles de l’application, de la plate-forme d’exécution et de l’application
dé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’une promotion du
modèle de la plate-forme ou conforme à un métamodèle différent et indépendant de celui
de 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-formes
cibles 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 des
contextes de modélisation U ML et D SML, que l’on souhaite générer un modèle de code
source ou un modèle indépendant de toute technologie de codage.
L’approfondissement que nous avons mené dans un contexte D SML a montré que la
repré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 projets dans lesquels une
seule plate-forme d’exécution est envisagée.
Un langage de modélisation de plates-formes d’exécution temps réel embarquées

a été défini. Ce langage, présenté sous le nom de RTEPML (Real-Time Embedded Platform
Modeling Language), s’appuie sur le motif ressource/service et les concepts du domaine du
temps réel et de l’embarqué qu’identifie le package S RM du profil U ML-M ARTE. RTEPML
permet de modéliser des plates-formes d’exécution dans un contexte de développement
utilisant des D SML comme alternative aux G PML (tel qu’U ML).
RTEPML permet de décrire les ressources qu’offre un système d’exploitation temps réel
embarqué ainsi que l’A PI des services associés à ces ressources. Des prototypes de mise
en œuvre de mécanismes exécutifs peuvent être précisés. RTEPML fournit également un
support 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 erreurs ou des modes
de 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’un
déploiement d’applications.
Un processus de déploiement d’applications basé sur RTEPML a été développé. Ce

processus se concrétise par des transformations de modèles. Il repose sur le mécanisme
d’intégration d’applications introduit dans RTEPML. L’originalité de ce processus réside
dans 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é à des templates , 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écisions
qui répondent à des choix de déploiement (ces choix peuvent concerner toutes ou une seule
application 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 toute technologie de
transformations.
Une implantation ATL a été développée pour outiller l’approche et l’expérimenter. A
l’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èles
et ensembles de fonctions. L’introduction d’un langage dédié au déploiement aboutit à des
descriptions concises, rapides à développer et faciles à maintenir. Enfin, la construction in-
crémentale que propose le processus, en fonction des technologies impliquées, permet de
capitaliser sur les modèles et les fonctions qui composent les transformations.
Perspectives
Les suites à donner à cette étude se répartissent en trois axes. Le premier vise à améliorer
la modélisation des plates-formes d’exécution et le processus de déploiement proposés. Le
second et le troisième axes visent à étendre ces principes de modélisation et de déploiement
à d’autres domaines d’applications et à un contexte de modélisation G PML.
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 aux
concepteurs des déploiements de vérifier que les règles de transformations produisent des
systè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 fait
actuellement 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 du package S RM d’U ML-M ARTE. Ces concepts ne sont toutefois
pas suffisants. Ils devront être complétés pour couvrir des mécanismes supplémentaires que
sont susceptibles de fournir les systèmes d’exploitation temps réel embarqués (telle que la
gestion 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, par
exemple, 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 au

rythme des avancés technologiques des systèmes d’exploitation existants (contrairement à
un métamodèle de langage de programmation). Son maintien nécessitera une veille perma-
nente. Son évolution soulèvera également la question de l’évolution des outils qui 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 fonctions
qui 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. Cette phase devra être
couplé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ération d’un modèle
d’application indépendant de toute technologie de codage. Bien que des expérimentations
aient permis de générer des codes source, les mises en œuvre possibles pour cette phase
n’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 à part
entière. En particulier, les relations entre les plates-formes d’exécution et les langages de
programmation doivent être précisées.
Enfin, l’utilisation d’un métamodèle de plates-formes d’exécution offre la perspective
d’unifier les représentations explicites des plates-formes d’exécution et d’en faciliter ainsi
leurs 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é à la
description des plates-formes d’exécution du domaine de l’embarqué et du temps réel. Cette
démarche vise à fournir une base commune pour capitaliser les efforts de développement
d’un tel métamodèle. Des collaborations autour d’un même métamodèle de plate-forme
d’exécution, dans la lignée de ce que propose le profil U ML-M ARTE dans un contexte U ML,
seraient également bénéfiques dans un contexte de modélisation D SML.
Étendre l’approche à d’autres domaines
Nous nous sommes intéressés, dans cette étude, aux déploiements d’application sur des
plates-formes d’exécution logicielles embarquées temps réel. Or, bien que nous n’ayons pas
identifié 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 être
mené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ée sur des repré-
sentations explicites des plates-formes, vis-à-vis d’une approche par pivot, pourront être
confirmé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, par
exemple, 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 G PML

Les travaux de cette étude ont été menés dans un contexte de modélisation basé sur des
D SML. En complément des travaux existants sur le portage d’applications dans un contexte
U ML, basés notamment sur le profil U ML-M ARTE, l’approche de déploiement que nous
avons proposée pourra être généralisée à ce contexte. Des travaux sont actuellement menés
sur ce sujet.
Troisième partie
Annexes
A
Mé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 K M 3 [56])
-- @name RTEPML
-- @version 1.0
-- @authors matthias.brun@eseo.fr (@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 concept

reference 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 concepts

attribute isAbstract : Boolean;
reference supertype : Resource;
-- add prototype concept

reference prototype[0-1] container : Prototype;
-- add platform native resource instance concept

reference 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 de RTEPML
---------------------------------------------------------------
-- 1.2 -- Resource Instance and Resource Instance Property
---------------------------------------------------------------
class ResourceInstance extends NamedElement {

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 {

}
class CallService extends LocatedElement {

reference parameters[*] ordered container : CallParameter;
reference service : ResourceService;
}
class CallParameter extends LocatedElement {

reference parameter : ServiceParameter;
attribute val : String;
}
---------------------------------------------------------------
-- 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 concept

reference entryPointElements[*] : ResourceProperty;
reference prototypeEntryPointElement : PrototypeResourceInstance;
reference addressSpace : MemoryPartition oppositeOf

concurrentResources;
}
---------------------------------------------------------------
-- 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[*] :
}
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[*] :
}
---------------------------------------------------------------
-- 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;
}
}
B
Extraits de transformations ATL
163
Transformation de promotion
La transformation Platform2Meta du 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 transformation Platform2Meta (en ATL)
1 -- Transformation Platform2Meta
2 --
3 -- Promote a platform model into an application metamodel.
4 --
5 module Platform2Meta;
6 create OUT : MMM from IN : Platform;
7
8 -- Rule Platform2Metamodel
9 --
10 -- Create a metamodel of application from a platform description.
11 --
12 rule Platform2Metamodel {
13 from platform : Platform!Platform
14 to
15 metamodel : MMM!Metamodel (
16 classes <- Sequence{application}->union(platform.resources)
17 ),
18 application : MMM!Class (
19 name <- ’Application’,
20 ref <- platform.resources
21 )
22 }
23
24 -- Rule Resource2Class
25 --
26 -- Create a metaclass for each resource. Create first a reference to that
27 -- metaclass, in order to reference the created metaclass in the application.
28 --
29 rule Resource2Class {
30 from resource : Platform!Resource
31 to
32 reference : MMM!Reference (
33 contain <- true,
34 cardinal <- ’-1’.toInteger(),
35 class <- class
36 ),
37 class : MMM!Class (
38 name <- resource.name,
39 attributes <- Sequence{resource.properties}
40 ),
41 name : MMM!Attribute (
42 name <- ’name’,
43 type <- #String
44 )
45 }
46
47 -- Rule Property2Attribute
48 --
49 -- Create attribute of meta-class from property of resource.
50 --
51 rule Property2Attribute {
52 from property : Platform!Property
53 to
54 attribute : MMM!Attribute (
55 name <- property.name,
56 type <- property.getType()
57 )
58 }
164 Annexe B. Extraits de transformations ATL
Transformations de déploiements basées sur RTEPML

Helper getResource (version simple)
Le listing B.2 présente une implantation simplifiée d’un helper ATL (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 ce helper est donné à la suite de sa
définition, au sein d’une règle Activity2SchedulableResourceInstance1 .
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 getResource
2 --
3 -- Parameter : A metaclass of metamodel conform to MOF.
4 -- Return : The first class of a model that conforms to
5 -- the metaclass parameter passed to the helper.
6 -- RTEPML use : Return a platform resource conforms to
7 -- an executive concept identified by a metaclasse.
8 --
9 helper def: getResource(metaclass : MOF!EClass) : MOF!EClass =
10 metaclass.allInstances()->first();
11
12 -- Rule Activity2SchedulableResourceInstance
13 --
14 -- Generate an RTEPML instance resource typed by a
15 -- schedulable resource from a ROBOT activity.
16 --
17 rule Activity2SchedulableResourceInstance {
18 from s : ROBOT!Activity
19 to
21 ...
22 type <-
23 thisModule.getResource(RTEPML!SchedulableResource),
24 ...
25 ),
26 ...
27 }
Le helper getResource du listing B.2 s’appuie sur l’opération O CL allInstances fournie

par ATL. Cette opération retourne l’ensemble des classes conformes à la classe à laquelle
elle s’adresse.
Dans cette version du helper , 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 du helper getResource, tel que nous l’avons défini, se fait au
travers 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 du helper ATL getResource (in-
troduit dans la sous-section précédente) permettant de prendre en considération des critères
associés à des classes. Ce helper permet ainsi de localiser, dans un modèle de plate-forme
d’exécution, une ressource conforme à une classe de RTEPML, dans le respect du critère qui
l’accompagne.
1
Cet 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 getResource
2 --
3 -- Parameters : A metaclass of metamodel conform to MOF,
4 -- a criterion that correspond to an operation (helper) and
5 -- a sequence of parameters associated to the criterion helper.
6 -- Return : The first class of a model that conforms to
7 -- the metaclass respecting the criterion.
8 -- RTEPML use : Return a platform resource conforms to an executive
9 -- 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 =
14
15 thisModule.getResources(metaclass, criterion, parameters)->first();
16
17 -- Helper getResources
18 --
19 -- Parameters : A metaclass of metamodel conform to MOF,
20 -- a criterion that correspond to an operation (helper) and
21 -- a sequence of parameters associated to the criterion helper.
22 -- Return : A set of class of a model that conforms to
23 -- the metaclass respecting the criterion.
24 --
25 helper def: getResources( metaclass : MOF!EClass,
26 criterion : String,
27 parameters : Sequence(String) ) : Set(MOF!EClass) =
28
29 let resources : Set(MOF!EClass) =
30 metaclass.allInstances()->asSequence() in
31
32 if criterion.oclIsUndefined()
33 then resources
34 else resources
35 ->select(r|r.refInvokeOperation(criterion, parameters))
36 endif;
La partie du helper getResource chargée de récolter l’ensemble des ressources est fac-
torisée dans un helper getResources défini à la suite. Ce helper se charge alors de localiser
les ressources en s’appuyant, dans un premier temps, sur l’opération O CL allInstances, que
nous avons évoquée dans la version simple, et en appliquant, dans un second temps, si un
critère est stipulé, une sélection (select) sur l’ensemble retourné.
Au sein de cette sélection, l’opération O CL refInvokeOperation, également fournie par
ATL, est mise à contribution pour évoquer le helper du critère dont le nom est passé en pa-
ramètre (sous forme d’une chaîne de caractères). L’appel à ce helper peut être accompagné
de paramètres transmis dans une séquence.
Un exemple d’utilisation de ce helper est donné dans la suite de cette annexe, au sein
d’une règle XConcept2XResourceInstance, page 168.
Helper getProperty (version simple)

Cette sous-section présente deux implantations simplifiées du helper ATL getProperty
permettant 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 de
helpers dédiés à chaque propriété. Ces helpers sont alors évoqués à partir du helper getPro-
perty. La seconde implantation propose un helper getProperty générique, qui ne nécessite
plus d’appels à des helpers dédiés.
Chacune de ces implantations se réfère aux algorithmes 4.2 et 4.4, introduits dans le
chapitre 4, page 82.
Utilisation de plusieurs helpers dédiés
Le listing B.4 présente une implantation simplifiée d’un helper ATL getProperty qui
met à contribution un ensemble de helpers dé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 role
5 -- 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{});
12
13 -- Helper getPriorityElement
14 --
15 -- Return : An element which the role corresponds to
16 -- ’Priority’ as defined in RTEPML.
17 -- Use : helper getPriorityElements
18 --
20 def: getPriorityElement() : RTEPML!ResourceProperty =
21 if (self.oclIsKindOf(RTEPML!ConcurrentResource))
22 then self.getPriorityElements()->first()
23 else OclUndefined
24 endif;
25
26 -- Helper getPriorityElements
27 --
28 -- Return : A set of elements whose the roles correspond to
29 -- ’Priority’ as defined in RTEPML.
30 --
32 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 helper getProperty de cette approche s’appuie sur l’opération O CL refInvokeOpe-

ration fournie par ATL. Comme cela fut évoqué précédemment, cette opération permet
d’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 des helpers de la forme
getXXXElement où XXX est un nom de rôle attribué à une propriété. Le helper getPrio-
rityElement, ligne 19, retourne par exemple la propriété correspondant à la priorité d’une
ressource concurrente. Ce helper peut alors être invoqué via l’appel getProperty(’Priority’).
On remarquera l’utilisation d’un helper récursif getPriorityElements chargé de récolter
les propriétés dont le rôle correspond à une priorité dans l’ensemble des classes dont hérite
le 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 des helpers
dé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’un helper ATL getProperty géné-
rique.
Listing B.5: getProperty : localisation d’une propriété (version simple, générique, en ATL)
1 -- Helper getProperty (generic)

2 --
4 -- Return : A resource property in the platform model which role
5 -- corresponds to the role parameter passed to the helper.
6 -- Use : helper getPropertyElements
7 --
9 def: getProperty(property : String) : RTEPML!ResourceProperty =
10 self.getPropertyElements(property + ’Element’)->first();
11
12 -- Helper getPropertyElements
13 --
15 -- Return : A set of elements whose the roles correspond to
16 -- which is passed to the helper, as defined in RTEPML.
17 --
19 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 getProperty de cette approche, ou plus précisément le helper getProper-

tyElements mis à contribution, s’appuie sur l’opération O CL refGetValue fournie 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ètre
de 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 associations
porteuses des rôles attribués aux propriétés. Au sein du helper getProperty, les noms des
associations sont reconstitués sous la forme XXXElement, où XXX est le nom du rôle. Ce
helper peut donc, par exemple, être invoqué via l’appel getProperty(’priority’). L’accès à
la propriété concernée se fera alors via l’association priorityElement qui identifie le rôle de
priorité pour une propriété.
On remarquera l’utilisation, dans cette version également, d’un helper récursif getPro-
pertyElements chargé de récolter les propriétés dans l’ensemble des classes dont hérite le
concept concerné. Le rôle de la propriété recherchée est passée en paramètre à ce helper .
Cette approche présente l’avantage d’être rapide à implanter, puisqu’elle ne nécessite
pas d’autres helpers . 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 les helpers récursifs de la version précédente (multi-helpers ) par le
helper récursif générique de cette version.
Règle XConcept2XResourceInstance (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ègle
ATL 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 (respectivement XConcept et XResource) précisée
par un critère (XConceptCriterion et XResourceCriterion).
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 XConcept2XResourceInstance
2 --
3 -- Translate an application XConcept into a platforme resource instance
4 -- typed by XResource. Both XConcept and XResource have criterion.
5 --
6 rule XConcept2XResourceInstance {
7
8 from s : Application!XConcept (
9 s.XConceptCriterion()
10 )
11
12 to t : RTEPML!ApplicationResourceInstance
13 type <- thisModule.getResource(
14 RTEPML!XResource, ’XResourceCriterion’, Sequence{}
15 ),
16 ...
17 ),
18 ...
19 }
Dans l’exemple proposé, les critères sont exprimés par des helpers ATL. L’implantation
de ces helpers , que nous ne détaillerons pas, se fait en O CL.
Le critère sur le concept applicatif est pris en compte au sein d’une pré-condition
d’application (ou d’exécution) de la règle (ligne 9). Le critère sur le concept exécutif est
passé comme paramètre au helper getResource, via le nom du helper qui capture ce critère
(ligne 14). Remarque : Un ensemble de paramètres peut accompagner le helper du critère.
Ceux-ci sont alors transmis par une séquence (vide dans l’exemple) dans le dernier para-
mètre du helper getResource.
Le helper getResource permettant de prendre en compte des critères associés aux classes
est présenté dans cette annexe page 164.
Règle XConcept2XResourceInstance (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és
dans les correspondances, avant de les appliquer. La première mise en œuvre conditionne
l’application d’une règle au plus haut niveau de la transformation. La seconde influe sur le
dé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-formes
cibles 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 ressources
avec des règles ATL déclaratives (la règle d’origine XConcept2XResourceInstance est 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.10
du chapitre 4, page 92.
Listing B.7: XConcept2XResourceInstance : exemple générique (disponibilité 0/1 (a), en ATL)
2 --
5 --
7
10 and
11 thisModule.getResources(
13 )->notEmpty()
14 )
15
16 to t : RTEPML!ApplicationResourceInstance
17 type <- thisModule.getResource(
19 ),
20 ...
21 ),
22 ...
23 }
24
25 -- Rule XConcept2notXResourceInstance
26 --
27 -- Trace the lack of XResource (with XResourceCriterion)
28 -- in the target execution platform.
29 --
30 rule XConcept2notXResourceInstance {
31
34 and
35 thisModule.getResources(
37 )->isEmpty()
38 )
39
40 -- 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ée
pour 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 les
instructions 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 le helper getRessources pour évaluer l’ensemble des
éléments conformes au concept envisagé dans le modèle de la plate-forme (modèle transmis
comme paramètre à la transformation). Si cet ensemble n’est pas vide (not empty), la mise
en œuvre du mécanisme applicatif est effectuée. Dans le cas contraire, une trace est générée.
Le helper getResources mis à 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 ressources
au sein d’une règle ATL.
Cette implantation oriente l’exécution de la règle, selon que la plate-forme fournit ou
ne fournit pas de ressource conforme au concept attendu. Ce mécanisme est présenté dans
l’algorithme 4.11 du chapitre 4, page 92.
Listing B.8: XConcept2XResourceInstance : exemple générique (disponibilité 0/1 (b), en ATL)
2 --
5 --
6 -- Trace the lack of XResource (with criterion) in the target platform.
7 --
9
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 resource
21 thisModule.CreateResourceInstance(s, resource);
22 } else {
23 -- Trace the lack of resource
24 thisModule.TraceLackOfResource(s, resource);
25 }
26 }
27 }
28
29 -- Rule CreateResourceInstance
30 --
31 -- Called rule that generate an application resource instance typed by
32 -- the resource passed to the rule in the second parameter, from the
33 -- 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 element
39 resource : RTEPML!Resource -- platform resource
40 ) {
41 to
43 ...
44 type <- resource,
45 ...
46 ),
47 ...
48 }
171
L’orientation du déroulement de la règle XConcept2XResourceInstance est implantée

par un branchement conditionnel dans un contexte impératif (bloc do des lignes 18 à 26).
En effet, la technologie ATL ne permet pas d’exprimer des conditions sur la génération d’un
ensemble d’éléments, au sein d’une règle, dans un contexte déclaratif.
Dans ce contexte, deux règles sont explicitement appelées (CreateResourceInstance et
TraceLackOfResource), selon qu’une ressource conforme au concept envisagé est fournie
ou 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 la
génération des propriétés et des appels de services dans la suite de cette annexe).
Parallèlement, la règle TraceLackOfResource génère une trace si la plate-forme cible
ne fournit pas de ressource conforme au concept impliqué dans la règle. L’implantation de
cette 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 de
définition de variable (using, ligne 13 à 17). Cette localisation s’appuie sur le helper getRe-
source présenté dans cette annexe, page 164.
Règle XConcept2XResourceInstance (prototypes de conception)

Le listing B.9, page suivante, illustre l’introduction d’une prise en compte des
prototypes de conception dans une règle ATL (ce listing reprend la règle XCon-
cept2XResourceInstance pré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 en fonction 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ègles
est alors guidée par des pré-conditions. La seconde approche consiste à orienter l’exécution
d’une unique règle, par un branchement conditionnel, dans un contexte impératif.
Le premier mécanisme à l’inconvénient d’être coûteux en nombre de règles et donc plus
long à implanter. La solution présentée implante donc le second mécanisme. Ce mécanisme
a é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 de concep-
tion pour mettre en œuvre un concept donné, la règle XConcept2XResourceInstance invoque
explicitement une règle appropriée.
Ainsi, lorsque la ressource impliquée dans la règle est directement instanciable (aucun
prototype n’est présent), la règle CreateResourceInstance est invoquée (ligne 25). Cette
rè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ègle ClonePrototype est
invoquée (ligne 33). Cette règle génère alors un ensemble d’instances de ressources confor-
mément à ce que précise le prototype. La règle ClonePrototype est présentée dans la sous-
section suivante.
On remarquera qu’une séquence (variable) nommée SetOfInstances est initialisée avant
l’appel de la règle ClonePrototype (ligne 31). Cette structure y sera utilisée pour mémoriser
les instances générées à partir du prototype. Son rôle sera détaillée dans la suite de cette
annexe. On remarquera également qu’un chaîne vide est passée en second paramètre de la
règle ClonePrototype. 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)
2 --
5 -- A resource provided by the target platform conform to the XResource
6 -- may be described with a design prototype.
7 --
8 -- Trace the lack of XResource (with criterion) in the target platform.
9 --
11
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 resource
25 thisModule.CreateResourceInstance(s, resource);
26
27 } else {
28 -- with prototype :
29 -- create resource instances according to the prototype,
30 -- (1) initialize a SetOfInstances structure
31 thisModule.initSequence(’SetOfInstances’);
32 -- (2) create the elements
33 thisModule.ClonePrototype(s, ’’, resource);
34 }
35 } else {
36 -- Trace the lack of resource
37 thisModule.TraceLackOfResource(s, resource);
38 }
39 }
40 }
Règle ClonePrototype
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ègle CloneProto-
type de 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ègle ClonePrototype est une règle ATL explicitement appelé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 des instances à générer si une hiérarchie de prototypes
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 instances
représentées dans le prototype est générée pour l’application (lignes 17 à 36). Dans un
second temps, ces instances sont mises en relation, à l’image des associations spécifiées
dans le prototype (lignes 39 à 42).
173
Listing B.10: ClonePrototype : appliquer un prototype de conception (en ATL)
1 -- Rule ClonePrototype
2 --
3 -- Called rule that generate application resource instances
4 -- and their associations according to a design prototype.
5 --
6 -- Parameters : A source application element, a prefix (used to identifie
7 -- instances when hierachic prototypes are used), and
8 -- a platform resource that provides a design prototype.
9 --
10 rule ClonePrototype(
12 prefix : String, -- prefix for the instance names
14 ) {
15 do {
16 -- Create resource instances according to the prototype
17 for (i in resource.prototype.instances) {
18
19 if ( i.isNotPlatformResourceInstance() ) {
20
21 -- the considered instance within the prototype
22 -- is not a platform native one (predefined)
23
24 if ( i.type.prototype.oclIsUndefined() ) {
25 -- without prototype :
26 -- generate an application resource instance
27 thisModule.CreateResourceInstanceFromPrototype(
28 source, prefix, resource, i );
29 } else {
30 -- with prototype :
31 -- recursive call
32 thisModule.ClonePrototype(
33 source, prefix + i.name, i.type );
34 }
35 }
36 }
37
38 -- Create resource instance associations according to the prototype
39 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-forme
d’exécution. Seule les instances propres au prototype engendre une génération d’instance
pour 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 que
l’instance à générer est typée par une ressource unique, directement instanciable, ou par
une ressource dont la mise en œuvre relève (elle aussi) d’un prototype de conception.
Dans le premier cas, une instance est générée via un appel à la règle CreateResourceIns-
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ègle ClonePrototype (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 mise
en œ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, en
préfixant le nom des instances par le nom du chemin de progression à travers la hiérarchie
de prototypes (le nom du chemin est donné par la concaténation des nom successifs des
instances 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ègle CreateAsso-
ciationFromPrototype est appelée (ligne 40). Cette règle est présentée dans la suite de cette
annexe, page 175.
Règle CreateResourceInstanceFromPrototype
Le listing B.11 illustre la génération d’une instance de ressource à partir d’une instance
de ressource stipulée dans un prototype de conception. La règle CreateResourceInstance-
FromPrototype de ce listing est mise à contribution dans le listing B.10 de la sous-section
précédente. Son principe est introduit dans l’algorithme 4.14 du chapitre 4, page 95.
La règle CreateResourceInstanceFromPrototype est 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 CreateResourceInstanceFromPrototype
2 --
3 -- Called rule that create an application resource instance
4 -- from an instance represented in a resourcedesign prototype.
5 --
7 -- instance when hierachic prototypes are used), a platform
8 -- resource that provides the design prototype, and the
9 -- considered instance.
10 --
11 rule CreateResourceInstanceFromPrototype(
13 prefix : String, -- prefix for the instance name
14 resource : RTEPML!Resource, -- platform resource
15 instance : RTEPML!PrototypeResourceInstance,
16 ) {
17 to
19 ...
20 name <- source.name + prefix + instance.name,
21 type <- instance.type,
22 ...
23 )
24 do {
25 -- Add created element into the SetOfInstances structure
26 thisModule.addSequence(’SetOfInstances’, t);
27 }
28 }
La règle CreateResourceInstanceFromPrototype génère une instance de ressource dont

le type est déduit de celui de l’instance spécifiée dans le prototype (ligne 21). On remarquera
l’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 des
associations entre les instances (dans la règle CreateAssociationFromPrototype introduite
dans la sous-section précédente et présentée dans la sous-section suivante).
Les helpers relatifs à la structure SetOfInstances sont présentées dans la suite de cette
annexe (page 177).
Règle CreateAssociationFromPrototype
Le listing B.12, page suivante, illustre la génération d’une association, dans le modèle de
l’application déployée, à partir d’une association stipulée dans un prototype de conception.
La règle CreateAssociationFromPrototype de ce listing est mise à contribution lorsqu’un
prototype est appliqué pour générer un ensemble d’instances (listing B.10, page 173). Son
principe est introduit dans l’algorithme 4.15 du chapitre 4, page 96.
La règle CreateAssociationFromPrototype est 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ègle CreateAssociationFromPrototype génère une association dont les extrémités
(src et dst) sont déduites des extrémités de l’association stipulée dans le prototype (lignes 22
et 23). Pour cela un helper getInstance est 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 soit
une instance de ressource propre à l’application, soit une instance de ressource prédéfinie
sur 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 au
travers de l’association match qui relie l’élément du prototype à l’instance de la plate-forme
qu’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ées SetOfInstances. Cette structure mémorise l’ensemble des
instances qui ont été générées à partir des éléments du prototype (ce principe a été introduit
dans la sous-section précédente). L’instance concernée est alors localisée dans la structure
SetOfInstances à partir de son nom. Les informations impliquées dans le nommage de l’ins-
tance sont fournies au helper , via le paramètre infoname.
Cependant, l’instance concernée a pu être générée à partir d’un élément du prototype
dont le type (la ressource) est directement instanciable, ou à partir d’un autre prototype de
conception (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 localisation
de l’instance s’appuie sur le helper getMasterName pour identifier l’instance « maîtresse »
qui ressort de la hiérarchie de prototypes (cf. Motifs de conception, page 69). Le nom de
cette 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 CreateAssociationFromPrototype
2 --
3 --
4 -- Called rule that create an application resource instance association from
5 -- an association between prototype resource instance in a design prototype.
6 --
8 -- instance when hierachic prototypes are used), a platform
9 -- resource that provides the design prototype, and the
10 -- considered association.
11 --
12 rule CreateAssociationFromPrototype(
14 prefix : String, -- prefix for the instance name
15 resource : RTEPML!Resource, -- platform resource
16 association : RTEPML!PrototypeResourceInstanceAssociation
17 ) {
18 to
19 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 }
26
27 -- Helper getInstance
28 --
29 -- Parameter : An information about an application resource instance that was
30 -- genereted from the ’self’ prototype resource instance.
31 -- Return : The application instance that was generated from the
32 -- ’self’ prototype resource instance.
33 --
34 helper context RTEPML!PrototypeResourceInstance
35 def : getInstance(infoname : String) : RTEPML!ResourceInstance =
36
37 if (self.isNotPlatformResourceInstance())
38 then
39 -- select the correct generated instance,
40 -- into the SetOfInstances structure
41 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 endif
47
48 else -- use platform resource instance
49 self.match
50
51 endif;
52
53 -- Helper getMasterName
54 --
55 -- Return : The name of the prototype resource instance whith ’master’ role.
56 --
57 helper context RTEPML!PrototypeResourceInstance
58 def: getMasterName() : String =
59
60 self.type.prototype.masterInstance.name +
61 if (not self.type.prototype.masterInstance
62 .type.prototype.oclIsUndefined())
63 then self.type.prototype.masterInstance.getMasterName()
64 else ’’
65 endif;
177
Structure SetOfInstances
Le listing B.13 présente la structure SetOfInstances mise à 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 sein des règles qui
concernent 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 SetOfInstance
2 --
3 -- A sequence of resource instances.
4 --
5 helper def : SetOfInstance : Sequence(RTEPML!ResourceInstance) =
6 Sequence{};
7
8 -- Helper initSequence
9 --
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{});
16
17 -- Helper addSequence
18 --
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) );
27
28 -- Helper selectSequence
29 --
30 -- Select an element into the sequence, by its name.
31 --
32 -- Parameters : The name of the sequence and
33 -- 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 structure SetOfInstances est une séquence d’instances de ressources définie par un

helper (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 les helpers refGetValue et refSetValue fournis par ATL.
Remarque : La sélection d’une instance dans la structure SetOfInstances s’appuie sur
le nom de l’instance pour la localiser. Une solution basée sur une comparaison d’élément
est également envisageable. L’utilisation d’une telle sélection nécessite alors de modifier
l’utilisation qui en est faite dans les algorithmes concernés.
Règle CreateResourceInstance (renseignement des propriétés)

Le listing B.14, page suivante, illustre l’implantation d’un mécanisme de renseignement
des 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 de
prototype de conception, est présenté dans l’algorithme 4.16, du chapitre 4, page 99.
La règle CreateResourceInstance a é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. Elle
est explicitement appelée par la règle XConcept2XResourceInstance (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ée
par la règle et l’élément source à l’origine de sa création (ligne 28). Cette structure sera
utilisée pour localiser les instances qui ont été générées, dans le but de les référencer. Le
référencement des instances au cours de la transformation a été présenté et discuté dans la
sous-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 parcourt pour 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 le helper getPropertyRoles (ligne 31). Ce helper ne
sera pas détaillé dans cette annexe. Son implantation se restreint à retourner une séquence
de noms de rôles (définis « en dur » dans le helper ).
Les propriétés renseignées sont celles dont dispose la ressource qui type l’instance sur
la 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 (lignes 39 à 47). La se-
conde concerne les propriétés renseignées par une référence vers une instance de ressource
(lignes 49 à 57). Les helpers getPropertyValues et getPropertyReferences se chargent de
collecter les valeurs ou les références. Leurs implantations, propres au mé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 à la
règle CreateResourceInstanceProperty. Cette règle, explicitement appelée, prend comme
paramè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 le helper getProperty que nous avons introduit
précédemment dans cette annexe (page 165). Une implantation de la règle CreateResour-
ceInstanceProperty est présentée dans la sous-section suivante.
L’implantation proposée pour cette seconde phase génère finalement une trace 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 est
déléguée à la règle CompletePropertyReferences (ligne 66). Une implantation de cette règle
est 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 une
instance qui n’a pas encore été générée) est présenté dans ce rapport, dans la sous-section
qui concerne le renseignement des propriétés (chapitre 4, page 102). Dans l’implantation
proposée, la détection et la mémorisation des propriétés à compléter se fait au sein de la
règle CreateResourceInstanceProperty. Ce mécanisme est donc abordé plus en détail dans
la sous-section suivante.
179
Listing B.14: CreateResourceInstance : règle générique (gestion des propriétés, en ATL)
2 --
6 --
7 -- This rule is called by XConcept2XResourceInstance rule.
8 --
10 --
14 ) {
15 to
17 ...
19 properties <- Sequence{},
20 ...
21 ),
22 ...
23
24 do {
25 -- memorize correspondance between source element and
26 -- generated instance (useful to locate which instances
27 -- have been already generated, in order to reference them)
28 thisModule.addSequence(’InstancesMemory’, Sequence{source, t});
29
30 -- fill in properties
31 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 and
36 -- a property information exists in the source element
37
38 -- generate properties with value
39 for ( value in source.getPropertyValues(role) ) {
40 t.properties.append(
41 thisModule.CreateResourceInstanceProperty(
42 t.type.getProperty(role),
43 value,
44 OclUndefined
45 )
46 );
47 }
48 -- generate properties with reference
49 for ( reference in source.getPropertyReferences(role) ) {
50 t.properties.append(
51 thisModule.CreateResourceInstanceProperty(
52 t.type.getProperty(role),
53 OclUndefined,
54 reference
55 )
56 );
57 }
58
59 } else {
60 -- Trace the lack of property
61 thisModule.TraceLackOfProperty(source, resource, role);
62 }
63 }
64
65 -- fill in incomplete properties
66 thisModule.CompletePropertyReferences(source, t);
67 }
68 }
Règle CreateResourceInstanceProperty
Le listing B.15 illustre l’implantation d’une règle ATL dédiée à la création des propriétés
d’instances de ressources (ResourceInstanceProperty).
Cette règle, CreateResourceInstanceProperty, est mise à contribution pour renseigner
les propriétés, dans la règle CreateResourceInstance de la sous-section précédente.
Listing B.15: CreateResourceInstanceProperty : création d’une propriété (en ATL)
1 -- Rule CreateResourceInstanceProperty
2 --
3 -- Called rule that generate an application resource instance property
4 -- 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 : OclAny
14 ) {
15 to
16 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 }
30
31 -- Helper getInstance
32 --
33 -- Parameter : A source application element.
34 -- Return : A resource instance generated from the source application
35 -- element passed to the helper (if that instance has already
36 -- been generated).
37 -- Use : Locate target element into the InstancesMemory structure.
38 --
39 helper def : getInstance(reference : OclAny) : RTEPML!ResourceInstance =
40
41 let memory : Sequence(OclAny) =
42 thisModule.refGetValue(’InstancesMemory’)
43 ->select(e | e.first() = reference) in
44
45 if memory.oclIsUndefined()
46 then OclUndefined
47 else memory.last()
48 endif;
La règle CreateResourceInstanceProperty est une règle explicitement appelée (called

rule). 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 par une 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ègle CreateResourceInstanceProperty génère une propriété d’instance de ressource
(ResourceInstanceProperty) associée à la propriété passée en paramètre. La valeur (val) de
cette propriété d’instance est renseignée par le second paramètre. Sa référence vers une
instance de ressource (ref ) est déduite du troisième paramètre. Cette déduction repose sur
le helper getInstance défini dans le même listing (ligne 39).
Le helper getInstance s’appuie sur la structure InstancesMemory évoquée dans la sous-
section précédente. Cette structure mémorise les instances de ressources qui sont générées,
ainsi que les éléments source à l’origine de leur génération (cette mémorisation est effectuée
lors de la création des instances, au fur et à mesure de l’exécution de la transformation).
Le helper getInstance localise 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’a
pas encore été générée (i.e. si le couple formé de l’élément source et de l’instance générée
n’est pas présent dans la structure), le helper ne retourne pas d’instance (OclUndefined).
Au sein de la règle CreateResourceInstanceProperty l’absence d’instance retournée
par le helper getInstance, 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 dont l’instance cor-
respondante n’est pas encore disponible dans le modèle généré (lignes 22 à 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 structure SetOfInstances (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éments
sources à l’origine de la génération de ces instances sont transformés). Cette résolution est
assurée par la règle CompletePropertyReferences présentée dans la sous-section suivante.
Règle CompletePropertyReferences
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 les
propriétés, dans la règle CreateResourceInstance présentée dans cette annexe, page 178.
La règle CompletePropertyReferences est 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 dans
l’autre paramètre ;
– l’instance de ressource que nous venons de mentionner (susceptible de renseigner des
références dans des propriétés d’instances encore incomplètes).
La règle s’appuie sur la structure SetOfPropertyToComplete que nous avons introduit
dans 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 ressource
gé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éter
concernées par l’élément source passé en paramètre (ligne 18). Chacune de ces propriétés
est 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 des
proprié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 CompletePropertyReferences
2 --
3 -- Called rule that complete resource instance properties whose
4 -- 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 resource
9 -- instance that is perhaps referenced by incomplete properties.
10 --
11 rule CompletePropertyReferences (
12 source : OclAny,
13 instance : RTEPML!ResourceInstance
14 ) {
15 do {
16 -- for each property that must refer to the instance
17 -- generated from the source element
18 for (property in
19 thisModule.refGetValue(’SetOfPropertyToComplete’)
20 ->select(e | e.first() = source) ) {
21
22 -- resolve the reference with the correponding instance
23 property.last().ref <- instance;
24
25 -- delete the property from the set of property to complete
26 thisModule.delSequence(’SetOfPropertyToComplete’, property);
27 }
28 }
29 }
Remarque : Nous ne détaillerons pas, dans la suite de cette annexe, plus de règles pour
ce 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ération
d’instances de ressources sans mise à contribution de prototypes de conception. Il convient
donc de préciser que la prise en compte de prototypes de conception nécessite de modifier
d’une part les règles ClonePrototype (page 172) et CreateResourceInstanceFromPrototype
(page 174) dans le respect des algorithmes 4.17 et 4.18 présentés dans le chapitre 4. Mais
également de modifier les structures de mémorisation, leurs accès et les règles que nous
venons 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ègle CreateResourceInstance (génération d’appels de services)

Le listing B.17, page suivante, illustre l’implantation d’une gestion d’appels de services,
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ée
dans l’algorithme 4.21, du chapitre 4, page 107.
La règle CreateResourceInstance a é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 explicitement
appelée par la règle XConcept2XResourceInstance (listing B.8 et B.9).
La génération des appels de services se fait au sein de cette règle dans un contexte
impé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ée

par 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 (page 178). La structure
InstancesMemory est utilisée par le helper getInstance (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)
2 --
6 --
7 -- This rule is called by XConcept2XResourceInstance rule.
8 --
10 --
14 ) {
15 to
17 ...
19 call <- Sequence{},
20 ...
21 ),
22 ...
23
24 do {
25 -- memorize correspondance between source element and
26 -- generated instance (useful to locate which instances
27 -- have been already generated, in order to reference them)
28 thisModule.addSequence(’InstancesMemory’, Sequence{source, t});
29 ...
30
31 -- generate call services
32 for ( service in source.getCallServices() ) {
33 -- for each information provided by the source
34 -- element in order to call a service
35
36 if ( not service.get(’concept’)
37 .getService(service.get(’role’))
38 .oclIsUndefined()
39 ) {
40 -- the type of the element that is concerned
41 -- by the service provide it
42
43 t.call.append(
44 thisModule.CreateCallService(
45 service.get(’element’),
46 service.get(’concept’),
47 service.get(’role’)
48 )
49 );
50
51 } else {
52 -- Trace the lack of call service
53 thisModule.TraceLackOfService(source, resource, service);
54 }
55 }
56
57 -- fill in incomplete call service
58 thisModule.CompleteCallServiceReferences(source, t);
59 }
60 }
La seconde étape génère les appels de services. Elle parcourt pour cela une séquence
de tuples (élément, concept, rôle ) associés à l’élément source. Cette séquence est retournée
par le helper getCallServices (ligne 32).
Un tuple (élément, concept, rôle ) correspond à un appel au service identifié par un
rôle, adressé à une instance générée à partir d’un élément, conformément à un concept.
Remarque : Les accès aux champs du tuple se font avec l’opération O CL get sur une Map).
Le helper getCallServices ne sera pas détaillé dans cette annexe. Son implantation est
propre à la technologie de modélisation de l’application source. Un exemple d’algorithme
est donné page 109.
Les appels générés sont ceux dont le service appelé est fournit par la ressource qui type
l’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ègle CreateCallService (ligne 44).
Cette règle, explicitement appelée, prend comme paramètres les différentes informations
associées au service (élément, concept et rôle) que nous venons d’évoquer. Une implantation
de la règle CreateResourceInstanceCallService est présentée dans la sous-section suivante.
L’implantation proposée pour cette seconde phase génère finalement une trace lorsqu’un
service 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 services incomplets
dont 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ègle CompleteCallServiceReferences (ligne 58). Cette règle ne sera pas détaillée
dans cette annexe. Son implantation s’apparente à celle de la règle CompletePropertyRefe-
rence présentée précédemment (page 181).
Règle CreateCallService
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ègle CreateResourceInstance
de la sous-section précédente.
La règle CreateCallService est 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ègle CreateCallService génère un appel (CallService) associé à un service et adressé
à une instance de ressource (ref ). Le service est localisé par le helper getService. Nous ne
détaillerons pas ce helper dans la suite de ce rapport. Son implantation s’apparente à celle
du helper getProperty introduit précédemment dans cette annexe (page 165). L’instance de
ressource à laquelle s’adresse le service est déduite du premier paramètre. Cette déduc-
tion repose sur le helper getInstance que nous avons introduit précédemment (listing B.15,
page 180, ligne 39).
Le helper getInstance localise, au sein de la structure InstancesMemory évoquée dans
la sous-section précédente, l’instance qui a été générée à partir de l’élément source passé en
paramètre. Si cette instance n’a pas encore été générée (i.e. si le couple formé de l’élément
source et de l’instance générée n’est pas présent dans la structure), le helper ne retourne pas
d’instance (OclUndefined).
185
Au sein de la règle CreateCallService l’absence d’instance retournée par le helper ge-

tInstance conduit à mémoriser l’appel de service (alors incomplet) et l’élément source dont
l’instance correspondante n’est pas encore disponible (ligne 22). Cette mémorisation se fait
dans une structure (SetOfCallServiceToComplete) dont la manipulation s’apparente a ce qui
a été présenté pour la structure SetOfInstances (page 177).
Comme cela fut abordé dans la sous-section précédente, les références des appels de
services à 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ègle CompleteCallServiceReferences que nous avons évoquée
précédemment.
Listing B.18: CreateCallService : création d’un appel de service (en ATL)
1 -- Rule CreateCallService
2 --
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 : String
13 ) {
14 to
15 t : RTEPML!CallService (
16 ref <- thisModule.getInstance(element),
17 service <- concept.getService(role),
18 parameters <- Sequence{}
19 )
20 do {
21 -- detect service to complete
22 if ( t.ref.oclIsUndefined() ) {
23 thisModule.addSequence(
24 ’SetOfCallServiceToComplete’, Sequence{element, t} );
25 }
26
27 -- fill in parameters with value
28 for ( val in reference.getParameterValues(role) ) {
29 t.parameters.append(
30 thisModule.CreateCallServiceParameter(val, OclUndefined)
31 );
32 }
33
34 --fill in parameters with reference
35 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 service

s’effectue en deux phases successives. La première concerne les paramètres renseignés par
une 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). Les helpers getParameterValues et getPa-
rameterReferences se 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ègle
CreateCallServiceParameter. Cette règle, explicitement appelée, prend comme paramètre
soit une valeur littérale, soit une référence. Nous ne la détaillerons pas dans la suite de cette
annexe. Son implantation s’apparente à celle de la règle CreateResourceInstanceProperty
présentée précédemment (page 180).
Templates de génération de règles de transformations

Template Concept2ResourceInstance (simple)
Le listing B.19 illustre le principe d’un template de génération de règle du type XCon-
cept2XResourceInstance (présentée dans le listing B.9, page 172).
L’utilisation de templates pour 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: Template de génération d’une règle ATL de déploiement (version simple)
1 /-- Template Concept2ResourceInstance

2 --
3 -- Generate an ATL transformation rule that make a correspondance
4 -- 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 -- Generated
13 --
14 -- That rule translate an application <concept> with the <concept.criteria>
15 -- criteria into a platforme resource instance typed by a <resource> with
16 -- the <resource.criteria> criteria.
17 --
18 rule <concept><concept.criteria>2<resource>Instance<resource.criteria> {
19
20 from s : Application!<concept.name> (
21
22 /-- 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>,
34
35 /-- 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 de template
précis, mais reprend une syntaxe proche de langages existants (tel qu’Acceleo [79]).
Le principe d’un template est de fournir un code source dont une partie sera complétée
soit par un simple remplacement, soit par une construction plus complexe guidée par des
structures de contrôles. La génération d’un code source ainsi complété et construit émane
d’un moteur de template . Ce moteur prend en entrée le template et 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 template présenté dans le listing B.19 est censé prendre sa source d’information dans
un 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 type
de template est disponible dans le listing 4.2 de cette même section, page 115.
Le template proposé 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 à
ApplicationConcept et à RTEPMLConcept dans le métamodèle de déploiement).
Les parties du template à remplacer ou à construire se distinguent par des balises (en
gras 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éments du modèle de
déploiement. Remarque : La notion de paramètre associé à un critère est introduite dans le
mé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-
cept2XResourceInstance pré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 pas
retranscrit dans cette exemple qui se concentre sur les parties qu’influence le template .
L’utilisation de ce template dans un template de 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 un
template de génération de règle du type XConcept2XResourceInstance. Ce listing enrichit
le 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 template présenté dans le listing B.20 prend sa source d’information dans un modèle
de déploiement conforme au métamodèle que nous avons introduit dans la section 4.5 du
chapitre 4, page 121 (figure 4.17). Un exemple de modèle associé à ce type de template est
disponible dans le listing 4.4 de cette même section, page 122.
La règle générée par ce template considère successivement, dans ses pré-conditions
d’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 qui
type l’instance de ressource générée par la règle (lignes 45 et 53). On remarquera que pour
cela, le helper getResource a été modifiée pour prendre en compte un critère supplémentaire.
Les modifications apportées à ce helper (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: Template de génération d’une règle ATL de déploiement (décisions)
1 /-- Template Concept2ResourceInstance

2 --
3 -- Generate an ATL transformation rule that make a correspondance
4 -- 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 -- Generated
13 --
14 -- That rule translate an application <concept> with <concept.criteria> and
15 -- <concept.decisions> criteria into a platforme resource instance typed by
16 -- a <resource> with <resource.criteria> and <resource.decisions> criteria.
17 --
18 rule <concept><concept.criteria>2<resource>Instance<resource.criteria> {
19
20 from s : Application!<concept.name> (
21
22 /-- 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 /-- 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>,
43
44 /-- 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 },
51
52 /-- 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 ce template dans un template de 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. Le template de ce listing fait appel au template de génération de règles présenté dans
le listing B.20, de la sous-section précédente.
Listing B.21: Template de génération d’une transformation ATL de déploiement
1 /-- Template GenerateTransformation

2 --
3 -- Generate an ATL transformation using a template that
4 -- generate the deployment rules (Concet2ResourceInstance).
5 --
6 -- Parameter : the root of the deployment model.
7 --
8 --/
9 template GenerateTransformation(deployment) :
10
11 -- Transformation : Application to RTEPML
12 --
13 -- Generated
14 --
15 -- Allow to deploy an application on an execution platform.
16 --
17 module Application2RTEPML;
18 create OUT : RTEPML from IN1 : Application, IN2 : RTEPML;
19
20 /-- 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 ce template est de générer chaque règle de correspondance (ou règle de

déploiement) d’après ce que décrit le modèle de déploiement qui le renseigne. Le modèle
de déploiement et les templates sont transmis en entrée d’un moteur de template .
C
Technologies 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 à recenser
les potentielles de modélisation des plates-formes de notre domaine d’intérêt (les systèmes
embarqué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 dans
chacune des approches U ML et D SML.
C.0.1 Approche U ML
P ML (Platform Modeling Language) [107] est un métamodèle dédié à la description
de plate-forme au sens large (telles que des plates-formes d’exécution ou d’analyse). Ce
mé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’U ML (P ML-U ML, dans la version 1.4
d’U ML) 1 et intégré dans G ME. P ML-U ML permet, entre autre, de modéliser les ressources
et 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 implicite
ou explicite. Pour cela, des transformations de modèles, en G ReaT (Graph Rewriting and
Transformation) [54], sont disponibles pour passer d’un métamodèle à un modèle conforme
à P ML. L’outillage associé à P ML, et intégré dans G ME, 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 description
des règles de transformation se confond avec les descriptions des ressources et des services
des plates-formes d’exécution.
T UT-Profile (Tampere University of Technology - U ML Profile) [63] est un profil U ML

(dans la version 2.0 d’U ML) initialement prévu pour la modélisation d’applications temps
réel embarquées et de plates-formes d’exécution matérielles. Ce Profil a été étendu par
l’introduction de concepts liés aux plates-formes d’exécution logicielle [4]. Ces concepts
concernent les packages dédiés à la description de plates-formes logicielles (SwPlatformLi-
brary), les composants de plates-formes logicielles (SwPlatformComponent) et les éléments
typés par ces composants (SwPlatformProcess).
Cette approche permet, dans une modélisation U ML, 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 (U ML profile for Modeling and Analysis of Real Time and
Enbedded systems) [89], standardisé par l’O MG, est dédié à la modélisation et à l’ana-
lyse de systèmes embarqués temps réel. U ML-M ARTE 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 S RM (Software Resource Modeling) propose en particulier des artefacts
de modélisation des plates-formes d’exécution logicielles pour le domaine du temps réel
et de l’embarqué. Pour cela, S RM spécialise pour son domaine d’application les concepts
1
L’utilisation d’une extension lourde d’U ML pourrait s’apparenter à une approche D SML, en opposition à
l’approche par profil U ML.
194 Annexe C. Technologies de modélisation explicite des plates-formes d’exécution
généraux de ressources et de services du package G RM (Generic Resource Modeling) déjà

présents dans le profil S PT (Schedulability, Performance and Time) [85] que M ARTE se
destine à remplacer.
Les ressources identifiées par S RM concernent trois familles de concepts :
1. Les ressources concurrentes, qui offrent des contextes d’exécution concurrents (par
exemple les tâches et les interruptions) ;
2. Les ressources d’interaction, qui proposent des mécanismes de communication et
de synchronisation (par exemple les sémaphores, les évènements ou les boîtes aux
lettres) ;
3. Les ressources de gestion, qui fournissent des services pour la gestion d’autres res-
sources (par exemple les ordonnanceurs et les pilotes).
Le profil U ML-M ARTE permet, au travers du package S RM, d’identifier finement les
aspects 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 ressources
et des services mis à disposition par les exécutifs du domaine présents sur le marché (tels
que A RINC -653, O SEK /V DX -O S ou RT Linux) [114].
C.0.2 Approche D SML

A ADL (Architecture Analysis & Design Language) [103] est un langage de descrip-
tion d’architecture (ou A DL, Architecture Description Language) standardisé par la S AE
(Society of Automotive Engineer) pour le domaine des systèmes temps réel embarqués cri-
tiques. Le métamodèle d’A ADL définit l’ensemble des composants et des connecteurs de
son 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 A ADL, 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’instancier le modèle, puis
d’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 logicielle et du
support d’exécution matériel. Bien que le standard n’adresse pas la description d’un support
d’exécution logiciel, des composants logiciels spécifiques aux plates-formes pourraient être
décrits et mis en relation avec les composants de l’application, via les mécanismes d’héri-
tage ou d’implémentation que propose le langage. Cette façon de procéder est néanmoins
limitée, d’une part, par l’impossibilité de spécialiser les connecteurs pour des plates-formes
d’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 les threads). Le support d’exécution,
ainsi figé par ce que spécifie le standard, fait office de plate-forme d’exécution abstraite.
A ADL ne se prétend donc pas être un langage de description de plate-forme d’exécution
logicielle.
T HINK (THink Is Not a Kernel) [42] est une implantation d’un modèle de compo-
sants de type Fractal [39] pour le développement de systèmes d’exploitation embarqués.
T HINK 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 services
d’un système d’exploitation embarqué.
Au travers de KORTEX, T HINK permet de concevoir des plates-formes d’exécution em-
barquée par assemblage de composants. T HINK montre ainsi la capacité de Fractal à décrire
195
des plates-formes d’exécution. Néanmoins, le métamodèle de Fractal définit des concepts

de 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 T HINK
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. T HINK se
destine 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 (ou Platform Based Design [97]). Le métamodèle de Metropolis (Metropolis Meta
Model [75]) définit des concepts d’un haut niveau d’abstraction pour la modélisation de
systè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-formes
d’exécution (matérielles et logicielles) et les applications qui s’y destinent. Le déploiement
d’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, tels
que LTL (Linear Temporal Logic) ou L OC (Logic Of Constraints), pour la vérification de
proprié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’utilisation
conjointe de langages de modélisation et de langages de logique temporelle. Cette approche
offre, 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 cette ap-
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 aspect
mé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 temps
réel distribués. La modélisation des supports d’exécutions visés s’articule autour de com-
posants basés sur le standard C CM (C ORBA Component Model) [87] et spécialisés pour les
domaines 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 dans
le respect du standard C ORBA. Elle se prête ainsi à la modélisation explicite de certaines
plates-formes d’exécution, mais ne permet pas de modéliser les ressources et les services
de systèmes d’exploitation.
Le projet Ptolemy propose au travers de son atelier (Ptolemy II [69]) un ensemble

d’outils de modélisation et de simulation de systèmes embarqués temps réel, hétérogènes et
concurrents. Les métamodèles disponibles dans Ptolemy, en lien avec le support d’exécution
des systèmes, se focalisent sur la description de modèles d’exécution (les représentation
des lois qui gouvernent les interactions entre les composants d’un système). La plupart de
ces modèles supportent la conception orientée acteur (actor-oriented design) axée sur la
concurrence 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 chacune
des 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 la précision
des 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 et
matérielles. L’utilisation envisagée de chacune des technologies est finalement abordée.
Approches D SML Approches U ML

A ADL T HINK Metropolis CoSMIC Ptolemy P ML T UT M ARTE
Domaine
Emb.T.R ++ ++ + ++ ++ − + ++
Concepts ++ + − +(1) + − − +++
Modélisation
P.mat. ✓ ✓ ✓ ✓ ✓
P.log. ✓ ✓ ✓(1) ✓(2) ✓ ✓ ✓
Appl. ✓ ✓ ✓ ✓ ✓ ✓ ✓
Utilisation (prévue)
Conçoit ✓(3) ✓(4) ✓(3) ✓(3) ✓(3) ✓ ✓ ✓

Analyse ✓ ✓ ✓ ✓ ✓ ✓ ✓
Simule ✓ ✓ ✓ ✓
Déploie ✓(5) ✓ ✓(6) ✓(7) ✓ ✓ ✓
(1)
Ne concerne que les intergiciels conformes à C ORBA.
(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 D SML, le langage A ADL offre un ensemble assez complet de concepts du
domaine. Ce langage se focalise toutefois sur la description des supports matérielles et des
applications. Bien que les concepts relatifs aux applications soient étroitement liés avec ceux
des plates-formes logicielles, les artefacts de modélisation proposés par A ADL limitent la
description de ces plates-formes.
Parmi les technologies évaluées, D SML et U ML confondus, le profil U ML-M ARTE offre
actuellement 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 a de plus été conduite
sur la base d’un modèle de domaine qui spécifie ces concepts. Le profil U ML-M ARTE est
197
une implantation de ce modèle de domaine. Une implantation alternative dans un D SML est
également envisageable. Le langage RTEPML présenté dans ce rapport est par exemple une
implantation, dans un D SML, du package S RM d’U ML-M ARTE.
Abréviations
A ADL Architecture Analysis & Design Language

A DL Architecture Description Language
A MMA ATLAS Model Management Architecture
A PI Application Programming Interface
A RINC Aeronautical Radio Incorporated
A SIC Application Specific Integrated Circuit
ATL ATLAS Transformation Language
ATLAS Atlantic Data Systems
AUTOSAR AUTomotive Open System ARchitecture
AWK Aho, Kernighan et Weinberger
C AD Computer Aided Design
C ASE Computer Aided Software Engineering
C CM C ORBA Component Model
C ORBA Common Object Request Broker Architecture
CoSMIC Component Synthesis using Model Integrated Computing
D SML Domain Specific Modeling Language
D TD Document Type Definition
E MF Eclipse Modeling Framework
E MP Eclipse Modeling Project
F PGA Field Programmable Gate Array
G EF Graphical Editing Framework
G ME Generic Modeling Environment
G MF Graphical Modeling. Framework
G PML Generic Purpose Modeling Language
G ReaT Graph Rewriting and Transformation
G RM Generic Resource Modeling
H RM Hardware Resource Modeling
200 Abréviations
I DM Ingénierie Dirigée par les Modèles

KM3 Kernel Meta Meta Model
L INA Laboratoire d’Informatique de Nantes Atlantique
L OC Logic Of Constraints
LTL Linear Temporal Logic
M ARS Maintainable Real-Time System
M ARTE U ML profile for Modeling and Analysis of Real Time and Embedded systems
M DA Model Driven Architecture
M DE Model Driven Engineering
M IC Model-Integrated Computing
M OF Meta Object Facility
N FP Non Functional Property
OASIS Objects Actifs Synchrones Isochrones pour la Sûreté
O CL Object Contraint Language
O IL O SEK /V DX Implementation Language
O MG Object Management Group
O SATE Open Source A ADL Tool Environment
O SEK Offene Systeme und deren schnittstellen für die Elektronik im Kraftfahrzeug
P CP Priority Ceiling Protocol
P DM Platform Description Model
P IM Platform Independant Model
P IP Priority Inheritance Protocol
P ML Platform Modeling Language
P OSIX Portable Operating System Interface
P SM Platform Specific Model
QoS Quality of Service
Q VT Query View Transformation
RTES Real-time Embedded System
RT Linux Real-Time Linux
RTW Real-Time Workshop
S AE Society of Automotive Engineer
S PT Schedulability, Performance and Time
S QL Structured Query Language
Abréviations 201
S RM Software Resource Modeling

T CS Textual Concrete Syntax
T HINK THink Is Not a Kernel
T OPCASED The Open-Source Toolkit for Critical Systems
T UT-Profile Tampere University of Technology - U ML Profile
U ML Unified Modeling Language
V DX Vehicle Distributed eXecutive
X MI X ML Metadata Interchange
X ML eXtensible Markup Language
X SLT eXtensible Stylesheet Language Transformations
Table des figures
1.1 Principe de mise en œuvre d’une transformation de modèle dans l’I DM. . . . . . . . . . 10
1.2 Considération progressive des plates-formes dans le M DA. . . . . . . . . . . . . . . . 12
2.1 Un profil U ML d’applications spécifiques à la plate-forme O SEK /V DX. . . . . . . . . . 19

2.2 Description U ML d’une application spécifique à la plate-forme O SEK /V DX. . . . . . . . 20
2.3 Un métamodèle d’applications spécifiques à la plate-forme O SEK /V DX. . . . . . . . . . 20
2.4 Description avec un D SML d’une application spécifique à la plate-forme O SEK /V DX. . . . 21
2.5 Un profil U ML de description de plates-formes d’exécution. . . . . . . . . . . . . . . 21
2.6 Description explicite d’une plate-forme O SEK /V DX avec un profil U ML. . . . . . . . . . 22
2.7 Un D SML de description de plates-formes d’exécution. . . . . . . . . . . . . . . . . 23
2.8 Description explicite d’une plate-forme O SEK /V DX avec un D SML. . . . . . . . . . . . 23
2.9 Trois approches de déploiement d’une application sur une plate-forme. . . . . . . . . . 24
2.10 Plate-forme enfouie dans une transformation. . . . . . . . . . . . . . . . . . . . . . 25
2.11 Déploiement d’une application sur une plate-forme O SEK /V DX (U ML). . . . . . . . . . 26
2.12 Plate-forme implicitement décrite dans un métamodèle de langage de programmation. . . . 27
2.13 Déploiement d’une application sur une plate-forme O SEK /V DX implicitement décrite. . . . 27
2.14 Introduction d’un métamodèle pivot de plate-forme d’exécution. . . . . . . . . . . . . 29
2.15 Extrait d’un métamodèle pivot. . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.16 Déploiement d’une application sur une plate-forme O SEK /V DX via un pivot. . . . . . . . 30
2.17 Quatre approches de déploiement d’une application sur une plate-forme explicitement décrite. 31
2.18 Déploiement d’une application sur une plate-forme O SEK /V DX décrite avec un profil U ML. 32
2.19 Principe d’une transformation de déploiement sur une plate-forme décrite avec un profil U ML. 33
2.20 Un D SML de description de système (application + plates-formes d’exécution). . . . . . . 35
2.21 Promotion d’un modèle de la plate-forme O SEK /V DX en un métamodèle d’application. . . 36
2.22 Principe d’une génération de transformation de portage. . . . . . . . . . . . . . . . . 37
2.23 Génération d’un modèle de code spécifique à une plate-forme O SEK /V DX décrite avec un D SML. 39
2.24 Un D SML de description de plate-forme pouvant intégrer des applications. . . . . . . . . 40
2.25 Déploiement d’une application sur une plate-forme O SEK /V DX décrite avec un D SML. . . 41
3.1 Extrait du motif ressource/service du profil U ML-M ARTE [89]. . . . . . . . . . . . . . 59

3.2 Extrait du modèle de domaine de S RM : les ressources logicielles [89]. . . . . . . . . . 59
3.3 Extrait du modèle de domaine de S RM : les ressources d’exécution concurrentes [89]. . . . 60
3.4 Extrait du modèle de domaine de S RM : les partitions mémoires [89]. . . . . . . . . . . 61
3.5 Extrait du modèle de domaine de S RM : les ressources d’interaction [89]. . . . . . . . . 61
3.6 Extrait du modèle de domaine de S RM : les ressources de synchronisation [89]. . . . . . . 62
3.7 Extrait du modèle de domaine de S RM : les ressources de communication [89]. . . . . . . 62
3.8 Extrait du modèle de domaine de S RM : les interactions des ressources concurrentes [89]. . 62
3.9 Extrait du D SML RTEPML : fondation de la modélisation des ressources et des services. . . 63
3.10 Extrait du D SML RTEPML : les éléments nommés. . . . . . . . . . . . . . . . . . . 63
3.11 Extrait du D SML RTEPML : hiérarchie des ressources. . . . . . . . . . . . . . . . . . 64
3.12 Extrait du D SML RTEPML : affectation des rôles. . . . . . . . . . . . . . . . . . . . 64
3.13 Extrait du D SML RTEPML : les éléments typés. . . . . . . . . . . . . . . . . . . . . 64
204 Table des figures
3.14 Extrait du D SML RTEPML : les types de données. . . . . . . . . . . . . . . . . . . . 65

3.15 Extrait du D SML RTEPML : les instances de ressources prédéfinies dans une plate-forme. . 65
3.16 Extrait du D SML RTEPML : les instances de ressources et leurs propriétés. . . . . . . . . 66
3.17 Extrait du D SML RTEPML : les instances de ressources et les appels de services. . . . . . 66
3.18 Extrait du D SML RTEPML : les routines et les points d’entrée. . . . . . . . . . . . . . 67
3.19 Extrait du D SML RTEPML : l’héritage de ressource. . . . . . . . . . . . . . . . . . . 68
3.20 Extrait du D SML RTEPML : la composition de services. . . . . . . . . . . . . . . . . 69
3.21 Extrait du D SML RTEPML : les prototypes de conception. . . . . . . . . . . . . . . . 70
3.22 Extrait du D SML 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. 79
4.2 Extrait du D SML RTEPML : intégration d’une application sur la plate-forme. . . . . . . . 79
4.3 Déploiement d’une application de robotique sur une plate-forme O SEK /V DX. . . . . . . 80
4.4 Principe de déploiement d’une application via RTEPML. . . . . . . . . . . . . . . . . 84
4.5 Relations identifiées entre les concepts applicatif et exécutif. . . . . . . . . . . . . . . 87
4.6 Mise à disposition, par une plate-forme, de ressources conformes à des concepts de RTEPML. 90
4.7 Mise à disposition, par une plate-forme, de ressources avec ou sans prototype de conception. 93
4.8 Déploiement d’une application de robotique sur une plate-forme O SEK /V DX (prototype). . 97
4.9 Déploiement d’une application de robotique sur une plate-forme O SEK /V DX (propriétés). . 105
4.10 Déploiement d’une application de robotique sur une plate-forme O SEK /V DX (avec services). 109
4.11 Composition d’une transformation de déploiement basée sur RTEPML. . . . . . . . . . . 110
4.12 Organisation d’une transformation de déploiement basée sur RTEPML. . . . . . . . . . . 112
4.13 Exemple de métamodèle de déploiement (simple) . . . . . . . . . . . . . . . . . . . 114
4.14 Exemple de métamodèle de déploiement (simple, avec trace) . . . . . . . . . . . . . . 116
4.15 Organisation d’une transformation de déploiement basée sur RTEPML (génération de règles). 116
4.16 Choix de déploiement conceptuels et pratiques. . . . . . . . . . . . . . . . . . . . . 118
4.17 Exemple de métamodèle de déploiement (simple, avec décisions) . . . . . . . . . . . . 121
4.18 Organisation d’une transformation de déploiement basée sur RTEPML (choix de déploiement). 123
4.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. . . . . . . 131

5.2 Éditeurs développés et intégrés à l’atelier T OPCASED pour mener les expérimentations. . . 132
5.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). . . 43

2.2 Approches de déploiement sur des plates-formes implicitement décrites. . . . . . . . . . 46
2.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. . . . . . . . . 111

4.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. . . . . . . . . . . . . . . . . . . . 136

5.2 . . . . . . . . . . 137
Développement des fonctions d’accès aux informations des modèles.
5.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 U ML) [115] . . . . . . 34
2.2 Principe d’une génération de transformation de portage . . . . . . . . . . . . 37
4.1 Principe d’une transformation de déploiement . . . . . . . . . . . . . . . . . 81
4.2 Règle de correspondance (ruleConcept2ResourceInstance ) . . . . . . . . . . 82
4.3 Localisation d’une ressource (getResource ) . . . . . . . . . . . . . . . . . . 83
4.4 Localisation d’une propriété dans la plate-forme (getProperty ) . . . . . . . . 83
4.5 Principe d’une transformation de déploiement (➤concept/critère) . . . . . . . . 86
4.6 Règle de correspondance (ruleConcept2ResourceInstance ) (➤concept/critère) . 86
4.7 Localisation d’une ressource (getResource ) (➤concept/critère) . . . . . . . . . 86
4.8 Principe d’une transformation de déploiement (➤relations 1-0) . . . . . . . . . 88
4.9 Règle de correspondance (ruleConcept2MultiResourceInstances ) . . . . . . 89
4.10 Principe d’une transformation de déploiement (➤disponibilité) . . . . . . . . . 92
4.11 Règle de correspondance (ruleConcept2MultiResourceInstances ) (➤disponibilité) 92
4.12 Règle de correspondance (ruleConcept2MultiResourceInstances ) (➤prototypes) 94
4.13 Règle d’application d’un prototype (ruleClonePrototype ) . . . . . . . . . . . 94
4.14 Génération d’une instance (ruleCreateResourceInstanceFromPrototype ) . . . 95
4.15 Génération des associations (ruleCreateAssociationFromPrototype ) . . . . . 96
4.16 Sans prototype (ruleConcept2ResourceInstance ) (➤propriétés) . . . . . . . . . 99
4.17 Avec prototype (ruleCreateResourceInstanceFromPrototype ) (➤propriétés) . . 100
4.18 Règle d’application d’un prototype (ruleClonePrototype ) (➤propriétés) . . . . 101
4.19 Génération des propriétés (ruleCreatePropertiesFromPrototype ) . . . . . . . 102
4.20 Renseignement des propriétés (avec ou sans prototype) (➤référence) . . . . . . 104
4.21 Sans prototype (ruleConcept2ResourceInstance ) (➤services) . . . . . . . . . . 107
4.22 Exemple d’une déclaration d’appels de services (getCallServices ) . . . . . . 109
Listings
2.1 Extrait de la transformation ROBOT 2O SEK /V DX (en ATL) . . . . . . . .. ..

. . .28 .
2.2 Extrait de la transformation de promotion Platform2Meta (en ATL) . . . .. ..
. . .36 .
2.3 Extrait de la transformation Robot & PDM to C (en ATL) . . . . . . . .. ..
. . .39 .
2.4 Extrait de la transformation ROBOT 2P LATFORM (en ATL) . . . . . . . .. ..
. . .41 .
3.1 Description de la plate-forme NXT O SEK avec RTEPML (extrait) . . . . . .. ..
. . .73 .
4.1 Transformation de déploiement Robot2RTEPML (cas simple, en ATL) . . .. ..
. . .80 .
4.2 Exemple de modèle de déploiement . . . . . . . . . . . . . . . . . .. ..
. . .
115 .
4.3 Exemple de modèle de déploiement (Robot vers RTEPML) . . . . . . . .. ..
. . .
122 .
4.4 Exemple de modèle de décision (Robot vers O SEK /V DX) . . . . . . . .. ..
. . .
122 .
A.1 Métamodèle du langage RTEPML (en K M 3 [56]) . . . . . . . . . . . .. ..
. . .
153 .
B.1 Extrait de la transformation Platform2Meta (en ATL) . . . . . . . . . .. ..
. . .
163 .
B.2 getResource : localisation d’une ressource (version simple, en ATL) . . . .. ..
. . .
164 .
B.3 getResource : localisation d’une ressource (avec critères, en ATL) . . . . .. ..
. . .
165 .
B.4 getProperty : localisation d’une propriété (version simple, multi-helpers , en ATL) .
. . .
166 .
B.5 getProperty : localisation d’une propriété (version simple, générique, en ATL) . .
. . .
167 .
B.6 XConcept2XResourceInstance : exemple générique (avec critères, en ATL) . . . . . .
168 .
B.7 XConcept2XResourceInstance : exemple générique (disponibilité 0/1 (a), en ATL) . . .
169 .
B.8 XConcept2XResourceInstance : exemple générique (disponibilité 0/1 (b), en ATL) . . .
170 .
B.9 XConcept2XResourceInstance : exemple générique (prototypes de conception, en ATL) . 172 .
B.10 ClonePrototype : appliquer un prototype de conception (en ATL) . . . . . . . . . . . 173 .
B.11 CreateResourceInstanceFromPrototype : générer une instance à partir d’un prototype (en ATL) 174
B.12 CreateAssociationFromPrototype : générer les associations (en ATL) . . . . . . . . . . 176
B.13 SetOfInstances : une structure de mémorisation d’instances de ressources (en ATL) . . . . 177
B.14 CreateResourceInstance : règle générique (gestion des propriétés, en ATL) . . . . . . . . 179
B.15 CreateResourceInstanceProperty : création d’une propriété (en ATL) . . . . . . . . . . 180
B.16 CompletePropertyReferences : résolution des références pour les propriétés (en ATL) . . . 182
B.17 CreateResourceInstance : règle générique (génération d’appels de service, en ATL) . . . . 183
B.18 CreateCallService : création d’un appel de service (en ATL) . . . . . . . . . . . . . . 185
B.19 Template de génération d’une règle ATL de déploiement (version simple) . . . . . . . . 186
B.20 Template de génération d’une règle ATL de déploiement (décisions) . . . . . . . . . . . 188
B.21 Template de génération d’une transformation ATL de déploiement . . . . . . . . . . . 189
Bibliographie
[1] Alfred V. Aho, Brian W. Kernighan, and Peter Weinberger. The AWK programming
language. Addison-Wesley, 1988.
[2] Airlines Electronic Engineering Committee. Avionics Application Software Standard
Interface, 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, The
Netherlands„ 2006.
[4] Tero Arpinen, Mikko Setälä, Erno Salminen, Marko Hännikäinen, and Timo D.
Hämäläinen. Modeling embedded software platform with a U ML profile. In Fo-
rum on specification and Design Languages, FDL’07, Barcelona, Spain, September
2007.
[5] Colin Atkinson and Thomas Kühne. A generalized notion of platforms for model-
driven development. pages 119–136. 2005.
[6] ATLAS group. ATL : ATLAS Transformation Language, ATL User Manual, version
0.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 les
Recherches, Institut National des Sciences Appliquées de Lyon, université Claude
Bernard 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 M DA approach. In Actes des 1ère Journées sur
l’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 CEA
EDF INRIA cours numéro 6, Juin 2003.
[12] Jean Bézivin, Mireille Blay, Mokrane Bouzhegoub, Jacky Estublier, Jean-Marie
Favre, Sébastien Gérard, and Jean-Marc Jézéquel. Rapport de Synthèse de l’A S
C NRS sur le M DA. Novembre 2004.
[13] Jean Bézivin, Sébastion Gérard, Pierre-Alain Muller, and Laurent Rioux. M DA Com-
ponents : Challenges and Opportunities. In Metamodelling 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. In In Proceedings of the Metainformatics Symposium. Springer-
Verlag, 2005.
212 Bibliographie
[15] Mireille Blay-Fornarino and Paul Franchi. Espace technologique langages et I DM.
Technical report, Novembre 2004.
[16] A. W. Brown, D. J. Carney, E. J. Morris, D. B. Smith, and P. F. Zarrella. Principles of
CASE tool integration. Oxford University Press, Inc., New York, NY, USA, 1994.
[17] James Bruck and Kenn Hussey. Customizing U ML : 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énierie
dirigée par les modèles pour la réalisation d’un outil de génération de code conforme
O SEK/V DX á partir d’une description A ADL, Septembre 2006. Rapport de Master.
[19] Matthias Brun, Jérôme Delatour, Yvon Trinquet, Frédérique Thomas, and Sébastien
Gé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 Yanxin
Wang. Usage scenarios for an automated model compiler. In EMSOFT ’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 : Techniques
de 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. U ML and Platform-Based Design, volume U ML for
Real : 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. In
POPL ’90 : Proceedings of the 17th ACM SIGPLAN-SIGACT symposium on Prin-
ciples of programming languages, pages 125–135, New York, NY, USA, 1990. ACM
Press.
[24] Francis Cottet and Anne-Marie Déplanche. Encylcopédie de l’informatique et des
systè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, and
applications. ACM Press/Addison-Wesley Publishing Co. New York, NY, USA,
2000.
[26] Abhijit Davare, Douglas Densmore, Trevor Meyerowitz, Alessandro Pinto, Alberto
Sangiovanni-Vincentelli, Guang Yang, Haibo Zeng, and Qi Zhu. A next-generation
design framework for platform-based design. In Conference on Using Hardware
Design 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 Topical
Meeting on Nuclear Plant Instrumentation, Controls and Human-Machine Interface
Technologies (NPIC&HMIT 2004), Columbus, Ohio. September, 2004., September
2004.
[28] James Davis. GME : the Generic Modeling Environment. In OOPSLA ’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, Institut
National des Sciences Appliquées de Lyon, France, Octobre 2007.
[30] Julien DeAntoni and Jean-Philippe Babau. A mda-based approach for real time em-
bedded systems simulation. In DS-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’approche
U ML/ P NO. PhD thesis, Université Paul Sabatier, Toulouse, France, Septembre 2003.
[32] Jérôme Delatour, Raphaël Marvie, and Guillaume Savaton. Workshop on Metamodel
Pattern, MP2006. In 2è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ébastien Faucou. Mo-
dèle de plate-forme pour l’embarqué : première expérimentation sur les noyaux
temps réel. In Actes 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. A MW : a
generic model weaver. In In proceedings of 1ères Journées sur l’Ingénierie Dirigée
par les Modèles, pages 105–114, Paris, France, 2005.
[35] Eclipse. Eclipse Modeling Project. http ://www.eclipse.org/modeling/.
[36] Eclispe Modeling Framework. E MF 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, version
4.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 and
Analyzing Non-Functional Properties of Real-Time Systems. PhD thesis, Université
d’Evry, Sarclay, France, Septembre 2007.
[41] Pierre Farail and Patrick Gaufillet. T OPCASED : un environnement de développement
open source pour les systèmes embarqués. In Journée de travail N EPTUNE, numéro
2, Paris , France, pages 16–20. Génie logiciel, GL & IS, Meudon, France, Mai 2005.
[42] Jean-Philippe Fassino. T HINK : vers une architecture de systèmes flexibles. PhD
thesis, Ecole Nationale Supérieure des télécommunications, Paris, France, Décembre
2001.
[43] Jean-Marie Favre. Towards a basic theory to model model driven engineering. In In
Workshop 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énierie
dirigé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. PhD
thesis, Université de Rennes 1, octobre 2006.
[47] L. Fuentes-Fernández and A. Vallecillo-Moreno. An introduction to uml profiles.
U PGRADE, European Journal for the Informatics Professional, 5(2) :5–13, April
2004.
[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. CoS MIC : An M DA generative tool for distributed
real-time and embdedded component middleware and applications. In In Proceedings
of the OOPSLA 2002 Workshop on Generative Techniques in the Context of Model
Driven 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-paradigme
du 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
(G ReaT). 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 D SL for Metamodel Specification. In Pro-
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. T CS : a D SL for the specification
of textual concrete sysntaxes in model engineering. In In GPCE’06 : Proceedings of
the 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 Driven
Architecture–Practice and Promise. Addison-Wesley Professional, April 2003.
[59] Herman Kopetz. Real-Time Systems, Design Principles for Distributed Embedded
Applications. Kluwer Academic Publishers, 1997.
[60] Hermann Kopetz. The complexity challenge in embedded system design. In 11th
IEEE International Symposium on Object-Oriented Real-Time Distributed Compu-
ting (ISORC 2008), pages 3–12, Orlando, Florida, USA, May 2008. IEEE Computer
Society.
[61] Hermann Kopetz, Andreas Damm, Christian Koza, Marco Mulazzani, Wolfgang
Schwabl, Christoph Senft, and Ralph Zainlinger. Distributed fault-tolerant real-time
systems : The M ARS 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 W LAN terminal using U ML 2.0 based design flow. In SAMOS, pages
404–413, 2005.
Bibliographie 215
[63] Petri Kukkala, Jouni Riihimâki, Marko Hännikäinen, Timo D.Hämäläinen, and Klaus
Kronlöf. U ML 2.0 profile for embedded system design. In Design, Automation and
Test in Europe (DATE’05), Vol.2, pages 710–715., Los Alamitos, CA, USA, March
2005. IEEE Computer Society.
[64] I. Kurtev, J. Bézivin, and M. Akşit. Technological spaces : An initial appraisal. In
International Conference on Cooperative Information Systems (CoopIS), DOA’2002
Federated Conferences, Industrial Track, Irvine, USA, pages 1–6, October 2002.
[65] Laboratoire d’Informatique de Nantes Atlantique (L INA). The A MMA Home Page.
http ://atlanmod.emn.fr/.
[66] François Laburthe. C HOCO : implementing a cp kernel. In In : Proceedings of TRICS
2000, 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, and
P. 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. In In Workshop on
Intelligent Signal Processing, Budapest, Hungary, May 2001.
[69] Edward A. Lee. Overview of the Ptolemy project. Technical Report UCB/ERL
M03/25, EECS Department, University of California, Berkeley, July 2003.
[70] Edward A. Lee and Alberto Sangiovanni-Vincentelli. A framework for comparing
models of computation. IEEE Transactions on Computer-Aided Design of Integrated
Circuits and Systems, 17 :1217–1229, 1998.
[71] C.-L. Liu and James W. Layland. Scheduling algorithms for multiprogramming in a
hard-real-time environment. J. ACM, 20(1) :46–61, 1973.
[72] Frédérique Loiret. Tinap : Modèle et infrastructure d’exécution orienté composant
pour applications multi-tâches á contraintes temps réel souples et embarquées. PhD
thesis, Université des Sciences et Technologies de Lille, Lille, France, Mai 2008.
[73] Raphaël Marvie, Laurence Duchien, and Mireille Blay-Fornarino. Les plates-formes
d’exécution et l’I DM, 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 and
Models, pages 227–270. MIT Press, 1968.
[77] S. L. Montgomery. AD/Cycle : I BM’s Framework for Application Development and
Case. Van Nostrand Reinhold, 1991.
[78] Pierre-Alain Muller, Frédéric Fondement, Franck Fleurey, Michel Hassenforder,
Rémi Schnekenburger, Sébastien Gérard, and Jean-Marc Jézéquel. Model-driven
analysis 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 for model-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. In
In : Proc. of 13th International Conference on Principles and Practice of Constraint
Programming, pages 529–543. Springer, 2007.
[82] nxtO SEK. NXT O SEK 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 (O MG). Model Driven Architecture (M DA) Guide, ver-
sion 1.0.1, March 2001. http ://www.omg.org/mda/.
[85] Object Management Group (O MG). Response to the O MG R FP for Schedulability,
Performance and Time, June 2001. O MG Document ad/2001-06-14.
[86] Object Management Group (O MG). Meta Object Facility (M OF) Core Specification,
version 2.0, January 2006. http ://www.omg.org/mof/.
[87] Object Management Group (O MG). C ORBA Component Model, version 4.0,
April 2006. http ://www.omg.org/technology/documents/formal/components.htm,
formal/2006-04-01.
[88] Object Management Group (O MG). M OF 2.0 X MI Mapping Specification, version
2.1.1, December 2007. http ://www.omg.org/technology/documents/formal/xmi.htm.
[89] Object Management Group (O MG). U ML Profile for Modeling and Analysis of
Real Time and Embbeded systems (M ARTE), second revision submission, June 2007.
http ://www.omg.org/marte/.
[90] Object Management Group (O MG). Unified Modeling Language (U ML) : Super-
structure, version 2.1.2, November 2007. http ://www.omg.org/mda/.
[91] Object Management Group (O MG). Meta Object Facility (M OF)
Query/View/Transformation Specification, version 1.0, April 2008.
http ://www.omg.org/spec/QVT/1.0/.
[92] OSEK/VDX Group. O SEK /V DX System Generation O IL : O SEK Implementation
Language, version 2.5, July 2004. http ://www.osek-vdx.org/.
[93] OSEK/VDX Group. O SEK /V DX 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 en
oeuvre de systèmes répartis interopérables. PhD thesis, Ecole Nationale Supérieure
des télécommunications, Paris, France, Mars 2003.
[96] Alberto Sangiovanni-Vincentelli, Luca Carloni, Fernando De Bernardinis, and Marco
Sgroi. Benefits and challenges for platform-based design. In DAC ’04 : Proceedings
of 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 U ML. Computer,
33(6) :64–69, 2000.
Bibliographie 217
[99] Bran Selic. On software platforms, their modeling with U ML 2, and platform-
independent design. In ISORC ’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 des
systè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 the
usability of real-time scheduling theory with the cheddar project. Real-Time Syst.,
43(3) :259–295, 2009.
[102] Smart-(Q VT). Smart-(Q VT) manual, 2007. http ://smartqvt.elibel.tm.fr.
[103] Society of Automotive Engineer (S AE). Architecture Analysis & Design Language
(A ADL) AS5506, version 1.0, 2004.
[104] Software Engineering Institute (S EI). O SATE Open-Source A ADL 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. In CP, pages 13–16,
2005.
[106] Syntec Informatique, RNT Logiciel. Livre Blanc des premières Assises Françaises
du 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 for
hardware detailed modeling. In IEEE 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 logicielles
d’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ébastien
Gérard. Contribution á la modélisation explicite des plates-formes d’exécution pour
l’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 temps réel. Techniques
de l’ingénieur, Traité Contrôle et Mesures, Mars 1999.
[119] T. Vergnaud and B. Zalila. Ocarina, a compiler for the A ADL. Technical report, Paris,
France, 2006. http ://ocarina.enst.fr.
[120] Thomas Vergnaud. Modélisation des systèmes temps-réel répartis embarqués pour
la génération automatique d’applications formellement vérifiées. PhD thesis, Ecole
Nationale 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. X SL Transformations (X SLT) 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, November
1999.
[124] WindRiver. VxW ORKS Programmer’s Guide, 5.4. Edition 1, Mars 1999.
[125] Wayne Wolf and Jorgen Staunstrup. Hardware/Software CO-Design : Principles and
Practice. Kluwer Academic Publishers, Norwell, MA, USA, 1997.
Contribution à la considération explicite des plates-formes d’exécution logicielles
lors 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, telle

que la maîtrise du temps et des ressources impliquées, dépendent étroitement du support
d’exécution. En outre, les besoins de réutilisation des applications sur différents supports
d’exécution orientent le développement logiciel vers des conceptions indépendantes de tout
support d’exécution. Pour faciliter l’adaptation des applications à ces supports, l’ingénierie
dirigée par les modèles (I DM) propose alors une approche qui vise à spécialiser successive-
ment le modèle d’une application pour des technologies précises (identifiées sous le terme
de plate-forme), via des processus de transformations de modèles. Toutefois, peu de travaux
ont é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 de
transformation 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 implicite
ou 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 dans
laquelle la plate-forme d’exécution est explicitement modélisée. Pour cela, un langage dédié
à la modélisation des systèmes d’exploitation temps réel embarqués est proposé. Puis, un
processus 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 transformations
gé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
(I DM), Transformation de modèles, Métamodèle de plate-forme, Modèle de plate-forme,
U ML-M ARTE, Langage de modélisation dédié.
Contribution to the software execution platform integration during an application

deployment 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 to design platform-
independent software. In order to ease platform integration of the application software,
model-driven engeneering (M DE) aims at specializing application model using model trans-
formations. But few works specify how to consider a platform within a transformation. On
the one hand, this study compares several processes that transform a platform-independent
model of an application into a platform-dependent model. This comparative work focuses
on implicit or explicit consideration of real-time and embedded operating systems. On the
other hand, this study explores a modeling method where platforms are explicitly described.
A domain-specific modeling language (D SML) dedicated to the description of execution
platforms is proposed. Then an application deployment process based on this language is
introduced and evaluated. The process uses generic or generated transformation rules and a
D SML dedicated to the description of application deployment.
Keywords Execution platform, Real-Time, Model-Driven Engineering (M DE), Model

transformation, Platform metamodel, Platform model, U ML-M ARTE, Domain-specific mo-
deling language (D SML).

2010NANT2077 Brun Matthias These

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

2010NANT2077 Brun Matthias These

Transféré par

Droits d'auteur :

Formats disponibles

U NIVERSITÉ DE N ANTES

É COLE D OCTORALE STIM

T HÈSE DE D OCTORAT DE L’U NIVERSITÉ DE N ANTES

Spécialité : AUTOMATIQUE ET I NFORMATIQUE A PPLIQUÉE

Présentée et soutenue publiquement par :

Contribution à la considération explicite

Rapporteurs : Laurence D UCHIEN Professeur, Université Lille 1 - LIFL

Examinateurs : Joël C HAMPEAU Enseignant Chercheur, ENSIETA - LISyC

Directeur de thèse : Yvon T RINQUET

I Contexte et état de l’art 1

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

3 Un langage de description de plate-forme d’exécution 57

4 Un processus de déploiement sur une plate-forme explicitement décrite 77

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

Listes des figures, tableaux, algorithmes et listings 204

Contexte et état de l’art

e chapitre présente le contexte et la portée de cette étude. Il introduit en particulier le

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

1.1.2 Mise en œuvre

1.1.2.1 Architecture matérielle

1.1.2.2 Support d’exécution logiciel

La réalisation d’un logiciel embarqué se concrétise par un programme dont l’exécution

Positionnement Nous nous intéressons à mettre en œuvre des applications logicielles

1.1.2.3 Synchrone ou asynchrone

L’approche asynchrone consiste à observer en permanence les occurrences d’évène-

1.1.2.4 Systèmes d’exploitation multitâches

1.1.2.5 Sûreté de fonctionnement

1.1.3 Portée de l’étude

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

Espace technique La particularité de l’I DM réside dans l’utilisation systématique

1.2.1.2 Transformation de modèles

Modèle de transformation Une transformation de modèle s’appuie sur des règles de

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

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

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

F IG . 1.2: Considération progressive des plates-formes dans le M DA.

Positionnement Dans cette étude, le déploiement d’une application sur le support

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

Un langage de modélisation généraliste (G PML, Generic Purpose Modeling Lan-

2.1 Les plates-formes d’exécution

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

Ces deux approches témoignent d’une volonté de modélisation structurelle et compor-

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

2.2.1 Représentations enfouies

2.2.2 Représentations implicites

F IG . 2.1: Un profil U ML d’applications spécifiques à la plate-forme O SEK /V DX.

F IG . 2.2: Description U ML d’une application spécifique à la plate-forme O SEK /V DX.

Dans la littérature actuelle, les profils U ML dédiés à des plates-formes d’exécution

2.2.2.2 Approche D SML

Une approche alternative au profilage U ML capture implicitement les informations re-

F IG . 2.3: Un métamodèle d’applications spécifiques à la plate-forme O SEK /V DX.

La réalisation d’un D SML s’accompagne généralement d’une syntaxe concrète pour

2.2.3 Représentations explicites

F IG . 2.5: Un profil U ML de description de plates-formes d’exécution.

F IG . 2.6: Description explicite d’une plate-forme O SEK /V DX avec un profil U ML.

2.2.3.2 Approche D SML

F IG . 2.7: Un D SML de description de plates-formes d’exécution.

L’exemple de la figure 2.8 illustre l’utilisation de ce D SML pour la modélisation des

F IG . 2.8: Description explicite d’une plate-forme O SEK /V DX avec un D SML.

Dans la littérature actuelle, peu de D SML de description de plates-forme d’exécution