IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Design Patterns Discussion :

Conception d'un système multi-agent extensible


Sujet :

Design Patterns

  1. #1
    Membre régulier
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    255
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 255
    Points : 99
    Points
    99
    Par défaut Conception d'un système multi-agent extensible
    Bonjour,

    je suis sur un problème de conception sur lequel j'hésite un peu.

    J'ai besoin de concevoir un modèle permettant une extensibilité totale.

    Par exemple :

    j'ai deux pommes, une granny smith et une golden.
    j'ai deux instruments : l'un qui découpe en rondelles et l'autre qui pèle les pommes.

    Seulement la découpe en rondelle ne fonctionne que sur les granny smith et le pelage que sur les golden.

    Comment modéliser cela ?

    Et si un jour je veux ajouter une nouvelle pomme et/ou un nouvel instrument, comment modéliser de manière à réduire au maximum l'impact sur l'existant (le réduire à zéro si possible) ?

    Basiquement je peux utiliser l'héritage :
    - une Granny est une Pomme, mais seules les granny ont une méthode
    decouperEnRondelles(),
    - une Golden est une Pomme, mais seules les golden ont une méthode peler(),

    Si on va plus loin on peut décider que les instruments seront modélisés comme des interfaces :
    - une Granny implémente l'interface iPeutEtreDecoupeeEnRondelles,
    - une Golden implémente l'interface iPeutEtrePelee.

    Mais si je veux rajouter une opération, je serais obligé de modifier les classes en conséquence pour ajouter une implémentation d'interface. Ce n'est donc pas une bonne solution.

    Je peux peut-être utiliser le DP "Strategie", mais ce DP evoque une seule strategie. Si je veux pouvoir doter mes Pommes de plusieurs opérations, il faut que je trouve un moyen de l'en doter effectivement mais aussi de "choisir" l'opération à effectuer :
    - je peux peut-être "ajouter" des stratégies à ma Pomme en associant chaque stratégie à une clé facilement identifiable comme "PELER" et utiliser simplement une méthode execute(eStrategie) ; rajouter une opération passerait par la modification de l'énumération et la création d'une classe stratégie.

    Mais là aussi je me pose une question : ne serait-il pas plus simple de passer par un fichier (XML?) de définition des relations entre les opération et les pommes.

    Il faudrait alors que les les opérations sachent décider si elles peuvent être utilisées sur telle ou telle pomme, via la lecture du fichier. Toutes les manipulations de Pomme devront alors passer par une série de méthodes "génériques" permettant de manipuler les attributs de la pomme (getProperty/setProperty).

    N'est-ce pas un peu compliqué ? Y a-t-il plus simple (genre réflexivité) ?

  2. #2
    Membre expert
    Avatar de TheLeadingEdge
    Inscrit en
    Mai 2005
    Messages
    1 199
    Détails du profil
    Informations forums :
    Inscription : Mai 2005
    Messages : 1 199
    Points : 3 100
    Points
    3 100
    Par défaut
    Seulement la découpe en rondelle ne fonctionne que sur les granny smith et le pelage que sur les golden.
    Essaie de te procurer le livre Design Patterns Head First. Tu devrais y trouver ton bonheur. Ca ne parle pas de pommes mais c'est avec des canards qu'ils ont ce genre de pb. Genre Canard qui vole, canard en bois, canard qui fait coin-coin, canard en plastique qui flotte mais qui vole pas et qui fait coin-coin etc...

  3. #3
    Membre régulier
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    255
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 255
    Points : 99
    Points
    99
    Par défaut
    Merci monsieur

    Je pense qu'il doit y avoir du DP tout prêt pour ça, mais si ça inspire quelqu'un qui a déjà eu la même problématique, je veux bien des conseils.

    Je vais me plonger dans ce bouquin déjà.

  4. #4
    Membre expert
    Avatar de hed62
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Juillet 2007
    Messages
    2 029
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2007
    Messages : 2 029
    Points : 3 134
    Points
    3 134
    Par défaut
    Essaie de rechercher "Patron de méthode", ca peut t'inspirer.
    Hervé Delannoy, Ingénieur études&développement.

    Je n'accepte pas les demandes de mise en relation MSN/yahoo sans motif.
    ------------------------------------------------------------------------
    Si , ni , ne peuvent vous aider, mais nous oui, pensez à un pti et au !
    Merci de vous relire
    ____________________________________________________________________________________
    Recherche joueurs de "Magic" sur Lille et environs.
    Donner plutôt que jeter.

  5. #5
    Membre régulier
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    255
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 255
    Points : 99
    Points
    99
    Par défaut
    Le DP "Template Method" c'est une idée associé notamment au DP "Strategy", mais ça ne permet pas forcément une extensibilité totale.

    Je pensais plutôt utiliser un système à messages, comme le DP "Command" ou le DP "Observer", encore que ce ne soit pas tout à fait aussi simple que ça.

    Je me suis dit qu'avec une IoD je pourrais "injecter" des "Strategy" à des objets basiques pour les "décorer" (DP "Decorator").

    Il faudrait peut-être que mes objets "sachent" ce qu'ils sont capables de faire, ils auraient donc une liste de stratégies à leur disposition et lors de la réception d'un événement, ils tenteraient un mise en relation ; une fois la bonne stratégie trouvée par rapport à l'événement reçu, il suffirait de fournir à la stratégie le contexte apporté par l'événement (comme une sorte de commande en fait).

    Ainsi, avec des objets de base je peux agrémenter l'application de comportements au fur et à mesure des besoins.

    Qu'en pensez-vous ?

  6. #6
    Membre régulier
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    255
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 255
    Points : 99
    Points
    99
    Par défaut
    En cherchant encore un peu j'ai trouvé un article vraiment pas mal :

    http://pcaboche.developpez.com/artic...?page=sommaire

    Je pense qu'il contient pas mal d'infos qui vont bien m'être utiles.

  7. #7
    Membre régulier
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    255
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 255
    Points : 99
    Points
    99
    Par défaut
    Le DP "Visitor" pourrait également être utilisé, mais le problème c'est qu'il faut prévoir une méthode pour tous les objets à visiter.

    Or si on ajouter un objet à la hiérarchie d'objets, mes Visitors ne sauront pas le traiter... il faudra alors tous les modifier et les recompiler.

    Je pense qu'il faut que je combine le DP "Visitor" avec le DP "Strategy" et le DP "IoC" :


    Un Visitor serait Fabriqué selon un descripteur externe (Xml) en lui injectant (IoC) les Strategies (opérations similaires sur différentes Classes, un peu comme du polymorphisme paramétrique dynamique) qui vont bien. C'est un peu une Décoration de Visitor avec des Strategies, non ?

    Ici c'est le Visitor qui saurait sur quels objets il peut effectuer son traitement.

    Lors d'un "contact" entre deux objets (on parlera d'événement), l'émetteur de l'événement applique un Visitor sur le receveur. Si le Visitor sait traiter le receveur, alors il effectue le traitement, sinon il renvoit une erreur.

    Est-ce une approche "valide" ?
    Si oui comment procéder lors de l'implémentation ? (ex : en java).
    -> notamment pour que le Visitor "sache" quels objets il peut traiter (ie. de quels stratégies il dispose et comment les lui faire appliquer).

    A ce sujet je me dis qu'il faudrait peut-être "injecter" des Classes Stratégie dans le Visitor plutôt que des objets. Ce serait au visitor d'instancier ses stratégies selon les événements.

    Mais comment savoir si une stratégie (Classe) donnée peut traiter un type d'objet (Classe) donné ?

    Il faudrait que les classes soient instanciées puis que la méthode execute soit tentée sur l'objet à traiter pour voir s'il est rejeté ou pas ? C'est un peu lourd je trouve, non ?

  8. #8
    Membre expert
    Avatar de hed62
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Juillet 2007
    Messages
    2 029
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2007
    Messages : 2 029
    Points : 3 134
    Points
    3 134
    Par défaut
    Plutôt que Visitor, Chaine de responsabilité est plus adapté pour parcourir une collection et effectuer un traitement adapté.
    Hervé Delannoy, Ingénieur études&développement.

    Je n'accepte pas les demandes de mise en relation MSN/yahoo sans motif.
    ------------------------------------------------------------------------
    Si , ni , ne peuvent vous aider, mais nous oui, pensez à un pti et au !
    Merci de vous relire
    ____________________________________________________________________________________
    Recherche joueurs de "Magic" sur Lille et environs.
    Donner plutôt que jeter.

  9. #9
    Membre régulier
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    255
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 255
    Points : 99
    Points
    99
    Par défaut
    J'ai cherché une définition de ce DP "Chain of Responsibility".

    Il est basé sur des Handlers qui disposent d'une méthode handleRequest et qu'il faut initialiser avec un successeur (c'est donc réellement une chaîne, pour les parcours complets c'est l'idéal).

    Il faut que chaque Handler sache pour quel type d'objet il est prévu : comment peut-il savoir cela ? Si je prévois une méthode qui prend en paramètre un type d'objet particulier, je ne pourrais pas lui appliquer n'importe quel objet et le compilateur va probablement me crier dessus !

    Ou alors la méthode doit accepter n'importe quel objet et tester son type.
    Y a-t-il une autre solution ?

  10. #10
    Membre expert
    Avatar de hed62
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Juillet 2007
    Messages
    2 029
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2007
    Messages : 2 029
    Points : 3 134
    Points
    3 134
    Par défaut
    Je ne pense pas qu'un système puisse être ouvert à 100%... Il faut forcément faire des coupes, sinon on se retrouve à vouloir trop gérer, et
    1/ les performances en patissent
    2/ le développement se ralonge considérablement, parfois pour rien
    3/ on ne suis pas le principe "fais le. Fais le marcher. Fais le marcher bien. Fais le mieux." (contestable mais ca résume)
    4/ Tu va prévoir des choses qui n'arriveront jamais. On parle souvent de réutilisabilité. Mais du code ne peut être qualifié de réutilisable/extensible que si il a été réutilisé/étendu.

    Quoi qu'il en soit, cela reste un sujet passionnant ^^
    Hervé Delannoy, Ingénieur études&développement.

    Je n'accepte pas les demandes de mise en relation MSN/yahoo sans motif.
    ------------------------------------------------------------------------
    Si , ni , ne peuvent vous aider, mais nous oui, pensez à un pti et au !
    Merci de vous relire
    ____________________________________________________________________________________
    Recherche joueurs de "Magic" sur Lille et environs.
    Donner plutôt que jeter.

  11. #11
    Membre régulier
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    255
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 255
    Points : 99
    Points
    99
    Par défaut
    J'ai réellement besoin de cette extensibilité. Ce n'est pas une lubie

    C'est en fait pour réaliser un système multi-agents...

    Je veux que l'application soit une base configurable pour des gens qui ne savent pas forcément programmer, mais qui savent décrire (fichier de configuration) les agents.

    Les modules doivent pouvoir être combinés différemment selon les clients.

    Evidemment il restera toujours quelques objets à étendre par la hiérarchie classique, mais globalement je veux qu'il y en ait le moins possible.

    EDIT : j'ai supprimé l'image de l'ébauche.

  12. #12
    Membre confirmé

    Homme Profil pro
    Inscrit en
    Août 2006
    Messages
    317
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Août 2006
    Messages : 317
    Points : 597
    Points
    597
    Par défaut
    Je vois 2 étapes pour l'extension et pas une seule :
    - nouvelle fonctionnalité independante
    - fonctionnalités ou donnée composés

    1 fonctionnalité independante n'a pas besoin d'interagir avec d'autres extensions.
    1 composition de fonctionnalité et de donnée se font à l'interieur d'une fonctionnalité independante.

    Deja une fabrique me parait un point de depart pour la modularité.
    Tu vas en fonction du nom du parametre chercher un fichier et charger la class a l interieur.
    Un exemple de codage serait :
    PrefixeProg_NomClass

    Pour etendre ton systeme, 1 methode est : l'observer. Je rajoute a l'objet observable initial la class que tu viens d'instancier. (Extension de nouvelles fonctionnalités independantes).
    Pour l'observer, la methode d'appelle doit etre commune à toutes les classes de configuration (non problematique si tes fonctionnalités sont independantes)

    On a besoin d'une nouvelle fabrique pour etendre les objets observers.

    Le passage des données initiales à l'observer doit se faire a partir de la fabrique.

    Pour finir, il te reste à pouvoir composé les fonctionnalités (ça depend de ce que tes utilisateurs vont specifier). Ils peuvent specifier des fonctionnalités ou un comportement, dans ce cas, il faut faire appel à des decorateurs.
    Si ils specifient des combinaisons de données, ca sera un simple pattern composite.

    Ton systeme sera la parfaitement extensible. Seulement le codage des extensions devra suivre une methode tres particuliere et parfaitement codifié.

    Apres tes utilisateurs pourront coder des fichiers textes plus simples (XML ou autre specification) qui feront appel à ce systeme

  13. #13
    Membre régulier
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    255
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 255
    Points : 99
    Points
    99
    Par défaut
    Tu me parles d'une extensibilité "à chaud" si je ne m'abuse...

    En gros : on a un système qui tourne et on veut "pluguer" une fonctionnalité en cours de route ?

    Sinon je comprends pas l'intérêt de l'observer :

    Moi je parle d'une extensibilité "à froid" ; si tu as un système de descripteur Xml, un simple arrêt/relance de ton système te permet de recharger les nouvelles fonctionnalités !

    Par contre si c'est bien pour un plugin à chaud, ça m'intéresse aussi et là j'ai envie de dire : sois plus clair, détaille coco

    Merci quand même.

  14. #14
    Membre confirmé

    Homme Profil pro
    Inscrit en
    Août 2006
    Messages
    317
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Août 2006
    Messages : 317
    Points : 597
    Points
    597
    Par défaut
    --------------------------------------------------------------------------------

    Je parlais pour un systeme a froid mais j'avais mal compris ta demande.

    Dans ton cas, je retire le decorateur mais je laisse l'observer qui est la base.

    l'observer repondant va repondre a un etat de l'objet maitre.
    Ma pomme possede un etat. Je souhaite decouper ma pomme cette etat passe à decouper

    J'appelle mes observers et je leur dis changement d'etat. Les observers regarde l'etat et decide de reagir ou non. Si l'etat est decouper pomme, seul l'observer decouper reagira a cet etat, les autres ne feront rien.
    Si ma pomme n'a pas d'observer decouper et ben il se passera rien pour elle (execution d'un observer defaut qui renverra une exception: "methode non connu")

    l'observable : la pomme
    l'observer : l'instrument

    Le message entre les 2 : mettre a jour mon etat.

    L'usage du decorateur est seulement si tes instruments sont factorisables.

    (je reposte la, car tu avais deja donne une reponse avant que je modifie mon message et tu risquais de ne pas le voir)

  15. #15
    Membre régulier
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    255
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 255
    Points : 99
    Points
    99
    Par défaut
    Je comprends mieux

    Merci pour la précision !

    Je vais réfléchir à cela par rapport à mon schéma actuel, je ne vois pas encore bien où et comment ça peut s'insérer.

    Pour mémoire DP Observer :



    et DP IoC :


  16. #16
    Membre confirmé

    Homme Profil pro
    Inscrit en
    Août 2006
    Messages
    317
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Août 2006
    Messages : 317
    Points : 597
    Points
    597
    Par défaut
    Si je peux dire une petite chose sur ton shéma, il lie un observer à un sujet par une association unidirectionnelle (ac 2 class abstraites qui peuvent a la rigueur etre mis à part pour faciliter la vue d'ensemble)

    Seulement pour l'observer, il me semble que l'on a dans le sujet (observable) un attribut qui enregistre l'ensemble des observers. J'aurai donc plutot mis une relation d'agrégation.

    Par contre, je ne comprends pas tes 2 autres shémas ???

  17. #17
    Membre régulier
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    255
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 255
    Points : 99
    Points
    99
    Par défaut
    La relation Sujet->Observer est clairement une relation d'agrégation dans un cas concret. C'est ici un diagramme abstrait de Pattern...


    Le second schéma est le pattern IoC, simplement pour mémoire.

  18. #18
    Membre expert
    Avatar de hed62
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Juillet 2007
    Messages
    2 029
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2007
    Messages : 2 029
    Points : 3 134
    Points
    3 134
    Par défaut
    Ma pomme possede un etat. Je souhaite decouper ma pomme cette etat passe à decouper
    Ceci correspondrai au pattern state...

    J'appelle mes observers et je leur dis changement d'etat
    ... couplé à observer/observed ...

    Les observers regarde l'etat et decide de reagir ou non
    ... ca commence à coincer : si plusieurs observer : ils doivent être indépendant, au mieux, un seul observer par type d'évènement. Du coup observer n'est plus très adapté, il suffit d'une hashmap{Event->Handler}.
    Ou autre l'observer, unique(!?) est la racine d'une chaine de responsabilité, qui assure la prise en charge des modifs.

    Si ma pomme n'a pas d'observer decouper et ben il se passera rien pour elle
    Aie... On a basculé son état au tout début. Donc il faut juste faire une "demande de changement d'état", le handler concerné, s'il existe, effectue réellement le changement.

    Les trois parties sensibles de toute cette histoire, selon moi :

    - L'instanciation des objets (les pommes...) : relève d'une Factory AgentFactory, qui se débrouille comme elle veut pour instancier des Agents, dont les paramètres peuvent être données par une base de données (xml ou autre) AgentData, et dont le code peut effectivement être obtenu par introspection dynamique d'une DLL (ou autre compilation). En cas d'ajout d'Agent, on code une nouvelle classe, on compile, on écrase la DLL (ou autre), on ajoute une ligne dans le fichier XML (ou autre) décrivant la liste des agents disponibles AgentTypesAvailable. Coté application, la AgentFactory lit ce XML, en déduit la liste des classes d'agents dispo, et pour instancier utilise l'introspection et le chargement dynamique ; les paramètres sont passés grâce à la base des paramètres AgentData, ou par remplissage d'un formulaire de saisie.

    - L'interception des Evenement par l'Agent:
    La classe Agent de base emploie le pattern State, et à la construction, on instancie une Chaine de Responsabilité (en fonction des paramètres et d'une 3e source de données AgentHandlers). Une seconde Factory voit donc le jour : HandlerFactory (principe identique à AgentFactory). Lors d'un Evenement reçu par un Agent, cet agent délégue au 1er maillon de sa Chaine. Si l'Evenement peut être traité, il l'est, l'Etat est mis à joue ou pas, sinon, rien ne se passe.

    - La gestion des Evenements :
    Pour la communication :
    Soit on emploie une classe Monde, que tous les Agents observent, et sur laquelle chaque Agent peut appeler une méthode pour déclencher un evenement. Auquel cas tout le monde sait tout et peut tout dire (on peut poser des restrictions par la suite).
    Soit les Agent s'écoutent entre eux selon des règles à définir (proximité, abonnement, ...)
    Pour l'instanciation des Evenement :
    On peut potentiellement creer de nouveaux Event de la même manière que les Agents et les Handlers. Finalement un Evenement "n'est qu'un" type enuméré, donc un fichier XML EventTypesAvailable peut en dresser la liste. La classe Event de base permet de passer en plus à la construction un object (qui peut être aussi complexe que voulu). A charge ensuite aux Handlers qui le captent de savoir naviguer dans ce paramètre, par introspection ou autre (si on passe une hashmap au lieu d'un objet, la simple connaissance des clefs suffit).


    Plus j'en parle, plus ca m'interresse
    As tu envisagé les algorithmes génétiques pour ce projet ?
    Hervé Delannoy, Ingénieur études&développement.

    Je n'accepte pas les demandes de mise en relation MSN/yahoo sans motif.
    ------------------------------------------------------------------------
    Si , ni , ne peuvent vous aider, mais nous oui, pensez à un pti et au !
    Merci de vous relire
    ____________________________________________________________________________________
    Recherche joueurs de "Magic" sur Lille et environs.
    Donner plutôt que jeter.

  19. #19
    Membre régulier
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    255
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 255
    Points : 99
    Points
    99
    Par défaut
    en réponse à hed62 :

    Conception :

    Mon schéma partait effectivement sur ce principe là.

    En l'occurence, ce que tu nommes Event est sur mon schéma transmis par une référence à un Behavior d'un objet "intermédiaire" (tool), empaqueté dans une "requête d'action" (qui peut être vu comme un Event donc).

    L'intermédiaire pouvant être le même Agent que l'émetteur de l'événement (il s'utilise lui même pour agir).

    Chaque Agent (je vais finir par refaire mon schéma en changeant Thing par Agent, c'est plus parlant) peut embarquer plusieurs Behavior ("comportement" pour les anglophobes) et chaque Behavior sera doté d'un Handler par "cible" de ce comportement.

    Evidemment si toute la hiérarchie des Agents est concernée par le Behavior, le seul handler à créer est celui qui s'applique à la classe de base.

    Les handlers sont donc enfilés les uns à la suite des autres. Quand un handler ne sait pas traiter le receveur (si ce n'est pas SA "cible"), il passe à son successeur.
    Ici pour déterminer si le handler sait traiter la cible, je ne vois qu'une seule possibilité : tester son type...

    Je vois déjà quelques possibilités de modifications :
    - les handlers pourraient être des handlers "négatifs", c'est à dire qu'ils intercepteraient les "cibles" qui ne sont pas concernés par le Behavior et qui donc le feraient "échouer". Ils devraient donc être placés au début de la chaine de responsabilité,
    - les handlers ne devraient pas être cumulatifs, mais ils pourraient être spécialisés : s'il y a à la fois un handler pour une cible "de base" et pour une cible "fille" (sauf cibles d'exception), il faudrait que la cible la plus spécialisée soit déclarée en premier.

    Les handlers devraient donc être placés comme cela :
    *NEGATIFS>SPECIALISES>GENERIQUES

    Pour ce qui est de l'énumération d'Events, en fait je ne suis pas sûr qu'elle soit nécessaire : les événements étant des utilisations de Behavior, il suffit aux agent d'accéder aux behaviors (par un getBehaviors) pour obtenir la liste des actions possibles.

    Je vois bien un Monde découpé en Parcelles. Chaque parcelle verrait ses voisines et serait chargée de gérer les agents qui y agissent. En cas d'action de zone, la parcelle serait chargée de transmettre aux agents qu'elle gère et aux parcelles qu'elle connait et qui sont dans la zone, et ainsi de suite par propagation.

    Algo génétique :

    Wow là c'est du lourd

    Non je n'ai pas pensé aux algorithmes génétiques car pour le moment je n'ai pas envisagé de donner la possibilité à mes agents de se reproduire ou d'évoluer d'eux-mêmes.

    Mais c'est une idée qui va être mise de côté pour la V2 sois-en sûr.

  20. #20
    Membre expert
    Avatar de hed62
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Juillet 2007
    Messages
    2 029
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2007
    Messages : 2 029
    Points : 3 134
    Points
    3 134
    Par défaut
    Ici pour déterminer si le handler sait traiter la cible, je ne vois qu'une seule possibilité : tester son type...

    Cela ne me gêne nullement, et c'est très généralisable dans la classe de base.

    Les handlers devraient donc être placés comme cela :
    *NEGATIFS>SPECIALISES>GENERIQUES
    Effectivement

    Pour ce qui est de l'énumération d'Events, en fait je ne suis pas sûr qu'elle soit nécessaire
    Si, tout de même, car ce n'est pas parceque le Behavior n'en tient pas compte que l'Event ne peut exister et être lancé. Un Agent "Autiste" peut déclencher des Event qu'il serait incapable d'intercepter par ailleurs si un autre Agent l'envoyait.

    Je vois bien un Monde découpé en Parcelles.
    C'est une des façons de restreindre. Pour une V1 je te conseille de n'avoir qu'une Parcelle.

    Wow là c'est du lourd
    Pas forcément, au vu de ce que tu es en train d'essayer de faire
    Si tu as des questions là dessus...

    Ton projet m'interresse bien, en quel langage est/sera il développé ?
    Hervé Delannoy, Ingénieur études&développement.

    Je n'accepte pas les demandes de mise en relation MSN/yahoo sans motif.
    ------------------------------------------------------------------------
    Si , ni , ne peuvent vous aider, mais nous oui, pensez à un pti et au !
    Merci de vous relire
    ____________________________________________________________________________________
    Recherche joueurs de "Magic" sur Lille et environs.
    Donner plutôt que jeter.

Discussions similaires

  1. Programmer un système multi-agent
    Par elalia dans le forum Programmation par agent
    Réponses: 10
    Dernier message: 29/04/2011, 12h22
  2. [IA] Systèmes multi-agents et jeux vidéos simples ?
    Par progfou dans le forum Intelligence artificielle
    Réponses: 4
    Dernier message: 04/03/2011, 20h18
  3. Système multi agents en Delphi
    Par Promeneur dans le forum Delphi
    Réponses: 7
    Dernier message: 08/11/2006, 18h03
  4. Système multi agents
    Par Promeneur dans le forum Algorithmes et structures de données
    Réponses: 8
    Dernier message: 05/11/2006, 02h22
  5. Les Système Multi-agent avec Java
    Par oussam dans le forum Langage
    Réponses: 1
    Dernier message: 09/02/2006, 01h41

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo