Download - Rapport INES

Transcript
Page 1: Rapport INES

Université Mohammed Premier

Ecole Nationale des Sciences Appliquées d’Oujda

Filière Génie Informatique

Rapport du

Projet de Fin d’Année

Spécialité : Génie Informatique

Sujet :

JOCO 1.0

Système de modélisation et de réalisation

des applications modulaires à base des agents BDI

suivant la méthodologie O-MaSE

Année Universitaire : 2012 - 2013

Présenté par : Encadré par :

DAHMANI Sara M. Toumi BOUCHENTOUF

ERRAHHAL Mohammed M. Jamal BERRICH

ESSADDEK Mohammed

HADDOUTI Khalid

LAZAAR Ilyass

MILHI Yassine

Page 2: Rapport INES

1

Page 3: Rapport INES

2

Dédicaces

Nous dédions ce travail,

A nos chers parents,

C’est grâce à votre amour, votre immense affection et vos encouragements, la

confiance que vous nous avez accordée ainsi que vos innombrables sacrifices que nous

arrivions aujourd’hui au terme de ce travail. Nous espérons que vous y trouviez le

témoignage de notre profonde reconnaissance et notre éternel attachement.

A tous nos enseignants avec nos profondes considérations.

Qui n’ont épargné aucun effort à nous offrir un bon enseignement.

A tous nos amis,

Qui sans eux la vie nous semblerait bien fade, ce travail nous vous le dédions

en remerciement de tous les moments que nous avons passé ensemble.

Et A tous ceux qui nous ont assistés, pour la réalisation et le

bon déroulement de ce travail.

DAHMANI Sara

ERRAHHAL Mohammed

ESSADDEK Mohammed

HADDOUTI Khalid

LAZAAR Ilyass

MILHI Yassine

Page 4: Rapport INES

3

Remerciements

Nous souhaitons en particulier exprimer nos profondes gratitudes à nos

encadrants M. Toumi BOUCHENTOUF et M. Jamal BERRICH pour leurs

directives précieuses et leurs conseils pertinents qui nous ont été d’un appui

considérable dans notre démarche.

Nous tenons également à remercier toutes les personnes qui, par leur aide ou

simplement par leur gentillesse ont contribué à la bonne réalisation du projet.

Que messieurs les membres de jury trouvent ici l’expression de nos

reconnaissances pour avoir accepté d’évaluer notre modeste travail.

Page 5: Rapport INES

4

Résumé

Le présent rapport récapitule le résultat de quatre mois de travail acharné pour la

réalisation d’un projet intitulé JOCO (Jadex and OSGI Core for O-MaSE). Ce dernier permet

la modélisation et la réalisation des modules basés sur O-MaSE (Organisation based-Multiagent

System Engineering) et Jadex, ainsi que leur intégration dans un SMA (Système Multi Agents).

Notre mission en tant qu’élèves ingénieurs était la réalisation d’une application

client/serveur, qui sera une plateforme pour les SMA. D’une part la réalisation d’une

distribution de l’IDE Eclipse pour faciliter la modélisation des agents. Cette nouvelle

distribution est nommée JOCOLipse. Ensuite vient le développement de JOCOCore, qui est un

noyau basé sur la distribution Eclipse Scout, et qui représente un environnement de

fonctionnement des agents. Les différents modules générés par JOCOLipse seront ensuite

intégrés dans le noyau JOCOCore pour former un système multi agents dans lequel chaque

module est responsable d’un traitement spécifique. Le résultat final est un système où le

développeur ne fait que modéliser son agent et le système tâchera de générer le code approprié

pour qu’il soit intégré dans le noyau.

Mots clefs: Scout, Jadex, O-MaSE, SMA, OSGI, Agents, EMF, Spray, Graffiti, Ecore.

Page 6: Rapport INES

5

Abstract

The present report summarizes the result of four months of hard work for a project

entitled Jadex and OSGI Core for O-MaSE (JOCO). The latter allow modeling and

realization of modules based on Organization based-Multi-agent System Engineering (O-

MaSE) and Jadex, as well as their integration in a Multi Agents system (MAS).

Our mission as engineering students was the realization of a client/server application,

which will be a platform for MAS. On the one hand the realization of a draft distribution part

of the Eclipse IDE for easy modeling of agents. It's JOCOLipse. Then the development of

JOCOCore, a kernel based on Framework Eclipse Scout, which is indeed an agents working

environment. Finally, the integration of different modules to achieve a system where the

developer made that model its agent. The system will then seek to generate the appropriate

code, so that the agent will be integrated into the kernel.

Page 7: Rapport INES

6

Abréviations

Abréviation

Désignation

AC Active Component

ADF Agent Description File

API Application Programing Interface

BDI Belief Desire Intention

DL Daily SCRUM

ECore EMF Core

EMF Eclipse Modeling Framework

GMF Graphical Modeling Framework

GUI Graphical User Interface

IDE Integrated Developpement Environnement

INES INtelligent E-learning System

JDOM Java Document Object Model

JFaces Java Faces

JOCO Jadex and OSGI Core for O-MaSE

JRE Java Runtime Environnement

O-MaSE Organisation based-Multiagent System Engineering

OSGI Open Service GateWay Initiative

PDE Plug-in Development Environment

PO Product Owner

POA Programmation Orientée Agent

POO Programmation Orientée Objet

SDK Software Developpement Kit

SM SCRUM Master

SMA Système Multi Agent

SWT Standard Widget Toolkit

TM Team Member

UML Unified Modeling Langage

XML eXtensible Markup Langage

Page 8: Rapport INES

7

Liste des figures

Figure 1 : Architecture BDI d'un agent .................................................................................. 14

Figure 2 : Architecture d'une Application Modulaire ............................................................ 15

Figure 3 : Architecture d'INESv1 ............................................................................................ 17

Figure 4 : Architecture des Agents INESv1 ............................................................................ 18

Figure 5 : Méta-model O-MaSE ............................................................................................. 19

Figure 6 : Architecture du JOCO ............................................................................................ 23

Figure 7: Processus Métier de JOCOLipse ............................................................................. 24

Figure 8 : Structure de JOCOLipse ......................................................................................... 34

Figure 9 : Relation entre les composants du méta modèle ECore ........................................ 37

Figure 10 : Maquette du Wizard de création d'un projet JOCO ............................................ 38

Figure 11 : Maquette représentative de la perspective JOCO .............................................. 39

Figure 12 : Icônes des composants graphiques de la Palette ............................................... 40

Figure 13 : Exemple d'interconnexion entre les composants de la palette .......................... 40

Figure 14 : L’architecture du projet ‘ma.ensao.pfa.jocolipse’ .............................................. 41

Figure 15 : Structure interne du package 'ma.ensao.pfa.jocolipse' ...................................... 41

Figure 16 : Structure interne du package 'ma.ensao.pfa.exportWizards' ............................. 42

Figure 17 : Structure interne du package 'ma.ensao.pfa.handler' ........................................ 43

Figure 18 : Structure interne du package 'ma.ensao.pfa.models' ........................................ 44

Figure 19 : Structure interne du package 'ma.ensao.pfa.perspectives' ................................ 44

Figure 20 : Dépendances du Plugin JOCOLipse ..................................................................... 45

Figure 21 : Différentes Extensions de JOCOLipse .................................................................. 47

Figure 22 : Architecture de JOCOModule .............................................................................. 48

Figure 23 : Architecture du Serveur de JOCOCore ................................................................ 51

Figure 24 : Architecture du Client de JOCOCore ................................................................... 52

Figure 25 : Product Backlog ................................................................................................... 59

Figure 26 : Configuration des Sprints .................................................................................... 59

Figure 27 : Configuration des membres de l'équipe ............................................................. 59

Figure 28 : Sprint 1 ................................................................................................................ 60

Figure 29 : Sprint 2 ................................................................................................................ 60

Figure 30 : Sprint 3 ................................................................................................................ 60

Figure 31 : Sprint 4 ................................................................................................................ 61

Figure 32 : Sprint 5 ................................................................................................................ 61

Figure 33 : Sprint 6 ................................................................................................................ 61

Figure 34 : Sprint 7 ................................................................................................................ 61

Figure 35 : Création d’un nouveau projet JOCO : Choix du type de projet ........................... 62

Figure 36 : Sélection du nom du projet et du diagramme .................................................... 62

Figure 37 : Architecture du nouveau projet créé .................................................................. 63

Page 9: Rapport INES

8

Figure 38 : Modification dans la barre d’outils ..................................................................... 63

Figure 39 : Exemple de modélisation d’un agent de traduction ........................................... 63

Figure 40 : Perspective du nouveau projet créé ................................................................... 63

Figure 41 : Architecture du projet après génération des fichiers JAVA et ADFs ................... 64

Figure 42 : Lancement de la procédure de l’export .............................................................. 64

Figure 43 : Choix de type du projet à exporter ..................................................................... 64

Figure 44 : Lancement du wizard de l’export ........................................................................ 65

Figure 45 : Gestion des Logs dans l’étape de l’export ........................................................... 65

Figure 46 : Architecture du module crée .............................................................................. 66

Figure 47 : Architecture de JOCOCore : Perspective Scout ................................................... 67

Figure 48 : Architecture de JOCOCore : Perspective Java ..................................................... 67

Figure 49 : Vue principale : Module de traduction intégré dans JOCOCORE ........................ 68

Figure 50 : Démarrage du module de traduction .................................................................. 68

Page 10: Rapport INES

9

Table des matières Dédicaces ................................................................................................................................ 2

Remerciements ........................................................................................................................ 3

Résumé .................................................................................................................................... 4

Abstract ................................................................................................................................... 5

Abréviations ............................................................................................................................ 6

Liste des figures....................................................................................................................... 7

Introduction générale ............................................................................................................. 11

Chapitre Premier : Etude du projet JOCO ............................................................................. 12

Introduction ....................................................................................................................... 13

I- Présentation du projet JOCO ..................................................................................... 14

1. Idée derrière JOCO ................................................................................................. 14

2. Avantage des applications modulaires ................................................................... 15

Conclusion ...................................................................................................................... 16

II- Etude préalable et analyse ..................................................................................... 16

1. INESv1 : Plateforme E-learning à base des SMA .................................................. 16

2. O-MaSE : Une méthodologie de modélisation des SMA ....................................... 18

Conclusion ...................................................................................................................... 22

III- Conception générale et modélisation de l’application JOCO ................................ 22

1. Architecture générale.............................................................................................. 22

2. Processus d’utilisation ............................................................................................ 23

IV- Environnement de travail ...................................................................................... 24

1. Outils et technologies de développement choisis ................................................... 24

2. Méthodologie de travail adoptée : SCRUM ........................................................... 25

Conclusion ...................................................................................................................... 31

Chapitre Deuxième : Etude du projet JOCO ......................................................................... 32

Introduction ....................................................................................................................... 33

I- Mise en place du plugin JOCOLipse ......................................................................... 33

a. Calendrier et Backlog ............................................................................................. 34

b. Modélisation du plugin ........................................................................................... 36

i. Modélisation du méta-model de validation des graphes suivant O-MaSE : ....... 36

ii. Modélisation de l’architecture du plugin : .......................................................... 37

c. Réalisation du plugin .............................................................................................. 39

d. Tests unitaires ......................................................................................................... 48

e. Tests d’intégration, livraison et rétrospective......................................................... 49

Page 11: Rapport INES

10

Conclusion ...................................................................................................................... 49

II- Mise en place du noyau JOCOCore ...................................................................... 49

a. Calendrier et Backlog ............................................................................................. 50

b. Modélisation du noyau ........................................................................................... 51

c. Réalisation du noyau JOCOCore ............................................................................ 52

d. Tests unitaires ......................................................................................................... 54

e. Tests d’intégration, livraison et rétrospective......................................................... 54

Conclusion ...................................................................................................................... 55

Conclusion générale .............................................................................................................. 56

Webographie ......................................................................................................................... 58

Annexe 1 : Management du projet : SCRUM ....................................................................... 59

Annexe 2 : Interfaces de JOCOLipse .................................................................................... 62

Annexe 3 : JOCOCore ........................................................................................................... 67

Page 12: Rapport INES

11

Introduction générale

Depuis quelques années, une vague provenant de l’océan des technologies a tout dévasté

sur son passage, qu’il s’agisse de l’informatisation des tâches mécaniques, la simplification des

calculs ou l’automatisation d’un processus de raisonnement, rien n’a été épargné.

Cette vague qui a tout englouti n’est autre que l’informatisation des systèmes d’informations.

Ceux qui ont réussi à sortir de l’eau indemne sont désormais à la tête des plus grandes sociétés

informatiques.

De nos jours, les organismes ont de plus en plus recours à l’informatisation des

composantes de leur système d’information du fait qu’elle permet d’offrir des services

organisés, fiables et avec un accès rapide. Nous pouvons constater alors que lorsqu’il s’agit de

gain de temps et d’argent, les organismes ne lésinent pas sur les moyens peu importe le secteur

concerné.

Dans cette perspective, vient l’idée de concevoir INESv2 (INtelligent E-learning

System) dans sa deuxième version. INESv2 est une plateforme d’apprentissage électronique à

base des SMA (Systèmes Multi-Agents). Cette plateforme vient pour remédier au problème

majeur de sa précédente (INESv1), et pour faire d’elle une application modulaire. INESv2 se

base sur un réseau d’agents, communiquant entre eux, afin de simuler la réflexion humaine dans

la correction des exercices et la réponse aux questions posés par les étudiants utilisateurs.

La réalisation d’INESv2 comporte trois phases essentielles, d’abord la réalisation de

JOCOLipse qui est un outil de conception des SMA, ensuite la réalisation de JOCOCore qui est

un noyau servant à l’intégration des différents SMA en une seule application. Enfin vient la

réalisation d’INESv2 qui est une application Desktop modulaire, basée sur les SMA et offrant

des services e-learning. On visait atteindre le bout du projet, mais vu des contraintes

principalement relatives à la détermination des besoins et de la conception, on n’a été contraints

de nous astreindre aux deux premières phases. Notre réalisation étant un nouvel apport pour

tout ce qui est programmation orientée agent (POA), elle est effectivement la première

application offrant une interface graphique pour la création des agents BDIs suivant la

méthodologie O-MaSE et proposant la génération de l’ensemble des fichiers nécessaires pour

le fonctionnement des agents dans un conteneur d’agents tel que Jadex. Le projet JOCO n’exige

du développeur que de connaitre la méthodologie O-MaSE et les bases de la programmation

java pour pourvoir créé son système multi-agents.

Page 13: Rapport INES

12

Chapitre Premier : Etude du

projet JOCO

Page 14: Rapport INES

13

Introduction

De nos jours, un nouveau mode de programmation a émergé, il s’agit de la POA, c’est

une méthode qui exploite les théories de l’intelligence artificielle pour donner aux systèmes une

certaine autonomie vis-à-vis aux humains, les applications classiques suivait un modèle

séquentiel, les données dont les programmes avaient besoin y étaient stockées en dur. Afin de

les dynamiser, on faisait recours aux fichiers qui avaient un certain squelette pour faciliter

l’accès aux données. En suite les développeurs ont connu la POO, l’abstraction de l’application

sous forme de classes qui représentent en effet des objets de l’univers réel. On spécifie ensuite

les relations entre différentes classes à l’aide des diagrammes UML. Dans cette phase, on a

connu l’apparition des Design-Patterns (Patrons de conceptions). Parmi ces designs patterns on

pourra citer le modèle MVC où on a la séparation entre ce qui est Vue, Modèle, et Contrôleur.

L’ère des SMA est arrivée avec un nouveau concept et des nouvelles notions où le

développeur ne fait que modéliser. Néanmoins il cède la main à l’agent pour faire des

traitements à l’humaine mais d’une façon informatisée.

Commençons par définir un agent logiciel :

Un agent est un composant logiciel, un module informatique ou bien une entité virtuelle

autonome qui est capable d'agir dans un environnement, communiquer directement avec

d'autres agents, prendre des décisions, et qui a un comportement qui tend à satisfaire ses

objectifs, en tenant compte des ressources et des compétences dont il dispose, et en fonction de

sa perception, de ses représentations et des communications qu'il reçoit.

L'architecture BDI est conçue en partant du modèle "Croyance-Désir-Intention", en

anglais "Belief-Desire-Intention", de la rationalité d'un agent intelligent, mis au point pour la

programmation des agents intelligents. Ce modèle se base sur la mise en œuvre des croyances

d'un agent rationnel, cognitif, ses désirs et ses intentions, il utilise ces concepts pour résoudre

un problème particulier. En substance, il fournit un mécanisme pour séparer l'activité de

sélection d'un plan (suite d’actions) de son exécution. Par conséquent, les agents BDI sont en

mesure d'équilibrer le temps passé à délibérer sur les plans (en choisissant ce qu'il faut faire) et

l'exécution de ces plans (de le faire).

Page 15: Rapport INES

14

Durant cette partie, on essayera de présenter JOCOLipse et JOCOCore, les deux

composants de base de notre application.

I- Présentation du projet JOCO

1. Idée derrière JOCO

Pour résoudre la problématique liée au développement des SMA, nous avons dans un

premier lieu étudié l’architecture interne et le fonctionnement de ces systèmes afin de

déterminer les difficultés posées lors de développement orienté agent. Ensuite, nous avons

constaté que les agents ont besoin d’un environnement pour être exécutés ; mais ces

environnements, d’une part, ne suivent aucune méthodologie de modélisation des agents

constituants une organisation, et d’autre part, chaque environnement exige à l’agent une

Figure 1 : Architecture BDI d'un agent

Page 16: Rapport INES

15

structure interne pour le bon fonctionnement du système, ce qui rend le développement des

agents très difficile et change selon la plateforme utilisée.

Pour remédier à cela, on nous a proposé de développer une application qui modélisera,

tout d’abord, les SMA suivant la méthodologie O-MaSE à l’aide d’un éditeur graphique facile

à manipuler, et ensuite, de générer les fichiers nécessaires pour le fonctionnement de

l’organisation modélisée dans la plateforme Jadex.

Pour englober tout le processus de réalisation d’une application modulaire basée sur les

agents, nous avons jugé nécessaires de développer deux applications, une se chargera de la

création du cœur du module et l’autre créera les interfaces des modules générés et les injecter

dans le cœur de l’application.

2. Avantage des applications modulaires

Les applications les plus complexes se composent en général de plusieurs sections

chacune d’elles accomplit un besoin métier bien spécifique. Maintenant que les applications

deviennent de plus en plus immenses un développeur ne peut jamais réaliser une application

seul, mais souvent plusieurs équipes contribuent à sa réalisation. Quand on dit plusieurs équipes

on parle de plusieurs manières de codage. Dans la majorité des cas, les membres des différentes

équipes doivent communiquer du code, pour souvent le réutiliser ou bien l’intégrer avec

d’autres portions de code. Afin d’avoir des codes lisibles, réutilisables, on spécifie des standards

de code.

Une autre façon de faire c’est de diviser l’application en des modules, un module est

une application en elle-même qui effectue un traitement métier bien précis, qui sera

complémentaire pour les autres parties en vue d’obtenir une application complète.

Figure 2 : Architecture d'une Application Modulaire

Page 17: Rapport INES

16

Les modules doivent donc être semblables et doivent respecter la même structure pour

qu’ils puissent fonctionner sur le noyau. Les applications modulaires ont un autre avantage qui

est plus important que la distribution des tâches lors du codage, il s’agit de la maintenance et

les mises-à-jour en général, si on découvre une anomalie dans une fonctionnalité, il suffit de

corriger le module d’où elle parvient, et de recompiler le module en question sans affecter la

totalité des parties fonctionnelles.

INESv2 comme on l’avait prévu au départ, est une application modulaire, où chaque

module est un SMA et qui constitue un domaine d’apprentissage. La totalité des modules vont

être intégrés dans JOCOCore le noyau applicatif qui gère la totalité des SMA.

Conclusion

Le projet JOCO est donc une application modulaire qui vise à simplifier la création

d’organisations d’agents et de pouvoir générer des modules réutilisables et propres à chaque gamme de

fonctionnalités. La méthodologie O-MaSE étant flexible nous sera d’une grande utilité dans l’adaptation

des graphes schématisés avec plusieurs environnements d’exécution des agents.

II- Etude préalable et analyse

Afin de déterminer les besoins fonctionnelles du projet JOCO, il est nécessaire de

comprendre les différentes phases et méthodologies pour la modélisation et la réalisation d’un

System Multi-Agent. Dans ce but nous avons établi une étude sur le fonctionnement des SMA,

en se basant sur des solutions informatiques existantes.

Nous allons, dans un premier temps, étudier des produits nécessaires dans le processus

d’utilisation et d’autres similaires à quelques fonctionnalités de JOCO, allant de la

méthodologie de modélisation des SMA « O-MaSE » en passant par « AgentTool3 » le plugin

Eclipse qui permet d’instancier l’O-MaSE.

Dans un second temps, nous définirons et expliquerons l’architecture globale adoptée

dans ce projet. Nous présenterons ensuite le processus d’utilisation du JOCO.

1. INESv1 : Plateforme E-learning à base des SMA

INES est une plateforme d’apprentissage en ligne, permet de faire plusieurs

tâches comme :

Page 18: Rapport INES

17

- Gestion des étudiants, administrateurs, ressources, activités, droits, évaluation

etc.

- Création, management et distribution du contenu de l’Enseignement

- Guider et aider l’étudiant.

Ce Système Multi-Agent est composé par :

- Un agent conversationnel intelligent capable de communiquer, via un Chatter Bot, avec

les étudiants en langage naturel (CHARLIE),

- Un agent BDI qui agit comme le cerveau du système INES (EMMA & ISMAEL),

- Un moteur d'inférence basé sur JESS (un moteur de règles pour la plate-forme Java),

- Une ontologie

Figure 3 : Architecture d'INESv1

Page 19: Rapport INES

18

- EMMA est responsable de la réception de messages de CHARLIE et de les

transmettre à ISMAEL.

- ISMAEL interprète les messages reçus de CHARLIE (à travers EMMA) et effectue

les opérations appropriées.

Le scénario typique dans une communication CHARLIE-EMMA-ISMAEL-EMMA-

CHARLIE peut être vu dans la figure suivante :

Figure 4 : Architecture des Agents INESv1

La plateforme INES est une application non modulaire ainsi que les agents

de ce SMA ne suivent aucune méthodologie de développement orienté agents.

2. O-MaSE : Une méthodologie de modélisation des SMA

Cette méthode considère le système comme une organisation des agents, chaque agent

joue un rôle spécifique selon ses capacités pour atteindre et réaliser ses objectifs. Donc, le but

de cette méthode est de construire une société organisationnelle des agents en basant sur les

métas modèles de l'organisation.

O-MaSE est défini par le Framework OPEN Process, ce framework nous permet de

produire une méthodologie de modélisation, il utilise trois notions :

- méta-model

- Method Fragments

- Guidelines

Page 20: Rapport INES

19

Figure 5 : Méta-model O-MaSE

- But (Goal) : est un objectif que le système doit obtenir ou satisfaire. Il est différent de

- la fonction du système : le but ne s'intéresse que le résultat obtenu, cependant, la

fonction s'intéresse à la façon pour obtenir l'objectif.

- Rôle (Role) : est une entité capable d'obtenir des buts dans l'organisation. Un rôle doit

s'occuper au moins d'un but du système. Pour ce faire, il doit avoir des responsabilités,

droits et des relations. Donc, il y a une relation entre les rôles et les buts.

- Agent : les agents jouent un/des rôle(s) et ils assument les responsabilités des rôles avec

l’utilisation de ses droits et ses relations. C’est est une entité qui perçoit et peut effectuer

des actions sur son environnement. En outre, d'autres concepts importants sont liés aux

agents :

o Capacités (Capabilities) : représente les capacités d’un agent pour s'occuper des

missions. En basant sur les capacités, on détermine précisément la relation entre

les agents et les rôles : les agents ont des propres capacités et les rôles demandent

certaines capacités pour les jouer. Donc, quand un agent a les capacités

nécessaires demandées par un rôle, il pourra jouer ce rôle.

Page 21: Rapport INES

20

o Plans : Les plans ont une relation avec l’accès et le control des ressources

spécifiques, la capacité de communiquer avec d’autres agents, la capacité de

migrer vers une nouvelle plate-forme, ou la capacité d'utiliser des algorithmes

informatiques qui permettent à l'agent d'effectuer des calculs spécifiques

fonctionnels.

o Actions : Les actions sont associées à des agents logiciels ou matériels, ils

permettent aux agents de percevoir l’environnement réel.

- Modèle de domaine (Domain Model) : Le monde réel est capturé à l'aide du modèle de

domaine. Fondamentalement, le modèle du domaine décrit les objets de l'environnement

(les agents incluent) et les relations entre ces objets (propriétés de l'environnement).

- Politiques (Policies) : Une politique décrit comment une organisation peut se comporter

dans une situation particulière. Par ailleurs, le modèle de domaine est également utilisé

pour définir des politiques d'organisation spécifiques.

- Agent de l’organisation (Organization Agents - OA) : OAs sont des organismes qui

fonctionnent comme agents d'une organisation de niveau supérieur. Les OAs peuvent

jouer des rôles, avoir des capacités ou coordonner avec d’autres agents. ils ajoutent

l’idée de la hiérarchie de l’organisation du méta model d’O-MaSE.

- Protocoles : Ce concept est inclus afin de capturer les interactions entre l’Organisation

avec les acteurs externes, les agents et les rôles.

Ces protocoles peuvent être de deux types :

o Protocole externe : permet l'interaction entre l'organisation et les acteurs

(humains ou autres applications logicielles).

o Protocole interne : représente un modèle pour représenter toute communication

d'un agent qui envoi (initie) à un autre (répond) joue un rôle spécifique dans

l'organisation.

Les modèles d’O-MaSE :

- Model Roles : Ce model vise à identifier tous les rôles dans l'organisation ainsi que leurs

interactions avec autre organisation et avec des intervenants extérieurs.

- Model Domain : Capture les entités de domaine, les attributs et les relations qui existent

entre eux.

- Model Agent Classes : L'objectif de ce modèle est d'identifier le type d'agents qui

participeront à l’organisation.

Page 22: Rapport INES

21

- Model Protocol : Définit les interactions entre agents et / ou les actions effectuées par

les agents sur l'environnement.

- Model Plan : Définit les plans de l'agent. un plan peut être considéré comme un

algorithme pour atteindre un objectif spécifique. En outre, les plans sont faits de

plusieurs actions ou sous plans et peut nécessiter une interaction avec d'autres agents.

- Model Policies : il définit un ensemble de règles formellement spécifiés qui décrivent

comment une organisation peut se comporter dans des situations particulières. Ils

identifient les règles et les contraintes du système. Par exemple, les politiques peuvent

contrainte le comportement d'un agent jouant un rôle en ce qui concerne les autres agents

de l'organisation ou de restreindre un agent de jouer certaines combinaisons de rôles.

- Model Actions : Capture les interactions exercées par les agents de l'environnement.

- Model Services : Englobe les activités menées par les agents, dans l'exercice

de rôles, par le biais de services fournis à d'autres agents / rôles.

3. Etude d’un produit similaire à JOCOLipse : AgentTool3

AgentTool III est un plugin Eclipse, permettant la modélisation des SMA, il fournit des

diagrammes pour représenter les modèles de l’O-MaSE, il permet aussi de :

Vérifier si le diagramme des états de chaque tâche ou de chaque conversation est

consistant c’est-à-dire que chaque état a des conditions entrées et des conditions sorties ;

Vérifier la validité et la correspondance des différents diagrammes d'une organisation ;

Générer automatiquement le code selon le modèle conçu des agents. C'est le code

préliminaire sur la plateforme JADE, le programmeur doit le compléter après.

L'environnement de développement aT3 comprend en fait quatre composantes qui sont

intégrés dans un seul outil. Ces composants sont :

o L’éditeur graphique :

Il est le composant essentiel d’aT3, il prend en charge l'édition graphique de chacun des

modèles O-Mase. Ces modèles, lorsqu'ils sont combinés, définissent la conception d'un SMA à

l'aide des concepts de l’O-MaSE méta-modèle. Un designer crée des modèles en aT3 en faisant

glisser les éléments du modèle à partir d'une palette et de les placer sur le panneau de dessin.

Built-in de validation garantit que seules les connexions valides sont faites entre les

éléments de modèles appropriés. Pour modifier les détails internes d'éléments de modèle, aT3

offre également pop-up panneaux pour les articles tels que les attributs et les paramètres de

l'agent.

Page 23: Rapport INES

22

o AT3 Process Editor :

Il permet la création, la gestion et la vérification des processus personnalisés d’O-MaSE.

o Le Framework de vérification :

Le Framework de vérification AT3 offre aux concepteurs un moyen de maintenir la

cohérence entre leurs O-MaSE modèles en utilisant un ensemble de règles prédéfinies.

o Génération de code :

Ce composant prend tous les modèles de conception crée lors de l'élaboration afin de

les convertir en code qui implémente correctement les modèles. Évidemment AT3 contient un

Framework de génération du code automatique. La seule plate-forme prise en charge est JADE.

Conclusion

La mission qui nous a été confiée est la mise en œuvre d’une application de

modélisation et réalisation des SMA. Vu la difficulté de la tâche nous nous sommes

bien documentés sur les outils liés à l’orienté agent, et nous avons effectué des

études de cas concrets des applications existantes sur le marché, chose qui nous a

permis d’assimiler encore mieux leur fonctionnement, élaborer une vision et aussi de

dégager la problématique.

La conduite de ce projet a nécessité l’utilisation de méthodologies de

management qui nous ont permis la réalisation des différentes tâches en bonne

condition.

III- Conception générale et modélisation de l’application JOCO

1. Architecture générale

L’architecture de JOCO se divise en deux parties essentielles, le plugin JOCOLipse qui

offre un éditeur graphique, avec une palette contenant les différents éléments de modélisation

des SMA suivant O-MaSE et une zone de dessin pour représenter le JOCOModule, l’export de

ce module résulte la génération de trois plugins fonctionnels dans Eclipse Scout ainsi que les

fichiers descriptifs des agents. Et JOCOCore, le cœur de l’application JOCO, c’est une

application Client/ Serveur qui se chargera, au niveau du client, d’injecter les interfaces de

Page 24: Rapport INES

23

chaque JOCOModule, et au niveau du Serveur, JOCOCore lance l’application et la plateforme

Jadex et il fournit des services permettant la communication entre les différents agents.

Figure 6 : Architecture du JOCO

2. Processus d’utilisation

Le processus d’utilisation du JOCO est le suivant :

- Tâche 1 : Après l’installation du plugin, le développeur doit créer un nouveau

projet JOCO dans l’environnement de développement JOCOlipse, en définissant

le nom du projet et du model.

- Tâche 2 : Ensuite le modélisateur, à l’aide d’un éditeur graphique, glisse les

différents éléments de la méthodologie O-MaSE à partir d’une palette vers un

espace de dessin afin de modéliser le SMA.

- Tâche 3 : Un agent BDI est un agent qui a un plan et un fichier descriptif (ADF),

pour cela il est nécessaire de générer ces deux fichiers pour chaque agent

modéliser lors de la deuxième tâche, les fichiers générer doivent être adéquates

avec la plateforme Jadex.

- Tâche 4 : l’export du module modélisé dans JOCOlipse, sous forme de trois

plugins fonctionnels dans Eclipse Scout.

- Tâche 5 : L’import du projet généré dans le cœur du JOCO, c’est-à-dire

JOCOcore qui se base sur l’environnement Eclipse Scoupt.

Page 25: Rapport INES

24

- Tâche 6 : La création des interfaces et l’injection du module dans le cœur du

JOCO.

- Tâche 7 : L’export de l’application finale sous trois formats possibles.

On peut expliquer le processus de fonctionnement du système JOCOLipse – JOCOCore

par le schéma suivant :

Le processus n’est pas à 100% informatisé, il y a des tâches que le développeur doit

absolument faire manuellement : Export depuis JOCOLipse, import dans Scout, écriture du

corps des fichiers Java générés, etc.

IV- Environnement de travail

1. Outils et technologies de développement choisis

Ecore : La composante Ecore Tools fournit un environnement complet pour créer, éditer et

maintenir des modèles Ecore. Ce composant facilite la manipulation de modèles Ecore avec

un éditeur graphique Ecore et simplifie les liaisons avec d'autres outils Ecore existants.

L'éditeur de Ecore graphique implémente le support multi-schéma, une vue des propriétés,

ainsi que des évaluations de validation.

EMF : Le projet EMF est un Framework de modélisation et de simplification de la

génération du code pour la construction d'outils et d'autres applications basées sur un

modèle de données structuré. À partir d'une spécification du modèle décrit dans XMI, EMF

fournit des outils et support d'exécution pour produire un ensemble de classes Java pour le

modèle, avec un ensemble de classes d'adaptateurs qui permettent la visualisation et

l'édition du modèle basée sur les commandes, ainsi qu'un éditeur de base.

Graphiti : Graphiti est un Framework graphique basé sur Eclipse qui permet le

développement rapide des éditeurs de diagramme pour les modèles de domaine. Graphiti

Figure 7: Processus Métier de JOCOLipse

Page 26: Rapport INES

25

peut utiliser les modèles de domaine EMF très facilement, mais peut aussi traiter des objets

à base de Java.

Spray : il vise à fournir un ou plusieurs langages dédiés (DSL) (par exemple avec Xtext)

pour décrire des éditeurs visuels DSL pour l'environnement d'exécution Graphiti, et de

fournir la génération de code (par exemple avec Xtend2) pour créer le code réutilisable et

réaliser une implémentation dédiée pour le Framework Graphiti. Dans le cas général, le

DSL spray peut être utilisé pour générer du code pour d'autres Framework aussi.

JADEX : Jadex est un Framework qui permet de programmer des composantes actives et

des agents logiciels intelligents en XML et Java ainsi que des composantes passives

(composants SCA). Jadex est très flexible et peut être utilisé avec des infrastructures

middleware différents tels que JADE.

Eclipse Scout : Eclipse Scout rend plus facile pour les entreprises la création des

applications distribuées, basées sur la plate-forme Eclipse. Il se compose d'un

environnement d’exécution assurant une communication transparente entre les services de

la partie client et serveur. Il est aussi livré avec un ensemble complet de composants de

l'interface utilisateur. L'interface utilisateur n'est pas conçu pour une technologie de rendu

particulier, mais il encapsule les fonctionnalités de base dans un modèle et génère le résultat

suivant trois sorties possibles (desktop, mobile et web).

Web services : Un service web est un programme informatique permettant la

communication et l'échange de données entre applications et systèmes hétérogènes dans des

environnements distribués. Il s'agit donc d'un ensemble de fonctionnalités exposées sur

internet ou sur un intranet, par et pour des applications ou machines, sans intervention

humaine, et de manière synchrone.

2. Méthodologie de travail adoptée : SCRUM

Nous avons opté pour une méthode agile, qui est SCRUM qui a fait ses preuves, et a été

adoptée par beaucoup de professionnels.

Page 27: Rapport INES

26

La méthode SCRUM (qui signifie mêlée en Rugby) s'appuie sur le découpage d'un projet

en incréments, nommés "Sprint", ainsi que l'auto-organisation de l'équipe de développement.

Les Sprints peuvent durer entre deux et quatre sprints (avec une préférence pour deux

semaines). Chaque Sprint commence par une estimation suivie d'une planification

opérationnelle. Le Sprint se termine par une démonstration (un ensemble de tests) de ce qui a

été achevé. Avant de démarrer un nouveau Sprint, l'équipe réalise une rétrospective : elle

analyse ce qui s'est passé durant ce Sprint, afin de s'améliorer pour le prochain. Le client, ici

nommé le Product Owner, décrit les fonctionnalités que le produit doit remplir et les classe par

ordre de priorité et qui forment ce qu’on appelle le Product Backlog. À chaque fonctionnalité

ou Feature, sont associés plusieurs User Stories qui représentent les besoins détaillés exprimés

par le Product Owner. Ensuite, le Product Backlog est répartie en plusieurs Sprint Backlog qui

regroupent chacun les user stories à réaliser pour un Sprint. En fin de chaque Sprint, et afin

d’évaluer son rendement comme mentionné plus haut, le Product Owner jauge la livraison du

Sprint et son retour permet à l’équipe d’ajuster le Backlog du Sprint suivant tout en se focalisant

sur les fonctionnalités les plus prioritaires ; cette séance de « jugement » réuni tous les membres

de l’équipe et elle est appelée Rétrospective Meeting. Le SCRUM Master, un des membres de

l’équipe qui joue un rôle très important lors de la réalisation du produit, s’assure que les

principes et les valeurs de SCRUM sont respectés, facilite la communication au sein de l’équipe

et cherche à améliorer la productivité et le savoir-faire de son équipe.

Après avoir établi le cahier de charge de notre projet, en détailler l’aspect fonctionnel

était une étape primordiale, et puisqu’on utilise la méthodologie SCRUM, le Backlog du produit

s’avère la meilleure façon d’atteindre cette fin, en effet, ce dernier permet entre autres :

De lister d’une manière exhaustive les différentes fonctionnalités attendues ou

les cas d’utilisations prédéfinies.

De réaliser facilement des estimations de charges.

Page 28: Rapport INES

27

L’étude menée nous a permis d’établir le Backlog du produit :

Features ID User Stories Importance Estimation

Etude et

documentation

3

Entant que Team member (TM) je dois étudier la

plateforme Jadex et BDI afin de comprendre la

composition et le fonctionnement des agents BDIs

150 29

4

Entant que TM je dois étudier la méthodologie O-

MaSE et l’outil AgentTool III afin de pouvoir

modéliser des organisations d’agents suivant O-

MaSE et de comprendre le fonctionnement

d’AgentTool III

145 44

2

Entant que TM je dois étudier la plateforme

Eclipse Scout afin de comprendre son architecture

et son fonctionnement

140 29

1

Entant que TM je dois comprendre le processus de

la création d'un plugin Eclipse afin de pouvoir créer

un plugin Eclipse « Hello World »

135 20

5

Entant que TM je dois étudier EMF, GMF,

Graphiti et Spray afin de pouvoir créer un éditeur

graphique pour la création des organisations des

agents

130 29

6

Entant que TM je dois étudier les frameworks

Xtext et DSL afin de pouvoir créer des shapes dans

spray

125 16

7

Entant que SCRUM Master (SM) je dois réaliser

la spécification JOCOlipse v1.0 afin de garder une

traçabilité du travail de l’équipe

120 17

Réalisation

JOCOLipse

v1.0

9

Entant que TM je dois créer la partie preferencies

afin de permettre à l’utilisateur de choisir les

options de la pespectives à afficher

20 14

Entant que TM je dois créer l’explorateur de

projets du plugin afin de pouvoir créer des des

projets respectant l’architecture joco

60 14

10

Entant que TM je dois créer une Palette Spray afin

d’y ajouter des formes graphiques des organisations

d’agents

115 26

11

Entant que TM je dois créer la vue properties de la

palette spray afin de remplir les différentes

propriétés des composants de la palette

110 18

12

Entant que TM je dois gérer la validation des

données de la palette Spray afin d’assurer la

création d’organisations respectant le méta-modèle

O-MaSE

105 8

13

Entant que TM je dois créer la perspective

« JOCO Dev Perspective » afin de relier l’ensemble

des vues essentielles au nouveau projet joco

100 14

14

Entant que TM je dois gérer la génération et

l’export du module Scout à partir du projet joco du

plugin afin de pouvoir récupérer un output sous

forme de trois plugins (client, server et shared)

95 45

Page 29: Rapport INES

28

15

Entant que TM je dois gérer la génération des

agents (code java et adfs) à partir de la palette

graphique afin de pouvoir les inclure dans le

module généré

80 10

16

Entant que TM je dois créer une distribution -

Eclipse JOCO afin de regrouper les différents

composants et plugins nécessaire à la création d’un

projet JOCO et la génération d’un module scout

75 10

Réalisation

JOCOCore

v2.0

17

Entant que TM je dois modéliser le noyau

(Application Scout) afin de concevoir son

architecture et son processus de fonctionnement

70 7

18

Entant que TM je dois modéliser le ModuleLoader

dans JOCOCore afin de concevoir l’architecture et

le processus de fonctionnement du chargeur des

modules du noyau

65 4

19

Entant que TM je dois modéliser le BDIStarter

dans Jadex afin de concevoir l’architecture et le

processus de fonctionnement du lanceur des agents

BDI dans la plateforme Jadex du noyau

55 4

20

Entant que TM je dois modéliser la

communication interne du noyau afin de concevoir

le processus de communication inter-agents

50 18

21

Entant que TM je dois modéliser la

communication externe du noyau afin de concevoir

le processus de communication entre les agents et

les interfaces graphiques

45 18

22

Entant que SCRUM Master (SM) je dois réaliser

la spécification JOCOCore v2.0 afin de garder une

traçabilité du travail de l’équipe

40 30

23

Entant que TM je dois Implémentation les codes

des différentes parties du noyau JOCOCore

précédemment modélisées afin d’avoir un noyau

fonctionnel

35 10

Rédaction des

spécifications et

du rapport 24

Entant que TM je dois réaliser la spécification du

projet JOCO afin de garder une traçabilité du

travail de l’équipe

25 20

TOTAL : 454 heures/homme

Page 30: Rapport INES

29

La période de développement de l’application s’est étalée sur une période de

4 mois environ avec un effectif de six personnes, et a été divisé sur 7 sprints répartis

comme suit :

Sprint 0

Objectif : Planification et étude générale du projet

Date de début : 29 Janvier 2013 Date de fin : 18 Mars 2013

Sprint 1

Objectif : Etude et documentation sur les différentes technologies utilisées

Date de début : 7 février 2013 Date de fin : 27 février 2013

Vélocité : 156 heure/homme Facteur de focalisation : 80%

User Stories incluses : 1, 2, 3, 4, 5, 6 et 7

Sprint 2

Objectif : Deuxième partie de la documentation sur les technologies utilisées

Date de début : 5 Mars 2013 Date de fin : 18 Mars 2013

Vélocité : 104 heure/homme Facteur de focalisation : 80%

User Stories incluses : 8, 9, 10, 11, 12, 13, 14, 15 et 16

Sprint 3

Objectif : Modélisation du plugin JOCOLipse

Date de début : 4 Avril 2013 Date de fin : 18 Avril 2013

Vélocité : 156 heure/homme Facteur de focalisation : 80%

User Stories incluses : 8, 9, 10, 11, 12, 13, 14, 15 et 16

Page 31: Rapport INES

30

Sprint 4

Objectif : Réalisation du plugin JOCOLipse

Date de début : 2 Mai 2013 Date de fin : 9 Mai 2013

Vélocité : 52 heure/homme Facteur de focalisation : 80%

User Stories incluses : 8, 9, 10, 11, 12, 13, 14, 15 et 16

Sprint 5

Objectif : Modélisation du noyau JOCOCore

Date de début : 16 Mai 2013 Date de fin : 23 Mai 2013

Vélocité : 48 heure/homme Facteur de focalisation : 80%

User Stories incluses : 17, 18, 19, 20, 21, 22 et 23

Sprint 6

Objectif : Réalisation du noyau JOCOCore

Date de début : 27 Mai 2013 Date de fin : 3 Juin 2013

Vélocité : 48 heure/homme Facteur de focalisation : 80%

User Stories incluses : 17, 18, 19, 20, 21, 22 et 23

Sprint 7

Objectif : Rédaction des spécifications et du rapport de l’application

Date de début : 15 Juin 2013 Date de fin : 21 Juin 2013

Vélocité : 48 heure/homme Facteur de focalisation : 80%

User Stories incluses : 24

Page 32: Rapport INES

31

Conclusion

La vélocité totale des 7 sprints donne un total de 612 heure/homme qui est largement

supérieur au total estimé des différentes Userstories. Cela a été dû à une mauvaise estimation

des charges des différentes Userstories, ainsi qu’aux ré estimations effectuées tout au long du

projet à cause de la méconnaissance de la plupart des technologies utilisées.

L’adoption d’une méthodologie telle que SCRUM nous a permis de constater les

nombreux avantages des méthodologies agiles, en particulier les Daily meetings qui nous ont

donné l’opportunité de discuter les problèmes rencontrées dans les plus courts délais. D’autre

part l’obligation de mentionner quotidiennement les heures de travail effectuées par chaque

membre a permis d’établir une atmosphère de transparence et d’honnêteté ainsi que d’évaluer

l’avancement du projet très facilement à partir du Burn Down Chart.

Page 33: Rapport INES

32

Chapitre Deuxième : Etude du

projet JOCO

Page 34: Rapport INES

33

Introduction

Nous avons abordé jusqu’ici la présentation du projet JOCO et ses différentes phases

ainsi que ses objectifs et ses apports. Dans ce chapitre nous allons présenter la partie mise en

œuvre des deux phases du projet, à savoir : le plugin JOCOLipse et le noyau JOCOCore.

Avant d’entamer la réalisation, nous avons consacré une période de 20 jours, s’étalant

du 29janvier au 18 Mars, à l’étude du besoin et l’architecture du projet ainsi qu’un nombre

d’études sur les différents outils utilisés dans le développement. Cette période a été répartie

entre la mise en place du backlog dans un sprint 0, suivie de deux sprints 1 et 2 d’études des

outils et des environnements utilisés.

Les deux phases du projet ont été réalisées afin d’être complémentaires et de manière à

ce que les outputs de la première soient les inputs de la deuxième.

I- Mise en place du plugin JOCOLipse

L’Objectif principale du plug-in JOCOLipse est de modéliser et développer des modules

qui seront intégrés dans le noyau JOCOCore d’une application modulaire INES selon la

spécification O-Mase. C’est un outil qui rend la tâche de la création d’un nouveau module assez

simple car il couvre les différentes étapes de création et génère automatiquement la structure

nécessaire du module.

Il est conçu pour être un environnement de développement complet où le développeur

se focalise que sur la modélisation orientée agent du module INES.

Le plugin permettra au développeur de créer un projet « joco » contenant une palette

graphique où il pourra glisser et interconnecter les différents éléments graphiques tout en

respectant la méthodologie O-MaSE.

Page 35: Rapport INES

34

La structure de JOCOLipse est la suivante :

Figure 8 : Structure de JOCOLipse

Nous voyons dans la figure ci-dessus que JOCOLipse se base sur une palette graphique

qui interagit avec l’interface de la perspective JOCO pour pouvoir générer un module scout.

a. Calendrier et Backlog

La réalisation du plugin JOCOLipse s’est étalée sur deux sprints et a constitué un

release. Ce release a été clôturé par une livraison.

Sprint 3

Objectif : Modélisation du plugin JOCOLipse

Date de début : 4 Avril 2013 Date de fin : 18 Avril 2013

Vélocité : 156 heure/homme Facteur de focalisation : 80%

User Stories incluses : 8, 9, 10, 11, 12, 13, 14, 15 et 16

Page 36: Rapport INES

35

Sprint 4

Objectif : Réalisation du plugin JOCOLipse

Date de début : 2 Mai 2013 Date de fin : 9 Mai 2013

Vélocité : 52 heure/homme Facteur de focalisation : 80%

User Stories incluses : 8, 9, 10, 11, 12, 13, 14, 15 et 16

Ces sprints étaient composés de plusieurs userstories qui à leurs tour étaient éclatés en tâches :

User Stories Tâches

Etude de la plateforme Eclipse

Scout Développement d'application modulaire avec Eclipse Scout

Etude d'EMF et GMF + Etude de

Graphiti et Spray Etude Graphiti et Spray

Réalisation de la spécification

JOCOlipse v1.0 Réalisation de la spécification technique

Réalisation JOCOLipse v1.0 :

Explorateur de projets

Modélisation de l'explorateur de projets

Création d'un nouveau projet

Tester l'explorateur de projets

Réalisation JOCOLipse v1.0 :

Palette Spray

Conception des différentes icones de la palette

Finalisation du schéma de validation

Définition des propriètés des différents éléments

Création de la palette

Gestion du glissement des composants (validation)

Tester la palette

Réalisation JOCOLipse v1.0 :

Création de la vue properties

Modélisation de la vue propriètés

Réalisaion de la vue propriètés

Gestion du clique sur le composant

Tester la vue propriètés

Réalisation JOCOLipse v1.0 :

Création perspective - JOCO Dev

Perspective

Modélisation de la perspective JOCO

Création de la perspective JOCO

Tester la perspéctive

Réalisation JOCOLipse v1.0 :

Génération module pour Scout

Modélisation du contenu du module

Génération du fichier XML Global

Gestion du boutton générer (Génération des ADFs)

Gestion du boutton générer (Génération du code JAVA)

Transformer le code généré en plugins

Automatisation de l'export des fichiers générés

Tester la génération du code & plugins

Page 37: Rapport INES

36

Le résultat du Plugin été une première version de la distribution eclipse permettant la

modélisation et la génération du code spécifique à une organisation de BDIs suivant O-MaSE.

b. Modélisation du plugin

La modélisation du plugin peut être divisée en deux parties majeures, à savoir :

i. Modélisation du méta-model de validation des graphes suivant O-

MaSE :

La première étape consiste à créer un projet Encore (cf. document plugin-jocolipse.pdf)

et d’y modéliser le schéma représentatif du méta-model O-MaSE avec ses différents

composants graphiques. Dans ce méta model, nous avons pris comme point de départ l’élément

organisation d’O-MaSE qui joue le même rôle du package dans Jadex. Cette organisation(ou

package) est composée de plusieurs agents. Chaque agent joue un rôle. Ainsi un rôle pourra

achever des buts et initier des protocoles. L’architecture des agents dans Jadex repose sur les

buts, et chaque rôle peut achever un ou plusieurs buts. Dans le cas de buts multiples le choix

sera alors conditionné pas des délibérations et des conditions.

Comme dans Jadex et O-MaSE, un agent possède une capacité qui rassemble un

ensemble de plans exécutés à chaque fois que leurs déclencheurs soient captés dans

l’environnement. Il vient finalement l’élément Parameter, spécifique à Jadex, qui permet

d’ajouter d’autres informations et propriétés relatives à un plan, un but ou un protocole.D’autre

part, nous avons remarqué que des éléments important dans Jadex sont absents dans le

métamodel O-MaSE tel que les croyances, les faits et les paramètres. Ces éléments sont propres

à l’agent et diffèrent d’un agent à un autre. Nous avons donc utilisé l’élément DomainModel de

O-MaSE pour les classer.

Pour que les associations puissent être traitées comme des éléments dans les étapes

suivantes, nous avons été amenés à ajouter de nouveaux éléments représentants les différentes

associations entre les classes de notre méta model héritant de la classe « AssociationModel ».

Page 38: Rapport INES

37

Figure 9 : Relation entre les composants du méta modèle ECore

Ensuite il faudra créer un projet EMF basé sur notre projet Ecore. Ce projet EMF nous

a permis d’instancier le méta model antérieurement créé, l’inconvénient de cette méthode c’est

qu’elle est faite manuellement via des pop-up menu. De plus ce projet EMF permet de générer

du code java associé à chacune des classes créées dans l’Ecore. Pour remédier à ce problème,

et afin d’aider l’utilisateur à créer un graphe « instance » de notre méta-model facilement et

graphiquement, nous nous avons basé sur notre EMF pour créer un projet Spray.

Dans spray il faudra créer des formes (shapes) associées à chaque élément et chaque

association. La validation du graphe et les règles qui gèrent les relations entre les différents

éléments seront traitées en temps réel, ainsi l’utilisateur sera obligé d’utiliser les relations

valides uniquement.

ii. Modélisation de l’architecture du plugin :

Le plug-in JocoLipse est créé pour faciliter la création des modules E-Learning qui

seront intégrés dans la plateforme INES.La première tâche consiste à créer un nouveau projet

dans l’environnement de développement JocoLipse, on commence par lancer le wizard de

création qui se trouve dans le menu « File/new project ». Le wizard est composé d’une seul

page qui contient le nom du projet et le nom du module. Une vérification est faite pour s’assurer

qu’aucune exception n’est lancée.

Page 39: Rapport INES

38

Figure 10 : Maquette du Wizard de création d'un projet JOCO

Après la création, la perspective JocoLipse est chargée et l’arborescence du projet

s’ouvre dans l’explorateur. La perspective JocoLipse est composée de :

o Un explorateur de projet : Chaque projet est créé dans le but de développement

d’un seul module, il contient :

- Un fichier qui représente le module « *.diagram », ce fichier sera

modalisé a l’aide d’un éditeur graphique.

- Un répertoire « src » qui contient les fichiers « *.java » associés aux

agents.

- Un fichier d’ADF « nomModule.agent.xml », qui contient le schéma

ADF des agents. Il est généré automatiquement en lecture seul. Ce fichier

contient le code de base XML d’un schéma ADF

o L’éditeur graphique

o La palette des propriétés de chaque élément graphique

o Une console

Page 40: Rapport INES

39

o Deux boutons dans la barre d’outils : Exporter et Générer

Figure 11 : Maquette représentative de la perspective JOCO

c. Réalisation du plugin

Le plug-in Jocolipse est composé selon le besoin de quatre projets :

o « ma.ensao.pfa.jocolipse.metadata » qui représente le méta-model de la

spécification d’O-Mase sous forme d’une modélisation EMF

o « ma.ensao.ines.spray.diagram » qui décrit l’éditeur graphique qui permet la

modélisation agent. Cet éditeur est un projet basé sur le Framework Spray. Il est

conçu à partir du méta-model de la spécification avec des ajouts. Pour chaque

type des éléments conçus dans le méta-model, nous avons créé un menu et un

ensemble d’icônes correspondantes.

Page 41: Rapport INES

40

Chacune des icônes correspond à une forme graphique qui peut être un élément ou une

association :

Figure 12 : Icônes des composants graphiques de la Palette

Figure 13 : Exemple d'interconnexion entre les composants de la palette

Page 42: Rapport INES

41

o « ma.ensao.pfa.jocolipse.lib » qui contient les librairies utilisées dans le

développement sous forme de fichier Jar. Ce projet est inclus dans les autres

projets comme une dépendance essentielle pour le fonctionnement.

o « ma.ensao.pfa.jocolipse » qui décrit le fonctionnement du plug-in avec les

différents traitements (création du projet, génération du code, …). Ce projet est

un plug-in Eclipse qui rassemble les fonctionnalités de base de Jocolipse dans

un seul environnement, il personnalise l’environnement d’Eclipse et intègre

l’éditeur graphique et exécute les différents traitements et actions. L’architecture

du projet dans l’environnement Eclipse est sous forme d’un ensemble des

packages et des dossiers de ressources, et ainsi des fichiers de configuration et

de déploiement :

Le dossier « src » contient les packages utilisés dans le développement du projet :

o « ma.ensao.pfa.jocolipse » : contient la classe Activator qui respecte une

convention proposée par OSGi, elle permettra notamment de réagir à des

événements liés au cycle de vie du plug-in (arrêt, démarrage, ...).

Figure 14 : L’architecture du projet ‘ma.ensao.pfa.jocolipse’

Figure 15 : Structure interne du package 'ma.ensao.pfa.jocolipse'

Page 43: Rapport INES

42

o « ma.ensao.pfa.jocolipse.exportWizards » contient les classes qui gèrent la

fonctionnalité de l’export du projet sous forme d’un module INES. Il est

composé de deux classes principales : Une classe « ExportProjectWizard » qui

représente le Wizard et la classe « JocoExportProjectWizardPage » qui est une

page dans le Wizard. Le contenu de ce package est utilisé dans l’extension.

o « org.eclipse.ui.exportWizard » qu’on va la détailler dans la partie extension.

o « ma.ensao.pfa.jocolipse.handler » contient le contenu des actions de Jocolipse,

deux actions sont présentes : la génération de l’ADF et des classes Java associées

au diagramme agent, et l’exportation du module sous forme d’un module JOCO.

Il utilise les fonctionnalités du package métier du plugin.

Figure 16 : Structure interne du package 'ma.ensao.pfa.exportWizards'

Page 44: Rapport INES

43

o « ma.ensao.pfa.jocolipse.models » contient les classes métier du plug-in, ces

derniers réalisent les traitements associés aux actions. La classe

« ProjectUtils » contient des traitements utilitaires comme la récupération du

projet courant.

Figure 17 : Structure interne du package 'ma.ensao.pfa.handler'

Page 45: Rapport INES

44

o « ma.ensao.pfa.jocolipse.newProjectWizards » contient les classes qui

permettent la création d’un nouveau projet Joco.

o « ma.ensao.pfa.jocolipse.perspectives » contient la classe qui gère la perspective

Joco et les différents éléments qui la composent.

Figure 18 : Structure interne du package 'ma.ensao.pfa.models'

Figure 19 : Structure interne du package 'ma.ensao.pfa.perspectives'

Page 46: Rapport INES

45

o « res.icons » un dossier qui contient les ressources utilisées dans le plugin, en

particulier, les icones.

o « res » un dossier qui contient les fichiers utilisés dans la génération du module

JOCO. Ces fichiers sont considérés comme des templates de base du module.

Afin de gérer les dépendances entre les différents plugins isolés : il ne peut accéder aux

classes des autres plug-ins et les autres plug-ins ne peuvent accéder à ses classes. En modifiant

le fichier MANIFEST.MF d'un plug-in, il est possible de rendre accessibles tout ou partie de

ses classes.

Dans notre cas, le projet « ma.ensao.pfa.jocolipse » et en dépendance avec le projet

« ma.ensao.pfa.jocolipse.metadata » qui est l’éditeur graphique de la modélisation, et

« ma.ensao.pfa.jocolipse.lib » qui contient les librairies utilisées.

Il existe d’autres dépendances essénailles pour le fonctionnement du plug-in comme

« org.eclipse.ui » qui contient la bibliothèque graphiques de SWT. Le projet

«ma.ensao.pfa.jocolipse» déclare plusieurs extensions :

o « org.eclipse.ui.perspective » cette extension est utilisée pour ajouter une

nouvelle perspective à l’espace de travail d’Eclipse. Une perspective est un

ensemble de vues qui permet de travailler sur un thème donné.

Figure 20 : Dépendances du Plugin JOCOLipse

Page 47: Rapport INES

46

o « org.eclipse.ui.newWizards » Une extension permettant de créer un nouveau

wizard et de le mettre dans la boite de dialog qui contient l’ensemble de projets

existe dans la plateforme Eclipse. Cette boite de dialogue s’ouvre lors de la

création d’un nouveau projet. Chaque wizard est placé dans une seule catégorie,

définit une classe qui hérite de la classe de base d’un wizard, et contient une ou

plusieurs pages. Cette extension est utilisée pour la création d’un nouveau projet

Joco.

o « org.eclipse.ui.menus » Une extension qui ajoute des actions dans le menu

principal, la barre d’outils, ou dans le menu d’une vue. Elle est utilisée pour

l’ajout du bouton « générer » dans la barre d’outils.

o « org.eclipse.ui.handlers » Une extension qui permet de définir le

fonctionnement d’une action ou d’un bouton, Elle utilise le principe d’un

écouteur qui écoute le lancement d’une commande pour exécuter une méthode

d’une classe.

o « org.eclipse.ui.exportWizards » Une extension pour créer un wizard de type

export dans la boite dialog d’export.

o « org.eclipse.ui.perspectiveExtensions » Une extension qui permet de

personnaliser une perspective donnée, essentiellement pour personnaliser les

menus et la barre d’outils.

Page 48: Rapport INES

47

Dans notre cas, nous devons étendre de la perspective Joco pour ajouter un raccourci

vers la création d’un nouveau projet dans la barre de menu comme il est montré ci-dessus.

Le résultat sera l’ajout d’une nouvelle catégorie dans la page de création d’un nouveau

projet d’Eclipse, et elle contient un seul wizard. Ce nouveau projet contient un seul graphe où

l’utilisateur pourra glisser ses composants graphiques les interconnecter, et ensuite générer et

exporter le code de son projet compatible avec Eclipse Scoute et Jadex.

Cette phase de génération est faite à partir d’une méthode transformant le fichier

descriptif du graphe en un ou plusieurs fichiers xml et classes java dédiées à la plateforme

Jadex.

Figure 21 : Différentes Extensions de JOCOLipse

Page 49: Rapport INES

48

La dernière phase consistant à exporter le projet sera guidée par un wizzard choisissant

l’emplacement et le nom du projet à exporter. Le projet exporté sera constitué de trois plugins

suivant la spécification des projets Eclipse Scout, à savoir :

o Plugin de la partie client : Contient les interfaces de l’application.

o Plugin de la partie server : contient les classes java les ADFs, et les différents

traitements.

o Client pour la partie shared : cette partie gère les liaisons et les communications

entre les deux parties précédentes.

La structure du module généré est la suivante :

d. Tests unitaires

Durant le développement de chacune des phases du plugin JOCOLipse, nous avons

réalisé des tests unitaires pour nous assurer du bon fonctionnement de chacune d’elle. La

première difficulté que nous avons rencontrée était au niveau de la validation des graphes de la

palette, En effet, nous avons procédé au départ à une validation par schéma xml avant de faire

recours aux facilités que proposent les modèles Ecore pour la création des méta-modèles. Ces

tests nous ont aussi permis de découvrir et corriger certains problèmes et anomalies surtout

concernant le méta-model qui rassemble un grand nombre de composants, il fallait aussi

préciser un élément père de tous les autres éléments. D’autre part nous avons rencontré dans la

récupération du nom du projet puisque l’environnement du PDE ne fournit aucune méthode

pour récupérer une telle information. Un autre problème était lié au changement de la

perspective après la création d’un nouveau projet Joco, en effet même si nous précisions la

valeur de l’attribut « final perspective » dans le wizard de création, le changement ne

fonctionnait pas.

Après avoir résolu ces problèmes dont les solutions sont précisées dans le document

plugin-jocolipse.pdf, nous sommes passés à la phase d’intégration.

Figure 22 : Architecture de JOCOModule

Page 50: Rapport INES

49

e. Tests d’intégration, livraison et rétrospective

Les différents fragments du plugin étant séparés, nous avons procédé au regroupement.

Le problème majeur rencontré durant cette opération et l’ajout des dépendances. Ces

dépendances n’étant pas toutes reconnues, un eclipse configuré (les plugins spray et graphiti

installés) sera exigé pour les utilisateurs.

Nous avons constaté un deuxième dans la partie de l’exportation du projet, où nous

utilisons des fichiers templates qui sont situés dans le répertoire des ressources de plugin, le

problème consiste dans la récupération des chemins de ces fichiers. Pour résoudre ce problème,

nous avons utilisé une classe fournie par la plateforme Eclipse et qui permet de récupérer un

fichier de ressource statique (cf : document plugin-jocolipse.pdf).

Conclusion

Après avoir effectué une pile de tests et d’améliorations nous avons constaté que le

plugin est opérationnel permettant ainsi de satisfaire les objectifs précédemment conçus, nous

l’avons donc livré au SCRUM master qui l’a considéré donc valide.

II- Mise en place du noyau JOCOCore

La réalisation d’une application modulaire exige la mise en place d’un

conteneur des modules générés afin d’assurer leur intégration et leur

communication.

L’étape précédente consistait à la réalisation d’un plugin JOCOLipse qui

automatise et facilite le processus de création d’un JOCO module. Ce dernier est

généré à partir d’une description XML Des interconnexions entre les éléments O-

MaSE représentés dans la palette Graphique.

Page 51: Rapport INES

50

a. Calendrier et Backlog

La réalisation du noyau a constitué un release de deux sprints et a été clôturée par une

livraison.

Sprint 5

Objectif : Modélisation du noyau JOCOCore

Date de début : 16 Mai 2013 Date de fin : 23 Mai 2013

Vélocité : 48 heure/homme Facteur de focalisation : 80%

User Stories incluses : 17, 18, 19, 20, 21, 22 et 23

Sprint 6

Objectif : Réalisation du noyau JOCOCore

Date de début : 27 Mai 2013 Date de fin : 3 Juin 2013

Vélocité : 48 heure/homme Facteur de focalisation : 80%

User Stories incluses : 17, 18, 19, 20, 21, 22 et 23

Ces sprints étaient composés de plusieurs userstories qui à leurs tour étaient éclatés en tâches :

User Storie Tâches

Réalisation JOCOLipse v1.0 : Création

distrubition - Eclipse JOCO

Lancement de Jadex dans Scout I

Lancement de Jadex dans Scout II

Communication interne des agents du noyau

Gestion de la communication entre le noyeau & Jadex

Réalisation JOCOCore v2.0 :

Modélisation des BDIStarter dans Jadex

Rédaction du rapport I

Réalisation JOCOCore v2.0 : Modélisation

du noyau (Application Scout)

Rédaction du rapport II

Génération des ADFs

Amélioration de la palette

Création d'exemples de testes

Page 52: Rapport INES

51

User Stories Tâches

Réalisation JOCOCore v2.0 :

Modélisation de la communication externe

du noyau

Gestion de la communication Jadex Scout part 1

Gestion de la communication Jadex Scout part 2

Gestion de la communication Jadex Scout part 3

Rédaction des spécifications et du rapport Rédaction du rapport 1

Rédaction du rapport 2

Rédaction du rapport 3

Le résultat du noyau était un conteneur des modules générés par la distribution

JOCOLipse et qui assurait le lancement de la plateforme Jadex.

b. Modélisation du noyau

Le noyau JOCOCore est le cœur de notre application, il est basé sur la

distribution Eclipse Scout qui a pour avantage le regroupement des deux parties

client et serveurs dans une même instance du projet. D’autre part Eclipse Scout

sépare les différentes parties du projet et gère leur déploiement sous forme de trois

plugins à savoir : Server, Client et shared.

La partie serveur du noyau se base dans son fonctionnement sur les services.

En effet tous les traitements réalisés doivent êtres encapsulés dans un service qui

gère leur démarrage et leur arrêt. De plus le déploiement de l’application peut être

fait sous trois formes : Desktop, Mobile ou web.

Figure 23 : Architecture du Serveur de JOCOCore

Page 53: Rapport INES

52

Les modules JOCO étant composés d’un plugin serveur, ce dernier utilise les

services offerts par le serveur du JOCOCore.

La partie client du noyau est composée essentiellement des interfaces qui assurent la

communication entre l’utilisateur et le traitement associé du coté serveur.

Les modules JOCO étant composés d’un plugin client, ce dernier sera injecté dans la

partir client de JOCOCore.

c. Réalisation du noyau JOCOCore

La première phase de la réalisation du noyau JOCOCore consiste à créer un nouveau

projet Scout, et de le personnaliser par la suite en créant une interface Desktop principale, au

niveau du client. Celle-ci hérite de la classe abstraite AbstractDesktop et implémente la classe

IDesktop qui fournit un ensemble de méthode gérant la configuration de l’interface. Le

développeur possède par la suite le droit de personnaliser cette interface en ajoutant un système

d’onglets, des formes, des menus ou même des wizards.

Figure 24 : Architecture du Client de JOCOCore

Page 54: Rapport INES

53

D’autre part, la partie serveur du noyau JOCO implémente un ensemble de services

facilitant la tâche du codage au développeur. Citons à titre d’exemple les services de

configuration des différentes bases de données existantes, les services de remplissage des

tableaux et des formes, les web services. Le développeur a aussi la possibilité de créer son

propre service et de l’adapter à ses besoins. Dans notre cas, nous avons opté pour cette dernière

possibilité à savoir : la création d’un service personnalisé. En effet, nous avons procédé à la

création de plusieurs services :

- Service de lancement de la plate-forme Jadex : ce service gère le lancement et l’arrêt

de l’environnement d’exécution des agents

- Service BDIStarter : qui s’occupe du lancement des agents dans la plateforme Jadex

- Service d’envoi des requêtes: il s’occupe de l’envoi de la requête depuis linterface à

l’agent responsable de son traitement

- Service de l’ajout d’un Listner à la réponse : attend la réception du résultat du

traitement de la requête et met à jour l’interface client

La deuxième phase a pour but d’exploiter le module généré par JOCOLipse. Ceci va

être réalisé en deux étapes :

- Etape 1 : l’ajout des modules dans JOCOCore, c’est-à-dire l’import des trois plugins

généré par JOCOlipse dans l’environnement Scout. Pour le bon fonctionnement du

caractère modulaire de l’application, il faut ajouter les dépendances existantes entre

les plugins Client/ Serveur/ Shared et les même parties associées à l’architecture du

projet principal.

- Etape 2 : Définition de l’interface du module JOCO. En effet, on crée une classe

JAVA jouant le rôle du Desktop du Client JOCOModule, cette class hérite de la classe

AbstractDesktopExtention et implémente l’interface IDesktopExtention. Ensuite, on

effectue les différentes personnalisations de l’interface tel que l’ajout des formes, des

menus, des onglets, etc.

- Etape 3 : Injection de l’interface de JOCOModule créée dans la vue principale. Ceci,

sera établi par la surcharge de la méthode figurant dans le Desktop du Core, cette

méthode prend en paramètres la listes des extensions, c’est-à-dire les modules JOCO.

Page 55: Rapport INES

54

- Etape 4 : Utilisation des différents services fournis par JOCOCore à fin d’interagir

avec la plateforme Jadex gérant ainsi le cycle de vie des agents.

d. Tests unitaires

Durant la réalisation des différentes parties du noyau JOCOCore nous avons été amenés

à faire des tests unitaires afin de vérifier le bon fonctionnement de chacune d’elles appart. Les

problèmes rencontrés dans cette phase de tests étaient liés surtout à la communication interne

et externe du noyau. En ce qui concerne la communication interne la solution trouvée pour

assurer la communication entre deux agents et d’établir une communication entre les plans via

des internalevents. En ce qui concerne la communication externe, la solution des sockets

présentait un plantage de l’application ce qui nous a poussé à exploiter la solution des web

services, nous avons ainsi pu établir une communication entre les interfaces client et les agents

du serveur.

e. Tests d’intégration, livraison et rétrospective

Après nous avoir assuré du fonctionnement des différentes parties nous avons procédé

à l’intégration. Cette phase a été d’origine pour un nombre de problèmes dus essentiellement à

la grande différence entre la structure de la distribution Eclipse Scout des autres distributions

Eclipse. Parmi les problèmes rencontrés nous citons la difficulté trouvée au départ concernant

les configurations requises pour la création des applications modulaires, nous avons été

contraints d’attendre la réponse des spécialistes concernant le problème que nous avons posté

dans le forum officiel d’Eclipse Scout. Ces derniers nous ont conseillé d’utiliser quelques

héritages et des méthodes d’injection de modules. Une autre difficulté a été liée du lancement

de la plateforme Jadex, en effet après le premier lancement de cette plateforme un deuxième

démarrage s’avère impossible à cause de l’existence d’une ancienne instance en cours

d’exécution, le problème a été réglé par l’utilisation des services, au niveau du serveur

JOCOCore, qui gère le lancement et l’arrêt de la plateforme. Après avoir résolu le problème du

lancement de la plateforme, un autre problème relié au démarrage des agents BDIs dans Jadex

a fait face, ce problème qui persiste toujours n’a pas pu être résolu par la solution des services,

et le Forum Scout nous n’a pas été d’une utilité.

Page 56: Rapport INES

55

Conclusion

JOCOCore représente un conteneur de modules réutilisables dédiés à la création d’une

plateforme E-learning. C’est une application qui offre plusieurs avantages vu son caractère

modulaire ainsi que le déploiement sous trois formes (Desktop, mobile et web). Malgré les

objectifs ambitieux que nous nous sommes tracé, nous n’avons pas pu aller au-delà de la phase

du lancement de la plateforme Jadex.

Page 57: Rapport INES

56

Conclusion générale

Maintenant que notre rapport touche à sa fin, nous y avons présenté les différentes

phases pour la réalisation de JOCOLipse qui est un plugin de modélisation et de réalisation des

SMA, en vue de les intégrer dans JOCOCore qui est un noyau assurant le l’interconnexion de

ses derniers.

Afin de faciliter la tâche à toute personne désirant développer des applications orientées

agents, destinées à la plateforme Jadex et tout en suivant la méthodologie O-MaSE, le projet

JOCO a été donc réalisé. La mise en place de JOCO est passée par plusieurs étapes, et ceci en

commençant par une bonne planification et gestion des différentes ressources. Nous avions opté

pour une méthodologie de gestion de projets informatiques qui s’intéresse au potentiel humain

intitulée SCRUM. Cette méthodologie agile offre une visibilité sur l’état d’avancement du

projet et crée une atmosphère d’honnêteté au sein de l’équipe.

Notre vision de départ était la réalisation de JOCO et de nous en servir dans la réalisation

du prototype de la plateforme e-learning INESv2. La réalisation de JOCO est d’une grande

importance pour la réalisation d’une application modulaire, en effet la réalisation de

JOCOLipse et JOCOCore, présente environ les deux tiers d’INESv2.

La phase de conception a pris sa part dans le processus de réalisation. Dans cette phase

nous avons réalisé une conversion depuis la méthodologie O-MaSE vers un code spécifique

aux agents BDIs propres à l’environnement Jadex. Cette conversion est primordiale car elle

permet à un développeur ne connaissant que la méthodologie générale O-MaSE de créer son

SMA sans avoir à connaitre les spécifications d’un environnement tel que Jadex.

Dans le cas des applications Client/serveur, il est indispensable de créer les deux parties à part.

Notre choix a donc aiguillé vers la distribution Eclipse Scout, car elle offre la possibilité de

lancer une application client/serveur dans une seule instance de la machine virtuelle java.

JOCOLipse permet de générer des JOCOModules qui contiennent le code associés aux

organisations d’agents modélisés dans la palette. Ensuite vient JOCOCore pour contenir ses

différents modules et de gérer leur communication dans un SMA.

Dans la phase de documentation comme dans la phase de réalisation nous nous somme heurtés

aux problèmes liés à la documentation vu que la majorité des outils utilisés été encore

immatures et les spécialistes des forums prenaient du temps pour nous répondre.

Page 58: Rapport INES

57

Afin d’assurer la continuité du projet par les prochaines équipes, nous avons laissé une

traçabilité sous formes de documentations, de tutoriels et de guides de développement et

d’utilisation.

Une extension de ce travail serait de compléter le développement des fonctionnalités

restantes, à savoir le lancement des agents BDIs dans Eclipse Scout, l’intégration de la

communication interne et externe du noyau et finalement la réalisation d’une plateforme e-

learning basée sur les SMA.

Page 59: Rapport INES

58

Webographie

Bachmann, S. (2012, février 01). Édition graphique d'un modèle EMF : application à un modèle de

graphe. Récupéré sur http://sbachmann.developpez.com/eclipse/editiongraphiqueecore/

Documentation, I. (2004, 1 29). Generating an EMF Model using XML Schema (XSD). Récupéré sur

http://pic.dhe.ibm.com/:

http://pic.dhe.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=%2Forg.eclipse.emf.doc%2

Ftutorials%2Fxlibmod%2Fxlibmod.html

García-Ojeda, S. A.--. (2010). O-MaSE: a customisable approach to designing and building complex,

adaptive multi-agent systems. Récupéré sur http://www.dtic.mil/cgi-

bin/GetTRDoc?AD=ADA465610

Jos Warmer, K. T. (s.d.). Spray, A quick way of creating Graphiti. Récupéré sur User Guide:

https://spray.ci.cloudbees.com/job/spray-docs-

build/lastSuccessfulBuild/artifact/docs/org.eclipselabs.spray.doc.user/docs/html/SprayUserG

uide.html

Keulkeul, M. B. (2012, février 19). Support de cours sur une introduction à la modélisation avec

Eclipse EMF. Récupéré sur developpez.com:

http://mbaron.developpez.com/eclipse/introemf/

Spray-user Google Groupes. (s.d.). Récupéré sur

https://groups.google.com/forum/?fromgroups=#!forum/spray-users

Vogel, L. (2007, 08 12). Eclipse Modeling Framework (EMF) - Tutorial. Récupéré sur

http://www.vogella.com/articles/EclipseEMF/article.html

Warmer, J. (2012, 01 25). Integration of Spray & Shape DSL. Récupéré sur

https://code.google.com/a/eclipselabs.org/p/spray/downloads/detail?name=integration-

spray-shapes.pdf&can=2&q=

Page 60: Rapport INES

59

Annexe 1 : Management du projet : SCRUM

Figure 25 : Product Backlog

Figure 26 : Configuration des Sprints

Figure 27 : Configuration des membres de l'équipe

Page 61: Rapport INES

60

Figure 28 : Sprint 1

Figure 29 : Sprint 2

Figure 30 : Sprint 3

Page 62: Rapport INES

61

Figure 31 : Sprint 4

Figure 32 : Sprint 5

Figure 33 : Sprint 6

Figure 34 : Sprint 7

Page 63: Rapport INES

62

Annexe 2 : Interfaces de JOCOLipse

Figure 35 : Création d’un nouveau projet JOCO : Choix du type de projet

Figure 36 : Sélection du nom du projet et du diagramme

Page 64: Rapport INES

63

Figure 37 : Architecture du nouveau projet créé

Figure 40 : Perspective du nouveau projet créé

Figure 39 : Exemple de modélisation d’un agent de traduction

Figure 38 : Modification dans la barre d’outils

Page 65: Rapport INES

64

Figure 41 : Architecture du projet après génération des fichiers JAVA et ADFs

Figure 42 : Lancement de la procédure de l’export

Figure 43 : Choix de type du projet à exporter

Page 66: Rapport INES

65

Figure 44 : Lancement du wizard de l’export

Figure 45 : Gestion des Logs dans l’étape de l’export

Page 67: Rapport INES

66

Figure 46 : Architecture du module crée

Page 68: Rapport INES

67

Annexe 3 : JOCOCore

Figure 47 : Architecture de JOCOCore : Perspective Scout

Figure 48 : Architecture de JOCOCore : Perspective Java

Page 69: Rapport INES

68

Figure 49 : Vue principale : Module de traduction intégré dans JOCOCORE

Figure 50 : Démarrage du module de traduction