Présentation de QP

«Pendant plusieurs années, j’avais cherché à voir un livre ou un ma-gazine d’article qui décrirait une véritable méthodologie pratique pour coder les machines à état moderne (UML Statecharts) dans un langage de programmation courant comme le C ou le C++. Je n’ai jamais trouvé une telle technique» cite le Dr. Miro Samek dans son livre PSiCC (Prac-tical Statecharts in C/C++ : Quantum Programming for Embedded Systems). C’est en 2002 le Dr. Miro SAMEK a écrit le livre PSiCC qui était le premier livre à fournir ce qui manquait dans le domaine. C’est-à-dire une implémentation efficace des UML statecharts en C et C++.

PSiCC est également le premier livre à offrir le code source C et C++

d’un framework générique pour les applications temps réelle basées sur

les machines à état. La deuxième version du livre sort en 2008 et le fra-mework a été amélioré ainsi que son organisation, et est dénommé QP.

QP est une plateforme utilisée dans le développement des applications embarquées temps réel à partir des machines à état. Il est pour ce fait composer d’un processeur d’évènement dénommé QEP (Quantum Event Processor) et d’un framework gérant les aspects temps réel des systèmes dénommé QF (Quantum Framework). Un logiciel de modélisation et de génération de code dénommé QM accompagne également tout cet en-semble tout un aperçu est présenter au niveau de la figure 3.4. Mais, l’outil de modélisation des machines à état ne comporte pas tous les élé-ments des UML statecharts. En effet, les seuls éléélé-ments disponibles avec son outil de modélisation sont, les états, les transitions et les pseudos état de choix, d’entré historique et l’état initial.

Figure 3.4 – Aperçu du logiciel QM

QEP est un processeur d’événements hiérarchique générique, efficace et hautement portable qu’on peut utiliser dans n’importe quel environ-nement orienté évéenviron-nement, tels que les systèmes ayant une interface gra-phique, des jeux informatiques, ou les systèmes embarqués temps réel.

QEP met tout en œuvre pour être conforme à la spécification UML,

Chapitre 3. La génération de code dans les SETR

mais il ne peut pas vraiment mettre en œuvre l’ensemble des éléments du paquetage UML des machines état. Au lieu de cela, la stratégie de conception de QEP est de fournir juste assez d’éléments vraiment es-sentiels pour permettre directement la construction de machine à état de base et soutenir les concepts UML haut niveau à travers les modèles de conception. Ce processeur d’événement a été construit en tirant la meilleure partie des trois méthodes d’implémentation des machines à état à savoir : le NSC, le STT et le SP. Ce qui fait donc de lui une im-plémentation des machines à état plus puissante que l’utilisation de ces méthodes séparément.

De plus, QEP a un très faible encombrement RAM / ROM. Un objet de la machine à état ne nécessite qu’un seul pointeur de fonction dans la mémoire vive. Ce qui est très bénéfique car nous savons à quel point les mémoires vive et de stockage sont petites dans le domaine des systèmes embarqués. Ainsi, QEP permet de représenter l’implémentation d’une machine à état d’une façon très efficace, lisible et maintenable.

D’un autre côté, QF se charge de gérer l’exécution concurrente des machines à état. QF peut garantir que votre application est libre des

Figure 3.5 – Diagramme de paquetage illustrant l’interaction entre le framework temps réel, le RTOS et l’application [21]

risques traditionnels de préemption dans les systèmes multitâches tels

que l’inter-blocage, l’inversion de priorité, la famine, et le non détermi-nisme. Particulièrement, vous n’aurez jamais besoin d’utiliser les MU-TEX, les sémaphores, les moniteurs ou autre pénible mécanisme au ni-veau de votre application [21]. L’utilisation du framework temps réel se fait en se basant sur un RTOS de notre choix. La figure 3.5 montre les relations entre l’application le framework et le RTOS.

Conclusion partielle

Dans le processus de génération de code à partir des machines à état, plusieurs méthodes existent. Dans ce chapitre nous avons exposé les trois diverses méthodes les plus utilisées. Notre attention s’est le plus portée sur QEP qui a combiné et amélioré ses diverses méthodes.

Deuxième partie

MATERIELS ET

METHODES

CHAPITRE 4

Approches d’étude et outils

L’implémentation des UML statecharts nous pose d’abord le pro-blème de l’environnement dans lequel nous installerons l’outil de modé-lisation à utiliser puis de l’outil de génération de code. Notre méthode consiste à utiliser l’outil de modélisation Papyrus pour représenter nos diagrammes UML et l’outil de génération de code Acceleo qui sont tous deux des plugins intégrés à l’environnement Eclipse. Le code à générer se basera sur FreeRTOS. Dans ce chapitre, nous présentons la méthodologie d’étude ainsi que les différents choix techniques opérés dans l’implémen-tation de notre solution.

4.1 Eclipse, les outils de modélisation et de génération de code

Eclipse est un IDE open source, très connu et utilisé dans la com-munauté informatique. Il existe plusieurs versions et modèles d’Eclipse.

Pour nos travaux, nous allons utiliser la dernière version qui est baptisée LUNA, plus précisément l’Eclipse MDT (Modeling Tools) qui regroupe les divers plugins dont nous avons besoin pour travailler avec les mo-dèles UML. Il dispose en son sein de plusieurs outils de modélisation et de génération de code.

Chapitre 4. Approches d’étude et outils

4.1.1 Les outils de modélisation

Dans le but de pouvoir représenter les modèles UML, plusieurs ou-tils de modélisation ont été développés. Parmi ceux qui sont intégrés à la plateforme Eclipse, nous pouvons citer Papyrus et Topcased. Pa-pyrus s’appuie sur l’implantation EMF (Eclipse Modeling Framework) du méta-modèle UML2 considéré comme étant l’implantation de réfé-rence en termes de gestionnaire de modèles UML2. L’objectif du projet Papyrus open-source est double : premièrement, Papyrus vise à offrir une implantation complète, efficace, robuste et méthodologiquement du standard UML2, ainsi que de ses deux extensions majeures, SysML et MARTE ; deuxièmement, Papyrus est un outil ouvert et flexible pour la définition et l’utilisation de langages de modélisation de domaines spé-cifiques, grâce à une mise en œuvre très avancée du concept de profils UML.

Topcased développé par un consortium avec entre autre Airbus France, CNES, et Thalès, est un environnement de modélisation complet, qui possède un éditeur UML (GEF UML Editor), et de nombreux outils liés à l’ingénierie dirigée par les modèles comme la simulation d’exécution, la validation, la traçabilité des exigences, etc... [24]. Cependant, ces deux outils autrefois concurrents ont fusionné pour obtenir Papyrus MDT, qui en est à sa version 1.0 lors de la réalisation de nos travaux. Ainsi, les fonctions de ses deux puissants outils sont combinées en un seul projet.

Ce qui fait de lui un outil très complet pour la modélisation de nos dia-grammes UML et qui justifie son choix pour la modélisation des UML Statecharts dans nos travaux. Il permet la validation des modèles, leur simulation avec l’outil MOKA qui lui est intégré. La validation se base sur les contraintes OCL (Object Constraint Langage) qui est le langage sémantique utilisé par UML, la simulation se base sur Alf et fUML. Mais en travaillant avec les machines à état UML pour la génération automa-tique de code, les contraintes et les corps des fonctions sont souvent directement écrits dans le langage cible ce qui ne permet pas avec l’état actuel des travaux autour de papyrus MDT de faire les simulations de

nos machines à états.

Il existe encore beaucoup d’autres modeleurs UML, comme ArgoUML, starUML, etc. Ces outils, bien qu’ils puissent être de très bonne qualité, sont généralement moins complets et moins aboutis que ceux cités ci-dessus [24].

4.1.2 Les outils de génération de code

La génération de code consiste en une transformation du modèle source en un autre modèle cible. Une transformation est une généra-tion automatique d’un modèle cible à partir d’un modèle source selon une définition de transformation. Une définition de transformation est un ensemble des règles de transformation qui décrit comment un modèle source peut être transformé en un modèle cible [15].

Les modèles UML représentés par les outils de modélisation sont sto-ckés dans un format de fichier standard dénommé XMI pour pouvoir être interchangeables entre les divers outils de modélisation. Deux principales approches sont identifiées dans les littératures pour la génération de code dans le contexte des conceptions basées sur les modèles : l’approche à base de visiteur, et la génération de code basée sur les templates [6].

L’approche à base de visiteur consiste à utiliser un langage de program-mation comme le langage Java pour parcourir le fichier XMI du modèle afin de générer le code correspondant à chaque élément rencontré dans le fichier. D’autre part, les templates sont des fragments de code compo-sés de texte statique et de texte paramétré. Les textes paramétrés sont remplacés dans le processus de génération par le code adéquat dans le langage cible qui a été défini. La technique basée sur les templates est plus avantageuse que celle basée sur les visiteurs car les templates sont très semblables au code à générer et ils sont compréhensibles et facile à construire.

Les outils de génération de code intégré à la plateforme Eclipse basés sur les templates sont Acceleo, JET et Xpand. Nous choisirons Acceleo car il est basé sur la norme MOFM2T (Model to Text Transformation Language) et les modèles UML 2.X construis avec divers outils de

mo-Chapitre 4. Approches d’étude et outils

délisation sont compatibles avec lui. Nous l’utiliserons dans sa version 3.3.

Acceleo est un outil de transformation modèle vers texte (son déve-loppement a commencé en 2006) ; son objectif principal est de mettre en œuvre des générateurs de codes. Un programme Acceleo nécessite un méta-modèle et un modèle conforme avec le méta-modèle à partir duquel il génère le code source. Acceleo est sous la forme d’un plugin Eclipse convivial, donc facile à installer, et dispose d’outils de coloration syntaxique, d’auto complétion, etc. Le méta-modèle et le modèle sont définis en utilisant EMF, ce qui rend Acceleo compatible avec d’autres outils basés sur EMF [10]. Une caractéristique principale d’Acceleo est que le texte généré est mélangé avec la syntaxe Acceleo. La syntaxe d’Acceleo propose des structures de contrôle, les boucles, la définition des variables, mais avec une portée limitée. Il dispose des requêtes qui permettent à l’utilisateur de définir des opérations qui pourraient être répétées plusieurs fois. Mais Acceleo ne dispose pas de syntaxe pour dé-finir ni les variables globales, ni les structures de données tels que les tableaux, les listes etc. Pour pallier ces insuffisances, il est possible de définir des services Java que l’on invoque pour opérer des traitements qui ne pouvaient être réalisés en se limitant aux syntaxes d’Acceleo.