Étude comparative pour la modélisation de plates-formes d'exécution Application au temps réel embarqué Matthias Brun*,** — Jérôme Delatour** — Yvon Trinquet* — Frédéric Thomas*** — Sébastien Gérard**** * Institut de Recherche en Communications et Cybernétique de Nantes, Équipe Systèmes Temps Réel, Unité Mixte de Recherche (UMR) 6597 du CNRS 1 rue de la Noë, BP 92101, F-44321 Nantes cedex 03
** Groupe ESEO, Équipe de recherche TRAME 4 rue Merlet de la Boulaye, BP 30926, 49009 Angers cedex
*** OBEO, 2 route de la Noue, BP 76, 91193 Gif-sur-Yvette cedex **** CEA LIST, Boîte courrier 94, F-91191 Gif-sur-Yvette cedex RÉSUMÉ.
L'ingénierie des modèles promet une amélioration de la productivité du développement de logiciels, notamment une réduction des temps de développement consacrés à l'adaptation des applicatifs aux technologies permettant leur exécution. Pour atteindre ce but, une modélisation des technologies d'exécution (identifiées sous le terme de plate-forme), ainsi que la définition de transformations automatisant ces adaptations, sont nécessaires. Toutefois, peu de travaux ont été menés, à la fois, pour préciser comment modéliser ces plates-formes et comment les mettre en œuvre dans des transformations. Pour établir des éléments de réponses à ces questions, différentes propositions portant sur la représentation d'une plate-forme d'exécution et sur leur utilisation dans des transformations ont été évaluées. Cette évaluation repose sur une quantification de l'activité de développement de transformations utilisées dans le domaine du temps réel embarqué, à des étapes où la prise en compte du support d'exécution (noyaux temps réel) est indispensable. A l'issue de ces différentes expérimentations, et suivant le contexte d'utilisation, un ensemble de recommandations sur la modélisation des plates-formes et leur utilisation dans des transformations est proposé. Ces recommandations sont valables dans le cadre d'une ingénierie utilisant UML ou des langages dédiés, nos expérimentations ayant été effectuées avec chacune de ces deux approches. : Plate-forme d'exécution, temps réel, Ingénierie Dirigée par les Modèles (IDM), transformation de modèles, Métamodèle de plate-forme, modèle de plate-forme, UML MARTE, Langage de Modélisation Dédié MOTS-CLÉS
KEYWORDS:
Platform, Real-Time, Model Driven Architecture (MDA), model transformation, model of platform, Meta-model of platform, UML MARTE, Domain Specific Modeling Language (DSML)
Revue. Volume X – n° x/année, pages 1 à X
2
Revue. Volume X – n° x/année
1. Introduction L'un des soucis constants de l'industrie informatique dans le développement de logiciels est de s'abstraire des considérations technologiques. Différentes couches d'abstractions (des systèmes d'exploitation aux intergiciels, en passant par les machines virtuelles) ont ainsi été développées pour que le logiciel applicatif (ou sa modélisation) soit de plus en plus indépendant des technologies de mise en œuvre. Une telle séparation permet d'espérer une meilleure réutilisation du logiciel applicatif (en particulier de la connaissance métier qu'il capture) sur les supports technologiques sous-jacents. Malgré de nombreux efforts liés à la normalisation, aux méthodologies et aux outillages, beaucoup de temps est encore dépensé à l'adaptation des applicatifs aux supports technologiques, supports en évolution constante. L'un des points essentiels pour parvenir à une plus grande séparation des préoccupations est la modélisation explicite des aspects technologiques indépendamment des aspects applicatifs. L'Ingénierie Dirigée par les Modèles (IDM) a très tôt identifié cette problématique de séparation des préoccupations technologiques. En particulier, l'approche MDA (Model Driven Architecture) a proposé un cadre méthodologique différenciant des modèles indépendants des plates-formes (PIM : Platform Independant Model) de ceux en dépendants (PSM : Platform Specific Model). Le terme de plate-forme est utilisé pour caractériser les technologies sous-jacentes. Des transformations de modèles, plus ou moins automatiques, sont alors définies pour spécialiser un PIM en un PSM. Actuellement, peu de travaux ont été menés, à la fois, pour préciser ce qu'est un modèle de plate-forme (parfois identifié dans le MDA comme PDM – Platform Description Model) et définir comment mettre en œuvre de tels modèles dans des transformations. Un ensemble de questions corollaires se posent : Quelle représentation d'une plate-forme est la plus adéquate ? Une représentation est-elle préférable pour un contexte d'utilisation ? Peut-on espérer capitaliser des transformations et les réutiliser dans des contextes différents ? Pour établir des éléments de réponses à ces questions, nous avons expérimenté et évalué différentes propositions, à la fois, sur la représentation d'une plate-forme d'exécution et sur son utilisation dans des transformations. Ces expérimentations ont été faites dans le domaine du temps réel embarqué. En effet, les supports d'exécution y jouent un rôle fondamental. Les considérations inhérentes à ce domaine (respect des contraintes temporelles, limitation des ressources disponibles, accès à des ressources partagées, sûreté de fonctionnement, etc.) dépendent étroitement de ce support. La plate-forme d'exécution joue un rôle, depuis l'analyse des propriétés fonctionnelles et temporelles d'une application, tôt dans le cycle de développement, jusqu'au déploiement de l'application sur la plateforme. En outre, les besoins de réutilisation et de capacité de portage d'une
Étude comparative pour la modélisation de plates-formes d'exécution
3
application sur différentes plates-formes orientent le développement logiciel vers des conceptions indépendantes de toute plate-forme d'exécution. Cette séparation se retrouve souvent dans les pratiques métiers et les formalismes utilisés dans ce domaine. Par exemple, dans la norme AUTOSAR (AUTOSAR, 2008), norme automobile pour la conception de l'électronique et l'informatique embarquées, la modélisation de l'applicatif est clairement séparée et indépendante du support d'exécution, support qui lui aussi a été normé (successivement OSEK/VDX OS et AUTOSAR OS). Pour toutes ces raisons, le domaine du temps réel embarqué nous semble un bon candidat d'étude pour les plates-formes d'exécution. Lors de précédents travaux (Thomas et al., 2007), il a été identifié deux grandes approches de modélisation des plates-formes d'exécution : l'une, dite implicite, capture les concepts des plates-formes dans des métamodèles, l'autre, dite explicite, les capture dans des modèles. Toutefois, le contexte de ces travaux était basé sur le langage de modélisation UML (Unified Modeling Language) et son mécanisme d'extension par profil. Les premiers éléments de réponses apportés (intérêt d'une représentation explicite du PDM, algorithme de transformation en grande partie générique) étaient-ils liés aux spécificités d'UML ou étaient-ils toujours valides dans un contexte de langages dédiés, conçus et implantés selon d'autres technologies ? Afin de répondre à cette interrogation, nous avons poursuivi nos expérimentations dans un contexte de développement utilisant des DSML (Domain Specific Modeling Language - par opposition à Generic Purpose Modeling Language dont UML est un représentant, y compris dans ses formes profilés). En effet, l'utilisation d'un langage généraliste n'est pas toujours de mise, de nombreux langages de modélisation dédiés au temps réel et à l'embarqué sont parfois utilisés dans notre domaine d'activité, citons par exemple SDL (Specification and Description Langauge) et AADL (Architecture Analysis and Design Language). A l'image des profils UML, les DSML identifient des concepts métiers et offrent des moyens d'expressions dédiés à des domaines d'application. A l'inverse des profils UML, les DSML ne se basent pas sur le métamodéle UML (noyau commun de concepts) mais définissent entièrement des langages plus restreints. Il se conforment pour cela à des méta-métamodèles (tels que le MOF (Meta Object Facility) de l'OMG ou Ecore du projet EMF (Eclipse Modeling Framework)). A l'issue de ces expérimentations, il nous est maintenant possible de comparer les deux grandes approches de modélisation des plates-formes d'exécution, implicite ou explicite et d'apporter des réponses qui soient indépendantes des technologies utilisées (par profil UML ou DSML). Cet article est agencé en cinq parties. Suite à cette première partie introductive, un rappel sur la notion de plate-forme dans l'IDM est effectué. En partie 3, nous présentons les deux grandes approches de modélisation des plates-formes. Pour chacune d'elles, nous expliquons leurs représentations en UML et en DSML. En partie 4, nous donnons les principes de manipulations des descriptions de plate-
4
Revue. Volume X – n° x/année
forme pour déployer des applications (transformations d'un PIM vers un PSM). Cette partie se concentre sur les DSML, car les transformations basées sur UML ont fait l'objet d'un précédent article (Thomas et al., 2007). En partie 5, nous présentons les expérimentations que nous avons menées et l'évaluation de chacune des approches au travers des résultats obtenus. En partie 6, nous concluons sur cette étude et nos perspectives de recherche. 2. Caractérisation des plates-formes d'exécution dans l'IDM 2.1. Définition générale Le concept de plate-forme d'exécution se réfère aux systèmes, supports logiciels et matériels, nécessaires à l'exécution d'une application. La représentation en couches successives d'infrastructure matérielle, de système d'exploitation, de machine virtuelle et d'intergiciel illustre une hiérarchie typique des plates-formes d'exécution (Atkinson et al., 2005). Chacune de ces couches fournit une abstraction des platesformes sous-jacentes (Sangiovanni-Vincentelli et al., 2004). En pratique, une plate-forme est souvent considérée comme une application pour une plate-forme de plus bas niveau d'abstraction (Marvie et al., 2006). 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 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 (Delatour et al., 2005). Orthogonalement à cette notion de rôle, deux types de plates-formes se distinguent : les plates-formes abstraites et les plates-formes concrètes (Almeida, 2006). Une plate-forme abstraite est une plate-forme fictive. Elle offre les concepts idéaux, à un instant donné, face aux besoins de développement d'une application. L'implantation de ces concepts relève ultérieurement d'une ou de plusieurs platesformes concrètes. La différence entre plates-formes d'exécution abstraites et concrètes réside donc dans la mise à disposition d'un support fonctionnel permettant l'exécution d'une application. Une étude plus détaillée de la notion de plate-forme d'exécution a fait l'objet d'un précédent article (Thomas et al., 2007). Des précisions y sont données sur les apports successifs des travaux que nous avons référencés dans cette partie. 2.2. La considération des plates-formes dans le MDA L'OMG (Object Management Group), un consortium international de normalisation, définit un cadre normatif pour l'IDM : le MDA (OMG, 2003). L'un des objectifs du MDA est de faciliter le développement d'applications logicielles sur
Étude comparative pour la modélisation de plates-formes d'exécution
5
différentes plates-formes technologiques. Pour cela, cette approche vise à générer, par transformation de modèles, des applicatifs dédiés à une plate-forme technologique donnée (PSM : Platform Specific Model), à partir de descriptions indépendantes de toute plate-forme (PIM : Platform Independent Model). Le MDA propose ainsi de mettre en œuvre un même modèle de fonctionnalités (ou modèle métier) sur différentes solutions technologiques. Le MDA ne précise cependant pas comment renseigner les informations sur les plates-formes technologiques. La notion de description de plate-forme est évoquée (PDM : Platform Description Model), mais peu de précisions sont données sur sa forme ou sa prise en compte dans le processus de génération. Un PDM peut, par exemple, faire partie intégrante d'une transformation (d'un PIM vers un PSM) ou être transmis comme paramètre à cette transformation. Le MDA spécifie qu'une plateforme fournit un ensemble de fonctionnalités, au travers d'interfaces, et des patrons d'utilisation de ces fonctionnalités (OMG, 2003). Concernant les plates-formes d'exécution, elles sont décrites par un modèle constitué de ressources offrant des services nécessaires à l'exécution d'autres systèmes qualifiés d'applications (Selic, 2005). Enfin, l'approche MDA précise que l'utilisateur d'une plate-forme n'est pas concerné par les détails d'implantations des ressources et des services de la plateforme. Dans un contexte logiciel, un modèle de plate-forme d'exécution se restreint donc à la description de leurs signatures et de leurs comportements visibles depuis l'interface de programmation (Thomas et al., 2007). Dans le respect de l'approche MDA et dans la lignée des travaux de C. Atkinson (Atkinson et al., 2005), de R. Marvie (Marvie et al., 2006) et de B. Selic (Selic, 2000, 2005), nous avons identifié quatre axes pour modéliser l'interface de programmation d'une plate-forme d'exécution (Thomas et al., 2007) : 1) la caractérisation des concepts (les ressources et les instances de ressources que la plate-forme offre en nombre limité), 2) la caractérisation des traitements (les services associés aux ressources), 3) la caractérisation des règles d'utilisation (les contraintes et les patrons d'utilisation des ressources et des services) et 4) la caractérisation du comportement des ressources et des services (la description du comportement observable de ces ressources et de ces services). Nous nous focalisons, dans la suite de cet article, sur les deux premiers axes : la description des ressources et des services offerts par les plates-formes d'exécution logicielles. 2.3. Le motif ressource/service Dans le cadre des profils standards (OMG, 2001) puis (OMG, 2006) dédiés à la conception des application temps réel, l'OMG propose un motif de modélisation des ressources d'un système (figure 1) ; une ressource est instanciable sous la forme d'une instance de ressource ; elle offre des services et peut être quantifiée ou qualifiée par des propriétés non-fonctionnelles (NFP, Non Functionnal Properties).
6
Revue. Volume X – n° x/année
Figure 1. Extrait du motif ressource/service (OMG, 2006) Nous nous appuierons sur ce motif, dans la partie suivante, pour spécifier dans un métamodèle les ressources et les services offerts par les plates-formes d'exécution temps réel embarquées. 3. Principe de modélisation d'une plate-forme d'exécution 3.1. Deux approches de modélisation 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.), deux approches majeures de modélisation des plates-formes se distinguent. La première approche consiste à décrire la plate-forme dans un métamodèle conforme à un méta-métamodèle (nous parlons alors de description implicite ou de plate-forme implicite) (Kukkala et al., 2005) (Delatour et al., 2005) (Brun, 2006) (Taha et al., 2007). Ce métamodèle définit généralement un langage de modélisation d'applications dédiées à la plate-forme. Les ressources et les services offerts par la plate-forme sont représentés par des éléments du langage. La seconde approche consiste à décrire la plate-forme dans un modèle conforme à un métamodèle de plate-forme (nous parlons alors de description explicite ou de plate-forme explicite) (Sangiovanni-Vincentelli et al., 2001) (OMG, 2001) (Chen et al., 2003) (Pinto, 2004) (MPT, 2004) (Szemethy, 2006). Les ressources et les services fournis par la plate-forme sont représentés par des éléments du modèle. Cette approche se destine à expliciter ultérieurement les relations entre une plateforme et les applications qu’elle accueille. Nous présentons dans cette partie les principes de modélisation d'une plate-forme d'exécution, pour chacune des approches, dans une version UML et une version DSML. Chacune des approches sera illustrée par des exemples volontairement
Étude comparative pour la modélisation de plates-formes d'exécution
7
simplifiés. L'objectif n'est pas d'exposer une expérimentation dans son entier mais de mettre en valeur les principes de modélisation impliqués. Les exemples se focalisent sur la considération de plates-formes d'exécution pour des technologies dédiées à l'embarqué temps réel (les systèmes d'exploitation temps réel embarqués). Par conséquent, nous nous appuyons sur la modélisation du concept de tâche basique (BasicTask) offert par la plate-forme d'exécution OSEK/VDX (OSEK/VDX, 2005) (Trinquet, 2003). Une tâche basique OSEK/VDX fournit un contexte pour l'exécution d'un traitement spécifié par l'utilisateur sous la forme d'une routine (ou fonction). L'interface de programmation d'OSEK/VDX définit un ensemble normalisé de services et de propriétés associés aux tâches. Les services ActivateTask et TerminateTask permettent, par exemple, d'activer et de terminer l'exécution d'une tâche. De même, les propriétés Priority et StackSize permettent de préciser respectivement la priorité statique d'ordonnancement et la taille de la pile allouée à une tâche. 3.2. Description implicite d'une plate-forme d'exécution dans un métamodèle 3.2.1. Approche UML Suivant l'approche UML, la description implicite d'une plate-forme d'exécution peut prendre la forme d'une extension au métamodèle UML (c'est-à-dire un profil UML). Les éléments profilés du métamodèle sont alors spécialisés par des stéréotypes. Cette technique d'extension (dite extension légère) permet d'adapter la syntaxe et la sémantique du langage UML à un domaine particulier (dans notre cas, la description d'applications susceptibles de s'exécuter sur une plate-forme d'exécution donnée). Un profil UML spécialise la structure d'UML et une part de sa sémantique à travers le choix des noms des stéréotypes, de leurs attributs et de leurs relations. La figure 2 est un exemple de profil UML dédié à la description d'applications OSEK/VDX. Ce profil définit le stéréotype BasicTask permettant de décrire des tâches basiques OSEK/VDX. Ce stéréotype étend la métaclasse Class d'UML. Il sera donc utilisé pour spécifier la sémantique des classes d'un modèle. Dans l'exemple, le profil est appliqué à un modèle de contrôleur de robot (RobotController). La classe MotionController est stéréotypée BasicTask, une tâche basique de la plate-forme est ainsi dédiée au contrôle de mouvement. L'attribut priority du stéréotype est renseigné dans le but d'accorder une priorité 10 à cette tâche. De même, l'attribut du stéréotype entryPoint stipule que le point d'entrée de la tâche correspond à la méthode trajectoryControl() du contrôleur.
8
Revue. Volume X – n° x/année
Figure 2. Extrait d'un profil UML pour la description d'applications OSEK/VDX 3.2.2. Approche DSML Une solution alternative décrit implicitement la plate-forme d'exécution dans un DSML. Le métamodèle du DSML est alors implanté conformément à un langage de métamodélisation (par exemple, le standard MOF (Meta Object Facility) de l'OMG ou Ecore du projet EMF (Eclipse Modeling Framework)). Ce métamodèle, nommé syntaxe abstraite, définit les concepts et relations entre ces concepts qui caractérisent le DSML. Une part de leur sémantique est décrite à travers les noms des métaclasses, des attributs et des relations. Les syntaxes concrètes des DSML (graphiques ou textuelles) ne seront pas détaillées dans cet article, seuls les concepts de ces syntaxes nécessaires à la compréhension de certaines illustrations seront précisés. La figure 3 est un exemple de DSML dédié à la description d'applications OSEK/VDX. Ce DSML définit les concepts de tâche basique et d'instance de tâche basique. L'application introduite précédemment dans la figure 2 est ici modélisée avec le DSML (pour des raisons pédagogiques, nous avons réduit la représentation du point d'entrée (entryPoint) à une chaîne de caractère). Le modèle de l'application est décrit avec une syntaxe concrète mixte (graphique et textuelle). Cette représentation nous semble suffisamment intuitive pour ne pas être détaillée.
Figure 3. Extrait d'un DSML pour la description d'applications OSEK/VDX
Étude comparative pour la modélisation de plates-formes d'exécution
9
3.3. Description explicite d'une plate-forme d'exécution dans un modèle La seconde approche consistant à décrire explicitement une plate-forme d'exécution dans un modèle nécessite de se conformer à un métamodèle de plateforme. Or, bien que les métamodèles que nous ayons recensés (au travers des travaux évoqués dans la partie 3.1) permettent de décrire une large gamme de plates-formes, les artefacts qu'ils proposent se sont avérés incomplets ou trop abstraits pour satisfaire à nos besoins (Thomas et al., 2007). Pour certains, les niveaux d'abstraction sont, par exemple, trop éloignés des concepts métiers que nous souhaitons exprimer (tels que les notions de tâches, de sémaphores ou de boîtes aux lettres). Nous nous sommes donc intéressés à la conception d'un métamodèle de plate-forme logicielle d'exécution temps réel embarquée. Pour cela, les concepts utiles à notre domaine d'intérêt (les systèmes d'exploitation temps réel embarqués) ont été spécifiés dans un modèle de domaine qui a ensuite été implanté sous la forme d'un profil UML et d'un DSML. 3.3.1. Le modèle de domaine Le modèle de domaine est basé sur la notion de ressources qui offrent des services (motif ressource/service, figure 1). Le concept de ressource est spécialisé pour le domaine des applications logicielles (figure 4). Les ressources logicielles fournissent alors des services spécifiques comme, par exemple, la création et la destruction de la ressource.
Figure 4. Extrait du modèle de domaine : les ressources logicielles Sur la base des systèmes d'exploitation multitâches et des standards d'interface de programmation très largement utilisés dans l'industrie (tels que POSIX, OSEK/VDX, ARINC-653), trois familles de concepts représentatifs du domaine du temps réel embarqué ont été identifiées : – les ressources concurrentes, qui offrent des contextes d'exécution concurrents (par exemple les tâches et les interruptions) ; – 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) ; – les ressources de gestion (resource broker), qui fournissent des services pour la gestion d'autres ressources (par exemple les ordonnanceurs ou les pilotes).
10
Revue. Volume X – n° x/année
Chacune de ces familles spécialise alors le concept de ressource logicielle. La figure 5 présente la description des ressources concurrentes du modèle de domaine. Deux catégories de ressources concurrentes sont distinguées dans cet extrait : celles activées par un ordonnanceur (SwSchedulableResource) et celles activées suite à un évènement asynchrone du système (InterruptResource). L'activation d'une ressource concurrente peut être périodique, apériodique ou sporadique (propriété type typée par l'énumération OccurenceKind). 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 ou la taille de sa pile. Les associations entre la classe SwConcurrentResource et les classes ResourceProperty et ResourceService définissent les rôles que jouent respectivement les propriétés et les services d'une ressource concurrente.
Figure 5. Extrait du modèle de domaine : les ressources concurrentes La limitation en taille de l'article ne nous permet pas de présenter tous les détails du modèle de domaine. Ce modèle ainsi que son implantation dans un profil UML ayant été intégrés dans le profil UML/MARTE standard (UML profile for Modeling and Analysis of Real-Time and Embedded systems) (OMG, 2007), nous invitons le lecteur à se reporter à la norme pour cela (MARTE::SRM, Software Resource Modeling package, chapitre 14) . 3.3.2. Principe d'implantation du modèle de domaine en UML L'implantation du modèle de domaine dans un profil UML permet d'adapter la syntaxe et la sémantique du langage UML à la description de plate-forme d'exécution temps réel embarquée. Pour cela, les stéréotypes de chacun des concepts du domaine étendent la métaclasse Classifier d'UML (figure 6). Ils peuvent ainsi être utilisés pour spécifier la sémantique des métaclasses filles de Classifier (par exemple, les classes, les composants et les collaborations).
Étude comparative pour la modélisation de plates-formes d'exécution
11
La figure 6, extraite du profil MARTE::SRM, présente la modélisation du stéréotype permettant de décrire des ressources d'exécution concurrentes. Dans cet exemple, les concepts natifs d'UML TypedElement et BehavioralFeature sont utilisés en place des stéréotypes attendus ResourceProperty et ResourceService.
Figure 6. Extrait du profil MARTE::SRM L'exemple décrit en figure 7 illustre l'utilisation de ce profil pour la modélisation du concept de tâche basique OSEK/VDX. Les activations et les exécutions des tâches basiques étant gérées par un ordonnanceur, une tâche basique est identifiée comme une ressource ordonnançable (SwSchedulableResource). Les sémantiques des services et des propriétés sont précisées en renseignant les propriétés du stéréotype. Par exemple, l'attribut nommé priority permet d'exprimer la priorité d'une tâche. Cet attribut est donc référencé par la propriété priorityElements du stéréotype SwSchedulableResource.
Figure 7. Extrait du modèle de la plate-forme OSEK/VDX fait avec MARTE::SRM
12
Revue. Volume X – n° x/année
3.3.3. Principe d'implantation du modèle de domaine dans un DSML Parallèlement, l'implantation du modèle de domaine dans un DSML reprend la hiérarchie des ressources logicielles (SwResource) identifiée dans le modèle de domaine (figure 8). L'attribut name de la métaclasse SwResource (dont héritent toutes les ressources) ainsi que les attributs name des métaclasses ResourceProperty et ResourceService permettront d'associer les éléments d'un modèle de plate-forme d'exécution aux concepts du langage.
Figure 8. Extrait du DSML présenté : les ressources logicielles Les propriétés des ressources de chaque plate-forme d'exécution sont d'un type fourni par la plate-forme. Le DSML se doit donc de fournir la notion de type de donnée natif à la plate-forme d'exécution (DataType, figure 9). De plus, les valeurs de chacune des propriétés sont définies pour chaque instance de ressource, que ce soit des instances de ressources prédéfinies dans la plate-forme d'exécution ou des instances de ressources propres à l'exécution d'une application. Dans l'extrait du DSML présenté (figure 9), les instances de ressources possèdent ainsi des propriétés (ResourceInstanceProperty) dont l'attribut value donnera la valeur (cette version du DSML se contente d'une valeur littérale exprimée dans une chaîne de caractère). Enfin, les propriétés d'une instance sont associées aux propriétés de la ressource qui type l'instance.
Figure 9. Extrait du DSML présenté : les instances de ressources L'exemple décrit en figure 10 illustre l'utilisation du DSML pour la modélisation du concept de tâche basique OSEK/VDX. La ressource BasicTask, ses services et ses propriétés sont modélisés conformément au métamodèle qui définit le langage
Étude comparative pour la modélisation de plates-formes d'exécution
13
(figure 8, figure 9 et figure 5 pour ce qui concerne les ressources concurrentes). Les types nécessaires au typage des propriétés sont définis (Integer, String) et liés aux propriétés (par une flèche en pointillé suivant la convention graphique adoptée). Dans cet exemple, le modèle de la plate-forme est présenté avec une syntaxe concrète mixte (graphique et textuelle). La forme textuelle élément::[rôle] concept représente un élément de la plate-forme conforme à un concept du métamodèle et jouant un rôle (tel qu'il est défini par une association dans la figure 5).
Figure 10. Extrait du modèle de la plate-forme OSEK/VDX fait avec le DSML 3.3.4. Résultats sur le profil UML et le DSML proposés Chacune des implantations du modèle de domaine (le profil UML et le DSML) a été appliquée pour décrire les librairies OSEK/VDX et ARINC-653. Dans le cadre du profil UML, 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éotypés par les concepts du profil UML. Parallèlement, ces mêmes librairies ont été décrites directement avec le DSML. Le profil UML et le DSML ont ainsi permis de décrire 70% des ressources offertes par la plate-forme OSEK/VDX et 80% de celles offertes par la plate-forme ARINC-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 actuellement 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 nous 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 à poursuivre. Cet enrichissement peut se faire en s'appuyant sur différents modèles de domaine (ou leurs implantations dans un profil ou un DSML), chacun étant, par exemple, dédié à une considération donnée. Ainsi, dans UML MARTE, les mécanismes de temps sont gérés par un autre package. Cette pluralité permet notamment de réutiliser ces éléments dans d'autres profils ou dans d'autres DSML. La
14
Revue. Volume X – n° x/année
problématique de réutilisation de parties de metamodéles, qui rejoint celle des bonnes pratiques d'écriture des métamodéles (Delatour et al., 2006) ne sera pas plus étudiée ici. Nous avons identifié deux grands types de différences dans l'implantation du domaine de modèle entre l'approche par profil et par DSML. Le premier type de différence vient de la nature même des DSML : tous les concepts du langage doivent être définis. Par exemple, dans l'exemple présenté précédemment (figure 9), la modélisation explicite des types natifs de la plate-forme d'exécution est requise pour typer les propriétés des ressources. En comparaison, l'approche par profil UML bénéficie de la totalité du langage UML. Ainsi, dans le profil UML proposé, les éléments typés sont modélisés via le concept natif d'UML TypedElement. Les propriétés des ressources peuvent donc être typées avec des types natifs du langage (en plus des types propres à la plate-forme d'exécution). Cette différence est à nuancer, il serait par exemple possible de réutiliser la définition de ces types natifs présents dans un autre DSML. Le second type de différence est plus en rapport avec le mécanisme d'extension par stéréotypage d'UML. Ce mécanisme permet en effet d'identifier un élément en lui appliquant 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 DSML repose par contre sur une relation de conformité implantée actuellement, dans les outils tel qu'EMF, par la relation d'instanciation Java. La relation de conformité est alors simple. La modélisation d'une partition ARINC-653 permet d'illustrer cette différence. Une partition ARINC-653 est une unité de ségrégation spatiale (mémoire) et temporelle (processeur). Dans le respect du modèle de domaine initial, la sémantique d'une partition peut être identifiée via deux stéréotypes du profil UML. L'un pour l'aspect temporel (tel que SwSchedulableResource), l'autre pour l'aspect spatial (tel que MemoryPartition qui décrit une partition mémoire). Parallèlement, la modélisation d'une partition ARINC653 avec le DSML ne peut se conformer à l'équivalant de ces stéréotypes dans le DSML. Cette modélisation nécessite donc l'introduction dans le DSML d'un concept mixte de partition mémoire ordonnaçable. Ces différences nous ont permis de constater que la traduction du modèle de domaine dans un profil ou dans un DSML n'étaient pas facilement automatisables et ne faisaient pas forcément appel aux mêmes règles. 4. Principe d'utilisation des descriptions de plates-formes d'exécution L'une des utilisations prévues d'une description de plate-forme d'exécution est l'automatisation du déploiement d'une application sur une telle plate-forme. L'automatisation de ce déploiement avec des transformations de modèles s'appuyant sur le profil UML (et donc des descriptions explicites de plates-formes d'exécution)
Étude comparative pour la modélisation de plates-formes d'exécution
15
a fait l'objet d'un précédent article (Thomas et al., 2007). Nous nous focalisons donc dans cette partie sur l'approche de modélisation DSML. Nous y présentons les principes de déploiement d'une application sur une plate-forme d'exécution décrite implicitement ou explicitement. 4.1. Deux approches de description impliquent deux approches d'utilisation A l'image des approches de description d'une plate-forme d'exécution (implicite ou explicite), deux grandes familles d'approches se distinguent pour la mise en œuvre (ou déploiement) d'une application sur une plate-forme d'exécution (figure 11). La première approche s'appuie 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étamodèle. La seconde approche s'appuie sur une description explicite de la plate-forme, conformément à un métamodèle de plate-forme d'exécution. Le modèle d'une application peut alors être transformé, ou tissé, avec le modèle de la plate-forme sur laquelle l'application doit s'exécuter.
Figure 11. Deux approches de déploiement d'une application sur une plate-forme Nous proposons d'illustrer ces deux approches en nous appuyant sur les descriptions de la plate-forme OSEK/VDX de la partie précédente. Pour chacune des approches, nous détaillons le principe de déploiement d'une application et donnons un exemple de transformation. 4.2. Utilisation d'une description implicite de plate-forme d'exécution La figure 12 illustre un extrait simplifié de déploiement d'une application de robotique sur une plate-forme d'exécution OSEK/VDX. L'application de robotique
16
Revue. Volume X – n° x/année
est modélisée conformément à un métamodèle de contrôleur de robot (MMRobotController). Un contrôleur de robot se compose de contrôleurs de mouvements (MotionController) qui possèdent chacun une fonction de contrôle de trajectoire (TrajectoryControl). Dans l'exemple, l'application de contrôleur de robot modélisée se réduit à un seul contrôleur de mouvement (mc1) dont la fonction de contrôle de trajectoire est nommée tc1. Le modèle de l'application est alors transformé en un modèle conforme à un métamodèle décrivant implicitement la plate-forme OSEK/VDX. L'application résultante se compose d'une tâche basique de priorité 10. Cette tâche est identifiée par le nom du contrôleur de mouvement à qui elle offre un contexte d'exécution (mc1). Son point d'entrée correspond à la fonction de contrôle de trajectoire du contrôleur de mouvement (tc1) .
Figure 12. Déploiement utilisant un métamodèle de la plate-forme OSEK/VDX Des règles de transformation établissent les correspondances entre les éléments du modèle source et les éléments du modèle cible. Le code ATL (ATLAS Transformation Language) (Jouault, 2006) extrait de la transformation RC2OSEK (figure 13) décrit certaines correspondances appliquées dans l'exemple précédent. La règle MotionController_to_BasicTask stipule que toute instance de contrôleur de mouvement (MotionController) est transformée en une instance de tâche basique dont le point d'entrée correspond à la fonction de contrôle de trajectoire du contrôleur (référencée par son nom (tc.name, cf. TrajectoryControl, figure 10)). La valeur de priorité de la tâche est renvoyée par la fonction getPriority(). Nous ne détaillerons pas les implantations possibles de cette fonction qui peut, par exemple, déduire la priorité d'une tâche par calcul (à partir de données disponibles dans le modèle source) ou retourner une valeur transmise comme paramètre à la
Étude comparative pour la modélisation de plates-formes d'exécution
17
transformation (valeur issue d'un outil externe d'analyse d'ordonnancement, par exemple).
Figure 13. Exemple de règle de transformation (en ATL) Cette 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 (Kukkala et al., 2005) (Taha et al., 2007) (Delatour et al., 2005). Ce type de métamodèle s'apparente à une description de plate-forme abstraite dont l'intérêt réside dans la capacité à cibler de multiples plates-formes concrètes susceptibles d'exécuter une application. La figure 14 illustre l'introduction, dans le processus de transformation, d'un métamodèle d'une plate-forme abstraite jouant le rôle de pivot (Delatour et al., 2005). Dans cet exemple, le métamodèle pivot (ou langage pivot) fournit le concept de contexte d'exécution (Task) qu'offrent les systèmes d'exploitation multitâches utilisés dans l'industrie. Le déploiement de l'application s'effectue alors en deux temps. Une première transformation (T1) spécifie l'application avec les technologies qui permettent son exécution. Une deuxième transformation (par exemple T2 ou T2') déploie ensuite l'application sur une plate-forme concrète qui implémente les technologies nécessaires à son exécution. Dans l'exemple, les plates-formes concrètes envisagées sont OSEK/VDX ou ARINC-653 (ARINC, 2003). L'avantage de cette approche est de permettre la réutilisation des transformations. En effet, pour un même métamodèle source, la transformation de la première étape est utilisable pour toute plate-forme concrète cible envisagée. De plus, une transformation de la seconde étape développée pour les besoins d'un projet pourra être réutilisée dans d'autres projets, sans aucune dépendance avec les métamodèles sources des applications.
18
Revue. Volume X – n° x/année
Figure 14. Introduction d'un métamodèle pivot de plate-forme d'exécution Un premier ensemble de règles de transformation établit les correspondances entre les éléments du modèle de l'application et les éléments du modèle pivot. Le code ATL extrait de la transformation T1 (figure 15, transformation T1) décrit par exemple certaines correspondances appliquées dans l'exemple précédent. Le déploiement sur les plates-formes cibles s'appuie ensuite, dans une seconde étape, sur des règles de transformation qui établissent les correspondances entre les concepts du pivot et ceux des plates-formes envisagées. Le code ATL extrait de la transformation T2 (figure 15, transformation T2) décrit par exemple les correspondances appliquées dans l'exemple précédent pour ce qui concerne la plateforme OSEK/VDX.
Figure 15. Exemples de règles de transformation (en ATL)
Étude comparative pour la modélisation de plates-formes d'exécution
19
4.3. Utilisation d'une description explicite de plate-forme d'exécution La figure 16 reprend l'exemple introduit dans la partie précédente d'application de robotique déployée sur une plate-forme OSEK/VDX. La plate-forme d'exécution OSEK/VDX est ici explicitement modélisée avec le DSML (le modèle de la plateforme correspond à celui de la figure 10). Les modèles de l'application (PIM) et de la plate-forme (PDM) sont ensuite transformés en un modèle d'applicatif spécifique à la plate-forme OSEK/VDX (PSM). Dans cet exemple, ce modèle d'applicatif est conforme au métamodèle qui définit le DSML. L'applicatif résultant correspond à la plate-forme d'exécution ciblée dont certaines ressources sont instanciées en vue d'exécuter l'application. Une tâche basique de priorité 10 (nommée mc1) est, par exemple, instanciée pour offrir un contexte d'exécution sur la plate-forme. Le point d'entrée de cette tâche correspond à la routine de contrôle de trajectoire (tc1) de l'instance de contrôleur de mouvement mc1 (du modèle de l'application).
Figure 16. Déploiement d'une application sur une plate-forme d'exécution La transformation de déploiement établit la correspondance entre les éléments des modèles sources (PIM et PDM) et les éléments du modèle cible (PSM). Pour cela, deux ensembles de règles de transformation se distinguent. Le premier reproduit à l'identique le modèle de la plate-forme d'exécution dans le modèle cible (ce que spécifie R1 dans la figure 17). Le second définit les correspondances entre les éléments du modèle de l'application et des instances de ressources de la plateforme d'exécution. La règle R2 de la figure 17 stipule par exemple que tout élément
20
Revue. Volume X – n° x/année
conforme à un contrôleur de mouvement (MotionController) est transformé en un élément conforme à une instance de ressource ordonnançable. Au sein des règles de transformation, les instances de ressources sont associées aux ressources de la plate-forme qui les typent. Dans l'exemple de la figure 16, l'instance de tâche basique mc1 est ainsi associée à la ressource BasicTask (par une flèche en pointillé estampillées type). De même, les valeurs de propriétés affectées dans une instance de ressource sont associées aux propriétés de la ressource qui type l'instance. La valeur 10 de l'instance de tâche basique mc1 (figure 16) est ainsi associée à la propriété priority de la ressource BasicTask (par une flèche en pointillé suivant la convention graphique adoptée).
Figure 17. Transformation de déploiement (en ATL) Pour des raisons didactiques, la transformation de l'exemple (figure 17) ne comporte pas tout le code ATL. Certaines parties ont été volontairement omises. Cette transformation est plus générique que celle déjà présentée. Elle s'appuie, d'une part, uniquement sur les concepts du métamodèle de plate-forme d'exécution. Aucun concept propre à une plate-forme donnée n'intervient donc dans celle-ci. Elle implante, 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, cette transformation est par
Étude comparative pour la modélisation de plates-formes d'exécution
21
conséquent indépendante des plates-formes cibles. La considération de ces platesformes se résume à leurs modèles passés en entrée de la transformation. La généricité de la transformations est tout de même limitée. La conversion des types de donnée des modèles sources reste dépendante des plates-formes cibles. Dans l'exemple de la figure 15, la valeur de priorité est affectée en fonction de la plate-forme cible. 5. Évaluation 5.1. Protocole d'évaluation Suivant les principes d'utilisation des descriptions de plate-forme d'exécution que nous venons de décrire, le profil UML et le DSML introduits dans la partie 3 ont fait l'objet d'expérimentations pour le déploiement d'applications plus élaborées. Ces expérimentations s'inscrivent dans le cadre d'une étude sur la génération de code conforme à des standards du domaine de l'embarqué et du temps réel (tels que OSEK/VDX ou ARINC-653), à partir de descriptions UML, AADL (SAE, 2004) ou de DSML « maison » d'applications de robotique. Les expérimentations UML ont été menées avec l'éditeur Papyrus auquel le profil UML/MARTE a été intégré. Le DSML proposé a été développé avec des outils AMMA (Atlas Model Management Architecture), KM3 (Kernel Meta Meta Model) pour la syntaxe abstraite et TCS (Textual Concret Syntax) pour une syntaxe textuelle concrète. L'atelier TOPCASED (The Open-Source Toolkit for Critical Systems) a été mis à contribution pour la génération de syntaxes graphiques et l'intégration des différents outils dans un atelier commun. Les transformations de toutes les expérimentations ont été développées en ATL. Elles se composent, en moyenne, de centaines de règles. Les travaux concernant l'approche UML ont déjà fait l'objet d'un précédent article (Thomas et al., 2007). Nous avions montré qu'une description explicite de plates-formes d'exécution permettait d'utiliser un algorithme générique de transformation automatisant une partie du portage des applications d'une plate-forme à une autre. Pour corroborer (ou non) ces résultats, les expérimentations de déploiements d'applications décrites en AADL ou avec des DSML « maison » ont été menées dans un contexte DSML, suivant les trois approches présentées dans la partie 4. Nous proposons, dans cette partie, un retour sur l'évaluation de chacune de ces approches en nous appuyant sur les métamodèles et les transformations de modèles développés lors de ces expérimentations. Pour cette évaluation, notre attention s'est portée sur cinq critères : 1) les connaissances requises pour le développement des métamodèles et des transformations, 2) leurs temps de développement, 3) leurs tailles, 4) leurs maintenances et 5) leurs réutilisations possibles.
22
Revue. Volume X – n° x/année
5.2. Résultats Le tableau 1 illustre l'évaluation de chacune des approches. Description implicite sans pivot
Description explicite
avec pivot
T
MMc
T1
T2
Connaissance
c.
c.
d.
c.
d.
Temps dével.
+
+
+
++
Taille
+
+
+
Maintenance
+
+
Réutilisation + + T : transformation ; T1 : transformation de la première étape ; T2 : transformation de la seconde étape ; MMc : métamodèle décrivant une cible ; MMp :métamodèle décrivant un pivot ; MMpl : métamodèle de plateforme ; Mc :modèle d'une plateforme cible ; Connaissance : c. (cible), d. (domaine) ;
MMp MMc
T
MMpl
Mc
c.
d.
d.
c.
+
+
++
++
+
+
+
+
++
+
+
+
+
++
+ ++ + ++ ++ + Temps de développement : (~mois), + (~semaines), ++(~jours) ; Taille des transformations (en lignes) : (~104), + (~103), ++ (~102) ; Taille des MM (en métaclasses) : + (~50) ; Maintenance, Réutilisation : (mauvaise), ++ (très bonne) ;
Tableau 1. Synthèse des différentes approches expérimentées. 5.2.1. Description implicite d'une plate-forme d'exécution L'utilisation de descriptions implicites de plates-formes d'exécution, sans pivot intermédiaire, s'est avérée l'approche la plus simple et la plus rapide à mettre en œuvre. Seuls les concepts de la plate-forme cible ont été pris en compte. Étant familier de l'IDM et des techniques de transformation de modèle, il nous a fallut quelques semaines pour concevoir chaque métamodèle et chaque transformation. A titre d'information, les métamodèles développés se composent en moyenne de plusieurs dizaines de métaclasses et les transformations de plusieurs milliers de lignes. Cette approche implique néanmoins que les transformations soient figées autour de la plate-forme cible. Leurs mises en œuvre, leurs maintenances et leurs optimisations sont alors réservées à des experts à la fois de l'IDM, du domaine applicatif, du domaine métier (ici le temps réel embarqué) et des plates-formes d'exécution envisagées. De ce fait, la maintenance est rendue particulièrement difficile par l'enchevêtrement des connaissances de ces différents métiers dans la transformation.
Étude comparative pour la modélisation de plates-formes d'exécution
23
Enfin, toute considération d'une plate-forme d'exécution alternative a nécessité le développement complet d'une nouvelle transformation. Il n'y a pas eu ou très peu de réutilisations possibles des transformations déjà développées. La réutilisation s'est essentiellement limitée à prendre exemple sur ce qui avait été fait dans de précédentes transformations. Cette approche semble donc convenir pour le déploiement d'applications de petite taille, dans le contexte d'une plate-forme d'exécution précise. 5.2.2. Description implicite d'une plate-forme d'exécution jouant le rôle de pivot L'introduction d'une plate-forme pivot (abstraite) nous a permis de scinder le processus de déploiement en deux étapes de transformation. Outre la facilité de réutilisation promise par cette approche, les transformations se sont révélées plus faciles à maintenir que celles de l'approche précédente. En effet, si les concepts du domaine métier interviennent dans toutes les transformations, aucune compétence sur les plates-formes d'exécution 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 transformations de chacune des étapes sont ainsi utilisées (et maintenues) indépendamment des plates-formes concrètes envisageables 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, et la facilité de maintenance qui en résulte, sont dues à 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 platesformes 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émentaire 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. Finalement, cette approche nous a permis de déployer plusieurs applications sur différentes plates-formes d'exécution, sans avoir à ré-écrire les milliers de lignes nécessaires au déploiement de l'approche précédente. Le travail de conception du pivot et des transformations vers les plates-formes concrètes est donc un investissement qui peut s'avérer rentable s'il est courant (ou même simplement envisagé) d'avoir à déployer une ou plusieurs applications conformes à un même métamodèle sur différentes plates-formes d'exécution.
24
Revue. Volume X – n° x/année
5.2.3. Description explicite d'une plate-forme d'exécution L'utilisation d'un métamodèle de plate-forme d'exécution a également favorisé la considération de plates-formes alternatives. En effet, chaque déploiement a été mis en œuvre via une transformation en grande partie générique prenant en entrée le modèle de la plate-forme cible, en plus du modèle de l'application. L'intérêt d'une telle transformation est de se baser sur les concepts du métamodèle de plate-forme et non sur une plate-forme donnée (abstraite ou concrète). 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 à la transformation et, d'autre part, les éléments de traduction manquants à la transformation. Ces éléments se sont concrétisés par des fonctions de traduction, automatiquement intégrées à la transformation par le mécanisme de helper ATL. La transformation, ou plus précisément un noyau de celle-ci, est ainsi entièrement réutilisable. Les adaptations à une plate-forme cible se restreignent à des éléments modulaires de celle-ci. La généricité qu'apporte le mécanisme de cette transformation améliore donc, de façon conséquente, sa capacité de réutilisation. La taille de la transformation est impactée par la nécessité d'établir des correspondances à partir de deux modèles d'entrée (le modèle de l'application et le modèle d'une plate-forme d'exécution donnée). Toutefois, le temps de développement n'est pas significativement impacté. Il reste du même ordre que dans les autres approches (quelques semaines). Par rapport à l'utilisation d'un pivot, cette approche nous a également épargné le développement de transformations spécifiques aux plates-formes cibles. Outre le temps économisé, la maintenance est ici centralisée sur une seule transformation qui ne requière aucune compétence sur les plates-formes d'exécution envisagées. Elle est donc meilleur que la maintenance globale que nécessite l'approche par pivot. Enfin, comme pour l'approche par pivot, plusieurs mois ont été consacrés à l'étude des concepts qu'offrent les plates-formes d'exécution de notre domaine d'intérêt et à leurs organisations dans un métamodèle. Le développement de certains modèles de plates-formes d'exécution a été fait en parallèle pour valider les concepts retenus dans le métamodèle. D'autres modèles de plates-formes ont, par la suite, été développés en quelques jours. Ces descriptions explicites de plates-formes se sont avérées plus simples à maintenir que les descriptions implicites faites dans des métamodèles. En effet, aucune considération sur la représentation d'un applicatif censé s'exécuter sur la plate-forme ne vient, dans un modèle, parasiter la représentation des concepts de la plate-forme. Quand différentes plates-formes d'exécution cibles sont envisagées, cette approche nous semble donc la plus pertinente. Ce constat est d'autant plus renforcé quand le métamodèle de plate-forme d'exécution est déjà existant (normé ou partagé au sein d'une communauté). La grande généricité de la transformation et la rapidité de la définition de nouveaux modèles de plate-forme permettent alors une grande rapidité de développement.
Étude comparative pour la modélisation de plates-formes d'exécution
25
5.2.4. Transformation indépendante d'une plate-forme donnée : les limites. Que l'on utilise une plate-forme pivot ou un métamodèle de plate-forme, l'indépendance des transformations vis à vis des plates-formes d'exécution est à nuancer. En effet, les transformations abordées ou référencées dans cet article se limitaient à une seule ressource conforme à un concept. Elles ne géraient pas plusieurs ressources ayant la même sémantique. Par exemple, le standard OSEK/VDX discerne les tâches susceptibles d'attendre un événement (ExtendedTask) des tâches qui ne le peuvent pas (BasicTask). Ces deux catégories de tâche sont donc conformes au même concept de ressource ordonnançable (SwSchedulableResource) du modèle de domaine. Cet exemple, loin d'être isolé, implique que certaines plates-formes d'exécution offrent des alternatives de mise en œuvre des mécanismes d'exécution. Lors d'un déploiement d'application sur une plate-forme donnée, des choix doivent donc parfois guider les transformations sur les ressources à utiliser ainsi que sur leurs agencements (Brun et al., 2008). Or, à l'image de ces alternatives, ces choix dépendent des plates-formes cibles. Dès lors, telle que le propose l'approche par pivot, l'utilisation transparente de transformations dédiées aux plates-formes cibles perd de son intérêt, puisque des considérations sont à porter sur ces plates-formes. Néanmoins, l'expression de choix pour guider une transformation n'implique pas forcément que la transformation soit dépendante d'une plate-forme donnée. Seule l'exécution de la transformation peut en dépendre. Un modèle de choix dépendant de la plate-forme ciblée peut, par exemple, guider une transformation indépendante de cette plate-forme. L'ensemble des plates-formes d'exécution d'un domaine particulier peut également offrir des concepts différents pour la mise en œuvre d'un même mécanisme. Par exemple, les sémaphores associés à des variables partagées et les tableaux noirs (blackboard) fournissent des supports différents pour un échange de données entre des tâches. Or, les plates-formes d'exécution fournissent l'un, l'autre ou les deux concepts. Le choix d'un de ces concepts pour une implantation d'application relève donc à la fois des répercussions d'utilisations de ces concepts (par exemple le nombre de ressources et de services mis à contribution) et de la disponibilité de ces concepts sur une plate-forme donnée. Des choix conceptuels (indépendants d'une plate-forme donnée) peuvent ainsi s'ajouter, voir se mêler aux choix internes, propres à une plate-forme d'exécution. 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 plateforme concrète, telle que le propose l'approche par pivot) offre la perspective de pouvoir séparer les choix conceptuels des choix internes à une plate-forme. Cependant, l'existence de liens entre ces choix complexifient leurs considérations, leurs intégrations et leurs optimisations dans les transformations (un choix dans la première transformation est-il pertinent et optimal sur toutes les plates-formes envisageables ?). Au contraire, la centralisation des informations dans une seule
26
Revue. Volume X – n° x/année
transformation (telle que le propose l'approche par métamodèle de plate-forme) semble simplifier l'intégration et la possibilité d'optimiser ces choix. 6. Conclusion et perspectives Dans cet article nous avons identifié deux approches majeures de modélisation d'une plate-forme d'exécution logicielle. La première approche décrit implicitement les ressources et les services d'une plate-forme d'exécution donnée dans un métamodèle. La seconde approche décrit explicitement ces mêmes ressources et services dans un modèle conforme à un métamodèle de plate-forme d'exécution. Chacune de ces approches a été illustrée dans une version UML et une version DSML. Pour cela, nous avons tout d'abord défini le concept de plate-forme d'exécution au sens de l'IDM. Nous nous sommes ensuite focalisés sur le domaine des systèmes embarqués temps réels car la prise en compte du support d'exécution (les noyaux temps réel) est particulièrement importante dans ce domaine et nécessite une description détaillée de leurs plates-formes d'exécution. La considération explicite de plates-formes d'exécution nous a conduit à définir un métamodèle de plate-forme d'exécution dédié à notre domaine d'intérêt (les systèmes d'exploitation temps réel embarqués). Ce métamodèle a été implanté sous la forme d'un profil UML (intégré dans le profil UML/MARTE) et d'un DSML. Ces deux implantations nous ont permis de constater que la traduction du modèle de domaine dans un profil ou dans un DSML n'étaient pas facilement automatisables et ne faisaient pas forcément appel aux mêmes règles. Dans un contexte UML, l'intérêt d'une description explicite de plate-forme d'exécution ayant fait l'objet d'une précédente étude (Thomas et al., 2007), nous avons évalué les approches identifiées dans le cadre de déploiement d'applications utilisant des DSML. Nous voulions en particulier nous assurer que les premières conclusions établies avec l'utilisation d'UML étaient également valides lors de l'utilisation d'un DSML. La comparaison des approches (description implicite, description implicite avec utilisation d'une plate-forme abstraite jouant le rôle de pivot et description explicite) s'est basée sur les temps de développement, la taille des transformations obtenues, leur maintenance et leur degré de réutilisation. Outre la confirmation de la validité du motif ressource/service pour modéliser des plates-formes d'exécution (que ce soit sous forme de profil UML ou de DSML), les principales conclusions de cette étude sont les suivantes : – L'utilisation d'une description implicite de plate-forme n'est intéressante que lorsque très peu de plates-formes cibles sont envisagées. En effet, bien que cette approche se soit avérée la plus simple et la 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 des transformations est donc très limitée. De plus, la conception, l'optimisation et la maintenance de ces
Étude comparative pour la modélisation de plates-formes d'exécution
27
transformations mettent à contribution des compétences du domaine applicatif, du domaine métier et des plates-formes d'exécution envisagées ; – Si plusieurs plates-formes cibles sont envisageables, il est plus intéressant de passer directement à une approche par description explicite. En effet, la définition d'un pivot (avec une plate-forme décrite implicitement) ou la définition d'un métamodèle de plate-forme (permettant de décrire des plates-formes explicitement) sont de la même complexité et prennent des temps de développement équivalents. Mais, l'approche par plate-forme explicite permet d'obtenir des transformations plus génériques et plus facilement adaptables à différentes plates-formes cibles. Une fois le métamodèle de plate-forme défini, l'adaptation à différentes plates-formes est très rapide. En outre, le fait de disposer d'une description explicite des plates-formes (sous forme de modèles) permet d'envisager leur comparaison dans un cadre d'utilisation particulier. Avec les plates-formes implicites, ces comparaisons sont malaisées car leurs descriptions sont mélangées dans un même métamodèle avec les informations liées au domaine applicatif ; – Ces conclusions sont vraies que l'on soit dans une démarche de développement basée UML ou DSML. Ces conclusions nous encouragent à poursuivre le travail initié avec le profil UML/MARTE et à l'étendre à une approche DSML. Se fonder sur un métamodèle de plate-forme d'exécution offre en effet 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 (destinés à l'analyse ou la génération de code par exemple). L'échange et la capitalisation des modèles sont aussi des motivations à l'unification de la communauté autour de tels métamodèles. Nous devons néanmoins limiter la portée de ces conclusions. Bien que nous n'ayons pas identifiés de points particuliers qui pourraient limiter l'application de ces concepts à d'autres domaines que l'embarqué et le temps réel, d'autres expérimentations doivent être menées sur des domaines d'étude différents. L'indépendance, et donc la généricité, des transformations vis-à-vis des platesformes d'exécution sont également à nuancer. Des choix doivent parfois guider les transformations sur les ressources à utiliser pour le déploiement d'une application. Or, ces choix peuvent dépendre des plates-formes ciblées. Par exemple, un même mécanisme de synchronisation peut être traduit de différentes manières sur une plateforme donnée. De plus, les plates-formes d'exécution d'un domaine particulier peuvent fournir des concepts différents pour la réalisation d'un même mécanisme d'exécution. L'expression et l'intégration de ces choix dans le processus de génération sont encore à l'étude actuellement. Un premier ensemble de propositions, avec une approche UML, a été fait (Thomas, 2008). Des investigations, dans un contexte DSML, sont en cours. Nous nous sommes restreints dans cet article à des modèles structurels qui se limitent à l'interface de programmation des plates-formes d'exécution. Nous n'avons abordé ni les règles d'utilisation, ni la modélisation du comportement d'une plate-
28
Revue. Volume X – n° x/année
forme d'exécution, bien que ces considérations soient indispensables au déploiement d'applications temps-réels. Ce point fera l'objet d'une étude à part entière. D'autres axes d'amélioration sont à étudier afin de faciliter la production des métamodèles, modèles et transformations associées. Concernant la production des DSML, la réutilisation de DSML existants (par exemple, par composition de sousensembles communs ou spécialisation de métamodèles abstraits) est à envisager. L'évaluation de la réutilisation des transformations s'est limitée, dans cette étude, à des changements radicaux de métamodèles sources ou de plates-formes d'exécution cibles. La réutilisation possible des transformations suite à une évolution d'un métamodèle reste, par exemple, à évaluer. De même, la traçabilité de l'exécution des transformations n'a pas été abordée dans cet article. Des modèles de trace ont été expérimentés dans un contexte UML, essentiellement à des fin de déverminage, mais d'autres fins (par exemple de vérification) sont certainement possibles. Des procédés de transformations tels que le tissage de modèle (Didonet et al, 2005) peuvent également faciliter la construction d’un modèle de correspondance lors de l'exécution des transformations. Les outils mis à contribution nous ont permis de mener les expérimentations sans aucune difficulté. Le temps passé pour les expérimentations a été plus consacré à la réflexion sur les métamodèles et sur les règles de transformation que sur leurs implantations. Nous nous sommes néanmoins restreints à un seul outil par technologie, sans évaluer la part de l'outillage dans les gains de productivité réalisés. Une étude focalisée sur l'outillage mériterait un article à part entière avec des expérimentations supplémentaires. Remerciements Ces travaux de recherches ont été financés en partie par le projet TOPCASED du pôle de compétitivité Aérospace Valley, projet supporté par le ministère des finances à travers le FUI. Nous tenons à remercier les responsables de ce projet pour leur soutien. 7. Bibliographie Airlines electronic engineering committee, Avionics Application Software Standard Interface, ARINC Specification 6531, Aeronautical radio, INC., Annapolis, Maryland, EtatsUnis, octobre 2003. Almeida J. P. A., ModelDriven Design of Distributed Applications, Thèse de doctorat; Instituut Fundamental Research Series, Enschede, Hollande, ISBN 9075176422, 2006. Atkinson C., Kühne T., « A Generalized Notion of Platforms for ModelDriven Development », ModelDriven Software Development, vol. 2, Springer Berling Heidelberg, ISBN 9783540256137, 2005, p. 119136.
Étude comparative pour la modélisation de plates-formes d'exécution
29
AUTomotive Open System ARchitecture, AUTOSAR release 3.1, http://www.autosar.org, 2008. Brun M., 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 OSEK/VDX à partir d'une description AADL, Thèse de Master, Institut de Recherche en Communications et Cybernétique de Nantes, Septembre, 2006. Brun M., Delatour J., Faucou S., Savaton G., « Retour d’expérience sur l’utilisation déclarative d’un langage de transformation pour la génération de code : de AADL vers OSEK/VDX OS », Actes des 3iemes Journées sur Ingénierie Dirigée par les Modèles IDM07, Toulouse, France, mars 2007, p. 132148. Brun M., Delatour J., Trinquet Y., « Code generation from AADL to a realtime operating system: an experimentation feedback », ICECCS '08 : Proceedings of the 13th IEEE Internal Conference on Engineering of Complex Computer Systems, IEEE Computer Society, Belfast, Northen Ireland, 2008, p. 257262. Chen R., Sgroi M., Lavagno L., Martin G., SangiovanniVincentelli A., Rabaey J., UML and PlatformBased Design, volume UML for Real : Design of Embedded RealTime Systems, chapitre 5. Kluwer Academic Publishers, May 2003. Delatour J., Thomas F., Savaton G., Faucou S., « Modèle de plateforme pour l’embarqué : première expérimentation sur les noyaux temps réel », Actes des 1eres Journées sur l'Ingénierie Dirigée par les Modèles IDM05, Paris, juillet 2005, p. 209216. Delatour J., Marvie R., Savaton G., MP2006 Workshop on MetaModel Pattern, 2èmes Journées sur l'Ingénierie Dirigée par les Modèles, Lille, juin 2006. Didonet Del Fabro M., Bézivin J., Jouault F., Breton E., Gueltas G., « AMW: a generic model weaver », Actes des 1eres Journées sur l'Ingénierie Dirigée par les Modèles IDM05, Paris, juillet 2005, p. 105114. Jouault F., Contribution à l’étude des langages de transformation de modèles, Thèse de doctorat, Université de Nantes, Nantes, France, septembre 2006. Kukkala P., Riihimâki J., Hämäläinen M., Kronlöf K., « UML 2.0 Profile for Embedded System Design », DATE’05 : Automation and Test in Europe Conference, Munich, Allemagne, mars 2005, p. 710715. Marvie R., Duchien L., BlayFornarino M., « Les platesformes d’exécution et l’IDM », L’ingénierie dirigée par les modèles, Hermes, ISBN : 2746212137, 2006, p. 7186. Metropolis Project Team, The metropolis meta model version 0.4. Rapport technique UCB/ERL M04/38, University of California, Berkeley, September 2004. Object Management Group, UML Profile for Modeling and Analysis of RealTime and Embbeded systems (MARTE) second revision submission, juin 2007 . Object Management Group, MDA guide version 1.0.1, juin 2003. Object Management Group, Response to the OMG RFP for Schedulability, Performance, and Time, juin 2001.
30
Revue. Volume X – n° x/année
Object Management Group, Unified Modeling Language (UML) : Superstructure, version 2.1.1, février 2007. OSEK/VDX Group, OSEK/VDX OS specification version 2.2.3, 2005. Pinto A., Metropolis design guidelines, Rapport technique, University of Califormia, Berkeley, novembre 2004. SangiovanniVincentelli A., Martin G., « PlatformBased Design and Software Design Methodology for Embedded Systems », IEEE Des. Test, vol. 18, n° 6, 2001, p. 2333. SangiovanniVincentelli A., Carloni L., Bernardinis F. D., Sgroi M., « Benefits and challenges for platformbased design », DAC ’04 : Proceedings of the 41st annual conference on Design automation, ACM Press, mai 2004, p. 409414. Selic B., « A Generic Framework for Modeling Resources with UML », IEEE Computer Society Press, vol. 33, n° 6, ISSN:00189162, 2000, p. 6469. Selic B., « On Software Platforms, Their Modeling with UML 2, and PlatformIndependent Design », ISORC ’05 : Proceedings of the Eighth IEEE International Symposium on ObjectOriented RealTime Distributed Computing, IEEE Computer Society, Washington, DC, EtatsUnis, 2005, p. 1521. Society of Automotive Engineer, Architecture Analysis & Design Language version 1.0, AS5506, 2004. Szemethy T., DomainSpecific Models, Model Analysis, Model Transformations. Thèse de doctorat, Université de Vanderbilt, Nashville, Tennessee, USA, May 2006. Taha S., Radermacher A., Gerard S., Dekeyzer JL. « An Open Framlework for Hardware Detailed Modeling”, SIES’07 : Proceedings of the IEEE Second International Symposium on Industrial Embedded Systems, IEEE Computer Society, Lisbon, Portugale, 2007, p. 118125. Thomas F., Delatour J., Gérard S., Brun M., Terrier F., « Contribution à la modélisation explicite des platesformes d’exécution pour l’IDM », L'Objet, HermesLavoisier, vol. 13, n°4, ISSN:12621137, 2007, p. 931. Thomas F., Gérard S., Delatour J., Terrier F., « Software RealTime Resource Modeling », Springer Science, vol. Embedded Systems Specification and Design Languages de FDL selected papers, Eungenio Villar, Barcelona, Spain, chap. 12, 2008, p. 169182. Thomas F., Delatour J., Terrier F., Gérard S., « Towards a framework for explicit platform based transformations », ISORC '08 : Proceedings of the 11th IEEE International Symposium on Objectoriented Realtime distributed Computing, Orlando, FL, Etats Unis, 2008, p. 211218. Thomas F., Contribution à la prise en compte des platesformes logicielles d'exécution dans une ingénierie générative dirigée par les modèles, Thèse de doctorat, Université d'Evry, Evry, France, novembre 2008. Trinquet Y., « Noyaux temps réel. le cas de OSEK/VDX ». Actes de l'Ecole d'été Temps Réel du GDR ARP thème STRQdS, Toulouse, France, sept. 2003, IRIT éditeur, ISBN 2 951454112, p. 227240.
Étude comparative pour la modélisation de plates-formes d'exécution
31
Matthias Brun est doctorant en Informatique à l'Institut de Recherche en Communications et Cybernétique de Nantes (IRCCyN, UMR 6597) et au Centre d'Etude et de Recherche de l'ESEO. Ses activités de recherches sont centrées sur la considération des plates-formes d'exécution logicielles au sein des processus de déploiements d'applications temps réel embarquées. Ses investigations pour la mise en œuvre de tels déploiements se situent aujourd'hui dans une ingénierie dirigée par les modèles. Elles portent plus particulièrement sur la modèlisation des plates-formes d'exécution et leur intégration dans des transformations de modèles. Jérôme Delatour est le responsable de l'équipe de recherche TRAME (TRAnsformations de Modèles pour l'Embarqué, http://trame.eseo.fr) au sein du laboratoire CER (Centre d'Etude et de Recherche) de l'école d'ingénieur ESEO (http://www.eseo.fr). Jérôme s'intéresse au développement d'applications temps réels en utilisant l'Ingénierie Dirigée par les Modèles. Dans ce contexte, il travaille actuellement à mieux définir la notion de plate-forme. Jérôme représente l'ESEO à l'OMG (Object Management Group) et participe à la normalisation du profil UML MARTE (Modeling and Analysing Real Time and Embedded systems, http://www.promarte.org/). Yvon Trinquet est professeur à l’Université de Nantes, et membre du laboratoire IRCCyN (UMR 6597) dont il dirige l’équipe « Systèmes Temps Réel ». Ses centres d’intérêt sont la mise en œuvre de systèmes temps réel, et plus particulièrement l’ordonnancement temps réel et les systèmes d’exploitation temps réel. Il a pris une part active dans le développement de Trampoline, une plate-forme s’exécution temps réel conforme au standard OSEK/VDX du domaine automobile, ainsi qu’au simulateur d’ordonnancement temps réel multiprocesseur STORM. Frédéric Thomas est diplômé de l'ESEO spécialité « systèmes embarqués et temps réel » et a obtenu la distinction de docteur en Ingénierie des Modèles à l'université d'Evry en 2008. Durant sa thèse, il a travaillé sur la modélisation des plates-formes d'exécution et sur l'automatisation des développements logiciels autour de ces platesformes. Dans ce contexte, il a contribué au profil UML-MARTE (Modeling and Analysis of Real-Time and Embedded systems). Il a rejoint la société Obeo en 2008 où il poursuit l'utilisation des technologies dirigées par les modèles pour le développement des systèmes embarqués temps réel. Sébastien Gérard est le responsable de l'équipe de recherche ACCORD au sein du laboratoire d'ingénierie dirigée par les modèles pour les systèmes embarqués (LISE) du CEA LIST, http://www-list.cea.fr/labos/fr/LLSP/LLSP_equipe.htm. Sébastien est également le chef de projet de l'initiative open-source Papyrus (modeleur de la fondation open source Eclipse supportant les langages de modélisation UML, SysML et proposant un mécanisme avancée d'adaptabilité aux spécificités métiers, http://www.eclipse.org/papyrus). Enfin, Sébastien représente le CEA à l'OMG (Object Management Group) et il est plus particulièrement responsable du groupe de travail en charge de la normalisation de MARTE (Modeling and Analysing Real Time and Embedded systems, http://www.promarte.org).
