Conception d'un système multi-agent extensible

**behess** · 15/05/2008, 16h20

Bon on va attendre un peu pour le diagramme car je commence à cafouiller au niveau du lien Observer / Observable ; dans mon diagramme ils sont tous les deux dotés d'une méthode qui accepte un Event :
- warnOfEvent() pour observer
- notify() pour observable

Et comme tous les agents sont des observers et des observables simultanément (mais pas des mêmes choses), je ne sais plus qui observe quoi, qui est observé... Je dois revoir tout ça.

Pour le dispatching des Events, j'ai pensé à créer des objets EventDispatchingModality qui peuvent être regroupés en étant chainés (pour éviter d'avoir un groupe qui n'aurait aucune responsabilité particulière).

Lorsqu'un Event ne peut être traité par un agent, il transmet à ses fils.
Si les fils ne peuvent traiter l'Event, il peut essayer

- soit avec ses connaissances (l'Event est stocké dans un objet Livraison, avec en destinataire la liste des connaissances ; et l'agent part en "livraison"),
- soit il l'envoie à son environnement selon les modalités précités.

Les modalités pourraient être :
- une distance numérique (nombre de Places),
- une direction symbolique (le type de lien que peut parcourir l'Event),
- un type de destinataire potentiel (ex : seulement ces types d'Agent / pas ces types d'Agent),
- une durée de subsistance (une minute, une heure),
- une réitérabilité (0 fois pour infinie; 1 fois, 2 fois),
- une transitivité (quels sont les types d'Agents qui peuvent réémettre cet Event ?).

**hed62** · 15/05/2008, 16h49

Lorsqu'un Event ne peut être traité par un agent, il transmet à ses fils.
Si les fils ne peuvent traiter l'Event, il peut essayer

- soit avec ses connaissances (l'Event est stocké dans un objet Livraison, avec en destinataire la liste des connaissances ; et l'agent part en "livraison"),
- soit il l'envoie à son environnement selon les modalités précités.

Je pense que ceci devrait être géré par les Behaviors. On peut en effet facilement imaginer des Agent autistes, qui ne peuvent communiquer, ou un Agent fier qui n'as pas besoin de ses copains, etc... Donc même si 99% des Agents auront ce comportement, je vote pour la flexibilité de déplacer ce comportement en Behavior.

Et comme tous les agents sont des observers et des observables simultanément (mais pas des mêmes choses), je ne sais plus qui observe quoi, qui est observé... Je dois revoir tout ça.

Il y a effectivement de quoi se perdre aisément, courage.

**behess** · 15/05/2008, 17h53

Donc même si 99% des Agents auront ce comportement, je vote pour la flexibilité de déplacer ce comportement en Behavior.

Tu me proposes de faire ce que tu me déconseillais l'autre jour de faire : du spécifique

Je pense que le comportement par défaut doit être le même pour tous, quitte à redéfinir ce comportement dans les agents autistes ou dans les agents fiers.

A la limite, on pourrait imaginer un comportement par défaut paramétrable, comme ça il suffirait de cocher quelques flags pour altérer celui-ci !

**hed62** · 16/05/2008, 08h58

Cela reste ton choix, mais
1/ "du spécifique" : En quoi le fait de coder un behavior pour atraper/propager un event est il du spécifique comparer à coder en dur dans l'agent ce comportement ?

2/ "tu me déconseillais l'autre jour de faire" : je viens de relire la discution (oula, du chemin a été fait finalement ^^) , quand ai je dit ca ? ici ? Si oui , effectivement, la déportation du code depuis l'agent vers un behavior peut parfaitement se faire plus tard. Mais cette remarque est valable pour quasi tout ce que nous avons dit jusque là

A bientôt ! Au fait, tu avances sur l'implémentation, ou pas encore ?

**behess** · 16/05/2008, 09h26

En quoi le fait de coder un behavior pour atraper/propager un event est il du spécifique comparer à coder en dur dans l'agent ce comportement ?

Oui tu as raison

Pour ce qui est de l'implémentation du dispatching par un Behavior, tu as peut-être une bonne idée finalement

Je vais regarder si c'est faisable, mais comme je suis en train de me dépatouiller avec les Observers et Observables, je mélange tout

Côté implémentation : je n'ai pas réellement commencé à implémenter quoi que ce soit

Je voudrais avoir un modèle assez stable du coeur avant de commencer. Tout au plus j'ai testé des notions de langage Java.

**hed62** · 16/05/2008, 09h35

Observers et Observables, je mélange tout

Tu peux préciser? parfois expliquer à quelqu'un clarifie ses propres pensées.

**behess** · 16/05/2008, 09h42

En fait mon problème c'est que les méthodes :
* notify() dans Observable et
* update() dans Observer,

j'en ai fait du :
* notify(Event) dans Observable et
* warnOfEvent(Event) dans Observer (que je vais sûrement renommer "takeCareOfEvent(Event), le "warnOf" n'est pas clair déjà,

en pensant les utiliser pour diffuser un événement.

Mais comme les agents sont à la fois Observer et Observable, je ne sais plus trop part quel interface passer. Je pense qu'il faut un scénario pour clarifier tout ça.

En fait tout dépend du destinataire :
* notify() transmet aux observateurs de l'agent mais ne traite pas l'Event lui même à priori,
* update() est plutôt censé traiter l'Event que le diffuser.

Or moi je veux une méthode qui puisse faire les deux selon le contenu de l'Event...

**hed62** · 16/05/2008, 09h54

Les méthodes génériques, que l'AgentBase possède :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
notify(Event e)
{
  foreach Observer o in myObservers
    o.update(e);
}
 
 
update(Event e)
{
  my_behavior.handle(e);
}

Et c'est tout.
Ensuit, par contre, le behavior Propagateur fera :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
handle(Event e)
{
  if e is UnEventQuiMinterressePas
    return true; // pour dire que le suivant doit le prendre en compte
  else if e is UnEventAPropager
    agent.notify(e)
}

Avec la décoration souhaité sur les propriétés autres de l'event et de l'agent.

Pas la peine de se prendre la tête avec qui observe qui et pourquoi

**behess** · 16/05/2008, 10h42

Avec cet exemple ça parait simple en effet...

En fait le réel problème c'est que j'ai du mal à définir qui peut être observé par qui...

Le World peut être observé [par tous les agents] car il diffuse des messages qui n'ont abouti nulle part ailleurs.
Une Place peut être observée [par ses agents et par les Places liées] car elle diffuse des messages aux agents qui y vivent et aux autres Places.
Un Agent peut être observé [par un autre agent] car il diffuse des messages à ses fils et à ses connaissances

Mais je me demande si World doit vraiment être observé par tous les agents ou si une restriction aux Places n'est pas à envisager (étant donné que les Places peuvent diffuser aux agents).

Finalement je ne me pose pas tant de questions que ça. L'écrire éclaircit vraiment les choses

**behess** · 16/05/2008, 16h30

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
update(Event e)
{
  my_behavior.handle(e);
}

En fait ce qu'on comprend ici c'est que my_behavior est en quelque sorte un Behavior Propagateur.

Il faut que l'agent sache explicitement ce qu'est un Behavior Propagateur et qu'il affecte tout événement qu'il ne peut pas traiter à ce type de Behavior.

Il faut que l'agent teste le "type" de ses Behaviors jusqu'à trouver un Propagateur et lui envoyer l'Event.

D'ailleurs ça me fait me demander comment un Behavior va faire pour déléguer au bon EventHandlers qu'il possède ? Là aussi il va falloir qu'il passe en revue les EventHandlers jusqu'à en trouver un qui "match" !

Soit il faut passer par une énumération d'Event et chaque Event renverra son propre "numéro" en quelque sorte. Soit on passe directement par le type même de l'Event.

On peut imaginer devoir implémenter une méthode match(Event) dans le Handler de base qui testera lui même s'il reconnait l'Event, et une méthode match(Behavior) dans le Behavior de base qui testera lui même s'il se reconnaît.

RAPPELS :

pourquoi les BehaviorAgentHandler ?
parce que : peler(UnePomme) ≠ peler(UnAnanas)

pourquoi les EventHandler ?
parce que : peler ≠ couper

quel serait l'enchaînement du traitement d'un événement ?

Event
-> catchedBy EventHandler
-> translateInto Behavior
-> delegateTo BehaviorAgentHandler

En gros, l'agent dispose d'une batterie de Behaviors et d'une batterie d'EventHandlers.

Mais chaque EventHandler doit normalement catcher un seul Event et le traduire en Behavior. Pourquoi les Behaviors ne catcheraient pas directement les Events qu'ils comprennent ?

On aurait :

Event
-> notCatchedBy behavior1
-> catchedBy behavior2
-> delegateTo BehaviorAgentHandler

ou

Event
-> notCatchedBy previousBehaviors
-> finallyCatchedBy propagatorBehavior (le dernier de la chaine)
-> delegateTo BehaviorAgentHandler

Le problème c'est qu'on limite la possibilité qu'un Event s'adresse à plusieurs Behaviors selon ses paramètres ; dans la nouvelle situation un Event => un Behavior. A moins que le Behavior lui-même ne teste les paramètres de l'Event et le relâche s'ils ne matchent pas...

Qu'en penses-tu hed62 ?

**hed62** · 16/05/2008, 16h47

Dans mon bout de code, my_behavior était le premier maillon d'une chaine de responsabilité.

Ce premier maillon récupère l'évènement. Si ce 1er behavior peut traiter l'event, il le fait, sinon, il passe la main au behavior suivant.

Les behavior de propagation sont des behavior comme les autres, si ce n'est que dans leur code de traitement, ils font my_agent.my_observers.notify(e).

my_behavior est en quelque sorte un Behavior Propagateur.

Pas forcément, c'est juste le premier.

Il faut que l'agent sache explicitement ce qu'est un Behavior Propagateur et qu'il affecte tout événement qu'il ne peut pas traiter à ce type de Behavior.

Non pas, l'agent n'a que son premier behavior à connaitre. La chaine de responsabilité balaiera tous les behaviors. Si aucun ne réponds à l'appel, l'event est simplement ignoré. Pour propager un event de type E1, il faut un bahavior de propagation dans la chaine, qui traite les event E1.

Il faut que l'agent teste le "type" de ses Behaviors jusqu'à trouver un Propagateur et lui envoyer l'Event

A moins que l'agent possède plusieurs chaines de Behavior (ce qui est très possible), non.

D'ailleurs ça me fait me demander comment un Behavior va faire pour déléguer au bon EventHandlers qu'il possède ? Là aussi il va falloir qu'il passe en revue les EventHandlers jusqu'à en trouver un qui "match" !

Je pensais que Behavior = EventHandlers ...
Si ce n'est pas le cas, il faut prévoir un premier niveau de chaine de responsabilité (agent.chaineDeBehavior et behavior.chaineDHandlers)

On peut imaginer devoir implémenter une méthode match(Event) dans le Handler de base qui testera lui même s'il reconnait l'Event, et une méthode match(Behavior) dans le Behavior de base qui testera lui même s'il se reconnaît.

C'est le principe de chaine de responsabilité. Un maillon récupère l'event, le traite, ou pas, puis renvoie un booleen pour dire si les autres maillons doivent être contactés. Ce booleen peut servir de match(). Dès qu'un maillon renvoie false, c'est que le maillon a matché et "consommé l'event".

En gros, l'agent dispose d'une batterie de Behaviors et d'une batterie d'EventHandlers.

Ca me conforte dans l'idée de deux niveaux de chaines.

Mais chaque EventHandler doit normalement catcher un seul Event et le traduire en Behavior. Pourquoi les Behaviors ne catcheraient pas directement les Events qu'ils comprennent ?

La j'ai décroché

Pour moi, l'event transite ainsi : passe du monde à l'agent, de l'agent à la chaine de behavior, de la chaine de behavior aux handlers, pour etre géré par du code dans le handler, ce qui produira diverses actions (modification de l'agent, émission d'un aurte event...).

A moins que le Behavior lui-même ne teste les paramètres de l'Event et le relâche s'ils ne matchent pas...

On peut imaginer toutes sortes de tests dépendant des maillons.

Encore une fois, tous ces avis ne sont que mon point de vue, le tien a peut être évolué entre deux !

**behess** · 16/05/2008, 17h15

En fait tu me conforte dans l'idée exprimée en fin de message :

une chaine de Behaviors qui soient traitent l'Event s'il est reconnu, soit passe la main au prochain. Les propagateurs étant destinés à propager, il devraient se trouver en bout de chaine. Et du coup inutile pour l'agent de savoir ce qu'est un propagateur

En écrivant mon dernier message j'ai réalisé que je m'était compliqué en distinguant l'EventHandler du Behavior : un Behavior n'a pas de EventHandlers : un Behavior EST un EventHandler. La relation n'était pas la bonne en fait.

On est bien d'accord.

Par contre je verrais bien un Event générique embarquer un nom de Behavior (obtenu par un getAvailableRequests() sur l'agent lui-même ou sur un autre agent), plutôt qu'un Event pour chaque Behavior.

Chaque agent doit savoir ce qu'il peut demander à un autre ou ce qui est demandable (traduction néologique de "available request").

**hed62** · 16/05/2008, 18h59

Par contre je verrais bien un Event générique embarquer un nom de Behavior

L'event préciserai donc comment il est censé être interprété ?

plutôt qu'un Event pour chaque Behavior.

La bijonction entre les event et les behavior n'est pas acquise selon moi : un behavior peut comprendre plusieurs event, des event peuvent etre compris par les meme behavior, un event peut avoir plusieurs behavior qui le comprennent, ou aucun, etc...

Chaque agent doit savoir ce qu'il peut demander à un autre ou ce qui est demandable

Là ca dépend de ce que tu veux faire. Un agent doit t il demander par avance si le futur récepteur d'un message est à même de le comprendre? ou les agent emmettent ils un peu 'au hasard' ? De la même manière, ce genre de choses, je les verrais bien gérées par des behavior d'émission.

Ainsi, pour émettre un event, un agent passe par une chaine de behavior (dédiée à la tache). Selon l'event (demande d'augmentation ou insulte envers un esclave), l'agent prendra plus ou moins de précautions en envoyant le message, et l'émettra à des destinataires différents.

Finalement, l'agent devient une plateforme de routage d'event

. Les behavior se chargent de l'intégralité du comportement.

**behess** · 16/05/2008, 23h08

L'event préciserai donc comment il est censé être interprété ?

C'est l'idée oui. ça éviterait d'avoir toute une hiérarchie d'Events vides...

La bijonction entre les event et les behavior n'est pas acquise selon moi : un behavior peut comprendre plusieurs event, des event peuvent etre compris par les meme behavior, un event peut avoir plusieurs behavior qui le comprennent, ou aucun, etc...

Effectivement la bijection n'est pas évidente...

Le problème c'est qu'on limite la possibilité qu'un Event s'adresse à plusieurs Behaviors selon ses paramètres ; dans la nouvelle situation un Event => un Behavior. A moins que le Behavior lui-même ne teste les paramètres de l'Event et le relâche s'ils ne matchent pas...

Quand je me relie je me dis que tu n'as pas du y comprendre grand chose

Je voulais dire qu'avec la solution initiale un Event pouvait s'adresser à n'importe quel Behavior, ses paramètres pouvant éventuellement entrer en jeu dans la décision du Behavior de traiter l'Event.

Dans la solution 1 Event => 1 Behavior, le Behavior fera probablement un plus grand usage des paramètres annexes (Modalités évoquées précédemment).

Event :
- Requested Behavior = Me Donner Augmentation "10€/mois"
- Modalités : avec_politesse, à_son_patron

Event :
- Requested Behavior = Me Donner Argent "1 pièce ou un ticket resto"
- Modalités : avec_politesse, avec_insistance, aux_passants

Event :
- Requested Behavior = Esclave Dire Insulte
- Modalités : avec_énervement, avec_dédain

Qu'en dis-tu ?

**behess** · 19/05/2008, 16h50

Envoyé par behess

En écrivant mon dernier message j'ai réalisé que je m'était compliqué en distinguant l'EventHandler du Behavior : un Behavior n'a pas de EventHandlers : un Behavior EST un EventHandler. La relation n'était pas la bonne en fait.

Je reviens sur cela, en fait ce que j'avais voulu faire c'est extraire cette partie de l'agent afin qu'elle soit remplaçable par un autre EventHandler.

Imaginons que subitement je décide de changer la manière dont les agents doivent gérer les Events, avec cette solution (ou variation) il suffit d'écrire un nouveau EventHandler et de faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

agent.setEventHandler(monNouveauEventHandler);

Je n'aurai pas besoin de modifier mon agent de base lui-même.

Simplement dans mon schéma ce n'est pas ce qui ressort.

Il aurait fallu que je décrive une interface "EventHandlable" avec une méthode handle(Event); qui aurait été implémentée par un "BasicEventHandle".

L'agent devrait quant à lui disposer d'une méthode getChainedBehaviors() que le BasicEventHandle appellerait pour fournir l'Event à la chaine de Behaviors.

Ce serait plus extensible et maintenable comme ça non ?

**hed62** · 19/05/2008, 17h00

Je pense que tu cherche trop complexe... La chaine de responsabilité permet déjà de faire cela.

L'agent dispose d'une (liste) chaine de Behavior, capable ou non de traiter les Event. Si tu veux changer les capacités d'un Agent (notamment en cas d'apprentissage d'une faculté) il suffit d'ajouter une nouvelle instance d'un type de Behavior est de l'introduire dans la chaine.

Si la modification est plus radicale, tu change la chaine complete d'un coup.

C'est là la force de la composition sur l'héritage : on peut changer à l'exécution. Cet aspect ramène au DP Stratégie d'ailleurs (déjà potentiellement implémenté lors de l'usage de Chaine de reponsabilité).

Il aurait fallu que je décrive une interface "EventHandlable" avec une méthode handle(Event); qui aurait été implémentée par un "BasicEventHandle".

Tu en dispose déjà : interface = celle des Behavior; un Behavior peut traiter (handle) un Event, l'implémentation étant le corps du Behavior.

L'agent devrait quant à lui disposer d'une méthode getChainedBehaviors() que le BasicEventHandle appellerait pour fournir l'Event à la chaine de Behaviors.

L'agent connait le premier maillon de sa chaine de Behavior. Il suffit à l'agent de passer l'event à ce premier maillon, et c'est tout. Je ne vois pas d'interêt à ajouter une classe pour retirer cette responsabilité à l'agent. Peut être y en a t il mais je ne la trouve pas.

**behess** · 19/05/2008, 17h45

L'agent dispose d'une (liste) chaine de Behavior, capable ou non de traiter les Event. Si tu veux changer les capacités d'un Agent (notamment en cas d'apprentissage d'une faculté) il suffit d'ajouter une nouvelle instance d'un type de Behavior est de l'introduire dans la chaine.

L'idée que j'exprimais n'était pas de pouvoir changer les capacités d'un Agent, auquel cas il suffit bien de changer les Behaviors,

mais bien de permettre la modification de la manière dont il gérerait les Events.

Ce qui n'est pas tout à fait la même chose

**hed62** · 19/05/2008, 19h14

hum je comprend..

Effectivement, ce serait de changer : au lieu de passer par une chaine de responsabilité, passer par un autre mécanisme. Effectivement , cela peut être interressant.

Avant de mettre cela en place, je pense que tu devrais trouver juste un exemple de ce qui se ferait mal avec la chaine , et mieux avec n'importe quel autre mécanisme de ton choix, histoire de justifier la différence.

**behess** · 20/05/2008, 10h53

Il n'est pas possible de prévoir ce que les utilisateurs vont en faire, mais on peut imaginer un EventHandler qui filtrerait, selon un critère quelconque dépendant de l'Event ou d'autre chose non prévu ici, les Behabiors qui recevront l'Event

.

Tu n'as pas répondu à mon message #54 , qu'en dis-tu ?

**hed62** · 20/05/2008, 11h17

Tu permettrais donc à l'utilisateur de coder des eventhandler/d'autres choses ? ok, dans ce cas, oui.

pour le #54 : Personnellement je n'aime pas trop qu'un Event précise à l'avance le behavior qui est censer s'occuper de lui... Cela augmente le couplage entre les diverses classes, je ne trouve pas que ce soit de sa responsabilité de savoir ce genre de choses.

Imagine qu'un Event E1 lancé par A0 précise qu'il veuille être traité par un behavior B1, sur l'agent A1. Tout ce passe bien plusieurs fois. Ensuite A1 évolue, perd B1 et gagne B2, tout autant à même de traiter E1. Cela ne fonctionnera plus, et tu devras aller modifier sois E1, soit l'émetteur A0 pour prendre en compte cette modification. Il "verront" donc des choses qu'ils ne devraient pas voir.

En ce qui concerne les "modalités" dont ils feraient meilleur usage, je ne vois pas le gain dans la solution 'l'event précise son behavior'. En effet, les modalites peuvent être passés dans une hashmap par exemple. Un behavior adapté connait les clefs de la hashmap qui lui permmetront de récupérer les modalités spécifiques qui l'interresse. Que l'event connaisse ou non son behavior, cela importe peu. Toutefois, il faut qu'un Event donné introduise les modalités dans la hashmap toujours de la même manière.
Par exemple, si A0 envoie E1 avec comme map {"montant"=>10} et la fois suivante {"amount"=>100}, forcément cela ne fonctionnera pas.
Cela peut se contourner grâce à un héritage des Event, mais cela entrainerait trop de classes peu utiles (qui ne présenteraient que des getters sur les modalités). Décorateur pourrait il résoudre ca ?

...
...
intense reflexion et moult éditions du message
...

En fait non, pas vraiment... ca ne change pas le nombre de classes à entrer.

Conception d'un système multi-agent extensible

Design Patterns

Discussions similaires

Partager

Partager