Bloc façade

Le bloc Façade¹ a pour objectif de cacher l’hétérogénéité des objets capteurs et actionneurs et assurer un canal de communication bidirectionnelle avec ces objets.

Dans l’architecture logicielle présentée dans le chapitre 5, le bloc façade a pour rôle de gérer tous les aspects concernant la communication entre le noyau de raison-nement et les objets du monde réel. Il garantit ainsi la synchronisation entre l’état des objets et leurs représentations conceptuelles dans le modèle sémantique. Le bloc façade assure aussi la transmission et l’interprétation des actions (envoyer un mes-sage, déplacer le robot, allumer la lumière, etc.) à destination des objets actionneurs du monde réel. Il permet également d’abstraire les technologies, les protocoles de communication, la découverte et l’enregistrement dynamiques de nouveaux objets ou services. Il permet aussi l’acquisition des données brutes émises par des objets ou des services. Ces données sont encodées dans un format compréhensible par les modules de raisonnement réactif et narratif.

Actuellement, le support de communication mis en ouvre au niveau du bloc façade utilise trois protocoles :JMS, HTTP et SOAP. Cependant, l’extension de ce bloc pour supporter d’autres protocoles tels qu’OSGi, iPOJO, UPnP, SNMP reste possible.

Dans le bloc façade, nous dénombrons plusieurs composants, figure A.1: 1. Source d’événements (Events sources) : Ce composant reçoit des événements

déclenchés par un objet du monde réel et alimente leContrôleur d’événements

(Event Controller) avec un nouveau message ;

2. Encodeur d’événements (Event Encoder) : Cet encodeur gère les transforma-tions des messages en formatµConcept ;

3. Contrôleur d’événements (Event Controller) : Ce composant traite les mes-sages encodés par le composant Event Controller et invoque le composant

MsgSender pour rediriger les messages vers le noyau ;

4. Récepteur de message (µConcept Message Receiver) : Ce composant a pour rôle de réceptionner des messages provenant du noyau ;

5. Gestionnaire d’actions (Action Handler) : Ce composant transforme chaque action contenue dans un message en commandes à exécuter par les objets du monde réel, puis invoque le composant Action Destinations;

6. Destination d’Action (Action Destinations) : Ce composant a pour rôle d’iden-tifier l’objet auquel le message est destiné, et le protocole de communication utilisé ;

Figure ^{A.1 – Architecture globale de la couche Façade.}

A.1.1 Noyau de raisonnement réactif

Il offre un ensemble d’interfaces pour alimenter et interroger la base de connaissances. La principale caractéristique de ce noyau est qu’il s’appuie sur un mécanisme de plug-in. Par ailleurs, il peut être exécuté indépendamment des autres couches permettant ainsi à tous les autres composants d’utiliser une interface de communication synchrone pour échanger des connaissances via le pro-tocoleJ M S. L’architecture interne de ce noyau est composée des modules suivants :

a) Modèle sémantique

Pour garantir la cohérence du modèle et du système, le modèle sémantique est associé à un module de gestion de contraintes d’intégrité (Constraint Checking), basé sur l’hypothèse du monde fermé avec présupposition du nom unique. En effet, à la réception d’un message de la façade ou du moteur d’inférence, le module vérifie si les contraintes d’intégrité (cardinalités de restrictions, domaines de propriété, propriété fonctionnelles, etc.) sont satisfaites avant de modifier le modèle, figure A.2. Ainsi, toutes les opérations de modification du modèle sémantique sont contrôlées. La vérification de contraintes d’intégrité est associée à un mécanisme de transaction qui

permet d’annuler des modifications du modèle en cas d’incohérence ou de détection d’erreur.

Figure ^{A.2 – Processus de contrôle de la cohérence du modèle sémantique.}

b) Module d’inférence

Il est en charge de l’exécution des règles, et de la synchronisation de la base de connaissances par rapport au modèle sémantique. Basé sur l’algorithmeRete, le module d’inférence est géré de manière synchrone avec le modèle sémantique. Afin de garantir la cohérence et l’intégrité du modèle sémantique, ce dernier ne peut pas être modifié par d’autres modules pendant le processus de raisonnement.

L’ontologie AmiOnt associée au langage de règlesSmartRules est transformée en une représentation orientée objet grâce à la fonction de génération dynamique des classes de l’outilASM². Tous les concepts, propriétés, instances et actions sont instanciés sous forme de composants J avaBeans, et par conséquent, tous les faits insérés dans la mémoire de travail du moteur d’inférence Drools correspondent à des instances de classes Java.

Le moteur d’inférenceDroolsa été choisi à partir des considérations suivantes : – Droolsreprésente le moteur orienté objet open source le plus utilisé à l’heure

actuelle ;

– Droolsoffre différents opérateurs de vérification de contraintes (not matches,

not contains, in, not) ;

– Drools est un système orienté "règles de production" à la différence, par exemple, du moteur d’inférence J ena2. Ce dernier est une extension du

mo-2. http ://asm.owmo-2.org/index.html. Il est un outil de manipulation de classes Java conçu pour la génération et la manipulation dynamiques de code.

teur d’inférence J ena2, qui a été développé pour supporter le chainage avant. Cependant, l’algorithme Rete n’est pas totalement intégré dans le nouvelle versionJ ena2;

– Drools peut être considéré comme un bon candidat pour combiner les principes OW A et CW A. En effet, Bragaglia et al. [173] se sont attaqués au défi qui consiste combiner le raisonnement en logique de description ALC avec le raisonnement à base de règles. Les auteurs ont proposé une approche basée sur le moteur de règlesDroolspour coupler les deux hypothèsesCW A

etOW A.

c) Module de traduction de règles

Il permet de traduire les règlesSmartRules vers le format du moteur de règles

Drools. La grammaire utilisée par ce module permet de construire automatique-ment un analyseur qui détermine la structure syntaxique des règles. Cet analyseur permet de détecter des ambiguïtés syntaxiques à l’étape d’édition des règles.

d) Modules de communication et d’orchestration

Le noyau de raisonnement réactif comprend deux modules permettant d’une part, la communication entre les modules internes du noyau et d’autre part, l’or-chestration de l’exécution de tous les modules. Le module de communication permet l’insertion dans le modèle sémantique des messages provenant des objets du monde réel, l’exécution des règles et la gestion de la persistance de l’état du système.