Table des matières - Gilles Daniel

Sciences sociales computationnelles : simulation sociale multi-agents. 137
La création de ces listes amènera souvent à introduire de nouveaux attributs pour
les agents comme pour l'environnement, dans un va-et-vient constant avec la phase
de conception. Une fois un ensemble cohérent de classes, attributs et règles de
conditions-actions créé, il peut être utile de résumer les dynamiques dans un
diagramme de séquences, un autre type de diagramme UML. Un diagramme de
séquences représente chaque classe d'agents par une ligne verticale, reliées entre elles
par des flèches horizontales pour chaque message ou action allant de l'objet expéditeur
à l'objet destinataire. La séquence des messages est ici symbolisée par
l'ordonnancement des flèches, de haut en bas. Le comportement des agents peut
également être représenté sous forme de diagrammes d'états-transitions ou de
diagrammes d'activité [FOW 99]. Un diagramme d'états-transitions représente chaque
état distinct d'un agent et explique les transitions d'un état à l'autre. Un diagramme
d'activité se concentre plutôt sur la manière dont les agents prennent leurs décisions.
A ce stade du processus de conception, la plupart des aspects internes du modèle
auront été définis, même si de nombreux détails devront sans doute encore être
précisés. L'étape finale consiste à concevoir l'interface utilisateur. Celle-ci se
compose de contrôles tels que des listes déroulantes, champs libres, interrupteurs et
autres boutons pour la saisie des paramètres d'entrée, ainsi que de graphiques divers
et variés représentant les sorties et permettant de suivre le déroulement de la
simulation. Au début, mieux vaut limiter le nombre d'entrées, pour des raisons de
simplicité. Au fur et à mesure que la compréhension du modèle évolue et que de
nouveaux paramètres d'entrée sont identifiés, de nouveaux contrôles peuvent être
ajoutés. De même pour les graphiques de sortie, mieux vaut commencer simplement
et éventuellement ajouter de nouveaux graphiques lorsque le besoin s'en fait sentir.
Bien évidemment, chaque modèle a besoin pour commencer d'au moins un contrôle
d’entrée et de sortie, afin de visualiser le bon déroulement de la simulation, comme
par exemple un compteur indiquant les pas de temps écoulés. Lors des simulations
préliminaires, on peut également avoir besoin de visualiser certaines sorties pour
s'assurer que le modèle répond correctement aux attentes, et repérer les éventuels
bugs. Ces visualisations peuvent ultérieurement être supprimées si elles ne sont pas
utiles pour répondre à la question de recherche.
Avant même d'écrire la première ligne de code du modèle, il est conseillé de
réfléchir à la manière dont la simulation sera testée. Une technique de plus en plus
répandue, appelée tests unitaires, consiste à développer, en parallèle du modèle luimême,
de petites unités de code destinées à tester un aspect particulier du programme.
Chaque fois que le programme est modifié, toutes ces unités sont re-exécutées pour
s'assurer que les changements apportés n'ont pas introduit de nouveau bug. Avec
l'extension du modèle, de nouveaux tests unitaires sont écrits, avec pour but de pouvoir
tout tester. L'idée de tests unitaires vient d'un type de programmation appelé eXtreme
Programing [BEC 99], une méthode de programmation particulièrement efficace pour
le prototypage et la conception itérative, typiques des simulations en recherche.