ADELFE - Glossaire |
| ||
Agent | ![]() |
|
Il n'y pas de définition universelle du terme "agent". La définition "classique" de Ferber peut être utilisée comme point de départ. Un agent est une entité physique ou virtuelle :
Si on travaille avec des agents coopératifs afin de bâtir des systèmes multi-agents adaptatifs (AMAS), l'autonomie est la principale propriété d'un agent. Un agent est capable de décider de son propre comportement. Cette propriété le différencie d'autres entités telles que les objets. De plus, les agents dans les AMAS ont une attitude sociale particulière : ils doivent étre coopératifs. Ainsi, un agent doit pouvoir détecter et traiter des Situations Non Coopératives afin de constamment revenir à un état qu'il juge être coopératif de son point de vue. Par exemple, un agent qui ne possède pas l'information demandée par un autre agent fera tout ce qu'il peut pour trouver un autre agent suceptible de répondre à cette requête. Le cycle de vie d'un agent est :
| ||
Système multi-agent adaptatif (Adaptive Multi-Agent System ou AMAS) | ![]() |
|
Un système multi-agent adaptatif est un système multi-agent capable de changer son comportement lors de l'exécution. Il fait cela pour ajuster son comportement à la dynamicité de son environnement afin d'accomplir la tâche pour laquelle il a été conçu ou afin d'améliorer ses fonctions ou ses performances. Un tel système se caractérise par les points suivants :
La théorie des AMAS (http://www.irit.fr/SMAC) dit que pour tout système fonctionnellement adéquat (i.e. qui réalise la fonction désirée) il y a au moins un système à milieu intérieur coopératif (dont les composants sont en interaction coopérative) qui réalise une fonction équivalente. En d'autres termes, pour concevoir un système réalisant une certaine fonction souhaitée, il suffit d'avoir un système formé d'agents coopératifs. Cette coopération dirige l'attitude sociale de ces agents.
| ||
Aptitude | ![]() |
|
Un agent possède des aptitudes à raisonner à la fois sur ses connaissances et sur ses croyances. Il s'agit plus précisément de connaissances opératoires qui peuvent consister, par exemple, à interpréter un signal en provenance d'un autre agent ou de l'environnement.
| ||
AUML | ![]() |
|
Un langage de modélisation unifié agent (A-UML) a été développé pour exprimer les interactions entre agents dans un SMA. Quand cela est possible, AUML réutilise les notations provenant d'UML et en ajoute de nouvelles. Le site officiel peut se visiter à l'URL http://www.auml.org/.
| ||
Autonomie | ![]() |
|
L'autonomie d'un agent peut s'exprimer de la manière suivante :
| ||
Caractéristiques | ![]() |
|
Une caractéristique est une propriété intrinsèque ou physique d'un agent.
| ||
Classe | ![]() |
|
Une classe est la description d'un ensemble d'objets qui partagent les mêmes opérations,
les mêmes relations et la même sémantique [Booch 98].
| ||
Diagramme de classes | ![]() |
|
Les diagrammes de classes représentent un ensemble de classes, interfaces et collaborations ainsi que leurs relations. Ces diagrammes décrivent la structure statique du système.
| ||
Diagramme de collaboration | ![]() |
|
Un diagramme de collaboration décrit les interactions entre les objets en termes
de messages séquencés. Ces diagrammes représentent une combinaison
des informations provenant des diagrammes de cas d'utilisation, de classes, de séquence qui décrivent à la fois la structure statique et la structure dynamique du système.
| ||
Besoins consensuels | ![]() |
|
Un besoin consensuel est une condition ou une fonctionnalité à laquelle
le système doit se conformer et sur laquelle les utilisateurs finals,
les concepteurs et les développeurs sont d'accord.
| ||
Échec à la coopération | ![]() |
|
Un échec à la coopération correspond à la détection d'une
Situation Non Coopérative.
Un tel échec peut être perçu comme un non respect d'un protocole ou
des interactions néfastes qui peuvent se produire entre le système et
son environnement.
| ||
Patron de conception (Design pattern) | ![]() |
|
Un patron de conception est une solution à un problème rencontré lors de l'étape de conception relativement à un contexte. C'est une manière éprouvée de modéliser des comportements ou des relations, indépendamment du langage utilisé pour l'implantation.
Un patron est décrit dans un certain format (dû à Gamma, Helm, Johnson et Vlissides) indiquant son but, ses motivations, les situations dans lesquelles il peut s'appliquer, sa structure, la solution proposée, ses conséquences d'utilisation, des exemples et d'éventuels patrons auxquels il serait lié.
| ||
Entité | ![]() |
|
Une entité est un acteur au sens UML, un ensemble de rôles cohérents que les utilisateurs des cas d'utilisation jouent quand ils interagissent avec les cas d'utilisation. Dans ADELFE, on va distinguer deux types d'entités :
| ||
Environnement | ![]() |
|
L'environnement d'un agent désigne tout ce qui est extérieur à l'agent. On distingue l'environnement dit social c'est-à-dire les agents qu'il connaît, et l'environnement dit physique constitué des ressources matérielles présentes dans le champ de perception de l'agent ou de ses propres effecteurs. Dans ADELFE, l'environnement doit être caractérisé en utilisant les termes fournis dans [Russel 95] que l'on retrouve aussi dans [Wooldridge 00] et [Lind 01].
| ||
Besoins fonctionnels | ![]() |
|
Un besoin qui spécifie une action que le système doit être capable d'effectuer, sans considération des contraintes physiques; un besoin qui spécifie le comportement du système en entrée et en sortie [Jacobson 99].
| ||
Besoins non fonctionnels | ![]() |
|
Un besoin qui spécifie les propriétés du système, telles que des contraintes environnementales ou d'implantation, de performance, de dépendance à la plate-forme cible, de maintenance, d'extensibilité et de sûreté. Un besoin qui spécifie des contraintes physiques sur un besoin fonctionnel [Jacobson 99].
| ||
Interface utilisateur graphique (GUI) | ![]() |
|
L'interface à travers de laquelle un utilisateur interagit avec le système [Jacobson 99].
| ||
But | ![]() |
|
Un but est un ensemble d'états du monde qu'un agent s'engage à réaliser/maintenir. Un but est donc une situation, mais toutes les situations ne sont pas des buts. Un ensemble d'états du monde n'est généralement pas un but à moins qu'un agent s'engage à le réaliser ou à le maintenir [Eurecom 00].
| ||
Langage d'interaction | ![]() |
|
Un langage d'interaction est un ensemble d'outils nécessaires à un agent pour communiquer directement ou indirectement avec d'autres agents ou vers son environnement.
| ||
Système Multi-Agent System (SMA) | ![]() |
|
Un Système Multi-Agent est un système composé d'un grand nombre d'entités autonomes, nommées agents, qui ont un comportement collectif qui permet d'atteindre une fonction désirér.
| ||
Situation Non Coopérative | ![]() |
|
Quand l'environnement est imprévisible, ou quand le système est ouvert, les algorithmes classiques échouent car le concepteur est incapable de trouver un algorithme capable de lister toutes les possibilités existantes. Le but de la technologie des AMAS est de concevoir des systèmes qui font de leur mieux quand une difficulté est rencontrée. Dans les programmes classiques, ces événements innatendus pourraient être traités par des exceptions. Dans le contexte de la théorie des AMAS, ces "exceptions" - qui expriment les situations inhabituelles auxquelles un agent doit faire face - sont appelées "Situations Non Coopératives" (SNC). Différents types de SNC existent, telles que :
| ||
Paquetage | ![]() |
|
En UML, un paquetage est un mécanisme générique pour organiser des éléments de modélisation en groupes [Booch 98].
| ||
Perception | ![]() |
|
Une perception est un moyen de recevoir de l'information d'un environnement physique ou social (les autres agents).
Aussi, le concepteur doit-il donner certaines capacités de perceptions à un agent.
| ||
Diagramme de protocole | ![]() |
|
Une protocole d'interaction entre agents (AIP) décrit un schéma de communication sous la forme d'une séquence de messages entre agents et des contraintes sur le contenu de ces messages [Odell 01].
| ||
Diagramme de séquence | ![]() |
|
Un diagramme de séquence est un moyen d'illustrer un cas d'utilisation en représentant les collaborations entre entités d'un point de vue temporel.
| ||
Compétences | ![]() |
|
Les compétences d'un agent désignent ses connaissances sur le domaine.
| ||
Diagramme d'états | ![]() |
|
Un diagramme d'états montre le comportement des classes en réponse à des stimuli externes. Ce diagramme modélise le flot de contrôle dynamique d'état en état au sein du système.
| ||
Système | ![]() |
|
Un système est un artefact qui offre un ensemble cohérent de cas d'utilisation à un utilisateur final. Il correspond au logiciel à réaliser.
Le développeur doit considérer à la fois le système et son environnement.
| ||
Cas d'utilisation | ![]() |
|
Un cas d'utilisation est un ensemble de scénarios li´s par un but utilisateur commun. Un sc´nario est une séquence d'étapes décrivant une interaction entre l'utilisateur et le système.
| ||
Représentation du monde | ![]() |
|
Les représentations du monde d'un agent - ou croyances - désignent des connaissances qui sont souvent partiales et partielles sur les compétences d'autres agents (l'environnement social), sur l'environnement physique ou sur l'agent lui-même. L'agent doit toujours pouvoir accéder à ces représentations pour décider de son comportement et, éventuellement, il doit pouvoir les modifier.
| ||
Stereotypes | ||
action | ![]() |
|
Une action est un moyen d’agir sur l’environnement lors de la phase d’action de l’agent. Un attribut « action » représente un paramètre d’une action. Par exemple, la longueur d’un déplacement, la taille maximale d’un message. Une méthode « action » représente une action possible pour l’agent. Par exemple, se déplacer, envoyer un message. Seul l’agent peut faire appel à ses actions, elles sont donc privées. Règles d'utilisation :
| ||
aptitude | ![]() |
|
Les aptitudes reflètent la capacité de l’agent à raisonner à la fois sur les connaissances et sur les croyances (représentations du monde) qu’il possède. Pour un agent logiciel, une aptitude peut se traduire par un moteur d’inférence sur une base de règles, par exemple, ou tout autre traitement sur les perceptions et les représentations. Un attribut stéréotypé « aptitude » représente une donnée ou un paramètre de fonctionnement d’un raisonnement effectué par une méthode stéréotypée « aptitude ». Par exemple, un entier représentant la profondeur de l’exploration d’un arbre de planification. Une méthode stéréotypée « aptitude » représente un raisonnement dont est capable l’agent à l’aide de ses perceptions et représentations du monde et paramétrée par un ou plusieurs attributs stéréotypés « aptitude ». Par exemple, une méthode permettant de planifier des actions, ou un mécanisme de décision. Un attribut ou une méthode stéréotypé « aptitude » ne peut être accédé/affecté ou appelée que par l’agent lui-même, pour traduire son autonomie de décision. Règles d’utilisation :
| ||
characteristic | ![]() |
|
Une caractéristique est une propriété intrinsèque ou physique d’un agent. Un attribut stéréotypé « characteristic » représente une valeur d’une telle propriété. Par exemple, la taille d’un agent, le nombre de pattes d’une fourmi. Une méthode stéréotypée « characteristic » représente un moyen de modifier ou de mettre à jour une propriété d’un agent. Par exemple, une méthode permettant de modifier le nombre de pattes d’une fourmi. Une caractéristique peut être appelée à n’importe quelle phase du cycle de vie d’un agent. Une caractéristique peut être visible ou invisible pour les autres agents.
| ||
cooperative agent | ![]() |
|
Un agent coopératif (‘cooperative’) est un agent qui possède une attitude sociale coopérative. En terme objet, un agent coopératif doit posséder une méthode ‘run’ simulant son cycle de vie « perception-décision-action ». Ceci est effectué par la relation d’héritage forcée à la classe CooperativeAgent. Règles d’utilisation :
| ||
cooperation | ![]() |
|
L’attitude sociale coopérative des agents est mise en oeuvre par l’application de règles de résolution de Situations Non Coopératives. Un agent doit posséder un ensemble de règles (prédicats) permettant la détection de Situations Non Coopératives, ainsi qu’une méthode de résolution de SNC associant aux situations des actions à mener afin d’en sortir. Une méthode stéréotypée « cooperation » est toujours privée et peut être de deux types :
Ces méthodes sont uniquement appelées lors de la phase de décision de l’agent. Règles d’utilisation :
| ||
interaction | ![]() |
|
Le langage d’interaction représente les outils qui permettent à l’agent de communiquer directement ou indirectement avec les autres agents ou avec son environnement. Par exemple, dans une simulation de fourmilière, les agents-fourmis communiquent indirectement, une fourmi dépose de la phéromone qui sera perçue par les autres fourmis, cette phéromone représente une certaine information. Dans ETTO, les BookingAgents communiquent directement en interagissant par échange de messages. Une méthode stéréotypée « interaction » représente la capacité de l’agent à interagir avec d’autres agents ou avec son environnement de manière indirecte. Par exemple, une méthode permettant de consulter sa boîte aux lettres de messages. Un attribut stéréotypé « interaction » représente une donnée ou un paramètre de fonctionnement d’une interaction effectuée par une méthode stéréotypée « interaction ». Par exemple, un attribut représentant le nom de l’agent visible par tous, une boîte aux lettres ou bien un entier désignant la taille maximale d’une boîte aux lettres. Une méthode stéréotypée « interaction » ne peut être appelée que par l’agent lui-même. Un attribut stéréotypé « interaction » peut être accédé par les autres agents. Les interactions se divisent en deux groupes : les perceptions et les actions qui sont des stéréotypes à part entière. (perception et action). Par exemple, une classe MessagesACL représentant une bibliothèque de communication implantant les ACL (request, inform, ...) de la FIPA. Règles d’utilisation :
| ||
perception | ![]() |
|
Une perception est un moyen de recevoir des informations de l’environnement physique ou social (les autres agents). Un attribut « perception » représente une donnée reçue de l’environnement et est forcément de visibilité privée. Par exemple, le nombre d’agent qu’un agent voit à un instant donné, une liste de messages. Une méthode stéréotypée « perception » est un moyen de modifier ou de mettre à jour des attributs « perception ». Ces méthodes ne sont pas nécessairement privées, car d’autres agents peuvent les appeler (pour par exemple, envoyer un message). Par exemple, la méthode permettant de mettre un message dans la boîte aux lettres de l’agent. Règles d’utilisation :
| ||
representation | ![]() |
|
Les représentations du monde d’un agent, ou croyances, portent sur les autres agents (environnement social), sur l’environnement physique et sur lui-même. L’agent doit toujours pouvoir accéder à ses représentations pour décider de son comportement et éventuellement, il doit pouvoir les modifier. Un attribut stéréotypé « representation » permet de représenter une unité de connaissances qui décrit un agent. Par exemple, le nombre d’agent qu’un agent connaît est une connaissance. Une méthode stéréotypée « representation » correspond à une manipulation d’une représentation : accès, modification, ... Par exemple, une méthode qui permet de changer le profil d’un utilisateur. Un attribut ou une méthode stéréotypé « representation » ne peut être accédé/affecté que par l’agent. Les représentations peuvent être représentées par un système multi-agent lorsque celles-ci doivent évoluer (par exemple, le réseau sémantique d’ABROSE (Voir http://www.irit.fr/SMAC/PROJETS/Projet_ABROSE.html). Règles d’utilisation :
| ||
skill | ![]() |
|
Les compétences reflètent des connaissances d’un domaine particulier qui permettent à un agent de réaliser sa fonction partielle. Plus concrètement, pour un agent logiciel, une compétence est un attribut ou une méthode de type fait ou règle. Un attribut stéréotypé « skill » représente une donnée utile pour agir sur le monde, ou bien un paramètre ayant un lien avec une méthode stéréotypée « skill ». Par exemple, un entier représentant une distance minimale à respecter pour un robot devant éviter les obstacles. Une méthode stéréotypée « skill » représente un raisonnement que l’agent peut effectuer uniquement lors de sa phase de décision. Par exemple, une méthode décrivant un raisonnement logique permettant d’éviter les obstacles. Un attribut ou une méthode stéréotypé « skill » ne peut être accédé/affecté ou appelée que par l’agent lui-même, pour traduire son autonomie de décision. Les compétences peuvent être représentées par un système multi-agent lorsque celles-ci doivent évoluer. Règles d’utilisation :
| ||
Bibliographie
|
![]() |