Mise en oeuvre d’un moteur d’exécution de modèles UML

Les principes de l’IDM

   L’ingénierie dirigée par les modèles [3] est un paradigme de développement logiciel quipréconise une utilisation intensive et systématique des modèles. Les modèles sont placés au cœur du processus de développement afin de faire face à la complexité croissante de la conception et de la production du logiciel. L’IDM est distinguée par sa capitalisation du savoir faire non plus au niveau du code source, mais plutôt au niveau des modèles. Cela ne signifie pas une rupture technique avec les solutions de développement existantes telles que les langages de programmation, mais au contraire, elle est complémentaire. En effet, l’utilisation des techniques de transformation de modèles, permet de générer le code source des applications automatiquement ou semi automatiquement depuis les modèles réalisés lors de la conception. De nombreux travaux [4, 5, 6, 7] se sont intéressés à cette nouvelle discipline informatique émergente. Ils ont aidé à clarifier et dégager ses concepts. Par la suite, à partir de ces travaux, nous allons définir les notions fondamentales liées à l’IDM. Nous allons d’abord donner la définition d’un modèle. Nous retiendrons la définition tirée de [8] :
Définition 1 Un modèle est une abstraction d’un système, construite dans une intention particulière. Cette abstraction devrait être représentative afin de répondre à des questions sur le système modélisé. Pour que le modèle soit efficacement manipulable par des outils informatiques, il doit respecter certaines qualités. Dans [9], Bran Selic avait identifié les caractéristiques essentielles qu’un modèle devrait avoir, ce sont principalement :
L’abstraction : le modèle doit assurer un certain niveau d’abstraction et cacher les détails que l’on ne souhaite pas considérer pendant l’étude.
La compréhensibilité : le modèle doit être compris intuitivement par les personnes qui l’utilisent. Donc, il doit être exprimé dans un formalisme assez compréhensible dont la sémantique est intuitive.
La précision : le modèle doit fournir une représentation fidèle et précise des propriétés du système à étudier.
L’économie : le modèle doit rester peu coûteux en comparaison aux coûts du développement du système réel. Cette liste n’est pas exhaustive et elle peut contenir également d’autres caractéristiques telles que la prédiction, la maintenabilité, la traçabilité, l’exécution, etc. Ainsi, l’obtention de modèles qui respectent toutes ces caractéristiques est une tâche non évidente. Dans le cadre du développement logiciel, on s’intéresse de plus en plus à la notion de modèles exécutables et interprétables par les machines. Il nous faut donc pouvoir formaliser la syntaxe d’un modèle, c’est-à-dire définir un langage de modélisation. Pour ce faire, l’IDM propose la notion du méta-modèle.
Définition 2 Un méta-modèle est un modèle d’un langage de modélisation. Il définit les concepts ainsi que les relations entre ces concepts nécessaires à la description des modèles. La relation entre un modèle et un méta-modèle est dite relation de conformité. Ainsi, un modèle est conforme à un méta-modèle. Par analogie, nous pouvons comparer cette relation à un concept de la programmation orientée objet, il s’agit d’instance d’objet. Par conséquent, nous pouvons dire qu’un modèle est une instance d’un méta-modèle. Dans l’IDM, le modèle d’un langage de modélisation s’appelle un méta-modèle. A partir de ces définitions nous identifions deux relations importantes dans l’IDM. La première relation lie le modèle et le système modélisé, elle s’appelle « Représentation de ». La deuxième relation lie le modèle et le méta-modèle du langage de modélisation, c’est la relation « Conforme à ». La figure 2.1 schématise ces deux relations.

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.

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étamodè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.

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.

Ingénierie dirigée par les modèles pour les systèmes temps réel embarqués

   Le développement des systèmes temps réel embarqués nécessite des spécifications précises, complètes et non ambiguës afin d’obtenir des logiciels sûres, fiables et efficaces. L’ingénierie dirigée par les modèles apporte de bonnes pratiques pour le développement de logiciels. Ces pratiques serviront également aux applications temps réel embarquées pour plusieurs raisons [48] :
La spécification des applications temps réel embarquées comprend différents points de vue (ex. fonctionnel, temps-réel, tolérance aux fautes, etc.). Cela nécessite des techniques d’abstraction lors du développement.
Les options d’implémentation visées peuvent varier considérablement ; différents modèles d’exécution peuvent être envisagés pour un même modèle en fonction de contraintes de réalisation particulières (modèle multi-tâches, communication synchrone, programmation en boucle, etc).
La contrainte de performance des STREs s’oppose aux techniques standard du développement logiciel. Les optimisations potentiellement réalisées peuvent produire un code fonctionnel qui pénalise la maintenabilité de l’application finale.
Le test et la validation des applications temps réel embarquées sont des activités critiques qui nécessitent la mise en place de modèles et d’outils d’analyse sophistiqués et spécifiques. L’utilisation de l’IDM pour le développement des STREs, nécessite la définition d’un ensemble cohérent et complet d’artéfacts (règles méthodologiques, transformations de modèles, génération automatique de code) préalablement testés, outillés et évalués. Il reste néanmoins que l’ingénierie dirigée par les modèles présente un inconvénient mineur qui consiste à produire un code généré moins performant qu’un code optimisé directement pour une plateforme cible.

Les sémantiques dénotationnelles

   La sémantique dénotationnelle a été introduite par Scott et Strachey [52] [53]. Son principe est d’associer chaque concept du langage d’origine à un objet mathématique appelé dénotation d’un autre formalisme rigoureusement défini. On parle aussi de modèle formel du langage. Ces objets forment le domaine sémantique du langage d’origine alors que l’association définit sa sémantique. Par ailleurs, la difficulté que nous pouvons rencontrer pour décrire ce type de sémantique est d’identifier les objets mathématiques qui correspondent pertinemment aux concepts du langage et de créer des correspondances entre eux. Dans le contexte de l’IDM, la sémantique d’un langage de modélisation est définie par sa transformation ou traduction vers un autre langage formellement définit tel que les réseaux de Pétri [54]. Sachant que les réseaux de Pétri ont une sémantique formelle, le modèle obtenu prend donc le sens du réseau de Pétri généré. En pratique, cela revient à créer une passerelle entre l’espace technique source et cible permettant en conséquence de profiter des outils disponibles dans l’espace technique cible pour des fins de simulation ou de vérification par exemple.

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