une plateforme générique et paramétrable nécessaire

Le morphisme entre modèle et implémentation est garanti dans Jedi par l’implémentation quasi- systématique d’un élément du modèle formel de Ioda par une classe, une classe abstraite, ou une interface lui étant dédiée. Nous ne décrivons ici que la part émergée de l’implémentation, i.e. la part de l’implé- mentation manipulée par les concepteurs afin d’implémenter les spécifications issues de la méthodologie Ioda. Choix effectués dans Jedi L’approche Ioda est générique, et peut en particulier être utilisée pour implémenter des environnements, ou des modèles de sélection d’interaction très différents. Dans Jedi, nous avons fait le choix de nous restreindre aux environnements, modèles de sélection d’interaction que l’on retrouve le plus souvent en simulation : les environnements euclidiens en deux dimensions, et les modèles de sélection d’interaction réactifs. Nous avons de plus fait le choix d’effectuer l’implémentation en JAVA pour trois raisons :source ou la cible dans interaction.Les langages permettant d’implémenter l’approche Ioda ne se limitent toutefois pas au JAVA, ou plus généralement aux langages orientés-objet. En effet, des prototypes ont pu être implémentés dans le langage Netlogo [WC99] et dans le langage Prolog [Col90].Le détail des principes de calcul de la distance, du calcul du voisinage, et plus généralement les primitives fournies par l’environnement, et leur implémentation sont décrites dans l’annexe A page 259. Il est à noter que l’extension de Jedi à d’autres formes d’environnement ne nécessite pas de modification profonde des diagrammes UML que nous décrivons ici.

Le modèle de sélection d’interaction dans Jedi

Nous restreignons dans Jedi les modèles de sélection d’interaction au modèle réactif basé sur une matrice d’interaction raffinée, que nous avons présenté dans le chapitre précédent. Ce modèle fournit, à notre sens, un bon compromis entre la complexité du modèle utilisé, et la complexité des comportements qu’il est possible de modéliser simplement.En effet, bien le modèle utilisé soit réactif, il est possible de modéliser des agents cognitifs. Par exemple, les primitives de perception et d’actions peuvent se baser sur un modèle fondé sur les croyances et les connaissances de l’entité, et utiliser ainsi des moteurs d’inférences de connaissance que l’on retrouve chez certains agents cognitifs, ou encore les interactions peuvent produire et consommer des buts poursuivis par une entité, et permettre ainsi de modéliser de la planification réactive. Vue d’ensemble sur le modèle Ioda dans Jedi Les éléments logiciels que nous présentons sont résumés sous la forme de diagrammes UML dans les figures 5.1 et 5.2. La plateforme Jedi est actuellement composée de 95 classes et interfaces, totalisant 14820 lignes de code physiques (commentaires et mise en page inclus), équivalentes à 5541 lignes de code logique

ce couple est implémenté sous la forme d’une interface étendant l’interface nommée EntitySi- gnature. La valeur id(S) correspond au nom de l’interface créée, et l’ensemble primitives(S) des primitives abstraites de cette signature sont représentées par des méthodes dans l’interface. Ces interfaces corres- pondent aux éléments contenus dans l’ensemble signatures(I) du 7-uplet définissant une interaction. Le Remarque. Nous nous plaçons dans le cadre des environnements euclidiens en deux dimensions décrits précédemment. Par conséquent, toutes les entités d’une simulation doivent implémenter les pri- mitives abstraites provenant de la signature des entités dans l’environnement, dont un résumé est fourni dans le tableau A.5 page 270 de l’annexe A. Pour des raisons exposées par la suite, ces primitives sont intégrées à l’interface EntitySignature. Remarque. Nous nous plaçons dans le cadre des environnements euclidiens en deux dimensions décrits précédemment. Par conséquent, toutes les entités d’une simulation doivent implémenter les pri- mitives abstraites provenant de la signature des entités dans l’environnement, dont un résumé est fourni dans le tableau A.5 page 270 de l’annexe A. Pour des raisons exposées par la suite, ces primitives sont intégrées à l’interface EntitySignature.