Nous avons détaillé ici l’architecture agent aMVC pour le contexte DOM en montrant qu’elle fait intervenir un niveau supplémentaire de considération multicomportementale.
Cette modélisation commence par le bas (l’agent) et non par le haut (le système). Nous avons d’abord divisé l’environnement en dynamiques, ce qui a créé des sous-ensembles d’état et de comportements dans l’agent. Puis, nous avons découpé l’agent comme un "mille-feuilles" où chaque feuille est associée à un plan comportemental. Enfin, un dernier partition-nement a été fait en fonction des composantes dans chaque plan : leModèle de l’agent, son Contrôleur et sa Vue.
Grâce à cette découpe, nous sommes en mesure de donner une couche comportementale à chaque expert, et, si nécessaire, de diviser encore plus le travail entre les différents experts grâce à la coupe aMVC, en donnant une partie de la couche (M, V ou C) à chacun. Ainsi, cette structuration facilite la création de l’agent dans un cadre collaboratif.
En outre, en utilisant la propriété du modèle aMVC, parmi d’autres avantages, nous sommes en mesure de réutiliser facilement et de personnaliser n’importe quelle partie de n’importe quelle couche comportementale. La séparation avancée dans aMVC favorise la réutilisation logicielle à plusieurs niveaux :
• Modèle : Un même état peut être la cible de plusieurs comportements différents
• Vue : Un même comportement peut avoir plusieurs interacteurs. Par exemple, le
dépla-cement d’un animal imaginaire peut être décliné selon qu’il évolue dans des milieux différents : des ailes pour l’environnement aérien, des pattes pour l’environnement terrestre et des nageoires pour l’environnement aquatique. De plus, ces vues peuvent être réutilisées dans d’autres simulations ou pour d’autres agents du système.
• Contrôleur : Un comportement peut se manifester dans la même simulation chez des
agents différents ou encore dans d’autres simulations du même domaine.
Nous sommes conscients de la complexité de l’architecture interne : il ne s’agit plus de manipuler un "simple" agent, mais un agent composé d’un très grand nombre de briques (d § (2p + 1)), voir fin de Section 5.2.2. Cependant, nous pouvons aussi faire le parallèle avec la Programmation Orientée Objet, qui, elle aussi, entraîne la création d’un grand nombre de classes. L’approche MVC enProgrammation Orientée Objet (POO) génère plus de code que
si nous nous en passons. Cela ne signifie pourtant pas que l’approche MVC est mauvaise : il s’agit de la conséquence d’une plus grande structuration du code. Autant pour une petite application, la programmation "en un seul bloc" contient moins de code et est beaucoup plus légère, mais ce n’est pas une solution à long terme. Le code selon l’approche MVC est conçu de manière à diminuer les coûts de maintenance, d’adaptation et de réutilisation. En POO, cette complexité est partiellement masquée lorsque nous utilisons des outils de haut niveau, des frameworks, qui permettent de faciliter sa mise en œuvre. Nous avons par cet intermédiaire une puissance d’expression importante, une flexibilité que n’a pas une programmation monolithique.
De la même manière, un framework adapté à notre modèle aMVC permettrait de contenir la complexité tout en gardant cette flexibilité et cette puissance d’expression, pour pouvoir
Dans cette approche, nous avons proposé un triple fractionnement de l’agent. Une plate-forme adaptée aux agents aMVC doit gérer, en plus du multidynamisme, ce type de structure. Et notamment :
• Plusieurs couches de Modèles (CM). • Plusieurs couches de Contrôleurs (CC). • Un ensemble de Vues reliées aux dynamiques.
Couches de modèles
Ce sont des ensembles d’états dynamiques liés à un domaine particulier (voir Figures 5.1b et 5.4). À chaque plan comportemental correspond un CM, sous-ensemble de données dyna-miques (états des agents) qui évolue avec le temps en fonction des CC et des lois internes du plan comportemental (qui font la cohérence et la consistance des données).
Dans une simulation, rien n’est statique. L’effet d’une couche de contrôleurs CCa sur celle des modèles CMa1produit une nouvelle couche de données. Soit nous faisons évoluer la couche précédente, soit nous en créons de nouvelles CMa2, et ainsi de suite des CMai, pour les réinjecter dans le système. Dans l’absolu, il est possible d’implémenter un système d’historique qui pourrait être utilisé pour les agents possédant une mémoire à long terme.
De plus, nous utilisons le Modèle actif (voir Section 4.3). Un des avantages est que d’autres sources peuvent changer le modèle. Par exemple, en dehors de ce modèle, dans le "logiciel", si quelqu’un voulait apporter un changement à l’ensemble des CC ou des CM, ce serait possible. Mais la raison la plus importante est que chaque couche de l’ensemble des CM a une vie propre ! En effet, étant donné qu’ils sont un sous-ensemble de données potentiellement dynamiques (états des agents) qui peuvent évoluer avec le temps en raison des CC et des lois internes, des changements se produisent par eux-mêmes sans interaction "extérieure".
CM CC
Dyn1
Différentes couches du système
M
XD123 CM CCM
D13XC
D1blXC
D2 XC
D3AXC
D1rgXC
D3bXV
D1XV
D2XV
D3X Dyn2 Dyn3FIGURE5.4 – Les différentes couches du système
Figure
Couches de contrôleurs
Un des avantages de l’utilisation des CC est que, dans un système complexe, les agents sont regroupés par familles (ou types). Chaque "type" se caractérise par un ensemble de comportements spécifiques : par exemple, le comportement d’un agent Loup Oméga sera le même que tous les autres agents Loup Oméga. En isolant ainsi les comportements des états et des interacteurs, nous pouvons factoriser les comportements et réduire la complexité du modèle.
Une couche de contrôleurs ne contient pas l’ensemble du comportement de l’agent, mais ceux liés à un plan comportemental du système complexe. Elle pourrait être définie par différentes méthodes ou formalismes connus, suivant les possibilités de la plateforme : logique, tableaux, machine de Turing, aUML. . . Ce ne sont que quelques exemples, mais nous pouvons utiliser un large éventail de méthodes de modélisation, selon la façon dont le modélisateur veut modéliser son système, étant donné qu’il s’agit de créer des briques élémentaires.
• 3 Vues pour chaque agent : une Vue dans chaque dynamique.
Dans la Figure 5.4, nous avons choisi de simplifier la représentation en n’illustrant la décomposition que d’un seul agent. En réalité, chaque agent est décomposé selon les plans comportementaux correspondant à son type et est inclus dans la couche adéquate, comme le montre la Figure 5.5. CM4 CM3 CM2 CM1 CC4 CC3 CC2 CC1 CC5 DynC DynB DynA
FIGURE5.5 – Modélisation des couches dans le cas d’un système complexe
Figure
5.4 Conclusion
Dans le chapitre précédent, nous avons défini le concept initial de l’agent aMVC. Ici, nous avons appliqué ce modèle au cadre multidynamique. La décomposition qui en résulte nous a permis de compléter celle obtenue par la méthode DOM . Alors que cette dernière se focalisait sur les seules dynamiques de l’environnement, cette nouvelle décomposition est centrée sur les agents et leurs comportements.
Nous pouvons remarquer une continuité dans la réflexion sur le paradigme agent : les agents sont souvent utilisés lorsque nous cherchons à représenter un système complexe et que nous ne pouvons le faire de manière globale. Nous utilisons ainsi les agents pour décomposer ce système. Dans le concept aMVC que nous proposons, nous cherchons à représenter un agent difficile à appréhender de manière globale. Nous le décomposons par l’intermédiaire de briques élémentaires. La richesse induite par ce cadre implique la complexité constitutionnelle de l’architecture de l’agent.
Cependant, avec l’aide d’un framework adapté, cette complexité peut être maîtrisée, à l’ins-tar des frameworks utilisant MVC en POO. À la fin de ce chapitre, nous avons proposé quelques caractéristiques d’une telle plateforme, en mettant en évidence les différentes couches et leurs relations. Dans le chapitre suivant, nous nous intéresserons à un volet complémentaire à cette proposition aMVC : une méthodologie pour mettre en place une SOA utilisant DOM et aMVC.
Étape A : Identification des comportements du modèle de domaine . . 124 Étape B : Déclinaison et formalisation des comportements du modèle
conceptuel . . . 127 Étape C : Bilan des dynamiques du système du modèle opérationnel . 130
6.3.2 Description sous forme d’actions . . . 132
Étape D : Identification des actions du modèle de domaine . . . 132 Étape E : Formalisation des actions du modèle conceptuel . . . 134 Étape F : Bilan des agents aMVC du système du modèle opérationnel . 135 6.4 Avantages obtenus . . . 139 6.5 Validation par approche comparative . . . 140
6.5.1 Exemple d’évaluation : les termites selon notre méthodologie de Mo-délisation MultiComportementale . . . 142
Étapes A, B et C . . . 142 Étapes D, E et F . . . 145
6.5.2 Positionnement par rapport aux approches de réutilisation des actions 148
Les termites selon IODA . . . 148 Autres approches . . . 150 Synthèse de la comparaison . . . 150
6.5.3 Positionnement par rapport aux approches de réutilisation des com-portements . . . 151
Les termites selon AGR . . . 151 Synthèse de la comparaison . . . 153
6.5.4 Positionnement par rapport aux approches de co-construction . . . 153 6.6 Conclusion . . . 153
plexe, suivant le paradigme agent. Elle se fait par une décomposition par des éléments à la fois simples et fondamentaux pour décrire le système, sous forme de tableaux synoptiques. Elle découpe le système en cellules pour obtenir une vision thématique des agents et explorer les divers aspects de leurs comportements. Ensuite, nous modélisons l’agent comme étant un agrégat de ces cellules. Cette démarche aide à la modélisation du système complexe étudié.
Parallèlement, cette approche permet de codifier, de traduire et d’intégrer la connaissance provenant de disciplines différentes dans le modèle. Elle offre aussi une représentation du mo-dèle, permettant sa cohérence et sa consistance malgré la pluridisciplinarité, avec différents niveaux d’abstraction possible. Elle aide à faire le lien entre les différents thématiciens, ce qui facilite la co-construction de modèles. Enfin, elle donne la possibilité à tous les acteurs de tra-vailler en synergie, par l’intermédiaire des supports communs que forme cette décomposition élémentaire.