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
1
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
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.
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.
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.
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
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
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
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
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
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.
12
Chapitre Premier : Etude du
projet JOCO
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).
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
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
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 :
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
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
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.
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.
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.
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
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.
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
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.
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.
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
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
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
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
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.
32
Chapitre Deuxième : Etude du
projet JOCO
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.
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
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
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 ».
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.
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
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.
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
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'
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'
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'
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'
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
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.
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
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
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.
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
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
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
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.
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é.
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.
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.
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.
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=
59
Annexe 1 : Management du projet : SCRUM
Figure 25 : Product Backlog
Figure 26 : Configuration des Sprints
Figure 27 : Configuration des membres de l'équipe
60
Figure 28 : Sprint 1
Figure 29 : Sprint 2
Figure 30 : Sprint 3
61
Figure 31 : Sprint 4
Figure 32 : Sprint 5
Figure 33 : Sprint 6
Figure 34 : Sprint 7
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
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
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
65
Figure 44 : Lancement du wizard de l’export
Figure 45 : Gestion des Logs dans l’étape de l’export
66
Figure 46 : Architecture du module crée
67
Annexe 3 : JOCOCore
Figure 47 : Architecture de JOCOCore : Perspective Scout
Figure 48 : Architecture de JOCOCore : Perspective Java
68
Figure 49 : Vue principale : Module de traduction intégré dans JOCOCORE
Figure 50 : Démarrage du module de traduction