Modélisation structurelle

Une modélisation structurelle permet d’illustrer l’architecture générale d’un système, ses composants ainsi que ses différents types de liens d’interactions. Dans [Muscutariu et Gervais, 2001], les auteurs ont, d’une part, défini un ADL (Architecture Description Language) permettant de modéliser l’infrastructure afin de supporter l’exécution des agents mobiles conformément au standard MASIF [Object Management Group, 2000]. Ils ont, d’autre part, spécifié les éléments nécessaires pour la représentation des mécanismes permettant une transparence à la distribution comme l’accès, la persistance, la migration des

agents et leur localisation. ADL est défini comme étant un profil UML (Unified Modeling Language) nommé «MASIF-DESIGN» qui spécifie les concepts de «région», «cœur d’agence» par des sous-systèmes stéréotypés.

Une plateforme conforme à la norme MASIF définit les éléments suivants: une région, un système d’agents, un cœur d’agence, une place et un agent. Chaque élément de la plateforme offre un ensemble des opérations qui représente les interactions entre les éléments. Ces interactions forment le raffinement nécessaire pour une spécification comportementale, le raffinement qui détaille la spécification opérationnelle d'un système d'agents.

La région est un système d'enregistrement supportant la localisation. Elle est modélisée comme un sous-système stéréotypé. En plus de l'interface MAFFinder spécifié dans MASIF, deux autres groupes d'opérations peuvent être fournis afin de faciliter les services de système d’agents. Comme la plateforme Grasshopper [Breugst et al., 1998], par exemple, qui fournit l'opération lookupCommunicationServer() permettant de connaître le mécanisme de communication sous-jacente que les agents utilisent (par exemple, socket, CORBA or RMI). Ces opérations sont mises en œuvre dans des méthodes avec le prototype défini dans l'interface IRegion (voir la figure 3.7).

Figure 3.7 Sous-système d’une région stéréotypé [Muscutariu et Gervais, 2001]

Le système d’agents est la plateforme qui permet de créer, d’interpréter, d’exécuter, de transférer et de terminer les agents. Il est représenté comme un nœud stéréotypé. Chaque système d'agents a un cœur d’agence et un ou plusieurs places. Le système d’agents agit

comme un conteneur pour exécuter les agents en utilisant les fonctionnalités offertes par le cœur d’agence.

Le cœur d’une agence permet de mettre en œuvre la gestion d'agents. Il est modélisé par un sous-système stéréotypé. En plus des actions spécifiées dans l'interface MAFAgentSystem définie dans la norme MASIF, d'autres opérations peuvent être identifiées afin de permettre la surveillance et le contrôle des agents en cours d'exécution. Dans [Muscutariu et Gervais, 2001], une interface appélée IAgentSystem est ajoutée comme défini dans la plateforme Grasshopper [Breugst et al., 1998] (voir la figure 3.8). Un exemple d'opérations que l’on retrouve dans cette interface est la fonction saveAgent() qui enregistre les données de l'agent afin de permettre une éventuelle reprise.

Figure 3.8 Sous-système d’un cœur d’agence stéréotypé [Muscutariu et Gervais, 2001]

Une place est un contexte qui est défini au sein d’un système d’agents dans lequel s’exécute un agent. Elle est modélisée par un paquetage et peut fournir des fonctions telles que le contrôle d'accès. Le concepteur peut définir, dans une interface nommée SpecialPlaceInterface, les opérations qui offrent des services aux agents situés dans une place SpecialPlace. Il ne peut y avoir qu’une seule SpecialPlace dans un système d’agents (voir la figure 3.9).

Figure 3.9 Paquetage SpecialPlace [Muscutariu et Gervais, 2001]

Un agent est représenté comme un élément stéréotypé. Des informations supplémentaires nécessaires pour la mise en œuvre peuvent être incluses dans le diagramme composant lié à une mise en œuvre d'agent. Encore une fois, l’exemple de la plateforme Grasshopper est utilisé pour identifier ces informations supplémentaires. Puisque la plateforme Grasshopper est un environnement pour un agent typé, la mise en œuvre d'agent modélisé comme un composant doit hériter d'une structure spécifique [Breugst et al., 1998]. Les opérations beforeMove() et afterMove() permettent de préparer la migration de l'agent (c’est-à-dire, la sauvegarde de l’état d’exécution). La figure 3.10 nous présente le diagramme de composant d'agent.

Figure 3.10 Diagramme de composant d'agent [Muscutariu et Gervais, 2001]

Dans [Chhetri et al., 2006], les auteurs proposent une spécification d’une ontologie pour la modélisation des systèmes à base d’agents mobiles. Dans leur article, les auteurs identifient des concepts clés pour la modélisation de systèmes d'agents mobiles. L'identification des principaux concepts et leurs interrelations est généralement une étape préalable à tout exercice de modélisation conceptuelle et reste le précurseur de la spécification formelle. Les concepts identifiés comme base pour décrire la mobilité d’agents sont: les rôles, les agents, le domicile, les itinéraires, les visites, les tâches, l’emplacement, les contraintes de migration et les

ressources. La figure 3.11 illustre les concepts principaux de la mobilité d’agents et leurs corrélations [Chhetri et al., 2006].

Tâche de bas niveau Visite Contrainte de migration Contrainte temporelle Autre contrainte Emplacement Région administrative Région géographique Ressource Réseau Calcul Monétaire Données Hôte Rôle Domicile Itinéraire Agent Place Tâche Tâche de haut niveau Contrainte spatiale

Figure 3.11 Concepts principaux de la mobilité d’agents et leurs corrélations

Rôles

Un rôle est par définition une position ou un but que n'importe quel objet/entité/agent a dans un système, une situation, une organisation, une société ou une relation. Typiquement, un agent dans un système doit acquérir ou prendre au moins un rôle et peut accomplir plusieurs rôles. Dans le contexte de la modélisation des systèmes d'agents mobiles, le rôle est perçu comme un concept principal parce qu'il peut exiger l'attribut de mobilité pour accomplir des responsabilités, des engagements et des obligations. Ainsi, un agent qui a un rôle et possède l'attribut de la mobilité sera un agent mobile. Le concept de rôle qui nécessite la mobilité doit être traité à la phase d'analyse pour développer des systèmes d'agents mobiles.

Agents

En général, un agent peut être défini comme une entité logicielle proactive, réactive, autonome et communicative placée dans un environnement. Dans le contexte d'agents utilisés pour des

applications mobiles et distribuées, la mobilité d'agents est évidemment un concept principal qui doit être modélisé. Comme dans le concept de rôle ou de tâches, la mobilité peut être associée à un agent. Cependant, même dans des cas où ni les rôles ni des tâches n'exigent d'attribut de mobilité, une spécification logicielle peut exiger que les agents soient mobiles pour faire face aux changements inattendus de la disponibilité de ressource (la migration obligatoire dans le cas d'échec hôte, par exemple).

Domicile

La notion de domicile est explicitement prise en compte dans plusieurs systèmes d'agents mobiles. Le domicile fait référence à l'origine ou au lieu de la création d'un agent mobile. Tout agent mobile ou fixe a bel et bien un «foyer» mais cette notion est particulièrement importante lorsqu'un agent possède la capacité de se déplacer et de visiter plusieurs endroits. Dans ce modèle, le domicile est un sous-type de lieu modélisé séparément car il possède des attributs supplémentaires tels que la transmission de messages aux agents et peut avoir des spécifications de contraintes distinctes. Les agents, qui ont des contraintes spatiales comme domicile, doivent être dans une certaine région administrative, par exemple.

Itinéraires

Un itinéraire définit généralement un ordre de visites à divers endroits pour accomplir des tâches spécifiques (à savoir un bas niveau ou sous-tâche). Un itinéraire peut aussi être directement associé à une tâche ou un objectif (c'est à dire un travail de haut niveau nécessitant l'agent de migrer vers certains endroits d'une façon commandée), qui peut alors être précisée en termes de sous-tâches spécifiques à effectuer lors des visites individuelles. En outre, un itinéraire est associé aux contraintes de migration qui déterminent l'ordre de visites dans un itinéraire, la raison et le moment où un itinéraire particulier est choisi et entrepris. Pour assurer que la conception de mobilité est à un niveau abstrait et supporte ainsi la gamme complète d'applications d'agents mobiles, il est essentiel que le concept d'itinéraires soit traité comme un concept de modélisation orthogonal. Cela signifie que les itinéraires et, par conséquent, la mobilité peuvent être associés librement à un autre composant des systèmes d'agents qui pourraient exiger l'attribut de mobilité des agents, des rôles et des tâches.

Visites

Comme discuté dans le cadre des itinéraires, une visite se réfère à un arrêt dans un itinéraire. Une visite implique un emplacement spécifique d’une ou de plusieurs sous-tâches qui doivent être exécutées à cet emplacement. En outre, la migration d'un emplacement vers un autre peut être dictée par des contraintes de migration de niveau de visite (c'est-à-dire spécifiée au niveau d'une visite individuelle) mais aussi par des contraintes de migration indiquées pour l'itinéraire dans l'ensemble.

Tâches

Les tâches sont des activités que l'agent est tenu d’accomplir. Elles sont modélisées de haut niveau ou de bas niveau (des sous-tâches). Une tâche de haut niveau exige normalement la migration et décrit un but ou un travail. Une sous-tâche n'exige pas normalement de mobilité et décrit une activité à être exécuté dans une visite.

Emplacement

Le concept d’emplacement fait partie intégrante de systèmes d'agents mobiles. La plupart des méthodes de modélisation d'agents mobiles tels que mGAIA (Mobile Generic Architecture for Information Availability) et AUML (Agent UML) [Poggi et al., 2003] comprennent des notations pour modéliser l'emplacement. mGAIA, une extension de la méthodologie GAIA, ne traite pas la mobilité dans la phase d'analyse mais elle modélise la mobilité dans la phase de conception [Sutandiyo et al., 2004]. Comme avec Agent UML, qui ne respecte pas le concept orthogonal, le principal inconvénient de cette approche réside dans le fait que seule la mobilité en association avec un agent spécifique est prise en compte. Une nouvelle similitude avec Agent UML est que mGAIA ne développe pas entièrement le concept de visite [Chhetri et al., 2006].

mGAIA et AUML limitent la portée de la place (connu comme l’agence ou le contexte) en modélisant l'emplacement. Une place est l'environnement d'exécution qui permet d’héberger les agents mobiles et supporte leurs interactions avec des systèmes informatiques externes. Les auteurs prennent, dans le cas présent, une vue holistique d'emplacement où il est essentiel

de modéliser des domaines géographiques/administratifs et des hôtes (aussi connu comme des nœuds ou des dispositifs) en plus des places. La modélisation de l'emplacement en ces termes permet de faciliter un plus haut degré de flexibilité et de puissance expressive lors de spécification de l'emplacement, que ce soit dans le cadre d'une visite, une ressource ou une contrainte de migration spatiale. Les concepteurs peuvent ainsi faire varier la précision (en spécifiant la place, l’hôte et la région géographique) et la complexité des spécifications d'accès (en spécifiant l’hôte mobile qui est localisé pendant les périodes dans une région d'administration et/ou géographique spécifique).

Notons que ce modèle de localisation représente explicitement la possibilité de se déplacer entre des lieux d'un hôte donné ainsi que la migration généralement considéré entre les hôtes. Il permet en outre la possibilité d'hôtes et leurs lieux associés ayant la mobilité, par exemple, les appareils mobiles tels que les assistants numériques personnels (PDA) ou des lieux d'exécution sur PDA. Ceci est important car, de plus en plus, les applications d'agents mobiles sont considérées comme étant particulièrement adaptées pour les environnements «pervasifs» qui impliquent des dispositifs mobiles ayant des ressources limitées. Les droits/permissions d'accès seraient un exemple de contraintes de migration spatiales pour une visite ou un itinéraire qui illustre bien l'utilisation de l'emplacement dans la spécification d'application d'agents mobiles. Un autre exemple serait la spécification indirecte d'une variété de contraintes spatiales pour un agent donné, un rôle, une tâche de haut niveau via l'utilisation d'un itinéraire associé à une contrainte spatiale accompagnante. En intégrant les notions complémentaires de régions géographiques/administratives et la place dans la modélisation d'emplacement, les auteurs proposent un paradigme de modélisation plus générale pour les agents mobiles.

Contraintes de migration

En spécifiant la mobilité par des visites et des itinéraires, les contraintes qui déterminent la migration et leurs corrélations avec d'autres concepts d'agents sont souvent ignorées. On note que ces contraintes peuvent être associées à une visite individuelle ainsi que des itinéraires dans son ensemble. Les contraintes de migration spécifient les priorités qui déterminent le

moment, la destination et la raison de la migration. Il existe trois types de contraintes (séparées ou combinées) qui peuvent conduire à la migration:

1. Spatial: Les contraintes spécifient la destination de la migration de l’agent;

2. Temporel: Les contraintes spécifient le moment de la migration de l’agent (y compris les limites de temps);

3. Autres: Ces contraintes comprennent toutes les autres conditions qui sont associés à la migration et peuvent inclure:

 La population d’agents: Si le nombre d'agents à un endroit particulier dépasse un nombre déterminé, l'agent devrait migrer vers un autre endroit où il ferait face à moins de concurrence pour les ressources;

 La indisponibilité des ressources: Si une ressource particulière n'est pas disponible ou accessible, l'agent devrait migrer;

 L’exigence de tâche: Une tâche peut exiger que l'agent soit dans un endroit particulier. Ceci exige la migration de l’agent vers cet endroit;

 La migration forcée: Un agent est forcé de quitter un endroit précis de façon inattendue, par exemple, dans le cas de défaillance de l'hôte.

Ressources

Ce concept est associé aux contraintes de migration, des tâches, des agents et des emplacements. Une tâche peut exiger des ressources spécifiques (par exemple la disponibilité d'une connexion de réseau pour réserver un film) et une contrainte de migration peut dépendre de la disponibilité de certaines ressources. Un agent ou un emplacement peut être associé à (c'est à dire avoir) des ressources spécifiques. Une ressource comprend:

1. Les ressources de calcul; 2. Les ressources de réseau; 3. Les ressources de données;

4. Les ressources monétaires (un agent doit avoir ce qui est comparable aux unités monétaires afin de payer les ressources informatiques qu'ils utilisent).