CHAPITRE V : IMPLÉMENTATION
Chapitre V
Implémentation
V.1. Introduction
Après avoir identifié les différentes
fonctionnalités de notre système à travers la
décomposition fonctionnelle de l'objectif global de l'organisation et la
détermination des différents rôles qui composent notre
application, nous allons passer à la dernière phase de notre
projet : l'implémentation du SMA. Nous allons alors mettre en oeuvre la
démarche conceptuelle adoptée dans le chapitre
précédent afin d'aboutir à une organisation
concrète d'un SMA d'ACI.
Le présent chapitre est structuré comme suit :
la section 2 est consacrée à la description des outils logiciels
utilisés lors du développement de notre application à
savoir la plate-forme MADKIT et les deux SGBD MySQL et Access. La section 3 est
dédiée à une présentation des schémas
conceptuels des bases de données utilisées, de l'architecture
d'implémentation du système et de quelques interfaces. Enfin,
nous exposerons les conclusions de cette phase et dégagerons quelques
perspectives.
V.2. Outils de développement de l'application
V.2.1. Plate-forme MADKIT
Comme nous l'avons déjà mentionné, notre
système est développé sur la base de la plate-forme Madkit
qui est une plate-forme destinée au développement et à
l'exécution des SMA fondés sur des critères
organisationnels (groupes et rôles).
En fait, la plate-forme Madkit est basée sur un MO (le
modèle AGR) qui permet en particulier de caractériser les agents
en utilisant la notion de groupe et de rôle.
Dans cette partie on va s'intéresser avec plus de
détails aux aspects techniques de la structure et des fonctions des
agents dans cette plate-forme qui propose une librairie de classe JAVA pour la
réalisation de ces agents.
Structure et fonctions d'un agent
La classe de base d'un agent MadKit (AbstractAgent)[URL
3], définit quelques fonctionnalités de base qui sont
associées à chaque agent et qui sont :
· Cycle de vie
Le cycle de vie d'un agent est composé d'une
séquence de quatre états : création, activation,
exécution, et destruction.
Les agents héritant de la classe Agent doivent
implémenter les méthodes suivantes:
public void activate() : qui est lancée lors de
l'initialisation de l'agent
public void live() : qui définit le comportement
permanent de l'agent.
On peut également employer la méthode
end(), qui est appelée par le noyau si on lui demande
d'arrêter l'agent.
· Communication
La communication est implémentée sous forme de
passage de message asynchrone, soit d'un agent à un autre
identifié par son AgentAddress ou son groupe et rôle,
soit sous la forme d'une diffusion à tous les teneurs d'un rôle
dans un groupe donné.
· Organisation
Tout agent dispose de primitives permettant d'observer son
organisation locale (connaître les groupes et rôles courants) et
d'y agir (prise de rôle, entrée et retrait d'un groupe).
· Outils
La classe de base des agents permet également de
manipuler une éventuelle interface graphique associée à
l'agent, les flots d'entrée/sortie ...
· Messages
Les messages sont définis par héritage à
partir d'une classe de base Message qui ne définit que la
notion d'émetteur et de destinataire. Une bibliothèque de
messages de base (Figure 19) est néanmoins fournie et permet l'envoi de
chaînes, d'objets sérialisés, de documents XML, ou bien de
messages conformes aux spécifications KQML et FIPA-ACL.
AbstractMessage
Message
|
|
|
|
|
|
|
|
ActMessage
|
|
StringMessage
|
|
|
|
XMLMessage
|
|
|
|
ObjectMessage
|
|
|
|
|
|
|
|
|
|
|
Figure 19 : Hiérarchie des messages
standards dans Madkit.
V.2.2. Systèmes de gestion de base de
données utilisés
Une base de données permet de mettre des
données à la disposition des utilisateurs pour une consultation,
une saisie ou bien une mise à jour, tout en respectant leurs droits. La
gestion de la base de données se fait grâce à un
système appelé système de gestion de bases de
données (SGBD)
Un SGBD est un ensemble de services (applications logicielles)
permettant de gérer les bases de données : permet
d'accéder aux données d'une façon simple, d'autoriser un
accès aux informations à de multiples utilisateurs et de
manipuler les données présentes dans la base de
données...
Dans notre application, nous avons opté aux choix de
deux SGBD Access et MySQL pour la consultation et l'extraction des informations
indispensables de répondre aux requêtes externes provenant de
l'utilisateur.
· SGBD Access
Microsoft Access est un Système de Gestion de Base de
Données Relationnel (SGBD-R) présentant une approche bureautique
et n'est pas conçu pour supporter de très grandes bases de
données opérationnelles sur de vastes réseaux. En Java,
Microsoft Access peut être utilisé de façon transparente
à l'aide de la passerelle JDBC-ODBC [URL 4].
· SGBD MySQL
MySQL est dérivé de SQL (Structured Query
Language), en français, langage de requête structurée.
C'est un système de gestion de base de données relationnel.
Concrètement, SQL permet de dialoguer avec une base de données en
langage presque courant. SQL s'utilise surtout via une fenêtre de
commande, MySQL s'utilisant via un langage de programmation, PHP étant
le langage de prédilection de MySQL. Le meilleur moyen de se mettre
à MySQL et de progresser est d'installer EasyPHP. EasyPHP est un
logiciel freeware qui crée un environnement serveur complet à la
fois pour PHP et MySQL[URL 4].
Il est à noter que les deux SGBD
présentés ci-dessus, sont utilisés afin de concevoir et
réaliser deux Base de Données différentes et qui vont
constituer par la suite nos deux sources d'informations depuis lesquelles nous
allons extraire les données nécessaires afin de répondre
à la requête de l'utilisateur.
V.3. Présentation de l'application V.3.1.
Architecture du système
Le but essentiel de notre travail est la réalisation
d'un SMA d'acquisition coopérative d'informations pour l'organisation
d'un voyage en gérant les préférences de l'utilisateur. On
va préciser dans cette partie comment se déroule le traitement
d'un tel problème : L'utilisateur soumet son problème à
l'interface et reçoit par la suite une réponse à sa
requête .Cette réponse est assurée via un ensemble d'agents
qui vont être en communication continuelle afin de répondre d'une
manière coopérative à la requête posée par
l'utilisateur. Les agents formant notre système sont :
- Un agent jouant le rôle Médiateur qui va se
charger de la décomposition de problème en deux grands sous
problèmes le premier concernant le voyage, et le deuxième
concernant l'hébergement.
- Deux agents jouant le rôle Coordinateur : Coordinateur 1
et Coordinateur2.
Le Coordinateur 1 va se charger du premier problème
concernant le voyage et le
Coordinateur2 va prendre la charge du deuxième
problème concernant l'hébergement.
- Un agent jouant le rôle d'un Matchmaker qui va localiser
les agents capables de
répondre à une requête donnée.
- Deux agents jouant le rôle Traducteur : Traducteur 1 et
Traducteur2.
Le premier agent sera affecté à une source de
données Access disposant des données sur les voyages, et le
deuxième sera affecté à une source de données
MySQL.
La figure référencée Figure 20
présente une vue globale sur l'architecture de notre
SMA.
Figure 20 : Architecture du système.
| 
