Réalisation et extension d`un simulateur d`automates cellulaires

Réalisation et extension d'un
simulateur d'automates cellulaires :
BioDyn3D
(Image de prototype, peut être sujette à des évolutions)
Rapport de stage
du 13 octobre 2014 au 13 avril 2015
par Olivier LE FLOHIC
Maître de stage : M. Pascal BALLET
Responsable de stage : M. Goulven GUILLOU
1
Sommaire
Introduction
3
I. Contexte
4
II. Travail demandé : objectifs principaux et secondaires
5
III. Analyse de l'existant
III.A. NetBioDyn
III.B. Prototype de BioDyn3D
6
6
12
IV. Environnement et outils de développement
IV. A. Unity3D
IV. A. 1. Éditeur
IV. A. 2. Environnement de codage : MonoDevelop
IV. B. Outils d'aide au développement
IV. B. 1. SVN
IV. B. 2. doxygen et Trac
14
14
14
15
17
17
17
V. Analyse et développement
V. A. Architecture du programme
V. B. Cheminement du développement
V. C. Optimisation du programme
20
20
21
26
Conclusion
30
Remerciements
30
Outils et références
31
Annexes
32
2
Introduction
Dans le cadre de ma deuxième année de Master SIAM (Systèmes d'Information en Applications
Marines) à l'Université de Bretagne Occidentale (UBO) de Brest, j'ai effectué un stage d'analyse et
développement, au sein même de cet établissement, dans le Lab-STICC*. La durée initialement
prévue était du 13 octobre 2014 au 13 février 2015, mais elle a été prolongée jusqu'à 17 avril 2015.
L'objectif de ce stage, en autonomie, est la poursuite du développement et l'extension d'un
simulateur d'automates cellulaires s'appelant BioDyn3D, créé par M. BALLET. Il est basé sur un
simulateur existant, NetBioDyn, qui est du même auteur. La principale différence est que
BioDyn3D est, comme son nom l'indique, en trois dimensions.
Le simulateur fournit un environnement dans lequel des entités vont évoluer et interagir d'après des
comportements, définis par l'utilisateur via une interface simplifiée. En effet, l'idée est de pouvoir
configurer le modèle de simulation, sans pour autant avoir des connaissances en programmation,
puisque les principaux utilisateurs seront des étudiants en biologie.
En raison de sa nature pédagogique, il est aussi prévu de permettre aux utilisateurs d'enregistrer et
charger leurs modèles en ligne afin de pouvoir les partager, d'où la nécessité de prévoir un système
adapté.
Le développement de BioDyn3D avait déjà commencé avant le début du stage : en effet, un
prototype fonctionnel (bien que comportant des bugs) a été réalisé par l'auteur original, et a posé les
bases des spécifications du programme, ainsi que l'environnement de développement.
La réalisation du projet a non seulement exigé de se familiariser avec l'existant (NetBioDyn et le
prototype de BioDyn3D), mais aussi avec l'environnement de développement Unity3D, sur lequel
l'application est développée.
* Lab-STICC : Laboratoire des Sciences et Techniques de l’Information, de la Communication et de
la Connaissance
3
I. Contexte
BioDyn3D est destiné à des étudiants en biologie, notamment dans des pays d'Europe de l'est de
l'ex-URSS. Il s'agit d'un projet financé par l'Union Européenne, et qui fait partie d'un plus vaste
programme dont l'objectif est de permettre à ces pays de se mettre à jour sur les compétences
d'appareillage biologique, par exemple pour l'identification de bactéries.
Le programme de l'UE implique plusieurs partenaires de pays membres : le Royaume-Uni, l'Italie,
la République Tchèque, et la France. Cette dernière se concentre davantage sur les simulations
d'instruments, là où le Royaume-Uni dispose d'un matériel bien physique, mais cher et peu
accessible.
C'est tout l'intérêt d'avoir des simulateurs, et BioDyn3D en fait partie : il aspire à fournir un outil
pour la simulation de colonies bactériennes, pour qu'ensuite les étudiants puissent aller au
Royaume-Uni afin d'être formés à l'usage du matériel physique.
On notera également la coopération de l'Université de Bretagne Occidentale (UBO) et de l'École
Nationale d’Ingénieurs de Brest (ENIB) : la première se spécialise dans les simulations, tandis que
la seconde se tourne davantage vers les modélisations 3D des appareillages.
4
II. Travail demandé : objectifs principaux et
secondaires
Comme nous l'avons déjà précisé, le projet, BioDyn3D, est une amélioration de NetBioDyn qui
introduit la 3D. Par conséquent, BioDyn3D devra avant toute chose d'être au moins capable de faire
les mêmes choses, tout du moins d'un point de vue simulation.
Les fonctionnalités qu'il faudra donc forcément inclure sont :
•
•
•
•
•
•
grille redimensionnable (dimensions X, Y ; dimension Z ajoutée pour BioDyn3D)
définition / modification des entités (demi-vie)
définition / modification des comportements (probabilité, réactions entité → entité)
exécution, pause et pas-à-pas de la simulation
enregistrement / chargement de modèles de simulations
dessin / gommage d'entités sur la grille
Certaines fonctionnalités secondaires n'ont pas été retenues, parce qu'elles ne sont pas nécessaires
pour l'exécution du programme :
•
•
•
graphes de quantités d'entités
exportation des résultats de la simulation
exportation du modèle de simulation sous forme textuelle
À noter que ces fonctionnalités restent prévues, mais leur priorité est très faible.
Une fois que toutes les fonctionnalités originales de NetBioDyn seront implémentées, il sera alors
possible de se pencher sur les extensions, qui permettront à BioDyn3D de bien se distinguer de son
ancêtre. On citera comme nouveautés :
•
•
molécules : produites et consommées par les entités
réactions « simples » : différentes des réactions de NetBioDyn : chaque direction peut avoir
une entité différente. Quelque chose d'assez similaire existe déjà dans une ancienne version
de NetBioDyn.
Idéalement, on souhaiterait aussi que les fonctionnalités suivantes soient implémentées :
système de « cloud » pour stocker/charger des modèles de simulation, afin de pouvoir les
partager
• support OpenCL, ou au moins un traitement des données en parallèle : en effet, la grille peut
devenir très dense (beaucoup d'entités), ce qui aura tendance à ralentir le programme. La
parallélisation de l'exécution des comportements permettrait d'accélérer la simulation, mais
cela pourrait rendre le code plus difficile à gérer.
Enfin, il serait aussi souhaitable, à terme, de fournir une aide pour l'utilisation du programme :
tutoriels et fichiers d'exemples, pour permettre aux utilisateurs de comprendre le fonctionnement et
les possibilités de BioDyn3D.
•
5
III. Analyse de l'existant
Comme nous l'avons déjà vu à plusieurs reprises, BioDyn3D est basé sur une application existante
du nom de NetBioDyn, et il existe également un prototype de la nouvelle version. Nous allons donc
voir plus en détail ces deux applications.
(Remarque : l'analyse comporte des images, mais n'illustre pas tout. Vous pouvez retrouver
certaines des images manquantes dans les annexes.)
III.A. NetBioDyn
(Sites web : http://netbiodyn.tuxfamily.org/ et http://virtulab.univ-brest.fr/)
Logo du site de NetBioDyn
NetBioDyn a été créé par M. Pascal BALLET, qui est également mon maître de stage, et
enseignant-chercheur à l'UBO de Brest.
Le programme est codé en Java, ce qui lui permet d'être multiplate-forme : il fonctionnera que ce
soit sur Linux, Mac ou PC, pourvu que la machine virtuelle de Java soit installée. En revanche, le
code n'est pas accessible au public.
NetBioDyn présente la particularité de ne pas demander de connaissances dans un langage de
programmation ; à la place, l'utilisateur se sert d'une interface pour définir des entités et des
comportements, et la simulation s'occupe du reste.
Il existe deux autres versions de ce programme : une version plus ancienne datant de 2008, et une
version similaire, mais avec support 3D. Le principe est le même (simulateur d'automates
cellulaires), mais le fonctionnement est très différent : en effet, et étonnamment, il y a beaucoup
plus d'options de paramétrage que dans la version la plus récente de 2013, ce qui permettait de
définir des comportements de natures différentes.
Cependant, il est important de noter que ce qui peut être fait dans une version ne l'est pas forcément
dans une autre : même si la version 2013 est, semble-t-il, moins riche, elle est capable de faire
certaines choses que les versions 2008 ne peuvent pas faire. Cela peut paraître étrange, mais il y a
une raison à cette simplification.
NetBioDyn 2013
Il s'agit de la version disponible en téléchargement sur le site du programme (voir plus haut), et de
celle sur laquelle les spécifications de BioDyn3D seront principalement basées.
Il est à noter que NetBioDyn 2013 comptait aussi intégrer les grilles 3D, quoiqu'avec une interface
6
2D en vue de dessus. Cependant, cette fonctionnalité n'a jamais été totalement implémentée, même
s'il est possible d'en trouver des vestiges dans cette version.
Aperçu général
Capture d'écran sous Windows 7. La coupure du bas de l'interface est a priori un bug.
On peut constater à partir de cette image un certain nombre de fonctionnalités, bien que toutes ne
soient pas implémentées. L'image ci-dessus a été prise durant une exécution, mise en pause à l'aide
des contrôles se trouvant au dessus du canevas.
En plus des indispensables enregistrement et chargement, la fonctionnalité la plus évidente est la
grille, sur laquelle sont placées les entités. Dans notre exemple, nous avons deux types d'entités
(rouge, en bas, et vert, en haut) ; ces informations sont reflétées dans le panneau de gauche, où sont
listés les types d'entités ainsi que le nombre d'instances de chacun de ces types.
Les entités interagissent à travers des comportements ; eux aussi sont listés du côté gauche.
L'évolution des populations (engendrée par les comportements) est représentée sous la forme de
graphe à droite ; il est possible de sélectionner quelles courbes sont affichées en sélectionnant les
types d'entités à gauche. L'utilisateur a aussi l'option d'exporter le résultat de la simulation sous une
forme textuelle, ou sous la forme d'une image animée au format GIF.
Les comportements (interface illustrée dans les annexes) sont définis avec une probabilité et au
moins une entité en réactif, et une entité en produit : c'est une réaction. Il est ensuite possible de
définir jusqu'à deux réactions supplémentaires pour un comportement, ces dernières s'appliquant sur
des cases voisines sélectionnées.
La 3D est l'une des fonctionnalités annoncées mais non implémentées ; la jauge (Z=0) et la case à
cocher « 3D » (en bas à droite), qui sont inactives, en témoignent.
7
Exemples
Capture de simulation
Début (pas 0)
Pas 90
Pas 180
Pas 270
Pas 360
Fin (pas 390)
Simulation avec deux entités.
L'entité verte se propage lentement, mais a une grande demi-vie, tandis que la rouge se propage
vite, mais meurt plus rapidement., d'où les nombreux espaces vides.
Exportation du modèle
Ces informations ont été prises telles quelles de la fonctionnalité « Export modèle ».
Entites:
ent1:Mobilite x =0.0 Mobilite y =0.0 Mobilite z =0.0, 1/2 Vie =200.0
ent2:Mobilite x =0.0 Mobilite y =0.0 Mobilite z =0.0, 1/2 Vie =4.0
Comportements:
exp_ent2 : ent2 + ent2 + =0.5=>ent2 + ent2 + ent2
exp_ent1 : ent1 + ent1 + =0.01=>ent1 + ent1 + ent1
8
Exportation des courbes
Ces informations ont été prises telles quelles de la fonctionnalité « Export courbes » ; la simulation
a duré 11 pas.
t
0
1
2
3
4
5
6
7
8
9
10
11
ent1
44
43
44
44
44
44
43
43
43
43
43
43
ent2
29
32
32
38
43
43
43
45
47
55
54
51
NetBioDyn 2008 (classique et 3D)
(Note : les captures d'écran de cette partie ont été prises depuis l'applet Java disponible sur le site
de NetBioDyn.)
Cette version, plus ancienne, n'est disponible que sous la forme d'applet Java en ligne, sur le site de
NetBioDyn. Ceci pose un gros problème : déjà de sécurité (par défaut, l'applet sera bloqué par le
navigateur à moins d'ajouter le site à la liste blanche), et ensuite pour le stockage : il n'est pas
possible d'enregistrer ou de charger les simulations que l'on a créées sur ces applets, ce qui rendait
les tests un peu plus compliqués.
Il existe deux variantes de l'application : classique et 3D (qui a également un plus grand contrôle de
la caméra). Mis à part cet aspect, ces deux variantes n'ont pas de différences fondamentales ; c'est
pour cette raison que notre analyse se basera principalement sur la variante 3D, qui est un peu plus
complète.
9
Aperçu général
Variante 3D (simulation à l'arrêt)
Mis à part les éléments en rapport avec la 3D, l'interface est pour ainsi dire la même pour les deux
variantes. On constate aussi que l'agencement de l'interface est assez différent de NetBioDyn 2013,
mais on y retrouve les mêmes fonctionnalités, voire plus.
Certaines fonctionnalités semblent prévues, mais n'ont pas été implémentées : « Exporter courbes »
et « Exporter les comportements » (à droite), qui existent dans la version 2013, mais ne fonctionne
pas dans les versions 2008.
Cette fois-ci, la grille est en 3D, mais il est possible de basculer sur une vue 2D ; la taille est
configurable, mais par défaut, elle est plus petite (100x100 sur la version 2D contre 40x40x40 sur la
version 3D), vraisemblablement pour des questions de performance. De plus, la grille est toroïdale,
c'est-à-dire qu'une case en bordure est considérée comme voisine d'une case se trouvant du côté
opposé sur le même axe.
Dans cette version, il y a beaucoup plus d'options de paramétrage ; cela peut paraître étrange,
compte tenu du fait que la version plus récente (2013) est moins riche. L'explication donnée par M.
BALLET est que, bien que ces fonctionnalités pouvaient être intéressantes, elles n'avaient pas de
raison d'être : l'objectif du programme est d'offrir un environnement facile d'utilisation ; or, par sa
richesse, c'était plutôt le contraire ; une simplification majeure s'imposait donc. De plus, la version
2008 était plus lente, car plus de fonctionnalités signifie davantage de calculs.
Il était possible de configurer les entités pour qu'elles aient tendance à se grouper sous une certaine
forme, soit par « affinité », soit par charges (des charges opposées s'attirent, des charges de même
signe se repoussent). Les cases se touchant par un coin étaient aussi considérées comme voisines, et
il était possible de créer des « liens », qui permettent de forcer deux entités à maintenir une distance
donnée entre elles.
10
Enfin, on citera les comportements spécialisés, appelé « migrations » ; comme leur nom l'indiquent,
ils contrôlent les déplacements des entités. Il y a bien les comportements « ordinaires », mais ces
derniers existent en trois versions : semi-situées (tester la présence de voisins), situées en absolu
(idem, mais la position du voisin a une importance), et complexes (série de tests et d'actions si les
conditions sont remplies). Une fois encore, les options sont bien plus variées, mais il faut bien
comprendre que l'excès de fonctionnalités...
… peut décourager l'utilisateur.
11
III.B. Prototype de BioDyn3D
Le développement de BioDyn3D était déjà entamé avant le début du stage, mais interrompu faute
de temps libre pour son créateur, Pascal BALLET. Le programme était réalisé dans l'environnement
de développement Unity3D, qui, comme son nom l'indique, permet de créer des applications en 3D,
spécialisées dans les jeux-vidéo, bien qu'il soit possible de faire d'autres types de programmes,
comme le simulateur dont nous parlons.
(Pour plus d'informations sur Unity3D, voir la partie « environnement de développement ».)
Il est à noter que l'analyse portant sur le prototype de BioDyn3D a été réalisé sur un prototype
modifié, pour des questions de compatibilité et d'ergonomie. En effet : M. BALLET m'a fourni le
code source qu'il a créé sous Mac, là où j'utilise une machine avec Windows, ce qui peut poser
quelques problèmes. Cela m'a obligé à apporter quelques altérations au code pour qu'il puisse être
compilé par Unity. Ceci étant dit, le comportement de l'application n'a pas été modifié d'une façon
générale.
Aperçu général et détail des fonctionnalités
(Note : une entité correspond à un unique cube, et non à un groupement de cubes.)
Premier constat : la 3D est déjà implémentée, et il y a une interface graphique fonctionnelle
(réalisée avec l'extension Daikon Forge). On retrouve aussi certains composants familiers, comme
12
les boutons marche/arrêt et le numéro de pas d'exécution. Parmi les autres ajouts figurent les
molécules : il s'agit de nouvelles propriétés, mais ces dernières n'interagissent qu'avec certaines
entités. C'est sur cela que nous allons bientôt revenir.
Cette image n'est pas totalement exhaustive, car elle ne montre pas les éditeurs d'éléments (actions,
molécules et entités) ainsi que les deux autres listes d'éléments (actions et molécules), mais la
plupart des fonctionnalités s'y trouvent.
On retrouve beaucoup d'éléments familiers : l'environnement sur lequel sont placées les entités,
ainsi que les listes de types d'entités ; la différence ici est que les différentes listes sont associées à
des onglets, et ne sont donc pas toutes visibles simultanément.
Pour ce qui est des molécules, bien qu'elles ne soient pas fonctionnelles dans ce prototype (elles ne
peuvent pas être placées sur la grille), il est possible de les définir, de la même manière que l'on peut
créer et modifier des entités et comportements. L'idée derrière les molécules est d'avoir un système
de « ressources » : les entités consomment et produisent des molécules, et les molécules se
propagent dans la grille. La différence ici est que les molécules sont des quantités plutôt que des
instances : une case peut contenir plus d'un même type de molécule qu'une autre.
Les entités n'ont fondamentalement pas tellement évolué, mis à part les demi-vies, absentes. Pour ce
qui est des comportements, ils ont été simplifiés : deux types de réactions existent : simple et
factorisée. Le fonctionnement est très similaire aux réactions semi-situées et situées en absolu,
respectivement, la seule différence étant qu'il n'y a que six directions (nord, sud, est, ouest, audessus et en-dessous), contre huit avant (4 côtés et 4 coins sur le même plan).
Capture de l'éditeur de comportements ; à gauche, mode « factorisé » ; à droite, mode « simple ».
La taille de l'éditeur a été réduite pour ce rapport.
On notera la présence d'un champ de texte avec la mention « Lua code » : il était en effet prévu
d'intégrer un système de script Lua qui permettrait de définir des comportements plus complexes ;
malheureusement, cette fonctionnalité n'a pas pu être testée, car j'ai dû la désactiver pour pouvoir
compiler et exécuter le projet.
13
IV. Environnement et outils de développement
Quitte à se répéter, BioDyn3D est réalisé sur Unity3D : il s'agit de l'environnement dans lequel le
développement s'est déroulé. En plus de cela, nous avons utilisé des outils d'aide à la gestion de
projets, tels que SVN ou doxygen.
IV. A. Unity3D
(Site officiel : http://www.unity3d.com)
L'environnement Unity est fourni avec un éditeur, qui permet de modifier les scènes et les
propriétés des objets qui s'y trouvent. Il est combiné avec un environnement de développement (par
défaut MonoDevelop), avec compilateur et débogueur pour faciliter le codage.
IV. A. 1. Éditeur
Vue générale de l'interface d'Unity, avec une scène ouverte. Le positionnement des différentes
parties est personnalisable selon les besoins de l'utilisateur.
L'éditeur de scène est la fonctionnalité principale d'Unity : il permet, entre autres, de placer et
positionner des objets (3D ou 2D) dans la scène, et de configurer les propriétés de ces objets (les
rendre solides, changer leur masque de collision, les redimensionner...).
14
Comme indiqué dans la légende de l'image, les éléments de l'interface sont totalement
personnalisables. Chacun a sa propre fonction : l'environnement 3D permet évidemment de
manipuler la scène en y plaçant des objets (la liste des objets est aussi un élément personnalisable),
tandis que l'explorateur de ressources permet de naviguer à travers les fichiers du projet et de les
organiser. Enfin, l'inspecteur permet d'avoir le détail des objets de la scène et des fichiers du projet ;
dans le cas des objets, cela permet de modifier leurs propriétés (nom, position, composants...) ; dans
le cas des fichiers, cela donne soit un simple aperçu (fichiers sources), soit un autre éditeur de
propriétés (dans le cas des textures par exemple).
Un aspect important de l'éditeur de scène est qu'il reste fonctionnel même durant l'exécution du
projet, ce qui permet de manuellement modifier les positions des objets même quand il sont en
mouvement. Les modifications ne sont pas maintenues après l'arrêt de l'exécution, ce qui permet
d'annuler une action problématique par exemple.
IV. A. 2. Environnement de codage : MonoDevelop
Vue générale de MonoDevelop, avec la zone d'édition et débogueur actif.
MonoDevelop est une implémentation open source du framework .NET, et cherche à fournir des
fonctionnalités similaires. A priori donc, un projet .NET créé sur VisualStudio (de Microsoft) serait
compatible avec MonoDevelop, et inversement.
15
L'éditeur a l'avantage de fournir un système d’auto-complétion, ce qui est relativement utile pour
trouver le nom d'une fonction, ou pour savoir combien de paramètres cette fonction prend, et quels
sont leurs types. C'est tout particulièrement pratique pour l'apprentissage de l'écriture de scripts pour
les applications Unity, car il n'est pas nécessaire de connaître les fonctions à l'avance : la découverte
peut se faire progressivement.
MonoDevelop intègre un compilateur, mais ce dernier n'est pas directement utilisé, car c'est
l'environnement Unity qui s'occupe de ce processus. La compilation aurait de toute façon de
grandes chances d'échouer, puisque les scripts créés dans le cadre du projet ne comportent pas de
point d'entrée (classe Main), celui-ci étant géré par Unity, une fois encore.
Ce qui nous intéresse surtout avec MonoDevelop, c'est le débogueur, les points d'arrêts, et les
contrôles d'exécution. Ces outils sont tout particulièrement utiles pour la détection et la résolution
de problèmes dans le code : un point d'arrêt, associé à une ligne de code, permet de mettre
l'exécution en pause quand il est atteint. Le simple fait d'atteindre ce point d'arrêt ou non est déjà
une manière de savoir si l'exécution se passe correctement, mais le débogueur est bien plus efficace
pour la collecte d'informations.
En effet, quand l'application est en mise en pause par un point d'arrêt (ou les contrôles d'exécution),
le débogueur et son explorateur de mémoire deviennent accessibles. L'explorateur de mémoire est
très puissant, car il permet non seulement de voir l'état des variables du programme (dans le
contexte du bloc de code exécuté), mais aussi de les modifier. Combinés avec les contrôles
d'exécution, il devient possible de détecter et corriger manuellement un résultat incorrect, et de
poursuivre l'exécution avec cette nouvelle valeur. Très utile pour les tests et la résolution de
problèmes.
16
IV. B. Outils d'aide au développement
Le développement n'a pas pu se faire sans un minimum d'organisation. Certains outils ont aidé dans
ce sens là.
IV. B. 1. SVN
Même dans un projet en autonomie, il est important d'avoir un système dit de « versionnage », c'està-dire quelque chose permettant de prendre un « instantané » de l'avancement du projet, et de
l'archiver, ou tout du moins d'enregistrer toutes les modifications du projet depuis le dernier
archivage. L'intérêt ici est que cela permet de revenir en arrière, partiellement ou en totalité, en cas
de problème (régression ou corruption des fichiers par exemple), ce qui peut s'avérer fréquent
durant le développement logiciel. Cela permet donc de faciliter cette opération qui serait autrement
lourde voire hasardeuse.
Il existe plusieurs applications de versionnage, l'une des plus connues étant SVN, ou « Apache
Subversion », évidemment maintenu par Apache. C'est cette application qui a été utilisée pour le
versionnage du projet.
SVN est pensé pour être utilisé avec un serveur, pour le partager avec une équipe de développeurs,
mais il est tout à fait possible de s'en servir localement s'il s'agit d'un projet réalisé seul. C'est
justement dans la deuxième situation que je me trouve pour BioDyn3D.
IV. B. 2. doxygen et Trac
Documenter le processus de développement représente une tâche importante pour la vie de
l'application, puisque je devrai rendre le code en l'état à la fin de mon stage. Il est donc nécessaire
de faire en sorte que la personne qui reprendra le développement (vraisemblablement M. BALLET)
soit en mesure d'y arriver dans les meilleures conditions possibles.
On peut donc se permettre d'avoir deux types de documentation : une pour le code, et une pour le
reste.
La documentation du code passe bien sûr par l'insertion de commentaires ainsi que l'utilisation de
bons noms de classes et de variables, afin d'avoir la meilleure lisibilité possible. Ceci dit, cela ne
permet pas d'avoir une compréhension générale des classes utilisées, mais plutôt une vision locale,
propre au contexte de lecture. D'où l'intérêt d'utiliser un générateur de documentation, tel que
doxygen.
doxygen est une application conçue pour analyser les fichiers de code sources d'un programme et de
s'en servir pour générer une documentation au format HTML, qui peut donc être consultée à l'aide
d'un navigateur standard. L'analyseur est capable de reconnaître plusieurs langages de
programmation, dont le C#, qui est un des langages supportés par Unity, et celui utilisé dans le
projet.
La documentation générée fournit la liste des « packages » du projet (les groupements de fichiers
qui ont été explicités), et la liste des classes (ainsi que sous-classes). Il est possible de regarder le
17
détail d'une classe en la choisissant dans la liste, ce qui mène à sa page dédiée.
Cette page dédiée donne une vue générale des éléments publiques (public) de la classe, ainsi que le
détail des héritages de classe, si existants. Les informations « privées » (private) ou « protégées »
(protected) ne sont pas affichées, car le but est d'informer sur l'usage, et non sur le développement
de la classe. Sont donc listés les variables, les attributs (variables avec accesseurs prédéfinis), les
types locaux (énumérations ou classes), et bien sûr les méthodes (avec les paramètres à inclure),
pourvu bien sûr qu'ils portent l'attribut « public ».
L'analyseur prendra aussi en compte certains commentaires spéciaux, si leur syntaxe est la bonne, et
qui peuvent donner des informations supplémentaires (tel que la raison d'être d'une fonction
donnée) qui seront affichées dans la page de la classe ; je n'ai cependant pas utilisé cette
fonctionnalité, car elle est tend à être contraignante.
Aperçu du détail d'une classe. On peut y voir les noms,
les types de retour et les paramètres des méthodes.
Il y a donc la première forme de documentation, avec doxygen. Pour ce qui est de l'autre, nous
avons Trac, une sorte de wiki avec des outils d'aide à la gestion de projet, dont un dépôt SVN qui
n'a pas servi à ce projet (il y avait déjà l'autre en place), et une liste de « tickets » (des billets pour
faire un rapport de bug, ou pour donner une tâche à un développeur).
Trac a posé quelques problèmes pour l'installation (dépendances à Python : j'ai installé
l'interpréteur, mais sans qu'il fonctionne), d'autant que la machine utilisée tournait sur Windows 7.
Ceci a été finalement résolu en utilisant une solution « clé en main » : un installateur Bitnami.
En effet, Bitnami (https://bitnami.com/) est un projet d'utilitaires prêts-à-l'emploi dont le but est de
faciliter le déploiement d'applications libres, avec support cloud (qui est l'autre grande
fonctionnalité du projet). Cela inclut des installateurs, mais aussi des machines virtuelles pré18
configurées ; dans notre cas, on se contentera d'un simple installateur pour Trac, qui inclut aussi les
dépendances Python nécessaires pour fonctionner.
Passés ces problèmes de mise-en-œuvre, il suffit de lancer Trac via Bitnami, et on peut y accéder
sur le navigateur à l'adresse localhost:81 (j'ai dû modifier le port car cela entrait en conflit avec le
serveur WAMP installé plus tôt durant le développement).
Aperçu d'une page du wiki Trac du projet. La fenêtre a été
redimensionnée pour la capture d'image.
Cet aperçu nous montre plusieurs de fonctionnalités du wiki ; il y a évidemment le contenu de page
personnalisable (c'est le principe même d'un wiki), mais on peut aussi voir un système
d'identification (ici, je suis connecté sous le nom d'utilisateur « admin »). Les onglets suggèrent
aussi d'autres fonctionnalités : une feuille de route, un explorateur de source, et des « tickets » , ce
qui est particulièrement utile pour la gestion de projet. À noter que toutes ces fonctionnalités n'ont
pas été utilisées, et que le contenu du wiki n'est plus à jour (mi-février 2015), la plupart du travail de
remplissage ayant été fait durant les premiers mois afin de se donner une piste pour le
développement, ce sur quoi nous allons revenir.
19
V. Analyse et développement
La phase la plus importante : en effet, c'est ici que l'on commencera à avoir des résultats concrets
avec lesquels il est possible d'interagir. Les phases précédentes étaient utiles pour définir les
objectifs ; la phase de développement est celle où ils seront implémentés.
V. A. Architecture du programme
Nous avons opté pour une architecture Modèle-Vue-Contrôleur (MVC), car elle offre l'avantage de
bien dissocier le côté logique de l'application de l'aspect graphique. Ceci peut être intéressant si l'on
devait décider de ne plus utiliser Unity3D pour le rendu graphique : il suffirait de réécrire le code
gérant les commandes utilisateur et l'affichage, et rien de plus.
Les « modèles » et « contrôleurs » représentent la partie logique et fixe, qui n'a donc pas besoin
d'être modifiée en cas de transition. Les modèles sont utilisés principalement pour stocker des
informations (le nom et la couleur d'une entité, entre autres) et effectuer des calculs qui ont un
rapport direct avec ces données (ex. : « Quelle est la longueur du nom de l'entité ? »).
Les contrôleurs, quant à eux, s'occupent de gérer tous ces modèles et d'en faire la synthèse, pour
définir l'évolution de l'exécution du programme ; par exemple, déplacer les entités sur une grille
(qui a une taille donnée) en s'assurant que la position cible, qui est déterminée par un
comportement, soit bien à l'intérieur des bornes.
La « vue », partie variable, quant à elle, couvre tout ce qui est graphique (et potentiellement sonore,
malgré le nom), ce qui inclut l'interaction avec l'utilisateur : affichage d'information sur la
simulation (e.g. la grille et son contenu), réaction si un bouton est pressé (bouton marche/arrêt)…
Les capacités d'affichage et de contrôle par l'utilisateur pouvant varier selon le support de
l'application, la partie « vue » est donc susceptible d'être modifiée ; ce que l'architecture MVC
prévoit !
20
V. B. Cheminement du développement
Il aura fallu un certain temps pour se décider sur le modèle de développement principal pour ce
projet. En effet, il d'abord aura été nécessaire se familiariser avec l'environnement (Unity3D) ainsi
qu'analyser le code du prototype de BioDyn3D fourni par M. BALLET, ce qui aura pris plus d'un
mois, sur les quatre initialement prévus.
Familiarisation avec Unity3D
S'adapter à l'environnement est, naturellement, une étape indispensable au développement du
programme. L'avantage dont j'ai pu bénéficier avec Unity est tout d'abord qu'il est soutenu par une
communauté d'utilisateurs active et diversifiée, et qui est prête à venir en aide aux nouveaux
utilisateurs comme aux utilisateurs avancés. Les forums en ligne regorgent donc de questions
fréquentes dont la réponse est déjà donnée, questions qu'un utilisateur novice a beaucoup de
chances de se poser.
L'autre gros avantage d'Unity qui m'a beaucoup aidé : la documentation et les tutoriels officiels en
ligne. En effet, les créateurs de l'environnement de développement ont aussi mis à la disposition des
utilisateurs des ressources pour son apprentissage, et les vidéos de tutoriels m'ont tout
particulièrement aidé à comprendre les mécanismes du fonctionnement d'Unity.
J'ai pu profiter de toutes ces ressources pour tenter un premier programme, sans but particulier, qui
reflète les tutoriels en ligne d'Unity : un « jeu » où l'on contrôle une boule en influençant son
déplacement avec les touches du pavé directionnel. L'intérêt immédiat est certes limité, mais cette
application a tout de même permis de tester les diverses fonctionnalités d'Unity, et même de faire un
brouillon de système de communication en ligne, où les positions de la boule étaient enregistrées et
chargées depuis un serveur MySQL via un page PHP (quoique tous les deux locaux). Cela peut être
intéressant, car un système de « cloud » est prévu pour BioDyn3D, à terme.
Pendant cette première phase, Unity a bénéficié d'une mise-à-jour (en version alpha), qui ajoutait
une nouvelle fonctionnalité : l'éditeur d'interfaces graphiques. Cela nous mène à la deuxième phase
de la familiarisation : le développement d'objets graphiques supplémentaires.
En effet, l'éditeur ne fournit que des objets graphiques basiques : boutons, champs de textes, cases à
cocher, etc. ; ce qui est insuffisant pour les besoins de l'application. J'ai donc profité de cette
opportunité pour m'initier à Unity de façon plus concrète, en développant ce qui nous manquait :
une liste d'éléments sélectionnables (comme sur les pages web) et un sélecteur de fichiers figurent
parmi les différents objets que j'ai réalisés durant cette phase.
Au terme de la familiarisation, j'ai pu comprendre l'un des grands principes d'Unity : qu'il fasse
partie de l'interface 2D ou de l'environnement 3D, tout objet a une position, une rotation, et une
échelle (ce trio s'appelle une transformation), même si cet objet n'est pas visible ou n'a pas besoin
de ces informations. Cette transformation est ce qu'on appelle un composant de l'objet (et l'unique
qui soit obligatoire), et l'objet en question peut porter d'autres composants : par exemple, cela peut
être un « écouteur d'événement » qui exécute une action si l'objet a été cliqué, ou un « moteur
physique » qui va permettre à l'objet d'être soumis à la gravité et d'entrer en collision avec les autres
éléments physiques. N'importe quel composant peut être ajouté à n'importe quel objet, sauf dans
21
certains cas d'incompatibilité entre composants.
Les objets qu'Unity met à la disposition de l'utilisateur sont alors en réalité des « pré-fabriqués »,
qui sont des objets dont les composants ont été pré-configurés : par exemple, un bouton est un objet
auquel on a ajouté une image (les bordures du bouton) et un écouteur (pour les clics et les survols
du curseur) en plus de la transformation, qui est obligatoire ; un cube (objet d'environnement 3D)
est un objet avec un modèle graphique, un masque de collision et, une fois encore, une
transformation.
Il y a deux types de composants : les composants dits natifs, qui sont intégrés à Unity, et les
composants personnalisés, qui sont soit disponibles via des extensions (payantes ou gratuites) qui
ont été créées par d'autres utilisateurs, ou par l'utilisateur lui-même à l'aide de scripts. Ces scripts
eux-mêmes peuvent créer et supprimer des composants pour un objet durant l'exécution du
programme (même si ces modifications ne sont pas enregistrées après l'arrêt), et ce, qu'ils soient
natifs ou personnalisés. Comprendre cela a été capital, car c'est cette propriété qui permettra de
gérer certains composants personnalisés.
Analyse du prototype existant créé par Pascal BALLET
Parallèlement à l'apprentissage d'Unity, j'ai analysé le prototype existant, analyse qui porte sur les
fonctionnalités (voir l'analyse de l'existant) et sur l'organisation du programme, afin de déterminer si
je pourrais reprendre le développement dans son état, ou s'il faudra reprendre à zéro.
Les scripts sont groupés par thèmes, ce qui est reflété par leur préfixes : CCNX, CSIM ou CGUI.
Après avoir analysé les relations entre les fichiers (voir les annexes), CCNX semble constituer une
interface entre CSIM (gestion de la simulation) et CGUI (gestion de l'affichage). L'architecture
ressemble à une architecture N-tiers, voire MVC, mais il serait difficile de se prononcer, car
l'analyse n'est pas allée beaucoup plus loin : le code était trop peu documenté (n'étant à l'origine pas
destiné à être partagé), ce qui compliquait la tâche.
Le projet utilisait aussi un « asset » d'Unity (ou extension) : Daikon Forge, pour la gestion de
l'interface graphique. Le problème est que cet asset est payant, et la licence n'est pas transférable, ce
qui signifie que je n'avais techniquement pas le droit de l'utiliser dans le développement.
La difficulté à reprendre le code et le problème de licence ont donc lourdement influencé une
décision radicale : recommencer le développement depuis le début. Cela signifie évidemment plus
de travail (presque tout est à refaire), mais d'un autre côté, cela signifie aussi plus de flexibilité, et
moins de temps à tenter de comprendre le code existant.
Première phase de développement : éléments graphiques
Avec l'arrivée de la version 4.6 d'Unity, qui introduit un éditeur d'interfaces graphiques de façon
native (contrairement à Daikon Forge qui est une extension), et les spécifications du programme
n'étant pas totalement décidées, je me suis penché sur l'interface graphique de l'application pour
tenter de faire une maquette, qui essaiera de répliquer l'interface de NetBioDyn, car cela ne
demandait pas (ou peu) de programmation. J'ai pu alors remarquer que les éléments graphiques
fournis par Unity étaient insuffisants : il y a certes des boutons, des champs de textes ainsi que des
barres défilantes, mais il n'y a pas, par exemple, de listes déroulantes, de fenêtres de notifications
(pour confirmer une action) ou de navigateur de fichiers (utile surtout pour l'enregistrement et le
chargement de fichiers de simulation).
22
Le développement de ces composants fut donc le sujet de la première phase de développement,
durant laquelle ma maîtrise d'Unity s'est beaucoup améliorée. Au final, j'ai pu réaliser certains des
éléments graphiques qui faisaient défaut :
Jauge synchronisée : la valeur affichée à droite est mise à jour pour refléter la valeur de la jauge
(les bornes sont configurables), et inversement : modifier la valeur mettra à jour la jauge.
À gauche : liste d'éléments sélectionnables ; il est possible de la configurer pour autoriser la
sélection de plusieurs éléments. À droite, une liste déroulante, qui est en fait une liste d'éléments qui
peut être masquée.
Fenêtre de notification, variantes « OK » et « OUI/NON ». Les boutons peuvent être associés à un
événement défini par l'utilisateur, ce qui est tout surtout utile pour les fenêtres « OUI/NON »
(confirmation d'action).
Explorateur de fichiers basique ; il utilise aussi la liste d'éléments sélectionnables. Pour des
questions de simplicités, il a été limité à un seul répertoire. Il est possible de renommer et
supprimer les fichiers, avec des notifications en cas d'erreur ou de demande de confirmation.
23
En utilisant tous ces éléments graphiques, j'ai pu réaliser une maquette (principalement visuelle) de
l'interface graphique prévue. Elle pourrait encore être sujette à des changements, mais voilà déjà
une idée de ce que l'on cherche à obtenir :
Mis à part la liste de types d'entités (en haut à gauche), l'interface n'est pas dynamique, mais cela
donne quand même une vue générale de ce que l'on cherche à réaliser. Elle est inspirée du premier
prototype de BioDyn3D ainsi que de NetBioDyn (2013). Les molécules n'étant pas encore à l'ordre
du jour, elles n'ont pas été incluses à l'interface, mais elles devraient à terme occuper l'espace à
gauche, en dessous de la liste de comportements (behaviors).
Le développement des composants graphiques aura cependant pris un certain temps, et passé un
stade donné, il a fallu s'arrêter pour pouvoir se concentrer sur l'aspect logique de l'application plutôt
que l'aspect graphique. En effet, j'ai passé près de deux mois à développer ces composants, et cela a
pris beaucoup de temps pour deux raisons : la formalisation des spécifications (quelles
fonctionnalités doivent être remplies, comment s'y prendre…) et les tests unitaires. L'excès de
rigueur n'est pas forcément une bonne chose…
Deuxième phase de développement : prototypage
Comme je viens de le mentionner, j'ai tenté d'être rigoureux dans le processus de développement ;
peut-être un peu trop. L'initiative partait du désir d'avoir un projet documenté, et suffisamment bien
organisé et testé pour que le développement puisse être repris facilement après mon départ. De ce
point de vue, les résultats ont été plutôt mitigés.
24
En effet, faire trop de « contrôle qualité » a eu pour conséquence de ralentir considérablement le
développement, et donnait trop peu de résultats pour une période de presque deux mois ; c'est un
problème, car obtenir des résultats est un aspect important pour la motivation. Il a donc fallu
prendre une approche différente.
Je suis donc passé à un modèle de développement plus « libre » et moins rigoureux, mais qui
donnait des résultats plus rapidement : en effet, il aura fallu seulement deux semaines pour réaliser
un prototype certes limité, mais bel et bien fonctionnel :
(Pour un exemple de simulation, voir les annexes.)
Ce prototype est capable de plusieurs fonctionnalités demandées par le projet ; en l'occurrence :
•
créer des types d'entités et des comportements, avec validation des données (une saisie
incorrecte sera bloquante)
•
placer / supprimer des instances sur la grille ; elles sont représentées par la couleur du type
d'entité
•
redimensionner la grille (non représenté ici)
•
exécuter les demi-vies (une entité peut disparaître spontanément au bout d'un certain temps)
•
exécuter les réactions définies (création/suppression/mutation ; mais de façon limitée)
•
exécuter un pas de la simulation, ou exécuter la simulation en continu
•
et, évidemment, donner une représentation graphique de la simulation ; en plus de cela, il y a
un « délai de rafraîchissement » qui indique combien de pas il faut attendre avant de le
mettre à jour
25
Les limitations, cependant, sont les suivantes :
•
le rendu est limité à la 2D, mais le code est théoriquement compatible avec la 3D
•
les comportements sont limités à une seule réaction avec une case voisine (en plus de la
réaction locale), contre 2 dans NetBioDyn 2013 ; cette limitation est une simple mesure de
simplification pour que le prototype ne soit pas trop long à réaliser
•
il n'est pas possible de supprimer ou modifier des types d'entités ou des comportements : une
fois créés, ils restent ainsi jusqu'à la fin de l'exécution
•
l'exécution est très lente : une simulation équivalente réalisée dans NetBioDyn 2013 sera
visiblement plus rapide et fluide
•
pas d'enregistrement / chargement, le modèle de stockage n'ayant pas encore été bien défini
•
du point de vue programmation, le code est relativement peu organisé : il s'agit d'un
brouillon, ni plus ni moins, l'idée étant de s'en servir comme modèle en vue d'une réécriture
Cela étant dit, l'objectif était d'obtenir un résultat concret, sans se préoccuper des questions de
praticité. L'interface n'est pas très ergonomique et le manque de contrôle sur les entités et
comportements créés est ennuyant, mais le prototype remplit tout de même le rôle qu'on attendait de
lui, en plus d'être source de motivation.
L'autre avantage de ce prototype « brouillon » est qu'il a mieux mis en évidence les besoins du
programme que la première analyse, qui pourtant se basait sur deux modèles : NetBioDyn 2013 et
BioDyn3D (prototype de M. BALLET). En effet, coder directement (même de façon peu
rigoureuse) permet de saisir plus facilement les contraintes, car elles deviennent évidentes avec
l'apparition des besoins, là où l'analyse purement théorique a tendance à faire beaucoup
d'abstractions ou à considérer certaines choses comme (faussement) évidentes.
Le prototype a pu être amélioré par la suite en y ajoutant la 3D. Ceci dit, le système de rendu est un
peu particulier. Nous allons y revenir.
V. C. Optimisation du programme
L'objectif principal du programme est évidemment d'offrir un automate cellulaire. Mais un
programme lent n'est pas non particulièrement attrayant ; d'où l'importance de l'optimiser.
Il y a deux aspects du simulateur qui peuvent être optimisés : le rendu, et la partie logique. Les deux
sont indépendants, de la même manière que la partie Vue et la partie Modèle-Contrôleur sont biens
séparées.
À ce jour, je n'ai implémenté d'optimisation que pour le système de rendu. Tout d'abord, il faut
savoir que les entités occupent une seule case de la grille 3D par instance, et que la grille ne peut
pas contenir plus d'une instance d'entité par case ; par conséquent, on peut représenter une entité
avec un objet cube.
Ceci étant, cela peut poser des problèmes ; en effet, pour une grille de taille 10x10x10, il peut donc
y avoir jusqu'à 1 000 entités simultanément, et donc autant de cubes qu'il faut gérer.
Mais les choses ne s'arrêtent pas ici. Comme il s'agit d'Unity, tout objet a donc des propriétés, dont
26
sa transformation et sa couleur, ce qui représente environ 13 flottants (9 pour la transformation, 4
pour la couleur avec canal alpha), soit un total de 13 000 valeurs à stocker en mémoire pour cette
taille de grille. Il paraît donc évident qu'il faut trouver une solution à cela.
Une solution consistait donc à réduire le nombre d'objets, sans pour autant réduire l'information
dont on bénéficiait. Pour y arriver, j'ai eu l'idée de fusionner les faces des cubes se trouvant sur le
même plan et pointant dans la même direction : les entités ne sont plus représentées par des cubes,
mais par six surfaces avec textures dynamiques avec une résolution d'un pixel par case, avec un
pixel de couleur pour une case occupée, et un pixel transparent pour une case vide.
L'avantage que cela donne est que cela réduit considérablement le nombre d'objets. Pour une grille
de taille 10x10x10, il faut compter 2*(10+10+10) = 60 objets, soit prêt de 17 fois moins ! L'autre
avantage est que le nombre d'objets augmente de façon linéaire, alors qu'il augmente de façon
exponentielle pour l'autre modèle.
Après quelques tests, j'ai pu réaliser un script qui s'occupe de ce système d'affichage. Voilà le
résultat pour une petite grille de taille 5x5x5 avec contenu aléatoire :
Afin d'illustrer le système de surfaces, j'en ai sélectionné une et je l'ai décalée légèrement pour
montrer qu'il n'y a pas de véritables cubes, seulement des surfaces dont la texture représente le
contenu de la grille. La texture de la surface sélectionnée est la suivante :
Il faut tourner l'image de 90° à gauche à cause de l'orientation, mais autrement, il s'agit bien de la
même texture.
Cependant, ceci n'est qu'un petit exemple, qui ne demande pas beaucoup de ressources. Voici donc
pour une grille de taille 20x20x20 :
27
Bien que cela ne soit pas visible sur cette image, le rendu était d'une vitesse relativement
acceptable, en dépit des environ 4 000 cubes (grille remplie à 50 %) qui sont représentés ici,
puisqu'il n'y a en réalité que 2*(20+20+20) = 120 objets, soit 33 fois moins qu'avec des cubes
individuels.
Le système étant fonctionnel, j'ai pu mettre à jour le prototype de simulateur, qui peut maintenant
donner un rendu 3D de la grille (même si l'interface ne permet de dessiner que sur une seule couche
pour le moment) :
Un constat intéressant a pu être fait à propos du système de rendu : de façon contre-intuitive, plus la
grille est vide, plus elle ralentit le programme. Ceci est dû aux nombreux pixels transparents des
28
textures de surfaces : le système de rendu doit calculer quelle sera la couleur du pixel de l'écran ;
mais pour cela, il doit tester les différents objets de la scène, jusqu'à trouver un pixel non
transparent ; hors, dans le cas d'une grille vide, il devra tester une surface, puis celle se trouvant
derrière, et ainsi de suite jusqu'à atteindre la limite de rendu. C'est cela qui provoque les
ralentissements.
Le système n'est donc pas forcément adapté à toutes les situations : il est possible qu'un système
hybride, utilisant des cubes et des surfaces, voie le jour : système cube quand il y a peu d'entités ;
système surface quand la grille devient dense. Mais il s'agit là d'une piste future que nous
n'explorerons pas tout de suite.
Du point de vue optimisation de la partie logique, rien n'a encore été fait ; j'ai cependant quelques
idées qui vont dans ce sens.
Chaque entité peut avoir jusqu'à 6 voisins (nord, sud, est, ouest, au dessus, en dessous) ; cela
correspond donc à 6 tests pour chaque entité ayant un comportement associé. Est-il envisageable de
se contenter de ne tester qu'une seule des 6 directions aléatoirement, et obtenir une évolution
similaire de la simulation ? Cela demanderait de faire une étude statistique, mais aussi de
déterminer quel serait le modèle témoin, et s'il est significatif.
Par exemple, une entité qui se propage dans une case voisine, pourvu qu'elle soit vide. La
simulation pourrait donner des résultats statistiquement différents si on ne testait qu'un seul voisin
(choisi au hasard) plutôt que tous les 6 : si l'entité a une case d'occupée adjacente, alors il y a 1/6
chance que l'opération échoue, là où elle aurait réussi dans tous les cas si tous les voisins étaient
testés. Cela devient encore plus sévère quand il y a davantage de voisins : 2/6, 3/6, 4/6 et 5/6
chances d'échouer.
Toute la difficulté ici sera donc de trouver un système d'optimisation, et si l'on souhaite de la
précision, ou de la performance ; c'est l'une des choses sur lesquelles que je tenterai de travailler
durant le reste du stage.
29
Conclusion
À ce jour, le projet n'est pas encore terminé. Parmi le travail réalisé, ce qui s'approche le plus de
l'objectif est le prototype de simulateur. Bien qu'il soit limité, il a permis de mettre en évidence
quelques uns des défis futurs pour le simulateur : notamment la vitesse d'exécution lente quand il y
a beaucoup d'entités, mais aussi la vitesse de rendu ; ces questions de performances nécessitent une
bonne optimisation de l'application, même si le but était d'abord d'avoir un simulateur fonctionnel,
peu importe les performances.
Il reste encore beaucoup de choses à implémenter, parmi les nouveautés, telles que les molécules ou
le système de cloud, mais aussi parmi les spécifications de base, comme la gestion des
comportements de façon optimisée. En effet, l'optimisation est l'autre aspect crucial : même si c'est
pour des fins d'expérimentation, il est toujours préférable d'avoir un programme rapide.
L'objectif pour la fin du stage (le 17 avril 2015) est d'au moins atteindre une version fonctionnelle et
« propre » (par opposition aux prototypes), qui soit documentée et donc maintenable, car BioDyn3D
continuera d'exister et d'être maintenu après mon départ.
Au final, le stage m'aura appris qu'essayer d'être trop rigoureux peut avoir des conséquences
néfastes pour le projet, et qu'il peut être acceptable de fonctionner de manière plus informelle si
cela permet de mieux cerner le problème et d'avancer quand on est bloqué.
En effet, se détacher des contraintes habituelles est une façon de regarder le problème sous un autre
angle. Ceci est important, notamment dans le cadre d'un projet en autonomie, car on aura surtout
tendance à n'avoir qu'un seul point de vue, et donc à s'enfermer dans un raisonnement qui n'est peutêtre pas le bon.
Pour autant, moins de formalisation ne signifie pas pour autant se relâcher : il est acceptable d'avoir
des prototypes qui soient « mal » codés, pourvu que les livrables soient réalisé convenablement. Et
c'est cette approche que je prendrai plus souvent à l'avenir.
Remerciements
J'aimerais remercier les personnes suivantes :
Pascal BALLET, maître de stage, qui a répondu à mes questions et m'a aidé à résoudre un certain
nombre de problèmes (qu'ils soient administratifs ou en rapport avec le projet) ; mais aussi et
surtout pour m'avoir proposé de réaliser mon stage au sein du département informatique.
Goulven GUILLOU, responsable de stage, qui a aussi répondu à mes interrogations, en rapport
avec le stage.
Les membres du Lab-STICC (Abdoulaye SARR, Alexandra FRONVILLE, Anne JEANNINGIRARDON entre autres), avec lesquels j'ai passé mon stage.
30
Outils et références
•
Site officiel d'Unity3D (http://unity3d.com/)
•
Tutoriels d'Unity et documentation (http://unity3d.com/learn)
•
Ancien site de NetBioDyn (http://netbiodyn.tuxfamily.org/)
•
Virtulab, où se trouvent des versions plus récente de NetBioDyn (http://virtulab.univbrest.fr/)
•
Trac (wiki et bug tracker) (http://trac.edgewall.org/)
•
Apache Subversion (SVN) (https://subversion.apache.org/)
•
Bitnami (https://bitnami.com/)
•
Dia (éditeur de diagrammes libre) (https://wiki.gnome.org/Apps/Dia/)
31
Annexes
Ces annexes regroupent des informations et illustrations supplémentaires en rapport avec le projet.
Captures d'écran de l'existant
Ces images complètent l'analyse de l'existant ; elles couvrent les thèmes qui ont été abordés sans
être illustrés.
NetBioDyn 2008
Éditeur de réaction ; ici, il s'agit d'une réaction « située en absolue ». Les carrés noirs avec points
rouges indiquent les positions voisines (sauf le point central) qui seront affectées.
32
Autre éditeur de réaction : il s'agit ici d'une réaction de type « complexe ». Elle offre beaucoup plus
d'options de configuration, comme « A est en contact avec B » (où A et B sont des types d'entités)
qui est un test, ou « A sera supprimé », qui est une action. Compte tenu de la complexité de la
fonctionnalité, la capture d'écran ne fait qu'effleurer les possibilités.
Éditeur de liens ; ils agissent comme des contraintes de distance entre des instances d'entités. Il est
possible de configurer un lien pour qu'il soit « imperméable », interdisant les entités de le traverser.
33
NetBioDyn 2013
Éditeur d'entité. Contrairement à NBD 2008, la version 2013 a simplifié les entités à l'extrême, leur
seule « charge utile » étant la demi-vie.
Éditeur de comportement. Même constat : l'interface a beaucoup été simplifiée.
34
Premier prototype de BioDyn3D
Éditeurs d'entités ; l'image a été agrandie pour des questions de lisibilité. Contrairement à NBD
2013, les entités n'ont plus de demi-vies ; à la place, il y a des informations de production et de
consommation de molécules. Dans cet exemple, les molécules sont pré-définies, mais il était prévu
que la liste des éléments (sous « Prod / Consum ») serait dynamique.
Éditeur de molécule. On constate les fonctionnalités prévues, telles que la diffusion, la quantité
initiale, ainsi que la variation de cette quantité au fil du temps.
35
Relations des fichiers du premier prototype de BioDyn3D
Les images qui suivent sont le résultat d'une analyse du code du premier prototype qui a été créé par
M. BALLET. Les « relations » sont définies simplement : dès qu'une autre classe est mentionnée,
on considère cela une relation. Cela permet quand même de se donner une idée de l'architecture.
36
37
38
Exemple de simulation
Le prototype réalisé est capable d'exécuter des simulations. Voici un exemple avec pour
paramétrage :
•
entités rouges :
◦ peuvent spontanément disparaître (à cause de leur demi-vie)
◦ se propagent dans les cases vides adjacentes (100 % de chance quand la condition est
remplie)
•
entités bleues :
◦ immobiles
◦ si une entité bleue est adjacente à une autre entité bleue, la voisine sera détruite (100 %
de chance quand la condition est remplie)
Cela donne :
Pas 0 (départ)
Pas 4
Pas 2
Pas 6
Les rouges commencent à
se propager.
Pas 8
Pas 10
Pas 15
Les rouges continuent de se
propager.
39
Pas 20
Les bleus n'évoluent plus ;
des rouges disparaissent
occasionnellement, mais ils
sont vite remplacés.