Content uploaded by Yassine Gangat
Author content
All content in this area was uploaded by Yassine Gangat
Content may be subject to copyright.
Approche méthodologique pour la modélisation
multicomportementale dans la SOA
Y. Gangat
a
yassine.gangat@univ-reunion.fr
D. Payet
a
denis.payet@univ-reunion.fr
R. Courdier
a
remy.courdier@univ-reunion.fr
a
Laboratoire d’Informatique et de Mathématiques - IREMIA EA2525, Université de La Réunion, Réunion
Résumé
Lorsque l’on comprend ce qu’est la SOA, quels
sont ses avantages et ses inconvénients, la pre-
mière question qui se pose est : "comment pro-
céder ?". Il n’y a pas de réponse unique. Cepen-
dant, il est nécessaire de suivre une méthodolo-
gie de conception de simulations ou encore un
processus de simulation. Elle consiste à définir
la suite d’opérations à réaliser pour obtenir une
simulation d’une partie du monde réel.
Nous proposons dans cet article un tronc com-
mun aux différentes méthodologies de concep-
tion de simulations. Ensuite, nous présen-
tons une nouvelle approche facilitant la co-
construction (la collaboration entre des théma-
ticiens pour construire un modèle) et la réutili-
sation de modèle, tirant parti de DOM et aMVC.
Enfin, nous appliquons cette approche méthodo-
logique sur un exemple et proposons quelques
perspectives.
Mots-clés : SOA, comportement, aMVC, métho-
dologie
Abstract
When we understand what MABS is, what are
its advantages and disadvantages, the first ques-
tion is "how ?". There is no unique answer. Ho-
wever, it is necessary to follow a simulation
design methodology. It helps to define the se-
quence of operations to perform a simulation
from a part of the real world.
We propose in this paper some common steps
to simulation design methodologies. Then, we
present our methodology that eases co-building
and re-use of models, taking advantange of
DOM and aMVC. Finally, we apply this metho-
dology on an example and offer few outlooks.
Keywords: ABS, behaviors, aMVC, methodo-
logy
1 Introduction et contexte
Drogoul [DVM
+
02] et Ramat [Ram06] ex-
pliquent qu’un processus de simulation peut
être décomposé de manière plus ou moins
fine, selon la granularité de la description vou-
lue par les auteurs, dans leurs contextes. Les
différents travaux [DVM
+
02, Rob06, Sar99,
GII
+
09] montrent bien l’absence d’unanimité
autour du "comment ?" de manière détaillée.
Cependant, toutes les réponses sont fondées sur
des méthodologies de conception de simula-
tions, chacune d’entre elles ayant ses spécifici-
tés dans son contexte, dépendant de l’ampleur
du projet et du nombre de personnes mobilisées.
Nous proposons dans cet article un tronc com-
mun à toutes ces méthodologies, puis une mé-
thodologie qui facilite la co-construction et la
réutilisation de modèle. Elle expose une nou-
velle façon de représenter un système complexe
naturel ou social, suivant le paradigme agent.
Elle se fait par l’intermédiaire d’une décompo-
sition élémentaire, sous forme de tableaux sy-
noptiques. Elle découpe le système en cellules
pour obtenir une vision thématique des agents
et explorer les divers aspects de leurs com-
portements. Ensuite, nous modélisons l’agent
comme étant un agrégat de ces cellules. Ces ou-
tils aident à la modélisation du système com-
plexe étudié.
La conception guidée proposée ici aide à faire le
lien entre les différents thématiciens, ce qui fa-
cilite la co-construction de modèles. Cette mé-
thodologie donne aussi la possibilité à tous les
acteurs (thématiciens, modélisateurs et informa-
ticiens) de travailler en synergie, par l’intermé-
diaire de supports communs que forme cette
décomposition élémentaire. Pour cela, nous
nous appuyons sur deux concepts : DOM
1
et
aMVC
2
.
1.1 Présentation de DOM
Après qu’une nouvelle application ait été créée
puis validée par sa commission d’étude, les ex-
perts veulent généralement la réutiliser, totale-
ment ou partiellement. Le fait de réemployer
un modèle dans un nouveau contexte permet
en effet de l’améliorer (en l’affinant de plus
en plus), mais aussi et surtout, de réduire le
1. Modélisation Orientée Dynamique
2. agent MVC
temps de conception de nouvelles applications.
De plus, ce fait permet aussi de réaliser des
économies financières. L’idée de la Modélisa-
tion Orientée Dynamique (DOM : Dynamic-
Oriented Modeling) est née de ce besoin de la
réutilisation de modèles [PCSR06], dans le do-
maine des systèmes multi-agents. Un besoin de-
venu aujourd’hui critique face à la complexité
de plus en plus importante des systèmes étudiés.
Cette complexité rend l’élaboration des modèles
longue et difficile. Les résultats obtenus sont
donc de plus en plus précieux et leurs réutili-
sations indispensables.
DOM est basée sur l’utilisation des dynamiques.
Une dynamique est une association d’un en-
semble d’activités qui participent à une caracté-
ristique majeure d’un problème complexe. Par
exemple, la production, la distribution et la
consommation d’énergie sont des activités qui
participent à la dynamique de l’évolution de
l’énergie.
Le but de cette méthode de modélisation
consiste à décomposer un problème complexe
en plusieurs sous-systèmes moins complexes
(c’est-à-dire les dynamiques), en utilisant l’en-
vironnement comme élément de couplage. En
quelques mots, DOM est basée sur l’intégra-
tion de plusieurs couches d’ "environnements",
chaque couche étant appelée Modèle mono-
dynamique (MDM
3
), dans un modèle multi-
MDM. Au niveau pratique, l’utilisation de
DOM a l’avantage de faciliter l’isolation (par-
tielle), au sein même du code, du traitement
propre à chacune d’elle. Ce qui simplifie le tra-
vail futur des (mêmes ou d’autres) modélisa-
teurs pour l’affinement de ces dynamiques.
Après avoir appliqué DOM à un exemple
concret dans DS puis dans EDMMAS [GCP09],
nous avons réalisé que DOM n’était pas suffi-
sante pour surmonter toutes les difficultés. En
effet, si cette approche est efficace au niveau
conceptuel et particulièrement pour la gestion
des environnements, nos travaux ont permis de
révéler un décalage conséquent entre le modèle
opérationnel et le modèle conceptuel. Ce déca-
lage causera ensuite un travail important lors de
l’implémentation des agents, notamment pour
leurs comportements impliquant plusieurs dy-
namiques. Plus les agents en intègrent, plus ils
deviennent délicats à appréhender sur le plan
implémentatoire en induisant une élévation de
complexité au niveau des modèles opérationnel
et informatique.
3. Mono-Dynamic Model
Pour compléter cette modélisation, nous avons
proposé un modèle d’architecture interne
d’agent basé sur le "célèbre" concept MVC, qui
permet, grâce aux ses propriétés, de faciliter la
réutilisation.
1.2 Présentation de aMVC
FIGURE 1 – Un agent basé sur DOM et aMVC
Nous avons proposé dans [GPC12a, GPC12b]
l’utilisation d’un design pattern comme brique
de base pour la construction d’un agent : le pat-
tern aMVC (Agent Modèle-Vue-Contrôleur) re-
présenté sur la Figure 1. Ce pattern a été in-
troduit pour pallier au décalage entre le modèle
opérationnel et le modèle conceptuel, et propo-
ser une architecture informatique de description
d’une SOA en cohérence avec une modélisa-
tion multidynamique. Ce modèle est inspiré des
design patterns du monde objet, en particulier
du Modèle-Vue-Contrôleur (MVC), qui, malgré
sa simplicité apparente, a facilité notamment la
réutilisation des modules des applications multi-
vue, multifenêtre. ..Nous avons transposé MVC
aux besoins du monde agent tel que nous l’abor-
dons.
Cette structuration est basée sur les trois compo-
santes que nous avons identifiées dans l’agent :
ses états, ses comportements et ses interac-
teurs (effecteurs et récepteurs). Après un pre-
mier fractionnement selon les dynamiques puis
selon les royaumes, concept introduit pour re-
présenter les domaines d’expertise comporte-
mentale, nous faisons une scission suivant ces
trois composantes, représentant respectivement
le modèle, le contrôleur et la vue du pattern
aMVC. Ces différentes couches aMVC, issues
de chacune des dynamiques, forment les briques
élémentaires notre agent.
1.3 Contexte
Le processus que nous décrivons dans cet article
a pour but de simplifier l’utilisation des concepts
précédents. Car dans un souci d’efficacité et de
cohérence, il nous semble important de proposer
une méthodologie de conception appropriée à ce
nouveau cadre de modélisation. En effet, l’ar-
chitecture que nous avons mise en place ouvrent
de nouvelles possibilités et son potentiel ne peut
s”exprimer que lorsqu’il est bien utilisé.
2 Aide à la conception de simula-
tions. . .
2.1 Tronc commun aux différentes métho-
dologies de conception de simulations
L’expression "Tronc commun" insiste sur le fait
qu’il s’agit d’un ensemble de phases communes
à plusieurs méthodologies. Cette trame est basée
sur des travaux précédents. Elle nous permettra
de positionner nos contributions présentées dans
la Section 3 suivante. Ce tronc commun com-
porte les cinq étapes de la Figure 2 :
1. Une phase de modélisation initiale : Les
thématiciens, aidés par les modélisateurs,
partent du système complexe réel et éta-
blissent un modèle du domaine. En géné-
ral, il s’agit d’une modélisation grossière
qui s’affine et gagne en pertinence au fur et
à mesure.
2. Une phase de formalisation : Les mo-
délisateurs, accompagnés par les thémati-
ciens, élaborent le modèle de conception.
Ils adaptent les connaissances des experts
au monde agent, passant du langage non-
formel à un langage formalisé "agent".
3. Une phase d’opérationnalisation : Les
deux précédents groupes collaborent
maintenant avec des modélisateurs-
informaticiens
4
, qui procèdent à une
phase d’opérationnalisation. Elle consiste à
exprimer les agents avec des propriétés en
relation avec l’implémentation (sans toute-
fois implémenter le modèle). Il peut s’agir
de propriétés techniques comme la distribu-
tion physique des agents ou de techniques
4. La différence entre modélisateurs-informaticiens et program-
meurs que nous établissons est la suivante : le premier établit son modèle
indépendamment de la manière que ce dernier sera implémenté. Le se-
cond s’appuie lui sur un langage de programmation ou une plateforme
de simulation particulière.
d’ordonnancement temporel. En d’autres
termes, les informaticiens doivent établir
avec les thématiciens et modélisateurs un
"cahier des charges".
4. Une phase d’implémentation : Les pro-
grammeurs, à partir du "cahier des charges"
précédent, implémentent la simulation sur
la plateforme choisie, avec ses concepts
spécifiques et réalisent les tests de valida-
tion.
5. Une phase d’exécution : Une fois le mo-
dèle informatique implémenté, les utilisa-
teurs procèdent à une succession d’expé-
riences sur la base de scénarios de simula-
tion. Ces utilisateurs sont les thématiciens,
les responsables du projet. . .
PROGRAMMEURS,
MODÉLISATEURS-INFORMATICIENS,
MODÉLISATEURS
THÉMATICIENS
MODÉLISATEURS-INFORMATICIENS
MODÉLISATEURS
THÉMATICIENS
MODÉLISATEURS
THÉMATICIENS
THÉMATICIENS
MODÉLISATEURS
Accompagnement d'un expert SOA
Modèle de domaine
Modèle opérationnel
Système réel
Modèle de conception
Modèle informatique
Modèle simulé
Formalisation
Opération-
nalisation
Implémentation
Exécution
Modélisation
Initiale
FIGURE 2 – Tronc commun aux méthodologies
de conception de SOA
Dans cette trame, nous avons volontairement
omis les cycles et retours ainsi que les étapes
d’analyses. La principale raison est que, dans
notre cadre de travail, nous nous intéressons par-
ticulièrement à la co-construction de modèle et
à sa réutilisation. De plus, nous marquons le fait
que l’accompagnement d’experts en SOA est un
point important à chaque phase. Ces derniers
les aident à avancer de manière efficace et leur
permettent d’employer un niveau de dialogue
adapté à chacun et à ce que l’on veut produire
pour une modélisation de SOA.
2.2 La collaboration entre les différents ac-
teurs
Dans un projet de modélisation de compor-
tement des tortues marines Chelonia mydas
du sud-ouest de l’Océan Indien [GDD
+
10,
DCM
+
12], nous avons abordé le sujet de la col-
laboration entre les différents acteurs participant
à un projet de modélisation commun en par-
tie, en structurant notre approche sur la dualité :
modèle conceptuel / modèle informatique. Nous
avons établi un prototype en travaillant sur deux
documents en parallèle :
1. La description conceptuelle, qui énonce le
modèle suivant ce que les thématiciens sou-
haitent exprimer.
2. La description informatique, qui spécifie le
modèle tel qu’il est (ou sera) implémenté
sur le prototype.
La distance entre ces deux documents est ap-
pelée distance implémentatoire. La réduction de
cette distance impose des modifications sur les
deux documents, donc des efforts de la part de
chacun des acteurs (dans le cas de ce projet,
il s’agissait de thématiciens, d’informaticiens et
de programmeurs). La description conceptuelle
doit être réexprimée (voire simplifiée) pour être
adéquation avec les contraintes (et les limites)
informatiques. La description informatique doit
être améliorée pour se rapprocher au mieux des
attentes des thématiciens.
Au final, plus la distance implémentatoire sera
faible, plus le risque d’un manque de pertinence
du prototype sera faible. Dès que la minimisa-
tion de ce risque sera jugée acceptable, l’effort
du passage du prototype à l’outil final sera en-
visagé. Cette distance ne peut être réduite que
lorsque chacun des intervenants travaille en sy-
nergie avec les autres. De plus, la présence d’un
expert de la SOA demeure importante pour aider
à la modélisation. Ce constat reste ainsi le même
à chaque niveau, car la source de cette connais-
sance à laquelle nous devons nous référer suit
une certaine hiérarchie :
– Les thématiciens, avec les modélisateurs,
créent un modèle de domaine.
– Les modélisateurs, avec les thématiciens,
mettent en place le modèle de conception.
– Les modélisateurs-informaticiens, travaillant
surtout avec les modélisateurs et parfois les
thématiciens, établissent un modèle opéra-
tionnel.
– Les programmeurs, aidés des modélisateurs-
informaticiens, et parfois des modélisateurs et
thématiciens, implémentent un modèle infor-
matique.
Dans cette hiérarchie, pour chaque point, le pre-
mier intervenant cité (en gras dans la Figure 2)
joue le rôle prépondérant ; ceux qui suivent
jouent le rôle d’accompagnateurs. Par exemple,
les modélisateurs-informaticiens établissent le
modèle opérationnel, mais ils ont besoin pour
cela de l’aide des modélisateurs et thématiciens
aussi. Ils apportent leur aide tout au long de cette
adaptation progressive du modèle : la mise en
place d’un modèle de niveau n implique parfois
un ajustement supplémentaire par rapport mo-
dèle précédent n − 1. Les acteurs du degré n − 1
doivent donc ajuster leur propre modèle et véri-
fier la correspondance avec ceux du degré n−2.
Et ainsi de suite. . .
Cette collaboration est essentielle pour per-
mettre une meilleure modélisation. En particu-
lier, la présence des experts dans le processus
de modélisation-simulation est un élément-clef.
Mais elle ne doit pas se limiter à la réalisation
commune de quelques étapes. L’ensemble du
processus de modélisation doit se faire en étroite
collaboration. Suivant ce principe, la méthodo-
logie que nous proposons permettra à tous les
acteurs de travailler et de communiquer sur la
base d’un cadre commun. Il est évident qu’il
s’agit là d’une répartition théorique des rôles,
mais souvent le même groupe de personnes
représente les modélisateurs-informaticiens, les
programmeurs et les experts en SOA. Cepen-
dant, il reste préférable de bien définir les rôles
pour faciliter la création des différents modèles
dans les contextes les plus généraux possible.
Ce tronc commun nous permettra de mieux vi-
sualiser notre méthodologie qui facilitera l’ac-
compagnement et la collaboration des acteurs
du projet.
3 . . . au travers d’une représenta-
tion élémentaire du système com-
plexe
Cette trame commune permet de mieux visuali-
ser le chemin à suivre pour simuler un système
complexe naturel ou social. Pour accompagner
les acteurs, nous proposons une représentation
élémentaire du système complexe au moyen
d’une décomposition sous forme de comporte-
ments et d’actions. Cette représentation se fait
par des éléments à la fois simples et fondamen-
taux pour décrire le système.
Dans un système complexe, les entités présentes
interagissent par des actions en rapport avec
leurs comportements. D’après la neuvième édi-
tion du dictionnaire de l’Académie française,
le comportement se définit comme "les activi-
tés des êtres vivants et leurs réactions physio-
logiques aux conditions de leur milieu". Les
comportements traduisent en psychologie "l’en-
semble des réactions objectivement observables
d’un sujet, d’un organisme qui répond à une
stimulation." Dans notre cadre de travail, nous
considérons la définition suivante :
Définition 1 (Comportement) Le comporte-
ment d’un agent représente ses actions pour
parvenir à l’objectif fixé.
L’approche méthodologique de Modélisation
MultiComportementale exposée dans ce cha-
pitre est une démarche systématique, qui per-
met de décomposer le thème d’étude en tâches
simples. Elle est structurée en deux axes liés :
celui des comportements et celui des actions.
Les descriptions obtenues et représentées sous
forme de tableaux se répartissent conformé-
ment à ces deux axes (voir Figure 3). Pour
plus de clarté, tout au long de cet article, le
mot "agent" correspond à une famille (ou un
type) d’agents, c’est-à-dire une spécification
d’agents possédant les mêmes comportements
et actions. Nous appelons instance d’agent une
instance particulière de cette famille d’agents.
Par exemple, nous avons le type agent "Termite"
et les instances d’agent termite
1
, termite
2
. . .
Comportements Actions
Agent / Expert Agent / Expert
Agent / Dynamique Agent / Dynamique
Dynamique et
environnements
Agents du système
B
E
C F
A D
FIGURE 3 – Axes de la méthodologie de la Mo-
délisation Multi-Comportementale
Dans cette section, nous décrirons les étapes
comme étant une suite séquentielle, mais nous
verrons que certaines tâches peuvent être me-
nées en parallèle.
3.1 Description sous forme de comporte-
ments
La première série d’étapes consiste à décrire le
système complexe au travers des divers compor-
tements de chaque type d’agent.
A : Identification des comportements du modèle de
domaine. D’abord, nous demandons aux thé-
maticiens (et modélisateurs) d’identifier les dif-
férentes familles d’agents. Ces dernières sont
classées en deux grands types : les agents ac-
tifs (qui possèdent au moins un comportement)
et les agents passifs (qui n’en possèdent aucun).
De manière générale, un "objet" du monde réel
qui n’a pas de but à atteindre au sein du système
multi-agents est un agent passif.
Ensuite, pour chaque agent, chaque expert ex-
prime les différents comportements qu’il peut
décrire (voir le tableau 1). Un ordre de priorité
par défaut des comportements sera défini pour
chaque agent. Cette priorité pourra changer en
fonction des besoins de la simulation, grâce à
un algorithme interne à l’agent. Par exemple, le
comportement de plus haute importance pour un
termite sera de chercher un morceau de bois ; si
elle en a déjà trouvé un, ce sera de le déposer
à coter d’un autre. Dans ce cas, cet algorithme
sera centré sur l’état "porte une instance de bois"
de l’agent termite.
Ainsi, chaque expert apportera sa contribution à
son niveau sur ces comportements :
– On peut rencontrer un comportement pos-
sédant une description commune pour deux
agents différents (par exemple, le compor-
tement de mouvement aléatoire peut être la
même pour un termite et une fourmi).
– Deux descriptions différentes pour le même
comportement d’un agent peuvent être défi-
nies par deux experts (par exemple, le com-
portement de mouvement aléatoire peut être
définie par un expert en changeant unique-
ment de direction et par un second en chan-
geant à la fois vitesse et orientation).
– Un expert pourra aussi bien décrire intégra-
lement le comportement qu’en présenter une
partie (voir l’exemple plus loin).
Résumé de l’étape A
A : Identification des comportements (par les
experts) :
– Choisir un agent. S’il s’agit d’un nouvel
agent :
– Description de l’agent.
– Ajout à une liste des types d’agents.
TABLE 1 – A : Les agents et les experts (Com-
portements)
Exp. 1 Exp. 2 Exp. 3 (. . .)
Agent A
Cpt.
1, 2, 3
7 Cpt. 1 . . .
Agent B 7
Cpt.
3, 4, 5
Cpt. 4 . . .
Agent C 7 7
Cpt.
6, 7, 8
. . .
Agent D 7 7 Passif . . .
. . . . . . . . . . . . . . .
Ordre de priorité des Cpt de l’agent A : 1,2,3
Ordre de priorité des Cpt de l’agent B : 4,5,3
Ordre de priorité des Cpt de l’agent C : 7,6,8
Légende :
X(ou texte correspondant) = participe
7= ne participe pas
– Définition du statut actif de chaque
agent : il est actif
5
lorsqu’il possède
au moins un comportement, sinon il est
passif.
– Décrire un comportement :
– Description en langage naturel du com-
portement. Nous pouvons remarquer
qu’il est possible d’avoir :
– Une description commune pour deux
agents différents.
– Deux descriptions différentes pour
un même comportement A
n
par des
experts différents i et j : A
n
Ex
i
et
A
n
Ex
j
.
– Description partielle d’un comporte-
ment.
– Ajout du comportement à la liste des
comportements de l’agent.
– Définition de la priorité du comporte-
ment.
– Définir l’algorithme de changement de
priorité (si besoin).
Résultat : Liste des agents, Listes des compor-
tements dans le modèle de domaine et Al-
gorithme de priorité.
B : Déclinaison et formalisation des comportements du
modèle conceptuel. Suite à cette première ana-
lyse, les modélisateurs doivent décliner chaque
comportement avec le concept d’actant, en uti-
lisant en particulier les notions d’acteur et d’ob-
jet. Cette sémantique nous permettra ensuite
de distinguer l’appartenance à une dynamique.
En linguistique, le terme d’actant (Lucien Tes-
nière, 1965, dans [Tes65]) désigne les consti-
tuants syntaxiques d’une phrase par opposition
5. Note : Il est possible qu’un agent soit actif dans une dynamique,
mais passif dans une autre.
au circonstant (manière, repère temporel, lieu de
l’action). Le verbe renvoie à un processus (que
nous associons à un comportement). Chaque ac-
tant impliqué dans ce processus peut jouer le
rôle sémantique suivant : l’acteur est celui qui
agit ; et l’objet/patient est ce qui subit l’action.
Par exemple, dans "Philippe frappe Jean", nous
avons Philippe = acteur = sujet et Jean = objet
patient = objet direct.
Par définition, l’acteur du comportement sera
l’agent lui-même. L’objet du comportement
peut être soit vide, soit l’agent lui-même (la
même instance), soit un ou plusieurs autres
agents (une autre instance ou un autre type
d’agent, passif ou non). Par exemple, dans une
simulation de termite, même si l’agent bois est
passif, selon la description de l’expert, le com-
portement de manipulation de l’agent termite
fait que l’agent bois est manipulé par le termite
et dépendra donc de ce comportement : Agent
termite → Manipulation.acteur et Agent bois
→ Manipulation.objet.
En se posant la question suivante : "Quelles sont
les différentes dynamiques inhérentes à cette
simulation, étant donné ce comportement ?"
les modélisateurs obtiennent alors ces relations
entre agents et dynamique, représentées le ta-
bleau 2 qui explicite dans quelles dynamiques
chaque type d’agent effectue potentiellement
une influence ou une perception, au travers des
comportements (plus précisément de leurs dé-
clinaisons) et de sa présence.
D’une part, la sémantique des actants nous per-
met de garder une cohérence pour l’attribution
d’une dynamique à un agent : par exemple,
Manipulation.acteur et Manipulation.objet im-
pliquent que l’agent termite et l’agent bois (res-
pectivement) entrent en jeu dans la dynamique
spatiale. Un agent peut donc participer à une dy-
namique sans avoir de comportement propre :
un objet inerte – un ballon de football – est un
agent passif qui intervient dans une dynamique
spatiale, sans pour autant avoir de comporte-
ment. De plus, il est possible qu’un comporte-
ment fasse partie de plusieurs dynamiques diffé-
rentes. Par exemple, le comportement de chasse
(et la déclinaison chasse.acteur notamment) im-
pose à la fois une intégration dans la dynamique
spatiale (pour se mouvoir) et celle de la com-
munication (pour appeler ses congénères). Elle
participe à ces deux dynamiques chez le loup.
Nous pouvons remarquer ici que l’expertise du
thématicien (ou d’un groupe de thématicien du
même domaine) représente un plan comporte-
mental, car le comportement proposé par un ex-
TABLE 2 – B : Les agents et les dynamiques as-
sociées (Comportements)
Dyn. 1 Dyn. 2 Dyn. 3 . . .
Agent A
Cpt.
1, 2
7
Cpt.
1, 3
. . .
Agent B 7
Cpt.
4, 5
Cpt 3 . . .
Agent C
Cpt.
6, 7, 8
Cpt.
9.objet
7 . . .
. . . . . . . . . . . . . . .
En tant qu’Agent A acteur Comportement 1, ma
fonction active est de faire telle et telle chose, afin
d’atteindre tel but. . .
pert peut être scindé sur plusieurs dynamiques.
La suite de cette étape est la formalisation
de ces déclinaisons selon la forme : "En tant
qu’<agent> acteur/objet du <comportement>,
ma fonction active/passive est de <besoin>,afin
de <but>, au travers des dynamiques <ens.
de dyn>". Cette formalisation est inspirée des
"User Stories" de Scrum. Les "users stories" ont
été créées pour être compréhensibles par tous
les acteurs d’un projet et incitent leurs auteurs
à donner plus de détails. [Coh04]
Résumé de l’étape B
B : Déclinaison et formalisation des comporte-
ments (par les modélisateurs) :
– Déclinaison des comportements selon ac-
teur/objet si besoin.
– Pour chaque déclinaison, création et/ou
association à une ou plusieurs dyna-
miques.
– Formalisation de ces déclinaisons se-
lon la forme : "En tant qu’<agent> ac-
teur/objet du <comportement>, ma fonc-
tion active/passive est de <besoin>,afin
de <but>, au travers des dynamiques
<ens. de dyn>." et ajout à la description.
Résultat : Liste des comportements formali-
sés (et de leurs déclinaisons) du modèle
conceptuel, Liste des dynamiques ; pour
chaque dynamique nous avons aussi la liste
des agents actifs (acteurs d’un comporte-
ment au moins dans la dynamique corres-
pondante) et celle des agents passifs (uni-
quement objets d’un ou plusieurs compor-
tements de la dynamique correspondante).
C : Bilan des dynamiques du système du modèle opé-
rationnel. Suite à cette première série d’étapes,
les équipes ont défini la liste des types d’agents
de la SOA souhaitée. Pour chaque agent, la liste
des comportements et de leurs déclinaisons ac-
compagnées de leurs priorités a été définie. Il en
TABLE 3 – C : Les dynamiques et environne-
ments du système
Dyn. 1 Dyn. 2 Dyn. 3 . . .
Environnements Env. α Env. β Env. γ
Agents A, C B A, B, C
est de même pour la liste des dynamiques où in-
terviennent ces agents et leurs déclinaisons.
À l’issue de ces étapes, un premier bilan (voir
tableau 3) définit les dynamiques du système,
ainsi que :
– les environnements nécessaires à la SOA, re-
latifs à ces dynamiques,
– les agents qui interviennent dans ces dyna-
miques.
Ce tableau permet de détecter les environne-
ments utiles à concevoir, ainsi que les synergies
envisageables entre les différentes dynamiques.
Il est bien sûr possible d’intégrer plusieurs dy-
namiques au même environnement, comme de
concevoir une dynamique agissant sur plusieurs
environnements. Pour chacun d’entre eux, les
modélisateurs-informaticiens le décrivent selon
les besoins des experts, en se basant par exemple
sur quelques propriétés proposées par Russel et
Norvig [RN09] :
– Observable (entièrement ou partiellement) vs
Inobservable.
– Déterministe vs Non déterministe vs Sto-
chastique.
– Épisodique vs Séquentiel.
– Dynamique (ou semi-dynamique) vs Sta-
tique.
– Discret vs Continu.
Une fois que ces environnements ont été décrits,
pour chacun d’entre eux, il est encore important
d’y adjoindre deux informations :
– La liste des lois de cet environnement. Les
lois de l’environnement comportent les diffé-
rentes règles responsables de la dynamique du
système comme l’évolution des attributs, les
primitives de l’environnement, les règles de
métriques. . .
– La liste des "attributs induits" par cet environ-
nement. Le fait qu’un agent ait un corps dans
un environnement implique certains attributs.
Par exemple, le fait que l’agent Loup parti-
cipe à la dynamique spatiale implique que ce
dernier a un corps dans l’environnement spa-
tial. Avoir un corps dans l’espace présuppose
donc une position (x et y, voire z), une vi-
tesse (nulle dans le cas d’objet immobile par
exemple) et une orientation.
Résumé de l’étape C
C : Bilan des dynamiques (par les
modélisateurs-informaticiens) :
– Identifier les environnements à associer
aux dynamiques :
– Décrire le type d’environnement
– Énoncer les lois de l’environnement
(métrique. . .).
– Créer des "attributs induits" par l’envi-
ronnement pour un agent (vitesse, po-
sition sociale. . .).
– Identifier les agents à associer aux dyna-
miques : pour chaque agent, nous établis-
sons la liste des déclinaisons de compor-
tement possibles selon le modèle précé-
dent.
Résultat : Liste des agents et des environne-
ments associés aux dynamiques.
3.2 Description sous forme d’actions
Une fois les types d’agents, les comportements,
les dynamiques et les environnements identi-
fiés, intéressons-nous aux actions. Comme nous
l’avons vu dans la définition 1, l’agent possède
des comportements formés d’actions. Nous pro-
cédons donc à un affinement des comportements
en actions.
D : Identification des comportements du modèle de
domaine. Les thématiciens établissent le dé-
tail des comportements de chaque agent sous
la forme d’un ensemble d’actions. Chaque ex-
pert décrit de manière détaillée les compor-
tements relatifs à ce comportement particu-
lier (qui peut parfois être commun à plusieurs
agents). Chaque comportement se décompose
en une ou plusieurs actions. Il est possible que
deux experts aient des visions différentes de
la même action. La mise en commun de ces
connaissances nous permet d’obtenir les infor-
mations du tableau suivant 4, extension du ta-
bleau obtenu à l’étape A (tableau 1). Cette iden-
tification permet :
– de connaître les actions liées à un comporte-
ment précis (d’un ou plusieurs agents),
– et de reconnaître exactement les actions que
chaque expert peut isoler.
Dans l’ordre que nous avons proposé ici, cette
étape D se déroule après l’étape C. Cependant,
il est possible qu’elle ait lieu juste après l’étape
A ou encore après la description d’un compor-
tement de l’étape A. En effet, la description de
ces actions ne nécessite pas les étapes B et C,
mais uniquement l’étape A sur le comportement
concerné.
TABLE 4 – D : Les agents et les experts (Ac-
tions)
Exp. 1 Exp. 2 Exp. 3 . . .
Cpt. 1 C
1
(Agent A)
Ac
1
Ex
1
Ac
2
Ex
1
7 Ac
1
Ex
3
Cpt. 2 C
2
(Agent A)
Ac
3
Ex
1
7 7
. . .
Cpt. 3 C
3
(Agent A, B)
Ac
7
Ex
2
Ac
8
Ex
2
Ac
7
Ex
2
Ac
8
Ex
2
7
. . .
TABLE 5 – E : Les agents et les dynamiques
(Actions)
Dyn. 1 Dyn. 2 Dyn. 3 ...
Cpt. 1 C
1
(Agent A)
Ac
1
D
1
Ac
2
D
1
7 Ac
1
D
3
Cpt. 2 C
2
(Agent A)
Ac
3
D
1
7 7
. . .
Cpt. 3 C
3
(Agent A, B)
7
Ac
7
D
2
Ac
8
D
2
7
. . .
Résumé de l’étape D
D : Identification des actions (par les thémati-
ciens) :
– Choisir un comportement et lister les ac-
tions.
– Décrire chaque action :
– Description en langage naturel.
– Ajout de l’action à la liste.
Résultat : Liste des actions du modèle de do-
maine de chaque comportement pour cha-
cun des agents.
E : Formalisation des actions du modèle conceptuel.
Cette étape consiste en la formalisation des ac-
tions sous forme d’algorithme, voire de logique
de premier ordre si besoin. Puis ces actions
se répartissent selon les dynamiques. Autant il
était possible qu’un comportement puisse faire
partie de plusieurs dynamiques différentes, au-
tant il est préférable que chaque action parti-
cipe au moins de dynamiques possible, pour
permettre ensuite la décomposition élémentaire.
Ainsi nous obtenons les dépendances actions-
dynamiques qui existent pour chaque compor-
tement pour chacun des agents, comme sur le
tableau 5.
Résumé de l’étape E
E : Formalisation des actions (par les modélisa-
teurs) :
– Formaliser chaque action sous forme
d’algorithme et/ou de logique de premier
ordre (suivant la nécessité).
– Associer chaque action à la dynamique
correspondante
Résultat : Liste des actions formalisées de
chaque comportement pour chacun des
agents.
F : Bilan des agents aMVC du système du modèle opé-
rationnel. Le second bilan (voir tableau 6) est
obtenu à partir des connaissances précédentes et
est centré sur les agents. Il permet de préparer
les agents pour l’architecture aMVC (voir Sec-
tion 1.2). Cette dernière sépare les trois compo-
santes que nous avons identifiées sur un agent :
– Les modèles M : Son état, ou encore l’en-
semble des attributs qui caractérise un agent.
Nous utilisons comme notation :
– E
a
pour l’état complet de l’agent A.
– E
ai
pour l’ensemble des attributs qui le ca-
ractérise par rapport à l’action Ac
i
.
– E
aj
pour l’ensemble des attributs qui le ca-
ractérise par rapport aux environnements
Env
j
(les attributs induits).
E
a
est donc l’union de tous les E
ai
et E
aj
relatifs à cet agent. Ces états sont en général
en rapport avec les dynamiques et environ-
nements considérés, mais pas toujours. Par
exemple, la position spatiale d’un agent est en
accord avec la dynamique spatiale, mais son
identifiant n’est en corrélation avec aucune
dynamique particulière.
A cette étape, les modélisateurs-
informaticiens se basent sur l’avis des
modélisateurs et des thématiciens pour dé-
crire les variables du modèle : quels sont
leurs types ? leurs valeurs minimales et
maximales ? les intervalles de changement ?
Quelles sont les valeurs par défaut ? à l’initia-
lisation ? S’agit-il de paramètres de scénario
(donc configurables dans une future interface)
ou non ?. . .
– Les vues V : Les interacteurs I
k
de l’agent
(qui permettent l’influence et la perception)
avec la dynamique associée. Dans le tableau,
D
k
dans la colonne V d’un agent signifie qu’il
participe à la dynamique D
k
et qu’il effectue
donc des influences/perceptions grâce à des
interacteurs dans cette dynamique.
Par facilité d’écriture, nous assignerons à la
colonne V, les dynamiques directement. Cela
sous-entend les interacteurs de l’agent liés à
cette dynamique pour effectuer les actions.
– Les contrôleurs C : L’ensemble des actions
Ac
l
du comportement C considéré, qui gère
les interactions de l’agent dans les dyna-
miques, avec les environnements. Ils seront
formalisés sous forme de pseudo-code.
TABLE 6 – F : Les agents de la SOA
Expert Agent A Agent B . . .
M V C M V C
Expert 1
E
a1
D
1
D
3
Ac
1
7 7 7
E
a2
D
1
Ac
2
7 7 7
E
a3
D
1
Ac
3
7 7 7
E
a7
D
2
Ac
7
7 7 7
E
a8
D
2
Ac
8
7 7 7
. . . . . . . . .
Expert 2
E
a7
D
2
Ac
7
E
b7
D
2
Ac
7
E
a8
D
2
Ac
8
E
b8
D
2
Ac
8
Expert 3 E
a1
D
1
D
3
Ac
1
7 7 7
. . . . . . . . . . . . . . . . . . . . . . . .
Comportement 1 (C
1
)= Ac
1
et Ac
2
Comportement 2 (C
2
)= Ac
3
Comportement 3 (C
3
)= Ac
7
et Ac
8
. . .
Pour rappel, l’algorithme est la sémantique
de l’expression de la résolution d’un pro-
blème. Elle est décrite de diverses manières :
formules mathématiques pures, graphiques
complexes, pseudo-codes. . .. Le pseudo-code
est une syntaxe possible de l’algorithme. Elle
permet de décrire un algorithme de manière à
faciliter le passage dans un langage program-
mation.
Résumé de l’étape F
F : Bilan des agents (par les modélisateurs-
informaticiens) :
– Formaliser chaque comportement pour
chacun des agents sous la forme aMVC :
– M = État de l’agent
– V = Interacteurs dans la dynamique
concernée
– C = Comportements (groupe d’actions)
exprimés sous forme de pseudo-code
Résultat : Décomposition sous la forme aMVC
des agents.
4 Exemple d’évaluation : les ter-
mites selon notre méthodo-
logie de Modélisation Multi-
Comportementale
Pour illustrer nos propos, voici un exemple
bien connu : celui des termites de Mitchell Re-
snick [Res97]. Il est inspiré par le comportement
des termites empilant des copeaux de bois. Les
termites suivent un ensemble de règles simples,
aboutissant à la construction d’une pile unique
de copeaux.
Étapes A, B et C. Ces étapes de la première
phase se concentrent sur les comportements.
Elle se résume ainsi dans le tableau 7.
A : Dans cet exemple, nous distinguons deux
familles d’agents : les agents de type "Termite"
et ceux de type "copeau de Bois". L’agent Bois
est un agent passif alors que l’agent Termite
peut être décrit selon les deux comportements
suivants :
– Comportement d’Errance (priorité = 1) :
Chaque termite commence à errer au hasard.
– Comportement de Manipulation d’un co-
peau de bois (priorité = 2) : S’il rencontre un
copeau de bois, il le prend, il continue à errer
au hasard jusqu’à rencontrer un autre copeau
de bois, il le dépose dans un espace vide à côté
de l’autre.
L’algorithme qui permet le changement de prio-
rité se traduit par :
if prio(Errance) = 1 then
if Rencontrer Bois then
prio(Errance) = 2 et prio(M anip) = 1
end if
end if
if prio(Manip) = 1 then
if Déposer Bois then
prio(Errance) = 1 et prio(M anip) = 2
end if
end if
B : Le comportement d’errance n’a pas besoin
d’être décliné, car l’agent Termite en est l’ac-
teur et l’objet à la fois : il influe sur lui-même
pour se déplacer. Par contre, le comportement
de manipulation doit être décliné : Manipula-
tion.acteur et Manipulation.objet. En effet, le
comportement de manipulation de l’agent Ter-
mite fait que l’agent Bois est manipulé par le
termite. L’acteur de la manipulation est donc
l’agent Termite et l’objet de ce comportement
est l’agent Bois.
La formalisation de ces comportements est la
suivante :
– Comportement d’Errance : En tant que
Termite acteur de l’Errance, ma fonction
active est d’ errer aléatoirement, afin de
trouver un agent Bois, au travers de la dy-
namique spatiale.
– Comportement de Manipulation.acteur :
En tant que Termite acteur de la Manipu-
lation, ma fonction active est de trouver un
agent Bois, le déplacer en errant, afin de le
déposer près d’un autre agent Bois, au tra-
vers de la dynamique spatiale.
TABLE 7 – Étapes A, B et C
Expert Termite
Agent Termite
Errance
Manipulation
Agent Bois (Aucun cpt)
(a) A : Les agents et les experts (Comporte-
ments)
Dynamique Spatiale
Agent Termite
Errance
Manipulation
Agent Bois Présence uniquement
(b) B : Les agents et les dynamiques associées (Com-
portements)
Dynamique Spatiale
Environnement Env. Spatial 2D
Agents Termite, Bois
(c) C : Les dynamiques et environnements du système
– Comportement de Manipulation.objet : En
tant que Bois objet de la Manipulation,
ma fonction passive est d’être déplacé, afin
d’être déposé près d’un autre agent Bois,
au travers de la dynamique spatiale.
Étant donné que le comportement de manipu-
lation impose une présence dans la dynamique
spatiale, nous pouvons déduire que l’agent Ter-
mite a une présence dans cette dynamique. Le
fait que l’agent Bois soit l’objet de cette ma-
nipulation, même s’il n’a pas de comportement
propre, implique qu’il participe aussi à la dyna-
mique spatiale. Le comportement d’errance de
l’agent Termite se déroule aussi dans la dyna-
mique spatiale.
C : L’environnement proposé pour cette dy-
namique spatiale est à deux dimensions (avec
un repère centré par exemple), non accessible,
déterministe, non épisodique, statique et dis-
cret. L’agent Termite n’a pas de connaissance de
l’environnement dans sa totalité, mais il ne per-
çoit que ce qui se trouve à sa position. Tous les
agents participants à cette dynamique ont obli-
gatoirement une position x et y. De plus, ils au-
ront une vitesse (qui sera nulle si l’agent ne se
déplace pas) ainsi qu’une direction (nulle si in-
utile).
Étapes D, E et F. La seconde phase de notre mé-
thodologie sur cet exemple nous amène à nous
intéresser aux actions et se résume ainsi dans le
tableau 8.
D : L’expert des termites considère les deux
comportements et explicite les actions :
TABLE 8 – Étapes D, E et F
Expert Termite
Cpt Errance
(Agent Termite)
Errer
Cpt Manipulation
(Agent Termite)
Prendre le copeau
Errer avec le copeau
Déposer le copeau
S’éloigner du tas
(Agent Bois) (Aucune action)
(a) D : Les agents et les experts (Actions)
Dynamique Spatiale
Cpt Errance
(Agent Termite)
Errer
Cpt Manipulation
(Agent Termite)
Prendre le copeau
Errer avec le copeau
Déposer le copeau
S’éloigner du tas
(Agent Bois) (Présence uniquement)
(b) E : Les agents et les dynamiques (Actions)
Expert Agent Termite Agent Bois
M V C M V C
Termite
E
T −Err
D
Spatiale
Ac
Err
E
Bois
D
Spatiale
C
directe
E
T P rndCp
Ac
P rndCp
E
T ErrCp
Ac
ErrCp
E
T DepoCp
Ac
DepoCp
E
T Eloi
Ac
T Eloi
(c) F : Les agents du système
– Comportement d’Errance : Elle est compo-
sée uniquement de l’action d’Errer aléatoi-
rement.
– Comportement de Manipulation : Lorsque
l’agent Termite rencontre un copeau de bois,
il va Prendre le copeau de bois, puis Errer
avec le copeau jusqu’à en rencontrer un autre.
Ensuite, il devra Déposer le copeau de bois
dans un espace vide à côté de celui-ci. En-
fin, il va S’éloigner du tas de copeaux et re-
prendre le comportement d’Errance.
E : Les modélisateurs formalisent ensuite les
actions du modèle de domaine :
– Comportement d’errance : Comportement par
défaut
– Ac
Err
= Errer aléatoirement, c’est-à-dire
se déplacer d’une certaine distance, à une
certaine vitesse, puis changer sa direction
d’un certain angle.
– Comportement de Manipulation : Compor-
tement lorsque l’instance de l’agent Termite
considérée rencontre une instance Bois1
– Ac
P rndCp
= Prendre le copeau de bois :
Termite se positionne sur Bois1 et influe
sur sa position (de sorte que pos
T erm
=
pos
Bois1
). Il passe au comportement sui-
vant.
– Ac
ErrCp
= Errer avec le copeau de bois
jusqu’à en rencontrer un autre : Termite
se déplace de la même manière qu’Errer,
mais de telle sorte que pos
T erm
= pos
Bois1
pour chaque pas de temps n. Il continue jus-
qu’à croiser une autre instance d’agent Bois
Bois2. Il passe au comportement suivant.
– Ac
DepoCp
= Déposer le copeau de bois à
côté d’un autre copeau : Lorsque Termite
portant une instance d’agent Bois1 ren-
contre Bois2, il recule puis dépose Bois1 à
côté de Bois2 (suivant la métrique de l’envi-
ronnement). Si Termite trouve sur son che-
min Bois2 au moment t, alors on aura :
pos
T erm
(t) = pos
Bois2
et
pos
T erm
(t − 1) = pos
T erm
(t + 1) =
position
Bois2
.
– Ac
Eloi
= S’éloigner du tas de copeaux : Le
Termite recule encore par rapport à la posi-
tion précédente, change de direction d’un
certain angle et recommence à Errer.
Dans notre cas, toutes les actions participent à
une seule et même dynamique, la dynamique
spatiale, exerçant ainsi des influences et percep-
tions dans l’environnement associé.
F : La dernière étape de notre méthodologie
conduit les acteurs du projet à expliciter les en-
sembles des variables qui caractérisent l’agent
par rapport au comportement. Le type agent
"Bois", ayant un corps dans l’environnement
spatial, possède donc les variables suivantes
pour son état :
E
Bois
={id ="id de cette inst. de Bois",
position ="pos (x,y) dans l’espace 2D",
vitesse ="vecteur (i,j), nul",
angle ="direction du Bois, nulle "}
Son contrôleur sera de type "directe", c’est-à-
dire qu’il effectuera les modifications de l’état
de l’agent selon les informations des récepteurs.
Par contre, concernant le termite, nous dénom-
brons davantage de variables, chaque comporte-
ment ayant accès à une subdivision de cet en-
semble. Nous notons :
– E
T ermite
→ l’état complet d’un agent de type
"Termite".
– E
T −EnvSpatial
→ le sous-ensemble en rela-
tion avec les "attributs induits" de l’environ-
nement.
– E
T −n
→ le sous-ensemble en relation avec le
comportement n.
Nous avons donc :
E
T EnvSpat
={id ="id de cette inst. de Termite",
pos ="pos (x,y) dans l’espace 2D",
vit ="vecteur (i,j)",
angle ="direction en radians"}
E
T Err
={}
E
T P rndCp
={id
B1
="id de l’inst. Bois1 renc./portée"}
E
T ErrCp
={id
B1
="id de l’inst. Bois1 renc./portée"}
E
T DepoCp
={id
B1
="id de l’inst. Bois1 renc./portée",
id
B2
="id de l’inst. Bois2 rencontrée"}
E
T Eloi
={}
Dans l’exemple présent, on peut considérer que
l’état complet d’un agent de type Termite est le
suivant (id
Bois1
etid
Bois2
étant nulles dans cer-
tains cas) :
E
T
={id ="id de cette inst. de Termite",
pos ="pos (x,y) dans l’espace 2D",
vit ="vecteur (i,j)",
angle ="direction en radians",
id
B1
="id de l’inst. Bois1 rencontrée/portée",
id
B2
="id de l’inst. Bois2 rencontrée"}
À partir de ce point, nous obtenons les éléments
essentiels pour permettre l’implémentation de la
simulation sur plateforme ou dans un langage
donné.
5 Évaluation et perspectives
Les descriptions de notre approche mé-
thodologique de Modélisation Multi-
Comportementale aident à représenter le
système complexe considéré. Elle permet en
effet de construire progressivement le modèle
final en intégrant petit à petit ses informations
en suivant les différentes étapes synthétisées
sur la Figure 4, et dans laquelle nous illustrons
à quel moment les concepts DOM et aMVC
interviennent.
De par sa construction, notre méthodologie faci-
lite la collaboration entre des thématiciens pour
construire un modèle :
– En effet, chacun peut utiliser son vocabulaire
pour exprimer sa connaissance sur les entités
et ensuite la comparer entre collègues.
– Grâce à l’affinement progressif de cette mé-
thodologie, il est simple de détecter les er-
reurs éventuelles, si chaque expert consulte et
réajuste les informations issues des différents
outils de cette méthodologie.
PROGRAMMEURS,
MODÉLISATEURS-INFORMATICIENS,
MODÉLISATEURS
THÉMATICIENS
MODÉLISATEURS-INFORMATICIENS
MODÉLISATEURS
THÉMATICIENS
MODÉLISATEURS
THÉMATICIENS
THÉMATICIENS
MODÉLISATEURS
Accompagnement d'un expert SOA
B
A
E
D
C F
Comportements
Actions
Modèle de domaine
Modèle opérationnel
Système réel
Modèle de conception
Modèle informatique
Modèle simulé
Formalisation
Opération-
nalisation
Implémentation
Exécution
Modélisation
Initiale
aMVC
DOM
FIGURE 4 – Les étapes de l’approche
méthodologique de Modélisation Multi-
Comportementale
Cette méthodologie facilite aussi la collabora-
tion entre les groupes d’experts, de modélisa-
teurs, de modélisateurs-informaticiens. . . :
– En effet, chaque acteur possède une tâche
bien déterminée en fonction de ses capacités,
tout en ayant une vision globale du système.
– De plus, après l’implémentation de la simula-
tion suivant l’architecture aMVC, il sera aisé
de rectifier et de réutiliser les comportements
et actions des agents, au besoin.
La synergie qu’elle crée permet donc une col-
laboration plus efficace et facilite la création de
comportements complexes.
Les perspectives de ce travail consiste main-
tenant à évaluer ce que nous avons proposé
en la comparant avec d’autres méthodologies
d’abord. Dans un second temps viendra la mise
en place d’une outil d’aide à la conception de
SOA respectant les concepts de DOM et aMVC,
basé sur cette méthodologie puis son adaptation
à notre plateforme existante GEAMAS-NG.
Remerciements
Nous souhaitons remercier Nicolas Sébastien
et Daniel David, anciens membres de l’équipe,
d’avoir contribué aux premières réflexions de
cette méthodologie.
Références
[Coh04] Mike COHN : User stories ap-
plied : for agile software develop-
ment. Addison-Wesley, Boston,
2004.
[DCM
+
12] Mayeul DALLEAU, Stéphane CIC-
CIONE, Jeanne A MORTIMER, Ju-
lie GARNIER, Simon BENHAMOU
et Jérôme BOURJEA : Nesting phe-
nology of marine turtles : insights
from a regional comparative analy-
sis on green turtle (Chelonia my-
das). PloS one, 7(10):e46920, jan-
vier 2012.
[DVM
+
02] Alexis DROGOUL, Diane VAN-
BERGUE, Thomas MEURISSE, Lip
UNIVERSITÉ, Paris PLACE et Jus-
sieu Paris CEDEX : Multi-Agent
Based Simulation : Where are the
Agents ?, Multi-Agent-Based Si-
mulation. In II, Sichman J.S., Bous-
quet F., and Davidsson P. (Eds.),
Proceedings of MABS 2002, Third
International Worshop, pages 89–
104. Springer-Verlag, 2002.
[GCP09] Yassine GANGAT, Rémy COUR-
DIER et Denis PAYET : Démons-
tration : Aménagement énergétique
d’un territoire - une approche par
simulation multi-agents. In Jour-
nées Francophones Systèmes Mul-
tiAgents, JFSMA’09, pages 237–
240, Lyon, France, octobre 2009.
Cepadues.
[GDD
+
10] Yassine GANGAT, Mayeul DAL-
LEAU, Daniel DAVID, Nicolas SE-
BASTIEN et Denis PAYET : Turtles
are the turtles. In European Simu-
lation and Modelling Conference,
ESM’2010, pages 439–442, Has-
selt, Belgium, octobre 2010. Euro-
sis.
[GII
+
09] José Manuel GALÁN, Luis R
IZQUIERDO, Segismundo S IZ-
QUIERDO, José Ignacio SANTOS,
Ricardo DEL OLMO, Adolfo
LÓPEZ-PAREDES et Bruce ED-
MONDS : Errors and artefacts in
agent-based modelling. Journal
of Artificial Societies and Social
Simulation, 12(1):1, 2009.
[GPC12a] Yassine GANGAT, Denis PAYET
et Rémy COURDIER : Another
step toward reusability in agent-
based simulation : Multi-behaviors
& aMVC. In 24th IEEE Interna-
tional Conference on Tools with Ar-
tificial Intelligence (ICTAI 2012),
pages 1112–1119, Athens, Greece,
novembre 2012. IEEE Computer
Society.
[GPC12b] Yassine GANGAT, Denis PAYET et
Rémy COURDIER : Methodology
for a New Agent Architecture Ba-
sed on the MVC Pattern. Lec-
ture Notes in Computer Science
- Artificial Intelligence : Metho-
dology, Systems, and Applications,
755:230–239, septembre 2012.
[PCSR06] Denis PAYET, Rémy COURDIER,
Nicolas SEBASTIEN et Tiana RA-
LAMBONDRAINY : Environment
as support for simplification, reuse
and integration of processes in spa-
tial MAS. 2006 IEEE International
Conference on Information Reuse
Integration, pages 127–131, 2006.
[Ram06] Eric RAMAT : Introduction à la
modélisation et à la simulation à
événements discrets. Modélisation
et simulation multiagents : applica-
tions aux Sciences de l’Homme et
de la Société, pages 49–74, 2006.
[Res97] Mitchel RESNICK : Turtles, ter-
mites, and traffic jams : explora-
tions in massively parallel micro-
worlds. Complex adaptive systems.
MIT Press, 1997.
[RN09] Stuart RUSSELL et Peter NORVIG :
Artificial Intelligence : A Modern
Approach. Prentice Hall Press, Up-
per Saddle River, NJ, USA, 3rd édi-
tion, 2009.
[Rob06] Stewart ROBINSON : Conceptual
modeling for simulation : issues
and research requirements. In Pro-
ceedings of the 38th conference on
Winter simulation, numéro 1994 de
WSC ’06, pages 792–800. Winter
Simulation Conference, 2006.
[Sar99] Robert G SARGENT : Validation
and verification of simulation mo-
dels. In Winter Simulation Confe-
rence WSC Proceedings, WSC ’04,
pages 17–28. Winter Simulation
Conference, 1999.
[Tes65] Lucien TESNIÈRE : Eléments de
syntaxe structurale. Klincksieck,
Paris, 1965.
