Implémentation du « coeur » des agents

2.1.1. Architecture générale d'un agent

Les agents ont été conçus selon une approche orientée objet. Les classes utilisées sont présentées sur le diagramme de classes UML en figure IV.3. En suivant une cohérence et pour éviter l'existence de dépendances cycliques, nous avons scindé nos agents en deux principales classes, à savoir, « Modèle physique » et son héritière « Noyau décisionnel ». La classe « Modèle physique » comporte les membres qui décrivent la partie « opérative » de l'agent (taille, position, orientation, vitesse ...) ainsi que la mémoire des options et veto considérés. Cette classe définit également les méthodes permettant à l'agent d'agir (de se déplacer) en fonction de l'option sélectionnée. La classe « Noyau décisionnel » porte les comportements et définit les méthodes responsables de la perception et de la cognition de l'agent.

La classe « Comportement » dépend des classes « Modèle physique », « Option » et « Veto ». Cette classe abstraite est étendue pour construire les classes correspondant aux comportements utilisés par l'agent.

Figure IV.3 : Modèle UML d'un agent.

La classe comportement implémente rigoureusement le modèle de comportement proposé au chapitre III. Nous avons ajouté dans les classes option et veto des membres permettant de les décrire. Noyau décisionnel ^Comportement Modèle physique Veto Option Spécialisation 1 Spécialisation 2 Spécialisation Dépendance Composition Notations UML utilisées :

Chapitre IV : Validation du modèle proposé : application à la navigation autonome. 100

2.1.2. Étiquetage des options et veto

Les architectures orientées comportement sont souvent très difficiles à mettre au point, en particulier parce que les données numériques qu'elles manipulent ne peuvent pas être appréhendées facilement. De plus, ces informations sont perdues après la fusion ou après l'arbitrage. Pour aider à la compréhension des options et des choix de l'agent nous proposons « d'étiqueter » les options et les veto.

Le concepteur d'une application choisit les informations contenues dans la désignation des options. Nous pensons qu'il est utile d'indiquer le type et l'instance du comportement qui a proposé l'option. Si ce comportement peut proposer plusieurs alternatives, alors il n'est pas inutile de mentionner à quelle alternative l'option correspond. De cette manière, les désignations associées aux options peuvent servir au concepteur en l'aidant à comprendre le sens des choix (données numériques) de l'agent. Cela s'avère important pour valider le bon fonctionnement d'un agent ou, au contraire, diagnostiquer une erreur. Comme nous le montrerons par la suite, ces informations supplémentaires peuvent également être utilisées par le modèle décisionnel lui-même.

A titre d'exemple, une option proposée par un comportement d'évitement statique attaché à un objet particulier correspondant à un évitement par la gauche peut être notée comme suit dans le tableau IV.4.

Tableau IV.4 : Exemple de désignation d'une option. Type de comportement ^{Instance de l'objet}

concerné 26 Alternative

Éviter obstacle statique 123 Passer à gauche

Remarque : Précisons, que les dénominations ne sont pas attachées aux options mais à

leurs composantes. En effet, après l'exécution de l'étape 3, « spécifier les options brutes », il est possible que la même option soit composée de composantes provenant de diverses options et de divers comportements. C'est pour cela que la description d'une option doit décrire chacune de ses composantes.

Nous venons de décrire les classes qui composent notre agent, nous avons également proposé quelques adaptations afin de faciliter l'application de notre modèle. Nous allons exposer la manière dont l'algorithme de sélection d'actions est implémenté au sein du cycle global d'un agent.

26 Dans un environnement simulé, les objets peuvent être référencés par une clef unique, l'ajout de ce type d'information est à rapprocher de la notion « d'affordance » (cf. chapitre I). Dans un environnement réel il serait difficile de différencier les instances d'une même classe d'objets.

Chapitre IV : Validation du modèle proposé : application à la navigation autonome. 101

2.1.3. Cycle global d'un agent

Notre mécanisme de sélection d'actions s'inscrit dans le cycle perception, cognition, action d'un agent selon l'algorithme ci-dessous.

Algorithme IV.1 : Cycle perception, cognition, action d'un agent.

//Perception

Oublier les options et veto du cycle précédent (étape 1) Instancier les comportements

//Décision

(étape 2) Recevoir les options et veto de chaque comportement (étape 3) spécifier les options brutes

(étape 4) relever les options valides

Si il existe au moins une solution valide alors

(étape 5) Évaluer les options valides (étape 6) Sélectionner la meilleure option

Sinon

Choisir de rester sur place

fin si

//Action

Déplacer le personnage en fonction de l'option considérée

Afin d'appliquer notre modèle, il faut concevoir les comportements qui seront utilisés et implémenter la fonction qui les instancie (étape 1 de l'algorithme). Les comportements sont conçus comme des spécialisations de la classe « comportement »

2.1.4. Identification des comportements

L'une des difficultés de l'approche orientée comportement réside dans la division du problème en un ensemble cohérent de comportements complémentaires. Notons que ce problème est récurrent en informatique, qu'il s'agisse d'identifier des agents ou de simples sous-programmes. Les méthodologies ne proposent que peu de directives précises pour cette étape essentielle. Bien que ne disposant pas d'une méthodologie précise, nous essaierons de suivre les grands principes de l'approche orientée comportement :

● «Encapsulation », au sein d'un comportement, des données et des méthodes relatives à ce qui est pris en compte par ce comportement (perception, décision et action).

● Mise en oeuvre de comportements simples, réactifs lorsque cela est possible, conformément au « Principe de parcimonie » [Drogoul, 1993] qui conseille de toujours vérifier qu'un agent possède bien la granularité minimale nécessaire.

● Construction incrémentale des agents.

Comme pour [Hostetler, 2003], nous débuterons nos développements par un comportement « suivre la voie » qui choisit l'orientation du personnage et un comportement « maintenir la

vitesse » qui décide de la vitesse. Nous développerons ensuite le comportement permettant de

prendre en compte les obstacles statiques, puis le comportement « inertie » destiné à la persistance des choix. Nous développerons le comportement « éviter un obstacle» et terminerons par le comportement « éviter un agent » (qui est conçu comme une spécialisation de l'évitement d'un obstacle statique). La figure IV.4 ci-dessous illustre la manière dont la classe abstraite « comportement » est redéfinie afin de créer le modèle décisionnel complet de l'agent. Le comportement « parasite » est utilisé pour les validations.

Chapitre IV : Validation du modèle proposé : application à la navigation autonome. 102

Figure IV.4 : Spécialisation de la classe « comportement » (Diagramme de classe UML).

Nous venons d'établir la liste des comportements qui seront utilisés par le modèle décisionnel. Nous commençons par développer le comportement permettant à l'agent d'avancer sur une voie libre.