Mécanismes de définition des sémantiques : Classification

Télécharger le fichier pdf d’un mémoire de fin d’études

L’approche MDA

L’approche MDA (Model Driven Architecture) est proposée et soutenue par l’OMG [17] pour le développement des systèmes logiciels. Cette approche fixe les technologies à utiliser pour chaque niveau de modélisation dans l’IDM. Elle repose sur un ensemble de standards de l’OMG dont le standard UML [18] pour l’élaboration de modèles et le standard MOF [19] pour la définition de méta-modèles.
Le principe fondamental du MDA est la séparation entre la logique métier et la logique d’implémentation. Cela est réalisé par la création de modèles du système séparément des plates-formes d’exécution. Cette séparation (entre le modèle du système et de la plate-forme d’exécution) automatise le processus de manipulation de modèles et conduit à la génération automatique du code de l’application.

Démarche MDA

La démarche de développement recommandée par le MDA se divise essentiellement en cinq étapes :
1. L’élaboration du modèle d’exigences CIM (Computation Independent Model), appelé aussi modèle métier ou modèle du domaine applicatif. Ce modèle aide à maitriser la complexité du système et donne une vision sur des exigences dans un environnement particulier, mais sans rentrer dans le détail de la structure du système, ni de son implémentation.
2. L’élaboration du modèle indépendant de toute plate-forme d’exécution PIM (Platform Independent Model). C’est un modèle qui ne contient que des informations fonctionnelles du système, sans détails techniques relevant de l’implémentation. À ce niveau, le formalisme utilisé pour exprimer un PIM est le langage de modélisation UML.
3. L’enrichissement du modèle PIM par raffinement successif. Dans cette étape de nature incrémentale, nous pouvons continuer à détailler le comportement du système tout en omettant les détails liés à la plateforme.
4. Choix des plates-formes d’exécution et génération des modèles correspondants PSM (Platform Specific Model). Ces modèles sont obtenus par une transformation du PIM en y ajoutant les informations techniques relatives à la plate-forme cible. Ils représentent une vue détaillée du système et sont dépendants d’une plate-forme d’exécution.
5. Les informations liées à la plate-forme d’exécution sont décrites dans un modèle de plate-forme PDM (Platfom Description Model). Ce modèle fournit les concepts techniques et les services fournis par la plate-forme cible. Notons qu’il existe plusieurs niveaux de détail du PSM. Le premier niveau est issu de la transformation du PIM et du PDM. Le niveau le plus détaillé, est un code généré dans un langage spécifique tel que Java, C++, etc.
En effet, le modèle de chaque étape contient des hypothèses sur la sémantique d’exécution du modèle du système final mais à des niveaux différents d’abstraction. Par exemple, la concurrence peut être décrite à un niveau élevé d’abstraction par des concepts de processus ou d’objet actif [20] [21] puis raffinée en un ensemble de tâches sur une plateforme d’exécution. A un haut niveau l’application est indépendante de la plateforme d’exécution mais à un niveau plus raffiné, elle est spécifique à un système multitâche ou distribué. Ces hypothèses joueront un rôle important dans la simulation du comportement du système final.

Transformation de modèles dans l’approche MDA

Le développement des applications logiciel dans l’approche MDA est centré sur la conception d’un ensemble de modèles et sur leurs transformations. Le formalisme de modélisation UML est ainsi choisi pour exprimer les différents modèles pendant que leurs transformations sont réalisées en utilisant le langage QVT(Query, View, Transformation) [22] standardisé par l’OMG. La figure 2.3 résume les transformations potentielles entre les différents types de modèles que nous avons présentés dans la section précédente.
Les transformations du type CIM vers CIM, PIM vers PIM et PSM vers PSM visent à compléter, spécialiser ou filtrer le modèle. La transformation CIM vers PIM permet de passer de la vue exigence à une vue fonctionnelle préliminaire indépendante de tout détail d’implémentation. La transformation du PIM vers PSM permet de spécialiser le PIM selon la plate-forme d’exécution ciblée en se basant sur les informations fournies par le PDM. La transformation du PSM vers du code est la phase de génération du code, elle permet après compilation d’obtenir l’exécutable de l’application.

La Sémantique des langages de modélisation

Un langage de modélisation est nécessaire pour l’élaboration et la production des modèles. Dans la sphère de l’ingénierie dirigée par les modèles, ce langage pourrait être un langage à vocation générale ou spécifique. Un langage générique peut être utilisé pour décrire une grande variété de systèmes. Tandis qu’un langage spécifique (DSML pour Domain Specific Modeling langage) contient des concepts distinctifs permettant de décrire des systèmes ciblés. La figure 2.4 récapitule les étapes de création d’un langage de modélisation. Dans les deux cas, la création d’un langage de modélisation consiste à :
1. Définir une syntaxe abstraite du langage.
2. Définir une syntaxe concrète du langage.
3. Définir une sémantique du langage.

La syntaxe abstraite

La syntaxe abstraite d’un langage de modélisation exprime structurellement l’ensemble de ses concepts ainsi que les relations entre ces concepts (présentée par le tableau 2.1). Elle est définie en utilisant un langage de méta-modélisation tel que MetaGME [23] et MOF de l’OMG [19]. Ces langages offrent les concepts et les relations élémentaires permettant la description de la syntaxe abstraite sous forme de méta-modèle. Cependant, les facilités graphiques qu’offrent ces langages manquent d’expressivité pour capturer toutes les propriétés du langage de modélisation, contrairement aux langages de programmation traditionnels où les grammaires hors-contexte [24] sont suffisantes pour exprimer les constructions permises par un langage. Par exemple, supposons que nous voulions définir un langage de modélisation pour les graphes orientés acycliques. En plus des notions de nœuds et d’arêtes, une contrainte supplémentaire s’impose qui interdit les cycles dans un graphe. Cette contrainte n’est pas exprimable en langage graphique comme MOF sans l’utilisation d’un langage de contraintes supplémentaires tel que OCL [25]. Dans le contexte des langages de modélisation, ces contraintes sont spécifiées au niveau du méta-modèle sous forme de règles de bonne formation qui devront être respectées par les modèles conformes à ce méta-modèle.

La syntaxe concrète

La syntaxe concrète fournit aux utilisateurs les notations nécessaires (présentées par le tableau 2.2) pour exprimer un modèle. Les langages de programmation traditionnels ont généralement une notation textuelle, tandis que les langages de modélisation peuvent être textuels ou visuels. La syntaxe concrète permet de manipuler les concepts de la syntaxe abstraite et créer des modèles qui lui sont conformes. Elle est définie en annotant chaque concept de la syntaxe abstraite par une décoration qui sera manipulée par un utilisateur potentiel du langage. Il existe plusieurs outils qui permettent de définir des syntaxes concrètes, nous citons principalement GMF [26] pour des syntaxes graphiques et TCS [27] pour des syntaxes textuelles.

La sémantique

La sémantique d’un langage de modélisation décrit précisément et sans ambigüité la signification des concepts de ce langage. On dit qu’une sémantique est formelle lorsqu’elle est exprimée dans un formalisme mathématique. Elle permet de donner d’une manière claire et rigoureuse le sens d’un modèle. Une sémantique est alors caractérisée par [28] :
Un domaine sémantique dont les concepts sont compréhensibles et bien définis. Un mapping entre les éléments de la syntaxe abstraite et les éléments du domaine sémantique.
Prenons par exemple le langage de programmation C. La sémantique d’un programme est donnée par l’exécution d’un ensemble de mots-clés qui revient à exécuter un jeu d’instructions d’une machine cible. Le domaine sémantique dans ce cas est constitué d’un jeu d’instructions de la machine cible et le mapping sémantique est réalisé par un compilateur qui traduit des programmes écrits en C dans le jeu d’instructions approprié.
La sémantique d’un langage de modélisation peut être divisée en deux types : la sémantique statique ou structurelle et la sémantique dynamique ou comportementale. La sémantique statique traite des propriétés à vérifier avant l’exécution et concerne la signification du modèle en termes de structure et de règles de bonne formation. Quant à la sémantique dynamique, elle permet de donner une description du comportement du modèle pendant l’exécution. Traditionnellement, la sémantique de nombreux langages de modélisation est décrite de manière informelle, en langage naturel, nous citons notamment la norme UML2 [18]. Une sémantique informelle pose en fait plusieurs problèmes, nous identifions :
L’ambigüité et les mauvaises interprétations des concepts du langage de modélisation par les utilisateurs. Les normes des langages exigent une sémantique précise. Une norme d’un langage mal définie sémantiquement est ouverte à l’incompréhension et aux mauvaises utilisations par les développeurs d’outils tout en limitant significativement l’interopérabilité des modèles.
Une sémantique informelle ne peut être interprétée par les outils, ce qui incite les développeurs d’outils à implémenter leur propre compréhension de la sémantique. Le même langage pourrait être implémenté différemment. Ainsi, deux outils différents peuvent offrir des implémentations contradictoires de la même sémantique.
En effet, associer une sémantique précise au langage apporte une solution aux problèmes précédemment cités. De plus, elle est essentielle pour centraliser le sens des modèles entre les différents acteurs du processus de développement. Cela est particulièrement important dans le cas des modèles destinés aux systèmes temps réel et embarqués. Ainsi, la sémantique joue un rôle capital pour déterminer les capacités essentielles d’un langage dans une démarche de développement IDM tel que la capacité d’exécution, de transformation ou de vérification.
En résumé, ce chapitre a présenté le contexte général de ces travaux de thèse qui s’inscrivent dans le cadre du développement des systèmes temps réel embarqués. Dans la suite nous nous intéressons à la modélisation de la partie applicative de ces systèmes dans une architecture monoprocesseur. Nous focalisons principalement notre étude sur les aspects de concurrence entre tâches et le respect des contraintes temporelles. Dans le chapitre suivant nous allons présenter un état de l’art portant sur la modélisation de la partie applicative en mettant en évidence les sémantiques d’exécution des langages de modélisation.

Langage de modélisation : UML

L’approche MDA préconise l’utilisation du langage de modélisation UML (Unified Modeling Language) [18] pour la construction de modèles tout au long du cycle de développement du logiciel. C’est un langage de modélisation graphique à caractère générique, utilisé pour spécifier, visualiser et documenter les artefacts d’un système logiciel.
Le langage UML est défini sous forme d’un méta-modèle, organisé en plusieurs paquetages. Chaque paquetage introduit des concepts que nous pouvons exprimer par des notations graphiques à travers des diagrammes. Ces diagrammes peuvent être regroupés en deux classes principales : celle relative à la modélisation structurelle et celle relative à la description du comportement. La figure 2.5 décrit l’organisation de ces différents diagrammes. Nous donnons ci-dessous une courte description de certains diagrammes.
Le diagramme de classe : ce diagramme couvre un aspect fondamental dans la modélisation, il permet d’exprimer d’une manière précise la structure statique d’un système, en termes de classes et de relations entre ces classes. Une classe correspond à la description d’un concept du domaine d’application considéré.
Le diagramme d’objet : est destiné à représenter les instances des classes définies dans le diagramme de classe et les liens qui les connectent. Ce diagramme fige ainsi une image du système modélisé à un instant donné.
Le diagramme de composant : manipule la notion de composant qui permet de représenter une abstraction d’un ensemble de classes réalisant différentes fonctionnalités et qui communiquent par des interfaces avec leur environnement. Le diagramme de composant permet d’expliciter les unités logicielles qui forment le socle du système.
Le diagramme de structure composite : ce diagramme manipule la notion de port et de connecteur. Il permet d’exprimer la composition entre les classes et leurs éléments internes.
Le diagramme de cas d’utilisation : capture les fonctionnalités que nous offre un système. Il manipule les concepts d’acteur et de cas d’utilisation. Un acteur est une entité extérieure du système qui peut initier l’un des cas d’utilisation. Ce diagramme décrit, sous forme d’actions et de réaction le comportement d’un système du point de vue utilisateur. Souvent, il est utilisé dans les premières phases de spécification.
Le diagramme d’activité : permet de se focaliser sur la partie dynamique d’un système. Il permet de définir le comportement d’une opération ou le déroulement d’un cas d’utilisation, par l’enchaînement et la coordination d’un ensemble d’actions. Une action est une étape de calcul élémentaire. L’enchainement d’un ensemble d’actions peut être représenté par des flots de contrôle ou des flots de données ou bien des deux.
Le diagramme de machine à états : permet de décrire les comportements discrets d’un système via des automates d’états finis. Il s’agit de graphes d’états, reliés par des arcs orientés qui décrivent les transitions. Ce diagramme permet de décrire les changements d’états d’un objet ou d’un composant, en réponse aux interactions avec d’autres objets/composants ou avec des acteurs.
Le diagramme de séquence : illustre la séquence d’interactions entre objets selon l’ordre chronologique des envois de messages entre eux.

Extension du langage UML

L’objectif d’UML en proposant autant de diagrammes et concepts est de fournir un langage de modélisation généraliste qui couvre une grande partie du domaine du logiciel. Cependant, il arrive parfois que ce langage ne soit pas adapté à capturer certaines propriétés particulières à un domaine spécifique. C’est le cas par exemple des systèmes temps réel, pour lesquelles il est nécessaire de spécifier des propriétés temporelles (échéance, période, etc.), ce qui n’est pas supporté par la notation standard d’UML. Pour remédier à ce problème, il existe deux solutions pour étendre UML.
La première méthode d’extension est nommée extension lourde (Heavyweight extension). Elle est fondée sur la manipulation d’une copie du méta-modèle d’UML en lecture et en écriture. En d’autres termes, ce mécanisme permet d’importer des éléments du méta-modèle d’UML en utilisant l’opération merge [29] et d’ajouter, supprimer ou modifier certaines caractéristiques. Toutes les modifications sont alors effectuées directement sur une copie des méta-classes concernées.
La deuxième méthode, est dite extension légère (Lightweight extension), dans ce cas, le méta-modèle d’UML n’est manipulé qu’en lecture et les éléments importés sont utilisés sans modification de leurs caractéristiques. Cette technique est réalisée grâce au concept de profil, normalisé par l’OMG [18]. Un profil permet alors d’étendre ou de restreindre le méta-modèle d’UML afin de l’adapter à un domaine spécifique. Il offre les moyens pour réaliser les modifications suivantes sur le méta-modèle d’UML :
étendre les méta-classes du méta-modèle UML via des stéréotypes. ajouter des propriétés aux stéréotypes.
spécifier de nouvelles règles de bonne formation concernant les stéréotypes sous forme de contraintes OCL.
La figure 2.6 montre un fragment du méta-modèle UML correspondant aux éléments de profil. Ce dernier est constitué fondamentalement de stéréotypes, de valeurs étiquetées et de contraintes.
Le stéréotype est le mécanisme de base pour étendre UML. Il étend une ou plusieurs méta-classes existantes du méta-modèle UML afin de permettre leur utilisation dans un domaine spécifique. Quant aux valeurs étiquetées, elles sont caractérisées par un nom et un type et sont considérées comme les propriétés des stéréotypes. En effet, un stéréotype est défini au niveau M2 et sera appliqué à un élément du modèle (niveau M1) et les valeurs de ses propriétés représentent les valeurs étiquetées. En plus des stéréotypes et des valeurs étiquetées, des contraintes peuvent être spécifiées afin de contraindre la sémantique des éléments du méta-modèle. Les contraintes peuvent être non formelles et renseignées dans la documentation du profil ou bien formelles et décrites en langage de contraintes OCL(Object Constraint Language) [25],standardisé par l’OMG. L’OMG a standardisé plusieurs profils couvrant différents domaines, nous en mentionnons quelques-uns :
1. Le profil CORBA CCM [30], pour la modélisation d’applications à base de composants.
2. Le profil SoC (System on a Chip) [31], offre des facilités pour la modélisation des systèmes sur puce.
3. Le profil SPT (Schedulability, Performance and Time) [32], pour la modélisation d’applications temps réel .
4. Le profil UTP (UML Testing) [33] Profile qui permet la spécification des tests d’application.
L’OMG a standardisé plusieurs profils pour la modélisation des applications temps-réel embarquées. On s’intéressera particulièrement au profil MARTE (Modeling and Analysis of Real-time and Embedded Systems)[34] que nous allons utiliser le long cette étude. Ce profil définit les fondements pour la description et l’analyse des systèmes temps réel et embarqués (STRE). MARTE se concentre principalement sur l’analyse d’ordonnancabilité et de performance. Il offre aussi les concepts qui permettent de modéliser les caractéristiques matérielles des STRE. La partie modélisation du profil fournit le support nécessaire partant de la spécification à la conception détaillée des caractéristiques temps réel et embarquées des systèmes. La partie analyse fournit des mécanismes permettant d’annoter les modèles avec les informations requises pour effectuer des analyses spécifiques. Le profil MARTE remplace le profil SPT.

Développement des systèmes temps réel embarqués (STRE)

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

Les systèmes informatiques temps réel et embarqués sont présents de plus en plus dans plusieurs domaines d’application. Parmi ceux-ci nous citons par exemple : le domaine du transport (automobile, ferroviaire, aéronautique), le domaine militaire (missiles, radars), le domaine des télécommunications (téléphonie, serveurs, box), le domaine de l’électroménager (téléviseurs, machines à laver), le domaine du multimédia (consoles de jeux, navigateurs GPS), etc.
Un système est qualifié comme temps réel [35] si son bon fonctionnement est caractérisé non seulement par la correction des valeurs qu’il produit, mais aussi par le respect de contraintes temporelles sur cette production de valeurs. Un système temps réel interagit avec son environnement, généralement caractérisé par un procédé physique, qui lui-même évolue avec le temps. Le temps de réponse désiré d’un tel système est alors fixé par l’environnement avec lequel il interagit. De plus, ce type de système réagit en permanence aux variations du procédé (l’environnement) et agit en conséquence pour obtenir le comportement souhaité, cette caractéristique définit la notion de réactivité. La définition suivante explique le fonctionnement d’un système temps réel :
Définition 4 Un système réactif est un système qui réagit continuellement avec son environnement
à un rythme imposé par cet environnement. Il reçoit, par l’intermédiaire de capteurs, des entrées provenant de l’environnement, appelées stimuli. Il réagit à tous ces stimuli en effectuant un certain nombre d’opérations et il produit, grâce à des actionneurs, des sorties utilisables par l’environnement, appelées réactions ou commandes.
La figure 2.7 illustre la définition précédente. Un système temps réel est alors constitué de deux sous systèmes distincts : le procédé à contrôler et le système de contrôle. Le procédé contient des capteurs et des actionneurs. Les capteurs vont récupérer des informations du procédé et les transmettre au système de contrôle. Quant aux actionneurs, ils vont commander le procédé afin de réaliser une tâche bien définie. Le système de contrôle est composé d’un calculateur et d’interfaces d’entrées/sorties qui servent à communiquer avec le procédé. Le calculateur va exécuter un algorithme de contrôle en respectant des propriétés temporelles et envoyer des ordres de commande aux actionneurs via l’interface de communication. Il est important de noter qu’un système temps réel est dit embarqué lorsqu’il est enfoui à l’intérieur de l’environnement avec lequel il interagit, comme un calculateur dans un avion ou une voiture.

Table des matières

1 Introduction 
2 Positionnement 
1 Ingénierie dirigée par les modèles
1.1 Les principes de l’IDM
1.2 L’approche MDA
1.2.1 Démarche MDA
1.2.2 Transformation de modèles dans l’approche MDA
1.3 La Sémantique des langages de modélisation
1.3.1 La syntaxe abstraite
1.3.2 La syntaxe concrète
1.3.3 La sémantique
1.4 Langage de modélisation : UML
1.5 Extension du langage UML
2 Développement des systèmes temps réel embarqués (STRE)
2.1 Introduction aux systèmes temps réel embarqués
2.2 Classification
2.3 Architecture
2.3.1 La couche matérielle
2.3.2 La couche logicielle
2.4 Processus de développement
2.5 Conclusion
2.6 Ingénierie dirigée par les modèles pour les systèmes temps réel embarqués
3 Etat de l’art 
1 Mécanismes de définition des sémantiques : Classification
1.1 Les sémantiques axiomatiques
12 Table des matières
1.2 Les sémantiques dénotationnelles
1.3 Les sémantiques opérationnelles
1.4 Comparaison entre les différents types de sémantiques
2 Approches et outils pour la définition de sémantiques et l’exécution de modèles
2.1 Critères de comparaison
2.2 Kermeta
2.2.1 Évaluation
2.3 TopCased
2.3.1 Évaluation
2.4 Semantic Units
2.4.1 Évaluation
2.5 MagicDraw/Cameo
2.5.1 Évaluation
2.6 iUML
2.6.1 Évaluation
2.7 Ptolemy
2.7.1 Évaluation
2.8 ModHel’X
2.8.1 Évaluation
2.9 Synthèse
3 fUML
3.1 Introduction
3.2 La syntaxe : Concepts de modélisation
3.3 La sémantique : Le modèle d’exécution de fUML
3.3.1 Points de variation sémantique
3.4 Le moteur d’exécution et son environnement
3.5 L’exécution des activités
3.6 Analyse de fUML
3.6.1 Les exécutions concurrentes
3.6.2 Le temps
3.6.3 La prise en charge des Profils
3.7 Évaluation
4 Contribution 
1 L’ordonnancement dans fUML
1.1 Conclusion
2 Le temps dans fUML
2.1 Conclusion
3 Les profils dans fUML
3.1 L’extension syntaxique
3.2 L’extension sémantique
4 Application et validation : Sémantique d’exécution d’un sous profil de MARTE pour l’analyse d’ordonnancement
4.1 Introduction à la méthodologie de modélisation Optimum
4.1.1 Le modèle de charge de travail (WorkLoad Model)
4.1.2 Le modèle d’analyse d’ordonnançabilité
4.2 Cas d’étude
4.3 La sémantique d’exécution d’Optimum
5 Conclusion 
1 Résumé
2 Perspectives

Télécharger le rapport complet