Le contrôleur de dialogue CD

Nous avons suivi les règles de conception d’une hiérarchie d’agents PAC pour réaliser le contrôleur de dialogue [ZZA06b] [ZZ07].

C’est au niveau de ces agents que se fait le choix du Noyau fonctionnel NF et du Composant Technique de Présentation CTP adéquats.

En effet, le CTP sollicite l’agent par un simple envoi de message sans même savoir par quel NF va se faire le traitement de ce message. De la même manière, les Noyaux Fonctionnels NF transmettent aux agents les résultats des traitements sans même savoir quel CTP présentera leurs résultats. En effet, quatre agents apparaissent (Figure.4.4):

1. Un Agent Réparation qui gère l’enchaînement des tâches relatives aux scénarios de maintenance. Tout flux d’informations concernant une intervention de réparation pendant une tâche de maintenance transite par cet agent.

2. Un Agent Base de données BDD qui gère les tâches concernant l’administration des données liées à la fonction maintenance.

3. Un agent scénario qui gère la conception des scénarios, la gestion des différentes augmentations ainsi que toutes les opérations qui leur sont liées telles que la modification ou la suppression d’un scénario (Figure.4.5).

4. Un agent panne qui gère les tâches liées aux ordres de réparation que donne l’administrateur ainsi que les informations relatives aux pannes survenues (Figure.4.6)

Ces quatre agents sont regroupés sous un agent PAC ciment chargé d’établir la communication entre les agents eux mêmes ainsi qu’entre les agents et les Noyaux Fonctionnels NF.

Figure 4. 4. La hiérarchie d’agents PAC peuplant le contrôleur de dialogue du système

Figure 4. 5. Agent scénario et ses fils

Figure 4. 6. Agent panne et ses fils

P A Pannes non traitées P A Ordre de réparation P A Types de pannes P A Valider réparation P A Panne P A Base de données P A Scénario P A Gestion des augmentations P A Ajout Scénario P A Suppression scénario P A Modification scénario P A Réparation P A Scénarios P A Base de données P A Panne P A Ciment

Le Contrôleur de dialogue CD est une hiérarchie d’agents PAC. Il a fallu donc trouver la structure de ces derniers en prenant en compte les trois aspects : 1. Autonomie,

2. Hétérogénéité des différents messages reçus, 3. Création / Destruction dynamique des agents

Pour répondre au besoin d’autonomie, l’utilisation des threads est nécessaire. Rappelons qu’un agent PAC est un agent à 3 facettes, P (Présentation), A (Abstraction) et C (Contrôle). Chaque facette a ses propres données et ses propres traitements. Ces traitements sont exécutés par un thread. Ainsi, à chaque facette est associée un thread.

Les facettes communiquent entre elles et avec les facettes d’autres agents. Cette communication ne doit pas être bloquante. Il existe deux moyens principaux de communication inter-thread, les variables globales et la communication par envoi de messages:

1. Les variables globales sont un moyen de communication facile à mettre en place. Toutefois leur utilisation devra être faîte avec rigueur pour éviter des problèmes dus à l’accès aux variables partagées. De plus, l’utilisation de variables partagées peut nuire aux performances dans le cas où elles seraient demandées en consultation ou en modification par plusieurs threads simultanément, ce qui traduit un blocage d’une facette de l’agent et par conséquent de l’agent.

2. L’envoi de messages a l’avantage d’être non bloquant, ce qui satisfait le critère d’autonomie. C’est pour ce type de communication que nous optons. La communication par envoi de messages implique la création d’une boîte aux lettres pour chaque thread (facette). Cette boîte aux lettres doit satisfaire deux critères :

1. Elle doit être hétérogène car elle peut recevoir des messages de n’importe quelle facette et chaque facette peut envoyer une multitude de types de messages. Le type de messages n’est connu par le thread au moment du traitement du message.

2. Les fonctions send() et receive() de la boîte doivent être en exclusion mutuelle. La fonction receive() effectue une lecture consommatrice.

Les agents doivent pouvoir être créés d’une manière dynamique: un agent naît et meurt, ce qui rejoint le concept de l’objet (un objet naît et meurt). Ainsi pour créer un agent, il suffit d’instancier un objet d’une classe. L’objet résultant se charge de créer et de lancer les threads ainsi que de la création des boîtes aux lettres. La durée de vie de l’agent est donc égale à la durée de vie de l’objet.

Un agent PAC est donc matérialisé par : Trois threads (un pour chaque facette),

Trois boîtes aux lettres (une pour chaque facette), Un objet (pour la création et la destruction de l’agent).

Le squelette de tous les threads est de la forme suivante :

La boîte aux lettres est un objet instancié de la classe BAL. Les données qu’elle contient sont des objets instanciers de classes dérivées d’une classe abstraite nommée Générique.

La classe Agent X est une classe dérivée d’une classe abstraite nommée Agent.

La classe abstraite Agent est de la forme :

Afin que l’implémentation de l’agent soit concrétisée, des concepts propres à la programmation orientée objet (Classes abstraites, héritage,..) et à la

Message mess /* Le message*/

Entier code /* code contenant le code de traitement*/

Debut

Tant que (5<6) {

Boite. receive (mess) /* Récupérer le message */

Code = mess. Recup_codetr() /* Récupérer le code de traitement*/ Switch (code) { case 0 : /*traitement 0*/ break ; case 1 : /*traitement 1*/ break ; . . . case n : /*traitement n*/ break ; } } Class Agent { Public :

BAL Boitep /* Boite de la facette P */ BAL Boitea /* Boite de la facette A */ BAL Boitec /* Boite de la facette C */

Vecteur dynamique d’adresses d’agents Hier

/* Hier contient à l’indice 0 l’adresse de l’agent père et dans le reste des indices les adresses des agents fils */

programmation système (synchronisation, exclusion mutuelle) sont utilisés. Pour réaliser ceci, l’outil utilisé pour développer le contrôleur de dialogue est Borland C++ Builder 6.0 sous la plate-forme Windows.

La classe Agent X est de la forme :