Génération du code exécutable

Le modèle spécifique à la plate-forme généré à la fin du processus de transformation générique est un modèle UML qui encapsule les aspects fonctionnels et les aspects spécifiques à la plate-forme cible :

– Les aspects fonctionnels sont ceux qui sont spécifiés par le concepteur au niveau du modèle de l’application indépendant de la plate-forme.

– Les aspects spécifiques à la plate-forme correspondent aux opérations et propriétés qui sont annotées par les stéréotypes du profils DPD dans le modèle détaillé de plate- forme.

– Les comportements spécifiés par des activités nécessaires à l’implantation des mécanismes de concurrence, de synchronisation et de communication.

Les figures 5.25 et 5.26 représentent les modèles de l’application Producer/Consumer spécifiques aux plates-formes Java et C++/POSIX. A partir de ces modèles, un code exécutable peut être généré en utilisant des générateurs de code standard UML/Java et UML/C++. Ces générateurs doivent supporter la génération de codes depuis les éléments des packages UML qui supporte la modélisation structurelle et comportementale.

Pour notre travail, la génération de code est réalisée à travers les générateurs de codes Java et C++ qui sont intégrés dans Papyrus. Papyrus est développé au sein du laboratoire CEA LIST, c’est un outil d’édition graphique de modèles UML2.3, rigoureusement conforme à la norme UML.

2

Discussion

L’infrastructure de transformation proposée dans cette étude a été décrite dans le langage de transformation ATL [21]. Les premiers résultats de l’utilisation de cette infrastructure sont

Producer-Consumer notify() Console main() System init() send() receive() queue:LinkedList Connector init() incrementCounter_protected() decrementCounter_protected() incrementCounter() decrementCounter() token = 1 sem : Semaphore quantity : Integer Counter createObj(count, con) init() run() launch() stop() resume() suspend() produce() period = 10 priority = 7 suspended = false stopped = false thrd : Thread con : Connector count : Counter console : Console Producer createObj(count, con) init() run() launch() stop() resume() suspend() produce() period = 10 priority = 4 suspended = false stopped = false thrd : Thread con : Connector count : Counter Consumer

FIGURE5.25 – Modèle généré spécifique à la plate-forme Java

Producer-Consumer notify() Console main() System init() send() receive() queue : mqd_t Connector init() incrementCounter_protected() decrementCounter_protected() incrementCounter() decrementCounter() token = 1 sem : sem_t quantity : Integer Counter createObj(count, con) init() staticOp() launch() stop() resume() suspend() produce() period = 10 priority = 7 suspended = false stopped = false thrd : pthread_t con : Connector count : Counter console : Console Producer createObj(count, con) init() staticOp() launch() stop() resume() suspend() produce() period = 10 priority = 4 suspended = false stopped = false thrd : pthread_t con : Connector count : Counter Consumer

FIGURE5.26 – Modèle généré spécifique à la plate-forme C++/POSIX

encourageants puisque, d’une part, ils montrent que l’implantation d’une infrastructure de transformation basée sur des plates-formes existe et que, d’autre part, une infrastructure générique est envisageable pour aider à la construction des transformations ciblant plusieurs plates-formes tout en préservant les critères de qualité. Ces critères ont été définis dans le chapitre 3 pour juger la qualité de la transformation de modèle.

En effet, les transformations construites dans cette étude satisfont les critères suivants : – La réutilisabilité : les transformations sont indépendantes des concepts applicatifs et

de la plate-forme cible

– La séparation de préoccupation : Les transformations sont réalisées par un expert IDM sont se préoccuper des informations spécifiques à la plate-forme.

3 Conclusion 97

de l’application multitâche ainsi que ses comportements associées sont réifiés lors de déploiement par rapport à la plat-forme cible.

– la complétude : le modèle produit en sortie de la transformation est complet. A partir de ce modèle, on peut générer du code exécutable.

L’explicitation des plates-formes a permis de capitaliser une grande partie des règles de transformation. Cependant, ces règles sont dépendantes :

1. de la méthode de modélisation proposée pour la conception des systèmes multitâches. 2. du profil SRM utilisé comme langage pivot pour la modélisation des plates-formes

d’exécution et des concepts applicatifs de haut niveau.

3. des hypothèses de correspondance entre l’application et les ressources de la plate- forme. Ces hypothèses peuvent être spécialisés pour établir une correspondance spécifique entre un concept applicatif et une ressource de la plate-forme.

La transformation proposée est donc générique pour des modèles applicatifs et des modèles de plates-formes respectant les hypothèses de modélisations proposés dans cette étude.

3

Conclusion

L’objectif de ce chapitre était d’expérimenter l’intégration des modèles détaillés de plates- formes dans une ingénierie générative dirigée par les modèles. Pour cela, dans un premier temps, un cadre de conception et de déploiement été proposé. Ce cadre vise à déployer une application multitâche indépendante de la plate-forme sur un ensemble de plates-formes cibles. Le cadre proposé offre une méthode de modélisation des applications multitâches. Il supporte aussi une infrastructure de transformation générique permettant de déployer l’application multitâches sur une plate-forme cible spécifiée par son modèle détaillé en entrée de cette infrastructure. Cette infrastructure gère les mécanismes de communication et de synchronisation d’une manière indépendante de la plate-forme.

Ce cadre d’expérimentation a montré qu’une infrastructure de transformation générique basée sur des modèles détaillés de plates-formes est faisable. Il a mis en avant une véritable séparation de préoccupation entre un concepteur qui modélise son application multitâche suivant la méthode proposé, un fournisseur des chaînes de transformations qui offre une infrastructure de transformation sans se préoccuper de la plate-forme cible et enfin, un expert de plate-forme qui fournit un modèle détaillé de cette plate-forme. Ce cadre d’expérimentation a été publié dans la conférence internationale ICECCS 2011 [50].

Le cadre d’expérimentation, proposé dans ce chapitre, doit être confronté aux critères de qualités définis dans le chapitre 3 en termes de réutilisation des transformations et en termes d’impact sur le coût de portabilité des applications. C’est le sujet du chapitre suivant.

C

6

Validation et expérimentation

1 Évaluation de la performance . . . . 98 1.1 Description de la procédure d’évaluation . . . 98 1.2 Résultats et discussion . . . 98 2 Spécification d’un cas d’étude . . . . 99 2.1 Présentation de Java temps réel . . . 100 2.2 Modélisation de la plate-forme RTSJ . . . 101 2.3 Intégration du modèle détaillé de RTSJ dans le processus de

déploiement . . . 105 2.4 Évaluation du coût de la portabilité . . . 106 3 Conclusion . . . 109

L’objectif de ce chapitre est d’évaluer et valider le cadre expérimental proposé dans cette étude. Plus particulièrement il vise deux objectifs : a) étudier la performance du code généré et b) mesurer le coût de portage d’une application vers une nouvelle plate-forme en utilisant le cadre proposée.

Pour cela, ce chapitre est divisé en deux sections principales. La première section évalue la performance de notre approche et confronte les résultats vis-à-vis des implantations orientées objet codées manuellement. La deuxième section présente un cas d’étude où une application est portée vers une nouvelle plate-forme (Java temps réel). Premièrement, elle présente la modélisation de la nouvelle plate-forme avec les heuristiques de modélisation présentées dans le chapitre 4, ensuite, elle propose un ensemble de métriques pour estimer le coût de portage de l’application.

1

Évaluation de la performance

L’objectif principal de cette section est de montrer que le processus de transformation gé- nérique proposé n’introduit pas une consommation de mémoire supplémentaire signifiante et donc de prouver que ce processus peut être utilisé pour le développement des systèmes multitâches embarqués. En effet, l’empreinte mémoire est considérée comme une contrainte importante pour les systèmes embarqués. Ceci est particulièrement important dans un sens où la complexité croissante des logiciels embarqués a introduit une nécessité croissante d’utiliser des processus modernes de génie logiciel pour faciliter le développement des tels systèmes. La motivation majeure de ces processus de développement est la réutilisation. Pour garantir la réutilisation, ces processus, comme par exemple les approches orientées aspects [67] ou celles orientées composants [81], adoptent des techniques qui conduisent à une quantité supplémentaire de code et des données utilisés pour réaliser une fonctionnalité du système. Cela introduit une augmentation de l’empreinte mémoire du système et nui aux contraintes des systèmes embarqués qui possèdent des ressources limitées en termes de mémoire. Par conséquence, un processus de développement dédié aux systèmes embarqués ne doit pas introduire une consommation de mémoire supplémentaire significative.