Wikip - Modifications récentes [fr]

Modèle:EnConstruction

2026-07-24T17:08:53Z

WikiAdmin a importé Modèle:EnConstruction par téléversement de fichier (1 version) dfg

Nouvelle page

<includeonly>{{Ligne_exergue
|gaucheW=width:32px;
|gauche=🚧
|texte={{fr§en|Cet article est en travaux. Son contenu encore incomplet, est temporaire.|This article is under construction. Its content is still incomplete and temporary.}}
|color=#FFFF20
}}</includeonly><noinclude>
{{Model
|class=page
|texte=Ce modèle informe le lecteur que la page est en cours de modification, que sa rédaction n'est pas terminée.
|syntaxe=<nowiki>{{EnConstruction |image=[construction32.png] }}</nowiki>
|specification=
;image
:L'image ou l'icône apparaissant à gauche du texte expliquant que la page est en cours de rédaction. Par défaut l'image est [[Image:construction16.png]].
}}
Exemple :

<nowiki>{{EnConstruction}}</nowiki>

donnera :

{{EnConstruction}}

</noinclude>

Modèle:Minitodo

2026-07-24T17:08:53Z

WikiAdmin a importé Modèle:Minitodo par téléversement de fichier (1 version) dfg

Nouvelle page

<includeonly><div style="margin:0em;padding:0.1em;">{{atCount|name=todo_count|prefix=todo |id={{{2|}}}}} : {{{1}}}</div></includeonly><noinclude>
{{Model
|class=§
|texte=
|syntaxe=<nowiki>{{minitodo |texte|id}}</nowiki>
|specification=
;texte
:Le texte décrivant le travail restant à faire.
;id 2
: l'id est un identifiant unique dans la page.
}}

Exemple :

<nowiki>{{minitodo |Il ne faut pas oublier de finir …}}</nowiki>

donnera :

{{minitodo |Il ne faut pas oublier de finir …}}

{{#atallref:}}
</noinclude>

Les paragraphes tagués et/ou numérotés - bases

2026-07-24T17:08:53Z

WikiAdmin a importé Les paragraphes tagués et/ou numérotés - bases par téléversement de fichier (1 version) dfg

Nouvelle page

<noinclude>{{IntroductionNotation
|texte=
|index=Accueil
}}</noinclude>{{Not|{{m|§-n|class=cNumParTag}} : Paragraphe numéroté de 15cm de large ☞[[Modèle:Par|§-n]] |not_§1}}
{{Not|{{m|§-n|class=cNumParTag2}} : Paragraphe numéroté de 18cm de large ☞[[Modèle:Par2|§-n]] |not_§2}}
{{Not|{{m|§|class=parTag}} : Paragraphe non numéroté de 15cm de large ☞[[Modèle:ParW|§]] |not_§}}
<noinclude>
Classement par domaine:
* [[Les paragraphes tagués et/ou numérotés - Tous|Tous]]
* [[Les paragraphes tagués et/ou numérotés - bases|Les bases]]
* [[Les paragraphes tagués et/ou numérotés - généraux|Les généraux]]
* [[Les paragraphes tagués et/ou numérotés - d'informatique|Les informatiques]]
* [[Les paragraphes tagués et/ou numérotés - des mathématiques|Les mathématique]]
</noinclude>

Modèle:Code

2026-07-24T17:08:52Z

WikiAdmin a importé Modèle:Code par téléversement de fichier (1 version) dfg

Nouvelle page

<includeonly>{{AtIfNotNul|1={{{line|}}}|2={{#tag:syntaxhighlight|{{{code|}}}|lang={{{lang|text}}}|style="font-family: monospace; font-size:10pt; padding:0.1ch;margin:0.0ch;{{{colNb|80.5}}}ch;"|line=|lineStart={{{lineStart|1}}}}}|3={{#tag:syntaxhighlight|{{{code|}}}|lang={{{lang|text}}}|style="font-family: monospace; font-size:10pt;padding:0.1ch;width:{{{colNb|80}}}ch;"}}}}
</includeonly><noinclude>
{{Model
|class=lang
|texte=Ce modèle sert présenter un code programmation. Si le code utilise le caractère {{dq|{{!}}}} alors utiliser la balise (tag sgml) {{mmm|<syntaxhighlight>}}.
|auteurs=
|syntaxe=<nowiki>{{code|lang=|code=}}</nowiki>
|specification=
;lang=
:c++ php …
;code=
: le code
; colNb
: nombre de caractères en largeur (nombre de colonnes)
; line
: active la numérotation, mettre n'importe quelle valeur
; lineStart
: numéro de ligne de départ, par défaut 1
}}
Exemple :

<nowiki>{{parW|1=
{{code|colNb=80.5|lang=cpp|style=border:3px dashed blue;|code=
#2345678901234567890123456789012345678901234567890123456789012345678901234567890
# 1 2 3 4 5 6 7 8
#include <time.h>
#include <stdio.h>
void sleep( time_t nb_sec )
{
time_t limit, top; time(&top); limit = top + nb_sec ;
while (top < limit)
{
time(&top);
}
};
int main( int argc, char * argv[] )
{
time_t start, stop; time(&start); sleep( 5 ) ; time(&stop); printf("start : %ld\n",start ); printf("stop : %ld\n",stop ); printf("in seconds: %f\n",difftime(stop,start));
}
}}
}}{{parW|1=
{{code|lang=cpp|colNb=86.5|code=
#2345678901234567890123456789012345678901234567890123456789012345678901234567890123456
# 1 2 3 4 5 6 7 8
#include <time.h>
#include <stdio.h>
void sleep( time_t nb_sec )
{
time_t limit, top; time(&top); limit = top + nb_sec ;
while (top < limit)
{
time(&top);
}
};
int main( int argc, char * argv[] )
{
time_t start, stop; time(&start); sleep( 5 ) ; time(&stop); printf("start : %ld\n",start ); printf("stop : %ld\n",stop ); printf("in seconds: %f\n",difftime(stop,start));
}
}}
}}</nowiki>

donnera :

{{parW|1=
{{code|colNb=80.5|lang=cpp|style=border:3px dashed blue;|code=
#2345678901234567890123456789012345678901234567890123456789012345678901234567890
# 1 2 3 4 5 6 7 8
#include <time.h>
#include <stdio.h>
void sleep( time_t nb_sec )
{
time_t limit, top; time(&top); limit = top + nb_sec ;
while (top < limit)
{
time(&top);
}
};
int main( int argc, char * argv[] )
{
time_t start, stop; time(&start); sleep( 5 ) ; time(&stop); printf("start : %ld\n",start ); printf("stop : %ld\n",stop ); printf("in seconds: %f\n",difftime(stop,start));
}
}}
}}{{parW|1=
{{code|lang=cpp|colNb=86.5|code=
#2345678901234567890123456789012345678901234567890123456789012345678901234567890123456
# 1 2 3 4 5 6 7 8
#include <time.h>
#include <stdio.h>
void sleep( time_t nb_sec )
{
time_t limit, top; time(&top); limit = top + nb_sec ;
while (top < limit)
{
time(&top);
}
};
int main( int argc, char * argv[] )
{
time_t start, stop; time(&start); sleep( 5 ) ; time(&stop); printf("start : %ld\n",start ); printf("stop : %ld\n",stop ); printf("in seconds: %f\n",difftime(stop,start));
}
}}
}}
</noinclude>

Dfg txt like uml language

2026-07-24T17:08:50Z

WikiAdmin a importé Dfg txt like uml language par téléversement de fichier (1 version) dfg

Nouvelle page

{{IntroductionDFG
|keyWords= uml text txt language langage dfg
|texte=
|auteurs=Arthur TOROSSIAN
|index=DataFlowGenerator
}}
== Exemples ==
=== Dfg grammar ===
{{parW|1=
{{code|lang=text|code=
CEl
? help : CStr
? longHelp : CStr
? shortHelp : CStr
CAss
? card : CStr
name : CStr
CLeave (CEl,CAss,)
? admVals : CStr
? defVal : CStr
? isAttr : CBool
CScalarLeave (CLeave,)
? unit : CStr
CClBase (CEl,)
? accept : CStr
type : CStr
CClass (CClBase,)
? her : CStr
* bool : CBool (CLeave,)
* clDef : CClDef (CClass,)
* clDefInst : CClDefInst (CClDef,CAss,)
* clInst : CClInst (CClBase,CAss,)
* clRef : CClRef (CClBase,CAss,)
* date : CDate (CLeave,)
* flt : CFlt (CScalarLeave,)
* int : CInt (CScalarLeave,)
* map : CMap (CEl,CAss,)
keyType : CStr
valType : CStr
* method : CMethod
name : CStr
* arg : CArg
dir : CStr
name : CStr
type : CStr
? unit : CStr
* str : CStr (CLeave,)
dfg : CDfg (CClass,)
}}
}}
=== Load curve ===
{{parW|1=
{{code|lang=text|code=
consumption : CLoadCurve
energyUnit : CStr
timeStep : CFlt
timeUnit : CStr
* values : CFlt
0:1 comment : CComment
ligne : CStr
}}
}}
=== Surface dépôt ===
{{parW|1=
{{code|lang=text|code=
surfaceDepot : CSurfaceDepot
? highWaterLevel : CFlt
* profileData : CProfileData
num : CInt
surface : CFlt
form : CForm
* coef : CFlt
? highWaterLevel : CFlt
}}
}}
=== ihm calcul data ===
{{parW|1=
{{code|lang=text|code=
ihmCalculData : CIhmCalculData
calculMode : CInt # 1 -> production, 2-> Sûreté, 0 -> non défini
bathyDate : CDate
tidalDate : CDate
# projectionDuration
tidalGap : CFlt # [m] déôte de marée
lowSeaLevel : CFlt # [m]CM niveau de basse mer
* pump : CPump
ref : CStr
active : CBool
? pbes : CFlt # [m]CM
sedimentaryDynamics : CSedimentaryDynamics
sedimentaryDynamicType : 1->auto, 2->null, 2->manual
autoCalculMode : CInt
# 1 -> Prédéfinie,
# 2 -> Prorata
autoPredefinedMode : CInt # 1-> maximum, 2-> quantil75, 3->moyen
siltingPeriod : CInt
# 1-> après dragage à septembre,
# 2-> octobre à dragage d'hiver,
# 3-> dragage d'hiver à dragage été
manualDynamic : CManualDynamic
* profileData : CProfileData
num : CInt
surface : CFlt
}}
}}

Dfg1 reference manual - xml - dfguml

2026-07-24T17:08:49Z

WikiAdmin a importé Dfg1 reference manual - xml - dfguml par téléversement de fichier (1 version) dfg

Nouvelle page

<noinclude>{{IntroductionDFG}}</noinclude>
[[Catégorie:Dfg1RefManual]]{{proj_p|L'élément {{m|<?xml … ?>}} fait partie du langage XML même. Il possède les attributs {{m|version}}{{clink|ref_xml_version}} et {{m|encoding}}{{clink|ref_xml_encoding}}.
|par_xml_ref}}

Dfg1 reference manual - xml - plantuml

2026-07-24T17:08:49Z

WikiAdmin a importé Dfg1 reference manual - xml - plantuml par téléversement de fichier (1 version) dfg

Nouvelle page

<noinclude>{{IntroductionDFG}}</noinclude>
[[Catégorie:Dfg1RefManual]]{{proj_p|Le diagramme UML de l'exemple {{clink|dfgumlr_xml}} est donné par {{clink|plantumlr_xml}}, qui n'est réduit qu'une seule classe; la classe racine.}}

Dfg1 reference manual - xmlEncoding - dfguml

2026-07-24T17:08:48Z

WikiAdmin a importé Dfg1 reference manual - xmlEncoding - dfguml par téléversement de fichier (1 version) dfg

Nouvelle page

<noinclude>{{IntroductionDFG}}</noinclude>
[[Catégorie:Dfg1RefManual]]{{proj_p|Et l'attribut {{m|encoding}} du nœud «?xml»{{clink|par_xml_ref}} est le type de l'encodage du fichier texte, ce type a toujours la valeur «UTF-8».
|ref_xml_encoding}}

Dfg1 reference manual - xmlVersion - dfguml

2026-07-24T17:08:48Z

WikiAdmin a importé Dfg1 reference manual - xmlVersion - dfguml par téléversement de fichier (1 version) dfg

Nouvelle page

<noinclude>{{IntroductionDFG}}</noinclude>
[[Catégorie:Dfg1RefManual]]{{proj_p|L'attribut {{m|version}} du nœud {{clinkn|par_xml_ref|«?xml»}} est la version du XML utilisé, sa valeur est toujours «1.0».
|ref_xml_version}}

Manuel utilisateur de Data Flow Generator V1

2026-07-24T17:08:47Z

WikiAdmin a importé Manuel utilisateur de Data Flow Generator V1 par téléversement de fichier (1 version) dfg

Nouvelle page

{{IntroductionDFG}}
{{Modèle:EnConstruction}}
== Exemple de script d'utilisation ==
{{parW|1=
{{code|lang=bash|code=
#!/bin/bash
dataName="chenalData"
dfgCheck=/home/atoross/dvlp/tools/svn/dfg1dvlp/dfgGrammarCheck.py
dfgPath=/home/atoross/dvlp/tools/svn/dfg1dvlp/dfg_V1PythonGenDriver.py

rm -Rf ./generated/*
#python ${dfgPath} -h
python ${dfgCheck} -c ${dataName}Model.xml -o generated/${dataName}ModelGr.xml
python ${dfgPath} --pathGrammarfile ${dataName}Model.xml \
--dataName ${dataName} \
--pathGen generated \
--exportTxt \
--plantuml

# chenalDataPlantUml.puml
plantUml=/home/atoross/exe/bin/plantuml.jar
java -jar ${plantUml} -charset 'UTF-8' -tsvg \
generated/${dataName}PlantUml.puml
}}
}}

Data Flow Generator - Historique

2026-07-24T17:08:47Z

WikiAdmin a importé Data Flow Generator - Historique par téléversement de fichier (1 version) dfg

Nouvelle page

{{IntroductionDFG}}
{{proj_p|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 {{m|alertes|#FF8080}} disséminé ici et là.}}
{{proj_p|D'abord il faut distinguer le {{m|langage pivot}}({{clink|langage pivot}}), {{m|le moteur de simulation par évènement discret}}({{clink|Une simulation à événements discrets}}) et {{m|les outils de génération de codes}} que j'ai nommé {{m|Data Flow Generator}} noté {{m|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 {{m|Discrete Event Simulator Generator}} - noté {{m|DisEvtSimGen}} ou {{m|DFG1}} dont version est 1.X.X - car je lui ai adjoint le moteur de simulation par évènement discret,
{{Rq|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 {{m|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.}}
{{proj_p|La spécification du {{m|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.}}
{{Rq|Pour concevoir le moteur j'ai été grandement aidé par Olivier, le grand gourou du domaine, en échangeant beaucoup sur {{m|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 {{m|Sim-Diasca}} (exemple : le temps fuji).}}
{{proj_p|Les sources du {{m|moteur de simulation par évènement discret}} sera forcément fourni au projet !}}
{{RqI|On peut difficilement dissocier le moteur du {{m|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.}}
{{Rq|Dailleurs je ne comprends pas comment {{m|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 {{m|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 {{m|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.}}
{{RqI|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 ?}}
{{proj_p|{{m|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 .
}}
{{Rq|N'oublions pas que {{m|DFG}} génère aussi du C++ utilisant {{m|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 {{m|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é {{m|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 …)).
{{Ex|Il faut dire que j'avais une première expérience dans le projet {{m|PERFECT}}. Contraint par des conditions similaires, en 2005, j'ai écrit un générateur d'intégration de solveurs, que j'ai appelé {{m|PERFECT_Maker}}, dans le projet {{m|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 {{m|YACS}} de SALOME développé par André (SINETICS-I2A) (http://www.salome-platform.org/about/yacs) et le {{m|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é {{m|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 à {{m|DFG}}. Merci, merci, merci, …}}
{{RqI|Pourquoi faire ce petit REX historique ? En fait, {{m|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 {{m|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.}}
{{RqI|Sans l'existence préalable de {{m|DFG}}, le {{m|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 {{m|DFG}}. Par contre le temps passé a permis de mettre {{m|rapidement}} au point le {{m|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 {{m|ForCity}} ainsi que bon nombre de lignes de code généré gratuitement pour le projet {{m|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}}
{{Def|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 {{m|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 {{m|COSMO}}.|langage pivot|langage pivot}}
{{Def|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).|Une simulation à événements discrets|Une simulation à événements discrets}}

Dfg1 reference manual - grammar - dfguml

2026-07-24T17:08:47Z

WikiAdmin a importé Dfg1 reference manual - grammar - dfguml par téléversement de fichier (1 version) dfg

Nouvelle page

<noinclude>{{IntroductionDFG}}</noinclude>
[[Catégorie:Dfg1RefManual]]
{{proj_p|Le nœud {{m|grammar}} (définit la grammaire du langage) est la racine du meta-modèle de Data Flow Generator. Ce nœud doit être toujours présent dans tout modèle.
|par_grammar_ref}}
{{proj_p|Il possède les attributs type, version et fileFormatVersion.}}
{{proj_p|L'attribut {{m|type}} est le nom de la classe correspondante qui a toujours la valeur {{m|xml}}.}}
{{proj_p|L'attribut {{m|version}} est la version du méta-modèle (ou grammaire). La version actuelle est «2.0.0».}}
{{proj_p|L'attribut {{m|fileFormatVersion}} est la version du format de fichier. Sa valeur est gérée par le modélisateur. Pour plus d'information sur le versionnement voir [[#Grammar.2FFile_Format_versioning|Annexe]].
}}

Comment utiliser les fichiers de Dia comme fichier d'entrée de Data Flow Generator V1

2026-07-24T17:08:46Z

WikiAdmin a importé Comment utiliser les fichiers de Dia comme fichier d'entrée de Data Flow Generator V1 par téléversement de fichier (1 version) dfg

Voir les modifications

Guide de Référence de DfgBehaviour

2026-07-24T17:08:46Z

WikiAdmin a importé Guide de Référence de DfgBehaviour par téléversement de fichier (1 version) dfg

Nouvelle page

Guide de Référence de DfgUml

2026-07-24T17:08:38Z

WikiAdmin a importé Guide de Référence de DfgUml par téléversement de fichier (1 version) dfg

Nouvelle page

{{IntroductionDFG}}
{{parW|
{{Modèle:EnConstruction}}
}}
[[Catégorie:dfg1RefManual]]
== Notations et abréviations ==
{{:Les paragraphes tagués et/ou numérotés - bases}}
{{:Les paragraphes tagués et/ou numérotés - généraux}}
{{:Les paragraphes tagués et/ou numérotés - d'informatique}}

== Les prérequis pour lire ce document ==
{{proj_p|Le meta-modèle utilise le langage {{m|XML}} ([http://www.w3schools.com/xml/ Lien vers un tutoriel sur XML]).}}
{{proj_p|Au dessus du langage XML le méta-modèle décrit des diagrammes de classes du langage {{m|UML}} ([http://www.sparxsystems.com/uml-tutorial.html Lien vers un tutoriel sur UML]).}}
{{proj_p|Il faut donc connaître les langages {{m|XML}} et {{m|UML}} pour lire ce document.}}

== Le langage XML ==
{{proj_p|Même si la connaissance du langage XML est un prérequis pour lire ce document, il est utile de rappeler ici quelques notions. Le but étant de préciser le vocabulaire et les notations que nous utiliserons dans la suite.}}
{{proj_p|La langage XML permet de définir des langages et ce pourquoi il est un métalangage. Ces langages permettent de créer des documents au format texte structurés à l'aide de {{m|balises}}({{m|tags}}).
}}
=== Balise ouvrante ===
{{Def
|1=
Une balise dite ouvrante est un texte commençant le symbole {{m|<}}(plus petit), suivi du nom de balise puis des attributs de la balise. Elle se termine par le symbole {{m|>}}(plus grand).

Les attributs suivent la syntaxe suivante :
{{code|lang=xml|code=attributeName2="AttributeValue2"}}
par exemple :
{{code|lang=xml|code=color="green"}}
Et la structure générale d'une balise ouvrante est :
{{code|lang=xml|code=
<baliseName attributeName1="AttributeValue1"
attributeName2="AttributeValue2"
…
attributeNamen="AttributeValuen">
}}
|2=|3=balise ouvrante}}
{{Ex|1={{code|lang=xml|code=<city name="Paris">}}|2=|3=}}

=== Balise fermante ===
{{Def
|1=
Une balise dite fermante est un texte commençant le symbole {{m|<}}, puis {{m|/}}, suivi du nom de balise et se terminant par le symbole {{m|>}}(plus grand).
<source lang="xml"></baliseName></source>
|2=
|3=balise fermante}}
{{Ex|1=<source lang="xml"></city></source>|2=|3=}}

=== Balise ouvrante et fermante ===
{{Def
|1=Une balise ouvrante et fermante est une balise ouvrante qui ne se termine pas par {{m|>}} mais par {{m|/>}}.
<source lang="xml">
<baliseName attributeName1="AttributeValue1" attributeName2="AttributeValue2" … attributeNamen="AttributeValuen"/>
</source>
|2=
|3=balise ouvrante et fermante}}
{{Ex|1=<source lang="xml"><city name="Paris"/></source>|2=|3=}}

=== Nœud ===
{{Def|Un nœud XML est l'ensemble du texte commençant par une balise ouvrante et se terminant par la balise correspondante fermante. Le nom du nœud est le nom de la balise correspondante
|Nœud XML|Nœud XML}}
{{Ex|1=Un nœud XML appelé city : <source lang="xml"><city id="AR32"> <name>Paris</name> … </city></source>|2=|3=}}
{{Def|L'en-tête d'un nœud est l'ensemble des attributs de la balise.
|En-tête de nœud|En-tête de nœud}}
{{Def|Le corps d'un nœud est la partie du texte qui se trouve entre la balise ouvrante et la balise fermante correspondante.
|Corps de nœud|Corps de nœud}}
{{Rq|Le corps d'un nœud où la balise est ouvrante et fermante possède un corps vide.}}
{{Rq|Le corps de nœud peut aussi contenir d'autres nœuds. L'en-tête et le corps d'un nœud définissent sa structure. Cette structure est arborescente. }}
{{Ex|1=<source lang="xml"> <russian_doll name="Galina">
<russian_doll name=" Anastasiya">
<russian_doll name=" Marta"/>
</russian_doll>
</russian_doll>
</source>|2=|3=Les poupées russes}}
{{Rq|Dans certains cas un élément d'un nœud peut se mettre sous la forme d'un attribut ou sous la forme d'un nœud. Cela peut être le cas par exemple pour nommer un nœud.}}
{{Ex|1=<source lang="xml"><city name="Paris"> … </city></source> ou <source lang="xml"><city> <name>Paris</name> … </city></source>|2=|3=}}

== Le modèle vide ==
{{proj_p|Le modèle minimal de Data Flow Generator est donné par l'exemple {{clink|empty_model_ref}}
}}
{{ex|
<source lang="xml">
<?xml version="1.0" encoding="UTF8"?>
<grammar type="xml" version="2.0.0" fileFormatVersion="1.0.0">
</grammar>
</source>|empty_model_ref}}
{{proj_p|Ce modèle est composé de deux éléments XML; {{m|?xml}}{{clink|par_xml_ref}} et {{m|grammar}}{{clink|par_grammar_ref}}.}}
{{proj_p|Le document DfgUml doit comporter un unique nœud racine nommé {{m|grammar}}{{clink|par_grammar_ref}}.}}
{{proj_p|Le diagramme de classes de ce modèle est le diagramme vide.}}

== Le modèle minimal ==
{{proj_p|Tout modèle doit définir un unique nœud racine à l'aide du nœud nommé {{m|clDefInst}}.}}
{{proj_p|Dans les exemples {{clink|dfguml_minimal_model}} et {{clink|dfg_ex_minimal}}, qui illustrent le modèle minimal, la racine a pour nom «model» et nous avons nommé sa classe «CModel».}}
{{ex|
<source lang="xml">
<?xml version="1.0" encoding="UTF8"?>
<grammar type="xml" version="2.0.0" fileFormatVersion="1.0.0">
<clDefInst type='CModel' name="model" >
</clDefInst>
</grammar>
</source>
|dfguml_minimal_model}}
{{figuml|UML diagramme équivalent|class CModel {
}
|dfg_ex_minimal}}

== Les nœuds, associations et héritages du méta-modèle ==
=== Liste des nœuds ===
{{proj_p|Pour commencer nous donnons seulement la liste des nœuds utilisés dans le méta-modèle, chaque nœud sera plus loin étudié de près : {{m|bool}}, {{m|int}}, {{m|flt}}, {{m|str}}, {{m|date}}, {{m|clDefInst}}, {{m|clInst}}, {{m|clRef}}, {{m|clDef}}, {{m|method}}, {{m|arg}}. Les types primitives sont {{m|bool}} (booléen), {{m|int}}(entier), {{m|flt}}(réel), {{m|str}}(chaîne de caractères), {{m|date}}(date).}}

=== Association entre classes ===
{{proj_p|L'association entre classes est définie par l'inclusion d'un nœud (enfant) dans un autre nœud (parent). Côté parent la cardinalité est toujours {{m|1}} et côté enfant l'attribut {{m|card}} permet de le définir avec la convention suivante :

Soient n, n1, n2 des entiers
{{tab|Notation de cardinalité||
{{line| {{col_t|notation dans les doubles quottes}} {{col_t|description}} }}
{{line| {{col|"n1:n2"}} {{col|de n1 à n2}} }}
{{line| {{col|"?" or "0:1"}} {{col|de 0 à 1, optionnel}} }}
{{line| {{col|"*" or "0:*"}} {{col|de 0 à l'infini}} }}
{{line| {{col|"+" or "1:*"}} {{col|de 1 à l'infini}} }}
{{line| {{col|"n:" or "n:*"}} {{col|de n à l'infini}} }}
{{line| {{col|"n" or "n:n"}} {{col|de n à n, exactement n}} }}
{{line| {{col|si non présent}} {{col|valeur de défaut : exactement 1 }} }}
}}
}}
{{Ex|Voici un exemple d'associations entre la classe A et les classes B,C,D,E,F,G.
<source lang="xml">
<?xml version="1.0" encoding="UTF8"?>
<grammar type="xml" version="2.0.0" fileFormatVersion="1.0.0">
<clDefInst type='A' name="a" >
<clDefInst type='B' name="b"/>
<clDefInst type='C' name="c" card="4"/>
<clDefInst type='D' name="d" card="?"/>
<clDefInst type='E' name="e" card="*"/>
<clDefInst type='F' name="f" card="+"/>
<clDefInst type='G' name="g" card="3:45"/>
</clDefInst>
</grammar>
</source>
Le diagramme UML équivalent est le suivant :
{{figuml|Association|
class A {
}
A *-- "1" B : b
class B {
}
A *-- "4" C : c
class C {
}
A *-- "0..1" D : d
class D {
}
A *-- "0..*" E : e
class E {
}
A *-- "1..*" F : f
class F {
}
A *-- "3..45" G : g
class G {
}
}}
Et une instance persitante possible de ce modèle utilisant le format XML peut être le fichier suivant :
<source lang="xml">
<?xml version="1.0" encoding="UTF-8"?>
<grammar driverName="DataFlowGenerator_XML_DOM_MINIDOOM" driverVersion="1.0.0" fileFormatVersion="1.0.0" type="xml" version="2.0.0">
<a>

<c/>
<c/>
<c/>
<c/>
<f/>
<g/>
<g/>
<g/>
</a>
</grammar>
</source>
}}

=== Héritage ===
{{Ex|Prenons le cas d'une classe CRoot qui est associée (agrégation) à un classe C qui hérite de la classe B qui hérite de la classe A. Ce cas est décrit par diagramme {{clink|Héritage simple}}.
{{figuml|Héritage simple|class CRoot {
}
abstract class A {
}
A : CInt a
abstract class B {
}
B --{{!}}> A
B : CInt b
CRoot *-- "3" C : c
class C {
}
C --{{!}}> B
C : CInt c
|Héritage simple}}
L'équivalent en modèle DFGUML sécrira :
<source lang="xml">
<?xml version="1.0" encoding="UTF8"?>
<grammar type="xml" version="2.0.0" fileFormatVersion="1.0.0">
<clDefInst type='CRoot' name="root" >
<clDef type='A' name="a">
<int name="a" defVal="1"/>
</clDef>
<clDef type='B' name="b" her="A">
<int name="b" defVal="2"/>
</clDef>
<clDefInst type='C' name="c" her="B" card="3">
<int name="c" defVal="3"/>
</clDefInst>
</clDefInst>
</grammar>
</source>
Et une instance possible de ce modèle est la suivante :
<source lang="xml">
<?xml version="1.0" encoding="UTF-8"?>
<grammar driverName="DataFlowGenerator_XML_DOM_MINIDOOM" driverVersion="1.0.0" fileFormatVersion="1.0.0" type="xml" version="2.0.0">
<root>
<c>
<a>1</a>
2
<c>3</c>
</c>
<c>
<a>1</a>
2
<c>3</c>
</c>
<c>
<a>1</a>
2
<c>3</c>
</c>
</root>
</grammar>
</source>
}}
{{proj_p|L'héritage est définie avec l'attribut {{m|her}} dont la valeur est la classe parente. Afin de ne pas associer une définition de classe, qui est un nœud donné avec la classe parent qui lui-même est le nœud parent associé on utilise la balise {{m|clDef}} comme c'est le cas des classes A et B dans notre cas précédent.}}

== Les éléments ==

=== {{fr§en|Le nœud «?xml»|The «?xml» node}} ===
{{:dfg1 reference manual - xml - dfguml}}
{{ex|
<source lang="xml">
<?xml version="1.0" encoding="UTF8"?>
<grammar type="xml" version="2.0.0" fileFormatVersion="1.0.0">
<clDefInst name="root" type="CRoot">
</clDefInst>
</grammar>
</source>
|dfgumlr_xml
}}
{{:dfg1 reference manual - xml - plantuml}}
{{figuml
|
|class CRoot {
}
@enduml
|plantumlr_xml}}

=== {{fr§en|L'attribut «version» du nœud «?xml»|The attribute named «version» of the «?xml» node| -◊- }} ===
{{:dfg1 reference manual - xmlVersion - dfguml}}

=== {{fr§en|L'attribut «encoding» du nœud «?xml»|The attribute named «encoding» of the «?xml» node| -◊- }} ===
{{:dfg1 reference manual - xmlEncoding - dfguml}}

=== {{fr§en|Le nœud «grammar»|The «grammar» node}} ===
{{:dfg1 reference manual - grammar - dfguml}}
{{ex|
<source lang="xml">
<?xml version="1.0" encoding="UTF8"?>
<grammar driverName="DataFlowGenerator_XML_DOM_MINIDOOM" driverVersion="1.0.0" fileFormatVersion="1.0.0" type="xml" version="2.0.0">
<clDefInst name="root" type="CRoot">
</clDefInst>
</grammar>
</source>
|dfgumlr_grammar
}}

== Annexe ==
=== Description du mét-modèle par lui-même ===
{{parW|1=
{{code|lang=xml|code=
<dfg dfgDrvName="DataFlowGenerator_XML_DOM_MINIDOOM" dfgDrvVer="3.0.0" dfgModelVer="3.0.0" dfgMetaModelVer="3.0.0" type="CDfg">

<clDef type="CEl">
<str name="help" card="?" isAttr="True" />
<str name="shortHelp" card="?" />
<str name="longHelp" card="?" />
</clDef>
<clDef type="CAss">
<str name="name" help="python_re_pattern='^[a-zA-Z_][a-zA-Z0-9_]*$'" isAttr="True" />
<str name="card" card="?" isAttr="True" />
</clDef>
<clDef type="CLeave" her="CEl:CAss" >
<str name="defVal" card="?" isAttr="True" />
<str name="admVals" card="?" isAttr="True" />
<bool name="isAttr" card="?" isAttr="True" />
</clDef>
<clDef type="CScalarLeave" her="CLeave">
<str name="unit" card="?" isAttr="True" />
</clDef>
<clDef type="CClBase" her="CEl" >
<str name="type" isAttr="True" />
<str name="accept" card="?" isAttr="True" />




</clDef>
<clDef type="CClass" her="CClBase" >
<str name="her" card="?" isAttr="True" />

<clDefInst name="str" type="CStr" her="CLeave" card="*"/>
<clDefInst name="int" type="CInt" her="CScalarLeave" card="*"/>
<clDefInst name="bool" type="CBool" her="CLeave" card="*"/>
<clDefInst name="date" type="CDate" her="CLeave" card="*"/>
<clDefInst name="flt" type="CFlt" her="CScalarLeave" card="*"/>

<clDefInst name="clDef" type="CClDef" her="CClass" card="*"/>
<clDefInst name="clInst" type="CClInst" her="CClBase:CAss" card="*"/>
<clDefInst name="clDefInst" type="CClDefInst" her="CClDef:CAss" card="*"/>
<clDefInst name="clRef" type="CClRef" her="CClBase:CAss" card="*"/>


<clDefInst name="map" type="CMap" her="CEl:CAss" card="*">

<str name="valType" isAttr="True" />
<str name="keyType" isAttr="True" />
</clDefInst>



<clDefInst name="method" type="CMethod" card="*">
<str name="name" isAttr="True" />
<clDefInst name="arg" type="CArg" card="*">
<str name="type" isAttr="True" help="python_re_pattern='^[a-zA-Z_][a-zA-Z0-9_]*$'"/>
<str name="dir" isAttr="True" admVals="in:out:inout"/>
<str name="name" isAttr="True" />
<str name="unit" isAttr="True" card="?"/>
</clDefInst>
</clDefInst>
</clDef>
<clDefInst name="dfg" type="CDfg" her="CClass" >






</clDefInst>
</dfg>
}}
Sous forme texte:
{{code|lang=text|code=
CEl
. ? help : CStr
. ? longHelp : CStr
. ? shortHelp : CStr
CAss
. ? card : CStr
. name : CStr
CLeave (CEl,CAss,)
. ? admVals : CStr
. ? defVal : CStr
. ? isAttr : CBool
CScalarLeave (CLeave,)
. ? unit : CStr
CClBase (CEl,)
. ? accept : CStr
. type : CStr
CClass (CClBase,)
. ? her : CStr
. * bool : CBool (CLeave,)
. * clDef : CClDef (CClass,)
. * clDefInst : CClDefInst (CClDef,CAss,)
. * clInst : CClInst (CClBase,CAss,)
. * clRef : CClRef (CClBase,CAss,)
. * date : CDate (CLeave,)
. * flt : CFlt (CScalarLeave,)
. * int : CInt (CScalarLeave,)
. * map : CMap (CEl,CAss,)
. . keyType : CStr
. . valType : CStr
. * method : CMethod
. . name : CStr
. . * arg : CArg
. . . dir : CStr
. . . name : CStr
. . . type : CStr
. . . ? unit : CStr
. * str : CStr (CLeave,)
dfg : CDfg (CClass,)
}}
}}
{{:DataFlowGenerator:Versionnement}}

=== Liens externes ===
* Structure d'un document XML
: http://www.commentcamarche.net/contents/xml/xmlstruc.php3

DataFlowGenerator:see too

2026-07-24T17:08:38Z

WikiAdmin a importé DataFlowGenerator:see too par téléversement de fichier (1 version) dfg

Nouvelle page

<noinclude>[[Category:DataFlowGenerator|{{PAGENAME}}]]</noinclude>
== Voir aussi ==
{{parW|
* [[Tutoriel de Data Flow Generator V0]]
* [[Manuel d'utilisation de Data Flow Generator V0]]
* [[Manuel de référence de la grammaire de Data Flow Generator V0]]
* [[Manuel de référence des fichiers au format XML utilisés par les drivers générés par Data Flow Generator V0]]
* [http://dfg.bht-diffusion.com Lancer Data Flow Generator]
:*[http://dfg.bht-diffusion.com/ Générer les drivers c++ et python en ligne sur http://dfg.bht-diffusion.com]
}}

DataFlowGenerator:Versionnement

2026-07-24T17:08:31Z

WikiAdmin a importé DataFlowGenerator:Versionnement par téléversement de fichier (1 version) dfg

Nouvelle page

=== Application versioning ===
{{parW|
;R-V1.V2.V3.V4
:The identification consists of:
::{{m|R}} (release) xn pre-alpha alpha beta gamma/rcn prod/gold/live_release
:::The release is the qualification of software distribution or delivery often as a file or set of files, called a package. Here are the qualifications in the logical order of software development project (http://en.wikipedia.org/wiki/Software_testing):
:::{{m|xn}} or x1,x2, ...
::::delivery made during the development after unit tests. Distribution can be used between development teams who do not share the same basic sources;
:::{{m|pre-alpha}} or {{m|rpa}}
::::delivery made before the end of development and after integration tests. Distribution can be used between development integration testing teams;
:::{{m|alpha}} or {{m|ra}}
::::delivery made to the test team for System tests;
:::{{m|beta}} or {{m|rb}}
::::delivery made to a small number of users for User Acceptance Tests(UAT);
:::{{m|gamma_n}} or {{m|rcn}}
::::delivery also called "Release Candidate" number n, after nth UAT;
:::{{m|prod}}, {{m|gold}}, ou {{m|lr}} (live release)
::::delivery called "live release" which is considered to be very stable and relatively bug-free with a quality suitable for wide distribution and use by end users (http://en.wikipedia.org/wiki/Software_release_life_cycle).
::{{m|V1}}
:::a number that indicates the evolution of the system architecture and/or a large number of functional changes;
::{{m|V2}}
:::a number that indicates the evolution of the functions provided by the application;
::{{m|V3}}
:::a number that indicates the evolution of implementations of functions;
::{{m|V4}}
:::a number, optional, which indicates the integration of bugfixes.
}}

=== Grammar/File Format versioning ===
{{parW|
;gr{{m|V1}}.gr{{m|V2}}.gr{{m|V3}} / fl{{m|V1}}.fl{{m|V2}}.fl{{m|V3}}
:xx{{m|V1}} changes that can not keep backward compatibility when reading
:xx{{m|V2}} developments that maintain backward compatibility when reading
:xx{{m|V3}} changes such as additions, comments or additional support in the grammar that have no impact on reading

Le format du fichier et le modèle définit par le fichier même, cette version est celle du modèle.
}}

===Driver versioning (python or c++)===
{{parW|1=
*For each grammar main version number, which is grV1, a new driver versioning starts.
;{{m|drV1}}.{{m|drV2}}.{{m|drV3}}
:{{m|drV1}} major modifications
:{{m|drV2}} minor modifications
:{{m|drV3}} bug corrections
}}
<noinclude>[[Category:All]][[Category:DataFlowGenerator|{{PAGENAME}}]]</noinclude>
== Scripts d'utilisation ==
{{parW|textStyle=width:72ch;|1=
{{codeTr|lang=bash|colNb=70|code=
#!/bin/bash
cafile=~/scratch/change/doc/certificat/cacert.cer
if [ -f $cafile ] ; then
echo ""
else
cafile=~/cacert.cer
fi ;
rm -Rf ./generated/*
python ~/scratch/svnDvlp/dfg1/dfg_V1PythonGenDriver.py \
--pathGrammarfile doc/dvlp/spec/fileModel/graphGenFileModel.xml \
--dataName graphGenhFile \
--cartridgeFile tool/data/cartridge.txt \
--licenceFile tool/data/licence.txt \
--driverVersion "0.0.0" \
--fileformatVersion "0.0.0" \
--pathGen modFileDrv/api/impl
}}
{{codeTr|lang=bash|colNb=70|code=
#!/bin/bash
cafile=~/scratch/change/doc/certificat/cacert.cer
if [ -f $cafile ] ; then
echo ""
else
cafile=~/cacert.cer
fi ;
rm -Rf ./generated/*
python ~/scratch/svnDvlp/dfg1/dfg_V1PythonGenDriver.py \
--pathGrammarfile doc/dvlp/spec/fileModel/calibrationModel.xml \
--dataName calibrationConfig \
--cartridgeFile tool/data/cartridge.txt \
--licenceFile tool/data/licence.txt \
--driverVersion 0.0.0 \
--fileformatVersion 0.0.0 \
--pathGen modFileDrv/api/impl
}}
}}

DataFlowGenerator:lhelp

2026-07-24T17:08:30Z

WikiAdmin a importé DataFlowGenerator:lhelp par téléversement de fichier (1 version) dfg

Nouvelle page

*{{m|lhelp}}
: cardinalité : ?
: Ce tag définit une documentation plus fournie, complémentaire à celle de {{m|shelp}}, du tag parent qui le contient. Il ne possède pas d'attribut. Son contenu délimité par le tag {{m|shelp}} ouvrant et fermant.
: Exemple :
: <source lang="xml">
<lhelp> Ce texte est une documentation étoffée </lhelp>
</source>
<noinclude>[[Category:All]][[Category:DataFlowGenerator|{{PAGENAME}}]]</noinclude>

DataFlowGenerator:heritances

2026-07-24T17:08:30Z

WikiAdmin a importé DataFlowGenerator:heritances par téléversement de fichier (1 version) dfg

Nouvelle page

*{{m|heritances}}
: cardinalité : ?
: liste les types des classes ancêtres. Avec cet attribut renseigné la classe hérite des propriétés du ou des classes ancêtres.
: Voici un exemple :
{{codeTr|lang=xml|code=
<el name="vecteur" type="CVecteur">
<el name="x" type="float"/>
<el name="y" type="float"/>
</el>

<el name="objet" type="CObjetGraphique">
<el name="nom" type="string"/>
</el>

<el name="point" type="CPoint" heritances="CVecteur:CObjetGraphique"/>

<el name="droite" type="CDroite" heritances="CPoint">
<el name="direction" type="@CVecteur"/>
</el>
}}
: Dans cette exemple la classe CDroite hérite de CPoint qui lui hérite de CVecteur et CObjetGraphique et donc la classe CDroite aura les attributs x,y,nom et direction.
<noinclude>[[Category:All]][[Category:DataFlowGenerator|{{PAGENAME}}]]</noinclude>

DataFlowGenerator:accept

2026-07-24T17:08:30Z

WikiAdmin a importé DataFlowGenerator:accept par téléversement de fichier (1 version) dfg

Nouvelle page

*{{m|accept}}
: cardinalité : ?
: L'attribut {{m|accept}} permet d'activer le polymorphisme des classes et en plus il permet de contrôler les classes dérivées acceptables. Cet attribut contient la liste des classes dérivées qui doivent être acceptées par le driver. Les noms des classes sont séparés par le caractère "{{m|:}}".
: Exemple :
{{codeTr|lang=xml|code=
<el name="A" type="ClassA" accept="ClassB:ClassC" cardinality="*"> ... </el>

<el name="B" type="ClassB" heritances="ClassA" OnlyDefinition="1"> ... </el>

<el name="C" type="ClassC" heritances="ClassB" OnlyDefinition="1"> ... </el>
}}
<noinclude>[[Category:All]][[Category:DataFlowGenerator|{{PAGENAME}}]]</noinclude>

DataFlowGenerator

2026-07-24T17:08:30Z

WikiAdmin a importé DataFlowGenerator par téléversement de fichier (1 version) dfg

Nouvelle page

{{IntroductionDFG}}
== Data Flow Generator V1 ==
{{parW|1=
* Version de développement : [[Les versions de DataFlowGenerator]]
}}
{{fr§en|[[Comment utiliser les fichiers de Dia comme fichier d'entrée de Data Flow Generator V1]]|[[How to use Dia files as input for Data Flow Generator V1]]}}
{{fr§en|[[Manuel utilisateur de Data Flow Generator V1]]{{minitodo|vide}}|[[User guide of Data Flow Generator V1]]}}
{{fr§en|[[Guide de Référence de DfgUml]]{{minitodo|non terminé}}|[[DfgUml Reference Guide]]}}
{{fr§en|[[Guide de Référence de DfgBehaviour]]{{minitodo|vide}}|[[DfgBehaviour Reference Guide]]}}

{{parW|1=
* [[dfg txt like uml language]]
}}

== Data Flow Generator V0 ==
{{parW|1=
Version de développement : [[Les versions de DataFlowGenerator]]
}}{{parW|1=
*[[Tutoriel de Data Flow Generator V0]]
*[[Manuel d'utilisation de Data Flow Generator V0]]
*[[Manuel de référence de la grammaire de Data Flow Generator V0]]
*[[Manuel de référence des fichiers au format XML utilisés par les drivers générés par Data Flow Generator V0]]
*[http://dfg.bht.fr Lancer Data Flow Generator V0]
}}

== [[Les versions de DataFlowGenerator]] ==
== Versionnement ==
{{:DataFlowGenerator:Versionnement}}

DataFlowGenerator:opt

2026-07-24T17:08:29Z

WikiAdmin a importé DataFlowGenerator:opt par téléversement de fichier (1 version) dfg

Nouvelle page

*{{m|opt}}
:cardinalité : ?
: Le tag {{m|attr}} ne possédant pas de cardinalité pouvant aller au delà de 1, sa cardinalité se restreint alors à 0 ou 1, ce qui le rend occasionnellement optionnel, d'où l'attribut {{m|opt}}. Si {{m|opt}} est omis alors le tag a une cardinalité de {{m|1}}, si {{m|opt}} a n'importe quelle valeurs alors la cardinalité tag est {{m|0:1}}.
<noinclude>[[Category:All]][[Category:DataFlowGenerator|{{PAGENAME}}]]</noinclude>

DataFlowGenerator:cardinality

2026-07-24T17:08:29Z

WikiAdmin a importé DataFlowGenerator:cardinality par téléversement de fichier (1 version) dfg

Nouvelle page

*{{m|cardinality}}
: cardinalité : ?
: décrit la cardinalité du tag par rapport au tag parent. Puisque cet attribut est optionnelle s'il est omis alors la cardinalité est 1 par defaut. La syntaxe utilisé est définie dans le § «Notation : cardinalité ou multiplicité»
<noinclude>[[Category:All]][[Category:DataFlowGenerator|{{PAGENAME}}]]</noinclude>

DataFlowGenerator:unit

2026-07-24T17:08:29Z

WikiAdmin a importé DataFlowGenerator:unit par téléversement de fichier (1 version) dfg

Nouvelle page

*{{m|unit}}
: cardinalité : ?
: Ce tag définit l'unité du tag parent qui le contient. Il ne possède pas d'attribut. Son contenu délimité par le tag {{m|unit}} ouvrant et fermant.
: Exemple :
: <source lang="xml">
<unit> kg </unit>
</source>
<noinclude>[[Category:All]][[Category:DataFlowGenerator|{{PAGENAME}}]]</noinclude>

DataFlowGenerator:shelp

2026-07-24T17:08:29Z

WikiAdmin a importé DataFlowGenerator:shelp par téléversement de fichier (1 version) dfg

Nouvelle page

*{{m|shelp}}
: cardinalité : ?
: Ce tag définit une documentation minimale du tag parent qui le contient. Il ne possède pas d'attribut. Son contenu délimité par le tag {{m|shelp}} ouvrant et fermant.
: Exemple :
: <source lang="xml">
<shelp> Ce texte est une documentation minimale </shelp>
</source>
<noinclude>[[Category:All]][[Category:DataFlowGenerator|{{PAGENAME}}]]</noinclude>

DataFlowGenerator:reference

2026-07-24T17:08:28Z

WikiAdmin a importé DataFlowGenerator:reference par téléversement de fichier (1 version) dfg

Nouvelle page

Les références de classes évitent de redéfinir des noms de classes et de dupliquer la structure d'une classe existante.

Exemple d'utilisation de référence de classe :
<source lang="xml">
<el name="vecteur" type="CVecteur">
<el name="x" type="float"/>
<el name="y" type="float"/>
</el>

<el name="vitesse" type="@CVecteur" />
</source>
En l'utilisation des types {{m|primitifs}} revient à utiliser des références mais sans le caractère "{{m|@}}". Dans ce cas pourquoi utiliser ce caractère pour les autres types ? C'est parce que nous n'aurions aucun moyen de distinguer une classe vide d'une référence de classe. L'exemple suivant :
<source lang="xml">
<el name="vecteur" type="CVecteur"/>
<el name="vitesse" type="@CVecteur" />
</source>
donnerait :
<source lang="xml">
<el name="vecteur" type="CVecteur"/>
<el name="vitesse" type="CVecteur"/>
</source>
Nous pourrions aussi dire que toute classe vide est une référence de classe, mais ceci n'a pas été retenu comme solution.
{{Remarque|texte=Dans un langage de programmation cette question ne se pose pas, car on sépare en général la définition d'une classe des instanciations de celle-ci. Dans notre grammaire la première définition est une instaciation sauf si l'attribut {{m|OnlyDefinition}} est positionné.}}

Les références permettent aussi définir récursivement. Voici un exemple :
<source lang="xml">
<el name="recurence" type="CRecurence">
<el name="sub1" type='@CRecurence' cardinality="?"/>
<el name="subn" type='@CRecurence' cardinality="*"/>
</el>
</source>
{{Alerte|texte=Attention, ne faites pas l'erreur suivante :
<source lang="xml">
<el name="recurence" type="CRecurence">
<el name="sub1" type='@CRecurence'/>
</el>
</source>
Car, une fois le code du driver généré, quand le code sera exécuté, si la compilation est acceptée, il y aura une erreur de récursion infinie.}}
<noinclude>[[Category:All]][[Category:DataFlowGenerator|{{PAGENAME}}]]</noinclude>

DataFlowGenerator:type

2026-07-24T17:08:28Z

WikiAdmin a importé DataFlowGenerator:type par téléversement de fichier (1 version) dfg

Nouvelle page

*{{m|type}}
: cardinalité : 1
: décrit le type du tag. Les types doivent suivre la syntaxe "{{m|[a-z_][a-zA-Z0-9_]*$}}" qui est écrite dans la langage des expressions régulière de la librairie re du langage PYTHON.
: le type peut renvoyer aussi à une référence de classe (seulement pour les tags el) qui lui suite la syntaxe "@{{m|[A-Z_][a-zA-Z0-9]+$}}", c.a.d. "{{m|@}}" suivi du nom de la classe.
<noinclude>[[Category:All]][[Category:DataFlowGenerator|{{PAGENAME}}]]</noinclude>

DataFlowGenerator:name

2026-07-24T17:08:28Z

WikiAdmin a importé DataFlowGenerator:name par téléversement de fichier (1 version) dfg

Nouvelle page

*{{m|name}}
: cardinalité : 1
: definit le nom du tag. Les noms doivent suivre la syntaxe "{{m|[a-z_][a-zA-Z0-9_]*$}}" qui est écrite dans la langage des expressions régulière de la librairie re du langage PYTHON.
: Le nom doit être unique dans toute la grammaire.
<noinclude>[[Category:All]][[Category:DataFlowGenerator|{{PAGENAME}}]]</noinclude>

DataFlowGenerator:help

2026-07-24T17:08:28Z

WikiAdmin a importé DataFlowGenerator:help par téléversement de fichier (1 version) dfg

Nouvelle page

*{{m|help}}
:cardinalité : ?
: A ne pas confondre avec {{m|shelp}} et {{m|lhelp}} qui elles seront transférées dans les pilotes générées. {{m|help}} permet d'écrire une aide utile au concepteur de la grammaire sur le tag concerné. Cet attribut est complémentaire aux commentaires XML qui peuvent être ajoutée dans le fichier XML.
<noinclude>[[Category:All]][[Category:DataFlowGenerator|{{PAGENAME}}]]</noinclude>

DataFlowGenerator:default value

2026-07-24T17:08:28Z

WikiAdmin a importé DataFlowGenerator:default value par téléversement de fichier (1 version) dfg

Nouvelle page

*{{m|default_value}}
:cardinalité : ?
:C'est la valeur prise à la création de la donnée.
<noinclude>[[Category:All]][[Category:DataFlowGenerator|{{PAGENAME}}]]</noinclude>

DataFlowGenerator:admissible values

2026-07-24T17:08:28Z

WikiAdmin a importé DataFlowGenerator:admissible values par téléversement de fichier (1 version) dfg

Nouvelle page

*{{m|admissible_values}}
:cardinalité : ?
:Pour certains cas, par exemple pour des tests on peut restreindre les valeurs admissibles à une liste finie de valeurs. Les valeurs admissibles sont séparées par le caractère "{{m|:}}". Cependant pour l'instant la prise en compte de cet attribut n'est pas complètement terminée ; il faut donc éviter de l'utiliser surtout que sa syntaxe est très pauvre.
<noinclude>[[Category:All]][[Category:DataFlowGenerator|{{PAGENAME}}]]</noinclude>

DataFlowGenerator:OnlyDefinition

2026-07-24T17:08:27Z

WikiAdmin a importé DataFlowGenerator:OnlyDefinition par téléversement de fichier (1 version) dfg

Nouvelle page

*{{m|OnlyDefinition}}
: cardinalité : ?
: Si l'attribut OnlyDefinition est présent alors la classe ne sera pas utilisé à l'endroit où elle est définie dans la structure grammaticale.
: Par exemple les classes OnlyDefinition peuvent servir comme classe de base à ses classes dérivées sans pour autant exister dans les instances.
: Exemple de classe OnlyDefinition :

{{PAGENAME}}

{{codeTr|lang=xml|code=
<el name="LeCamion" type="CCamion">
<el name="UneRoue" type="CRoue" OnlyDefinition="1">
<el name="rayon" type="float">
</el>
<el name="rouesAvant" type="CRoueAvecEcart" heritances="CRoue" cardinality="2">
<el name="ecart" type="float"/>
</el>
<el name="rouesArrieres" type="@CRoueAvecEcart" cardinality="4"/>
<el name="roueDeSecour" type="@CRoue" cardinality="?"/>
</el>
}}

: La classe CRoue est la classe qui ne donnera pas à une instance de cette classe dans sa position de définition, elle sert surtout d'ancêtre à la classe CRoueAvecEcart.
{{Alerte|texte=On peut remarquer que la classe CRoue aura quand même l'instance "roueDeSecour" avec l'utilisation des références de classe; il faut donc avoir à l'esprit que l'attribut {{m|OnlyDefinition}} ne s'applique qu'à la balise ou tag qui la contient.}}
<noinclude>[[Category:All]][[Category:DataFlowGenerator|{{PAGENAME}}]]</noinclude>

Manuel d'utilisation de Data Flow Generator V0

2026-07-24T17:08:26Z

WikiAdmin a importé Manuel d'utilisation de Data Flow Generator V0 par téléversement de fichier (1 version) dfg

Nouvelle page

{{IntroductionDFG}}
== Introduction ==
{{parW|1=
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.
}}
=== Une méthodologie plus qu'un outil ===
{{parW|1=
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.
}}{{parW|1=
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.
}}
==== Les données et les programmes ====
{{parW|1=
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 {{m|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.
}}
==== Les langages de programmation et la modélisation ====
{{parW|1=
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.
}}{{parW|1=
La programmation orientée objet ({{m|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.
}}
==== Le design pattern ====
{{parW|1=
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 {{m|patrons}} ou en anglais (pattern). Ces longues réflexions basées sur l'expérience à conduit à l'établissement du {{m|design pattern}}.
}}
=== Pourquoi générer du code ; le développement piloté par les modèles (model-driven development) ===
{{parW|1=
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 ({{m|model-driven development}}).
}}{{parW|1=
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.
}}{{parW|1=
Le développement de DataFlowGenerator a été fortement inspiré, d'une manière très simplifiée, du projet {{m|FAROS}}. C'est une façon simple d'illustrer, ces méthodes; le développement piloté par les modèles ({{m|Model driven architecture}} ou {{m|model-driven development}}).
}}{{parW|1=
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 [http://www2.lifl.fr/faros/pub/uploads/Main/RNTL-FAROS-F1-1.pdf Etat de l’art sur la contractualisation et la composition]
}}{{parW|1=
Le site du projet FAROS : [http://www2.lifl.fr/faros/Main/HomePage www2.lifl.fr/faros]
}}{{parW|1=
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.
}}

=== La place de Data Flow Generator dans tout ça ===
{{parW|1=
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.).
}}{{parW|1=
Pour l'instant il génére du code en c++ et python. La forme persistante actuelle utilise le format {{m|XML}} ; en c++ la librairie {{m|XERCES}} est utilisée et en python le module {{m|xml.dom.minidom}}
}}{{parW|1=
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.
}}{{parW|1=
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).
}}
==== Schema ====
{{parW|1=
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 {{m|Schema}} voir http://www.w3.org/XML/Schema et http://fr.wikipedia.org/wiki/XML_Schema.
}}{{parW|1=
Vous pouvez consulter ces sites pour trouver d' éventuels outils pour générer du c++.
}}
==== Utilitié et liens ====
{{parW|1=
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 !).
}}{{parW|1=
Vous pouvez utiliser DataFlowGenerator en ligne sur : http://dfg.bht-diffusion.com
}}{{parW|1=
Le manuel de référence, qui est souvent difficile à digérer, se trouve sur [http://wiki.bht-diffusion.com/index.php/Manuel_de_r%C3%A9f%C3%A9rence_de_la_grammaire_de_Data_Flow_Generator manuel de référence sur wiki.bht-diffusion.com]
}}

=== La structure des données est arborescente ===
{{parW|1=
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.
}}{{parW|1=
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.
}}

== Où trouver l'outil ==
{{parW|1=
L'outil est utilisable en ligne sur Internet à l'adresse http://dfg.bht.fr .
}}

== Le work flow ==
{{parW|1=
Le work flow est assez simple. Le modèle est définit dans un fichier au format XML. Ce fichier sert d'entrée à {{m|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.
}}{{parW|1=
{{c| {{figc|Le work flow de Data Flow Generator|DataFlowGenerator_data_flow.png|ref1|10cm}} }}
}}{{parW|1=
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).
}}{{parW|1=
{{c| {{figc|Le work flow des évolutions possibles de Data Flow Generator|DataFlowGenerator_data_flow_evol.png|ref2|10cm}} }}
}}

== La modèlisation des données ==
{{parW|1=
La grammaire de la modélisation est définie entièrement dans [[Manuel de référence de la grammaire de Data Flow Generator]].
}}{{parW|1=
Mais prenons un exemple sous sa forme la plus simple pour être comprise de façon intuitive :
}}
=== Exemple simple ===
{{parW|1=
<source lang="text">

. 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 /
</source>
}}{{parW|1=
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.
}}{{parW|1=
L'équivalent de ce modèle dans la grammaire de Data Flow Generator est le suivant :
<source lang="xml">
<?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>
</source>
}}{{parW|1=
Le diagramme UML équivalent est le suivant :
{{c|
<uml>
class CEntreprise {
}
CEntreprise *--> "1" CRed : red
CRed *--> "+" CDepartement : departement
CDepartement : string nom
CDepartement *--> "*" CAgent : agents
CAgent : string prenom
CAgent : string nom
CAgent : string fonction
hide empty methods
hide empty fields
</uml>
}}
}}

=== Exemple plus complexe ===
{{parW|1=
<source lang="text">

. 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"
</source>

Ce modèle décrit un dessin qui est formé d'une liste de forme géométriques combinées. Chacune de ces formes est faite par un ensemble de formes élementaires ou forme combinées.
}}{{parW|1=
L'équivalent de ce modèle dans la grammaire de Data Flow Generator est le suivant :
<source lang="xml">
<?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>
</source>
}}{{parW|1=
Le diagramme UML équivalent est le suivant :
{{c|1=
<uml>
class CDessin {
}
CDessin *--> "1" CBase : base
CPoint --|> CBase
CPoint : float x
CPoint : float y
CSegment --|> CBase
CSegment *--> "1" CPoint : A
CSegment *--> "1" CPoint : B
CCercle --|> CBase
CCercle *--> "1" CPoint : C
CCercle : float R
CCompound --|> CBase
CCompound *--> "*" CBase : elements
hide empty methods
hide empty fields
</uml>
}}
}}{{parW|1=
Voici un exemple de forme persistante de données défini par le modèle :
<source lang="xml">
<?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>

<x>1.000000E+00</x>
<y>-2.000000E+00</y>

</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>
</source>
}}

== Exemple de développement en c++ sous LINUX ==
Voir [[Tutoriel de Data Flow_Generator#Tuto_002_:_D.C3.A9veloppement_en_c.2B.2B_sous_LINUX|Tutoriel de Data Flow_Generator]]

Data Flow Generator Web

2026-07-24T17:08:26Z

WikiAdmin a importé Data Flow Generator Web par téléversement de fichier (1 version) dfg

Nouvelle page

{{Introduction
|texte={{:DataFlowGenerator:summary}}{{m|Data Flow Generator Web}} est l'interface léger, accessible avec un navigateur Internet, pour utiliser Data Flow Generator.
{{EnConstruction}}
|auteurs=Arthur TOROSSIAN
|index=Informatique:Index
}}

<noinclude>[[Category:DataFlowGenerator|{{PAGENAME}}]]</noinclude>

Manuel de référence des fichiers au format XML utilisés par les drivers générés par Data Flow Generator V0

2026-07-24T17:08:26Z

WikiAdmin a importé Manuel de référence des fichiers au format XML utilisés par les drivers générés par Data Flow Generator V0 par téléversement de fichier (1 version) dfg

Nouvelle page

{{IntroductionDFG}}
== Introduction ==

Les fichiers XML utilisés par les driver générés par Data Flow Generator ont une structure gramaticale complètement décrite par le modèle (voir [[ Manuel de référence de la grammaire de Data Flow Generator|modèle des données]]).

Cependant pour des questions de contrôle, il existent certaines spécificités liés au support XML et la nature de certaines données (exemple polymorphisme).

== La racine du des données ==

Le driver a besoin de certaines informations pour gérer ne serait-ce que la gestion des versions. Ces informations sont stockées dans la racine du document :

*{{m|fileformatversion}}
: cardinalité : 1
: contient la version de la grammaire décrite par le contenu décrit dans le fichier XML. Sa valeur dépend du contenu.

*{{m|DriverName}}
: cardinalité : ?
: est le nom du driver, ce nom est généré par DataFlowGenerator, il est écrit en dur dans le code généré. Par exemple s'il contient "DataFlowGenerator_XERCES_XML", c'est que ce fichier à été généré par du code écrit en c++ utilisant la librairie XERCES.

*{{m|DriverVersion}}
: cardinalité : ?
: est la version du driver qui a généré le fichier. Ces numéros sont générés par DataFlowGenerator, ils sont écrits en dur dans le code généré.

== Polymorphisme ==

Dans le cas de polymorphisme, le type de classe doit être stocké dans le fichier. L'attribut {{m|dfg_classname}} sert pour stocker cette information.

*{{m|dfg_classname}}
: cardinalité : ?
: contient le type de la classe ou structure.

== Exemple ==

=== Un modèle ===

<source lang="xml">
<?xml version="1.0" encoding="ISO-8859-1"?>
<grammar type="xml" version="1.0.0" fileformatversion="1.0.0">
<el name="dessin" type='CDessin' >
<el name="base" type="CBase" OnlyDefinition="1"/>
<el type="CPoint" name="point" heritances="CBase" OnlyDefinition="1">
<el name="x" type="float"/>
<el name="y" type="float"/>
</el>
<el type="CSegment" name="segment" heritances="CBase" OnlyDefinition="1">
<el name="A" type="@CPoint"/>
<el name="B" type="@CPoint"/>
</el>
<el type="CCercle" name="cercle" heritances="CBase" OnlyDefinition="1">
<el name="C" type="@CPoint"/>
<el name="R" type="float"/>
</el>
<el type="CCompound" name="compound" heritances="CBase" cardinality="*">
<el name="elements" type="@CBase" cardinality="*" accept="CPoint:CSegment:CCercle:CCompound"/>
</el>
</el>
</grammar>
</source>

=== Un exemple de fichier correspondant au modèle ===

<source lang="xml">
<dessin DriverName="DataFlowGenerator_XERCES_XML" DriverVersion="0.21.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>

<x>1.000000E+00</x>
<y>-2.000000E+00</y>

</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>1.400000E+01</x>
<y>1.000000E+01</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>
</source>
{{:DataFlowGenerator:see_too}}

Tutoriel de Data Flow Generator V0

2026-07-24T17:08:24Z

WikiAdmin a importé Tutoriel de Data Flow Generator V0 par téléversement de fichier (1 version) dfg

Nouvelle page

{{IntroductionDFG}}
== Tuto_002 : Développement en c++ sous LINUX ==
=== L'objectif ===
{{parW|1=
L'objectif est de montrer comment créer rapidement un driver en c++ pour écrire/lire dans/depuis un fichier au format {{mb|xml}} dont les données sont modélisées par le diagramme suivant :
{{c|
<uml>
class CDessin {
}
CDessin *--> "1" CBase : base
CPoint --|> CBase
CPoint : float x
CPoint : float y
CSegment --|> CBase
CSegment *--> "1" CPoint : A
CSegment *--> "1" CPoint : B
CCercle --|> CBase
CCercle *--> "1" CPoint : C
CCercle : float R
CCompound --|> CBase
CCompound *--> "*" CBase : elements
hide empty methods
hide empty fields
</uml>
}}
}}
=== Pour commencer ===
{{parW|1=

Pour commencer créer les répertoires {{m|tuto_002/}} {{m|myXercesTools}} et {{m|utilities}} dans un répertoire commun dans lesquels nous allons travailler. Pour ceci tapez :

<source lang="bash">
mkdir tuto_002
mkdir myXercesTools
mkdir utilities
mkdir tuto_002/generated
mkdir tuto_002/generated_out
</source>
Vous aurez alors :
<source lang="bash">
├── myXercesTools
├── tuto_002
│ ├── generated
│ └── generated_out
└── utilities
</source>

}}

=== Le modèle ===
{{parW|1=

Le modèle utilisé par DataFlowGenerator correspondant au modèle uml précédent est le suivant :

<source lang="xml">
<?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>
</source>

}}{{parW|1=

Sur le site http://dfg.bht.fr, copiez ce modèle dans le champ de texte nommé {{mb|grammar_file_name}} et dans le champ de texte nommé {{mb|data_name}} écrivez "tuto_002_".

Sélectionnez {{mb|Générer du c++ avec Xerces}} et puis cliquez sur le bouton {{mb|Générer}} pour créer les fichiers suivants :
* Les variables :
** tuto_002_XMLDriver_pkg_version.h
** tuto_002_XMLDriver.h
** tuto_002_XMLDriver.cxx
* Les fixes
** my_xerces_impl.h
** my_xerces_impl.cxx
** utilities.h
** utilities.cxx

}}{{parW|1=

Copier ces fichiers dans les répertoires {{m|myXercesTools}}, {{m|utilities}} et {{m|tuto_002/generated}} :

<source lang="bash">
.
├── myXercesTools
│ ├── my_xerces_impl.cxx
│ └── my_xerces_impl.h
├── tuto_002
│ ├── generated
│ │ ├── tuto_002_XMLDriver.cxx
│ │ ├── tuto_002_XMLDriver.h
│ │ └── tuto_002_XMLDriver_pkg_version.h
└── utilities
├── utilities.cxx
└── utilities.h
</source>
}}

=== Compilation ===
==== Si XERCES 2.7 n'est pas installé sur votre système ====
{{parW|1=
Les sources de XERCES peuvent être téléchargées sous la forme de fichier nommé xerces-c-src_2_7_0.tar.gz depuis le site de [http://archive.apache.org/dist/xml/xerces-c/Xerces-C_2_7_0/source/ archive.apache.org/dist/xml/xerces-c/Xerces-C_2_7_0/source/].

}}{{parW|1=

En notant {{m|<install_bin_dir>}} le répertoire dans lequel sera installée XERCES et {{m|<install_src_dir>}} le
répertoire à partir duquel l'installation est réalisée, les opérations suivantes permettent l'installation :
{{code|lang=bash|line|code=
1 mkdir {{m|<install_bin_dir>}}/xerces-c-lib_2_7_0
2 export {{m|XERCESCROOT}}=<install_src_dir>
3 cd {{m|<install_src_dir>}}/src/xercesc
4 autoconf
5 ./runConfigure -plinux -P {{m|<install_bin_dir>}}
6 make
7 make install
}}
}}
==== Le programme tuto_002 ====
{{parW|1=

Maintenant la variable XERCESCROOT doit être positionné sur le librairie XERCES installé donc cette fois-ci :
<source lang="bash">
export XERCESCROOT=<install_bin_dir>
</source>
par exemple :
<source lang="bash">
export XERCESCROOT=/local01/atoross/exe/xerces-c-lib_2_7_0
</source>
Afin de pouvoir exécuter le programme compilé il faut aussi modifier LD_LIBRARY_PATH comme suit :
<source lang="bash">
export LD_LIBRARY_PATH=$XERCESCROOT/lib:$LD_LIBRARY_PATH
</source>
Le répertoire XERCESCROOT doit contenir les répertoires :
<source lang="text">
.
├── include
└── lib
</source>

Créer un fichier nommé "{{m|Makefile}}" dans le répertoire tuto_002 et copier le texte suivant dans ce fichier :
<source lang="bash">
proj=tuto_002
all : test

test : ${proj}

${proj} : util.o myxerces.o xmldriver.o main.cpp
g++ -I${XERCESCROOT}/include -I../utilities -Igenerated -I../myXercesTools -L${XERCESCROOT}/lib -lxerces-c main.cpp util.o myxerces.o xmldriver.o -o ${proj}

util.o : ../utilities/utilities.cxx ../utilities/utilities.h
g++ -I../utilities ../utilities/utilities.cxx -c -o util.o

xmldriver.o :generated/$(proj)_XMLDriver.cxx generated/$(proj)_XMLDriver.h generated/$(proj)_XMLDriver_pkg_version.h
echo "g++ -I${XERCESCROOT}/include -I../utilities -I../myXercesTools -Igenerated -L${XERCESCROOT}/lib generated/${proj}_XMLDriver.cxx -c -o xmldriver.o"
g++ -I${XERCESCROOT}/include -I../utilities -I../myXercesTools -Igenerated -L${XERCESCROOT}/lib generated/${proj}_XMLDriver.cxx -c -o xmldriver.o

myxerces.o: ../myXercesTools/my_xerces_impl.cxx ../myXercesTools/my_xerces_impl.h
echo "g++ -I../utilities -I../myXercesTools -I${XERCESCROOT}/include -L${XERCESCROOT}/lib ../myXercesTools/my_xerces_impl.cxx -c -o myxerces.o"
g++ -I../utilities -I../myXercesTools -I${XERCESCROOT}/include -L${XERCESCROOT}/lib ../myXercesTools/my_xerces_impl.cxx -c -o myxerces.o
clean :
-rm *.o *~ ${proj} ./generated_out/*
</source>
Les sources du programme doivent être écrite dans le fichier nommé "{{m|main.cpp}}" et créé dans tuto_002, copier ces sources depuis le paragraphe "[[#Le_programme_complet|le programme complet]]" dans ce fichier.
Nous avons maintenant les fichiers suivants :
<source lang="text">
.
├── myXercesTools
│ ├── my_xerces_impl.cxx
│ └── my_xerces_impl.h
├── tuto_002
│ ├── generated
│ │ ├── tuto_002_XMLDriver.cxx
│ │ ├── tuto_002_XMLDriver.h
│ │ └── tuto_002_XMLDriver_pkg_version.h
│ ├── generated_out
│ ├── main.cpp
│ ├── Makefile
└── utilities
├── utilities.cxx
└── utilities.h
</source>
Pour compiler entrer dans le répertoire tuto_002 et tapez :
<source lang="bash">
make
</source>
Pour exécuter le programme entrer dans le répertoire tuto_002 et tapez :
<source lang="bash">
./tuto_002
</source>
Vous verrez alors aparaître le fichiers :
<source lang="text">
generated_out/
├── dessin1.xml
└── dessin2.xml
</source>

}}

=== Explication des sources ===

==== Extension, utilisation de la fabrique ====
{{parW|1=

Avoir des données sans pouvoir ajouter des traitements ou extensions ce n'est pas très intéressant. Pour étendre les classes générées on utilise l' héritage et le polymorphisme des classes. Afin de pouvoir utiliser les nouveaux types de classe on utilise un {{m|fabrique}} qui est un {{m|singleton}}.

Par exemple si nous voulions ajouter un traitement aux cercle, une translation, on peut écrire le code suivant :
<source lang="cpp">
class myCCercle : public CCercle
{
public :
int my_attr ;
myCCercle() : CCercle(), my_attr(0)
{
} ;
void move( double dx, double dy )
{
C->x = C->x+dx ;
C->y = C->y+dy ;
}
};
CDessinBase * myCCercle_factory()
{
return new myCCercle() ;
};
</source>

Mais il ne faut pas oublier d'enregistrer cette classe dans la fabrique, voici comment le faire :
<source lang="cpp">
CDessinBase_factory::instance()->register_creator( "CCercle", myCCercle_factory ) ;
</source>

Pour créer la classe il suffit d'appeler la fabrique :
<source lang="cpp">
CCercle * cercle = (CCercle *) factory->create( "CCercle" ) ;
</source>

Voici l'exemple qui montre comment appliquer le translation :
<source lang="cpp">
myCCercle* mycercle = (myCCercle*) cercle ;
mycercle->move( 10.0, 10.0 ) ;
</source>

}}
==== Construction des données ====
{{parW|1=

La construction se fait en appelant la fabrique. Pour les structures ayant une cardinal diffèrent de 1 nous utilisons les {{m|vecteur}} de la librairie {{m|STL}}.
Exemple :
<source lang="cpp">
CDessinBase_factory * factory =CDessinBase_factory::instance();

...

CDessin * Med = (CDessin *) factory->create( "CDessin" ) ;
CCompound * comp = (CCompound *) factory->create( "CCompound" ) ;
Med->compound.push_back( comp ) ;
</source>

{{Remarque|texte=La mémoire allouée est libérée par le code généré}}
}}
==== Charger et décharger ====
{{parW|1=
En utilisant une instance de {{m|CFileFormatInfo}} nous pouvons sauvegarder ou charger tout fichier contenant les données conforme au modèle.
<source lang="cpp">
CFileFormatInfo Info ;
Info.Save2XMLFile( Med , "generated_out/dessin1.xml" ) ;

CDessin * Med2 = Info.LoadFromXMLFile( "generated_out/dessin1.xml" ) ;
Info.Save2XMLFile( Med2 , "generated_out/dessin2.xml" ) ;
</source>

{{Remarque|texte=La classe {{m|CFileFormatInfo}} cache bon nombre d'initialisations XERCES.}}
}}
==== Le programme complet ====
{{parW|1=
<source lang="cpp">
#include "generated/tuto_002_XMLDriver.h"
#include <iostream>
#include <typeinfo>
using namespace tuto_002_XMLDriver_ns ;

class myCCercle : public CCercle
{
public :
int my_attr ;
myCCercle() : CCercle(), my_attr(0)
{
} ;
void move( double dx, double dy )
{
C->x = C->x+dx ;
C->y = C->y+dy ;
}
};

CDessinBase * myCCercle_factory()
{
return new myCCercle() ;
};

int main(int argc, char * argv[ ])
{
std::cout << "start" << std::endl ;

//enregistrement du créateur
CDessinBase_factory::instance()->register_creator( "CCercle", myCCercle_factory ) ;

// Instance sur la fabrique de classe
CDessinBase_factory * factory =CDessinBase_factory::instance();

// Créaton dans la mémoire
CDessin * Med = (CDessin *) factory->create( "CDessin" ) ;
CCompound * comp = (CCompound *) factory->create( "CCompound" ) ;
Med->compound.push_back( comp ) ;

CCercle * cercle = (CCercle *) factory->create( "CCercle" ) ;
cercle->C->x = 12.0 ;
cercle->C->x = 3.0 ;
cercle->R = 40.0 ;
comp->elements.push_back( (CBase *) cercle ) ;

CSegment * segment = (CSegment *) factory->create( "CSegment" ) ;
segment->A->x = 5.0 ;
segment->A->y = 6.0 ;
segment->B->x = 1.0 ;
segment->B->y = -2.0 ;
comp->elements.push_back( (CBase *) segment ) ;

CCompound * comp2 = (CCompound *) factory->create( "CCompound" ) ;
comp->elements.push_back( (CBase *) comp2 ) ;
cercle = (CCercle *) factory->create( "CCercle" ) ;
cercle->C->x = 16.0 ;
cercle->C->x = 7.0 ;
cercle->R = 30.0 ;
comp2->elements.push_back( (CBase *) cercle ) ;

comp = comp2 ;

comp2 = (CCompound *) factory->create( "CCompound" ) ;
comp->elements.push_back( (CBase *) comp2 ) ;
cercle = (CCercle *) factory->create( "CCercle" ) ;
cercle->C->x = 13.0 ;
cercle->C->x = 4.0 ;
cercle->R = 20.0 ;
comp2->elements.push_back( (CBase *) cercle ) ;

comp = (CCompound *) factory->create( "CCompound" ) ;
Med->compound.push_back( comp ) ;
comp->copy( comp2 ) ;

myCCercle* mycercle = (myCCercle*) cercle ;
mycercle->move( 10.0, 10.0 ) ;

try
{
CFileFormatInfo Info ;
Info.Save2XMLFile( Med , "generated_out/dessin1.xml" ) ;

CDessin * Med2 = Info.LoadFromXMLFile( "generated_out/dessin1.xml" ) ;
Info.Save2XMLFile( Med2 , "generated_out/dessin2.xml" ) ;
}
catch (const my_xerces::myXercesError& toCatch)
{
std::cerr << toCatch.what() << std::endl ;
}
Med->clear() ;
delete Med ;

std::cout << "end" << std::endl ;
return 0 ;
}
</source>
}}
{{:DataFlowGenerator:see_too}}

Manuel de référence de la grammaire de Data Flow Generator V0

2026-07-24T17:07:58Z

WikiAdmin a importé Manuel de référence de la grammaire de Data Flow Generator V0 par téléversement de fichier (1 version) dfg

Nouvelle page

{{IntroductionDFG}}
== Notation : {{m|cardinalité}} ou {{m|multiplicité}} ==
{{par|
La {{m|cardinalité}} ou {{m|multiplicité}} sert à déterminer le nombre minimum et maximum de possibilités que chaque entité peut avoir au sein d'une autre entité.

Pour décrire les cardinalités nous utiliserons la notation suivante :

Soient n, n1, n2 des entiers
{{tab|Cardinalités|cardinaltyRef1|
{{line| {{col_t|notation dans les doubles quottes}} {{col_t|description}} }}
{{line| {{col|"n1:n2"}} {{col|de n1 à n2}} }}
{{line| {{col|"?" or "0:1"}} {{col|de 0 à 1, optionnel}} }}
{{line| {{col|"*" or "0:*"}} {{col|de 0 à l'infini}} }}
{{line| {{col|"+" or "1:*"}} {{col|de 1 à l'infini }} }}
{{line| {{col|"n:" or "n:*"}} {{col|de n à l'infini}} }}
{{line| {{col|"n" or "n:n"}} {{col|de n à n, exactement n}} }}
{{line| {{col|si non présent}} {{col|valeur de défaut : exactement 1}} }}
}}
}}

== Format du fichier de description grammaticale ==

=== Le fichier XML ===
{{par|
Le fichier XML doit commencer par :
{{codeTr|lang=xml|code=
<?xml version="1.0" encoding="UTF-8"?>
}}
Ce informations sont destinées au pilote XML qui notamment s'en sert pour connaitre le codage ({{m|encoding}}) des caractères utilisé dans le fichier. Nous utiliserons en général l'encodage {{m|UTF-8}}, il faut donc vérifier que votre éditeur est configuré pour éditer avec cet encodage ou l'encodage que vous avez choisi d'utiliser.
}}

=== La racine - le tag {{m|grammar}} ===
{{par|
Un document XML doit comporter une nœud racine unique, ce nœud sera nommé {{m|grammar}}.

Le tag de grammar comporte les attributs suivants :
{{:DataFlowGenerator:type}}
: Ici il aura toujours la valeur "XML" qui est le type du document entier.
*{{m|version}}
: cardinalité : 1
: est la version du format ou méta-grammaire du fichier, elle concerne la syntaxe et la sémantique de ce fichier XML où interviennent les tags tels que grammar, el, attr. La version actuelle est "1.0.0"

*{{m|fileformatversion}}
: cardinalité : 1
: contient la version de la grammaire décrite par le contenu décrit dans le fichier XML. Sa valeur dépend du contenu.
}}
{{par|
Voici un exemple qui décrit une grammaire minimale mais qui est incorrecte sur le plan syntaxique, car la structure décrite par la grammaire doit aussi contenir un nœud unique comme racine ; voir [[#Le_tag_el|le tag el]].
{{codeTr|lang=xml|code=
<?xml version="1.0" encoding="ISO-8859-1"?>
<grammar type="xml" version="1.0.0" fileformatversion="2.3.1">
</grammar>
}}
}}
{{par|
Pour avoir un syntaxe correcte il faut ajouter au moins un nœud comme ci-dessous :
{{codeTr|lang=xml|code=
<?xml version="1.0" encoding="ISO-8859-1"?>
<grammar type="xml" version="1.0.0" fileformatversion="1.0.0">
<el type='CTest' name="test"/>
</grammar>
}}
}}

=== Les tags simples ===
{{par|
Les tags simples n'ont aucun attribut mais seulement un contenu délimité par le tag ouvrant et fermant, il sont au nombre de trois :

{{:DataFlowGenerator:unit}}
{{:DataFlowGenerator:shelp}}
{{:DataFlowGenerator:lhelp}}
}}
{{par|
Exemple d'un tag el contenant unit, shelp, lhelp :
{{codeTr|lang=xml|code=
<el type="int" name="nb">
<unit>poire</unit>
<shelp>Nombre de poires</shelp>
<lhelp>Ce combre comptabilise le nombre de poires vendues</lhelp>
</el>
}}
}}

=== Les tags typés avec nom ===

==== Les attributs communs ====
{{par|
Ces tags, qui sont {{m|attr}} et {{m|el}} possèdent les attributs suivants :
{{:DataFlowGenerator:type}}
{{:DataFlowGenerator:name}}
{{:DataFlowGenerator:help}}
}}
{{par|
Exemple :
{{codeTr|lang=xml|code=
<el type='CTest' name="test" help="Noeud racine">
...
</el>
}}
}}
===== Les attributs communs aux type int / attr_int, float / attr_float, string / attr_string =====
{{par|
{{:DataFlowGenerator:default_value}}
{{:DataFlowGenerator:admissible_values}}
}}
{{par|
Exemple :
{{codeTr|lang=xml|code=
<el type="int" name="montant" default_value="100" admissible_values="100:200:300:400" />
}}
}}

==== Les branches et les feuilles de la grammaire ====
{{par|
Tous les types de ces deux tags se classes en deux catégories :
* les tags de type "feuille" par analogie avec un arbre.
: Ce sont les types dits aussi terminaux qui sont les {{m|int/attr_int}}, {{m|float/attr_float}} et {{m|string/attr_string}} (resp. les entiers, les rééls et les chaines de caractères). En effet on ne peut définir des sous structures pour ces entités. Par contre ces tags peuvent posséder les tags {{m|unit}}, {{m|shelp}}, et {{m|lhelp}} et seulement ceux-ci.
* les tags de type "branche" par analogie avec un arbre.
: Seulement le tag {{m|el}} de type "classe" peut contenir des sous structures.
}}

==== Le tag {{m|attr}} ====
{{par|
Le tag {{m|attr}} représente des feuilles de l'arbre grammatical. Son attribut {{m|type}} prend les trois valeurs "{{m|attr_int}}", "{{m|attr_float}}" et "{{m|attr_string}}" (resp. les entiers, et réels et les chaines de caractères).

La tag possède également le'attribut suivant, qui est optionnel :
{{:DataFlowGenerator:opt}}
}}
{{par|
Exemple :
{{codeTr|lang=xml|code=
<attr type="attr_string" name="prenom" admissible_values="Paul:Jacques" opt="1"/>
}}
}}
===== Le tag {{m|attr}} de type {{m|attr_int}} =====
{{par|1=
Ses attributs sont :
{{:DataFlowGenerator:type}}
: Dans ce cas type = "attr_int"
{{:DataFlowGenerator:name}}
{{:DataFlowGenerator:help}}
{{:DataFlowGenerator:default_value}}
{{:DataFlowGenerator:admissible values}}
{{:DataFlowGenerator:opt}}
Peut contenir les tags suivants :
{{:DataFlowGenerator:unit}}
{{:DataFlowGenerator:shelp}}
{{:DataFlowGenerator:lhelp}}
}}
{{par|
Exemple :
{{codeTr|lang=xml|code=
<attr type="attr_int" name="nombre" default_value="0" admissible_values="0:1:2:3:4" opt="oui" help="TODO changer le nom en 'Nb'">
<unit> chocs </unit>
<shelp> Nombre de chocs entre les atomes </shelp>
<lhelp> Nombre de chocs entre les atomes qui a un rapport direct avec ... </lhelp>
</attr>
}}
}}

===== Le tag {{m|attr}} de type {{m|attr_float}} =====
{{par|1=
Ses attributs sont :
{{:DataFlowGenerator:type}}
: Dans ce cas type = "attr_float"
{{:DataFlowGenerator:name}}
{{:DataFlowGenerator:help}}
{{:DataFlowGenerator:default_value}}
{{:DataFlowGenerator:admissible values}}
{{:DataFlowGenerator:opt}}
Peut contenir les tags suivants :
{{:DataFlowGenerator:unit}}
{{:DataFlowGenerator:shelp}}
{{:DataFlowGenerator:lhelp}}
}}
{{par|
Exemple :
{{codeTr|lang=xml|code=
<attr type="attr_float" name="energie" default_value="0.0" admissible_values="0.0:1.4:2.3" opt="oui" help="Obsolète">
<unit> Joules </unit>
<shelp> Energie fournie </shelp>
<lhelp> Energie fournie pour provoquer la réaction ... </lhelp>
</attr>
}}
}}

===== Le tag {{m|attr}} de type {{m|attr_string}} =====
{{par|1=
Ses attributs sont :
{{:DataFlowGenerator:type}}
: Dans ce cas type = "attr_string"
{{:DataFlowGenerator:name}}
{{:DataFlowGenerator:help}}
{{:DataFlowGenerator:default_value}}
{{:DataFlowGenerator:admissible values}}
{{:DataFlowGenerator:opt}}
Peut contenir les tags suivants :
{{:DataFlowGenerator:shelp}}
{{:DataFlowGenerator:lhelp}}
}}
{{par|
Exemple :
{{codeTr|lang=xml|code=
<attr type="attr_string" name="prenom" default_value="Paul" admissible_values="Paul:Jacques:Marie" opt="oui" help="TODO Compléter les valeurs admissibles">
<shelp> Prénom par défaut </shelp>
<lhelp> Prénom par défaut proposé dans la liste déroulante ... </lhelp>
</attr>
}}
}}

==== Le tag {{m|el}} ====
{{par|
Le tag {{m|el}} permet de donner une structure arborescente à la grammaire. Ainsi en plus des tags tels que {{m|attr}}, il peut contenir de façon récurrente d'autres tags {{m|el}}.
{{:DataFlowGenerator:cardinality}}
La particularité du tag {{m|el}} est qu'il peut avoir une cardinalité supérieur à 1. Cela n'empêche pas que les types {{m|int}}, {{m|float}} et {{m|string}} soient des feuilles de l'arbre grammatical.
}}
===== Les feuilles de l'arbre grammatical du tag {{m|el}} =====
====== Le tag {{m|el}} de type {{m|int}} ======
{{par|1=
Ses attributs sont :
{{:DataFlowGenerator:type}}
: Dans ce cas type = "int"
{{:DataFlowGenerator:name}}
{{:DataFlowGenerator:help}}
{{:DataFlowGenerator:default_value}}
{{:DataFlowGenerator:admissible values}}
{{:DataFlowGenerator:cardinality}}
Peut contenir les tags suivants :
{{:DataFlowGenerator:unit}}
{{:DataFlowGenerator:shelp}}
{{:DataFlowGenerator:lhelp}}
}}
{{par|
Exemple :
{{codeTr|lang=xml|code=
<el type="int" name="nombre" cardinality="+" default_value="0" admissible_values="0:1:2:3:4" opt="oui" help="TODO changer le nom en 'Nb'">
<unit> chocs </unit>
<shelp> Nombre de chocs entre les atomes </shelp>
<lhelp> Nombre de chocs entre les atomes qui a un rapport direct avec ... </lhelp>
</el>
}}
}}
====== Le tag {{m|el}} de type {{m|float}} ======
{{par|1=
{{:DataFlowGenerator:type}}
: Dans ce cas type = "float"
{{:DataFlowGenerator:name}}
{{:DataFlowGenerator:help}}
{{:DataFlowGenerator:default_value}}
{{:DataFlowGenerator:admissible values}}
{{:DataFlowGenerator:cardinality}}
}}
{{par|
Exemple :
{{codeTr|lang=xml|code=
<el type="float" name="energie" cardinality="*" default_value="0.0" admissible_values="0.0:1.4:2.3" opt="oui" help="Obsolète"/>
}}
}}

====== Le tag {{m|el}} de type {{m|string}} ======
{{par|1=
{{:DataFlowGenerator:type}}
: Dans ce cas type = "string"
{{:DataFlowGenerator:name}}
{{:DataFlowGenerator:help}}
{{:DataFlowGenerator:default_value}}
{{:DataFlowGenerator:admissible values}}
{{:DataFlowGenerator:cardinality}}
}}
{{par|
Exemple :
{{codeTr|lang=xml|code=
<el type="string" name="prenom" cardinality="?" default_value="Paul" admissible_values="Paul:Jacques:Marie" opt="oui" help="TODO Compléter les valeurs admissibles"/>
}}
}}

===== Les branches de l'arbre grammatical du tag {{m|el}} : les classes =====
====== Introduction ======
{{par|
Les branches de l'arbre grammatical ne sont rien d'autre que des tags {{m|el}} dans d'autres tags {{m|el}}.

Bien sûr les tags el de type {{m|int}}, {{m|float}} et {{m|string}} ne peuvent contenir d'autres tags el, car ce sont des feuilles de l'arbre.

En fait les autres types sont définis par la grammaire même. En effet les types {{m|int}}, {{m|float}} et {{m|string}} sont des types dits «primitif»; leur sémantique est à priori connu. Le nom des autres types doit être défini par la grammaire, c.a.d. par celui qui rédige la grammaire.
}}
{{par|
Voici un exemple où le nouveau type {{m|TypePoint}} a été défini à partir du type primitif {{m|float}} :
{{codeTr|lang=xml|code=
<el name="Point" type="TypePoint">
<el name="x" type="float">
<el name="y" type="float">
</el>
}}
}}
{{par|
Voici un autre exemple où le nouveau type {{m|TypeCercle}} a été défini à partir du type primitif {{m|float}} et un type définit par la grammaire, nommé {{m|TypePoint}}:

{{codeTr|lang=xml|code=
<el name="Point" type="TypeCercle">
<el name="Rayon" type="float">
<el name="Point" type="TypePoint">
<el name="x" type="float">
<el name="y" type="float">
</el>
</el>
}}
}}
{{par|
Les tags {{m|el}} de type défini par la grammaire seront appelé des {{m|classes}}. Mais la notion de classe enferme d'autres caractéristiques que nous allons développer dans la suite.
}}
====== Les attributs classiques ======
{{par|
{{:DataFlowGenerator:name}}
{{:DataFlowGenerator:help}}
{{:DataFlowGenerator:cardinality}}
}}
====== Les types classe et les références des classe ======
{{par|
Les noms des classes sont définit par l'attribut type:
{{:DataFlowGenerator:type}}
: Le nom des autres types doit être défini par la grammaire, c.a.d. par celui qui rédige la grammaire. Voici quelques exemples de noms de type de classe : CHead, CHist, CBody
{{:DataFlowGenerator:reference}}
}}
====== Les classes OnlyDefinition ======
{{par|
{{:DataFlowGenerator:OnlyDefinition}}
}}

====== L'héritage de classes : heritances ======
{{par|
{{:DataFlowGenerator:heritances}}
}}

====== Le polymorphisme des classes : accept ======
{{par|
{{:DataFlowGenerator:accept}}
}}

====== Exemples de classes ======
{{par|
Voici un exemple qui fait appel à une définition récurrente utilisation les attributs {{m|OnlyDefinition}}, {{m|heritances}}, {{m|accept}}.
{{codeTr|lang=xml|code=
<el OnlyDefinition="1" name="OnlyDefinition_geometry" type="CBasegeometry" >
<el name="shape" type="int" />
<el name="data" type="float" cardinality="*" />
</el>
<el name="geometry" type="Cgeometry" heritances="CBasegeometry" >
<el name="geometry" type="@CBasegeometry" cardinality="*" accept="CBasegeometry:Cgeometry"/>
</el>
}}
}}
{{par|
Avec cette grammaire on peut construire des données ayant l'allure suivante :
{{codeTr|lang=xml|code=
geometry
geometry
geometry
shape
data
...
data
geometry
shape
data
...
data
geometry
shape
data
...
data
...
}}
}}

=== Liste des tags ===
{{par|
*unit
*shelp
*lhelp
* les tags types avec nom et cardinalité
:*attr
::les types du tag attr
::*attr_int
::*attr_float
::*attr_string
:*el
::les types du tag el
::*int
::*float
::*string
::*classe quelconque
::*référence de classe quelconque
}}
{{:DataFlowGenerator:see_too}}

== Liens ==
* [[XERCES:Index|XERCES parser]]

DataFlowGenerator:summary

2026-07-24T17:07:54Z

WikiAdmin a importé DataFlowGenerator:summary par téléversement de fichier (1 version) dfg

Nouvelle page

{{fr§en|1=Data Flow Generator (Dfg) est un outil qui a pour but le développement de logiciels en gardant la {{m|synchronisation}} entre les sources ({{m|Python}} et {{m|C++}}) et les modèles utilisant {{m|DfgUml}}({{m|UML}}) et {{m|DfgBehaviour}}(code Python des méthodes).

Il fait appel aux paradigmes de développement suivants : {{m|Round-trip engineering}}, {{m|Object-oriented programming}} et {{m|Model-driven software development}}.

Dfg offre aussi la possibilité d'écrire ou lire automatiquement la forme persistante des données décrites dans {{m|DfgUml}}.

Il existe deux versions de Dfg : V0 et V1.

Dfg V1 utilise DfgUml et DfgBehaviour et ne génère pour l'instant que du code Python tandis que Dfg V0 n'utilise que DfgUml et génère du code Python et C++.

Dfg V1 peut aussi importer DfgUml depuis les diagrammes de classes contenus dans le fichiers édités par le logiciel {{m|[https://live.gnome.org/Dia Dia]}}.

L'outil est gratuitement utilisable en ligne sur Internet à l'adresse [http://dfg.bht.fr http://dfg.bht.fr] pour la version 0 et sur [http://dfg1.bht.fr http://dfg1.bht.fr] pour la version 1.

Les sources générés par Dfg suivent sous la licence [http://www.mozilla.org/MPL/1.1/ MPL 1.1] et/ou [http://www.gnu.org/licenses/lgpl.html LPGL]

|2=Data Flow Generator (Dfg) is a tool that is intended for software development by keeping the {{m|synchronization}} between the sources ({{m|PYTHON}} and {{m|C++}}) and models using {{m|DfgUml}} ({{m|UML}}) and {{m|DfgBehaviour}} (Python codes of methods).

It uses the following paradigms of development: {{m|Round-trip engineering}}, {{m|Object-oriented programming}} and {{m|Model-driven software development}}.

Dfg also offers the ability to automatically read and write the persistent form of data described by {{m|DfgUml}}.

There are two versions of Dfg: V0 and V1.

Dfg V1 uses DfgUml and DfgBehaviour and generates, currently, only Python code while Dfg V0 uses only DfgUml and generates Python and C++ code.

Dfg V1 can also import DfgUml from class diagrams contained in the files edited by the software {{m|[https://live.gnome.org/Dia Dia]}}.

The tool can be used online for free at [http://dfg.bht.fr http://dfg.bht.fr] for version 0 and [http://dfg1.bht.fr http://dfg1.bht.fr] for version 1.

Sources generated by Dfg ar under the license [http://www.mozilla.org/MPL/1.1/ MPL 1.1] and/or [http://www.gnu.org/licenses/lgpl.html LPGL]
}}
{{c|
{{figc|Data Flow Generator V1|dfg1.png|dfg1|512px}}
}}
<noinclude>[[Category:All]][[Category:DataFlowGenerator|{{PAGENAME}}]]</noinclude>