Identifier les agents (A 12 )

Le but de cette activité est de trouver ce qui sera considéré comme des agents dans le sys- tème à construire. Seuls les agents qui permettent de construire des AMAS sont intéressants. En effet, seuls des systèmes à milieu intérieur coopératif fournissent une fonction adéquate. Ces agents seront recherchés parmi les entités définies lors de A6S1. Il est ensuite nécessaire,

afin de garantir des règles de bonne utilisation, de stéréotyper la classe de chaque entité sé- lectionnée grâce au stéréotype nommé_{cooperative agent (voir §4.1). Cette activité enrichit} le document architecture logicielle.

Comme nous avons pu le voir dans le chapitre 2, peu de méthodes proposent de telles activités et considèrent les agents de manière "évidente". Par exemple, Tropos propose une identification des agents par agrégation de buts du système (voir §2.4.2.11).

Cette activité peut se succéder plus ou moins régulièrement avec l’activité A₁₃ d’étude des interactions afin de faciliter l’identification, comme il est spécifié par la conditioninter- actions OK de la figure 3.11. En effet, l’identification des agents repose en partie sur l’analyse du parcours des interactions "à risque" provenant de l’environnement.

3.5.3.1 Étudier les entités relativement au domaine (S₁)

Pour chaque entité définie dans A₆S₁, il faut étudier si cette entité :

– est autonome ;

– poursuit un but local ;

– doit interagir avec d’autres entités ;

– possède une vue partielle de l’environnement (ce qui signifie qu’elle ne peut percevoir qu’une partie réduite de son environnement, qu’elle ne possède qu’une connaissance partielle de lui) ;

– possède certaines capacités de négociation.

Les entités qui vérifient les trois premiers critères peuvent être vues comme des agents car elles respectent les caractéristiques minimales attribuées aux agents. Les deux autres critères sont facultatifs. Avant de conclure, des caractéristiques supplémentaires doivent être étudiées, c’est l’objet de l’étape suivante.

Exemple 3.18. Voici une analyse des entités d’ETTO :

3 Les entités actives :

@ Les enseignants (_{Teacher) :}

– Ils sont autonomes, car leur existence ne dépends pas de celles des autres et qui peuvent émettre de nouvelles contraintes de manière indéterminisme du point de vue des autres ;

– Leur but local est de satisfaire leurs contraintes et de donner des cours ;

– Ils peuvent interagir avec des étudiants (Students group) et des salles (Rooms) pour se mettre d’accord sur des horaires et des lieux d’enseignement ;

– Ils ont une vue locale de leur environnement ;

– Ils ont la capacité de négocier avec des étudiants et des salles.

@ Les étudiants (StudentsGroup) :

– Ils sont autonomes ;

– Leur but local est de satisfaire leurs contraintes ;

– Ils peuvent interagir avec des enseignants (Teachers) et des salles (Rooms) pour se mettre d’accord sur des horaires et des lieux d’enseignement ;

– Ils ont une vue locale de leur environnement ;

– Ils ont la capacité de négocier avec des enseignants et des salles.

@ Le gestionnaire des enseignements (CoursesManager) :

– Il est autonome ;

– Il n’a pas de but local, il se contente de répondre aux requêtes et de communiquer les données du NPP aux enseignants et étudiants ;

– Il interagit avec le NPP, les enseignants et les étudiants ;

– Il a une vue locale de son environnement ;

– Il n’a pas la capacité de négocier.

3.5. L'analyse (WD3)

– Il n’est pas autonome, il ne fera aucun changement sur l’environnement de son propre chef ;

– Il n’a pas de but local, il se contente de répondre aux requêtes et de communiquer les états et contraintes des salles aux enseignants et étudiants ;

– Il interagit avec les salles, les enseignants et les étudiants ;

– Il a une vue locale de son environnement ;

– Il n’a pas la capacité de négocier.

3 Les entités passives :

@ Les salles (_{Rooms) :}

– Elles ne sont pas autonomes, elles dépendant du gestionnaire de salles (Rooms Manager) ;

– Elles n’ont pas de but local ;

– Elles interagissent avec le gestionnaire de salles ;

– Elles ont une vue locale de leur environnement ;

– Elles n’ont pas de capacité de négociation.

@ Le plan pédagogique national (_{NPP, National Pedagogical Plan) :}

– Il n’est pas autonome ;

– Il n’a pas de but local ;

– Il interagit avec les gestionnaire des enseignements ;

– Il a une vue locale de son environnement ;

– Il n’a pas la capacité de négocier.

3.5.3.2 Identifier les entités potentiellement coopératives (S2)

Durant ses interactions avec d’autres entités ou avec l’environnement, une entité peut rencontrer des problèmes : le protocole d’interaction peut ne pas être respecté ou l’interac- tion elle-même être une source d’erreurs ou d’échecs (par exemple, incompréhension entre les participants). Ces échecs peuvent être la résultante d’un environnement dynamique, de l’ouverture du système,etc.

Cette identification des entités potentiellement coopératives correspond à un traçage des interactions de l’environnement vers les composants du système (identifiés dans l’activité A10) puis, de ces composants vers l’environnement. Les interactions sont celles présentes

dans l’architecture logicielle. Des cas d’utilisations, jusqu’aux classes, en passant par les dia- grammes de séquences, l’analyste doit tracer le traitement des échecs à la coopération. Les classes les prenant en compte en fin de parcours d’appel (ou événementiel) devront suivre un comportement coopératif pour les traiter au mieux. Une fois identifiées au niveau des classes, ces situations seront appelées Situations Non Coopératives (ou SNC) (voir §1.3). Les entités qui vérifient, au minimum, le dernier critère doivent être marquées durant l’étape suivante.

Exemple 3.19. Seules deux entités sont autonomes, ont un but local et interagissent avec les autres entités. Ces deux entités sont les enseignants (Teacher) et les étudiants (StudentsGroup). Leurs contraintes peuvent changer en temps réel, de ce fait leur environnement est dynamique (les uti- lisateurs changent leurs contraintes de manière imprévisible). Le protocole de communication sera pleinement adapté aux besoins des entités (seules des contraintes portant sur les objets de l’emploi du temps sont exprimables). Elles ne rencontreront alors pas d’échec à la coopération à proprement parler.

Cependant, ces entités peuvent se trouver dans des états dans lesquels elles ne respectent pas toutes leurs contraintes. Ces états sont vus comme des Situations Non Coopératives (SNC) puisqu’alors le système ne répondra pas aux besoins des utilisateurs.

3.5.3.3 Déterminer les agents (S₃)

Les entités identifiées dans les étapes précédentes et correspondant aux critères de co- opération peuvent maintenant être considérées comme des agents. Leurs classes doivent donc être marquées du stéréotype_{cooperative agent, qui indique qu’une classe représente} un agent coopératif (voir §4.1). Les résultats seront consignés dans le document nommé architecture logicielle.

Toutefois, il est possible qu’aucun n’agent n’ait été identifié dans l’étape A12S2. Si l’ana-

lyste est arrivé à cette étape, il est passé par l’activité d’adéquation aux AMAS (A₁₁), pour savoir si le système peut être modélisé comme un AMAS, et donc posséder des agents. Trois cas sont possibles : le système est un AMAS (des entités déjà identifiées sont des agents), le système est composé d’un AMAS (des entités identifiées devront elles-même être décom- posées en AMAS), ou bien les AMAS sont inutiles. Dans le premier cas, l’analyse devrait avoir identifié les agents dans l’étape précédente, sinon, il faut raffiner les interactions entre classes, grâce à l’activité A₁₃. Dans le deuxième cas, une analyse ultérieure devrait mener à une décomposition d’entités en AMAS (comme nous pourrons l’observer dans l’activité A14).