Différences entre les versions de « Manuel d'utilisation de Data Flow Generator V0 »
De Wikip
toross>WikiAdmin |
m (1 version importée : dfg) |
(Aucune différence)
| |
Version actuelle datée du 24 juillet 2026 à 19:08
|
Fig. n°1: Data Flow Generator V1
1 Introduction
L'informatique met à notre disposition des outils nous permettant d'éviter des tâches répétitives et ennuyeuses. Souvent, on devient informaticien car on veut éviter tout travail répétitif. Le développeur, déjà un informaticien, lui aussi veut éviter la programmation répétitive. Data Flow Generator est un outil parmi d'autres, que tout développeur finit par écrire car il est aussi un informaticien.
1.1 Une méthodologie plus qu'un outil
Ces outils, tels que Data Flow Generator, qui aident à se passer du travail répétitif, finissent par s'intégrer dans une méthodologie de développement. En général un développeur commence à écrire son code avant même d'avoir réfléchi aux données que le programme va utiliser, à la structure des données, et pourquoi pas à la structure du programme même, qui lui aussi peut être pensé comme
une entité qui s'articulerait autour d'une architecture.
La réflexion fut longue et axée principalement sur trois branches : la spécialisation des logiciels (bases de données, middle-wares, etc.) et la spécialisation des outils de développement (langages, modélisation, etc.) et la thésaurisation de l'expérience.
1.1.1 Les données et les programmes
Au fil des années, des logiciels se sont spécialisés dans le stockage et l'accès aux données (bases de données) ou dans le traitement de ces données, qui sont souvent des logiciels spécifiques à des besoins particuliers ou alors ces programmes sont mis dans des libraires quand ils sont réutilisables. Le langage SQL a été mis au point interroger ces bases de données, c'est un langage qui permet d'éviter de se préoccuper des problèmes que gèrent les base de données.
1.1.2 Les langages de programmation et la modélisation
En même temps, des langages de programmation se sont crées pour faciliter le travail du programmeur tout en évitant les taches répétitives. Chaque langage a ses qualités et ses défauts, nous dirons que chacun est optimal pour un ensemble de besoins donnés et chaque langage continue d'évoluer en intégrant de nouveaux concepts innovants.
La programmation orientée objet (POO) fut une étape importante pour commencer à modéliser la structure des données dans le code du programme même. La modélisation MERISE qui était utilisée pour modéliser les données dans les bases de données relationnelles finit par être remplacée par UML ; le diagramme de classe d'UML est un bon outil pour modéliser les classes dans langages orientées objet. C'est cette modélisation qui sera utilisée dans Data Flow Generator.
1.1.3 Le design pattern
En parallèle à toutes ces innovations, le non concepteur d'outil de développement, les utilisateurs de ces outils continuaient et continue de réfléchir.
Le développeur expérimenté finit par décrire ou définir des modèles ou ce qu'on appelle des patrons ou en anglais (pattern). Ces longues réflexions basées sur l'expérience à conduit à l'établissement du design pattern.1.2 Pourquoi générer du code ; le développement piloté par les modèles (model-driven development)
Toutes ces améliorations dans le monde du développement de logiciels se retrouvent forcément dans le développement piloté par les modèles (model-driven development).
Vous trouverez facilement de la documentation sur les avantages et les inconvénients du développement piloté par les modèles, qui est encore mal connu par bon nombre de développeurs.
Le développement de DataFlowGenerator a été fortement inspiré, d'une manière très simplifiée, du projet FAROS. C'est une façon simple d'illustrer, ces méthodes; le développement piloté par les modèles (Model driven architecture ou model-driven development).
Le projet FAROS a déjà écrit l'état de l'art sur cette question, si vous voulez en savoir plus consultez le chapitre 5 du document Etat de l’art sur la contractualisation et la composition
Le site du projet FAROS : www2.lifl.fr/faros
Mais retenez que cette méthodologie permet de se concentrer ce qui est essentiel, ce qui rend le nécessité de faire le développement, mis sous forme minimale, sous forme plus accessible à l'analyse et à la conception, et surtout la charge de la maintenance du code est forcément très réduits car l'action des corrections et des évolutions se limitent à une quantité d'information la plus minimale qui aussi limite les erreurs de propagation de la même information.
1.3 La place de Data Flow Generator dans tout ça
Data Flow Generator est un outil de développement, qui à partir d'un modèle (développement piloté par les modèles), génère du code qui permet de construire une structure de données en mémoire vive et la même structure de données sous forme persistante ou sérialisée. Il ne génère pas seulement du code déclarative comme certains éditeurs d'UML, mais aussi il génère un minimum de code pour manipuler ces données (copie, extraction, création, lecture, écriture, vérification de cardinalité, interception, etc.).
Pour l'instant il génére du code en c++ et python. La forme persistante actuelle utilise le format XML ; en c++ la librairie XERCES est utilisée et en python le module xml.dom.minidom
Il permet aussi de garder la cohérence entre le modèle et le code en cours de développement. En effet le modèle peut être modifié et le code régénéré sans gêner le développement manuel (classique) des traitements autour de ces données ainsi restructurées.
Cet outil a été développé en ayant à l'esprit rois exigences essentielles :
- Synchronisation permanente entre le modèle et le code
- La structure des données intrinsèquement définit par le code doit être exactement la structure définit par le modèle.
- Le passage immédiat en développement manuel (classique)
- Le code généré doit ressembler à un code développé manuellement afin que celui-ci puisse être reprise.
- Pas de pollutions avec le code généré (séparation entre code généré et code écrit)
- Le code généré ne doit pas être mélangé dans le code écrit manuellement (les fichiers sont bien séparés).
1.3.1 Schema
A ma connaissance il n'existe pas d'outil en open source équivalent à Data Flow Generator pour générer du c++. Pour le monde java il en existe sûrement.
La grammaire utilisée pour modéliser est une forme personnalisée très simplifiée et limité de Schema voir http://www.w3.org/XML/Schema et http://fr.wikipedia.org/wiki/XML_Schema.
Vous pouvez consulter ces sites pour trouver d' éventuels outils pour générer du c++.
1.3.2 Utilitié et liens
Pour ceux qui développent en C++, Python et veulent sérialiser leurs données sous format XML (et peut être bientôt sous HDF) ou tout simplement pour tout ceux qui veulent développer en C++ et Python et veulent avoir rapidement un ensemble de classes prêt à l'emploi en mémoire interne, cet outil peut dans la plupart des cas vous générer le code pour vous. Il n'y pas de rupture entre le modèle et le code généré; le modèle reflétera toujours la structure des données (Le modèle commande le code !).
Vous pouvez utiliser DataFlowGenerator en ligne sur : http://dfg.bht-diffusion.com
Le manuel de référence, qui est souvent difficile à digérer, se trouve sur manuel de référence sur wiki.bht-diffusion.com
1.4 La structure des données est arborescente
Les données en général sont structurées en arborescente. Par exemple le système de fichiers des système LINUX est arborescent avec une racine unique. Pour représenter des graphies il faut faire toucher certains feuilles de l'arbre par des liens.
Les modèles de Data Flow generator modélisent des données ayant une structures arborescentes à racine unique. Le modèle ne permet pas de définir des liens entre les feuilles. S'il faut décrire de graphes c'est l'utilisateur du code généré qui doit définir ces liens.
2 Où trouver l'outil
L'outil est utilisable en ligne sur Internet à l'adresse http://dfg.bht.fr .
3 Le work flow
Le work flow est assez simple. Le modèle est définit dans un fichier au format XML. Ce fichier sert d'entrée à DFG (Data Flow Generator). Suivant le langage choisi DFG contient des modèles applicatifs ou des sortes de patron de codes. A partir de ces données DFG génère le code permettant de travailler avec la structure de ces données défini par le modèle.
Fig. n°2: Le work flow de Data Flow Generator
Le work flow suivant montre les évolutions possibles pour étendre la liste des formats de bas niveau des fichiers de sérialisation (cadres en pointillés).
Fig. n°3: Le work flow des évolutions possibles de Data Flow Generator
4 La modèlisation des données
La grammaire de la modélisation est définie entièrement dans Manuel de référence de la grammaire de Data Flow Generator.
Mais prenons un exemple sous sa forme la plus simple pour être comprise de façon intuitive :
4.1 Exemple simple
<!-- tuto_001 from "tuto_001.xml" -->
. tuto_001 : grammar from "tuto_001.xml" type="xml" version="1.0.0"
FileFormatVersion="1.0.0"
. . entreprise:CEntreprise
. . . red:CRed
. . . . departement:CDepartement cardinality="+"
. . . . . nom:string /
. . . . . agents:CAgent cardinality="*"
. . . . . . prenom:string /
. . . . . . nom:string /
. . . . . . fonction:string /
Ce modèle dit que l'enreprise possède un R&D. la R&D possède plus d'un département. Chaque département a un nom et possède des agents (de 0 à l'infini). Chaque agent possède un prénom, nom et fonction.
L'équivalent de ce modèle dans la grammaire de Data Flow Generator est le suivant :
<?xml version="1.0" encoding="UTF8"?>
<grammar type="xml" version="1.0.0" FileFormatVersion="1.0.0">
<el name="entreprise" type='CEntreprise' >
<el name="red" type='CRed' >
<el name="departement" type='CDepartement' cardinality="1:*">
<el name="nom" type='string'/>
<el name="agents" type='CAgent' cardinality="*">
<el name="prenom" type='string'/>
<el name="nom" type='string'/>
<el name="fonction" type='string'/>
</el>
</el>
</el>
</el>
</grammar>
Le diagramme UML équivalent est le suivant :
4.2 Exemple plus complexe
<!-- tuto_002 from "tuto_002.xml" -->
. tuto_002 : grammar from "tuto_002.xml" type="xml" version="1.0.0" FileFormatVersion="1.0.0"
. . dessin:CDessin
. . . base:CBase OnlyDefinition="1"
. . . point:CPoint heritances="CBase" OnlyDefinition="1"
. . . . x:float /
. . . . y:float /
. . . segment:CSegment heritances="CBase" OnlyDefinition="1"
. . . . A:@CPoint
. . . . B:@CPoint
. . . cercle:CCercle heritances="CBase" OnlyDefinition="1"
. . . . C:@CPoint
. . . . R:float /
. . . compound:CCompound cardinality="*" heritances="CBase"
. . . . elements:@CBase cardinality="*" accept="CPoint:CSegment:CCercle:CCompound"
L'équivalent de ce modèle dans la grammaire de Data Flow Generator est le suivant :
<?xml version="1.0" encoding="UTF-8"?>
<grammar type="xml" version="1.0.0" FileFormatVersion="1.0.0">
<el name="dessin" type="CDessin">
<el name="base" type="CBase" OnlyDefinition="1">
</el>
<el name="point" type="CPoint" heritances="CBase" OnlyDefinition="1">
<el name="x" type="float"/>
<el name="y" type="float"/>
</el>
<el name="segment" type="CSegment" heritances="CBase" OnlyDefinition="1">
<el name="A" type="@CPoint"/>
<el name="B" type="@CPoint"/>
</el>
<el name="cercle" type="CCercle" heritances="CBase" OnlyDefinition="1">
<el name="C" type="@CPoint"/>
<el name="R" type="float"/>
</el>
<el name="compound" type="CCompound" cardinality="*" heritances="CBase">
<el name="elements" type="@CBase" cardinality="*"
accept="CPoint:CSegment:CCercle:CCompound"/>
</el>
</el>
</grammar>
Le diagramme UML équivalent est le suivant :
Voici un exemple de forme persistante de données défini par le modèle :
<?xml version="1.0" encoding="UTF-8"?>
<dessin DriverName="DataFlowGenerator_XML_DOM_MINIDOOM" DriverVersion="0.22.0" FileFormatVersion="1.0.0">
<compound>
<elements dfg_classname="CCercle">
<C>
<x>3.000000E+00</x>
<y>0.000000E+00</y>
</C>
<R>4.000000E+01</R>
</elements>
<elements dfg_classname="CSegment">
<A>
<x>5.000000E+00</x>
<y>6.000000E+00</y>
</A>
<B>
<x>1.000000E+00</x>
<y>-2.000000E+00</y>
</B>
</elements>
<elements dfg_classname="CCompound">
<elements dfg_classname="CCercle">
<C>
<x>7.000000E+00</x>
<y>0.000000E+00</y>
</C>
<R>3.000000E+01</R>
</elements>
<elements dfg_classname="CCompound">
<elements dfg_classname="CCercle">
<C>
<x>4.000000E+00</x>
<y>0.000000E+00</y>
</C>
<R>2.000000E+01</R>
</elements>
</elements>
</elements>
</compound>
<compound>
<elements dfg_classname="CCercle">
<C>
<x>4.000000E+00</x>
<y>0.000000E+00</y>
</C>
<R>2.000000E+01</R>
</elements>
</compound>
</dessin>
