5.4 Pattern organisationnel pour la simulation
5.4.4 Principe de simulation associ´ e
Sur la base de ce pattern organisationnel, nous avons impl´ement´e un noyau d’ex´ecution minimal qui contient des instances g´en´eriques des diff´erents agents, activateurs et sondes qui participent au processus de simulation ainsi d´efini, ceci de mani`ere `a fournir un m´ecanisme de simulation qui puisse ˆetre r´eutilis´e sans difficult´e. Le m´ecanisme de simulation est bas´e sur un principe ´ev´enementiel o`u l’ex´ecution d’un activateur particulier est consid´er´ee comme un ´ev´enement atomique qui sera d´eclench´e par le scheduler principal `a la date fix´ee. Par exemple, un activateur charg´e d’ex´ecuter tout un ensemble d’agents `a un instant t (DiscreteTimeActi- vator), c’est-`a-dire suivant un principe de simulation `a pas de temps constant, sera identifi´e dans le syst`eme comme un ´ev´enement individuel et ponctuel qui se r´ep`ete de fa¸con r´eguli`ere dans le temps. Le principal avantage de ce fonctionnement est de permettre `a un utilisateur de m´elanger diff´erentes politiques d’ex´ecution. Pour le scheduler les diff´erents activateurs d´e- finissent tous des ´ev´enements de mˆeme nature. Autrement dit, il est par exemple possible de faire ´evoluer les agents suivant un principe ´ev´enementiel grˆace `a un premier activateur tan-
Fig. 5.8 – Utilisation r´ecursive du pattern pour la simulation multi-´echelles.
dis que l’´evolution endog`ene de l’environnement sera mod´elis´ee par un processus d´efinissant une discr´etisation du temps r´eguli`ere appliqu´ee par un autre activateur. La partie critique du scheduler qui correspond `a l’application de ce principe est la suivante :
/∗ ∗ r e t u r n s t r u e i f t h e r e i s no more e v e n t t o e x e c u t e ∗/ p u b l i c b o o l e a n e x e c u t e N e x t E v e n t ( )
{
// n e x t e v e n t i n queue
SimEvent e v e n t = ( SimEvent ) e v e n t L i s t . remove ( 0 ) ;
i f( e v e n t != n u l l) { // g e t t h e s o u r c e o f t h e e v e n t G e n A c t i v a t o r a c t i v a t o r = ( G e n A c t i v a t o r ) e v e n t . g e t S o u r c e ( ) ; // u p d a t e GVT setGVT ( e v e n t . g e t D a t e ( ) ) ; // e x e c u t e n e x t e v e n t SimEvent s e = a c t i v a t o r . e x e c u t e (GVT) ; // add t h e e x t e r n a l e v e n t p r o d u c e d i f( s e != n u l l) addEvent ( e v e n t ) ; // s t a t e h a s changed : do a d i s p l a y o b s e r v e r s . e x e c u t e (GVT) ; r e t u r n f a l s e; } r e t u r n t r u e; }
On voit ici que tous les activateurs sont trait´es de la mˆeme fa¸con quelle que soit leur nature. C’est pourquoi il est donc possible de d´efinir plusieurs types d’activateur diff´erents et de les tester les uns apr`es les autres, ou en mˆeme temps de fa¸con `a analyser les r´eactions du mod`ele de simulation tr`es simplement. Le code suivant d´efinit par exemple deux activateurs diff´erents sur un mˆeme couple groupe/rˆole qui peuvent ˆetre utilis´es ind´ependamment ou simultan´ement.
a c t i v a t o r 1 = new D i s c r e t e T i m e A c t i v a t o r ( community , GenModel .MODEL GROUP, GenModel . SIMAGENT ROLE, ” d o I t ” , 1 , 1 ) ;
a c t i v a t o r 2 = new D i s c r e t e E v e n t A c t i v a t o r ( community , GenModel .MODEL GROUP, GenModel . SIMAGENT ROLE, ” d o I t ” , 1 ) ;
5.5 R´esum´e du chapitre 111
5.5
R´esum´e du chapitre
Dans ce chapitre nous avons pr´esent´e les outils logiciels qui nous ont servi de brique pour concevoir l’ensemble des applications de simulation que nous avons impl´ement´ees pendant nos recherches. Dans un premier temps ils nous ont permis de nous rendre compte par nous-mˆemes des probl`emes et des questions qui se posent lorsqu’on souhaite impl´ementer un simulateur multi-agents.
Dans un deuxi`eme temps, il nous faut rappeler le contexte dans lequel ces outils ont ´et´e ´elabor´es. Dans le chapitre pr´ec´edent nous avons insist´e sur l’importance de concevoir des outils de conception suffisamment g´en´eriques pour qu’ils puissent ˆetre r´eutilis´es quel que soit le domaine d’application. De notre point de vue, chaque exp´erience de simulation est en effet singuli`ere et n´ecessite un simulateur particulier qui soit adapt´e aux besoins. La r´eutilisabilit´e ´etait donc un de nos objectifs majeurs. Sur ce point, la vari´et´e des simulations qui ont ´et´e impl´ement´ees `a l’aide de ces outils nous a donn´e confiance dans notre approche. Rappelons ici qu’il s’agit de consid´erer que tout simulateur multi-agents doit faire face aux probl`emes d’ing´enierie logicielle li´es `a la gestion de l’ex´ecution des agents et `a l’observation du syst`eme. Notre deuxi`eme objectif ´etait de faire en sorte que le fonctionnement des simulateurs ´elabor´es `a l’aide de ces outils soit facilement modifiable et explicite. A l’instar des outils d’analyse de sensibilit´e, l’int´erˆet est de permettre l’exploration des diff´erentes impl´ementations qui sont possibles pour un mod`ele. Grˆace `a cette exploration, il s’agit d’une part d’identifier de possibles faiblesses dans les sp´ecifications d’impl´ementations du mod`ele, et d’autre part de mieux comprendre l’implication des choix de programmation sur les r´esultats obtenus.
Finalement, ces outils ont aussi constitu´e pour nous le moyen d’impl´ementer les diff´erentes perspectives de recherche que nous allons pr´esenter dans la suite de ce document. Comme nous l’avons dit dans le chapitre pr´ec´edent, nous pensons que le futur de la simulation multi-agents passe aussi par une r´eflexion approfondie sur la mani`ere dont nous caract´erisons et mod´elisons ces syst`emes. Dans le chapitre suivant, nous allons pr´ecis´ement nous attaquer au probl`eme de la mod´elisation de l’action dans les syst`emes multi-agents. Nous allons essayer de convaincre le lecteur de l’int´erˆet de modifier notre point de vue sur la mani`ere dont le r´esultat de la d´elib´eration d’un agent, c’est-`a-dire son action sur l’environnement, doit ˆetre mod´elis´e.