Data Flow Generator - Historique
|
Je tiens à apporter des éclaircissements du discours donné à Samuel et Olivier vendredi dernier, car j'ai l'impression que je les ai un peu choqué. Je me rend compte que tout le monde n'est pas forcément au courant de ce qu'est Data Flow Generator qui est intimement lié au langage pivot. Il a été déjà présenté à I2A et je remercie Pierre pour cela, c'est la seule fois où l'on m'a permis d'en parler devant le groupe. Aussi vous y verrez quelques alertes disséminé ici et là.
D'abord il faut distinguer le langage pivot(↬langage pivot), le moteur de simulation par évènement discret(↬Une simulation à événements discrets) et les outils de génération de codes que j'ai nommé Data Flow Generator noté DFG dont la version est 0.X.X (http://dfg.bht.fr/). Je le développe depuis des années. Aujourd'hui je le présente sous le nom de Discrete Event Simulator Generator - noté DisEvtSimGen ou DFG1 dont version est 1.X.X - car je lui ai adjoint le moteur de simulation par évènement discret,
On peut lui adjoindre une infinité de moteurs en réalité, notamment mon futur simulateur de combat aérien, histoire de se faire plaisir sur le plan technique.
Ces générateurs de code (DFG) n'appartiennent pas à EDF, je pense même qu'ils sont interdits d'existence en son sein. En effet j'ai au moins 3 fois proposé de faire leur développement au sein d'EDF, dans le cadre des 5% d’innovation par exemple, ou dans un projet, mais j'ai eu à chaque fois un refus non expliqué.
Depuis je ne propose plus rien, d'autant plus que le projet FAROS(http://www2.lifl.fr/faros/) a été arrêté pour la partie EDF, un projet dont l'objectif était de fournir justement un langage pivot.
Notre langage pivot va peut être sauver ForCity (je l'ai cru entendre un jour, j'ai dû rêvé) ! Mais soyons modeste et surtout miséreux; le projet ForCity va être une réussite et j'en suis sûr grâce à COSMO.
Je serai même content si on ne parle plus de langage pivot dans ce projet car sinon j'ai l'impression que je vais avoir des problèmes. J'ai accepté cet exercice en me servant de mes outils pour aller très vite, parce que David me l'a demandé et David est quelqu'un de bien ou du moins jusqu'à présent.
En tout cas ce n'est pas moi qui irai le crier sur le toit pour l'utiliser dans tout projet quel qu’il soit.
La spécification du langage pivot sous forme d'un document (note H SINETICS) sera fourni au projet, c'est le travail prioritaire qui m'a été demandé depuis mi-juillet par David.
Une version plus short incluant les API du moteur, maintenant qu'il est stabilisé, sera fournie le 10 octobre 2012.
Pour concevoir le moteur j'ai été grandement aidé par Olivier, le grand gourou du domaine, en échangeant beaucoup sur Sim-Diasca depuis octobre 2011 (http://innovation.edf.com/recherche-et-communaute-scientifique/logiciels/sim-diasca-80703.html). Aussi les échanges avec Jingxuan et Samuel ont permis de compléter les réflexions. Des réflexions qui ont même conduit à une évolution de Sim-Diasca (exemple : le temps fuji).
Les sources du moteur de simulation par évènement discret sera forcément fourni au projet !
On peut difficilement dissocier le moteur du langage pivot qui forcément utilise son API. Et de plus et c'est le plus important, le langage doit fournir l'API requis du moteur. Sinon on revient au cas des langages généraux tels que c++ auxquels on associerait un digramme de classes et c'est le cas de COSMO avec des inconvénients en plus.
Dailleurs je ne comprends pas comment COSMO peut prétendre définir un langage de simulation des systèmes complexes (de même nature qu'un langage pivot) sans fournir au moins un exemple de moteur de simulation (ce que nous appelons dans le projet scheduler). De plus c'est nous qui devons spécifier ce moteur en sachant beaucoup moins que les experts de COSMO (on n'est même pas encore formé). Je souhaite bien du courage à Samuel. Pour le rédiger il faut d'abord parfaitement maitriser leur langage de conception COSMO et surtout leurs paradigmes de programmation sinon on va aller vers de gros problèmes plus tard.
Le risque de non applicabilité à l'existant sera très grand, sauf si l'on veut tout refaire.
Souvent quand on parle de simulateur on parle de moteur de simulation. Et ce qui fait sa valeur c'est surtout son moteur. Achèteriez vous une voiture sans moteur ?
DFG n'est pas open source ni même gratuit, par contre les sources générées par DFG le sont sous la licence http://www.mozilla.org/MPL. Même si j'avais la volonté de le rendre open source, il ne serait pas présentable de toute façon; pas le temps chez moi d'appliquer des règles d'assurance qualité quand il s'agit de développer dans l'urgence, dans un temps limité et ponctuellement au fil de bon nombre d'années. Par contre une interface web permet gratuitement de générer des sources, autant qu'il le faut ; voir http://dfg.bht.fr et celui du pivot avec le moteur sur http://dfg1.bht.fr, en bonus sur http://at.bht.fr/ vous trouverez mes dessins et photos.
Voici (documentation non mise à jour par rapport à la version actuelle, elle le sera peut être pendant mes futures vacances ou RTT) :
- Manuel d'utilisation de DFG http://wiki.bht.fr/index.php/Manuel_d%27utilisation_de_Data_Flow_Generator ;
- Manuel de référence de la grammaire de DFG http://wiki.bht.fr/index.php/Manuel_de_r%C3%A9f%C3%A9rence_de_la_grammaire_de_Data_Flow_Generator ;
- Manuel de référence des fichiers au format XML utilisés par les drivers générés par DFG http://wiki.bht.fr/index.php/Manuel_de_r%C3%A9f%C3%A9rence_des_fichiers_au_format_XML_utilis%C3%A9s_par_les_drivers_g%C3%A9n%C3%A9r%C3%A9s_par_Data_Flow_Generator .
N'oublions pas que DFG génère aussi du C++ utilisant XERCES pour parser le XML (voir la possibilité de génération en ligne sur http://dfg.bht.fr). XERCES m'a été imposé dans le projet PARAD, proposition de Stéphane PLOIX, pour lequel il n'était pas le plus compétent d'après moi et ils n'ont pas pensé me consulter ou même consulter I2A. Par contre moi, j'ai même consulté les experts C++ de I2A, l'un d'entre eux avait déjà testé XERECES et il me l'avait fortement déconseillé. Et pour cause l'API XERCES ne faisait pas appel à c++ mais du c version pointeur de chaine de caractère 16 bits, à la mode des années 80! Or j'ai rejoint ce projet dans l'urgence et il fallait fournir rapidement les pilotes; j'aime ce genre de défit dans lequel j'ai toutes les excuses pour moi.
Et c'est pour éviter d'utiliser l'API XERCES directement que j'ai pensé utiliser mes outils de génération de code pour générer son wrapping (une couche d'encapsulation c++, à l'époque mes outils étaient dans un état primaire, aujourd'hui je ne suis pas loin de finir mon parseur/compilateur universel …)).
Il faut dire que j'avais une première expérience dans le projet PERFECT. Contraint par des conditions similaires, en 2005, j'ai écrit un générateur d'intégration de solveurs, que j'ai appelé PERFECT_Maker, dans le projet SALOME ; voir http://www.irisa.fr/orap/Forums/Forum18/programme.html le pdf http://www.irisa.fr/orap/Forums/Forum18/Expo_Torossian_EDF.pdf.
Je remercie Jean-Yves BERTHOU pour m'avoir demandé de faire cette présentation.
Une approche et des idées qui se retrouvent plus tard dans YACS de SALOME développé par André (SINETICS-I2A) (http://www.salome-platform.org/about/yacs) et le Wrappeur de OpenTurn développé par Ivan (SINETICS-I2A) (http://doc.openturns.org/openturns-latest/html/WrapperGuide/cid3.xhtml).
Quelques mois après, la société de sous traitement du projet PARAD a adopté DFG pour produire les sources des classes et leur structure c++ de la partie métier de la radio protection. Je remercie ce projet pour m'avoir forcé à donner naissance à DFG. Merci, merci, merci, …
Pourquoi faire ce petit REX historique ? En fait, l'agent EDF qui j'étais, était devenu le sous-traitant de notre sous traitant pour ce travail. Et le constat le plus grave est que ce sous traitant faisait plus confiance à moi que les responsables du projet et je pourrai même dire qu'en général on fait plus confiance à un sous traitant qu'à un agent EDF, la non prise en compte de notre note sur notre position sur COSMO en est un très bon exemple !? Dans le cadre du projet ForCity j'ai l'impression que nous vivons la même histoire mais à la puisse 10. Pour pouvoir développer et maintenir du code dans COSMO dans des temps acceptables, j'ai dit dès le début que je génèrerai le code COSMO (le code généré par DFG est fait pour être maintenu manuellement aussi, ainsi on ne peut faire la différence entre un code écrit manuellement). L'idée du langage pivot est venu à ce moment. Et depuis Olivier a fortement diffusé cette idée je ne sais pour quelle raison.
Sans l'existence préalable de DFG, le langage pivot ne pouvait pas être mis au point en quelques mois, il n'est qu'une copie du méta modèle (avec un renommage des tags plus règlementaire) de DFG. Par contre le temps passé a permis de mettre rapidement au point le le moteur de simulation par évènement discret. Je défis quiconque, sous traitant ou pas, de fournir l'équivalent en si peu de temps. Nous pouvons donc remercier TheArthurCompany pour avoir offert le langage pivot au projet ForCity ainsi que bon nombre de lignes de code généré gratuitement pour le projet PARAD et son sous traitant. Et je fournirai l'exemple du distributeur de soda en ne chiffrant pas le temps qu'il faut pour le réaliser; je vous laisserai la bonne surprise quand vous aurez vu son modèle. Le simulateur simplifié des transports aérien sera fourni à titre d'exemple sur http://dfg1.bht.fr
Le langage pivot est un langage permettant d'écrire un programme en le projetant vers un langage cible tel que le c++, en partant de modèles de conception faisant appel par exemple au langage UML. Dans notre cas le programme est à priori un programme de simulation des villes de type simulation de systèmes complexes contraint par le choix de COSMO.
Une simulation à événements discrets est une modélisation informatique où l'état d'un système est représenté par une séquence chronologique d'événements discrets. Chaque événement arrive à un instant donné et modifie l'état du système (source http://fr.wikipedia.org/wiki/Simulation_%C3%A0_%C3%A9v%C3%A9nements_discrets).
