4.4. Des diagrammes d’états-transitions vers l’implémentation des agents : l’ingénierie vers l’aval

L’ingénierie vers l’aval est le processus de transformation d’un modèle en code grâce à un mapping dans un langage d’implémentation donné. Dans cette section, nous proposons quelques règles informelles qui facilitent le travail d’implémentation d’un agent (héritant de la classe Agent de la plateforme JADE) à partir de son comportement sous la forme d’un statechart, mis au point dans la phase précédente (cf. chapitre 3, section 3.6), considérée comme une étape de spécification. Il s’agit donc de faciliter le passage de la spécification à l’implémentation. Ce passage se présente sous la forme d’un ensemble de transformations entre un diagramme d’états-transistions, modèle de comportement d’un agent et une classe d’agent, conformément à la structure proposée par JADE pour une telle classe.

Nous commençons d’abord par la présentation des étapes détaillées d’exécution d’un thread d’agent JADE. Ensuite, nous proposons des règles informelles de transformation entre le modèle de comportement d’un agent et sa classe correspondante en JADE. Puis, à titre d’exemple, nous appliquons ces règles sur le statechart de l’agent « Liv » (cf. chapitre 3, section 3.6.3.1, fig 3.16) afin de déterminer partiellement son code. En général ce code devra être complété par des instructions spécifiques à la gestion de l’activité d’un agent dans l’environnement d’exécution de JADE.

La figure 4.5 présente les étapes détaillées d’exécution d’un thread d’agent JADE. En fait, nous avons enrichi la figure 4.2 par d’autres étapes (marquées par un fond gris) que nous avons déduites au cours de l’utilisation de la plateforme JADE. Comme le montre cette figure, chaque agent JADE possède une méthode setup(). Elle est destinée à contenir les ordres d’initialisations de l’agent et d’ajout de comportements. Il est indispensable d'ajouter au moins un objet comportement (Behaviour) à l'agent, pour qu'il soit capable de faire quoi que ce soit. L’ajout d’un nouveau comportement se fait par la méthode addBehaviour(Behaviour b). La méthode takeDown() est exécutée juste avant la terminaison définitive de l’agent.

Chaque objet comportement (behaviour) possède entre autres les méthodes onStart(), onEnd() et action(). La méthode onStart() est exécutée une seule fois avant de commencer l'exécution du comportement, c’est-à-dire avant l’exécution de la méthode action() qui représente l’activité à exécuter par le comportement. La méthode onEnd() est exécutée une seule fois après la fin d’exécution du comportement.

Un objet comportement d’un agent peut être bloqué (méthode block()) en attendant l’arrivée d’un message provenant d’un autre agent. Quand un message est posté dans la boîte privée des messages de l’agent, le planificateur²⁶ (exécuté par la classe de base Agent et caché au programmeur) exécute le comportement.

La boîte privée des messages de chaque agent est partagée entre tous ses objets comportement. De ce fait, on peut bloquer un objet comportement et ne l’exécuter que lorsqu’un message vérifiant des conditions précises soit posté. La classe MessageTemplate fournie avec la plateforme JADE permet de créer ces conditions et par suite sélectionner le message correspondant.

*: If the method is called from within action() method, behaviour suspension occurs as soon as action() returns.

Après avoir présenté en détail les étapes d’exécution d’un thread d’agent, nous passons maintenant aux règles de transformation.

Nous avons déjà vu dans le chapitre 3 (section 3.6.2) qu’une transition τ = (S0, λ, Sd) est définie par son état origine S0, son état destination Sd et son étiquette λ. Cette dernière est constituée d’une expression d’événement ev, d’une expression conditionnelle cond et d’une expression d’action act, suivant la syntaxe ev [cond] / act. Alors, le premier élément de transformation peut être formulé comme suit :

A chaque couple « étiquette λ, état destination S _d  » on associe un objet comportement (Behaviour). Le type de cet objet (cf. figure 4.3) dépend de deux critères concernant l’événement ev constituant la transition. Le premier critère est lié au type de l’événement qui pourra être un message provenant d’un autre agent ou non (par exemple : événement temporel causé par l’expiration d’une temporisation). Nous avons déjà dit dans le rappel sur les statecharts (cf. chapitre 3, section 3.6.2) qu’un événement pourra être différé en vue d’un traitement ultérieur dans un état ne différant pas cet événement. Ce caractère différé caractérisant un événement constitue le second critère conduisant au choix du type de l’objet comportement. Nous nous intéressons ici seulement aux événements de type messages provenant d’autres agents. Nous dégageons donc deux règles :

1. Si l’événement constituant la transition est non différé dans aucun des états de l’agent, alors le type de l’objet comportement sera OneShotBehaviour(). Il ne doit être ajouté que lorsque l’agent termine l’exécution de l’état origine de cette transition. L’objet OneShotBehaviour() ajouté doit être bloquée jusqu’à l’arrivée du message correspondant.

2. Si l’événement est différé , alors le type de l’objet comportement sera CyclicBehaviour(). Il pourra être ajouté dans la partie initialisation de l’agent, en particulier dans la méthode setup(). L’objet CyclicBehaviour() ajouté doit être bloquée jusqu’à l’arrivée du message correspondant. La classe MessageTemplate de la plateforme JADE permet de créer des templates complexes pour sélectionner les messages reçus.

La troisième règle de transformation concerne les actions d’entrée et de sortie de chaque état (représenté par un comportement). Elle peut être formulée comme suit :

3. Dans certaines situations, on souhaite exécuter les mêmes instructions chaque fois que l’on entre dans un état quelle que soit la transition par laquelle on est arrivé. Ces instructions peuvent être placées dans la méthode onStart() du comportement associé. De même, à la sortie d’un état (fin d’exécution du comportement associé), on peut avoir envie d’exécuter les mêmes instructions, quelle que soit la transition par laquelle on repart. Ces instructions peuvent être placées dans la méthode onEnd() du comportement.

Dans la suite de cette section, nous montrons comment appliquer ces règles sur un exemple d’agents de notre système. Pour cela, nous nous référons au diagramme d’états-transitions de l’agent « Liv » (cf. chapitre 3, section 3.6.3.1, fig 3.16). Nous le reprenons sur la figure 4.6. La classe Java de l’agent « Liv » est obtenue à partir de son modèle de comportement, sa structure partielle est présentée dans le tableau 4.1.

Remarque :

Dans certains cas, après une application mécanique des transformations, on peut percevoir des possibilités de simplification.