iut de Blagnac - Toulouse II
Département Informatique
1, place Georges Brassens - BP 73
31703 Blagnac Cedex
INRA de Toulouse Midi-Pyrénées
24 Chemin de Borde Rouge
BP 52627
31326 Castanet Tolosan cedex
Rapport de stage
Conception et réalisation d’une interface graphique pour l’implémentation de
modèles à compartiments dans la plate-forme RECORD
Du mardi 10 avril 2012 au vendredi 29 juin 2012
Auteur
Rémy Phelipot(Promotion 2012)
Destinataires
Patrick Chabrier
Iulian Ober
iut de Blagnac - Toulouse II
Département Informatique
1, place Georges Brassens - BP 73
31703 Blagnac Cedex
INRA de Toulouse Midi-Pyrénées
24 Chemin de Borde Rouge
BP 52627
31326 Castanet Tolosan cedex
Rapport de stage
Conception et réalisation d’une interface graphique pour l’implémentation de
modèles à compartiments dans la plate-forme RECORD
Du mardi 10 avril 2012 au vendredi 29 juin 2012
Auteur
Rémy Phelipot(Promotion 2012)
Destinataires
Patrick Chabrier
Iulian Ober
Remerciements
Je remercie tout d’abord Monsieur Regis Sabbadin de m’avoir accueilli dans son unité, ainsi que mon superviseur de stage, Monsieur Patrick Chabrier, pour son aide et son soutien constant.
Je remercie l’iut de Blagnac, pour la qualité de la formation que j’ai eu la chance de suivre, et pour toutes
les compétences que j’ai pu acquérir grâce à eux.
Je remercie également mon tuteur de stage, Monsieur Iulian Ober, pour sa visite.
Enfin, je tiens à remercier ma famille, pour le soutien qu’elle m’a apporté tout au long de ce stage.
2
Table des matières
Introduction
6
1 Présentation de l’entreprise
1.1 INRA . . . . . . . . . . . . . . . . . . . . . . .
1.1.1 Histoire . . . . . . . . . . . . . . . . . .
1.1.2 Objectifs actuels . . . . . . . . . . . . .
1.1.3 Quelques exemples de contributions . .
1.2 Site de Toulouse Auzeville . . . . . . . . . . . .
1.2.1 Historique . . . . . . . . . . . . . . . . .
1.2.2 Axes scientifiques . . . . . . . . . . . . .
1.3 Unité BIA . . . . . . . . . . . . . . . . . . . . .
1.3.1 Objectifs . . . . . . . . . . . . . . . . .
1.3.2 Organisation . . . . . . . . . . . . . . .
1.3.3 Quelques logiciels développés par l’unité
1.4 Plateforme RECORD . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
. 7
. 7
. 7
. 8
. 8
. 8
. 9
. 9
. 9
. 9
. 10
. 10
2 Présentation du projet VLE/GVLE
2.1 Objectifs scientifiques . . . . . . . . . .
2.2 Technologies utilisées . . . . . . . . . . .
2.3 Présentation de VLE / GVLE . . . . . .
2.3.1 Le fichier vpz . . . . . . . . . . .
2.3.2 Notion de paquet . . . . . . . . .
2.3.3 GVLE . . . . . . . . . . . . . . .
2.4 Notion de plugins . . . . . . . . . . . . .
2.4.1 Aspects fonctionnels des plugins
2.4.2 Architecture logicielle des plugins
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
11
11
12
12
13
15
15
16
3 Présentation et état initial du projet de stage
3.1 Présentation du sujet de stage . . . . . . . . . .
3.2 Diagramme de Forrester . . . . . . . . . . . . .
3.2.1 Présentation . . . . . . . . . . . . . . .
3.2.2 Éléments d’un diagramme de Forrester .
3.2.3 Exemple . . . . . . . . . . . . . . . . . .
3.3 Objectifs visés par le stage . . . . . . . . . . . .
3.4 État initial du projet . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18
18
18
18
19
20
20
21
4 Réalisation du stage
4.1 Moyens à disposition . . . . . . . . . . .
4.2 Moyens et méthodologies mis en œuvre .
4.2.1 Développement Agile . . . . . . .
4.2.2 Git et le processus d’intégration
4.2.3 Coding style . . . . . . . . . . .
4.2.4 Documentation doxygen . . . . .
4.3 Détail du travail effectué . . . . . . . . .
4.3.1 Commit effectués . . . . . . . . .
4.3.2 Code généré par le plugin . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
22
22
22
22
26
27
27
27
34
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 État final du projet
36
5.1 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2 Fonctionnalités effectivement implémentées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3 Prolongements envisageables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Conclusion
38
3
TABLE DES MATIÈRES
Sources documentaires
39
Annexes
40
Abstract et résumé
48
4
Table des figures
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
Extraits d’un fichier vpz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Structure d’un paquet VLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fenêtre principale de GVLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Boite de dialogue d’édition d’un modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Menu de compilation inclus dans gvle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fenêtre de simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple de plugin de modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Boite de dialogue proposant la liste des plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ligne des tags pour le plugin Forrester contenant le nom du package du plugin, le nom d’espace, le
nom de la classe générée, et un compartiment avec sa position et ses dimensions. . . . . . . . . . .
.
.
.
.
.
.
.
.
12
13
14
14
15
15
16
16
. 17
3.1
3.2
Les différents éléments d’un diagramme de Forrester . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Diagramme de Forrester représentant les équations de Lotka-Volterra . . . . . . . . . . . . . . . . . . 20
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
Tableau des commandes principales de git . . . . . . . . . . .
Exemple de message de commit . . . . . . . . . . . . . . . . . .
Étapes du processus d’intégration . . . . . . . . . . . . . . . . .
Coding style pour une classe . . . . . . . . . . . . . . . . . . . .
Coding style pour un nom d’espace . . . . . . . . . . . . . . . .
Coding style pour les accolades . . . . . . . . . . . . . . . . . .
Commit de la phase d’initialisation . . . . . . . . . . . . . . . .
Boites de dialogue crées lors du premier commit . . . . . . . . .
Commit d’ajout de la zone de dessin et des classes de modèles .
Boites de dialogue crées ou modifiées lors du deuxième commit
Commit d’ajout des schémas d’intégration . . . . . . . . . . . .
Boites de dialogue crées ou modifiées lors du troisième commit
Commit d’ajout de la gestion des conditions expérimentales . .
Commit d’ajout de la gestion des observations . . . . . . . . . .
Commit de mise à jour de la forme d’un compartiment . . . . .
Commit de changements dans la gestion de la zone graphique .
Fenêtre principale du plugin au commit du 23 mai . . . . . . .
Code généré par le plugin . . . . . . . . . . . . . . . . . . . . .
5.1
Diagramme de classes du projet en fin de stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
25
26
26
27
28
28
29
29
30
30
31
31
32
32
33
34
Introduction
Dans le cadre de ma seconde année de DUT informatique, j’ai effectué un stage à l’Institut National de Recherche
en Agronomie de Toulouse du 10 avril 2012 au 29 juin 2012, et qui s’est déroulé au centre de Toulouse-Auzeville, dans
l’unité BIA (Biométrie et Intelligence Artificielle). Le sujet du stage concernait la conception et le développement
d’un plugin graphique pour un environnement de développement permettant la modélisation et la simulation de
systèmes dynamiques : gvle. Ce plugin doit permettre d’ouvrir gvle à une nouvelle communauté d’utilisateurs
en implémentant un nouveau type de formalisme : les diagrammes de Forrester, qui représentent graphiquement
des équations différentielles. L’objectif du stage était de créer un plugin développé en langage c++ possédant une
zone de dessin permettant d’éditer graphiquement ces diagrammes, et qui configurait de manière automatique
l’environnement de simulation, afin que la tâche de l’utilisateur soit au maximum simplifiée. Le formalisme de
Forrester comprenant de nombreux éléments, le but du stage était avant tout d’initier la conception du plugin
le plus loin possible, afin que d’autres développeurs prennent le relais pour améliorer et ajouter les éléments
manquants.
Afin de vous présenter le travail que j’ai effectué à l’inra durant ce stage, je présenterai dans un premier temps
l’inra et le projet vle/gvle, puis je présenterai dans un deuxième temps le projet de stage. Dans un troisième
temps, je présenterai les différents moyens et méthodes que j’ai utilisés et appliqués durant ce stage, pour enfin
détailler le travail que j’ai effectué.
6
1 Présentation de l’entreprise
Sommaire
1.1
INRA . . . . . . . . . . . . . . . . . . . . . . .
1.1.1 Histoire . . . . . . . . . . . . . . . . . . . . .
1.1.2 Objectifs actuels . . . . . . . . . . . . . . . .
1.1.3 Quelques exemples de contributions . . . . .
1.2 Site de Toulouse Auzeville . . . . . . . . . . .
1.2.1 Historique . . . . . . . . . . . . . . . . . . . .
1.2.2 Axes scientifiques . . . . . . . . . . . . . . . .
1.3 Unité BIA . . . . . . . . . . . . . . . . . . . . .
1.3.1 Objectifs . . . . . . . . . . . . . . . . . . . .
1.3.2 Organisation . . . . . . . . . . . . . . . . . .
1.3.3 Quelques logiciels développés par l’unité . . .
1.4 Plateforme RECORD . . . . . . . . . . . . . .
1.1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
7
8
8
8
9
9
9
9
10
10
INRA
1.1.1
Histoire
Mon stage s’est déroulé au sein de l’institut national de recherche agronomique, qui fût créé en 1946 dans le
contexte d’après-guerre afin de moderniser l’agriculture française. Depuis il accompagne les changements du monde
agricole, mais aussi des filières alimentaires afin de répondre aux attentes de la société, par exemple dans le domaine
de la suffisance alimentaire. L’institut se trouve sous la double tutelle du ministère chargé de la Recherche et du
ministère chargé de l’Agriculture. Avec la mondialisation, les prérogatives de l’INRA ont changé. Les changements
d’alimentation de la population, le développement de maladies émergentes 1 , l’érosion de la biodiversité, ainsi que
les progrès que la chimie verte 2 , ont fait prendre aux travaux de l’INRA une dimension mondiale, et les approches
qui permettent de répondre à ces problématiques ne sont plus les mêmes que par le passé.
L’institut possède actuellement un dispositif de recherche décentralisé, et mutualisé comptant prés de 2800
chercheurs, ingénieurs, techniciens et administratifs, ainsi que 2000 doctorants. Ces effectifs sont répartis en 19
centres régionaux et 14 départements scientifiques. L’INRA occupe le deuxième rang mondial et le premier en
Europe pour le nombre de publications en sciences agricoles et en sciences de la plante et de l’animal.
1.1.2
Objectifs actuels
Les objectifs principaux de l’INRA sont les suivants :
– produire et diffuser des connaissances scientifiques dans de nombreux domaines comme les sciences de la
vie, mais aussi dans les sciences économiques et sociales, les mathématiques et l’informatique appliquée, les
sciences de l’environnement, ou les sciences de l’aliment ;
– concevoir des innovations et des savoir-faire pour la société qui permettent le développement d’entreprises
agricoles, industrielles ou de services. De manière générale, l’INRA permet donc de favoriser l’emploi, en
partageant ses découvertes au plus grand nombre ;
– éclairer, par son expertise, les décisions des acteurs publics et privés ;
– développer la culture scientifique et technique et participer au débat science/société ;
– former à la recherche et par la recherche, grâce à l’accueil de doctorant et à des partenariats établis avec de
nombreux établissements de l’enseignement supérieur.
En outre, au terme d’analyses prospectives et de nombreuses consultations auprès de la communauté scientifique
et d’industriels, des chantiers de recherche ont été mis en place pour la période 2010-2020 sur des domaines très
variés :
1. infections nouvelles, causées par l’évolution ou la modification d’un agent pathogène ou d’un parasite existant
2. produits et procédés chimiques permettant de réduire ou d’éliminer l’utilisation et la synthèse de substances dangereuses ou
toxiques.
7
1.Présentation de l’entreprise
– Améliorer toutes les composantes de l’agriculture en conjuguant la performance économique, sociale et la
préservation de l’environnement ;
– Assurer des systèmes alimentaires sains et durables en étudiant les relations de causalités entre l’alimentation
et la santé ;
– Atténuer le réchauffement climatique et s’y adapter ;
– Valoriser la biomasse en synthétisant de nouveaux produits via les biotechnologies, et en analysant les méthodes de production.
1.1.3
Quelques exemples de contributions
Depuis plus de 60 ans, l’INRA a énormément contribué dans le domaine de la recherche sur de nombreux
domaines. Voici quelques-unes de ces contributions :
L’étoile de Choisy
Inscrite au catalogue officiel français en 1950, l’étoile de Choisy 1 est une variété de blé issu de plusieurs croisements entre différentes variétés de blé. Elle allie à la fois une très grande précocité, une forte productivité, une
assez bonne résistance au froid, ce qui a permis un renouveau agricole dans le sud-ouest de la France.
L’ultrafiltration du lait
L’ultrafiltration du lait 2 est un procédé industriel qui permet d’éliminer partiellement les petites molécules
présentes dans le lait. Breveté en 1969, après 14 ans de mise au point, ce procédé est aujourd’hui très utilisé afin
de fabriquer des fromages. L’ultrafiltration est un exemple de coopération entre des scientifiques de l’INRA et
des industriels, puisque ce procédé a été développé avec des chercheurs, mais aussi avec Jean-Claude Guilloteau,
fromager, qui créera quelques années plus tard la société « Fromagerie Guilloteau » qui fabrique encore aujourd’hui
le pavé d’Affinois en utilisant ce procédé.
1.2
Site de Toulouse Auzeville
1.2.1
Historique
Le centre de Toulouse-Auzeville est l’un des 19 centres Inra répartis sur l’ensemble de la métropole. Le centre
compte 950 agents, dont 300 chercheurs, et bénéficie d’une croissance forte depuis sa création en 1970. Il est
actuellement dirigé par Michèle Marin. Le site d’Auzeville est composé de 15 unités de recherches, dont 12 d’entre
elles sont associées avec des universités ou des établissements de l’enseignement supérieur :
AGIR : Agrosystèmes et agriculture, gestion des ressources, innovation et ruralité, en association avec l’inpt 3 ,
l’ensat 4 et eip 5 ;
BIA : Biométrie et intelligence artificielle ;
CEFS : Comportement et écologie de la faune sauvage ;
DYNAFOR : Dynamique et écologie des paysages agroforestiers avec l’inpt, l’ensat, et l’eip ;
GBF : Génomique et biotechnologie des fruits avec l’inpt, et l’ensat ;
GREMAQ : Groupe de recherche en économie mathématique et quantitative avec l’ut1 et le cnrs 6 ;
IHAP : Interaction hôtes agents pathogènes avec l’inpt et l’envt 7 ;
LCA : Laboratoire de chimie agro-industrielle avec inpt et ensiacet 8 ;
LERNA : Laboratoire d’économie des ressources naturelles avec l’ut1 et le cnrs ;
LGC : Laboratoire de génétique cellulaire en association avec l’inpt et l’envt
LIPM : Laboratoire des interactions plantes micro-organismes avec le cnrs ;
LISBP : Laboratoire d’ingénierie des systèmes biologiques et des procédés avec le cnrs et l’insa de Toulouse ;
SAGA : Station d’amélioration génétique des animaux ;
TANDEM : Tissus animaux, nutrition, digestion écosystème et métabolisme avec l’inpt et l’ensat ;
TOXALIM : Toxicité alimentaire avec l’inpt, l’envt, l’eip et l’ut3 ;
1.
2.
3.
4.
5.
6.
7.
8.
http://www.inra.fr/60ans/60_ans_de_resultats/etoile_de_choisy
http://www.inra.fr/60ans/60_ans_de_resultats/l_ultra_filtration_du_lait
Institut National Polytechnique de Toulouse
École Nationale Supérieure d’Agronomie de Toulouse
École d’ingénieur de Purpan
Centre national de la recherche scientifique
École nationale vétérinaire de Toulouse
École nationale supérieure des ingénieurs en arts chimiques et technologiques
8
1.Présentation de l’entreprise
1.2.2
Axes scientifiques
Cinq domaines de recherches principaux sont représentés sur le site de Toulouse Auzeville :
Le génome et l’amélioration des productions
Cet axe de recherche permet de comprendre l’organisation et le fonctionnement de l’ensemble des gènes d’un
organisme, pour ensuite sélectionner ceux qui ont un grand intérêt (au niveau de la qualité, de la résistance, etc.).
Plus d’un tiers des effectifs du centre sont associés à cette mission. Le but de ces recherches est de proposer aux
éleveurs de nouvelles connaissances permettant l’adaptation de leurs produits aux contraintes environnementales.
La sécurité sanitaire des aliments
L’objectif de cet axe de recherche est de développer des connaissances pour comprendre les effets et les mécanismes d’action des produits toxiques sur chaque étape du processus de production alimentaire. Ces travaux
permettent de mettre au point des outils de détection, de connaître les risques des produits, et donc de formuler
des recommandations à l’échelle de l’Union européenne pour obtenir des produits alimentaires toujours plus sains.
La transformation des produits agricoles
Dans une optique de développement durable, cet axe de recherche vise à concevoir des produits (énergie, produits
chimiques, et matériaux) issus de la biomasse 1 . L’optimisation de ces procédés permet des partenariats avec des
industriels afin de mettre au point des technologies nouvelles, saines pour l’environnement et économe en énergie.
L’économie de l’environnement et des marchés
Le but de cet axe de recherche est de créer des outils afin d’aider les pouvoirs économique et financier à anticiper
les attentes de la société sur les sujets environnementaux. Les économistes de l’inra construisent donc des modèles mathématiques afin de simuler des scénarios prospectifs sur les sujets sensibles (changement climatique, taxe
carbone, crise sanitaire) mais aussi dans de nombreux autres domaines (marchés agricoles, filière agroalimentaire).
L’environnement, le territoire et la société
Cet axe de recherche consiste à travailler sur les relations qui existent entre les ressources agricoles et environnementales et les processus de décision humains. Le but de ces travaux est de fournir des outils afin d’améliorer
la gestion de ces ressources et des structures agronomiques tant sur le plan de l’efficacité que du développement
durable.
1.3
Unité BIA
Ayant effectué mon stage dans l’unité bia de l’inra de Toulouse, je vais maintenant vous présenter les objectifs
de cette unité, son organisation et quelques exemples de logiciels développés par leurs soins.
1.3.1
Objectifs
Les objectifs de l’unité bia sont de développer et d’appliquer des méthodes statistiques et d’intelligence artificielle
dans deux domaines principaux :
– l’analyse et la gestion des systèmes de production et des ressources physiques.
– l’analyse de la structure et de la fonction des génomes.
Les recherches concernent la prévision à différentes échelles du comportement d’un système, l’aide à la décision
dans la conduite des systèmes et la bio-informatique. Ces recherches s’accompagnent d’une activité de production
de logiciels et d’une activité de formation pour leur diffusion.
1.3.2
Organisation
L’unité est dirigée par Régis Sabbadin, et est divisée en 2 équipes de recherches : MAD (Modélisation des
Agro-écosystèmes et Décision) et SaAb (Statistiques et Algorithmique pour la Biologie). Elle fait également partie
de 2 plate-formes : GENOTOUL ainsi que RECORD, dans laquelle j’ai effectué mon stage. (voir annexe I)
1. Ensemble des matières organiques d’origine végétale (algues incluses), animale ou fongique pouvant devenir source d’énergie par
combustion
9
1.Présentation de l’entreprise
1.3.3
Quelques logiciels développés par l’unité
Les logiciels produits par l’unité sont à destination des chercheurs de l’inra et de la communauté scientifique,
des biologistes ou bien des agronomes. Citons par exemple :
– Toulbar : outil de résolution pour des réseaux de contraintes pondérées ;
– RNAspace : plateforme d’annotation d’ARN non codant ;
– Eugène et FrameD : logiciels de prédiction de gène ;
– Cathagène : cartographie génétique et carte hybrides irradiées ;
– Milpat : localisation de motifs structurés ;
– MCQTL : détection de QTL
– MDP Toolbox : fonctions MATLAB pour modéliser et résoudre un problème décisionnel de Markov ;
– RECORD : plateforme de modélisation et simulation pour l’aide à la conception et à l’évaluation de système
de culture ;
– DIESE : bibliothèque c++ de développement de simulateurs de systèmes pilotés à l’événement discret.
1.4
Plateforme RECORD
Pour les agronomes, les expérimentations aux champs sont indispensables, mais très coûteuses, longues à mettre
en place et limitées dans leur généricité. Voilà pourquoi depuis plusieurs décennies, l’expérimentation virtuelle à pris
un grand essor dans leur profession, ce qui leur permet de concevoir des systèmes de culture répondant aux enjeux
actuels comme le réchauffement climatique, aux problèmes environnementaux, mais aussi à la sécurité sanitaire.
Afin de faciliter le travail des chercheurs, la plateforme record fut créée en 2006. Son objectif est de répondre
aux besoins des chercheurs dans les domaines de la modélisation et de la simulation de système de culture, en
fournissant des outils permettant l’utilisation de modèles hétérogènes tels que les modèles de plante, les modèles
de sol, les modèles de bioagresseur ou les modèles de décision.
La plateforme s’articule à ce jour autour de 3 axes clés :
– un logiciel de modélisation et de simulation : vle
– des fonctionnalités permettant la connexion dynamique avec des outils tels que R 1 ou le langage de programmation python ;
– une bibliothèque de modèles partagée sur un dépôt web ainsi qu’une documentation de tous ces éléments.
La maintenance, le développement et le fonctionnement de record sont assurés par 3 entités distinctes. L’équipe
record basée à l’unité bia de l’inra de Toulouse s’occupe du développement, de la maintenance et de la formation
des utilisateurs. Le « réseau utilisateurs » de record est chargé des animations de la plateforme. Enfin, le « comité
stratégique » est chargé, comme son nom l’indique, de piloter le projet et de prendre les décisions stratégiques pour
la plateforme.
Chaque année, deux sessions de formation sont organisées pour familiariser les utilisateurs à la plateforme
record et à ses nouveautés.
1. Langage de programmation et environnement mathématique utilisé pour le traitement de données et l’analyse statistique
10
2 Présentation du projet VLE/GVLE
Sommaire
2.1
2.2
2.3
Objectifs scientifiques . . . . . . . . . . . . . .
Technologies utilisées . . . . . . . . . . . . . .
Présentation de VLE / GVLE . . . . . . . . .
2.3.1 Le fichier vpz . . . . . . . . . . . . . . . . . .
2.3.2 Notion de paquet . . . . . . . . . . . . . . . .
2.3.3 GVLE . . . . . . . . . . . . . . . . . . . . . .
2.4 Notion de plugins . . . . . . . . . . . . . . . .
2.4.1 Aspects fonctionnels des plugins . . . . . . .
2.4.2 Architecture logicielle des plugins . . . . . . .
2.1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
11
12
12
13
15
15
16
Objectifs scientifiques
vle (Virtual Laboratory Environment) est un environnement de développement permettant la modélisation et
la simulation de systèmes complexes dynamiques. Développé dans le cadre de la plateforme record (voir partie
1.4), vle propose un ensemble d’outils et de bibliothèques pour modéliser et simuler des modèles hétérogènes
spécifiés dans des formalismes différents.
Le projet est basé sur le formalisme mathématique devs : Discrete Event System Specification, qui décrit les
modèles atomiques comme un ensemble d’états, un ensemble d’entrées et de sorties et une dynamique. Les états
sont pilotés par des fonctions de transitions internes et externes. Les modèles atomiques se connectent entre eux
via les entrées et sorties pour former des modèles couplés, qui peuvent eux-mêmes être couplés à d’autres modèles.
Au sein de l’inra, vle est utilisé afin de modéliser et de simuler des agroécosystèmes qui couvrent différents
niveaux d’organisation spatio-temporelle. En outre, ces systèmes incluent une composante humaine assurant une
fonction de gestion qui influence le système naturel ou artificiel et qui est soumise à des changements plus ou moins
aléatoires (variations de climat, variations de prix, changement de réglementation).
2.2
Technologies utilisées
vle et gvle ont été développés dans le langage de programmation orienté objet c++ en utilisant les bibliothèques standards et multi-plateforme stl. Ils utilisent également la bibliothèque boost 1 qui est libre, multiplateforme et gratuite afin de faciliter le développement en ajoutant, par exemple, de nouveaux outils pour effectuer
des calculs complexes. L’interface graphique a été développée en gtkmm 2 , avec l’aide de l’éditeur graphique glade 3 .
glade permet de concevoir graphiquement des interfaces graphiques gtk en enregistrant ou éditant un fichier xml.
Grâce à l’utilisation de ces différents éléments libre et multi-plateforme, Le logiciel vle est exécutable sur de
nombreux systèmes d’exploitation différents et possède des paquets pour les distributions linux les plus courantes
comme Debian, Ubuntu, RedHat, Fedora, Mandriva et Suse, ainsi qu’un installateur windows.
Enfin, vle utilise le moteur de production 4 cmake, qui permet d’automatiser la génération de l’exécutable et
l’installation du logiciel sur toutes les plateformes, mais aussi de compiler des paquets vle, comme nous allons le
voir dans la partie suivante.
2.3
Présentation de VLE / GVLE
vle est un logiciel en ligne de commande permettant d’effectuer des simulations de modèles dynamiques. La
conception des modèles s’effectue notamment par la création de classes c++ qui permettent de définir pour chaque
modèle une dynamique temporelle, mais aussi en configurant le fichier vpz(fichier xml) du projet. Afin d’aider au
1. http://www.boost.org/
2. http://www.gtkmm.org/en/
3. http://glade.gnome.org/
4. Logiciel dont la fonction principale consiste à automatiser l’ensemble des actions permettant d’obtenir un ensemble logiciel à
partir du code source.
11
2.Présentation du projet VLE/GVLE
maximum les utilisateurs, le projet gvle vise à cacher la configuration du fichier vpz et les étapes de configurations
et de compilation, grâce à une interface graphique, ce qui permet d’ouvrir la plateforme à un plus grand nombre
d’utilisateurs. L’utilisation de vle est donc complètement indépendante de gvle.
2.3.1
Le fichier vpz
Le fichier vpz est un fichier xml permettant de décrire les éléments d’une expérience. Il permet de définir la
structure des modèles, les conditions expérimentales, ainsi que les éléments observés et la méthode d’observation.
1
2
3
4
5
<model name="a" type="atomic" dynamics="dynamicA"
conditions="conditionA" observables="obsA">
<in> <port name="..." /> </in>
<out> <port name="..." /> </out>
</model>
6
7
8
9
<dynamics>
<dynamic name="dynamicA" library="big" model="tutu" />
</dynamics>
10
11
12
13
14
15
<conditions>
<condition name="conditionA">
<port name="..."> <double>34.23</double> </port>
</condition>
</conditions>
16
17
18
19
20
21
22
23
24
25
26
<views>
<outputs>
<output name="outputa" format="distant|local" location="host:port"
plugin="text|rdata|csv|cairo..." />
</output>
</outputs>
<observables>
<observable name="obsA"> <port name="x"> <attachedview name="viewA" /> </port>
</observable>
</observables>
27
28
29
<view name="viewA" type="timed|event|finish" output="outputa" timestep="0.5" />
</views>
Figure 2.1 – Extraits d’un fichier vpz
Comme on peut le voir dans la figure 2.1, les balises « <model> », « <conditions> », « <observables> » permettent de décrire les principales informations qui concernent un modèle. Toutefois, l’utilisation de ce fichier vpz
par les utilisateurs n’est pas aisée, voilà pourquoi gvle permet de gérer ce fichier de manière automatisée.
2.3.2
Notion de paquet
Pour faciliter la gestion des projets de modélisation de l’utilisateur, vle utilise un système de paquet (aussi
appelé projet) qui permet de séparer les différents travaux. Les paquets sont enregistrés dans un dossier particulier,
qui diffère selon le système d’exploitation de l’utilisateur (’/home/username/.vle/pkgs’ pour les systèmes Linux).
En outre, chaque projet possède une structure commune que nous allons détailler.
12
2.Présentation du projet VLE/GVLE
Figure 2.2 – Structure d’un paquet VLE
Les différents dossiers permettent d’organiser le contenu du paquet de façon rationnelle, en voici leur signification :
build : Dossier contenant les fichiers intermédiaires issus de la compilation du paquet ;
cmake : Ce dossier contient les différents éléments nécessaires à la compilation du paquet sous forme de bibliothèque ;
doc : Répertoire contenant la documentation du paquet, et notamment une documentation html générée lors de
la compilation du paquet(documentation doxygen) ;
exp : Ce répertoire contient les différentes expériences du projet, ce qui correspond à un fichier vpz par expérience.
lib : Ce dossier contient les bibliothèques dynamiques générées lors de la compilation du paquet, il s’agit de fichier
« .so » sous linux et « .dll » sous windows ;
output : Répertoire contenant les fichiers de sortie des expériences ;
plugins : Dossier présent uniquement dans le cas où le paquet contient un plugin de modélisation (voir partie 2.4),
il contient les librairies et les fichiers d’execution propre au plugin ;
src : Contient les fichiers sources des différents modèles (code c++) ;
test : Dossier contenant des classes c++ de tests, qui sont exécutées à la fin de la chaîne de compilation afin de
déterminer si le comportement des modèles est correct.
Afin de faciliter la compilation des paquets, vle propose une ligne de commande permettant d’automatiser ce
processus :
vle -P nom_du_paquet configure build
2.3.3
GVLE
gvle est une interface graphique pour vle. Elle permet de simplifier la création, l’édition et la simulation de
modèles.
Fenêtre principale
La fenêtre principale (voir figure 2.3) est composée d’une zone graphique qui permet de créer des modèles,
d’ajouter des ports d’entrée ou de sortie, et de relier les modèles entre eux. Pour accéder à ce diagramme, il suffit
de créer ou de charger un paquet, et d’ouvrir une expérience (fichier vpz). Pour l’éditer , les boutons présents dans
la barre d’outils permettent d’ajouter (bouton « Add models ») et de supprimer des modèles(bouton « Delete »),
mais aussi de relier les modèles entre eux(bouton « Add links »). Enfin, La liste présente dans la partie droite de la
fenêtre principale permet de visualiser l’ensemble des modèles du diagramme, et de les modifier ou de les renommer.
13
2.Présentation du projet VLE/GVLE
Figure 2.3 – Fenêtre principale de GVLE
La fenêtre principale permet également de visualiser le contenu du paquet grâce à l’arbre présent dans sa partie
gauche, ce qui permet de connaître l’état exact du projet sans quitter l’environnement de développement. En outre,
gvle permet d’éditer les fichiers textes en appliquant si cela est nécessaire une coloration syntaxique, notamment
pour les fichiers c++.
Fenêtre d’édition d’un modèle
En double cliquant sur un modèle dans la zone de dessin ou la liste des modèles, une boite de dialogue apparaît
et permet d’éditer ses différentes caractéristiques DEVS (voir figure 2.4).
Figure 2.4 – Boite de dialogue d’édition d’un modèle
L’onglet « Ports » permet d’ajouter ou de modifier les ports d’entrées et de sortie du modèle, qui seront utilisés
par la suite pour le connecter à d’autres modèles dans la fenêtre principale. L’onglet « Conditions » contient les
conditions expérimentales du modèle, ce qui peut correspondre par exemple à des valeurs initiales de variables, ou à
la spécification d’un pas de temps pour les calculs. L’onglet « Dynamics » contient la dynamique propre au modèle,
ce qui correspond à son comportement et décrit les changements d’état qui seront opérés lors de la simulation.
Cette dynamique correspond à une classe c++ que l’utilisateur doit écrire. Toutefois, les plugin de modélisation
visent à faciliter cette étape en générant la classe. Enfin, l’onglet « Observables » permet de choisir les éléments
qui seront dans le fichier de sortie après simulation, ce qui correspond au résultat de l’expérience.
14
2.Présentation du projet VLE/GVLE
Compilation du paquet
gvle permet aux utilisateurs de compiler leur paquet de manière graphique via un menu de la fenêtre principale
(figure 2.5). Il permet de configurer, de compiler et d’installer les bibliothèques dynamique dans le paquet, et
génère automatique la documentation doxygen. Il permet également de nettoyer le paquet, c’est à dire du supprimer
tout les fichiers intermédiaires de la compilation.
Figure 2.5 – Menu de compilation inclus dans gvle
Simulation
Après avoir compilé le paquet, l’utilisateur à la possibilité de lancer la simulation grâce à une boite de dialogue
(figure 2.6). Elle permet de choisir différent façon de simuler, par exemple en proposant le choix d’effectuer la
simulation en local sur le poste de travail de l’utilisateur, ou bien en ligne.
Figure 2.6 – Fenêtre de simulation
2.4
Notion de plugins
Le but de vle est de simuler des systèmes complexes, l’utilisateur doit donc être en mesure de manipuler des
modèles atomiques ou non atomiques permettant de représenter de façon précise un problème. Afin de répondre à
ce besoin, vle permet soit d’utiliser des modèles existants, soit de créer son propre modèle. Il existe deux moyens
dans gvle pour créer un modèle : développer une classe C++ utilisant le formalisme devs, ou alors utiliser un
plugin de modélisation permettant de générer une classe c++ d’un certain formalisme.
2.4.1
Aspects fonctionnels des plugins
Les plugin de modélisation sont des paquets de gvle qui permettent à l’utilisateur de générer, avec l’aide d’une
interface graphique, le code C++ d’un modèle utilisant un formalisme particulier. En effet il suffit de manipuler
une interface graphique qui peut se présenter comme une série de champs de saisie (voir figure 2.7(a)), ou un espace
de dessin (voir figure 2.7(b)), pour générer le code source correspondant.
15
2.Présentation du projet VLE/GVLE
(a) Plugin d’équation aux différences
(b) Plugin de diagramme d’état
Figure 2.7 – Exemple de plugin de modélisation
Les plugins permettent donc à l’utilisateur :
– d’éviter de programmer en C++
– de générer le code C++ d’un modèle
– de générer les ports d’entrées et de sorties
– de générer les ports des conditions expérimentales (valeurs initiales des variables par exemple) et d’observations
– de fournir une logique spécifique à un formalisme en particulier
La classe C++ générée par le plugin hérite d’une classe générique propre au formalisme utilisé, et qui permet
d’effectuer les calculs.
2.4.2
Architecture logicielle des plugins
Point d’entrée dans gvle
Le plugin de modélisation est lancé à partir du menu « dynamics » de la fenêtre d’édition d’un modèle (voir
figure 2.4). En choisissant ce plugin parmi la liste disponible (voir figure 2.8)ou bien en double cliquant sur un
modèle existant l’utilisant, la fenêtre principale du plugin sera lancée, et permettra d’éditer la dynamique. Lors
de la fermeture du plugin, celui-ci générera la classe c++ correspondant au modèle, et configurera les conditions
expérimentales et les éléments observables (manipulation du fichier vpz).
Figure 2.8 – Boite de dialogue proposant la liste des plugins
16
2.Présentation du projet VLE/GVLE
Patron de conception MVC
Les plugins de modélisations ont été conçus en utilisant le patron de conception (ou design pattern) modèlevue-contrôleur. L’architecture mvc permet de diviser le plugin en 3 parties :
1. la vue : qui correspond à l’interface avec laquelle l’utilisateur interagit ;
2. le modèle : qui correspond à la gestion des données et de leur intégrité ;
3. le contrôleur : qui permet de gérer la vue et les données.
Dans un plugin de gvle, la vue est gérée grâce à une ou plusieurs classes c++, mais aussi par un fichier xml. En
effet, le projet utilise gtkmm, une bibliothèque permettant de créer des interfaces graphiques, et qui permet leurs
conceptions grâce à un logiciel graphique : « Glade 1 ». Après avoir conçu l’interface via « glade », un fichier xml
est sauvegardé. Ce fichier xml sera utilisé par le plugin pour dessiner les différentes interfaces graphiques.
Le modèle est géré dans gvle grâce à une ou plusieurs classe c++, et parmi celles-ci une classe permet de garder
en mémoire l’ensemble des informations du formalisme utilisé (Statechart pour le plugin de diagramme d’état par
exemple).
Enfin, il n’existe pas dans les plugin de gvle une classe contrôleur à proprement parler, celui-ci est en effet distribué
dans les classes d’interface graphique.
Classe générique ModelingPlugin
La classe « ModelingPlugin » est une classe abstraite permettant de créer un plugin pour gvle. Elle définit un
socle de méthodes virtuelles pures 2 qui permet à gvle d’exécuter le plugin. Ces méthodes sont :
– create : Appelée dans le but de créer un nouveau modèle atomique ;
– modify : Appelée dans le but d’éditer un modèle atomique existant ;
– start : Permet de lancer les interfaces graphiques.
Génération du code C++
Les plugins utilisent un « template » afin de générer le code C++ correspondant à un modèle. Ce « template »
contient la structure commune à toutes les classes C++ générées par le plugin. Le « template » est composé de
plusieurs parties, la première est la ligne des « tags » (voir figure 2.9) . Cette ligne permet de sauvegarder des
informations essentielles pour l’édition du modèle, elle permet par exemple de sauvegarder le nom de la classe,
les positions et caractéristiques des éléments graphiques du plugin (largeur, hauteur, position pour un état d’un
diagramme d’état par exemple). La ligne des « tags » est chargée automatiquement à chaque édition d’un modèle
existant, et est sauvegardée lorsque tous les changements faits par l’utilisateur sont achevés.
@@tag Forrester@vle.extension.differentialEquation
@@namespace :nomEspace ;class :classe ;634|400 ;c :comp1,275,151,71,25|
Figure 2.9 – Ligne des tags pour le plugin Forrester contenant le nom du package du plugin, le nom d’espace, le
nom de la classe générée, et un compartiment avec sa position et ses dimensions.
1. http ://glade.gnome.org/
2. à redéfinir obligatoirement dans les classes dérivées
17
3 Présentation et état initial du projet
de stage
Sommaire
3.1
3.2
Présentation du sujet de stage . . . . . . . .
Diagramme de Forrester . . . . . . . . . . . .
3.2.1 Présentation . . . . . . . . . . . . . . . . . .
3.2.2 Éléments d’un diagramme de Forrester . . . .
3.2.3 Exemple . . . . . . . . . . . . . . . . . . . . .
3.3 Objectifs visés par le stage . . . . . . . . . . .
3.4 État initial du projet . . . . . . . . . . . . . .
3.1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18
18
18
19
20
20
21
Présentation du sujet de stage
Le sujet du stage concernait la conception et la réalisation d’une interface graphique pour l’implémentation
de modèles à compartiments dans la plateforme RECORD (voir annexe II). Il s’agissait donc de développer
un plugin pour gvle qui implémentait les diagrammes de Forrester, un formalisme particulier permettant de
représenter graphiquement des équations différentielles. Cette implémentation devait être effectuée en c++, avec
le support des bibliothèques graphiques gtkmm et cairo, ainsi que de la bibliothèque boost.
Le stage devait se dérouler sous un mode de développement agile, c’est à dire avec un développement de type
itératif, chaque itération ayant ses étapes de conception, de développement, de test et de documentation. Le projet
de stage était très fortement ancré dans le monde du logiciel libre, puisque d’une part vle est un logiciel sous
licence gnu gpl 1 mais aussi car le processus de développement utilise de nombreux logiciels libres, citons par
exemple :
– le système d’exploitation des postes de travail : ubuntu, qui est un système linux libre et gratuit ;
– l’utilisation de git, logiciel de gestion de version très répandu dans les projets libres ;
– gtkmm et cairo, qui sont des bibliothèques libres et gratuites sous licence lgpl ;
– la bibliothèque boost qui est également libre et gratuite.
3.2
Diagramme de Forrester
3.2.1
Présentation
Les diagrammes de Forrester 2 permettent de représenter graphiquement des modèles à base d’équations différentielles, ce qui facilite la compréhension de systèmes complexes grâce à une approche visuelle. De façon plus
concrète, ces diagrammes font apparaître la façon dont des éléments affectent des flux et par quelles relations ces
éléments sont reliés. Ainsi, il est possible par exemple de modéliser dans le cadre d’un diagramme de Forrester, un
modèle représentant les naissances et les décès de prédateurs et de proies. De manière générale, les diagrammes de
Forrester sont utilisés pour étudier comment des écosystèmes fonctionnent.
Les diagrammes de Forrester sont composés de différents éléments que nous allons détailler (figure 3.1), puis
nous illustrerons ces diagrammes avec un exemple.
1. Cette licence permet à tout utilisateur d’exécuter le logiciel pour n’importe quel usage, d’étudier son fonctionnement et de
l’adapter à ses besoin en modifiant le code source fourni par le développeur, de redistribuer des copies, de diffuser les versions modifiées
à la communauté.
2. Jay Wright Forrester, né en 1918, il est un pionnier américain en informatique et un théoricien des systèmes.
18
3.Présentation et état initial du projet de stage
3.2.2
Éléments d’un diagramme de Forrester
Représentation
graphique
Nom
Description
Niveau ou compartiment
Représente une accumulation de flux : une variable
d’état
Flux
Variation d’un niveau, il représente un changement
de l’état du système
Canal matériel
Canal d’information
Canal de transmission d’une grandeur physique qui
se conserve
Canal de transmission d’une certaine information
qu’il n’est pas nécessaire de conserver
Nuage
Représente une source ou un puit, il correspond à un
niveau inépuisable ou insaturable
Variable auxiliaire
Une quantité d’une certaine signification du monde
physique dans le monde réel et avec un temps de
réponse instantané
Constante
Un élément du modèle qui ne change pas de valeur
Variable exogène
Variable dont l’évolution est indépendante de celle
du système, elle représente une influence de l’environnement sur le système.
Retard
Un élément qui simule des retards dans la transmission de l’information ou du matériel
Figure 3.1 – Les différents éléments d’un diagramme de Forrester
19
3.Présentation et état initial du projet de stage
3.2.3
Exemple
Figure 3.2 – Diagramme de Forrester représentant les équations de Lotka-Volterra
Le diagramme de Forrester suivant représente les équations de Lotka-Volterra qui constituent un modèle proiesprédateurs. Nous pouvons observer différents éléments dans ce diagramme : d’une part les compartiments qui
désignent les variables d’état (X pour les proies et Y pour les prédateurs) ; d’autre part les flux qui sont soit
en entrée des compartiments, ou bien en sortie ; les paramètres (a, b, c, d) ; et enfin les dépendances qui sont
représentées par les flèches pointillées entre les compartiments et les flux. Les équations correspondantes à ce
diagramme sont :
0
X (t) = aX(t) − bX(t)Y (t)
Y 0 (t) = −cY (t) + dX(t)Y (t)
On peut observer qu’un flux entrant sur le compartiment apporte de la « matière » à ce compartiment, ce
qui correspond à une valeur positive dans l’équation (aX(t) ou bien dX(t)Y(t)). À l’inverse un flux sortant d’un
compartiment enlèvera de la « matière » de celui ci, ce qui correspond à une valeur négative dans l’équation
(bX(t)Y(t) ou cY(t)).
Les flèches pointillées permettent de faire apparaître les ressources utilisées par les flux : les paramètres (a, b,
c, d) et les variables d’état X et Y.
3.3
Objectifs visés par le stage
Le but principal du projet était, avant tout, d’initier le développement du plugin afin que d’autres développeurs
puissent le poursuivre (la durée d’un stage n’étant pas suffisante). Les objectifs précis du projet furent fixés durant
les premières semaines du stage. Le travail a été subdivisé en taches permettant à chaque étape d’obtenir une
version fonctionnelle du plugin. Le but final du projet était d’obtenir une version du plugin permettant l’ajout et
la modification d’un modèle basé sur le formalisme de Forrester. Ce modèle devait être simulable et pouvoir varier
en fonction du temps (modèle non constant).
Afin de répondre à ces objectifs, les spécificités fonctionnelles et techniques suivantes devaient être réalisées :
– la gestion de la zone graphique : dessin des éléments, gestion des événements souris, rafraîchissement,
– la gestion de la persistance de la zone graphique (sauvegarde et rechargement des données graphiques, comme
par exemple la taille d’un compartiment ou sa position),
– la gestion des données du modèle (caractéristiques des compartiments et des flux, schéma d’intégration),
20
3.Présentation et état initial du projet de stage
– l’ajout, la suppression et la modification de compartiments et de flux,
– l’édition des « includes » personnalisés de l’utilisateur,
– la configuration du fichier vpz pour permettre la simulation.
Des objectifs secondaires ont également été formulés comme la nécessité d’utiliser un style particulier pour le
texte du code source du plugin (voir partie 4.2.3), ou bien le fait de documenter le code source avec des commandes
doxygen.
3.4
État initial du projet
Avant de débuter la conception et le développement du plugin, l’équipe de vle avait déjà implémenté quelques
fonctionnalités qui permirent de concentrer les efforts sur la partie graphique du plugin.
D’une part la classe générique « DifferentialEquation » héritant de « vle::devs::Dynamics » avait déjà été développée. Cette classe est utilisée comme classe parente des classes c++ générées par le plugin, et permet d’effectuer
les calculs nécessaires lors des simulations.
Par ailleurs, d’autres plugins utilisant une zone de dessin avaient été créés, notamment le plugin implémentant
les diagrammes d’état (statechart), ce qui permis de s’en servir de source d’inspiration au début du stage, et de
faciliter grandement la conception et le développement.
21
4 Réalisation du stage
Sommaire
4.1
4.2
Moyens à disposition . . . . . . . . . . . . . .
Moyens et méthodologies mis en œuvre . . .
4.2.1 Développement Agile . . . . . . . . . . . . . .
4.2.2 Git et le processus d’intégration . . . . . . .
4.2.3 Coding style . . . . . . . . . . . . . . . . . .
4.2.4 Documentation doxygen . . . . . . . . . . . .
4.3 Détail du travail effectué . . . . . . . . . . . .
4.3.1 Commit effectués . . . . . . . . . . . . . . . .
4.3.2 Code généré par le plugin . . . . . . . . . . .
4.1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
22
22
22
26
27
27
27
34
Moyens à disposition
Afin de nous aider dans la réalisation de ce stage, l’inra et l’unité bia a mis à notre disposition un certain
nombre d’outils matériels ou virtuels.
Tout d’abord, le poste de travail que nous avions à notre disposition était sous un système d’exploitation linux :
Ubuntu. La version de ce système utilisé à l’unité BIA était légèrement modifiée par rapport la version d’origine
car le compte utilisateur était stocké sur un serveur, à la manière du cloud computing, ce qui permettait de se
connecter à sa session à partir de n’importe quel ordinateur de l’unité. Le fait de travailler sous un système linux
a également grandement facilité le développement du projet, d’une part à cause des technologies utilisées par vle
comme gtkmm, cmake, boost qui sont facilement installable et utilisable sous ce système, et d’autre part car le
terminal (console) et les scripts shell permettent d’effectuer très rapidement des opérations répétitives comme la
compilation du projet, ou l’utilisation de git.
Par ailleurs, l’inra a mis à notre disposition une adresse email, que nous pouvions utiliser pour communiquer
avec les autres développeurs, ainsi qu’un intranet pour se tenir informer de la vie de l’unité, et de signaler les
éventuels retards ou empêchements. Enfin, nous avions accès à un chat irc nous permettant de poser nos éventuelles
questions aux autres développeurs de vle.
4.2
Moyens et méthodologies mis en œuvre
4.2.1
Développement Agile
Pour mener ce projet à bien, nous avons mis en place un cycle de développement s’inspirant des méthodes
AGILE. Nous effectuions des réunions régulières afin de définir les fonctionnalités à implémenter. En outre, nous
devions effectuer un développement itératif, chaque itération possédait ses objectifs et devait aboutir à une version
stable du plugin. Enfin, nous utilisions un site internet : mulcyber, qui permettait de spécifier un certain nombre
de taches qui correspondant chacune à une itération.
4.2.2
Git et le processus d’intégration
vle est un logiciel développé en mode collaboratif, associant plusieurs développeurs. Afin de garantir un processus de développement rigoureux et durable, une organisation a plusieurs niveaux d’intégration est en place.
le système de gestion de version GIT autorise de nombreux mode d’organisation. Dans ce chapitre nous allons
introduire GIT, ainsi que l’utilisation qui en fait dans le cadre de VLE
Généralités
git est un logiciel de gestion de version créé par Linus Torvalds 1 en 2005. Ce logiciel permet de conserver
l’historique des modifications apportées dans le développement d’un logiciel. Il est ainsi plus aisé de savoir quel
développeur a effectué une modification, quand il a effectué, et surtout en quoi consistait cette modification.
1. Créateur du noyau linux en 1991.
22
4.Réalisation du stage
git est plus particulièrement un logiciel de gestion de version décentralisé, cette caractéristique apporte de
nombreux avantages par rapport à d’autres systèmes de gestion de version. En effet git permet de :
– travailler de manière désynchronisée par rapport aux autres membres du projet ;
– travailler en mode hors-ligne ;
– donner aux développeurs une plus grande liberté, puisque leurs modifications ne peuvent affecter que leurs
dépôts
Fonctionnement
Afin de mieux expliquer comment git est utilisé dans le cadre du projet vle, il convient tout d’abord de définir
quelques concepts importants :
Un dépôt est un espace où sont conservées toutes les modifications apportées au code source du logiciel.
Un commit est une structure de donnée permettant de sauvegarder les informations concernant les changements
qui ont été apportés dans le code source. En outre, un commit contient d’autres informations importantes
comme le nom du développeur, la date, l’état du projet, ainsi qu’un message permettant d’éclaircir le but du
commit.
Une branche est une fonctionnalité permettant d’avoir plusieurs versions de travail dans un même dépôt, sans que
ces modifications entrent en conflits. Les branches permettent de séparer la version principale du programme,
des versions de travail, elles permettent également de travailler sur plusieurs fonctionnalités de manière
simultanée.
git est un logiciel fonctionnant en ligne de commandes, en voici quelques-unes qui sont couramment utilisées pour
récupérer ou enregistrer des modifications du code source.
git
git
git
git
git
clone adresse
branch nomdelabranche
checkout nomdelabranche
add fichier dossier
commit
git push
git fetch
git rebase
Effectue une copie locale d’un dépôt existant.
Créé une nouvelle branche dans le dépôt local.
Fait changer de branche.
Ajoute des fichiers ou dossiers pour le prochain commit.
Enregistre dans le système de gestion de version toutes les modifications ajoutées au projet. Un message de commit est créé, dans lequel il faut indiquer les
modifications apportées.
Envoi les commit sur un dépôt distant.
Met à jour le dépôt local avec une version d’un dépôt distant. Cette mise à
jour ne modifie pas l’état actuel du dépôt.
Permet de repositionner le dépôt dans un état différent, par exemple à un état
plus récent après un git fetch.
Figure 4.1 – Tableau des commandes principales de git
Dans le cadre du projet vle, et afin de rendre plus clair les messages de commit, ceux-ci doivent être écrit d’une
façon particulière (voir Figure 4.2). La première ligne du commit doit résumer les modifications apportées et ne
doit pas dépasser 50 caractères. Après une ligne blanche, le reste du message de commit permet de détailler les
modifications.
GFS2 : Allow caching of rindex glock
This patch allows caching of the rindex glock. We were previously setting the
GL_NOCACHE bit when the glock was released. That forced the rindex inode to
be invalidated, which caused us to reread rindex at the next access. However, it caused the
glock to be unnecessarily bounced around the cluster. This patch allows the glock to remain
cached, but it still causes the rindex to be reread once it has been written to by gfs2_grow.
Figure 4.2 – Exemple de message de commit
Utilisation dans le processus d’intégration
L’utilisation de git est omniprésente dans le développement de vle. Tout d’abord, le code source de la dernière
version stable est disponible grâce au dépôt public situé sur sourceforge 1 .
1. http ://sourceforge.net/projects/vle
23
4.Réalisation du stage
Au sein de l’vle, les développeurs disposent de dépôts privés accessibles sur le site internet de vle 1 , mais aussi
d’un dépôt local sur leur machine.
Il existe une hiérarchie pyramidale au sein des développeurs de vle qui permet de faciliter l’intégration des
nouvelles modifications au sein du projet (voir Figure 4.3). Patrick Chabrier est en charge de l’intégration des
modifications apportées à l’interface graphique GVLE. Gauthier Quesnel est le responsable scientifique et opérationnel de vle, il est chargé d’effectuer l’intégration des modifications apportées par les autres développeurs à la
version stable de vle.
Utilisation GIT durant le développement
Il existe 2 versions du logiciel vle : une version stable, et une version de développement. Durant ce stage,
le développement du plugin de modélisation s’est effectué sur une version en développement, car de nombreuses
modifications ont été apportées depuis la dernière version stable, et que la compatibilité du plugin entre ces 2
versions n’aurait pas été possible.
L’utilisation de git pendant le stage s’est déroulé en plusieurs étapes, et suit de près le processus d’intégration :
1. copie d’un dépôt d’une version de développement de vle sur le dépôt local : git clone ;
2. récupération des nouveautés de l’intégrateur : git fetch et git rebase ;
3. envoi des modifications sur le dépôt privé : git push ;
4. développement des nouvelles fonctionnalités ou corrections : git commit ;
5. envoi sur le dépôt privé des modifications : git push ;
6. contact par mail de l’intégrateur, afin qu’il teste les nouveautés ;
7. Refus ou acceptation des nouveautés par l’intégrateur, retour à l’étape 2.
1. http ://vle-project.org/git
24
4.Réalisation du stage
SourceForge
Dépot public
Version stable
Récupération des
modifications des
intégrateurs
Intégrateur :
Gauthier Quesnel
vle-project.org
Dépots publics
Versions de développement
Version intégration GVLE
Intégrateur :
Patrick Chabrier
Dépôt développeur
Dépot local
Mise à jour de la version
locale du developpeur
Version developpement
Developpeur
Développement
(modifications)
Figure 4.3 – Étapes du processus d’intégration
25
Publication des
modifications
4.Réalisation du stage
4.2.3
Coding style
Afin de garantir une homogénéité du code source du projet vle, certaines règles de formatage on été mises
en place pour le code source du projet : le coding style. Ces règles permettent une relecture aisée du code source,
et concernent par exemple les indentations, les espaces, ou bien le nommage des éléments. Durant ce stage, nous
avons du appliquer les règles suivantes :
Ordre des éléments d’une classe c++
1
2
#ifndef THENAMESPACE_CLASS_HPP
#define THENAMESPACE_CLASS_HPP 1
3
4
namespace thenamespace {
5
6
7
8
9
10
11
class Class : virtual, public, protected, private class1, class2
{
public:
typedefs ...
variables ... // Public attributes are rare.
functions ...
12
13
14
15
16
protected:
typedefs ...
variables ...
functions ...
17
18
19
20
21
22
private:
typedefs ...
variables ...
functions ...
};
23
24
25
} // namespace thenamespace
#endif
Figure 4.4 – Coding style pour une classe
Il existe un ordre spécifique afin de définir une classe. Les éléments de la classe doivent être placés selon leur
visibilité, de la manière suivante : tout d’abord les éléments publics, protégés, puis privés ; et dans ces domaines de
visibilité, les premiers éléments doivent être les « typedef », les variables puis les fonctions. Cet ordre permet de
voir rapidement les fonctionnalités de la classe.
Toutes les classes et les fonctions doivent être rattachées à un « nom d’espace » (namespace) afin d’éviter
d’encombrer le nom d’espace principal (std). En outre, un nom d’espace doit obligatoirement correspondre à un
dossier du projet.
Règles de nommage
Les noms d’espace doivent être écrits en minuscule, de même que les dossiers auxquels ils correspondent par
exemple :
1
2
3
namespace examples { namespace generator {
...
}}
Figure 4.5 – Coding style pour un nom d’espace
La première lettre d’une classe doit être une majuscule, et la première lettre d’une fonction doit être écrite en
minuscule. Enfin les attributs d’une classe doivent commencer par un « m » minuscule.
26
4.Réalisation du stage
Règles de mise en page
Afin d’obtenir un code source lisible, la largeur du document est fixée à 80 caractères. Pour les mêmes raisons,
une fonction ne peut dépasser les 50 lignes. Enfin l’indentation du texte est fixée à 4 caractères.
Règles pour les accolades
1
2
3
4
5
int fonction(int x)
{
if (x == y) {
...
}
6
do {
...
} while (condition);
7
8
9
10
if (x == y) {
...
} else if (x > y) {
...
} else {
...
}
11
12
13
14
15
16
17
18
switch (test.getX()) {
case 0:
...
break;
case 1:
{
...
}
default:
...
}
19
20
21
22
23
24
25
26
27
28
29
30
}
Figure 4.6 – Coding style pour les accolades
Les accolades doivent être placées selon la définition de Kernighan et Ritchie : une accolade se trouve sur l’instruction
de la ligne, sauf dans le cas d’une fonction et du case.
4.2.4
Documentation doxygen
Nous avons du mettre en œuvre durant ce stage une documentation doxygen. Cette documentation est placée
sous forme de commentaires dans le code source du plugin au niveau des classes, des méthodes et des attributs. Elle
permet de générer une documentation html contenant le détails de ces éléments, mais aussi des graphes d’appels
de fonctions et des outils de recherche permettant à un développeur étranger au projet de facilement trouver les
éléments qui l’intéresse.
4.3
Détail du travail effectué
4.3.1
Commit effectués
Afin de rendre compte de façon exhaustive du travail effectué, nous allons détailler et commenter le contenu de
chaque commit du projet de stage.
27
4.Réalisation du stage
Phase d’initialisation
commit b54d5f63ca1abb28e67929c832821d7efd66ffa8
Author : Remy Phelipot <Remy.Phelipot@toulouse.inra.fr>
Date : Thu Apr 19 13 :07 :06 2012 +0200
gvle/modeling : start the Forrester modeling plugin
To start the implementation of the first version of Forrester modeling
plugin, we have provided a minimal gui. This gui can generate a
buildable c++ class which implements a differential equation. The
include field is enabled and insert custom include lines in c++ code.
- A minimal Plugin class is added, with a basic template.
- A dialog class is added.
- An include button and a source dialog are added.
- A source code generator method is added.
- Parse methods are added, to reload an existing generated class.
- The Forrester.glade file is added.
- Doxygen documentation fields are added.
Signed-off-by : Patrick Chabrier <patrick.chabrier@toulouse.inra.fr>
Figure 4.7 – Commit de la phase d’initialisation
Ce premier commit a été effectué après la phase d’initialisation des premières semaines du stage, le 19 avril.
Il correspond à un niveau de fonctionnalité minimum, c’est à dire à la génération d’un modèle (génération du
code c++ et gestion de la persistance des informations du plugin). Afin d’accélérer le développement, une grande
partie du code source a été repris d’un plugin existant : fsa qui implémente des diagrammes d’état. Les éléments
implémentés par ce commit sont les suivants :
– une classe « plugin » permettant d’interfacer le plugin avec gvle, ainsi que de générer le code c++ du modèle
grâce à un template(voir annexe III),
– une fenêtre principale permettant de piloter le plugin (figure 4.10(a)),
– une fenêtre permettant d’éditer les includes de la classe générée (figure 4.10(b)).
(a) Fenêtre principale du plugin au commit du 19 avril
(b) Fenêtre de personnalisation des includes
Figure 4.8 – Boites de dialogue crées lors du premier commit
28
4.Réalisation du stage
Ajout de la zone de dessin et des classes de modèles
commit ef7935d2f62b19fe0988692a07b2be9f0350a4b5
Author : Remy Phelipot <Remy.Phelipot@toulouse.inra.fr>
Date : Thu Apr 26 09 :29 :59 2012 +0200
Add a Forrester drawing area and its management
To create Forrester diagrams, we add a drawing area and its management
in the project. To save all components of Forrester diagrams, we add a
model class : "Forrester". We also add several gui classes to get
informations about a Forrester compartment.
Complete list of changes :
- The drawing area in the Forrester dialog is added.
- A model class to store informations about a Forrester diagram is added.
- A model class to store informations about a Forrester compartment is added
- The Drawing area management in source file generator is added.
- A dialog to get the compartment name is added.
- "select", "add", and "delete" actions for compartments are added.
Signed-off-by : Patrick Chabrier <patrick.chabrier@toulouse.inra.fr>
Figure 4.9 – Commit d’ajout de la zone de dessin et des classes de modèles
Ce deuxième commit effectué le 29 avril a permis d’ajouter la zone de dessin, ainsi que l’implémentation des
compartiments des diagrammes de Forrester. Une fois encore, une partie du code source a été repris du plugin fsa
afin d’accélérer le développement. Les fonctionnalités suivantes ont été ajoutées au plugin lors du commit :
– une zone graphique de dessin a été ajoutée, pour permettre l’édition du diagramme ;
– des classes modèles ont été ajoutées afin de stocker les informations du diagramme et des compartiments ;
– la persistance de la zone graphique à été ajoutée, ce qui permet de recharger un diagramme en éditant le
modèle ;
– une fenêtre d’édition des compartiments a été ajoutée.
(a) Fenêtre principale du plugin au commit du 19 avril
(b) Fenêtre de saisie du nom d’un
compartiment
Figure 4.10 – Boites de dialogue crées ou modifiées lors du deuxième commit
29
4.Réalisation du stage
Ajout du choix des schémas d’intégration
commit 1921bdd29da36f8068fc37fd3903f1470fca0b7b
Author : Remy Phelipot <Remy.Phelipot@toulouse.inra.fr>
Date : Mon May 7 12 :55 :27 2012 +0200
Add the integration scheme management
Adding the support of Euler, RK4 and RSS2 integration method in
Forrester plugin. In the same time, we allow user to double click in
the drawing area, so it is now possible to edit the name (and the
timestep if the choosen integration method is RSS2) of a compartment.
Complete list of changes :
- Several windows to handle the name and the time step of a
compartment are added.
- The double click support in the drawing area is added.
- The treatment of the conditions (saving and reloading) is added.
- ’NewForresterDialog’ class is renamed ’NewCompartmentDialog’.
- The Forrester.glade file is cleaned.
- The Timestep field is added in the model of compartments.
- The CMakeLists file is updated.
Signed-off-by : Patrick Chabrier <patrick.chabrier@toulouse.inra.fr>
Figure 4.11 – Commit d’ajout des schémas d’intégration
Le troisième commit a été effectué le 7 mai. Les fonctionnalités implémentées permettent à l’utilisateur de choisir
son schéma d’intégration (méthode de calcul lors des simulations). En fonction du schéma d’intégration choisi,
l’utilisateur peut modifier grâce à une boite de dialogue un pas de temps global, ou bien un deltaQ propre à chaque
compartiment pour le mode d’intégration QSS2. Ce dernier choix a entraîné des modifications dans la fenêtre
d’édition des compartiments, pour permettre la saisie de ce deltaQ.
(a) Fenêtre principale du plugin au commit du 7 mai
(b) Fenêtre d’édition d’un (c) Fenêtre de saisie du pas de
compartiment
temps global
Figure 4.12 – Boites de dialogue crées ou modifiées lors du troisième commit
30
4.Réalisation du stage
Ajout de la gestion des conditions expérimentales
commit ea0edb72225fdb140e781a55dc34e894cfc3fb10
Author : Remy Phelipot <Remy.Phelipot@toulouse.inra.fr>
Date : Fri May 11 10 :39 :22 2012 +0200
Add experimental condition management
We add the management of experimental conditions, so it’s now possible
to initialize each variables of the Forrester diagram.
Complete list of changes :
- A spin button in the dialog of the compartment is added.
- The experimental conditions management (saving and reloading) is added.
- Some g++ debug flags to the CMakeList are added.
- Some constructors are fixed, the attributes were not initialized in
the right order.
- The settings of variables in the plugin template is added.
Signed-off-by : Patrick Chabrier <patrick.chabrier@toulouse.inra.fr>
Figure 4.13 – Commit d’ajout de la gestion des conditions expérimentales
Ce commit datant du 11 mai ajoute l’initialisation des compartiments avec une valeur initiale. Ces valeurs sont
sauvegardées dans le fichier vpz de vle. Une nouvelle fois, la fenêtre d’édition des compartiments a été modifiée
afin de permettre la saisie de cette valeur.
Ajout de la gestion des observations
commit f49100601bd386fd82881b04c4ad85bff40f3f23
Author : Remy Phelipot <Remy.Phelipot@toulouse.inra.fr>
Date : Mon May 14 15 :56 :54 2012 +0200
Add observable value support
The implementation of observable values to the Forrester plugin is
added. The generated classes can now be simulated (all variables have
a constant value).
Complete list of changes :
- The implementation of observable values is added.
- The name check of the compartment to test if the name is a numeric
or not is fixed.
Signed-off-by : Patrick Chabrier <patrick.chabrier@toulouse.inra.fr>
Figure 4.14 – Commit d’ajout de la gestion des observations
Les modifications incluent dans ce commit datant du 14 mai permirent, pour a première fois depuis le début
du projet, d’obtenir un modèle simulable avec vle. L’implémentation des observables(flux de sortie lors de la
simulation) était effectivement la dernière étape pour arriver à ce but. Par ailleurs, de légères modifications ont été
apportées à la vérification du nom d’un compartiment, afin que celui ci ne soit pas un chiffre, ce qui provoquait un
bug lors de la compilation du modèle généré.
31
4.Réalisation du stage
Mise à jour de la forme d’un compartiment
commit a68a751994c81edd1cee027dd8bd5f16ce7ac062
Author : Remy Phelipot <Remy.Phelipot@toulouse.inra.fr>
Date : Tue May 15 14 :25 :11 2012 +0200
Update the shape of the Forrester compartment
The Forrester compartment has now a rectangular form. We did also
improve the compartment focus, when we displace it or click on it.
Complete list of changes :
- The shape of compartments(background color have also changed) is
updated.
- The focus of the compartment is changed, selected compartment is now
always visible.
Signed-off-by : Patrick Chabrier <patrick.chabrier@toulouse.inra.fr>
Figure 4.15 – Commit de mise à jour de la forme d’un compartiment
Ce commit du 15 mai changea la forme des compartiments dans la zone graphique, qui était jusqu’à présent de la
même forme que les états du diagramme d’état (plugin fsa). En outre, lors de la sélection d’un compartiment, celui
ci passe au premier plan, ce qui a changé la manière de dessiner la zone graphique (le compartiment sélectionné
étant dessiné en dernier).
Changements dans la gestion de la zone graphique
commit e6d7edf56d8268d29bc56e9a4120f0e0a7086c31
Author : Remy Phelipot <Remy.Phelipot@toulouse.inra.fr>
Date : Wed May 23 17 :26 :05 2012 +0200
Add a graphical item abstract class and flows
To improve the creation of new graphical items, we add an abstract
class called "GraphicalItem", and several sub-classes : "Compartment",
"Flow", and "ForresterGI". The previous code has been adapted to this
new model. Finaly, the user can now add a flow to the forrester
diagram.
Complete list of changes :
- A new abstract class for graphical items is added.
- Several inherited classes of this new abstract class are added.
- The previous treatment of the drawing area to fit the new model is
modified.
- 2 new folders of the project (graphicalItems and dialogs) are added.
- A new graphical item, the Flow is available.
- A dialog and a class to modify the name of a Flow is available.
- A new button in the main window to add a flow is added.
Signed-off-by : Patrick Chabrier <patrick.chabrier@toulouse.inra.fr>
Figure 4.16 – Commit de changements dans la gestion de la zone graphique
Ce commit effectué le 23 mai apporte de nombreux changements dans la gestion de la zone graphique et des différents
traitements associés. La création d’une classe abstraite pour les éléments graphiques fut un élément central des
modifications, puisqu’il permit d’utiliser le polymorphisme afin de dessiner tous les éléments graphiques. En outre,
le traitement de la sauvegarde des éléments a été également modifié via l’utilisation du downcast (voir annexe VI),
afin de déterminer à quelle classe appartient un élément. Par ailleurs, ce commit ajoute un nouvel élément à la
zone de dessin : les flux qui permettent de faire varier le modèle dans le temps.
32
4.Réalisation du stage
Figure 4.17 – Fenêtre principale du plugin au commit du 23 mai
33
4.Réalisation du stage
4.3.2
1
2
3
4
5
6
7
8
Code généré par le plugin
/**
* @file dsqdsq.cpp
* @author ...
* ...
* @@tag Forrester@vle.extension.differentialEquation
@@namespace:test3;class:Test;400|400;c:c1,271,265,71,25|
;f:f1,35,306,72,20;@@end tag@@
*/
9
10
#include <vle/extension/differentialEquation/DifferentialEquation.hpp>
11
12
//@@begin:include@@
13
14
15
16
17
//@@end:include@@
namespace vd = vle::devs;
namespace ve = vle::extension::differentialEquation;
namespace vv = vle::value;
18
19
namespace test3 {
20
21
22
23
24
25
26
27
28
29
30
class Test : public ve::DifferentialEquation
{
public:
Test(
const vd::DynamicsInit& init,
const vd::InitEventList& evts)
: ve::DifferentialEquation(init, evts)
{
c1 = createVar("c1");
}
31
32
33
34
35
virtual void compute(const vd::Time&)
{
grad(c1) = 0;
}
36
37
38
virtual ~Test()
{ }
39
40
41
42
private:
Var c1;
};
43
44
} // namespace test3
45
46
DECLARE_DYNAMICS(test3::Test)
Figure 4.18 – Code généré par le plugin
Le code généré par le plugin Forrester peut être divisé en 2 parties : les tags (commentaires en en-têtes du
fichier) et la classe c++.
Les tags permettent de sauvegarder les informations importantes du plugin, et sont rechargées à l’édition d’un
modèle. On peut observer dans cet exemple : le nom de la classe générée « Test », le nom d’espace « test3 », la taille
de la zone graphique « 400|400 », la position et les dimensions des compartiments et des flux : « c :c1,271,265,71,25| »
et « f :f1,35,306,72,20 ».
Dans la classe c++, on retrouve les compartiments, définis par des attributs Var et initialisés dans le constructeur de la classe. La méthode compute est utilisée lors de la simulation, et contient les équations différentielles du
diagramme de Forrester. On peut remarquer que dans cet exemple, elles ne varient pas dans le temps (grad(c1) =
0), car les liens entre les flux et les compartiments n’ont, à l’heure actuelle, pas été implémentés (cet ajout sera
34
4.Réalisation du stage
présent avant la fin du stage).
La classe c++ est générée à partir d’un template (voir annexe III). Ce fichier contient des balises, par exemple
« for i in compartments » qui sont remplacées par des informations ciblées. À la fermeture du plugin, ce traitement
de remplacement des balises est effectué, ce qui permet d’obtenir une classe en langage c++, et qui est compilable
par vle.
35
5 État final du projet
Sommaire
5.1
5.2
5.3
5.1
Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fonctionnalités effectivement implémentées . . . . . . . . . . . . . . . . . . . . . . . . .
Prolongements envisageables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
37
37
Diagramme de classe
Figure 5.1 – Diagramme de classes du projet en fin de stage
Ce diagramme de classe représente une partie du travail que j’ai pu effectuer lors de mon stage. Nous pouvons
y voir la classe abstraite graphicalItem, qui permet de définir des éléments graphiques comme les compartiments et
les flux. Cette classe regroupe un certain nombre de membres et de méthodes communs à tous ces éléments, citons
par exemple :
– les coordonnées et les dimensions de l’élément : membres x , y, width et height
– une méthode permettant de dessiner l’élément sur la zone graphique : méthode draw
– une méthode permettant de savoir si l’élément a été sélectionné par un clic de l’utilisateur : méthode select
La classe Forrester permet de sauvegarder l’état du plugin. Elle contient un vecteur d’élément graphique (de
type GraphicalItem), le schéma d’intégration choisi par l’utilisateur, et des méthodes permettant d’ajouter ou de
supprimer des éléments graphiques du vecteur.
36
5.État final du projet
La classe Plugin est la pièce centrale de l’architecture logicielle. Elle est instanciée par gvle, et permet de
recharger et sauvegarder les données, mais aussi de lancer l’interface graphique. Cette classe possède également un
template qui permet de générer le code c++ associé au diagramme. Le template est utilisé grâce à une bibliothèque
propre à gvle, et est constitué de balises qui sont remplacées par les informations nécessaires lors de la fermeture
du plugin. Après la génération, on obtient donc une classe c++ du modèle compilable.
Enfin, la classe ForresterDrawingArea est une classe purement graphique qui permet de gérer la zone de dessin.
Elle permet de dessiner tous les éléments constitutifs du diagramme, mais aussi de gérer les actions de l’utilisateur,
comme les différents clics souris.
En nous plaçant du point de vue du modèle MVC, nous pouvons dire que les classes modèles sont représentées
par les classes Forrester, ainsi que toutes les classes filles de GraphicalItem. Ces classes contiennent toutes les
données du diagramme, et sont utilisées lors du rechargement et de la sauvegarde, mais aussi lors de l’édition du
diagramme. Les classes « vues » sont représentées par la classe ForresterDrawingArea, mais aussi les classes gérant
les boites de dialogue comme CompartmentDialog et FlowDialog.
5.2
Fonctionnalités effectivement implémentées
Au terme de ce projet de stage, la majorité des objectifs explicités dans la partie 3.3 ont été remplis. Le plugin de
modélisation que j’ai développé permet la gestion d’une zone de dessin implémentant les diagrammes de Forrester,
la configuration de l’environnement vle/gvle (modification du fichier vpz), ainsi que la génération du code c++
du modèle associé au diagramme.
Voici la liste exhaustive des fonctionnalités de la dernière version stable du projet de stage :
– l’utilisateur a la possibilité de créer un diagramme de Forrester en ajoutant des compartiments et des flux à
la zone de dessin ;
– l’utilisateur peut choisir un schéma d’intégration pour son modèle : euler, Rk4 et Qss2. En fonction du schéma
d’intégration choisi, il a la possibilité de choisir un pas de temps pour l’intégration (méthode d’intégration
Euler et Rk4), ou bien un deltaQ pour la méthode d’intégration Qss2 ;
– l’utilisateur peut intégrer directement dans le plugin des includes particuliers, ce qui lui permettra d’utiliser
d’autres classes ou types dans son modèle.
– Le plugin génère le code c++ du modèle, et sauvegarde dans ce même fichier des informations lui permettant
de recharger le modèle ;
– Le plugin configure le simulateur gvle (fichier vpz), ce qui permet de lancer la simulation sans configuration
de l’utilisateur
La dernière version de développement du plugin (version instable), permet la connexion des compartiments et
des flux grâce à des flèches. Les diagrammes de cette version pourront donc générer des modèles non constants, ce
qui constituera une première version intéressante pour les utilisateurs de l’inra. Cette version sera finalisée d’ici la
fin du stage, le 29 juin 2012.
5.3
Prolongements envisageables
Comme nous avons pu le voir dans la partie présentant les diagrammes de Forrester, ces diagrammes possèdent
de nombreux éléments. À l’heure actuelle, seuls les compartiments et les flux sont implémentés dans le plugin, il
reste donc encore de nombreux autres éléments à ajouter pour que les modélisateurs puissent créer des diagrammes
de Forrester complets. D’autre part, des améliorations en terme d’ergonomie sont encore possibles, par exemple
en mettant en place un système de zoom afin d’adapter la zone graphique à la convenance de l’utilisateur, mais
aussi en facilitant la visualisation des caractéristiques d’un élément graphique grâce à une infobulle. Le stage ne
permettant que de lancer le développement du plugin, il reste encore beaucoup de travail à effectuer sur ce projet.
37
Conclusion
Le stage que j’ai effectué à l’inra de Toulouse m’a beaucoup apporté. D’une part il m’a fait découvrir le
domaine de la modélisation des systèmes dynamiques et le domaine de la recherche agronomique en général,
que je ne connaissais pas jusqu’à présent. D’autre part il m’a permis de m’améliorer dans le langage c++ que
j’avais déjà commencé à pratiquer à l’iut de Blagnac. Ce stage m’a également beaucoup apporté au niveau des
compétences en conception et développement d’interface graphique et de dessin vectoriel, et m’a permis de découvrir
les bibliothèques Gtkmm et cairo.
Travailler dans le monde du logiciel libre, de par les outils utilisés dans le développement (ubuntu et git par
exemple) et la nature même du projet vle/gvle, a été une expérience enrichissante et m’a motivé pour participer
à d’autre développement du monde libre. Par ailleurs, le domaine de la recherche que j’ai côtoyé durant ce stage
m’a également beaucoup intéressé, et m’a interpellé quant à la possibilité de travailler dans ce domaine dans le
futur. Ainsi je pense continuer à me tenir informé concernant les opportunités d’effectuer une thèse ou bien de
travailler dans ce domaine : la recherche fondamentale restant encore un domaine abstrait pour moi, je souhaiterai
participer aux développements d’applications en relation avec le monde de la recherche.
Enfin, le fait de passer d’un contexte scolaire à un contexte professionnel m’a permis de progresser, de par les
responsabilités j’ai pu prendre lors du stage, mais aussi grâce au travail en équipe et aux relations de travail que
j’ai pu établir.
En conclusion, ce stage de fin d’études de dut informatique a été très enrichissant, tant sur le plan personnel
que professionnel, et m’a conforté dans mon projet professionnel : devenir ingénieur en informatique, afin d’acquérir
les compétences scientifiques et techniques nécessaire à ce genre de projet.
38
Sources documentaires
Sites internet
• inra (en ligne). inra, 2009, mis à jour le 7 juin 2012 (consulté le 8 juin 2012).
Disponible sur : http://www.inra.fr
• vle (en ligne). vle, 2012, mis à jour le 21 mai 2012 (consulté le 8 juin 2012).
Disponible sur : http://www.vle-project.org/wiki/Main_Page
• record (en ligne). inra, 2012, mis à jour le 4 juin 2012 (consulté le 8 juin 2012).
Disponible sur : http://www4.inra.fr/record
• Site des développeurs Gnome (en ligne). The GNOME Project, 2005-2011 (consulté le 24 mai 2012).
Disponible sur : http://developer.gnome.org
• Site officiel de Cairo (en ligne)(consulté le 24 mai 2012).
Disponible sur : http://www.cairographics.org/
Articles encyclopédique
• Wikipédia, l’encyclopédie libre (en ligne). Fondation Wikimedia, 2003- (consulté le 8 juin 2012). Jay Wright
Forrester. Disponible sur : http://fr.wikipedia.org/wiki/Jay_Wright_Forrester
• Wikipédia, l’encyclopédie libre (en ligne). Fondation Wikimedia, 2003- (consulté le 31 mai 2012). DEVS.
Disponible sur : http://fr.wikipedia.org/wiki/Devs
39
Annexes
Tables des annexes
I
II
III
IV
V
VI
Organigramme de l’unité Bia en janvier 2012
Offre de stage . . . . . . . . . . . . . . . . . . . .
Exemple de template du projet . . . . . . . . .
Méthode create de la classe Plugin . . . . . . .
Méthode modify de la classe Plugin . . . . . .
Méthode generateSource de la classe Plugin .
40
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41
42
43
44
45
46
I
Organigramme de l’unité Bia en janvier 2012
41
II
Offre de stage
Sujet de stage informatique 2012
Conception et réalisation d’une interface graphique pour l’implémentation de
modèles à compartiments dans la plateforme RECORD
Lieu : Unité de recherche INRA de Biométrie et Intelligence Artificielle (UR875 BIA)
Chemin de Borde-Rouge-Auzeville
BP 52627 - F-31326 Castanet-Tolosan cedex, France
Contacts :
– Patrick Chabrier patrick.chabrier@toulouse.inra.fr (INRA Toulouse, UR875 BIA, F-31325 Castanet-Tolosan, France)
– Olivier Martin Olivier.Martin@agroparistech.fr (INRA AgroParisTech, UMR791 MoSAR, F-75005 Paris, France)
– Hélène Raynal Helene.Raynal@toulouse.inra.fr (INRA Toulouse, UR875 BIA, F-31325 Castanet-Tolosan, France)
Contexte
Le travail proposé se situe dans le cadre du projet RECORD 1 dont l’objectif est de développer une plate-forme
informatique de modélisation et de simulation pour l’aide à la conception et à l’évaluation des systèmes de production.
Cette plate-forme vise à devenir un outil commun qui facilite le développement, le partage et la réutilisation des modèles
à l’INRA 2 . La plateforme RECORD est construite sur la base du logiciel libre VLE 3 qui constitue un environnement
informatique de multi-modélisation et de simulation reposant sur le formalisme de bas niveau DEVS 4 . Son utilisation se
fait à travers l’interface graphique GVLE. Dans l’optique d’ouvrir l’utilisation de la plateforme à une nouvelle communauté d’utilisateur, une voie d’amélioration concernant l’utilisation de la plateforme pour la construction de modèles de
systèmes dynamiques reposant sur des équations différentielles ou modèles dits à compartiments a été identifiée.
Objectif du stage
Développement d’une nouvelle extension de l’interface graphique GVLE permettant d’éditer un diagramme de type
Forrester 5 et de générer une classe C++ dérivant de celle des équations différentielles disponible au sein de VLE.
– Analyse et spécification des fonctionnalités de modélisation graphique en utilisant le logiciel ModelMaker 6 .
– Étude de l’existant et définition d’une stratégie de réutilisation.
– Conception et programmation de l’interface graphique.
Les développements seront effectués dans le cadre d’un processus de développement logiciel agile et OpenSource
préétabli, en utilisant à la fois des outils de génie logiciel (GIT, SourceForge) et des bibliothèques standards (Boost,
Glade, gtkmm).
Compétences demandées & profil
Langage de programmation C++, Modélisation conceptuelle, Méthodes du génie logiciel. Goût pour le développement
logiciel et en particulier des interfaces graphiques. Intérêt concernant le domaine de la modélisation et la simulation des
systèmes dynamiques. Le candidat devra justifier d’un niveau équivalent Master I en informatique.
Le travail donne droit à une indemnité de stage de 400e/mois.
1.
2.
3.
4.
5.
6.
Rénovation et CooRDination de la modélisation de cultures pour la gestion des agro écosystèmes,http ://www4.inra.fr/record
Institut national de la recherche agronomique, http ://www.inra.fr/
Virtual Laboratory Environment, http ://www.vle-project.org
Discrete EVent Specification, Zeigler, B.P., 1976. Theory of Modeling and Simulation. Wiley Interscience.
Forrester, J.W., 1977. Principles of Systems. MIT Press.
Citra, M. J. (1997). Modelmaker 3.0 for Windows. Journal of Chemical Information and Modeling, 37(6), 1198-1200.
42
III
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
Exemple de template du projet
const std::string PluginForrester::TEMPLATE_DEFINITION =
"/**\n"
"␣␣*␣@file␣{{classname}}.cpp\n"
"␣␣*␣@author␣...\n"
"␣␣*␣...\n"
"␣␣*␣@@tag␣Forrester@vle.extension.differentialEquation␣"
"@@namespace:{{namespace}};"
"class:{{classname}};{{width}}|{{height}};"
"c:{{for␣i␣in␣compartments}}"
"{{compartments^i}}|"
"{{end␣for}};"
"f:{{for␣i␣in␣flows}}"
"{{flows^i}}|"
"{{end␣for}};"
"fa:{{for␣i␣in␣flowsArrows}}"
"{{flowsArrows^i}}|"
"{{end␣for}};"
"@@end␣tag@@\n"
"␣␣*/\n\n"
"#include␣<vle/extension/differentialEquation"
"/DifferentialEquation.hpp>\n\n"
"//@@begin:include@@\n"
"{{include}}\n"
"//@@end:include@@\n"
"namespace␣vd␣=␣vle::devs;\n"
"namespace␣ve␣=␣vle::extension::differentialEquation;\n"
"namespace␣vv␣=␣vle::value;\n\n"
"namespace␣{{namespace}}␣{\n\n"
"class␣{{classname}}␣:␣public␣ve::DifferentialEquation\n"
"{\n"
"public:\n"
"␣␣␣␣{{classname}}(\n"
"␣␣␣␣␣␣␣const␣vd::DynamicsInit&␣init,\n"
"␣␣␣␣␣␣␣const␣vd::InitEventList&␣evts)\n"
"␣␣␣␣:␣ve::DifferentialEquation(init,␣evts)\n"
"␣␣␣␣{\n"
"{{for␣i␣in␣createVar}}"
"␣␣␣␣␣␣␣␣{{createVar^i}}\n"
"{{end␣for}}"
"␣␣␣␣}\n\n"
"␣␣␣␣virtual␣void␣compute(const␣vd::Time&)\n"
"␣␣␣␣{\n"
"{{for␣i␣in␣equations}}␣"
"␣␣␣␣␣␣␣{{equations^i}}\n"
"{{end␣for}}"
"␣␣␣␣}\n\n"
"␣␣␣␣virtual␣~{{classname}}()\n"
"␣␣␣␣{␣}\n\n"
"private:\n"
"{{for␣i␣in␣definitionVar}}"
"␣␣␣␣{{definitionVar^i}}\n"
"{{end␣for}}"
"};\n\n"
"}␣//␣namespace␣{{namespace}}\n\n"
"DECLARE_DYNAMICS({{namespace}}::{{classname}})\n\n";
43
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
\
IV
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Méthode create de la classe Plugin
bool PluginForrester::create(vpz::AtomicModel& model,
vpz::Dynamic& /*dynamic*/,
vpz::Conditions& conditions,
vpz::Observables& observables,
const std::string& classname,
const std::string& namespace_)
{
//Initialisation du plugin
std::string conditionName((fmt("cond_DTE_%1%") % model.getName()).str());
mForrester = new Forrester(classname);
mView->setForrester(mForrester);
//create conditions
vpz::Condition condition(conditionName);
mForrester->integrationScheme(Forrester::EULER);
15
//Lancement de l interface graphique
if (mDialog->run() == Gtk::RESPONSE_ACCEPT)
{
//Generation du code c++ du modele
generateSource(classname, namespace_);
generateCondition(conditions, model);
generateExperimentalConditions(conditions, model);
generateObservable(model,observables);
mDialog->hide();
destroy();
return true;
}
else
{
mDialog->hide();
destroy();
return false;
}
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
}
44
V
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Méthode modify de la classe Plugin
bool PluginForrester::modify(vpz::AtomicModel& model,
vpz::Dynamic& /*dynamic*/,
vpz::Conditions& conditions,
vpz::Observables& observables,
const std::string& conf,
const std::string& buffer)
{
//Recuperation des informations contenue dans
//la ligne des tags du fichier c++
std::string namespace_;
std::string classname;
strings_t lst;
//Class name & namespace
boost::split(lst, conf, boost::is_any_of(";"));
parseConf(lst, classname, namespace_);
mForrester = new Forrester(classname);
//Width & Heigth
strings_t wh;
boost::split(wh, lst[2], boost::is_any_of("|"));
mForrester->getForresterGI().setWidth(
boost::lexical_cast < unsigned int > (wh[0]));
mForrester->getForresterGI().setHeight(
boost::lexical_cast < unsigned int > (wh[1]));
loadConditions(lst[3]);
loadFlows(lst[4]);
loadFlowsArrow(lst[5]);
//Includes
mInclude.assign(parseFunction(buffer, "//@@begin:include@@",
"//@@end:include@@", "include"));
//Recuperation des informations de l environnement vle (vpz)
setIntegrationModeFromCondition(conditions, generateConditionName(model));
32
setIntegrationTimeStep(conditions, generateConditionName(model));
loadInitialValues(conditions, generateConditionName(model));
33
34
35
mView->setForrester(mForrester);
//Lancement de l interface graphique
if (mDialog->run() == Gtk::RESPONSE_ACCEPT)
{
//Generation du code c++ du modele/Configuration de l environnement
generateSource(classname, namespace_);
generateCondition(conditions, model);
generateExperimentalConditions(conditions, model);
generateObservable(model,observables);
mDialog->hide();
destroy();
return true;
}
else
{
mDialog->hide();
destroy();
return false;
}
return true;
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
}
45
VI
1
2
3
4
5
6
7
8
9
10
11
12
13
Méthode generateSource de la classe Plugin
void PluginForrester::generateSource(const std::string& classname,
const std::string& namespace_)
{
utils::Template tpl_(TEMPLATE_DEFINITION);
tpl_.stringSymbol().append("namespace", namespace_);
tpl_.stringSymbol().append("classname", classname);
tpl_.stringSymbol().append("width",
boost::lexical_cast < std::string > (
mForrester->getForresterGI().getWidth()));
tpl_.stringSymbol().append("height",
boost::lexical_cast < std::string > (
mForrester->getForresterGI().getHeight()));
tpl_.stringSymbol().append("include", mInclude);
14
15
16
17
18
19
20
21
tpl_.listSymbol().append("compartments");
for (graphical_items::const_iterator it = mForrester->getItems().begin();
it != mForrester->getItems().end(); ++it)
{
if (CompartmentGI* item = dynamic_cast<CompartmentGI*>(*it))
tpl_.listSymbol().append("compartments", item->toString());
}
22
23
24
25
26
27
28
29
30
tpl_.listSymbol().append("flows");
for (graphical_items::const_iterator it = mForrester->getItems().begin();
it != mForrester->getItems().end(); ++it)
{
//downcast
if (FlowGI* item = dynamic_cast<FlowGI*>(*it))
tpl_.listSymbol().append("flows", item->toString());
}
31
32
33
34
35
36
37
tpl_.listSymbol().append("flowsArrows");
for (std::list<FlowArrow*>::const_iterator it = mForrester->getFlowArrow().begin();
it != mForrester->getFlowArrow().end(); ++it)
{
tpl_.listSymbol().append("flowsArrows", (*it)->toString());
}
38
39
40
41
42
43
44
45
46
tpl_.listSymbol().append("createVar");
for (graphical_items::const_iterator it = mForrester->getItems().begin();
it != mForrester->getItems().end(); ++it)
{
if (CompartmentGI* item = dynamic_cast<CompartmentGI*>(*it))
tpl_.listSymbol().append("createVar", item->getName() + "␣=␣" +
"createVar(\"" + item->getName() + "\");");
}
47
48
49
50
51
52
53
54
55
tpl_.listSymbol().append("equations");
for (graphical_items::const_iterator it = mForrester->getItems().begin();
it != mForrester->getItems().end(); ++it)
{
if (CompartmentGI* item = dynamic_cast<CompartmentGI*>(*it))
tpl_.listSymbol().append("equations",
"grad(" + item->getName() + ")␣=␣0;");
}
56
57
58
59
60
tpl_.listSymbol().append("definitionVar");
for (graphical_items::const_iterator it = mForrester->getItems().begin();
it != mForrester->getItems().end(); ++it)
{
46
if (CompartmentGI* item = dynamic_cast<CompartmentGI*>(*it))
tpl_.listSymbol().append("definitionVar",
"Var␣" + item->getName() + ";");
61
62
63
}
64
65
std::ostringstream out;
tpl_.process(out);
mSource = out.str();
66
67
68
69
}
47
Abstract et résumé
Abstract
My professionnal training took place at the INRA, the French agronomic research institute, and more precisely
at the BIA unity (biology and artificial intelligence) of Toulouse Auzeville from the 10th April 2012 to the 29th
June 2012.
I was involved in the creation of a plugin to the existing software : GVLE. GVLE is a modeling and simulating development environment based on the discrete event formalism DEVS 1 , it is a base of the "RECORD"
platform and allows INRA researchers to model and simulate complex models.
To extend the audience of the platform, I had to implement into the plugin a new modeling formalism : the
Forrester 2 diagrams. These diagrams allow users to model differential equations in a graphical way.
To realize this project, I used c++ language, the gtkmm/cairo graphical libraries, and the model-view-controler
design pattern. My work consisted in designing and developing a drawing area which enable users to create and edit
Forrester diagrams. Furthermore, I had to configure the gvle environement with the model informations. Finaly, I
provided the c++ code generation of the associated model.
1. DEVS formalism was invented by Dr. Bernard P. Zeigler in 1976.
2. Jay Wright Forrester is a pioneer American computer engineer and a systems scientist.
48
Résumé
La plateforme record, initiée en 2006, a pour but de faciliter la mise au point et l’utilisation de modèles de
culture, ainsi que d’améliorer la qualité et l’efficacité des modélisations au sein de l’inra. Elle vise à permettre
l’utilisation de modèles hétérogènes, issus de milieux scientifiques différents, comme l’agronomie, la science du sol,
la bioclimatologie, la physiologie végétale, l’épidémiologie, les sciences de la gestion, les statistiques ou les mathématiques appliquées. Dans le cadre de cette plateforme, le logiciel vle, basé sur le formalisme mathématique devs 1 ,
a pour objectif de répondre aux attentes des chercheurs, des ingénieurs, et des modélisateurs, afin de proposer un
logiciel permettant la création, l’utilisation, et l’expérimentation virtuelle des modèles.
L’environnement de développement gvle propose une interface graphique pour vle afin d’aider et d’assister les
utilisateurs dans leur travail. Elle permet la création et l’édition graphique de modèles, un éditeur de code source,
la configuration et l’exécution des simulations. Dans le but de faciliter la modélisation, gvle peut être enrichi grâce
à des plugin, qui permettent d’ajouter la gestion de formalismes particuliers, comme par exemple les diagrammes
d’état.
Dans l’optique d’ouvrir la plateforme record à de nouveaux utilisateurs, l’ajout d’un plugin implémentant les
modèles à compartiments (aussi appelés diagrammes de Forrester 2 ) a été décidé. Les diagrammes de Forrester permettent de représenter graphiquement des modèles à base d’équations différentielles en faisant apparaître la façon
dont des éléments affectent des flux et par quelles relations ces éléments sont reliés. Les modèles à compartiments
sont couramment utilisés pour d’étudier le fonctionnement des écosystèmes.
L’objectif du stage consistait en la conception et la réalisation d’un plugin pour gvle permettant la création et
l’édition de diagramme de Forrester, ainsi que la génération de code C++ du modèle associé et la configuration de
l’environnement vle. Le travail de développement s’est articulé autour d’une zone de dessin permettant d’éditer
les diagrammes de façon simple, rapide et ergonomique.
1. Discrete EVent Specification, Zeigler, B.P., 1976. Theory of Modeling and Simulation. Wiley Interscience
2. Jay Wright Forrester, né en 1918, est un pionnier américain en informatique et un théoricien des systèmes.
49
50