Vue d’ensemble sur le cycle de vie de RobotML

2 Vue d’ensemble sur le cycle de vie de RobotML

Comme nous l’avons présenté dans le chapitre 3, le cycle de vie d’un DSML comporte quatre phases : l’analyse du domaine, la conception, l’intégration des pla-teformes cibles à travers la définition de générateurs de code et enfin l’utilisation. Pour effectuer l’Analyse du domaine, nous nous sommes basés sur un état de l’art sur les middleware, les simulateurs et les DSL existants pour la robotique. Cet état de l’art a permis d’identifier certaines exigences notamment l’indépendance par rap-port aux plateformes cibles (middleware et simulateurs) et la représentation d’une architecture à base de composants. Ces dernières, combinées avec les concepts du domaine fournis par une ontologie de la robotique mobile définie dans le cadre du projet PROTEUS, ont permis de délimiter le domaine d’application (c.-à-d. la ro-botique mobile) et d’extraire de l’ontologie les abstractions dont les roboticiens ont besoin pour la définition de leurs applications.

Après cette étape d’analyse du domaine arrive l’étape de Conception où l’on identi-fie la syntaxe abstraite ainsi qu’une syntaxe concrète qui s’articule autour de cette syntaxe abstraite afin de fournir un éditeur graphique permettant de manipuler les concepts du domaine.

Plusieurs générateurs de code ont ensuite été implantés afin d’établir des règles de transformations à partir de ces abstractions vers les plateformes cibles.

Enfin, la phase d’utilisation de RobotML consiste à tester toute la chaîne d’outillage de la modélisation vers la génération de code.

3 Analyse du domaine

L’analyse du domaine pour la définition de notre DSML se base sur une ontologie de la robotique mobile définie dans le cadre du projet PROTEUS [7] ainsi que sur l’état de l’art des simulateurs et des middleware robotique. Une ontologie est une représentation formelle des connaissances décrivant un domaine donné [111].

L’ontologie de PROTEUS a été construite à partir de la connaissance des experts en robotique dans différents sous-domaines. Leur expertise porte sur les domaines sui-vants : commande, contrôle, perception, navigation, localisation, contrôle du trafic, optimisation, planification et simulation. Afin de partager leurs connaissances, des experts du domaine partenaires du projet PROTEUS, se sont réunis pour décrire des scénarios et pour exprimer leurs connaissances et leurs besoins dans la robotique

mobile autonome. À partir de ces réunions, les exigences de l’ontologie ont été défi-nies.

Ces exigences concernent la modélisation de la mécanique et des composants électro-niques ainsi que des architectures de contrôle, les systèmes, les simulateurs, etc. Ces exigences incluent également la modélisation d’un robot donné ainsi que le suivi de son évolution (comportement) pendant l’exécution de son scénario. Comme il faut modéliser le comportement du robot, il est nécessaire de modéliser son environne-ment et sa mission.

L’ontologie a été définie autour du concept System. Ce dernier représente une en-tité ayant des intéractions, il peut être considéré comme un composant au sens du génie logiciel. Un System est défini comme un bloc qui déclenche des intéractions et est impacté par les intéractions des autres systèmes. Le choix d’une représentation d’une telle architecture a pour but de permettre la définition des composants, de leurs comportements et des différents échanges de données entre eux. Ainsi, le code final généré à partir du DSML (dont les concepts sont extraits de l’ontologie) pourra correspondre aux concepts architecturaux utilisés par les plateformes cibles.

L’ontologie de PROTEUS a été décrite avec le langage OWL que nous avons pré-senté dans la section 3.1.1.1 et est organisée de manière modulaire où les modules sont définis comme une spécialisation du module principal (le Kernel). Certains modules permettent de spécifier les classes décrivant les System, leurs ports et leurs caractéristiques. D’autres modules servent à décrire l’environnement du robot, les outils de simulation utilisés pour tester les solutions ou encore les expérimentations (validation, vérification, tests).

La figure IV.15 montre la classification des différents systèmes (System) définis par l’ontologie. Comme nous l’avons dit un System est une entité ou une unité logique qui réalise une intéraction, il peut lui même comporter d’autres Systems dans ce cas, il s’agit d’un CompositeSystem. Les PhysicalObject, Software et AtomicSystem sont des Systems. Un PhysicalObject décrit toutes les entités physiques dans un scénario de robotique. Il peut être un Hardware (c.-à-d. horloge, effecteur, un bus de communication ou encore un capteur) sur lequel le Software s’exécute. Un PhysicalObject peut également être un Agent capable d’agir comme les robots (Robot) et les humains (Human).

La figureIV.16montre la relation entre les différentes Systems. Une Interaction est un concept abstrait utilisé pour décrire les intéractions entre les Systems. Elle s’effectue à travers des Ports qui représentent des interfaces pour les

entrées/sor-IV.3 Analyse du domaine

Figure IV.15 – Classification des systèmes dans l’ontologie (extrait de [7])

ties entre les Systems. Un System possède un état et un modèle d’évolution. Un EvolutionModel représente la propriété intrinsèque d’un composant d’évoluer à travers le temps. Deux types spécifiques d’EvolutionModel sont distingués mais ne sont pas représentés dans cette figure : Algorithm et StateMachine. Un Algorithm est une méthode pour la résolution d’un problème sous forme d’une séquence d’ins-tructions. Une machine à états est définie par des transitions, des événements et s’appuie sur des états (State) pour indiquer l’évolution d’un système à travers des états.

Les données échangées entre les différents Systems sont représentées dans le module Information (voir figure IV.17). Une Information est directement ou indi-rectement liée à une intéraction. Le lien direct indique qu’une intéraction transmet des informations. Le lien indirect indique qu’une intéraction possède un protocole qui contient des informations. Une Abstraction est une Information qui n’est pas directement interprétée par la machine.

Contrairement aux abstractions, Data est une information directement interprétée par la machine. Une spécification de Data qui n’est pas représentée sur cette figure est PhysicalData ; elle désigne un objet mathématique-algébrique ayant une unité physique associée.

Figure IV.16 – Intéraction entre les systèmes dans l’ontologie (extrait de [7])

Figure IV.17 – La classe Information dans l’ontologie (extrait de [7])

Les classes de l’ontologie représentant les concepts du domaine peuvent être re-prises, modifiées ou supprimées dans le DSML. Par exemple, Interaction permet de définir un lien entre deux Systems mais n’est pas assez explicite. Nous l’avons remplacé dans le modèle du domaine par les concepts Port et Connector pour