Code source du démonstrateur

Introduction

Beaucoup de moyens informatiques ont été investis dans la mise en œuvre du démonstrateur qui n’est pas simplement un site Web. Il est vecteur d’un savoir-faire et propose un panel d’outils donnant un accès, que nous espérons le plus direct possible, aux résultats les plus récents dans les différents thèmes scientifiques abordés par la plateforme EDStar.

S’ajoute à cela tout l’aspect didactique que permet le démonstrateur, mais qui n’est qu’à ses balbutiements et qui n’a donc pas encore influencer massivement sa mise en œuvre.

Position scientifique et choix techniques

Dès le début de la conception, une attention particulière a été porté sur le fait de rendre le démonstrateur accessible au plus grand nombre et facile d’utilisation. De plus, le démonstrateur devait être la passerelle vers la plateforme EDStar, en plus d’être un instrument scientifique. Concrètement, techniquement, cela a imposé plusieurs décisions fortes :

  • Utilisation d’un site web pour le démonstrateur. D’autres formats étaient possibles, mais un site web est accessible à partir de nombreux supports (ordinateur, smartphone, tablette, télévision, etc.) d’à peu près n’importe où, même s’il n’est pas exempt de contraintes.
  • Utilisation des standards du web, à savoir le HTML5/CSS3 et le JavaScript, pour être le plus compatible possible avec les différents navigateurs. S’est ajouté en cours de route le WebAssembly, qui est bien parti pour devenir un nouveau standard, et qui permet l’accès à des performances difficiles à atteindre avec du pur JavaScript. Si elle s’installe réellement sur la durée, cette technologie permettrait aussi d’utiliser une partie du Star-Engine directement dans le démonstrateur au lieu de faire des mises en œuvres spécifiques.
  • Se limiter à 2 dimensions pour les outils de démonstration. Même si les méthodes mises en œuvres sont utilisables en 3D, il est très difficile de rendre simple d’utilisation des outils où il faut naviguer dans une scène géométrique, et ce d’autant plus que cela doit se faire dans un navigateur et possiblement sur un écran tactile.

Ce sont ajoutés d’autres choix techniques, plus arbitraires mais réfléchis et cohérents avec l’approche de la plateforme EDStar :

  • Pas de serveur de calcul : tout est fait sur la machine de l’utilisateur. Ainsi, nous pouvons limiter le temps de maintenance du démonstrateur et faire, par la même occasion, la démonstration de l’efficacité des méthodes.
  • Ouvrir le démonstrateur à d’autres thématiques que la thermique, le sujet initial qui a amené à la création du démonstrateur. Cela implique de ne pas cloisonner les développements informatiques à du spécifique thermique.
  • Pas de concurrence à des outils professionnels. Le démonstrateur n’est pas une solution logicielle mais un instrument scientifique qui apporte sur certains thèmes, des ressources pédagogiques numériques pour mieux comprendre ce que propose la plateforme EDStar.
  • Cohérence entre la mise en œuvre des solveurs dans le démonstrateur et la mise en œuvre dans le Star-Engine . L’objectif étant de permettre une transition douce entre les deux.
  • Rendre le code source du démonstrateur ouvert. C’est un matériel scientifique, il se doit donc d’être accessible dans son entièreté, garantissant ainsi la transparence et la cohérence avec le discours qui l’accompagne. De plus, ce code source peut être exploité comme une première approche à la prise en main et l’apprentissage des algorithmes et méthodes.

Plusieurs conséquences techniques directes découlent de ces choix :

  • La performance n’est pas une priorité. Le calcul se faisant sur l’appareil de l’utilisateur, nous dépendons de la puissance disponible.
  • Faire attention à la compatibilité. En effet, même si nous utilisons des standards, leur mise en œuvre différent d’un navigateur à l’autre, et certaines parties des standards ne sont pas forcément disponibles. Mais le choix le plus contraignant pour la compatibilité fut celui du WebAssembly dans la mesure où cette technologie est relativement récente (juin 2015, date de la première annonce publique). À l’heure où ces lignes sont écrites, cette technologie semble disponible pour environ 85% des utilisateurs de téléphones ou ordinateurs (source ), ce qui reste tout à fait raisonnable.

Modules du démonstrateur

La mise en œuvre des outils de démonstration a nécessité le développement de plusieurs modules. Nous pouvons les séparer en 3 groupes.

Les bibliothèques de base, génériques :

  • sdm_geometry [C99, WebAssembly] : permet de créer, gèrer et interroger des scènes géométriques ;
  • sdm_maths [JavaScript] : fourni des outils mathématiques nécessaires aux solveurs notamment ;
  • sdm_units [JavaScript] : fourni les unités internationales et des outils de conversion ;
  • sdm_graphics [JavaScript] : fourni une API pour l’affichage de primitives graphiques. Deux mises en œuvres sont proposées : une en WebGL pour l’affichage dans le navigateur avec les meilleures performances possibles, l’autre en SVG pour l’extraction d’image pour la génération de documents ;
  • sdm_solver [JavaScript] : outils et fonctionnalités de solveur génériques ;
  • sdm_learning [JavaScript] : mise de côté pour le moment, aura pour but de proposer des outils et fonctionnalités pour mettre en place des modes d’apprentissage interactifs.

Les bibliothèques dédiées, spécifiques :

  • sdm_editor_scene [JavaScript] : fourni des outils et fonctionnalités pour la création de scènes géométriques. Aujourd’hui, fourni également les briques de base d’un éditeur graphique de scènes géométriques ;
  • sdm_solver_pisp [JavaScript] : le solveur pour le calcul de la constante $\pi S/P$ ;
  • sdm_solver_therm [JavaScript] : le solveur pour le calcul thermique.

Les éditeurs dédiées :

  • sdm_pisp_editor [JavaScript] : éditeur graphique pour la création de scènes géométriques. Ces scènes sont compatibles avec le solveur de calcul de la constante $\pi S/P$ qu’il est aussi possible d’appeler, et dont on peut visualiser le résultat ;
  • sdm_therm_editor [JavaScript] : éditeur graphique pour la création de scènes géométriques et la configuration des paramètres physiques. Ces scènes sont compatibles avec le solveur thermique qu’il est aussi possible d’appeler, et dont on peut visualiser le résultat.

La figure 1 propose aussi de visualiser les dépendances entre ces modules.

Figure 1 - Schéma actuel des dépendances entre les bibliothèques

Modèle de conception MVC (Modèle-Vue-Contrôleur)

Étant données les technologies Web, le modèle MVC paraît le plus simple et le plus efficace à mettre en place. Voici de manière informelle ce que représentent chacune des composantes du MVC:

  • Modèle :
    • Les modules JavaScript des solveurs avec leurs dépendances ;
  • Vue :
    • Tout le code HTML/CSS, avec les quelques codes JavaScript servant à scripter les éléments de l’interface ;
  • Contrôleur :
    • Tout le code JavaScript, mais servant à brancher et piloter le passage du modèle à la vue, et vice-versa ;
    • Les modules des éditeurs dédiées.

Technologies utilisées

Il y a habituellement deux groupes dans lesquels les technologies peuvent appartenir : celles utilisées dans la chaîne de production et celles embarquées dans l’application puisque nécessaire à son fonctionnement.

Voici la liste des bibliothèques et outils utilisés dans la chaîne de production :

  • Babel (licence MIT) : compilation JavaScript vers JavaScript ;
  • Chai (licence MIT) : assertions haut niveau en JavaScript ;
  • Dotenv (licence BSD-2-Clause) : outil de configuration par variables d’environnement en JavaScript ;
  • Mocha (licence MIT) : framework de tests JavaScript ;
  • Node.js (licence spécifique) : utilisé comme interpréteur de JavaScript en ligne de commande ;
  • Emscripten (licence MIT) : utilisé comme outil permettant de compiler du code C/C++ vers du WebAssembly ;
  • Hugo (licence Apache 2.0) : générateur de site Web statique ;
  • Git (licence GPLv2) : système de gestion de version ;
  • Pandoc (licence GPLv2) : pour transformer des bibtex en JSON.

Voici la liste des bibliothèques utilisées par le démonstrateur :

  • Babel (licence MIT) : compilation JavaScript vers JavaScript ;
  • Chart.js (licence MIT) : affichage de graphe en JavaScript ;
  • Pixi.js (licence MIT) : affichage WebGL dans le navigateur ;
  • MathJax (licence Apache 2.0) : affichage de mathématiques dans le navigateur, en partant de maths LaTeX ;
  • require.js (licence MIT) : mise en œuvre de l’«Asynchronous Module API» ;
  • Svg.js (licence MIT) : dessin vectoriel au format SVG ;
  • w3.css (libre, aucune licence) : framework CSS pur, simple et efficace, qui gère nativement tout les types d’appareils.

Accès

Veuillez vous référer à la documentation de installation de l’environnement de développement du démonstrateur.