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.