Modélisation explicite de l’adaptation sémantique entre modèles de calcul

Dans un monde industriel où l’on devient de plus en plus exigeant et précis en termes de besoins en logiciels, répondre à ces besoins devient une tâche de plus en plus complexe pour les développeurs. Un développeur se doit donc de maîtriser plusieurs technologies et langages de programmation s’il veut être capable de répondre aux besoins de ses clients. La complexité des logiciels induit forcément une complexité au niveau de leurs codes sources, ce qui rend la tâche difficile pour les développeurs lors des phases de modification ou d’évolution de ces programmes; manipuler une grande quantité de codes peut être une tâche à la fois fastidieuse et coûteuse.

Une volonté d’abstraction est apparue dans le monde du génie logiciel afin de permettre aux développeurs de se détacher des technologies tout en minimisant le coût du développement d’un logiciel et le temps de sa mise sur le marché. Cette abstraction permettra d’avoir des solutions de logiciels plus génériques. Elle contribuera aussi à faciliter la tâche des développeurs qui ne seront plus obligés de maîtriser telle technologie pour réaliser tel programme, ou encore de manipuler du code pour modifier ou faire évoluer une application. Étant donné que la phase de développement se doit d’être liée à une certaine technologie et un certain langage de programmation, c’est donc dans la phase de modélisation d’un logiciel que cette volonté d’abstraction peut être concrétisée ; un modèle est plus abstrait que le code. L’ingénierie Dirigée par les Modèles (IDM) [Kent 2002, Jézéquel 2012] est un paradigme qui a fait son apparition dans le monde du génie logiciel en offrant une démarche qui se base sur les modèles pour la programmation. Le principe est de considérer que tout ou partie d’une application est généré à partir des modèles. Les modèles de conception de l’application se doivent donc d’être explicites et bien précis, mais encore, ils doivent eux-même être manipulables. Cela offrira aux développeurs la possibilité de les transformer lors de l’incorporation d’une technologie à une application ou encore l’application de patrons de conceptions. Modifier ou faire évoluer un logiciel devient alors une tâche plus facile, il suffit de reprendre la conception du logiciel à travers la manipulation des modèles.

Modélisation par composants

Les différentes étapes du cycle de développement en V d’un système, réduisent la complexité de sa conception verticalement en identifiant différents niveaux d’abstraction (modèle, algorithme, code source, etc). La modélisation par composant [Lee 2011, Gössler 2005], quant à elle, permet de réduire la complexité de la conception horizontalement en décomposant chaque activité (ou niveau d’abstraction) en différents domaines métiers .

La conception d’un modèle à base de composants est obtenue en assemblant des boîtes noires , contenant des entités de conception fortement encapsulées. Le comportement d’un composant n’est donc pas visible de l’extérieur ; il n’est visible que sur son interface composée de ses entrées et de ses sorties. Ces interfaces possèdent des spécifications concises et rigoureuses permettant aux composants d’être regroupés et structurés pour former le modèle global .

Un avantage de cette approche est que les composants (ou boites noires) sont indépendants les uns des autres, ce qui les rend exploitables dans différents modèles et permet de définir une bibliothèque de composants pour chaque paradigme de modélisation. Dans le contexte de la modélisation hétérogène , la décomposition d’un système hétérogène est avant tout induite par les différents domaines techniques mis en jeu. Les composants considérés lors de la modélisation d’un tel système sont définis selon des sémantiques différentes. Prenons l’exemple d’un système hétérogène : un robot humanoïde. Ce système implique quatre domaines techniques : l’informatique pour la programmation, la mécanique pour modéliser les mouvements, l’électronique pour modéliser les circuits électroniques et l’automatique pour modéliser le contrôleur. Chaque domaine technique est associé à une sémantique différente, il impose donc l’utilisation d’un paradigme de modélisation adéquat. Ce système est alors décomposé en quatre composants, chaque composant dans ce cas est un sous-modèle associé à une sémantique propre à un domaine technique particulier. Pour obtenir un modèle hétérogène en utilisant la modélisation par composants, deux principales tâches doivent être réalisées :

• La définition précise de la sémantique de chaque paradigme de modélisation utilisé: nous distinguons trois approches pour définir la sémantique de chaque paradigme de modélisation, la première se base sur les modèles de calculs, la deuxième sur les connecteurs (ou interfaces) des composants, et la troisième sur des opérateurs de composition.

• La définition précise de l’adaptation sémantique entre les différents paradigmes de modélisation utilisés : l’adaptation sémantique est la colle qui permet de regrouper les différents composants pour former le modèle global d’un système hétérogène .

Approche à base de modèles de calculs

Dans l’approche à base de modèles de calculs, la sémantique de chaque paradigme de modélisation est définie par un Modèle de Calcul (MoC). Les MoCs viennent principalement de Ptolemy II [Eker 2003, Brooks 2008a], une plateforme de conception et de simulation de modèles hétérogènes réalisée à l’université de Berkeley. Dans Ptolemy II, l’idée centrale est que chaque MoC définit la loi de combinaison des comportements des composants d’un modèle, selon un paradigme de modélisation approprié.

Un modèle conçu selon cette approche est composé de deux principales parties : (1) une structure qui regroupe les différents composants modélisant le comportement du modèle, (2) et une instanciation d’un MoC (Director dans PtolemyII) qui définit la sémantique de ses composants, à savoir la nature des données échangées entre eux, la notion de temps qu’ils partagent, ou encore leur sémantique de comportement (séquentiel, concurrent, synchrone, etc).

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela chatpfe.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

1 Introduction
1.1 Contexte
1.2 Objectif
1.3 Organisation de la thèse
I Modélisation et simulation des systèmes hétérogènes
2 Modélisation par composants et Modèles de Calculs (MoCs)
2.1 Introduction
2.2 Modélisation par composants
2.2.1 Approche à base de modèles de calculs
2.2.2 Approche à base de connecteurs
2.2.3 Approche à base d’opérateurs de composition
2.3 Modèles de Calculs (MoCs)
2.3.1 MoC « Discrete Events » (DE)
2.3.2 MoC « Finite State Machine » (FSM) et « Timed Finite State Machine » (TFSM)
2.3.3 MoC « Synchronous DataFlow » (SDF)
2.3.4 MoC « Continuous-Time » (CT)
2.4 Conclusion
3 Modélisation du temps
3.1 Introduction
3.2 Notion d’instants
3.3 Domaine de temps
3.4 Natures de temps
3.4.1 Temps continu
3.4.2 Temps discret
3.5 Contraintes temporelles
3.5.1 Le langage de spécification de contraintes d’horloges CCSL
3.5.2 Modélisation du MoC SDF avec CCSL
3.6 Conclusion
4 Modélisation hétérogène
4.1 Introduction
4.2 Modélisation hétérogène hiérarchique
4.3 Hétérogénéité des modèles
4.3.1 Hétérogénéité des données
4.3.2 Hétérogénéité du temps
4.3.3 Hétérogénéité du contrôle
4.4 Adaptation sémantique
4.4.1 Adaptation sémantique des données
4.4.2 Adaptation sémantique du temps
4.4.3 Adaptation sémantique du contrôle
4.5 Outils de modélisation et de simulation des systèmes hétérogènes
4.5.1 Simulink/Stateflow
4.5.2 MODELICA
4.5.3 Ptolemy II
4.5.4 ModHel’X
4.6 Conclusion
II Contribution
5 Première approche avec CCSL
5.1 Introduction
5.2 Modélisation des MoCs
5.2.1 Description de la sémantique de TFSM avec CCSL
5.2.2 Description de la sémantique de DE avec CCSL
5.2.3 Description de la sémantique de SDF avec CCSL
5.3 Adaptation sémantique des MoCs avec CCSL
5.3.1 Adaptation sémantique entre DE et TFSM
5.3.2 Adaptation sémantique entre DE et SDF
5.4 Limites de l’approche
5.5 Conclusion
6 Tagged Events Specification Language (TESL)
6.1 Introduction
6.2 TESL (Tagged Events Specification Language)
6.2.1 Horloges et Tics
6.2.2 Relations sur les instants d’horloges
6.2.3 Relations sur les étiquettes des instants
6.2.4 Résolution des spécifications TESL
6.3 Conclusion
7 Intégration de TESL dans ModHel’X
7.1 Introduction
7.2 Intégration de TESL dans ModHel’X
7.2.1 Adaptation sémantique du contrôle
7.2.2 Adaptation sémantique du temps
7.3 Algorithme de simulation de ModHel’X
7.3.1 Préparer le modèle global pour sa simulation .
7.3.2 Déterminer les DrivingClocks susceptibles de déclencher un pas de simulation
7.3.3 Déterminer les occurrences des évènements associés au modèle global durant un pas de simulation
7.3.4 Réaliser le snapshot .
7.4 Conclusion
III Mise en œuvre