Wikip - Contributions de l’utilisateur [fr]

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

2026-07-24T17:08:53Z

WikiAdmin : 1 version importée : dfg

<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:Minitodo

2026-07-24T17:08:53Z

WikiAdmin : 1 version importée : dfg

<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>

Modèle:EnConstruction

2026-07-24T17:08:53Z

WikiAdmin : 1 version importée : dfg

<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:Code

2026-07-24T17:08:52Z

WikiAdmin : 1 version importée : dfg

<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 : 1 version importée : dfg

{{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 - plantuml

2026-07-24T17:08:49Z

WikiAdmin : 1 version importée : dfg

<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 - xml - dfguml

2026-07-24T17:08:49Z

WikiAdmin : 1 version importée : dfg

<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 - xmlVersion - dfguml

2026-07-24T17:08:48Z

WikiAdmin : 1 version importée : dfg

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

Dfg1 reference manual - xmlEncoding - dfguml

2026-07-24T17:08:48Z

WikiAdmin : 1 version importée : dfg

<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 - grammar - dfguml

2026-07-24T17:08:47Z

WikiAdmin : 1 version importée : dfg

<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]].
}}

Data Flow Generator - Historique

2026-07-24T17:08:47Z

WikiAdmin : 1 version importée : dfg

{{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}}

Manuel utilisateur de Data Flow Generator V1

2026-07-24T17:08:47Z

WikiAdmin : 1 version importée : dfg

{{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
}}
}}

Guide de Référence de DfgBehaviour

2026-07-24T17:08:46Z

WikiAdmin : 1 version importée : dfg

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

2026-07-24T17:08:46Z

WikiAdmin : 1 version importée : dfg

{{IntroductionDFG}}
{{EnConstruction}}
== {{fr§en_title|Avertissement|Warning|{{sepLos}}}} ==
{{par2|{{fr§en|Ce document est écrit en français et en anglais, le français étant la référence.
La traduction en anglais est donnée à titre indicatif sans garantir sa bonne traduction.
|This document is written in French and English, the French being the reference.
The English translation is provided for information without guarantee of its correct translation.
}}}}
{{par|{{fr§en|Pour écrire ce document la version de Dia utilisée est {{mm|0.97.1}} et la version de dfgWebClient est {{mm|0.3x.0.0}}.
|For writing this document the Dia version used is {{mm|0.97.1}} and the dfgWebClient.py version is {{mm|0.3x.0.0}}.
}}}}

== {{fr§en_title|Objectif du document|Purpose of this document|{{sepLos}}}} ==
{{par2|
{{fr§en|Le but de ce document est d'expliquer comment utiliser l’éditeur de schéma technique qu'est {{m|Dia}} ([https://live.gnome.org/Dia]) afin de s'en servir comme outils de modélisation pour {{m|Dfg}} (Data Flow Generator V1 [http://dfg1.bht.fr]).

En effet Dia permet d'éditer des diagrammes de classes de type {{m|Uml}} et Dfg peut les importer en les traduisant dans son propre modèle qui est décrit dans le langage {{m|DfgUml}}.

C'est une solution alternative à une écriture directe dans le langage DfgUml utilisant le langage {{m|Xml}} comme support.
|The purpose of this document is to explain how to use the technical diagram modeler which is {{m|Dia}} ([https://live.gnome.org/Dia]) to be used as modeling tools for {{m|Dfg}} (Data Flow Generator V1 [http://dfg1.bht.fr]).

Indeed Dia help us to edit {{m|Uml}} Class Diagrams and Dfg can import and translating them into his own language, which is dfguml{{m|DfgUml}}.

This is an alternative to a direct writing in DfgUml language which uses the {{m|Xml}} language as support.
}}
}}
{{par2|
{{fr§en
|Ce document n'est donc pas un manuel d'utilisation de Dfg mais identifie les liens qui existent entre DfgUml et les diagrammes de classe de Dia et explique comment utiliser Dia pour modéliser avec Dfg.
|Therefore this document is not a Dfg user manual but identifies links between DfgUml and class diagrams and explains how to use Dia in order to model with Dfg.
}}
}}

== {{fr§en_title|Les prérequis pour lire ce document|The prerequisites to read this document|{{sepLos}}}} ==
=== {{fr§en_title|Connaissance de UML|Knowledge of UML|{{sepLos}}}} ===
{{par2|
{{fr§en|Dans {{m|Dfg}} la modélisation se fait à l'aide du langage {{m|DfgUml}}, une version texte contrainte et enrichie des digrammes de classe d'{{m|Uml}}. Il faut donc bien connaitre la modélisation à l'aide des diagrammes de classe. ([http://www.sparxsystems.com/uml-tutorial.html Lien vers un tutoriel sur Uml]).
|With {{m|Dfg}} modeling is maiden with {{m|DfgUml}} language, a constraint and extended text version of {{m|Uml}} class diagrams. We must therefore know the modeling using class diagrams. ([http://www.sparxsystems.com/uml-tutorial.html Link to a Uml tutorial]).
}}
}}
{{Ex|
{{figuml
|{{fr§en|Exemple que l'on doit comprendre|Example that we must understand}}
|abstract class CPicture {
}
CPicture *-- "0..*" CBase : els
abstract class CBase {
}
abstract class CCompound {
}
CCompound --{{!}}> CBase
CCompound *-- "0..*" CBase : els
abstract class CPoint {
}
CPoint --{{!}}> CBase
CPoint : float xx
CPoint : float yy
abstract class CSegment {
}
CSegment --{{!}}> CBase
CSegment *-- "1" CPoint : first
CSegment *-- "1" CPoint : second
abstract class CCircle {
}
CCircle --{{!}}> CPoint
CCircle : float radius
|uml_example_to_understand}}
}}

=== {{fr§en_title|Connaissance de XML pour modéliser avec DfgUml|Knowledge of XML to model with DfgUml|{{sepLos}}}} ===
{{par2|
{{fr§en|{{m|DfgUml}} utilise le langage {{m|Xml}} comme langage de bas niveau, on peut se contenter de notions basiques telles que les balises (les tags) et leurs attributs ([http://www.w3schools.com/xml/ Lien vers un tutoriel sur Xml]).
Voici ci-après le diagramme {{clink|uml_example_to_understand}} décrit dans le langage DfgUml :
|{{m|DfgUml}} uses the {{m|Xml}} language as a low-level language, normally it is sufficient to know basic concepts such as tags and their attributes ([http://www.w3schools.com/xml/ Link to a Xml tutorial]).
Here below diagram {{clink|uml_example_to_understand}} described in DfgUml language:
}}
}}
{{par|
<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">
<clDef type="CPicture">
<clInst accept="CCompound:CPoint:CCircle:CSegment" card="*" name="els" type="CBase"/>
</clDef>
<clDef type="CBase"/>
<clDef her="CBase" type="CCompound">
<clInst accept="CCompound:CPoint:CCircle:CSegment" card="*" name="els" type="CBase"/>
</clDef>
<clDef her="CBase" type="CPoint">
<flt name="xx"/>
<flt name="yy"/>
</clDef>
<clDef her="CBase" type="CSegment">
<clInst accept="CCircle" card="" name="first" type="CPoint"/>
<clInst accept="CCircle" card="1" name="second" type="CPoint"/>
</clDef>
<clDef her="CPoint" type="CCircle">
<flt name="radius"/>
</clDef>
<clInst name="picture" type="CPicture"/>
</grammar>
</source>
|margeWidth=5ch|dfg_example_to_understand}}

=== {{fr§en_title|Connaissance des diagrammes de classes du logiciel Dia|Knowledge of class diagrams of Dia software|{{sepLos}}}} ===
{{par2|
{{fr§en|Concernant Dia, il faut savoir au moins créer un diagramme de classe.
Le modèle de l'exemple précédent {{clink|uml_example_to_understand}} est schématisé par {{m|Dia}} par le diagramme {{clink|dia_example_to_understand}}:
|About Dia, you should know at least how to create a class diagram.
The model of the previous example {{clink|uml_example_to_understand}} is schematized by the Dia diagram {{clink|dia_example_to_understand}}:
}}
{{fig|{{fr§en|Vue dans Dia|View in Dia}}|dia_example_to_understand.png|dia_example_to_understand}}
}}
{{Rq|{{fr§en|Afin que Dfg puisse identifier la classe qui sera la classe racine de la structure de donnée, le fichier Dia doit toujours contenir la classe {{mm|ClDfgUml}} comme le montre le diagramme {{clink|dia_example_to_understand}}. En plus cette classe doit être liée par composition de multiplicité de 1 avec une et une seule classe.
|In order to indicate to Dfg which class will be the class root of data structure, the Dia file must always contains a class named {{mm|ClDfgUml}} as shown in the diagram {{clink|dia_example_to_understand}}. In addition this class must be linked to a unique another class by a composition association where the multiplicity is 1.
}}
|Dfg_needs_ClDfgUml_Rq|width=1100px}}

=== {{fr§en_title|Connaissance de la programmation orienté objet pour distinguer une instance de son modèle|Knowledge of object-oriented programming to distinguish an instance from its model|{{sepLos}}}} ===
{{par2|
{{fr§en|Les trois vues qui sont les documents {{clink|uml_example_to_understand}}, {{clink|dfg_example_to_understand}} et {{clink|dia_example_to_understand}} décrivent le même modèle. Ce modèle peut avoir une instance qui sous sa forme persistante (dans le langage DfgUml) peut être par exemple le fichier Xml suivant :
|The three views which are {{clink|uml_example_to_understand}}, {{clink|dfg_example_to_understand}} and {{clink|dia_example_to_understand}} documents, describe the same model. This model can have an instance which, under persistent form (by using DfgUml language), can be, for example, the following XMl file :
}}
}}
{{ex|
<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">
<picture>
<els dfgClName="CCompound">
<els dfgClName="CPoint">
<xx>0.0</xx>
<yy>0.0</yy>
</els>
<els dfgClName="CSegment">
<first dfgClName="CPoint">
<xx>0.0</xx>
<yy>0.0</yy>
</first>
<second dfgClName="CPoint">
<xx>0.0</xx>
<yy>0.0</yy>
</second>
</els>
</els>
<els dfgClName="CPoint">
<xx>0.0</xx>
<yy>0.0</yy>
</els>
<els dfgClName="CCircle">
<xx>0.0</xx>
<yy>0.0</yy>
<radius>0.0</radius>
</els>
</picture>
</grammar>
</source>
|tuto01_dia2dfg_instance|width=140ch}}

== {{fr§en_title|Cas simple mais complet|Simple but complete case|{{sepLos}}}} ==
=== {{fr§en_title|Où trouver les sources ?|Where are the sources?|{{sepLos}}}} ===
{{par2|
{{fr§en|Les sources de cet exemple peuvent être téléchargés à partir de ce [[:file:dfgTuto01.zip|lien]].
|The sources of this example can be download from this [[:file:dfgTuto01.zip|link]].
}}
}}

=== {{fr§en_title|Modélisation de la structure|Structure modeling|{{sepLos}}}} ===
{{par2|
{{fig|Data Flow Generator V1 sources|dfg1.png|dfg1_simple_case_tuto01|614px}}
{{fr§en|Dans notre exemple le fichier de départ est {{mm|tuto01.dia}} qui est le point 1 sur diagramme {{clink|dfg1_simple_case_tuto01}}. Son schéma Uml est donné par {{clink|dfg1_simple_case_tuto01_dia}}.
Téléchargez {{mm|dfgWebClient.py}} depuis la page [http://dfg1.bht.fr] et exécutons maintenant la commande d'appel à Dfg :
|In our example the first file to edit is {{mm|tuto01.dia}} which is the point 1 on diagram {{clink|dfg1_simple_case_tuto01}}. Its Uml diagram is given by {{clink|dfg1_simple_case_tuto01_dia}}.
Download {{mm|dfgWebClient.py}} from the page [http://dfg1.bht.fr] and execute the call command of Dfg :
}}
<source lang="bash">
python dfgWebClient.py --pathGrammarfile tuto01.dia --dataName tuto01
</source>
}}
{{par2|
{{fr§en|Lors de l'appel au serveur, Dfg
#traduit le fichier le contenu de {{mm|tuto01.dia}} en en DfgUml qui sera retourné dans {{mm|tuto01_generated.dfg}} (point {{mm|2}} sur {{clink|dfg1_simple_case_tuto01}});
#génère la première version du modèle {{mm|DfgBehaviour}} renvoyé dans {{mm|tuto01_ManualBeHaviour.py}} (point {{mm|3}} sur {{clink|dfg1_simple_case_tuto01}});
#génère l'{{mm|exécutable}} au complet renvoyé dans les fichiers {{mm|tuto01_XmlDrvClassDiagrBeHaviour.py}} et {{mm|tuto01_XmlDrvClassDiagrBeHaviour_pkg_version.py}} (point {{mm|4}} sur {{clink|dfg1_simple_case_tuto01}});
# génère et renvoie d'autres fichiers tels que {{mm|tuto01PlantUml.png}} qui est un autre rendu Uml généré par Dfg en partant de {{mm|tuto01_generated.dfg}}. Un rendu visible sur le diagramme {{clink|dfg1_simple_case_tuto01_plantuml}}.
|During this call to the server, Dfg
#translates the content of the file {{mm|tuto01.dia}} into DfgUml language and returns it in the file named {{mm|tuto01_generated.dfg}} (point {{mm|2}} on {{clink|dfg1_simple_case_tuto01}});
#generates the first version of {{mm|DfgBehaviour}} model returned in the file {{mm|tuto01_ManualBeHaviour.py}} (point {{mm|3}} on {{clink|dfg1_simple_case_tuto01}});
#generates the complete {{mm|executable}} returned in files named {{mm|tuto01_XmlDrvClassDiagrBeHaviour.py}} and {{mm|tuto01_XmlDrvClassDiagrBeHaviour_pkg_version.py}} (point {{mm|4}} on {{clink|dfg1_simple_case_tuto01}});
#generates and returns other files like {{mm|tuto01PlantUml.png}} which is an other Uml view of model generated by Dfg from {{mm|tuto01_generated.dfg}}. This view is shown by the diagram {{clink|dfg1_simple_case_tuto01_plantuml}}.
}}
{{fig|tuto01.dia|dfg1_simple_case_tuto01_dia.png|dfg1_simple_case_tuto01_dia|614px}}
{{fig|tuto01PlantUml.png|dfg1_simple_case_tuto01_plantuml.png|dfg1_simple_case_tuto01_plantuml|614px}}
}}

=== {{fr§en_title|Modélisation du comportement|Behaviour modeling|{{sepLos}}}} ===
{{par2|
{{fr§en|La modélisation du comportement se fait dans le fichier {{mm|tuto01_ManualBeHaviour.py}} à l'aide d'un éditeur de texte ou d'un éditeur de code Python. Il ne faut écrire que dans l'espace de texte se trouvant entre les lignes (parties en {{m|…}}) :
|The behavior modeling is written in the file {{mm|tuto01_ManualBeHaviour.py}} with a text editor or a Python code editor. You have to write only in the space which is located between the following lines (the part which is {{m|…}}) :
}}
<source lang="python">
# dfg_start_manual do not modify this line
…
#dfg_end_manual do not modify this line
</source>
}}
{{par2|
{{fr§en|Par exemple concernant la classe CCompound nous avons au départ:
|In the case of CCompound class at the start we have:
}}
<source lang="python">
################################################################################
# CCompound
################################################################################
# dfg_start_class do not modify this line
class CCompound : # ancestors : CBase
pass
#-------------------------------------------------------------------------------
# dfg_start_def do not modify this line
def calcDimension( self ) : #dimension:out flt,
# dfg_start_manual do not modify this line
pass # TODO
#dfg_end_manual do not modify this line
return dimension
# dfg_end_def do not modify this line

# dfg_end_class do not modify this line
</source>
}}
{{par2|
{{fr§en|La ligne "pass # TODO" est alors remplacée de la façon suivante :
|The line "pass # TODO" is then replaced by the following :
}}
<source lang="python">
…
# dfg_start_manual do not modify this line
dimension=0
for el in self.els :
dimension += el.calcDimension()
self.dimension=dimension
#dfg_end_manual do not modify this line
return dimension
…
</source>
}}
{{par2|
{{fr§en|Il faut faire la même chose pour les autres classes et les autres méthodes. Afin que ces lois de comportement soient prise en compte il faut appeler de nouveau Dfg qui va les extraire depuis {{mm|tuto01_ManualBeHaviour.py}} et les injecter dans {{mm|tuto01_XmlDrvClassDiagrBeHaviour.py}}. On exécute donc une nouvelle fois la commande :
|We have to do the same thing for all the other classes and methods. In order to have this behavior laws integrated in the executable we have to make a new call to Dfg. Then Dfg will extract them from {{mm|tuto01_ManualBeHaviour.py}} and will insert them into {{mm|tuto01_XmlDrvClassDiagrBeHaviour.py}}. Let's call again Dfg :
}}
<source lang="bash">
python dfgWebClient.py --pathGrammarfile tuto01.dia --dataName tuto01
</source>
}}
{{par2|
{{fr§en|Si vous éditez {{mm|tuto01_XmlDrvClassDiagrBeHaviour.py}} vous retrouverez alors notre loi de comportement autour de la ligne 1000. Vous y trouverez aussi d'autres méthodes générées et définies par Dfg telles que :
|If you edit the file {{mm|tuto01_XmlDrvClassDiagrBeHaviour.py}} then you will find our behavior law near the line 1000. For the CCompound class you will find other methods generated and defined par Dfg like :
}}
{{mm|add_els}}, {{mm|clear}}, {{mm|clear_all_id}}, {{mm|construct}}, {{mm|construct2}}, {{mm|copy}}, {{mm|create_copy}}, {{mm|extract_els}}, {{mm|fromXML}}, {{mm|get_dimensionRef}}, {{mm|get_elsLen}}, {{mm|get_elsRef}}, {{mm|get_id_dict}}, {{mm|get_longHelp}}, {{mm|get_nameRef}}, {{mm|get_shortHelp}}, {{mm|get_unit}}, {{mm|gr_name}}, {{mm|init}}, {{mm|insert_els}}, {{mm|set_all_id}}, {{mm|set_dimension}}, {{mm|set_name}}, {{mm|set_ptrs}}, {{mm|toXML}}.
}}

=== {{fr§en_title|L'instance de l'exécutable et l'état initial|Exectable isntance and initial state|{{sepLos}}}} ===
{{par2|
{{fr§en|Pour exécuter notre modèle il nous reste à écrire deux fichiers : un petit fichier python appelé {{mm|tuto01.py}} (point {{m|5}} sur {{clink|dfg1_simple_case_tuto01}}) qui va instancier notre modèle exécutable et un fichier nommé {{mm|tuto01InitState.xml}} une instance de la structure de données qui n'est rien d'autre que son état initial écrit dans le langage DfgUml.
|In order to execute our model we have to write two files : a small code of Python in a file named {{mm|tuto01.py}} (point {{m|5}} on {{clink|dfg1_simple_case_tuto01}}) which will create instances of our executable model and a file named {{mm|tuto01InitState.xml}}, an instance of data structure which is its initial state written in the DfgUml.
}}
}}
{{Ex|tuto01.py:
<source lang="python">
import tuto01_XmlDrvClassDiagrBeHaviour
def main():
info=tuto01_XmlDrvClassDiagrBeHaviour.CFileFormatInfo()
dfg = info.loadFromXMLFile( "tuto01InitState.xml" )
for el in dfg.picture.els :
el.calcDimension()
print "dimension of '%s' is %0.2f" %(el.name, el.dimension)
info.Save2XMLFile( dfg, "tuto01FinalState.xml" )
if __name__ == u'__main__' :
main()
</source>
|width=140ch}}
{{Ex|tuto01InitState.xml:
<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">
<picture>
<els dfgClName="CCompound">
<name>Compound 1</name>
<dimension>0</dimension>
<els dfgClName="CPoint">
<name>Point 1</name>
<dimension>0</dimension>
<xx>1.0</xx>
<yy>0.5</yy>
</els>
<els dfgClName="CSegment">
<name>Segment 1</name>
<dimension>0</dimension>
<first dfgClName="CPoint">
<name>Point 2</name>
<dimension>0</dimension>
<xx>9.0</xx>
<yy>2.0</yy>
</first>
<second dfgClName="CPoint">
<name>Point 3</name>
<dimension>0</dimension>
<xx>0.5</xx>
<yy>-6.0</yy>
</second>
</els>
</els>
<els dfgClName="CPoint">
<name>Point 4</name>
<dimension>0</dimension>
<xx>-7.0</xx>
<yy>3.14</yy>
</els>
<els dfgClName="CCircle">
<name>Circle 1</name>
<dimension>0</dimension>
<xx>3.0</xx>
<yy>1.0</yy>
<radius>20.0</radius>
</els>
</picture>
</grammar>
</source>
|width=140ch}}

=== {{fr§en_title|Exécution et état final|Runing and final state|{{sepLos}}}} ===
{{par2|
{{fr§en|L'exécution se fait en lançant la commande:
|The running is launched by the command:
}}
<source lang="bash">
python tuto01.py
</source>
{{fr§en|Ce qui affiche:
|Which displays:
}}
<source lang="text">
dimension of 'Compound 1' is 11.67
dimension of 'Point 4' is 0.00
dimension of 'Circle 1' is 40.00
</source>
{{fr§en|Et l'état final est sauvegardé dans le fichier {{mm|tuto01FinalState.xml}}:
|And last state is stored in the file {{mm|tuto01FinalState.xml}}:
}}
<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">
<picture>
<els dfgClName="CCompound">
<dimension>11.6726175299</dimension>
<name>Compound 1</name>

<els dfgClName="CPoint">
<dimension>0.0</dimension>
<name>Point 1</name>

<xx>1.0</xx>
<yy>0.5</yy>
</els>
<els dfgClName="CSegment">
<dimension>11.6726175299</dimension>
<name>Segment 1</name>

<first dfgClName="CPoint">
<dimension>0.0</dimension>
<name>Point 2</name>

<xx>9.0</xx>
<yy>2.0</yy>
</first>
<second dfgClName="CPoint">
<dimension>0.0</dimension>
<name>Point 3</name>

<xx>0.5</xx>
<yy>-6.0</yy>
</second>
</els>
</els>
<els dfgClName="CPoint">
<dimension>0.0</dimension>
<name>Point 4</name>

<xx>-7.0</xx>
<yy>3.14</yy>
</els>
<els dfgClName="CCircle">
<dimension>40.0</dimension>
<name>Circle 1</name>

<xx>3.0</xx>
<yy>1.0</yy>

<radius>20.0</radius>
</els>
</picture>
</grammar>
</source>
}}

== {{fr§en_title|Les exigences de DfgUml|DfgUml Requirements|{{sepLos}}}} ==
=== {{fr§en_title|Les éléments UML utilisés dans Dia utilisés par Dfg|UML elements used in Dia used by Dfg|{{sepLos}}}} ===
{{par2
|
{{fr§en
|Seuls les éléments {{m|classe}}, {{m|héritage}}, {{m|agrégation}} et {{m|composition}} sont utilisés par Dfg lors de l'importation. Ce sont ces éléments que l'on peut retrouver tels quels quand on commence à écrire du code. Les éléments {{m|agrégation}} et {{m|composition}} se retrouvent sous la forme d'un même objet, la différence se fait en modifiant son type en éditant ses propriétés.
|Only class {{m|elements}}, {{m|inheritance}}, {{m|aggregation}} and {{m|composition}} are used by Dfg when importing. These are the elements that can be found as is when we begin to write code. The {{m|aggregation}} and {{m|composition}} elements are found in the form of a single object, the difference is done by changing the type by editing its properties.
}}
{{fig||UML_elements_used_in_Dia_used_by_Dfg.png}}
}}

=== {{fr§en_title|Cardinalité et Multiplicité : notation|Cardinality and Multiplicity: notation|{{sepLos}}}} ===
{{par2|
{{fr§en
|Soient n, n1, n2 des entiers
{{tab
|
|
|
{{line| {{col_t|notation entre les doubles quottes}} {{col_t|description}} }}
{{line| {{col|"n1:n2"}} {{col|de n1 à n2}} }}
{{line| {{col|"?" ou "0:1"}} {{col|de 0 à 1, optionnel}} }}
{{line| {{col|"*" ou "0:*"}} {{col|de 0 à l'infini}} }}
{{line| {{col|"+" ou "1:*"}} {{col|de 1 à l'infini}} }}
{{line| {{col|"n:" ou "n:*"}} {{col|de n à l'infini}} }}
{{line| {{col|"n" ou "n:n"}} {{col|de n à n, exactement n}} }}
{{line| {{col|si non présent ou chaine vide}} {{col|valeur de défaut : exactement 1 }} }}
}}
|Let n, n1, n2 integers
{{tab
|
|
|
{{line| {{col_t|notation between double quotes}} {{col_t|description}} }}
{{line| {{col|"n1:n2"}} {{col|from n1 to n2}} }}
{{line| {{col|"?" or "0:1"}} {{col|from 0 to 1, optional}} }}
{{line| {{col|"*" or "0:*"}} {{col|from 0 to infinite}} }}
{{line| {{col|"+" or "1:*"}} {{col|from 1 to infinite}} }}
{{line| {{col|"n:" or "n:*"}}{{col|from n to infinite}} }}
{{line| {{col|"n" or "n:n"}} {{col|from n to n, exactly n}} }}
{{line| {{col|if no present or empty string}} {{col|default value: exactly 1}} }}
}}
}}
}}

=== {{fr§en_title|Les conventions de nommage|Naming conventions|{{sepLos}}}} ===
{{par2|
{{fr§en|Les conventions de nommage sont définies par le langage des expressions régulières du langage Python défini dans le module {{mm|re}}. Si ces conventions ne sont pas respectées Dfg génèrera une erreur.
|Naming conventions are defined in the regular expression language of Python provided by the module {{mm|re}}. If these conventions are not respected Dfg will generate an error.
}}
}}
==== {{fr§en_title|Noms de classes:|Class names|{{sepLos}}}} ====
{{par2|
{{fr§en|
*L'expression régulière à vérifier est:
:{{mm|^[Cc][l]?([A-Z][a-z0-9]+)*$}}
*Exemples:
:{{mm|ClCivilAircraft}} {{mm|clCivilAircraft}} {{mm|CAircraft}} {{mm|cAircraft}}
|
*The regular expression to check is:
:{{mm|^[Cc][l]?([A-Z][a-z0-9]+)*$}}
*Examples:
:{{mm|ClCivilAircraft}} {{mm|clCivilAircraft}} {{mm|CAircraft}} {{mm|cAircraft}}
}}
}}
==== {{fr§en_title|Noms d'attribut|Attribute names|{{sepLos}}}} ====
{{par2|
{{fr§en|
*L'expression régulière à vérifier est:
:{{mm|^([a-z][a-z0-9]+(?:[A-Z][a-z0-9]+)*)(?:\[([^\]]*)\])?$}}
*Exemples:
:{{mm|civilAircraft}} {{mm|civil}} {{mm|xmlDriverName}} {{mm|vals[:12]}} {{mm|vals[3:10]}} {{mm|vals[*]}}
|
*The regular expression to check is:
:{{mm|^([a-z][a-z0-9]+(?:[A-Z][a-z0-9]+)*)(?:\[([^\]]*)\])?$}}
*Examples:
:{{mm|civilAircraft}} {{mm|civil}} {{mm|xmlDriverName}} {{mm|vals[:12]}} {{mm|vals[3:10]}} {{mm|vals[*]}}
}}
}}
==== {{fr§en_title|Noms d'association|Association names|{{sepLos}}}} ====
{{par2|
{{fr§en|Les noms des associations|}}
}}

==== {{fr§en_title|Noms de méthodes|Method names|{{sepLos}}}} ====
{{par2|
{{fr§en|
*L'expression régulière à vérifier est:
:{{mm|^[a-z][a-z0-9]+([A-Z][a-z0-9]+)*(_[a-z][a-z0-9]+([A-Z][a-z0-9]+)*)*$}}
*Exemples:
:{{mm|get_firstName}} {{mm|getName}}
|
*The regular expression to check is:
:{{mm|^[a-z][a-z0-9]+([A-Z][a-z0-9]+)*(_[a-z][a-z0-9]+([A-Z][a-z0-9]+)*)*$}}
*Examples:
:{{mm|get_firstName}} {{mm|getName}}
}}
}}

=== {{fr§en_title|Les classes|Classes|{{sepLos}}}} ===
{{par2
|
{{fr§en
|La structure des données est organisée en arborescence comme l'illustre l'exemple {{clink|tuto01_dia2dfg_instance}}. Rien dans les diagramme de class UML et rien dans Dia ne permet d'identifier la classe racine de cette arborescence. Il faut donc trouver un moyen d'identifier clairement la classe racine. L'ajout d'une classe nommée {{mm|ClDfgUml}} permet d'identifier la classe racine. Il suffit d'associer la classe racine à la classe {{mm|ClDfgUml}} avec une association de composition avec une multiplicité de 1 de chaque côté. Le nom de cette association du côté de {{mm|ClDfgUml}} sera le nom de l'instance de la classe racine.
|The data structure is organized in a tree structure as shown in the example {{clink|tuto01_dia2dfg_instance}}. Nothing in the UML class diagram and nothing in Dia can help us to identify the root class of this tree. We must find a way to clearly identify the root class. Adding a class named {{mm|ClDfgUml}} allows us to identify the root class. It's enough to associate the root class to the class {{mm|ClDfgUml}}; a composition association with a multiplicity of 1 on each side. The side name of this association, on the side of {{mm|ClDfgUml}} class will be the name of the instance of the root class.
}}
{{figuml||ClDfgUml *-- "1" CClassRoot : rootName
|Required_by_Dfg_class}}
}}

=== {{fr§en_title|Les attributs|Attributes|{{sepLos}}}} ===
{{par2
|
{{fr§en
|Pour les attributs, Dia permet de définir le nom, le type et la valeur par défaut ainsi que la visibilité. Dfg n'importe que le nom, le type et la valeur par défaut. Les attributs sont traduits en types primitifs (str, int, bool, date, flt) dans le langage DfgUml.
|For attributes, Dia allows us to define the name, type, default value and visibility. Dfg translates only name, type and default value. Attributes are translated into DfgUml language primitive types (str, int, bool, date, flt).
}}
}}
{{Ex|
{{fr§en|Exemple de types primitifs dans le langage DfgUml :|Example of primitive types in the DfgUml language:}}
<source lang="xml">
<str defVal="kWh" name="energyUnit"/>
<str defVal="h" name="timeUnit"/>
<flt defVal="3.14" name="values" card="*"/>
<flt defVal="1.0" name="timeStep"/>
</source>
|width=140ch}}
==== {{fr§en_title|Nom et cardinalité|Names and cardinalities|{{sepLos}}}} ====
{{par2|
{{fr§en
|Dfg permet de définir la cardinalité/multiplicité dans le nom de l'attribut de Dia en utilisant les crochets; […], en effet les types simples (string, real, integer) peuvent être multiples dans le langage DfgUml. Cette possibilité est illustrée dans l'exemple {{clink|dia2dfg_attributes_consumption}} qui est traduit par Dfg en {{clink|dia2dfg_attributes_consumption_dfg}} qui lui même peut avoir pour instance {{clink|dia2dfg_attributes_consumption_instance}}.
|Dfg defines the cardinality/multiplicity in the Dia attribute name using the brackets; [...], indeed simple types (string, real, integer) can be multiple in DfgUml language. This possibility is illustrated in the example {{clink|dia2dfg_attributes_consumption}} which is translated in Dfg {{clink|dia2dfg_attributes_consumption_dfg}} which itself may have for instance {{clink|dia2dfg_attributes_consumption_instance}}.
}}
}}
{{Ex
|{{fr§en|Exemples de nom d'attribut avec cardinalité : {{mm|vals[:12]}}, {{mm|vals[3:10]}}, {{mm|vals[*]}}.|Examples of attribute name with cardinality: {{mm|vals[12]}}, {{mm|vals[3:10]}}, {{mm|vals[*]}}.}}
{{fig||dia2dfg_attributes_consumption.png|dia2dfg_attributes_consumption}}
|width=140ch}}
{{Ex
|<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">
<clDef type="CLoadCurve">
<str card="" defVal="kWh" name="energyUnit"/>
<str card="" defVal="h" name="timeUnit"/>
<flt card="*" defVal="3.14" name="values"/>
<flt card="" defVal="1.0" name="timeStep"/>
</clDef>
<clInst name="consumption" type="CLoadCurve"/>
</grammar></source>
|dia2dfg_attributes_consumption_dfg|width=140ch}}
{{Ex
|<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">
<consumption>
<values>3.14</values>
<values>4.24</values>
<values>5.64</values>
<values>6.94</values>
<values>7.04</values>
<timeStep>1.0</timeStep>
<energyUnit>kWh</energyUnit>
<timeUnit>h</timeUnit>
</consumption>
</grammar></source>
|dia2dfg_attributes_consumption_instance|width=140ch}}

==== {{fr§en_title|Les types|Types|{{sepLos}}}} ====
{{par2|
{{fr§en
|Les types possibles sont : {{mm|str}}, {{mm|string}}, {{mm|int}}, {{mm|integer}}, {{mm|bool}}, {{mm|boolean}}, {{mm|date}}, {{mm|flt}}, {{mm|float}}, {{mm|real}}, {{mm|double}}. Ces types sont traduits dans les 4 types primitifs de DfgUml qui sont {{mm|str}}, {{mm|int}}, {{mm|bool}}, {{mm|date}}, {{mm|flt}}.
|Possible types are: {{mm|str}}, {{mm|string}}, {{mm|int}}, {{mm|integer}}, {{mm|boolean}}, {{mm|boolean}}, {{mm|date}}, {{mm|flt}}, {{mm|float}}, {{mm|real}}, {{mm|double}}. These types are translated into the four DfgUml primitive types that are {{mm|str}}, {{mm|int}}, {{mm|bool}}, {{mm|date}}, {{mm|flt}}.
}}
}}

==== {{fr§en_title|Les valeurs par défaut|Default values|{{sepLos}}}} ====
{{par2|
{{fr§en
|Les valeurs par défaut sont simplement reprises telles quelles dans le langage DfgUml dans l'entité {{mm|defVal}}.
|The default values are just copied in the DfgUml language entity {{mm|DefVal}}.
}}
}}
{{Ex|
{{fr§en|Exemple:|Example:}}
<source lang="xml">
<str defVal="kWh" name="energyUnit"/>
</source>
|width=140ch}}

=== {{fr§en_title|Les méthodes|Methods|{{sepLos}}}} ===
{{par2|
{{fr§en
|Les méthodes doivent toujours renvoyer le type {{mm|void}}. Les entrées et sorties sont plus généralement identifiées à l'aide de la {{mm|direction}} de chaque argument de la méthode. La direction peut avoir comme valeurs : {{mm|in}}, {{mm|out}}, {{mm|inout}}. Dia et DfgUml permettent d'utiliser la notion de direction pour définir les entrées et sorties d'une méthode. Un exemple de méthode nommée addition est donné dans le diagramme de Dia ({{clink|methods_signature_in_dia}}), dans le langage [http://www.omg.org/cgi-bin/doc?formal/02-06-39 Idl] ({{clink|methods_signature_idl}}), dans le langage DfgUml ({{clink|methods_dfguml}}) et le langage DfgBehaviour ({{clink|methods_behaviour}}).
|All methods must always return the type {{mm|void}}. Inputs ans outputs are generally identified by the {{mm|direction}} of each argument of a method. Diraction has the values: {{mm|in}}, {{mm|out}}, {{mm|inout}}. Dia and Dfg uses the direction notion in order to define method inputs and outputs. An example of a method named "addition" is given in the Dia diagram ({{clink|methods_signature_in_dia}}), in the [http://www.omg.org/cgi-bin/doc?formal/02-06-39 Idl] language ({{clink|methods_signature_idl}}), in the DfgUml language ({{clink|methods_dfguml}}) and in DfgBehaviour language ({{clink|methods_behaviour}}).
}}
{{fig||dia_methods.png|methods_signature_in_dia}}
}}
{{Ex|
<source lang="idl">
void addition( in aa:int, in int bb, out int addResult, inout bool negative)
</source>
|methods_signature_idl|width=140ch}}
{{Ex|
<source lang="xml">
<clDef type="CMethod">
<method name="addition">
<arg dir="in" name="aa" type="int"/>
<arg dir="in" name="bb" type="int"/>
<arg dir="out" name="addResult" type="int"/>
<arg dir="inout" name="negative" type="bool"/>
</method>
</clDef>
</source>
|methods_dfguml|width=140ch}}
{{Ex|
<source lang="python">
def addition( self ,aa ,bb ,negative ) : #aa:in int, bb:in int, addResult:out int, negative:inout bool,
# dfg_start_manual do not modify this line

addResult = aa + bb
negative = addResult < 0

#dfg_end_manual do not modify this line
return addResult ,negative
</source>
|methods_behaviour|width=140ch}}

=== {{fr§en_title|Les Associations|Associations|{{sepLos}}}} ===
{{par2|
{{fig|{{fr§en|Les parties nommables|The nameable parts}}|association_names_01.png}}
{{fig|{{fr§en|Les parties nommables pour Dfg|The Dfg nameable parts}}|association_names_02.png}}
{{fig|{{fr§en|Le lien vers le parent|The link to the parent}}|association_names_03.png}}
{{fig|{{fr§en|L'interface de saisi des noms|The interface for entering names}}|association_names_04.png|width=200px}}
}}
==== {{fr§en_title|Les Compositions|Compositions|{{sepLos}}}} ====
{{par2|
{{fr§en
|Selon Dfg, les données sont organisées dans une structure {{m|arborescente}} (voir le § [[#parAggregations|«Les Agrégations»]] pour sa transformation en graphe) avec une {{m|racine unique}}. Les branches de l'arbre sont les {{m|classes}} et les feuilles sont les {{m|types primitifs}} de Dfg : {{mm|str}}, {{mm|int}}, {{mm|bool}}, {{mm|date}}, {{mm|flt}}.

Chaque instance de classe doit avoir une {{m|unique classe parente}}, sauf pour la racine. La classe parente est responsable du cycle de vie des classes dites enfant. C'est l'association {{m|composition}} qui représente le mieux cette relation entre parent et enfant. Le nom de rôle côté losange noir, celui du côté parent ou rôle du côté A de l'association, est le nom de l'instance ou des instances du ou des enfant(s).

L'unicité du parent impose une multiplicité de 1 du côté du losange noir et la syntaxe de la multiplicité du côté des enfants est décrite dans le § [[#Cardinalit.C3.A9_et_Multiplicit.C3.A9_:_notation_-.E2.97.8A-_Cardinality_and_Multiplicity:_notation|«Cardinalité et Multiplicité : notation»]].
|
}}
{{fig||dia_composition.png|composition_in_dia}}
}}
{{par2|
{{fr§en
|La figure {{clink|composition_in_dia}} montre l'emplacement du nom et cardinalité de la composition. Tandis que la figure {{clink|composition2_in_dia}} montre un exemple possible.
|
}}
{{fig||dia_composition2.png|composition2_in_dia}}
}}
{{par2|
{{fr§en
|Côté DfgUml la composition est défini principalement à l'aide des nœuds Xml {{mm|clInst}} et {{mm|clDefInst}}.
Ils composent la classe parente identifiée par l'attribut {{mm|type}} du nœud Xml parent avec leurs nœud Xml enfants dont les classes sont aussi identifiées par l'attribut {{mm|type}}. Dans l'exemple {{clink|composition2_dfg}} la classe {{mm|CParent}} compose avec la classe {{mm|CChild}}.
La différence entre {{mm|clInst}} et {{mm|clDefInst}} est illustrée par l'exemple {{clink|composition1_dfg}}; {{mm|clInst}} fait appel à une classe déjà défini par un autre nœud Xml, c'est une instance de cette définition, tandis que {{mm|clDefInst}} défini la classe (les … dans {{clink|composition1_dfg}} où un peut avoir des sous structures) en même temps que la composition même.

Le nom de la composition du côté du losange noir est défini par l'attribut Xml {{mm|name}} de {{mm|clInst}} et {{mm|clDefInst}}. La cardinalité ou multiplicité du côté opposé du losange noir est défini par l'attribut Xml {{mm|card}}.
|
}}
}}
{{Ex|
<source lang="xml">
<clInst card="+" name="name1" type="CChild"/>
<clDefInst card="*" name="name2" type="CChild">
…
</clDefInst>
</source>
|composition1_dfg|width=140ch}}
{{Ex|
<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">
<clDef type="CParent">
<clInst accept="CChild" card="+" name="name" type="CChild"/>
</clDef>
<clDef type="CChild"/>
<clInst name="composition" type="CParent"/>
</grammar>
</source>
|composition2_dfg|width=140ch}}

==== {{fr§en_title|Les Agrégations|Aggregations|{{sepLos}}}} ====
{{par2|
{{fr§en
|Le fait que chaque élément de données ne possède qu'un seul parent qui est aussi son propriétaire (si le parent est détruit ses enfants sont détruits), nous ne pouvons construire qu'une structure arborescente de nos données si l'on n'utilise que les compositions (voir le § [[#Les_Compositions_-.E2.97.8A-_Compositions|«Les Compositions»]]). Pour transformer l'{{m|arbre}} en {{m|graphe}} il faut ajouter des {{m|références}}, ce qui peut correspondre en Uml à des {{m|agrégations}}.

Le nom de rôle côté losange blanc, celui du côté A de l'association, est le nom de référence sur la classe référencée. La multiplicité du côté du losange blanc est 1 car sinon il faudrait ajouter une autre instance côté de la classe référencée. La syntaxe de la multiplicité du côté de la classe référencée est décrite dans le § [[#Cardinalit.C3.A9_et_Multiplicit.C3.A9_:_notation_-.E2.97.8A-_Cardinality_and_Multiplicity:_notation|«Cardinalité et Multiplicité : notation»]].
|
}}
{{fig||dia_aggregation.png|aggregation_in_dia}}
|parAggregations}}
{{par2|
{{fr§en
|La figure {{clink|aggregation_in_dia}} montre l'emplacement du nom et cardinalité de l'agrégation. Tandis que la figure {{clink|aggregation2_in_dia}} montre un exemple possible.
|
}}
{{fig||dia_aggregation2.png|aggregation2_in_dia}}
}}
{{par2|
{{fr§en
|La figure {{clink|aggregation3_in_dia}} met en scène d'un exemple où une composition et une agrégation pointe vers la même classe qui est ici {{mm|CReferencedClass}}.
|
}}
{{fig||dia_aggregation3.png|aggregation3_in_dia}}
}}
{{par2|
{{fr§en
|La figure {{clink|aggregation3_in_dfg}} montre le diagramme de la figure {{clink|aggregation3_in_dia}} converti par Dfg en un diagramme Uml dans le langage [http://plantuml.sourceforge.net PlantUml]].
|
}}
{{figuml||
abstract class CAlpha {
}
CAlpha o-- "0..*" CReferencedClass : childRefs
CAlpha *-- "0..*" CParent : parents
abstract class CReferencedClass {
}
abstract class CParent {
}
CParent *-- "0..*" CReferencedClass : childs
|aggregation3_in_dfg}}
}}
{{par2|
{{fr§en
|Côté DfgUml l'agrégation est défini principalement à l'aide du seul nœud Xml {{mm|clRef}}. Il crée une référence dans la classe du nœud Xml parent sur la classe référencée par le nœud Xml enfant {{mm|clRef}}.

Dans l'exemple {{clink|aggregation2_dfg}} la classe {{mm|CAlpha}} possède une référence nommée {{mm|childRefs}} sur le classe {{mm|CReferencedClass}}.

Le nœud {{mm|clRef}} fait appel à une classe déjà défini par un autre nœud Xml, c'est une référence sur une ou plusieurs instances de cette définition.
Le nom de l'agrégation du côté du losange blanc est défini par l'attribut Xml {{mm|name}} de {{mm|clRef}} et la cardinalité ou multiplicité du côté opposé du losange blanc est défini par l'attribut Xml {{mm|card}}.
|}}
}}
{{Ex|
<source lang="xml">
<clRef card="1:100" name="referenceName" type="CReferencedClass"/>
</source>
|aggregation1_dfg|width=140ch}}
{{Ex|
<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">
<clDef type="CAlpha">
<clInst accept="CParent" card="*" name="parents" type="CParent"/>
<clRef accept="CReferencedClass" card="*" name="childRefs" type="CReferencedClass"/>
</clDef>
<clDef type="CReferencedClass"/>
<clDef type="CParent">
<clInst accept="CReferencedClass" card="*" name="childs" type="CReferencedClass"/>
</clDef>
<clInst name="aggregation" type="CAlpha"/>
</grammar>
</source>
|aggregation2_dfg|width=140ch}}

=== {{fr§en_title|Héritage|Inheritance|{{sepLos}}}} ===
{{par2|
{{fr§en
|
|
}}
{{fig||dia_heritage.png|heritage_in_dia}}
{{figuml||
abstract class CAlpha {
}
abstract class CBeta {
}
CBeta --{{!}}> CAlpha
abstract class CGamma {
}
abstract class CDelta {
}
CDelta --{{!}}> CBeta
CDelta --{{!}}> CGamma
|heritage_in_dfg}}
}}
{{Ex|
<source lang="xml">
<clDef her="CAlpha" type="CBeta"/>
</source>
|heritage1_dfg|width=140ch}}
{{Ex|
<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">
<clDef type="CAlpha"/>
<clDef her="CAlpha" type="CBeta"/>
<clDef type="CGamma"/>
<clDef her="CBeta:CGamma" type="CDelta"/>
<clInst name="heritage" type="CAlpha"/>
</grammar>
</source>
|heritage2_dfg|width=140ch}}

== {{fr§en_title|Notations et abréviations|Notations and Abbreviations|{{sepLos}}}} ==
{{par2|
{{fr§en|
* {{m|Def|#E8FFE8}} : définition
* {{m|Ex|#E8FFE8}} : exemple
* {{m|Not|#80FFB0}} : notation
* {{m|§|#E8E8FF}} : paragraphe
* {{m|Rm|#FFD080}} : remarque
|
* {{m|Def|#E8FFE8}} : definition
* {{m|Ex|#E8FFE8}} : example
* {{m|Not|#80FFB0}} : notation
* {{m|§|#E8E8FF}} : paragraph
* {{m|Rm|#FFD080}} : remark
}}
}}

== Références ==
{{minitodo||||{{#atallref:}}}}
{{#atallref:}}

DataFlowGenerator:see too

2026-07-24T17:08:38Z

WikiAdmin : 1 version importée : dfg

<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]
}}

Guide de Référence de DfgUml

2026-07-24T17:08:38Z

WikiAdmin : 1 version importée : dfg

{{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:Versionnement

2026-07-24T17:08:31Z

WikiAdmin : 1 version importée : dfg

=== 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

2026-07-24T17:08:30Z

WikiAdmin : 1 version importée : dfg

{{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:accept

2026-07-24T17:08:30Z

WikiAdmin : 1 version importée : dfg

*{{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:heritances

2026-07-24T17:08:30Z

WikiAdmin : 1 version importée : dfg

*{{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:lhelp

2026-07-24T17:08:30Z

WikiAdmin : 1 version importée : dfg

*{{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:shelp

2026-07-24T17:08:29Z

WikiAdmin : 1 version importée : dfg

*{{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:unit

2026-07-24T17:08:29Z

WikiAdmin : 1 version importée : dfg

*{{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:cardinality

2026-07-24T17:08:29Z

WikiAdmin : 1 version importée : dfg

*{{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:opt

2026-07-24T17:08:29Z

WikiAdmin : 1 version importée : dfg

*{{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:admissible values

2026-07-24T17:08:28Z

WikiAdmin : 1 version importée : dfg

*{{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:default value

2026-07-24T17:08:28Z

WikiAdmin : 1 version importée : dfg

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

DataFlowGenerator:help

2026-07-24T17:08:28Z

WikiAdmin : 1 version importée : dfg

*{{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:name

2026-07-24T17:08:28Z

WikiAdmin : 1 version importée : dfg

*{{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:type

2026-07-24T17:08:28Z

WikiAdmin : 1 version importée : dfg

*{{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:reference

2026-07-24T17:08:28Z

WikiAdmin : 1 version importée : dfg

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:OnlyDefinition

2026-07-24T17:08:27Z

WikiAdmin : 1 version importée : dfg

*{{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 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 : 1 version importée : dfg

{{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}}

Data Flow Generator Web

2026-07-24T17:08:26Z

WikiAdmin : 1 version importée : dfg

{{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 d'utilisation de Data Flow Generator V0

2026-07-24T17:08:26Z

WikiAdmin : 1 version importée : dfg

{{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]]

Tutoriel de Data Flow Generator V0

2026-07-24T17:08:24Z

WikiAdmin : 1 version importée : dfg

{{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 : 1 version importée : dfg

{{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 : 1 version importée : dfg

{{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>

MediaWiki:Sidebar

2026-06-14T18:30:16Z

WikiAdmin :

** randompage-url|randompage
*Α Β Γ Δ Ε Ζ Η Θ Ι Κ Λ Μ Ν Ξ Ο Π Ρ Σ Τ Υ Φ Χ Ψ Ω α β γ δ ε ζ η θ ι κ λ μ ν ξ ο π ρ σ τ υ φ χ ψ ω { } [] ⟨⟩ Æ ∃ ∀ ⊤ ⊥ ¬ ∧ ∨ ⇔ ⇐ ⇒ ≤ ≠ ≥ ∈ ∋ ∉ ⊂ ⊃ ⊄ ⊆ ∪ ∩ ≡ ≝ ≜ 。◊ ∵ ∴ ∞ ℵ ∅∂ ∫ ≈ Δ δ ∇ ± × ÷ ⊗ ⊖ ★ ↦ ⟼ → ⟶
** Symboles mathématiques|Symb. math.
* ⊕ ⊖ ★ ␣ … «…» «» ‘…’ ‘’ “…” “” '…' '' "…" "" „“ ☚ ☛ ☜ ☞ ☟ ☠ ☡ ☢ ← ↑ → ↓ ↔ ↕ ⇄ ⇅ ↲ ↰ ↳ ↱ ◊ ↪ ↩ ⤻ ⤺ ⤹ ⤸ ⤿ ⤾ ⤴ ⤵ ⤷ ⤶ ⮍ ⮏ ⮎ ⮌ ↬, ↫
** Symboles|Symboles
* Boutiques
** https://www.bht-diffusion.com|BHT Diffusion Broderie
** https://www.electra-bike.fr/index.php|BHT Bike
* Mes wiki
** https://at.bht.fr| Racine
** https://at.bht.fr/paintWiki| Peinture
** https://at.bht.fr/musicWiki| Musique
** https://at.bht.fr/astroWiki| Astres
** https://wiki.bht.fr| Wiki
** http://at.bht.fr|Racine
* Admin
** Special:Allpages| Liste des pages
** Spécial:Importer| Importer
** Special:Recentchanges|Mod. réc.
** MediaWiki:Sidebar| MediaWiki:Sidebar
** MediaWiki:Common.css | css
* Astres
** https://www.sunearthtools.com/dp/tools/pos_sun.php?lang=fr&point=48.815122824097436,2.554336120783804#google_vignette | ☀ soleil

MediaWiki:Sidebar

2025-10-08T11:54:30Z

WikiAdmin :

MediaWiki:Timeless.css

2025-10-08T11:48:45Z

WikiAdmin : 1 version importée

/* Tout CSS placé ici sera chargé avec les pages accédées par les utilisateurs de l’habillage Timeless */
/* CSS placed here will affect users of the Timeless skin */

@import url(https://tools-static.wmflabs.org/fontcdn/css?family=Merriweather);
html {
background: rgb(0,0,0) !important;
height: 100%;
font-size: 1.1em;
filter: brightness(100%) contrast(100%) grayscale(0%) !important;
-webkit-filter: brightness(100%) contrast(100%) grayscale(0%) !important;
overflow-x: hidden;
}

body, .wikitable {
margin: 0;
color: #ccccff;
font-family: 'Merriweather', serif;
}
.wikitable > tr > th,
.wikitable > * > tr > th {
background-color:#888;
color: #ccccff;
text-align:center;
}

/*
h1 {
color: white;
text-shadow: 1px 1px 1px #000;
font-size: 40px !important;
}
h1, h2, h3, h4, h5, h6 {
color: #6699ff;
font-family: 'Merriweather', serif;
}
*/
#personal .dropdown b {
font-weight: normal;
}
b, strong {
text-shadow: 1px 1px 1px #000;
}
#f-list {
text-align: center;
font-size: 14px;
}
div.editOptions {
border: #222;
background: #111;
}
#mw-header-nav-hack {
border-top: solid 2px #333;
background: #111;
}
#mw-site-navigation .sidebar-inner {
background: #111;
border: 0;
padding : 0; /* ATMODIF */
}
@media screen and (min-width: 851px) {
#p-logo-text a {
position: fixed;
right: 75vw;
color: #aaaadd; /* ATMODIF */
}
}
@media screen and (max-width: 850px) {
#p-logo-text {
margin-top: 0;
}
}
@media screen and (max-width: 1099px) and (min-width: 851px) {
#p-logo-text a.long {
padding-left: 7px;
float: left;
font-size: 23px !important;
}
}
@media screen and (max-width: 1099px) and (min-width: 851px) {
#mw-related-navigation .sidebar-inner {
background: #111 !important;
border: solid #222;
}
}
@media screen and (max-width: 1099px) and (min-width: 851px) {
#mw-site-navigation .sidebar-inner {
background: #111;
border: solid #222;
}
}
#mw-site-navigation .sidebar-chunk {
border: outset #222;
background: #111;
/* box-shadow: 2px 2px 1px rgba(0,0,0,0.5); */
box-shadow: none ;
border-radius: 3px;
}
@media screen and (max-width: 851px) {
#mw-site-navigation .sidebar-chunk {
/* padding: 0 15px 5px 20px; */
}
}
@media screen and (max-width: 1099px) and (min-width: 851px) {
#mw-site-navigation .sidebar-inner {
background: #111 !important;
border: solid #222 !important;

}
}
.mw-parser-output {
color: #C4C0C8 ; /* org : #ff9900; text default color AT TODO */
}
#searchInput {
padding: 0.2em 4.5em 0.2em 2em !important;
margin: 0;
}
#searchInput-container {
background: #111;
/* height: 35px; ATMODIF */
}
#simpleSearch {
border: inset 1px #000;
border-radius: 3px;
background: #111;
/* height: 35px; ATMODIF */
/* width: 48vw; ATMODIF */
width: 210mm; /* ATMODIF */
position: absolute;
left: 0;
right: 0;
margin-left: auto;
margin-right: auto;
top: 7px;
}
#user-tools {
position: fixed;
right: 86px;
}
@media screen and (min-width: 851px) {
#user-tools {
left: 74vw;
top: 5px;
}

.mw-notification {
background: #111;
border: #222;
background: #111;
border-radius: 5px;
color: #999;
width: 200px;
}
.postedit-container {
position: absolute;
left: 0;
right: 0;
margin-left: auto;
margin-right: auto;
padding: 0;
padding: 15px 0 15px 15px;
text-align: right;
}
.postedit-icon {
margin: auto;
padding: 0;
}
.mw-wiki-logo {
background-size: contain;
}
#mw-header-container {
background: #111;
padding : 0em; /* ATMODIF */
color: #ccccff; /* ATMODIF */
}
#mw-header {
width: 100%;
max-width: 100%;
padding: 0;
position: static;
}
@media screen and (max-width: 850px) {
#menus-cover {
background: #000;
}
}
@media screen and (max-width: 850px) {
#personal h2 {
display: none;searchInput-container
}
}
#mw-content-container {
background: #000;
}
@media screen and (max-width: 850px) {
#mw-content-block {
background: #000;
}
}
@media screen and (max-width: 850px) {
#site-tools h2 {
right: 3em;
top: 0.9em;
padding-bottom: 5px;
}
}
@media screen and (max-width: 850px) {
#p-logo-text a.long {
width: 100%;
top: 7px;
text-align: center;
font-size: 40px !important;
}
}
@media screen and (min-width: 851px) {
#p-logo-text {
width: 29em;
}
}
@media screen and (min-width: 851px) {
#personal h2:after {
width: 1px;
}
}
@media screen and (max-width: 850px) {
#p-logo-text {
position: static;
left: 0 !important;
right: 0;
margin-left: 0;
margin-right: 0;
width: 100%;
top: 3.3em;
}
}
@media only screen and (min-width: 992px) and (max-width:768px) {
#p-logo-text {
right:74vw;
}
}
@media only screen and (min-width: 900px) and (max-width:100px) {
#p-logo-text {
right: 74vw;
top: 3em;
}
}
@media screen and (max-width: 900px) and (min-width: 100px) {
#p-logo-text a.long {
font-size: 43px !important;
}
}
@media screen and (max-width: 1700px) and (min-width: 800px) {
#p-logo-text {
left: 12px !important;
}
}
@media screen and (max-width: 1700px) and (mix: 851px) {
#mw-site-navigation {
background: #000;
}
}

#mw-page-header-links li.selected a {
color: #cccc00;
}
#mw-related-navigation .sidebar-chunk {
background: #111;
border: outset #222;
/* box-shadow: 2px 2px 1px rgba(0,0,0,0.5); */
border-radius: 3px;
}
@media screen and (max-width: 1099px) and (min-width: 851px) {
#mw-related-navigation .sidebar-chunk {
background: #111;
border: outset #222;
/* box-shadow: 2px 2px 1px rgba(0,0,0,0.5); */
border-radius: 3px;
padding: 0 15px 5px 20px;
}
}
.color-middle-container, .ts-inner {
padding: 0;
}
#p-logo-text {
left: 120px;
}
#p-logo-text a.long {
padding-top: 5px;
padding-left: 6px;
font-size: 30px;
text-shadow: 1px 1px 1px #222;
}
#p-search {
width: 70em;
padding-right: 33px;
}
#personal .dropdown h3 {
line-height: 25px;
}
#personal h2 {
text-shadow: 2px 2px 0 #111;
padding-top: 7px;
font-size: 24px;
text-transform: lowercase;
}
#personal .dropdown {
background: #222!important;
border: solid #000;
}
.codeEditor-status {
color: #000;
}
.oo-ui-labelElement-label {
text-shadow: 1px 2px #111;
}
#iframeframe {
height: 700px;
}
#wpSave {
text-shadow: 2px 2px 2px #000 !important
}
#mw-footer-container {
background: #000;
padding-top: 1em;
}
fieldset {
background: #222!important;
border: solid #111;
}
input {
background: #111;
border: solid 1px #111!important;
border-radius: 2px;
padding-left: 5px;
color: #999;
}
.mw-ui-button.mw-ui-progressive, .mw-ui-button.mw-ui-progressive:active, .mw-ui-button.mw-ui-progressive.mw-ui-checked, input[type='submit'], input[type='button'], button {
border: solid 1px #222!important;
border-bottom: 0!important;
text-shadow: 0 0 0 #000 !important;
border-bottom: solid 1px #222!important;
}
.oo-ui-flaggedElement-destructive {
background: #111;
border: 1px solid #444;
color: #FF3333 !important;
padding-left: 15px !important;
padding-right: 15px !important;
}
.oo-ui-flaggedElement-destructive:hover {
background: #222;
color: #CC0000 !important;
}
#searchInput {
border: 0!important;
}
@media screen and (max-width: 850px) {
#searchInput {
padding: 0 0 0 6px !important;
}
}
.oo-ui-textInputWidget input, .oo-ui-textInputWidget textarea {
background-color: #111;
color: #fff;
}
.oo-ui-textInputWidget > .oo-ui-labelElement-label {
line-height: 0.5em;
}
#pagehistory li.selected {
background-color: #555;
}
.warningbox {
background: #1d1d16;
}
.mw-plusminus-neg {
color: #FF0000;
}
#searchButton, #mw-searchButton {
border: 0 !important;
left: 38vw;
right: 0;
margin-left: auto;
margin-right: auto;
}
#mw-footer .footer-places li {
float: right;
display: block;
}
#mw-footer ul, #mw-footer li {
margin: 0 auto;
}
#mw-footer #lastmod {
float: left;
left: 25px;
}
.diff-addedline .diffchange {
background: #1d1d16;
padding-left: 7px;
}
.oo-ui-buttonElement.oo-ui-labelElement > input.oo-ui-buttonElement-button, .oo-ui-buttonElement.oo-ui-labelElement > .oo-ui-buttonElement-button > .oo-ui-labelElement-label {
text-shadow: 0 0 0 #000 !important;
}
.oo-ui-labelElement-label {
text-shadow: 0 0 0 #000
}
.oo-ui-panelLayout-expanded {
background: #222;
}
.oo-ui-messageDialog-message {
color: #999;
}
.oo-ui-buttonElement-frameless.oo-ui-widget-enabled > .oo-ui-buttonElement-button {
color: #999;
}
.oo-ui-messageDialog-actions-horizontal .oo-ui-actionWidget {
border-right: 1px solid #111
}
.oo-ui-dialog-content > .oo-ui-window-body {
outline: 1px solid #111;
}
.oo-ui-messageDialog-content > .oo-ui-window-foot {
outline: 1px solid #111;
}
.wikiEditor-ui .wikiEditor-ui-view {
border: 1px solid #000;
}
.wikiEditor-ui .wikiEditor-ui-top {
border-bottom: 1px solid #000;
}
textarea[style] {
background: #111 !important;
color: #fff;
}
pre, .mw-code {
background: #112;
color: #B0B0B0;
border: 1px solid #444;
}
.oo-ui-iconWidget.oo-ui-iconElement.oo-ui-iconElement-icon {
background-color: #B0B0B0;
border: 1px solid #333;
}

/****************************************************************/
#p-top-label{ padding-left: 0.2em; }
#mw-site-navigation, #mw-related-navigation, .sidebar-chunk, .mw-portlet-body {
margin: 0; padding: 0;
padding-left: 0.1em;
}

@media screen {

.mw-body .mw-parser-output h1::after, .mw-body .mw-parser-output h2::after {
content: '';
display: block;
/* border-bottom: solid 2px #c8ccd1; */
border-bottom: none;
overflow: hidden;
}

#mw-content {
background: #222;
border: solid #946c20;
-webkit-border-bottom-right-radius: 4px;
-webkit-border-bottom-left-radius: 4px;
-moz-border-radius-bottomright: 4px;
-moz-border-radius-bottomleft: 4px;
border-bottom-right-radius: 4px;
border-bottom-left-radius: 4px;
}

/* Personnaliser l'apparence de la barre latérale */
#site-navigation {
background-color: #f0f0f0;
padding: 10px;
border-radius: 5px;
}
#site-tools {
background-color: #e0e0e0;
padding: 10px;
border-radius: 5px;
}

}

.mw-portlet-body { margin-bottom: 0em; } /* ATTODO espace barre latérale */
.mw-portlet-body { margin-bottom: 0em; } /* ATTODO espace barre latérale */
.sidebar-inner { margin-bottom: 0em; } /* ATTODO espace barre latérale */

@media screen and (min-width: 1340px) { /* ATTODO espace barre latérale */
#mw-site-navigation .sidebar-chunk .mw-portlet-body {
margin-bottom: 0em;
}
}

MediaWiki:Sidebar

2025-10-08T08:53:10Z

WikiAdmin :

MediaWiki:Sidebar

2025-10-08T08:52:34Z

WikiAdmin :

** randompage-url|randompage
Α Β Γ Δ Ε Ζ Η Θ Ι Κ Λ Μ Ν Ξ Ο Π Ρ Σ Τ Υ Φ Χ Ψ Ω α β γ δ ε ζ η θ ι κ λ μ ν ξ ο π ρ σ τ υ φ χ ψ ω { } [] ⟨⟩ Æ ∃ ∀ ⊤ ⊥ ¬ ∧ ∨ ⇔ ⇐ ⇒ ≤ ≠ ≥ ∈ ∋ ∉ ⊂ ⊃ ⊄ ⊆ ∪ ∩ ≡ ≝ ≜ 。◊ ∵ ∴ ∞ ℵ ∅∂ ∫ ≈ Δ δ ∇ ± × ÷ ⊗ ⊖ ★ ↦ ⟼ → ⟶
** Symboles mathématiques|Symb. math.
* ⊕ ⊖ ★ ␣ … «…» «» ‘…’ ‘’ “…” “” '…' '' "…" "" „“ ☚ ☛ ☜ ☞ ☟ ☠ ☡ ☢ ← ↑ → ↓ ↔ ↕ ⇄ ⇅ ↲ ↰ ↳ ↱ ◊ ↪ ↩ ⤻ ⤺ ⤹ ⤸ ⤿ ⤾ ⤴ ⤵ ⤷ ⤶ ⮍ ⮏ ⮎ ⮌ ↬, ↫
** Symboles|Symboles
* Boutiques
** https://www.bht-diffusion.com|BHT Diffusion Broderie
** https://www.electra-bike.fr/index.php|BHT Bike
* Mes wiki
** https://at.bht.fr| Racine
** https://at.bht.fr/paintWiki| Peinture
** https://at.bht.fr/musicWiki| Musique
** https://at.bht.fr/astroWiki| Astres
** https://wiki.bht.fr| Wiki
** http://at.bht.fr|Racine
* Admin
** Special:Allpages| Liste des pages
** Spécial:Importer| Importer
** Special:Recentchanges|Mod. réc.
** MediaWiki:Sidebar| MediaWiki:Sidebar
** MediaWiki:Common.css | css

MediaWiki:Sidebar

2025-10-08T08:51:57Z

WikiAdmin :

* randompage-url|randompage
* Α Β Γ Δ Ε Ζ Η Θ Ι Κ Λ Μ Ν Ξ Ο Π Ρ Σ Τ Υ Φ Χ Ψ Ω α β γ δ ε ζ η θ ι κ λ μ ν ξ ο π ρ σ τ υ φ χ ψ ω { } [] ⟨⟩ Æ ∃ ∀ ⊤ ⊥ ¬ ∧ ∨ ⇔ ⇐ ⇒ ≤ ≠ ≥ ∈ ∋ ∉ ⊂ ⊃ ⊄ ⊆ ∪ ∩ ≡ ≝ ≜ 。◊ ∵ ∴ ∞ ℵ ∅∂ ∫ ≈ Δ δ ∇ ± × ÷ ⊗ ⊖ ★ ↦ ⟼ → ⟶
** Symboles mathématiques|Symb. math.
* ⊕ ⊖ ★ ␣ … «…» «» ‘…’ ‘’ “…” “” '…' '' "…" "" „“ ☚ ☛ ☜ ☞ ☟ ☠ ☡ ☢ ← ↑ → ↓ ↔ ↕ ⇄ ⇅ ↲ ↰ ↳ ↱ ◊ ↪ ↩ ⤻ ⤺ ⤹ ⤸ ⤿ ⤾ ⤴ ⤵ ⤷ ⤶ ⮍ ⮏ ⮎ ⮌ ↬, ↫
** Symboles|Symboles
* Boutiques
** https://www.bht-diffusion.com|BHT Diffusion Broderie
** https://www.electra-bike.fr/index.php|BHT Bike
* Mes wiki
** https://at.bht.fr| Racine
** https://at.bht.fr/paintWiki| Peinture
** https://at.bht.fr/musicWiki| Musique
** https://at.bht.fr/astroWiki| Astres
** https://wiki.bht.fr| Wiki
** http://at.bht.fr|Racine
* Admin
** Special:Allpages| Liste des pages
** Spécial:Importer| Importer
** Special:Recentchanges|Mod. réc.
** MediaWiki:Sidebar| MediaWiki:Sidebar
** MediaWiki:Common.css | css

MediaWiki:Sidebar

2025-10-08T08:51:40Z

WikiAdmin :

** randompage-url|randompage
* Α Β Γ Δ Ε Ζ Η Θ Ι Κ Λ Μ Ν Ξ Ο Π Ρ Σ Τ Υ Φ Χ Ψ Ω α β γ δ ε ζ η θ ι κ λ μ ν ξ ο π ρ σ τ υ φ χ ψ ω { } [] ⟨⟩ Æ ∃ ∀ ⊤ ⊥ ¬ ∧ ∨ ⇔ ⇐ ⇒ ≤ ≠ ≥ ∈ ∋ ∉ ⊂ ⊃ ⊄ ⊆ ∪ ∩ ≡ ≝ ≜ 。◊ ∵ ∴ ∞ ℵ ∅∂ ∫ ≈ Δ δ ∇ ± × ÷ ⊗ ⊖ ★ ↦ ⟼ → ⟶
** Symboles mathématiques|Symb. math.
* ⊕ ⊖ ★ ␣ … «…» «» ‘…’ ‘’ “…” “” '…' '' "…" "" „“ ☚ ☛ ☜ ☞ ☟ ☠ ☡ ☢ ← ↑ → ↓ ↔ ↕ ⇄ ⇅ ↲ ↰ ↳ ↱ ◊ ↪ ↩ ⤻ ⤺ ⤹ ⤸ ⤿ ⤾ ⤴ ⤵ ⤷ ⤶ ⮍ ⮏ ⮎ ⮌ ↬, ↫
** Symboles|Symboles
* Boutiques
** https://www.bht-diffusion.com|BHT Diffusion Broderie
** https://www.electra-bike.fr/index.php|BHT Bike
* Mes wiki
** https://at.bht.fr| Racine
** https://at.bht.fr/paintWiki| Peinture
** https://at.bht.fr/musicWiki| Musique
** https://at.bht.fr/astroWiki| Astres
** https://wiki.bht.fr| Wiki
** http://at.bht.fr|Racine
* Admin
** Special:Allpages| Liste des pages
** Spécial:Importer| Importer
** Special:Recentchanges|Mod. réc.
** MediaWiki:Sidebar| MediaWiki:Sidebar
** MediaWiki:Common.css | css

Modèle:MRDo

2024-12-18T12:07:21Z

WikiAdmin : 1 version importée

<includeonly>{{{1}}}</includeonly><noinclude>
{{Model
|class=form
|texte=Mise en forme du texte dans le style {{m|RDo rule to do, to adopt}}.
|syntaxe=<nowiki>{{mRDo|mot}}</nowiki>
|specification=
;texte
:le texte à mettre en forme.
}}
Exemple :

<nowiki>{{mRDo|La vie est belle}}</nowiki>

donnera :

{{mRDo|La vie est belle}}

</noinclude>

Modèle:MAno

2024-12-18T12:07:20Z

WikiAdmin : 1 version importée

<includeonly>{{{1}}}</includeonly><noinclude>
{{Model
|class=form
|texte=Mise en forme du texte dans le style {{m|Ano anomaly}}.
|syntaxe=<nowiki>{{mAno|mot}}</nowiki>
|specification=
;texte
:le texte à mettre en forme.
}}
Exemple :

<nowiki>{{mAno|La vie est belle}}</nowiki>

donnera :

{{mAno|La vie est belle}}

</noinclude>

Modèle:MDef

2024-12-18T12:07:20Z

WikiAdmin : 1 version importée

<includeonly>{{{1}}}</includeonly><noinclude>
{{Model
|class=form
|texte=Mise en forme du texte dans le style {{m|Def definition}}.
|syntaxe=<nowiki>{{mDef|mot}}</nowiki>
|specification=
;texte
:le texte à mettre en forme.
}}
Exemple :

<nowiki>{{mDef|La vie est belle}}</nowiki>

donnera :

{{mDef|La vie est belle}}

</noinclude>

Modèle:MExa

2024-12-18T12:07:20Z

WikiAdmin : 1 version importée

<includeonly>{{{1}}}</includeonly><noinclude>
{{Model
|class=form
|texte=Mise en forme du texte dans le style {{m|Exa example}}.
|syntaxe=<nowiki>{{mExa|mot}}</nowiki>
|specification=
;texte
:le texte à mettre en forme.
}}
Exemple :

<nowiki>{{mExa|La vie est belle}}</nowiki>

donnera :

{{mExa|La vie est belle}}

</noinclude>

Modèle:MExo

2024-12-18T12:07:20Z

WikiAdmin : 1 version importée

<includeonly>{{{1}}}</includeonly><noinclude>
{{Model
|class=form
|texte=Mise en forme du texte dans le style {{m|Exo exercice}}.
|syntaxe=<nowiki>{{mExo|mot}}</nowiki>
|specification=
;texte
:le texte à mettre en forme.
}}
Exemple :

<nowiki>{{mExo|La vie est belle}}</nowiki>

donnera :

{{mExo|La vie est belle}}

</noinclude>