Différences entre les versions de « Guide de Référence de DfgUml »
toross>WikiAdmin |
m (1 version importée : dfg) |
(Aucune différence)
| |
Version actuelle datée du 24 juillet 2026 à 19:08
|
| 🚧 |
|
1 Notations et abréviations
§-n : Paragraphe numéroté de 15cm de large ☞§-n
§-n : Paragraphe numéroté de 18cm de large ☞§-n
§ : Paragraphe non numéroté de 15cm de large ☞§
Def-n : Définition ☞Def
Not-n : Notation ☞Not
Rqe-n : Remarque ☞Rqe
Que-n : Question ☞Que
Qup-n : Question importante ☞Qup
Exa-n : Exemple ☞Exa
Exo-n : Exercice ☞Exo
tdo-n : A faire ☞Tdo « to do »
Ano-n : Anomalie ☞Ano
RDo-n : Règle à appliquer ☞RDo « Rule do »
RDn-n : Règle à ne pas suivre ☞RDn « Rule do not»
Csl-n : Style de code ☞Csl
2 Les prérequis pour lire ce document
Le meta-modèle utilise le langage XML (Lien vers un tutoriel sur XML).
Au dessus du langage XML le méta-modèle décrit des diagrammes de classes du langage UML (Lien vers un tutoriel sur UML).
Il faut donc connaître les langages XML et UML pour lire ce document.
3 Le langage XML
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.
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 balises(tags).
3.1 Balise ouvrante
Une balise dite ouvrante est un texte commençant le symbole <(plus petit), suivi du nom de balise puis des attributs de la balise. Elle se termine par le symbole >(plus grand).
Les attributs suivent la syntaxe suivante :
attributeName2="AttributeValue2"
par exemple :
color="green"
Et la structure générale d'une balise ouvrante est :
<baliseName attributeName1="AttributeValue1"
attributeName2="AttributeValue2"
…
attributeNamen="AttributeValuen">
<city name="Paris">
3.2 Balise fermante
Une balise dite fermante est un texte commençant le symbole <, puis /, suivi du nom de balise et se terminant par le symbole >(plus grand).
</baliseName>
</city>
3.3 Balise ouvrante et fermante
Une balise ouvrante et fermante est une balise ouvrante qui ne se termine pas par > mais par />.
<baliseName attributeName1="AttributeValue1" attributeName2="AttributeValue2" … attributeNamen="AttributeValuen"/>
<city name="Paris"/>
3.4 Nœud
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
<city id="AR32"> <name>Paris</name> … </city>
L'en-tête d'un nœud est l'ensemble des attributs de la balise.
Le corps d'un nœud est la partie du texte qui se trouve entre la balise ouvrante et la balise fermante correspondante.
Le corps d'un nœud où la balise est ouvrante et fermante possède un corps vide.
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.
<russian_doll name="Galina">
<russian_doll name=" Anastasiya">
<russian_doll name=" Marta"/>
</russian_doll>
</russian_doll>
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.
<city name="Paris"> … </city>
<city> <name>Paris</name> … </city>
4 Le modèle vide
Le modèle minimal de Data Flow Generator est donné par l'exemple ↬empty_model_ref
<?xml version="1.0" encoding="UTF8"?>
<grammar type="xml" version="2.0.0" fileFormatVersion="1.0.0">
</grammar>
Ce modèle est composé de deux éléments XML; ?xml↬par_xml_ref et grammar↬par_grammar_ref.
Le document DfgUml doit comporter un unique nœud racine nommé grammar↬par_grammar_ref.
Le diagramme de classes de ce modèle est le diagramme vide.
5 Le modèle minimal
Tout modèle doit définir un unique nœud racine à l'aide du nœud nommé clDefInst.
Dans les exemples ↬dfguml_minimal_model et ↬dfg_ex_minimal, qui illustrent le modèle minimal, la racine a pour nom «model» et nous avons nommé sa classe «CModel».
<?xml version="1.0" encoding="UTF8"?>
<grammar type="xml" version="2.0.0" fileFormatVersion="1.0.0">
<clDefInst type='CModel' name="model" >
</clDefInst>
</grammar>
 |
6 Les nœuds, associations et héritages du méta-modèle
6.1 Liste des nœuds
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 : bool, int, flt, str, date, clDefInst, clInst, clRef, clDef, method, arg. Les types primitives sont bool (booléen), int(entier), flt(réel), str(chaîne de caractères), date(date).
6.2 Association entre classes
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 1 et côté enfant l'attribut card permet de le définir avec la convention suivante :
Soient n, n1, n2 des entiers
| notation dans les doubles quottes | description |
|---|---|
| "n1:n2" | de n1 à n2 |
| "?" or "0:1" | de 0 à 1, optionnel |
| "*" or "0:*" | de 0 à l'infini |
| "+" or "1:*" | de 1 à l'infini |
| "n:" or "n:*" | de n à l'infini |
| "n" or "n:n" | de n à n, exactement n |
| si non présent | valeur de défaut : exactement 1 |
T n°1: Notation de cardinalité
Voici un exemple d'associations entre la classe A et les classes B,C,D,E,F,G.
<?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>
Le diagramme UML équivalent est le suivant :
 |
Et une instance persitante possible de ce modèle utilisant le format XML peut être le fichier suivant :
<?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>
<b/>
<c/>
<c/>
<c/>
<c/>
<f/>
<g/>
<g/>
<g/>
</a>
</grammar>
6.3 Héritage
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 ↬Héritage simple.
 |
L'équivalent en modèle DFGUML sécrira :
<?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>
Et une instance possible de ce modèle est la suivante :
<?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>
<b>2</b>
<c>3</c>
</c>
<c>
<a>1</a>
<b>2</b>
<c>3</c>
</c>
<c>
<a>1</a>
<b>2</b>
<c>3</c>
</c>
</root>
</grammar>
L'héritage est définie avec l'attribut 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 clDef comme c'est le cas des classes A et B dans notre cas précédent.
7 Les éléments
===
|
===
L'élément <?xml … ?> fait partie du langage XML même. Il possède les attributs version↬ref_xml_version et encoding↬ref_xml_encoding.
<?xml version="1.0" encoding="UTF8"?>
<grammar type="xml" version="2.0.0" fileFormatVersion="1.0.0">
<clDefInst name="root" type="CRoot">
</clDefInst>
</grammar>
Le diagramme UML de l'exemple ↬exa-11 est donné par ↬plantumlr_xml, qui n'est réduit qu'une seule classe; la classe racine.
 |
===
|
===
L'attribut version du nœud «?xml»↬§-15 est la version du XML utilisé, sa valeur est toujours «1.0».
===
|
===
Et l'attribut encoding du nœud «?xml»↬§-15 est le type de l'encodage du fichier texte, ce type a toujours la valeur «UTF-8».
===
|
===
Le nœud 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.
Il possède les attributs type, version et fileFormatVersion.
L'attribut type est le nom de la classe correspondante qui a toujours la valeur xml.
L'attribut version est la version du méta-modèle (ou grammaire). La version actuelle est «2.0.0».
L'attribut 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 Annexe.
<?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>
8 Annexe
8.1 Description du mét-modèle par lui-même
<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:
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,)
8.2 Application versioning
- R-V1.V2.V3.V4
- The identification consists of:
- 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):
- 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;
- pre-alpha or rpa
- delivery made before the end of development and after integration tests. Distribution can be used between development integration testing teams;
- alpha or ra
- delivery made to the test team for System tests;
- beta or rb
- delivery made to a small number of users for User Acceptance Tests(UAT);
- gamma_n or rcn
- delivery also called "Release Candidate" number n, after nth UAT;
- prod, gold, ou 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).
- V1
- a number that indicates the evolution of the system architecture and/or a large number of functional changes;
- V2
- a number that indicates the evolution of the functions provided by the application;
- V3
- a number that indicates the evolution of implementations of functions;
- V4
- a number, optional, which indicates the integration of bugfixes.
- R (release) xn pre-alpha alpha beta gamma/rcn prod/gold/live_release
8.3 Grammar/File Format versioning
- grV1.grV2.grV3 / flV1.flV2.flV3
- xxV1 changes that can not keep backward compatibility when reading
- xxV2 developments that maintain backward compatibility when reading
- xxV3 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.
8.4 Driver versioning (python or c++)
- For each grammar main version number, which is grV1, a new driver versioning starts.
- drV1.drV2.drV3
- drV1 major modifications
- drV2 minor modifications
- drV3 bug corrections
9 Scripts d'utilisation
#!/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
#!/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
9.1 Liens externes
- Structure d'un document XML
