AUML & La Modélisation des Systèmes à base D’Agents

Télécharger le fichier pdf d’un mémoire de fin d’études

Approche orientée-agent et approche orientée-objet

Au regard des caractéristiques d’agent, il apparaît que l’approche orientée-agent dans le développement de logiciel consiste en une décomposition du problème en agents ayant des interactions, une autonomie, et un objectif spécifique à atteindre. Les concepts clés d’abstraction liés à un système orienté-agent sont : agent, interaction, organisation.
Bien qu’il existe une similarité superficielle entre objet et agent, la terminologie objet n’est pas adaptée aux systèmes agents :
 les objets sont généralement passifs alors que les agents sont permanents actifs;
 les agents sont autonomes et responsables de leurs actions alors que les objets n’en sont toujours pas;
 on ne peut prévoir tous les comportements des agents dans les systèmes;
Les Systèmes Multi-Agents Temps Réel
 l’approche orientée-objet ne fournit pas un ensemble adéquat de concepts et de mécanismes pour modéliser les systèmes complexes dans lesquels les rapports évoluent dynamiquement;
 certains chercheurs définissent un agent comme un objet actif ayant une autonomie et un objectif. [Sab01]

Avantages et Inconvénients de l’approche centrée sur l’agent

Une nouvelle approche émerge pour palier aux manques des approches traditionnelles, il s’agit de l’approche orientée-agent. Parmi ces avantages :

La Modélisation des systèmes

L’approche OA offre une façon beaucoup plus naturelle de concevoir ce type de système. Selon [Gar03] trois grandes techniques sont utilisées pour la modélisation des SMA : l’approche centrée sur les tâches, l’approche centrée sur les buts et celle centrée sur les rôles. La première se base sur le fait que chaque agent peut effectuer des tâches, et que chaque tâche peut être effectuée par un ou plusieurs agents. Avec cette approche, il faut déterminer les tâches à effectuer pour l’atteinte du but global. Par la suite, il faut déterminer un ordonnancement et une cédule des tâches que chaque agent doit exécuter et coordonner leurs activités. La deuxième approche, celle centrée sur les buts, demande la spécification des buts intermédiaires des agents (ou sous systèmes) qui sont impératifs
à l’atteinte du but global (but du système). De cette façon, lorsque tous les buts secondaires sont rencontrés, le but global est atteint et le système a donc atteint son objectif (les tâches pour lesquelles le système a été conçu). La troisième approche, soit celle centrée sur les rôles, nécessite une abstraction plus élevée que les deux premières. Les agents sont plutôt modélisés en fonction de leurs responsabilités au sein du groupe (sous-système ou système). Plusieurs méthodologies ont été développées pour chacune de ces approches. Cependant, de l’avis de la majorité des chercheurs dans le domaine, une méthodologie OA en particulier ne peut être utilisée pour la modélisation de tous les types de SMA.
La majorité des méthodologies développées s’appliquent à un ou quelques domaines en particulier mais ne sont pas appropriées dans d’autres circonstances. Que l’on utilise une méthodologie spécifique pour la modélisation d’un système ou que l’on applique des concepts génériques comme l’approche centrée sur les rôles, les buts ou celle centrée sur les tâches, l’approche agent offre une façon beaucoup plus naturelle de développer les systèmes « intelligents » et distribués d’aujourd’hui. L’approche OA permet une factorisation (décomposition en sous-systèmes) et une délégation naturelle des tâches, buts et/ou rôles à ces sous-systèmes et leurs agents. L’approche permet aussi de déterminer les protocoles de communication, d’interaction, de coordination et de négociation entre les agents. De cette façon, il est possible de superposer le problème réel sur le système à base d’agents.

La Tolérance aux fautes

Les systèmes à base d’agents possèdent un avantage marqué au niveau de la tolérance aux fautes par rapport aux systèmes centralisés. La majorité des SMA sont distribués sur plusieurs machines et effectuent les différentes tâches en parallèle et/ou en concurrence. Par exemple, prenons plusieurs agents sur différents ordinateurs qui ont les qualifications requises pour effectuer des tâches de même nature. Donc, si une machine (ou un sous-système du SMA) est indisponible pour quelque raison que ce soit, les tâches à effectuer par ce sous-système peuvent être redistribuées à d’autres agents ayant la capacité d’effectuer ces dernières sur d’autres machines.

L’Autonomie des systèmes

L’approche OA suppose la mise en application des concepts inhérents aux agents. Il faut donc que les agents d’un système possèdent une certaine autonomie, un certain degré d’intelligence artificielle, une représentation de leur environnement, qu’ils puissent interagir avec celui-ci, qu’ils soient capables de « prendre de l’initiative », de communiquer entre eux et qu’ils soient capables de s’adapter à différentes situations. La nécessité de ces concepts à différents niveaux d’un programme indique un certain besoin d’autonomie et valide en quelque sorte le choix de l’approche SMA plutôt que l’approche OO.

Autres avantages

Plusieurs autres avantages sont attribuables aux agents et SMA :
 La facilité de « changement d’échelle d’une architecture » (scalability) car plusieurs agents peuvent s’ajouter ou se retirer dynamiquement d’un système.
 La configuration automatique d’un SMA grâce à la plus grande « proximité » du monde réel des agents.
 La résolution plus rapide et efficace de problèmes en exploitant le parallélisme.
 La réduction des coûts de développement de logiciel : plus un logiciel est modulaire, plus la complexité et les coûts de développement diminuent.
 Flexibilité des systèmes : les systèmes sont composés de plusieurs agents ayant des habiletés différentes, ils peuvent donc résoudre différents problèmes (ils peuvent aussi résoudre des problèmes en coopérant et en se partageant les tâches dépendamment des capacités de chacun).

Les Difficultés de l’approche orientée-agent

Dans de nombreuses situations, le développement OA procure plusieurs avantages marqués par rapport à l’approche OO. Cependant, l’utilisation de ce nouveau paradigme engendre plusieurs difficultés. Voyons la principale difficulté de cette approche.

Méthodologies non-standardisées

Le développement d’applications OO permet l’utilisation de standards comme OMT et UML (Unified Modeling Language) pour la modélisation, la conception et l’implémentation. Cependant, la même chose n’est pas possible lorsque l’on développe une application OA. Aucun standard n’existe encore aux niveaux des méthodologies et de la technique de développement. Quelques standards sont définis par la FIPA (Foundation for Intelligent Physical Agents) pour l’implémentation des SMA [FIPA97]. Par contre, les standards définissent beaucoup plus le niveau architectural et les modes de communication que le niveau conceptuel qu’impliquent la modélisation et la conception. Si nous voulons impérativement utiliser une méthodologie pour la création d’un SMA, il faut donc déterminer la méthodologie qui représente le mieux le type de système à développer. Un tel choix suppose une connaissance relativement bonne des différentes méthodologies disponibles, ce qui est rarement le cas [Gar03].

Les Systèmes Temps Réel

Définition

De nombreuses définitions ont été proposées pour clarifier la notion de système temps réel (STR). Cependant, comme les caractéristiques des systèmes temps réel sont très variées, aucune des définitions proposées n’est vraiment complète pour tenir compte de tous les domaines d’applications. En effet, selon l’aspect abordé dans les STR, on choisit une définition qui s’approche le plus de la problématique traitée. Ainsi, on assimile, selon le cas, un système temps réel à un système rapide, à un système en interaction directe avec un procédé physique, à un système réactif, à un système qui ne fournit pas de réponse en différé, à un système avec un comportement prédictible, à un système qui travaille sur des données fraîches, à un système robuste, etc.
Il existe différentes définitions d’un système temps réel. Par exemple J-P Haton et ses coauteurs [Hat91] définissent le fonctionnement temps réel en référence au temps de réponse d’un système, c’est-à-dire le temps utilisé par le système pour identifier un évènement extérieur et y répondre. I. Benyahia [Ben93] définit un système temps réel comme un système capable de répondre à un évènement avant une date fixée par le processus extérieur. Toutes ces définitions ont en commun la notion de temps de réponse. Cette notion est définie par le délai limite nécessaire pour émettre un résultat.
Une définition plus générale qui résume ce que doit être un système temps réel est la suivante : ‘’ c’est un système dont le comportement dépend non seulement de l’exactitude des traitements effectués, mais également de l’instant où les résultats de ces traitements sont fournis. Dans ces systèmes, un retard dans la production d’un résultat est considéré comme une erreur, pouvant souvent entraîner de graves conséquences [Kav92].
On distingue, en général, deux principaux types de tâches temps réel : (1) à échéances dures ou strictes (hard), où le non respect de l’échéance peut provoquer une exception dans le système, et peut avoir de graves conséquences sur l’application, (2) à échéances molles, ou relatives (soft), où le retard d’une tâche ne provoque pas d’exception, c.à.d. que les tâches de ce type peuvent manquer leurs échéances occasionnellement sans engendrer de graves conséquences [Sad04].

Les Caractéristiques d’un système temps réel

Le temps de réponse d’un système temps réel est une caractéristique importante, mais il ne représente pas le seul paramètre à prendre en compte. Dans [Dod89], les auteurs ont défini les caractéristiques suivantes d’un système temps réel :
 La Réactivité : Elle peut être définie comme étant la capacité à réagir à des stimulations extérieures. Un système temps réel doit être réactif face aux événements externes asynchrones de l’environnement. Il doit pouvoir classer ces événements en fonction de leur urgence et donner la priorité au plus urgent. Il doit également focaliser ses ressources en fonction des données. Dans la majorité des applications temps réel (surveillance, procédés industriels,…), ces événements asynchrones sont délivrés par des capteurs.
 L’Adaptabilité : Elle peut être définie comme la capacité du système à adapter son comportement à de nouvelles données. Contrairement à la réactivité, cette caractéristique n’est en général que partiellement traitée. Certains modèles ne sont pas facilement extensibles ou modifiables [Gue96].  Les Types d’interaction (forte/faible) : Toute application temps réel est en interaction (forte ou faible selon les cas) avec son environnement. Lequel environnement peut être un procédé industriel, un moteur d’avion, un malade, etc. la nature de l’environnement a une incidence directe sur la ‘’criticité’’ des actions entreprises dans une application temps réel. La notion de ‘’criticité’’ (ou ‘’criticality en anglais) est utilisée comme critère pour pouvoir classer les applications temps réel selon la sévérité, en termes de coût engendré par le non respect des contraintes temporelles. Ainsi, on classe les applications temps réel en deux types : les applications à contraintes temporelles strictes (‘’hard real time applications’’), où le non respect des contraintes de temps peut conduire à des défaillances avec des conséquences pouvant être graves, et les applications à contraintes temporelles relatives (‘’soft real time applications’’), où le dépassement des échéances est considéré comme une faute bénigne [Duv01].
 Le Déterminisme : c’est le but à atteindre pour tout système temps réel, pour assurer la prévisibilité, i.e., enlever toute incertitude sur le comportement des activités (individuelles et mises ensemble). Dans un STR dur (à contraintes strictes), on cherche à ce que toutes les échéances soient respectées, alors que dans un STR à contraintes relatives, on cherche à minimiser le retard moyen des activités, ou maximiser le nombre de tâches qui respectent leurs échéances par exemple [Sad04].

Les Systèmes Multi-Agents Temps Réel

Introduction

De nos jours, l’incorporation du paradigme des systèmes multi-agent dans les systèmes temps réel offre la flexibilité, l’adaptabilité et la distribution. Ces caractéristiques aident à relever les nouveaux défis dans ce domaine comparé aux applications temps réel traditionnelles.
D’après [Eur00], ‘’Si on se concentre dans les sytèmes temps réel distribués, on peut distinguer plusieurs nœuds indépendants qui travails pour achever des objectifs commun dans un environnement ayant des contraintes temporelles strict. Le developpement de nouvelles applications dans le domaine des sytèmes temps réel distribué à ajouter de la compléxité aux systèmes de ce type. En générale, ces systèmes ont une distribution physique du problème et leurs nœuds doivent partager les ressources limitées. Par conséquent, il est nécessaire pour ces nœuds de travailler de maniére coordonée et de s’engager à réaliser les tâches spécifique ‘’.
Le paradigme agent semble être très puissant et très prométeux pour être utilisé dans le développement des systèmes complexe, en particulier dans le développement des sytèmes temps réel d’où émerge le concept des sytèmes multi-agent temps réel [Eur00].

Définition

Selon Botti et al. [Bot95], un agent temps réel (ATR) est un agent ayant des contraintes temporelles dans quelques un de ses responsabilités. Généralement, un ATR (Agent Temps Réel) est un agent composé d’une série de tâches, dont quelques unes ont des contraintes temporelles. Dans ces agents, il est aussi nécessaire de prendre en compte l’exactitude temporelle, qui est exprimé au moyen d’un ensemble de restrictions temporelles imposé par l’environnement. Par conséquent l’ATR assure la satisfaction de ses restrictions temporelles. Si le non respect de ces restrictions temporelles engendre des conséquences catastrophiques, l’agent est de type Hard. D’autre part, si l’insatisfaction de ces mêmes restrictions n’engendre qu’une dégradation dans les réponses alors l’agent est de type Soft.
La définition suivante d’un système multi-agents temps réel est basée sur la définition ci-dessus d’un agent temps réel :
‘’Un système multi-agents temps réel est un système multi-agents où au moins un de ses agents est un agent temps réel’’ [Jul04a].
Dans la section suivante, nous allons analyser brièvement les principales méthodologies de développement de SMA temps réel que nous avons recensées dans la littérature. Il y a, parmi celles-ci, certaines sur lesquelles nous ne possédons pas assez d’informations, nous nous permettons de faire une étude plus détaillée. Il nous semble cependant que ces méthodologies sont les plus représentatives des méthodologies de développement des SMA temps réel existantes.

Travaux Similaires

Introduction

L’approche orienté agent consiste à décomposer les problèmes en agents autonomes. Ces agents peuvent interagir à haut niveau et sont organisés en sociétés. Cette organisation sert à décrire l’activité du système. L’identification du rôle et des capacités de chaque agent y est donc essentielle.
Selon [Woo00b], les approches orientée-objets existantes ne capturent pas convenablement le comportement flexible et autonome de résolution de problèmes, la richesse des interactions et la complexité des structures organisationnelles d’un système multi-agents temps réel.
Pour faire face à ce problème que différentes méthodologies développées sur la base de notations ou méthodes orientées-objet ont vu le jour. Parmi elles nous trouvons : la Méthodologie RT-Message [Jul04b] ; la Méthodologie BDI-ASDP étendue pour le temps réel [Mel05] ; et la Méthode de développement de Lichen Zhang [Zha06]. Dans les paragraphes qui suivent nous allons essayer d’analyser ces trois méthodologies de développement des systèmes multi-agents temps réel (SMATR) en se basant surtout sur les propriétés associés à l’activité d’analyse du processus de développement de chacune, en guise de première contribution à ce travail.

Analyse des Méthodologies de Développement des SMA-Temps Réel

Durant les dernières années, il a été reconnu largement que la conception et le développement des systèmes multi-agents a été pour une grande part ad hoc. Luck et al. (2003) ont noté que : ‘’ il existe des méthodologies de développement orientées objet, mais celles ci ne sont pas applicable de même pour les systèmes orientés agents qui utilisent des méthodes inappropriées ou ad hoc ‘’ [Kou07].
Plusieurs propositions méthodologiques pour le développement logiciel (‘’software enginieering’’) existent et peuvent être appliquées aux systèmes à base d’agents. Quelques une d’entre elles proviennent du domaine des systèmes à base de connaissances [Fer98], d’autres sont directement centré sur les propriétés des agents [Omi01], et d’autres sont des extensions de méthodologies de développement orienté objet et de langages, comme UML [Ode00]. Seulement très peu de ces méthodologies tiennent compte des comportements temporels des agents [Mel05].
Parmi ces méthodologies qui adressent directement la conception des systèmes multi agents temps réel, nous nous sommes intéressés aux trois suivantes : la Méthodologie RT-Message [Jul04b] ; la Méthodologie BDI-ASDP étendue pour le temps réel [Mel05] ; et la Méthode de développement de Lichen Zhang [Zha06].
La méthodologie ‘’RT-Message’’ [Jul04b] est un ensemble d’idées flexibles et adaptables, qui couvrent les phases d’analyses, de conception et d’implémentation des systèmes multi-agents temps réel. Elle utilise les mêmes modèles qu’utilise la méthodologie ‘’Message’’ [Mes99] [Mes01], lors de l’activité d’analyse auxquels elle ajoute quelques extensions temporelles dans le but de spécifier les comportements des agents temps réel. Dans la phase de conception, RT-Message propose l’utilisation de l’architecture SIMBA afin de modéliser les systèmes multi agent temps réel. [Jul04a]
Le deuxième travail est celui de Melián et al. [Mel05], son objectif principal est d’étendre la méthodologie de développement basé sur les agents BDI, afin de permettre la modélisation des systèmes multi-agent temps réel, et son application à un exemple pratique. Les auteurs de ce travail ont ainsi utilisés ‘’la méthodologie BDI-ASDP’’ (BDI-Agent Software Development Process) [Ein03], qui est basée sur la décomposition du problème en beliefs, desires et intentions, et ont étendue de capacité de modélisation des contraintes temporelles à travers les diagrammes de temps (timing diagrams) proposés dans UML 2.0. [Mel05]

Le Langage de Modélisation AUML

Rappel sur AUML

UML a unifié et formalisé les méthodes de plusieurs approches, incluant les méthodes de Booch, Rumbaugh, Jacobson, et Odell. Bauer a noté dans [Bau01b] ‘’qu’UML soufre d’insuffisance pour la modélisation des systèmes à base d’agents [Bau00b]’’. Principalement, cela est dû à deux raisons majeurs : premièrement, comparé aux objets, les agents sont actives parce qu’ils peuvent prendre l’initiative et ont un contrôle globale sur leurs comportements. Deuxièmement, les agents n’interagissent pas de façon individuel mais plutôt en coopération ou en coordination avec d’autres agents. Les systèmes multi-agents sont des communautés sociales de membres interdépendants qui agissent individuellement.
De ce fait, plusieurs langages de modélisation des systèmes agents sont proposés, parmi eux nous citons : Agent Modelling Language (AML) [Tre05] ; et Agent UML1 (AUML) [Hah08].
AUML (Agent Unified Modeling Language) est un langage offrant de nombreux artefacts en vue de la construction d’un système logiciel. Avec ses vues et ses divers types de diagrammes, AUML offre la possibilité de modéliser la structure statique d’un système, ses besoins fonctionnels, en plus de son comportement collectif et individuel [Gag07].
AUML est un langage de modélisation graphique qui a été standardisé par FIPA2 (Foundation for Intelligent Physical Agents) comité technique de modélisation. Il a été proposé comme une extension du langage de modélisation unifié (UML). Jusqu’ à maintenant il n y’a pas de standard reconnu pour la modélisation des systèmes multi-agents et AUML a émergé comme un candidat pour assumer une tel position. Il utilise les caractéristiques de ‘’décomposition’’, ‘’d’abstraction’’, et ‘’d’organisation’’, qui réduisent la complexité de développement de logiciel. AUML décompose le système en petites parties d’objets, de modèles, de cas d’utilisation ou de classes, et d’actions opérationnelles. Concernant ‘’l’abstraction’’, elle offre une vue spécialisée abstraite de la modélisation (classe, cas d’utilisation, diagramme, interface, etc.).
‘’L’organisation’’ orientée agent définie un ensemble d’éléments et de notations comme la spécification des besoins pour la modélisation du domaine. Son objective est de fournir un modèle et une architecture interne d’un système agent. Elle offre généralement quelques Framework (classe, diagramme, interface, etc.) pour voir comment les agents peuvent être construits dans un système.
La partie principale d’AUML est les mécanismes de modélisation des protocoles d’interaction des systèmes multi-agents. Cela est réalisé par l’introduction d’une nouvelle classe de diagramme à UML : ‘’diagramme de Protocole’’. Ces diagrammes étendent les diagrammes de séquence en incluant : ‘les rôles d’agents’, ‘multithreaded lifelines’, ‘protocole templates’, etc. [Gag07].

Les Incohérences du Langage AUML

AUML tout comme UML [Ake02] offre la possibilité de décrire plusieurs “vues” d’un même système. Cependant, ces différentes vues peuvent être en conflit puisqu’elles peuvent présenter des incohérences. De plus, l’expérience montre que de très nombreuses fautes de modélisation sont perceptibles à travers la détection d’incohérences [Mus03] [Reg99] [Mor00] [Ast98]. Selon [Mal05], une incohérence est la violation d’une propriété associée au langage AUML qui doit être respectée par tout modèle AUML. En effet, la cohérence peut concerner un seul diagramme (on parle de cohérence intra-diagramme) ou plusieurs diagrammes (on parle de cohérence inter-diagrammes). Parmi les incohérences intra-diagramme, on peut mentionner la présence de cycles dans un graphe d’héritage pour un diagramme de classes, l’existence d’une transition dont l’état source est un état final dans un diagramme d’états-transitions et le non respect de l’ordre d’envoi de message d’un point de synchronisation dans un diagramme de communication (par exemple, le numéro du message bloqué est inférieur au numéro du message bloquant). La représentation des systèmes complexes, en utilisant les différents diagrammes cités précédemment, peut engendrer des incohérences inter-diagrammes. On peut citer, entre autres, un événement appel d’un diagramme d’états-transitions qui ne figure pas comme méthode dans la classe correspondante. Aussi, un envoi de message (appel de procédure) dans un diagramme de communication ne figurant pas comme une méthode à visibilité appropriée dans la classe de l’objet destinataire. Par ailleurs, l’état final d’un système fini ne se compose pas de différents états finaux des différents objets impliqués dans le diagramme de communication [Gag07].
Dans la section suivante nous allons présenter quatre des principaux diagrammes d’AUML, ainsi que les travaux qui les considèrent.

Les Principales Représentations d’Agent UML

Comme nous l’avons indiqué dans l’introduction, Agent UML est une extension d’UML afin de prendre en compte les notions agent que ce dernier n’a pas. Puisqu’Agent UML est une extension, il hérite des représentations proposées par UML. En voici la liste :
1. Diagrammes de séquence
2. Diagramme de collaboration
3. Diagramme d’activité
4. Diagramme d’état transition
5. Diagramme de cas d’utilisation
6. Diagramme de classe
7. Diagramme d’objets
8. Packages
9. Diagramme de composants
10. Diagramme de déploiement
Les cinq premières représentations correspondent à des diagrammes dynamiques alors que les quatre dernières correspondent à des diagrammes statiques. Nous rappelons que notre but est de déterminer quelles représentations ont besoin d’être modifiées ou améliorées pour pendre en charge les spécificités des systèmes multi-agent temps réel. Les diagrammes de séquence ont déjà été modifiés puisqu’ils portent maintenant le nom de diagrammes de protocole [Ode00] [Bau00b]. Ces diagrammes de protocole ont été eux aussi améliorés par Huget [Hug02b], et correspondent à la représentation des protocoles d’interaction. Les diagrammes de classe ont aussi été modifiés. Il ne faut pas oublier qu’un agent diffère d’un objet par conséquent le diagramme de classes qui permet de représenter les classes constituant le système sera aussi modifié.
Nous trouvons deux approches pour ces diagrammes de classes : celle de Bauer [Bau01b] et celle de Huget [Hug02c]. La première approche [Bau01b], propose d’interpréter l’acceptation des actes de communication dans les diagrammes de classe agent. Selon Huget [Hug02c], cette approche est irréaliste dés que les agents englobent plusieurs protocoles complexes. ‘’L’agent head automata’’ ajouté par Bauer au diagramme de classe pose problème, il contient les actes de communication aussi bien que les actions déclenchés par les messages reçus. Cette interprétation des actes de communication ne doit pas être à l’intérieur des diagrammes de classe agent mais à l’extérieure. Il sera mieux d’utiliser les diagrammes de séquence si les concepteurs veulent représentés les protocoles ou les diagrammes d’activités s’ils veulent représentés les actions déclenchées par les messages. De plus, si les concepteurs insèrent ‘’l’agent head automota’’ dans les diagrammes de classe agent, ils violent un des principes d’UML portant sur le fait ‘’qu’un diagramme est uniquement utilisé pour décrire une seul vue du système’’ : les diagrammes de classe agent sont utilisés pour représenter le contenu des agents et non comment ces derniers réalisent les actions liées aux messages. De ce fait, nous nous sommes basés sur la deuxième proposition [Hug02c] jugée intéressante et qui sera décrite ci-dessous.
Dans les paragraphes qui suivent nous rappelons brièvement à quoi servent ces représentations (diagrammes de cas d’utilisation, de classe, de protocole, et d’état transition) et nous présentons les principaux travaux qui les considérent.

Les Diagrammes de Cas D’utilisation AUML

Introduction

Les diagrammes de cas d’utilisation sont utilisés pour définir des cas d’utilisation du système et donnent une analyse du système. Ils représentent les cas d’utilisation, les acteurs, et les relations qui existent entre les acteurs et les cas d’utilisation. Un cas d’utilisation peut être vu comme un scénario dans le système, par exemple quand un utilisateur essaye de se connecter au système et un mot de passe est nécessaire. Dans les systèmes multi-agents, les cas d’utilisation sont intéressants lorsqu’il s’agit de réaliser l’analyse des besoins (requirement analysis). Ils sont utiles durant le dialogue entre les utilisateurs finaux et les concepteurs puisqu’ils sont graphiques, et permettent aux utilisateurs de saisir les différents éléments du système. L’avantage principal des cas d’utilisation est de se concentrer sur le quoi et non sur le comment, c.à.d. sur le comportement du système et non sur comment le système est implémenté.
La figure 2.1 présente le diagramme de cas d’utilisation d’un agent client situé au sein d’une entreprise de production. Nous avons un seul acteur sur cette figure : l’agent client. Les cas d’utilisation sont annotés par un cercle : placer ordre, modifier ordre, et annuler ordre. Les lignes entre l’acteur et les cas d’utilisation dénote que l’acteur utilise ces scénarios.
Chaque cas d’utilisation dans le diagramme à besoin d’être complètement documenté et spécifié. Le type de documentation demandée pour chaque cas d’utilisation varie selon le type du système à spécifier. Il peut aller d’une description textuelle à inclure différent types de diagrammes UML [Pap00].
Peu de travaux considèrent les diagrammes de cas d’utilisation pour la modélisation des SMA, parmi eux nous trouvons les propositions de Michael Papasimeon et Clinton Heinze [Pap00], Clinton Heinze, Michael Papasimeon, et Simon Goss [Hei00], Bernhard Bauer et James Odell [Bau05].
Ce pendant, il n’y a jusqu’à maintenant aucune proposition essayant d’étendre ces diagrammes pour la description des besoins fonctionnels des systèmes multi-agent temps réel. Un besoin qui nous a motivés à exploiter cette voie de recherche, pour en proposer une solution. De plus, les diagrammes de cas d’utilisation semblent avoir un intérêt mineur lors de la conception des systèmes multi-agents temps réel. Mais ils pourraient être intéressants si les utilisateurs finaux ne sont pas les concepteurs ou si ces utilisateurs n’arrivent pas à comprendre d’autres diagrammes. Selon [Des08], Un modèle de cas d’utilisation UML décrit et formalise les relations entre le système logiciel à réaliser et le monde extérieur. Cette description se place du point de vue externe (boîte noire) sans jamais entrer dans les structures internes du logiciel. L’objectif est de préciser les frontières du système et les différentes interactions mises en oeuvre dans la réalisation des besoins métiers.
Le modèle est constitué par deux principaux types d’élément UML : les Acteurs et les Cas d’utilisation (voir figure 2.2 ci-dessous). Le container qui apparaît dans le diagramme (sous forme rectangulaire) représente le système. Les cas d’utilisation sont visualisés à l’intérieur du système, les acteurs à l’extérieur du système.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport-gratuit.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

Introduction Générale
1. CONTEXTE DE LA RECHERCHE
2. MOTIVATIONS
3. OBJECTIFS SCIENTIFIQUES
4. DEMARCHE SUIVIE
5. ORGANISATION DU MANUSCRIT
Chapitre 1 : Les Systèmes Multi-Agents Temps Réel
RESUME
INTRODUCTION
1. LES SYSTEMES MULTI-AGENTS
1.1. LE CONCEPT D’AGENTS
1.2. LES SYSTEMES MULTI-AGENTS
1.3. ENVIRONNEMENT
1.4. INTERACTION
1.5. ORGANISATION
1.6. APPROCHE ORIENTEE-AGENT ET APPROCHE ORIENTEE-OBJET
1.7. AVANTAGES ET INCONVENIENTS DE L’APPROCHE CENTREE SUR L’AGENT
1.7.1. LA MODELISATION DES SYSTEMES
1.7.2. LATOLERANCE AUX FAUTES
1.7.3. L’AUTONOMIE DES SYSTEMES
1.7.4. AUTRES AVANTAGES
1.7.5. LES DIFFICULTES DE L’APPROCHE ORIENTEE-AGENT
1.7.5.1. METHODOLOGIES NON-STANDARDISEES
2. LES SYSTEMES TEMPS REEL
2.1. DEFINITION
2.2. LES CARACTERISTIQUES D’UN SYSTEME TEMPS REEL
3. LES SYSTEMES MULTI-AGENTS TEMPS REEL
3.1. INTRODUCTION
3.2. DEFINITION
4. TRAVAUX SIMILAIRES
4.2. ANALYSE DES METHODOLOGIES DE DEVELOPPEMENT DES SMA-TEMPS REEL
5. CONCLUSION
Chapitre 2 : AUML & La Modélisation des Systèmes à base D’Agents
RESUME
INTRODUCTION
1. LE LANGAGE DE MODELISATION AUML
1.1. RAPPEL SUR AUML
1.2. LES INCOHERENCES DU LANGAGE AUML
2. LES PRINCIPALES REPRESENTATIONS D’AGENT UML
2.1. LES DIAGRAMMES DE CAS D’UTILISATION AUML
2.1.1. INTRODUCTION
2.1.2. LES ACTEURS
2.1.3. LES CAS D’UTILISATION
2.1.4. LES SCENARIOS
2.1.5. LES RELATIONS ENTRE CAS D’UTILISATION
2.1.5.1. LA RELATION D’INCLUSION
2.1.5.2. LA RELATION D’EXTENSION
2.1.5.3. LA RELATION D’HERITAGE
2.2. LES DIAGRAMMES DE CLASSE AUML ETENDUS
2.3. LES DIAGRAMMES DE PROTOCOLE AUML ETENDUS
2.4. LES DIAGRAMMES D’ETAT TRANSITION AUML
3. CONCLUSION
Chapitre 3 : Real-Time Maude
RESUME
1. INTRODUCTION
2. MAUDE
2.1 CARACTERISTIQUES DE MAUDE
2.2 CONCEPTS DE BASE
2.2.1 Sortes
2.2.2 Sous-sortes
2.2.3 Opérations
2.2.4 Variables
2.3 LES MODULES FONCTIONNELS
2.3.1 Équations inconditionnelles
2.3.3 Attributs équationnels
2.4 LES MODULES SYSTEMES
2.4.1 Règles de réécriture
2.4.2 Règles non conditionnelles de réécriture
2.4.3 Règles conditionnelles de réécriture
2.5 LES MODULES ORIENTES-OBJET
3. REAL TIME-MAUDE (RTMaude)
3.1 LES MODULES TEMPORISES (TIMED MODULES)
3.1.1 Les Domaines de Temps (Time Domains)
3.1.2 Les règles Tick
3.2 EXEMPLES DE MODULES TEMPORISES : MODELISATION D’UNE HORLOGE
3.3 LES MODULES TEMPORISES ORIENTES-OBJET (TIMED OBJECT-ORIENTED MODULES)
4. CONCLUSION
Chapitre 4 : Formalisation des Besoins Fonctionnels des SMA-Temps Réel
RESUME
1. INTRODUCTION
2. L’APPROCHE PROPOSEE
2.1. INTRODUCTION
2.2. LES DIAGRAMMES DE CAS D’UTILISATION AUML TEMPORISES (ASPECT FONCTIONNEL)
2.3. LES DIAGRAMMES DE CLASSE AUML TEMPORISES (ASPECT STRUCTUREL)
2.4. LES DIAGRAMMES DE PROTOCOLES AUML ETENDU (COMPORTEMENT COLLECTIF)
2.5. LES DIAGRAMMES D’ETAT TRANSITION AUML (COMPORTEMENT INDIVIDUEL)
3. PROCESSUS DE TRANSLATION PROPOSE
3.1. TRANSLATION DES DIAGRAMMES AUML VERS UNE SPECIFICATION FORMELLE RT MAUDE
3.2. LA DESCRIPTION DES DIFFERENTS MODES D’INTERACTION ENTRE AGENTS
3.3. ARCHITECTURE DU FRAMEWORK PROPOSE
3.4. LES RELATIONS ENTRE CAS D’UTILISATION DANS RT-MAUDE
4. CONCLUSION
Chapitre 5 : Etude de Cas : ‘’Gestion de Chaîne Logistique’’
INTRODUCTION
1. PRESENTATION
2. APPLICATION DU PROCESSUS DE TRANSLATION
2.1. LA DECOMPOSITION AGENTS DE LA GESTION DE CHAINE LOGISTIQUE
2.2. MODELISATION DE L’EXEMPLE AVEC LES DIAGRAMMES AUML ETENDUES
2.2.2. LE DIAGRAMME DE CLASSE AUML TEMPORISE DU ‘’SCM’’
2.2.3. LES DIAGRAMMES DE PROTOCOLE AUML ETENDU DU ’’SCM ‘’
2.2.4. LES DIAGRAMMES D’ETAT TRANSITION AUML DU ’’SCM ‘’
2.3. GENERATION DE SPECIFICATION RT-MAUDE
2.4. VALIDATION DE LA DESCRIPTION GENEREE
3. CONCLUSION
CONCLUSION & PERSPECTIVES
BIBLIOGRAPHIE

Télécharger le rapport complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *