Discussion :

[behess]

C'est très intéressant tout ça.

Je suis finalement d'accord avec ton argument à propos de l'évolution du Behavior qui pourra traiter le même Event que son prédécesseur.

Behavior aurait une méthode handle(Event) qui renverrait false par défaut.
Les sous-classes de Behavior surchargerait cette méthode avec les Events acceptés. Il faut donc une hiérarchie d'Events et une hiérarchie de Behaviors distincts.

L'autre solution est de faire une énumération d'événements. Si les sous-classes d'Event n'ont pas besoin de définir des nouveaux comportements, c'est aussi envisageable, même si c'est moins élégant.

[hed62]

Ce n'est pas forcément moins élégant, et quitte à faire une énumération, je vois très bien une classe <<enum>> EventType.
Ensuite vient une agrégation : Event a un TypeEvent.

Dans la classe mère des Behavior, je suggère le DP "Patron de méthode". Il sera minimaliste ici, mais utile tout de même. Je m'explique, cette classe mère behavior possède 1 collection de EventType, 3 méthodes surchargeables, qui sont :

- void initEventToHandle() // renseigne la collection de EventType
- bool isEventToHandle(Event e) // dit si e est à traiter. "return collection.contains(e.type)" par défaut
- void handle(Event e) // Effectue le traitement sur e. Corps vide (non abstract) dans la classe mère Behavior

Et une non surchargeable (à voir)
- bool receive(Event e) // code = if isEventToHandle(e) then handle(e)

Ainsi, seule handle(e) est à redéfinir à chaque fois, pas les tests validant les event. Les cas particuliers peuvent surcharger isEventToHandle pour tout prendre/ne rien prendre / tester plus finement.

J'ai dit receive en non surchargeable, mais finalement... pourquoi pas...

[behess]

3 méthodes surchargeables,

Pourquoi surchargeable ? tu veux dire redéfinissables (sous-entendu dans les sous-classes) ?

La surcharge serait intéressant si on avait une hiérarchie d'Events, c'est la manière élégante de traiter différents types d'Events :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
Behavior {
  // par défaut aucun Event n'est reconnu
  boolean handle(Event){ return false; }
}

Remercier extends Behavior {
  boolean handle(FaireUnCadeauEvent){return true;}
  boolean handle(RemunererEvent){return true;}
  boolean handle(DireMerciEvent){return true;}
}

[hed62]

tu veux dire redéfinissables (sous-entendu dans les sous-classes) ?

Tout à fait.

hiérarchie d'Events,

Pourquoi une hiérarchie ? Suivant le principe qui dit "privilégier la composition à l'héritage", j'ai parlé du TypeEvent. Plutôt que trois méthodes dans Remercier, tu aurais un

Code java :

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

1
2
3
4
5
6
 
handle(Event e)
if e.type == TypeEvent.FaireUnCadeauEvent
return true;
if e.type == TypeEvent.RemunererEvent
return true;

dans RemercierBehavior

En poussant plus loin l'utilisation des TypeEvent et voyant qu'il serait lourd de faire des if partout, j'ai mentionné la collection de TypeEvent représentant les Event à gérer.

Ainsi, Event devient :

Code java :

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

1
2
 
class Event  public TypeEvent type;

Behavior :

Code java :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
class Behavior 
  public List<TypeEvent> AGerer; 
 
  public void initEventToHandle()  
    AGerer = new ...;  
 
  public bool isEventToHandle(Event e)  
    return AGerer.Contains(e.type); 
 
  public void handle(Event e) 
  {} 
 
  public receive(Event e) 
    if(isEventToHandle(e)) 
      handle(e)

RemercierBehavior :

Code java :

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

1
2
3
4
5
6
7
8
9
 
class Remercier extends Behavior 
  public void initEventToHandle()  
    AGerer = new ...; 
    AGerer.add(TypeEvent.FaireUnCadeauEvent); 
    AGerer.add(TypeEvent.RemunererEvent); 
 
  public handle(Event e) 
    // dire merci à e.sender par exemple.

[behess]

privilégier la composition à l'héritage

J'avais bien compris. Simplement je disais que surcharger une méthode avec différents type d'Events est plus élégant qu'une suite de "if" testant le type d'un Event.

Il est certains cas où l'héritage est peut-être plus adapté que la composition, notamment quand on est amené à tester le "type" d'objet.

Cependant je ne dis pas que la solution passant par la composition est mauvaise... il faut juste bien réfléchir aux avantages que ça peut procurer par rapport à la solution "naturelle" en POO.

[hed62]

Simplement je disais que surcharger une méthode avec différents type d'Events est plus élégant qu'une suite de "if" testant le type d'un Event.

Ah oui tout à fait d'accord. D'où la solution intermediaire d'une collection. La méthode devient générique et partagé par tous les Behavior (
c'est le contains(e.type) )

Il est certains cas où l'héritage est peut-être plus adapté que la composition,

Absolument, comme tu le dit, le polymorphisme a ses intérêts.

il faut juste bien réfléchir aux avantages que ça peut procurer par rapport à la solution "naturelle" en POO.

Le principal avantage de l'usage des la collection de TypeEvent est de ne pas avoir de multiplication soit des méthodes handle qui risquent d'avoir un code similaire, soit de "if(e.type==X)" , c'est pareil.
D'autre part, la hiérarchie d'Event permet d'introduire des données spécifiques à chaque Event.
Par opposition, cette même hiérarchie impose un foisonnement de classes, au risque de s'y perdre en maintenance/développement.
Enfin, si un Event possède une hashmap de données, la hiérarchie n'apporte "plus que" les getters adaptés et certaines méthodes éventuelles.

Ma balance personnelle penche vers la création du type énuméré géré par collection, mais j'ai peut être des oeillères m'empéchant de voir d'autres avantages...

A toi de juger et trancher, je ne suis là que pour donner mon avis

[behess]

la hiérarchie d'Event permet d'introduire des données spécifiques à chaque Event

C'est la démarche que j'avais initié avec les modalités d'un Event générique... donc sans méthodes spécifiques... mais c'est peut-être plus simple de mettre ça directement dans les Event.

cette même hiérarchie impose un foisonnement de classes, au risque de s'y perdre en maintenance/développement

C'était ma crainte au départ. Mais si on reporte les propriétés des Events dans les modalités ça fera aussi beaucoup de classes. Les modalités pourront être partagés entre des Events n'ayant rien à voir les uns avec les autres ; là je vois un avantage à ne pas utiliser une hierarchie.

si un Event possède une hashmap de données, la hiérarchie n'apporte "plus que" les getters adaptés et certaines méthodes éventuelles

cf. ma remarque sur les modalités ; qui peuvent être stockées à l'aide d'une hashmap ou autre.

Ma balance personnelle penche vers la création du type énuméré géré par collection

Je pense finalement que c'est peut-être préférable.

Il vaut sans doute mieux recentrer les spécificités des Events au niveau des modalités et pouvoir ainsi les utiliser pour différents Events.

Chaque type d'Event devra être pourvu des modalités qui vont bien.

Lorsqu'un Behavior traitera cet Event, il demandera telle ou telle Modalité et saura que telle Modalité a la propriété truc et saura quoi en faire.

Et le petit plus c'est qu'au besoin je peux prévoir des méthodes spécifiques à la Modalité.

[behess]

Je place en PJ un autre diagramme, plus complet.

Il reprend les différents éléments de nos discutions de manière plus ou moins habile.

Merci de critiquer ce schéma au besoin pour m'aider à le parfaire.

Il faudrait probablement que je le scinde car il commence à être un peu énorme (euphémisme volontaire ).

[hed62]

Me revoila (enfin)

Je te proposerai d'utiliser les drawing settings de bouml pour clarifier le diagramme.

J'ai du mal avec le core::Event.getLastEmitter , enfin surtout le type de la méthode : Agentoid... Il n'y a nulle relation entre les deux.

Un AgentSpecificBehavior ne peut throw qu'un event ?
Pourquoi l'interface core::Behavior hérite de Chainable ? Où est l'intérêt je veux dire ?

A propos de BasicEventHandle : tu ne le masque pas de suite dans une chaine ? tu gardes cela pour une prochaine évolution ?

Je comprend bien le principe de MeetingRemeberance. Mais que fait le Behavior associé ici ? C'est volontaire pour le diagramme ?

Un Inhabitant n'a qu'un parent ?

Si le SetOfPlaces a pour clef les directions, pourquoi ne pas avoir un type énuméré Direction ?

Voila c'est tout pour le moment

Où en es tu de ton projet ?

[behess]

Me revoila (enfin)

Nous sommes tous occupés, pas de problème

Je te proposerai d'utiliser les drawing settings de bouml pour clarifier le diagramme.

C'est à dire ? C'est mon premier vrai diagramme, alors je suis un peu brouillon peut-être Je me dis qu'il faudrait sûrement scinder ça en plusieurs diagrammes, mais je ne sais pas où couper...

J'ai du mal avec le core::Event.getLastEmitter , enfin surtout le type de la méthode : Agentoid... Il n'y a nulle relation entre les deux.

Effectivement il manque les méthodes relatives à l'affectation des Agentoid...

1°) Je n'ai pas dessiné de relation car elle est indirecte (elle passe par le Behavior)

2°) le constructeur devrait prendre en paramètre un Agentoid comme "Emitter" : « Event(Agentoid emitter, Modality modality) » ou un truc dans ce genre

3°) il faudrait probablement une méthode « addNewEmitter(Agentoid emitter) » lors des renvois d'événement

Un AgentSpecificBehavior ne peut throw qu'un event ?

Oui alors là j'ai peut-être un problème avec les multiplicités... mais je me disais qu'à un instant t, un AgentSpecificBehavior de lance qu'un seul événement ; c'est plus une relation descriptive qui ne correspond pas à une méthode en particulier (c'est une relation abstraite en quelque sorte, je ne sais pas comment noter ça). Il faut y voir les méthodes de notification des interfaces du pattern Observer...

Pourquoi l'interface core::Behavior hérite de Chainable ? Où est l'intérêt je veux dire ?

En fait je voulais "mutualiser" l'interface Chainable en utilisant la généricité.
Avec BOUML on peut afficher l'instanciation d'une généricité avec la relation "realize", mais pas avec la relation "generalize". Or l'interface Chainable étant utilisée par des interfaces, il n'est pas possible de l'implémenter, elle ne peut être qu'étendue par ces interfaces.

A propos de BasicEventHandle : tu ne le masque pas de suite dans une chaine ? tu gardes cela pour une prochaine évolution ?

Euh, nan !
Je m'ai trompé Je dois changer la relation et associer le Behavior avec le BasicEventHandler.

Merci d'avoir mis le doigt dessus, je n'avais pas fait gaffe

Je comprend bien le principe de MeetingRemeberance. Mais que fait le Behavior associé ici ? C'est volontaire pour le diagramme ?

Tout simplement : j'ai pensé qu'il valait mieux faire de cette capacité un Behavior...

Un Inhabitant n'a qu'un parent ?

A priori oui. Ici parent n'a pas le sens de "papa, maman", mais plutôt le propriétaire de l'agent. Une relation "humaine" n'est pas modélisée ici.

Remarque il serait possible de généraliser la relation et spécifier dans celle-ci le type de relation dont il s'agit (ex : "PROPRIETAIRE", "PAPA", "MAMAN", "FRERE"), c'est à méditer.

Si le SetOfPlaces a pour clef les directions, pourquoi ne pas avoir un type énuméré Direction ?

En fait on pourrait ainsi y mettre ce qu'on veut.
Il suffirait de se créer son propre type énuméré ayant sa sémantique propre qui serait automatiquement "casté" en String. Ainsi on peut modéliser autre chose des Places "directionnelles" (ex : des places "introspectives" : "INDOOR" "OUTDOOR", etc).

Voila c'est tout pour le moment

Et c'est déjà beaucoup !!!! Merci à toi pour toutes ces remarques N'hésites pas à rebondir si tu n'es pas d'accord ou si tu as une autre idée sur ces questions (ou d'autres).

Où en es tu de ton projet ?

Je médite... car je viens de terminer une première lecture du livre sur les DP

[hed62]

C'est à dire ?

Je voyais deux "dessins" : un simple et un complet. Cela peut facilement se faire via les drawing settings de BoUML (clic droit dans le "blanc" => edit drawing settings)

Ca permetrait de "plonger" plus vite

1°) Je n'ai pas dessiné de relation car elle est indirecte (elle passe par le Behavior)

:/ à mon avis tu devrais alors revoir tes relations, enfin surtout leur navigabilité. Car là un Event ne connais pas de Behavior (normal selon moi). Mais si le Behavior "donne" l'Agentoid à l'Event (comme je le pense) alors il doit y avoir une relation entre Event et Agentoid.

2°) le constructeur devrait prendre en paramètre un Agentoid comme "Emitter" : « Event(Agentoid emitter, Modality modality) » ou un truc dans ce genre

C'est ce genre de choses qu'on peut masquer/afficher entre les deux dessins dont je parlais plus haut.

mais je me disais qu'à un instant t, un AgentSpecificBehavior de lance qu'un seul événement

Un DC est une vue statique, non dynamique. Il faut donc voir dans la globalité. Un AgentSpecificBehavior est il lié, ou non, à un, ou plusieurs, Event ?

Une relation de type <<uses>> serait peut être suffisante. (Quitte à définir ton stéréotype <<emits>>, ou encore utiliser le <<creates>>)

En fait je voulais "mutualiser" l'interface Chainable

Pourquoi le Behavior devrait être Chainable ? Que l'AgentSpecificBehavior soit chainable n'est pas suffisant ?

Avec BOUML ...

A voir sur le forum BoUML surement.

j'ai pensé qu'il valait mieux faire de cette capacité un Behavior

Oui, je n'en doute pas, je voulais dire, pourquoi est il "dessiné" là ? tout isolé alors que les behavior sont en haut à droite ?

Remarque il serait possible de généraliser la relation et spécifier dans celle-ci le type de relation dont il s'agit (ex : "PROPRIETAIRE", "PAPA", "MAMAN", "FRERE"), c'est à méditer.

Donc ce serait plutôt une relation nommée "Relations" avec une classe d'association enumérée RelationType, cardinalités *. Ca me va (et comme ca les Agent peuvent avoir des "Copains" aussi.

Je médite... car je viens de terminer une première lecture du livre sur les DP

Ca change souvent notre vision

Bon courage!

[behess]

Je voyais deux "dessins" : un simple et un complet. Cela peut facilement se faire via les drawing settings de BoUML (clic droit dans le "blanc" => edit drawing settings)

Ca permetrait de "plonger" plus vite

Ah oui, ok, tu proposes que je duplique le dessin et que j'enlève certaines choses comme les opérations, c'est ça ?

:/ à mon avis tu devrais alors revoir tes relations, enfin surtout leur navigabilité. Car là un Event ne connais pas de Behavior (normal selon moi). Mais si le Behavior "donne" l'Agentoid à l'Event (comme je le pense) alors il doit y avoir une relation entre Event et Agentoid.

Genre :

Code :

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

1
2
3
4
             transmitFor
Event <>----------------- (1,0) Agentoid
                             emitters

Un DC est une vue statique, non dynamique. Il faut donc voir dans la globalité. Un AgentSpecificBehavior est il lié, ou non, à un, ou plusieurs, Event ?

Une relation de type <<uses>> serait peut être suffisante. (Quitte à définir ton stéréotype <<emits>>, ou encore utiliser le <<creates>>)

Effectivement il faudrait peut-être utiliser un stéréotype « emits » sur une relation de type dépendance.

Oui, je n'en doute pas, je voulais dire, pourquoi est il "dessiné" là ? tout isolé alors que les behavior sont en haut à droite ?

Tout simplement à cause de la relation avec Inhabitant ; je n'avais pas la place de le mettre ailleurs

[hed62]

Pour la relation Event/Agentoid : oui, comme ca. Attention "emiters" induirait une cardianlité *

[behess]

Pourquoi le Behavior devrait être Chainable ? Que l'AgentSpecificBehavior soit chainable n'est pas suffisant ?

J'avais oublié de répondre à cette partie :
chaque Agentoid a une palette de comportements (Behaviors) à sa disposition

=> Chaine de Behaviors

chaque Behavior peut être spécialisée pour une type de "cible" particulière

=> Chaine de AgentSpecificBehavior

Autrement j'avais pensé implémenter ça sous forme de hiérarchie pour un Behavior donné, qui aurait une méthode treat(Event e,Agentoid target) redéfinie pour chaque type d'agent dont on voudrait spécifier le comportement cible.

Ce serait sûrement plus simple d'ailleurs... puisque de toute façon un AgentSpecificBehavior sera toujours lié au même Behavior !

Pour la relation Event/Agentoid : oui, comme ca. Attention "emiters" induirait une cardianlité *

Oui c'est volontaire, puisque chaque Agentoid peut "décider" de réémettre l'Event (après l'avoir secoué un peu éventuellement) en se rajoutant à la chaine des émetteurs.

[hed62]

chaque Agentoid a une palette de comportements (Behaviors) à sa disposition

=> Chaine de Behaviors

chaque Behavior peut être spécialisée pour une type de "cible" particulière

=> Chaine de AgentSpecificBehavior

aaaahhhhhhh .... Oui j'avais oublié cette histoire de double chaine.

[behess]

Autrement j'avais pensé implémenter ça sous forme de hiérarchie pour un Behavior donné, qui aurait une méthode treat(Event e,Agentoid target) redéfinie pour chaque type d'agent dont on voudrait spécifier le comportement cible.

Ce serait sûrement plus simple d'ailleurs... puisque de toute façon un AgentSpecificBehavior sera toujours lié au même Behavior !

En fait je viens de me souvenir pourquoi j'avais fait ça : en fait une hiérarchie ça n'irait pas : il faut surcharger une méthode, pas spécialiser une méthode. Donc l'autre réelle alternative ce serait de surcharger le handler du Behavior avec toutes les cibles à spécialiser. Mais le problème c'est qu'à chaque besoin de spécialisation, il faudrait modifier le Behavior, ce que je ne veux pas. Donc j'utilise la composition et je délègue à une Chaine de AgentSpecificBehaviors

A propos de BasicEventHandle : tu ne le masque pas de suite dans une chaine ? tu gardes cela pour une prochaine évolution ?

Euh, nan !
Je m'ai trompé Je dois changer la relation et associer le Behavior avec le BasicEventHandler.

Merci d'avoir mis le doigt dessus, je n'avais pas fait gaffe

Je reviens là dessus aussi...

En fait j'ai dis une grosse bêtise : c'est bien l'Agentoid qui dispose du EventHandler : celui-ci détermine comment l'Agent doit transmettre l'Event aux Behavior. Il joue le rôle d'une sorte de Mediateur. Par défaut ce serait le BasicEventHandler qui transmettrait au Behavior "tête-de-chaine" l'Event à traiter. Mais on pourrait en décider autrement (filtrer certains Behaviors par exemple) en créant son propre EventHandler.

Behavior sera une interface qui étend EventHandler (et Chainable également), alors que BasicEventHandler implémente EventHandler. D'ailleurs si tu as des idées d'adjectifs pour remplacer le nom des interfaces "Behavior", "EventHandler" et "AgentSpecificBehavior" je suis preneur.

[behess]

Pour mémoire :

Technique de double dispatch en Java.

Extension de Java qui permet de faire un peu la même chose.

Sur le même thème, ça aurait été parfait si Java avait implémenté un mot clé permettant d'avoir un accès au "caller" d'une méthode (si déclaré comme ça) ; ex:

Code :

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

1
2
3
4
5
6
// event constructor
Agentoid:Event(Agentoid target,EventType type,Modality... mods) {
  this.emitters.add(caller);
  ...
}

où « Agentoid: » préciserait la classe de l'appelant de la méthode, auquel qu'on pourrait accéder via le mot clé "caller". Ce serait plus clair que l'actuel :

Code :

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

1
2
3
4
5
6
// event constructor
Event(Agentoid caller, Agentoid target,EventType type,Modality... mods) {
  this.emitters.add(caller);
  ...
}

qu'il faut explicitement documenter

(j'ai pris un constructeur, mais ça pourrait être n'importe quelle méthode)

Enfin bref, je pinaille.

[hed62]

Tu peux parfaitement faire cela via la programmation par Aspects.
C'est très interressant et ouvre de nombreuses portes. Mais cela reste une technique lourde à mettre en place (mais ca vaut le coup !)
Il semblerait que tes liens fasse de la programmation par Aspect (mais je n'ai lu que quelques lignes) sans en donner le nom.

Enfin bref, je pinaille.

Effectivement, un paramètre, ce n'est pas la mort

[behess]

Merci pour tes contributions hed62 (Hervé, c'est ça ?).

Je me rends compte qu'il n'y a quasiment que des interfaces ou des classes abstraites dans mon schéma...

Tu me diras, c'est un modèle avant tout, mais je trouve que c'est un peu dérangeant qu'il n'y ait pas de classes concrètes Je peux peut-être ajouter des classes concrètes "fictives" pour décrire certains processus...?

En tout cas il manque certainement des diagrammes de séquences avec des classes concrètes pour avoir un aperçu du fonctionnement, non ?

[hed62]

C'est parceque tu arrives à un haut niveau d'abstraction, tu viens de spécifier ton framework multi agent. Une fois celui ci prêt, tu pourras commencer à fairedes applciations et donc implémenter des classes concrètes.