Code_Aster ®
Version
8.1
Titrate:
Rules concerning Structuration of the data
Date:
01/12/05
Author (S):
J. Key PELLET
:
D2.05.01-B Page
: 1/4
Organization (S): EDF-R & D/AMA
Handbook of Descriptif Informatique
D2.05 booklet: -
D2.05.01 document
Rules concerning Structuration of Données
Summary:
We indicate here the rules (and consultings) concerning Structuration of Données (SD):
·
to define new types of SD,
·
with which objects JEVEUX?
The reading of this document supposes the preliminary reading of the document [D4.01.01].
Handbook of Descriptif Informatique
D2.05 booklet: -
HT-66/05/003/A
Code_Aster ®
Version
8.1
Titrate:
Rules concerning Structuration of the data
Date:
01/12/05
Author (S):
J. Key PELLET
:
D2.05.01-B Page
: 2/4
1 Presentation
We indicate here the rules (and consultings) concerning Structuration of Données (SD):
·
to use new types of SD,
·
with which objects JEVEUX?
The reading of this document supposes the preliminary reading of the document [D4.01.01].
2
To define and use new type_SD
1 -
To think “Structures de Données”: not only for Structures de Données
“users” but also for all the objects of work. As soon as one must handle several
objects “at the same time”, to gather them in a type of Structures de Données that one
will document.
2 -
“To consult the asset”:
-
to know the types of existing SD,
-
to measure the adequacy of the types of existing SD to its need,
-
to put the question (and to pose it with the others): is necessary it to modify an existing SD or in
to create a news. In particular, it is necessary to avoid the multiplication of the types of SD
“user”,
-
any modification (or introduction) of type of SD must be discussed in EDA.
3-
To use the names of the types of Structures de Données in the comments of the routines.
Scrupulously to respect for that the orthography of these names [D2.01.02].
To write for example:
SUBROUTINE LOUSE (CART, NETTED)
C IN CART
: NAME Of a SD CARD
C IN NETTED: NAME Of a SD GRID
4 -
To use new suffixes for very new type of Structures de Données. The list of
suffixes currently used is given in [D4.01.02]. For reasons of legibility, one
can also begin its suffixes with a common character string.
Example: SD LISTE_RELA (K19)
suffixes: “.RLCO”, “.RLDD”, “.RLNO”,… (” .RL " --> “linear relation”).
5 -
A suffix must start with one “.” (legibility).
One can use the characters: “A, B,… Z, 0, 1,… 9, _, &.”
6 -
To respect the “standard” lengths for the names of Structures de Données: K8, K14 or
K19.
7 -
Not to multiply objects JEVEUX to make “prettier”:
-
one can store 1 K8 and 1 K24 in a vector of 2 K24
-
Boolean insulated can be coded in an entirety (0 or 1),
-…
Handbook of Descriptif Informatique
D2.05 booklet: -
HT-66/05/003/A
Code_Aster ®
Version
8.1
Titrate:
Rules concerning Structuration of the data
Date:
01/12/05
Author (S):
J. Key PELLET
:
D2.05.01-B Page
: 3/4
8 -
When one “begins” the structuring (for the types of Structures de Données moreover low
level), to use the longest names (K19) to be able later on to create the new ones
type of Structures de Données the container. (i.e to begin the suffixes “with the line”).
Example:
type_1er (K19) record
“.T1 AA”:
OJB
…
“.T1 BB”:
OJB
…
type_2nd (K14) record
“.T2AT1”
:
type_1er
…
The type of SD type_1er can be used as article of the type_2nd type.
9 -
To think of the references “upstream”: it is sometimes useful to store in Structure of
Data the names of Structures de Données which gave him birth. This supposes
that these Structures de Données are perennial (have an image in the base
“GLOBALE”).
10 -
To avoid the redundancies within a type of Structures de Données, because the update
becomes more problematic. Bad example: listr8 (list of realities) where one stores at the same time
the complete list of realities and the list of the intervals of constant step (one of objects (.VALE)
can constantly be recomputed with the others).
11 -
When one declares types of Structures de Données “caps”, for example:
type_1 (K8)::= record
/
$VIDE
:
type_2
/
$VIDE
:
type_3
it should be made sure that there is a means “of crossing” them”/“; i.e. to know to recognize
if Structure de Données is of type_2 type or type_3.
12 - Problem
“Hidden” SD:
It happens sometimes that a SD stores the name of other SD (for example, the SD_RESULTAT stores
in its object .TACH the name of the fields which make the SD_RESULTAT). When SD
referred is unknown (or hidden) of the user (it is the case of the fields of
SD_RESULTAT), it is necessary to find a name for these referred SD.
The following rule will be adopted:
If one must name a hidden SD that one reference in a SD user named NOMU
(K8), one will give to this hidden SD a name starting with NOMU.
Thanks to the compliance with this rule, command DETRUIRE/CONCEPT=NOMU will destroy
correctly TOUS objects JEVEUX created by the command having created NOMU.
To obtain a name of hidden SD complying with this rule, one can use the routine
GNOMSD.
Handbook of Descriptif Informatique
D2.05 booklet: -
HT-66/05/003/A
Code_Aster ®
Version
8.1
Titrate:
Rules concerning Structuration of the data
Date:
01/12/05
Author (S):
J. Key PELLET
:
D2.05.01-B Page
: 4/4
3
Basic objects JEVEUX
1 -
Not to use attribute “DOCU” of the OJB.
2 -
To try not to use “LONUTI”: one will in general seek to allocate “with just” them
objects. In this case, “LONUTI'=' LONMAX”.
To use attribute “LONUTI advisedly”: it is with the user to update it; one should not
he to give another significance that his: length really used of a vector.
3 -
For the collections which one knows that they will be never very large, it is preferable of
to create contiguous. In the contrary case, they should be created dispersed.
It will be said that a collection (or an object) is large if:
-
its volume can be higher than 1Méga word,
-
or if its volume can be higher than 10 times the number of ddls of the model.
4 -
Not to use the pointers (name or length) shared between several collections.
If (for example) 2 collections must be reached by the same names, one can make:
-
to create a pointer of names,
-
to create the collections in “numbered” access
- to make
JENONU before the access to the collections.
5 -
Not to store in OJB of the addresses memory of other OJB (because an address
memory is by “temporary” definition). One does it for the type of Structures de Données
mater_code and for well identified reasons of performance, but that must remain
exceptional.
Handbook of Descriptif Informatique
D2.05 booklet: -
HT-66/05/003/A