%
%     This file is part of the Code_Saturne Preprocessor, element of the
%     Code_Saturne CFD tool.
%
%     Copyright (C) 1998-2007 EDF S.A., France
%
%     contact: saturne-support@edf.fr
%
%     The Code_Saturne Preprocessor is free software; you can redistribute it
%     and/or modify it under the terms of the GNU General Public License
%     as published by the Free Software Foundation; either version 2 of
%     the License, or (at your option) any later version.
%
%     The Code_Saturne Preprocessor is distributed in the hope that it will be
%     useful, but WITHOUT ANY WARRANTY; without even the implied warranty
%     of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
%     GNU General Public License for more details.
%
%     You should have received a copy of the GNU General Public License
%     along with the Code_Saturne Preprocessor; if not, write to the
%     Free Software Foundation, Inc.,
%     51 Franklin St, Fifth Floor,
%     Boston, MA  02110-1301  USA
%

\section{Implémentation et configuration logicielle en langage~C
  \label{cha:implementation}}


Au premier abord, il peut sembler paradoxal d'implémenter
une approche objet avec un langage \og non objet \fg, comme le~C.

En fait, grâce aux macro-instructions et pointeurs de fonctions du~C,
il est possible d'implémenter
la plupart des notions objets (y compris des notions
comme l'\herit, la généricité, etc.).

Mais à vouloir coller de trop près à une programmation \og objet \fg,
le codage devient vite lourd à mettre en \oe{}uvre.
En s'écartant ainsi de la programmation en~C traditionnelle,
on risque de compromettre la lisibilité et la maintenabilité
du programme.

Du coup, le choix du langage~C par rapport au langage objet~C++,
peut paraître surprenant. Cependant, le C dispose encore de plusieurs avantages
sur le C++~: son interfaces binaire est mieux standardisée (i.e. des fichiers
objets ou librairies compilés sur une même architecture avec des compilateurs
différents peuvent être liés), et surtout, il est nettement plus simple, ce
qui fait à la fois que les compilateurs C sont souvent plus fiables que
certains compilateurs C++. Surtout, son apprentissage est plus rapide et aisé.

Ce qui importe le plus pour nous, c'est la possibilité de regrouper des données
dans une même structure. Le langage C possédant la notion de structures,
l'encapsulation de données ne pose pas de problèmes.
Nous ne cherchons pas à utiliser des relations d'héritage, et utilisons plutôt
des attributs pour indiquer quel comportement une méthode doit adopter pour
une structure donnée.

Dans le \pcs, on a donc choisi, en toute connaissance de cause, de rester dans
le cadre d'une programmation classique en~C, et d'implémenter uniquement les
notions fondamentales d'une approche objet qui sont utiles ici.

Ce chapitre expose l'architecture logicielle du \pcs,
construite à partir de la modélisation objet du chapitre précédent.
Il insiste aussi sur la manière dont les concepts objets
sont pris en compte dans le \pcs,
afin que tout développement à venir respecte
la structure objet du \pcs.


\subsection{Implémentation en~C\label{sec:implementation}}


\subsubsection{Approche objet\label{sec:implementation.approche}}


\paragraph{Modularité\label{sec:implementation.approche.modularite}}

La complexité d'un logiciel peut être réduite en partitionnant le programme
en parties relativement indépendantes (appelées \modules),
qui peuvent être appréhendées seules, avec quelques références
aux autres parties du programme.

Un \module exporte vis-à-vis de l'extérieur des informations qui sont contenues
dans son interface.

\paragraph{Encapsulation et masquage de l'information%
\label{sec:implementation.approche.encapsulation}}

À ce niveau de discussion, l'\encaps et le \masquage
peuvent se définir comme un seul principe~:
\begin{quote}
un \module doit rendre inaccessible de l'extérieur les données
qu'il manipule et ne peut rendre visibles aux autres \modules
qu'un ensemble de services contenus dans son interface.
\end{quote}

Par conséquent, une information gérée par un \module ne sera jamais
modifiable par les autres \modules, mais pourra être consultable
si l'interface du \module déclare une fonction qui exporte cette information.

L'avantage de la mise en application de ce principe est de dissimuler
aux autres \modules la représentation des données manipulées par
un \module, et donc de forcer un \module à utiliser une méthode (ou un
sous-programme) bien identifiée pour pouvoir accéder aux données d'un autre
\module.  Une modification de la représentation des données d'un \module ne
devrait avoir que de faibles conséquences sur les autres \modules.

\paragraph{Classification\label{sec:implementation.approche.classification}}

L'approche objet est basée sur le regroupement des données et des traitements.
Les données et les fonctions qui utilisent ou modifient ces données,
sont regroupées dans des unités appelées \classes.

Les données sont alors représentées par les \attributs de la \classe,
et les fonctions sont les \methodes de la \classe.

Une \classe est associée à un \module, et le principe de \masquage
appliqué à une \classe, consiste à rendre les \attributs
inaccessibles à l'extérieur de la \classe et seules les \methodes
de la \classe sont autorisées à manipuler explicitement les \attributs.
L'implémentation des \methodes reste cachée et seules les déclarations
des \methodes sont connues à l'extérieur de la \classe.


\subsubsection{Approche objet en~C\label{sec:implementation.C}}


\paragraph{Module\label{sec:implementation.C.module}}

Le langage~C (comme le~C++) impose d'identifier la notion de \module
à celle de fichier, celui-ci étant l'unité de compilation
du langage.

Une interface est implémentée en~C sous la forme de fichier à inclure
(fichier avec l'extension \og .h \fg).\\
Les relations d'inclusion en~C (\fc{\#include}) sont transitives~:
il est donc possible d'importer par transitivité une interface
de \module qui n'est pas utile.\\
Le corps du \module sera un fichier source (fichier avec l'extension \og .c \fg)
n'exportant rien.


\paragraph{Classe\label{sec:implementation.C.classe}}

Une \classe définie lors de la conception est transformée en structure~C
(\fc{struct}).

Chaque \attribut défini dans la \classe devient un membre de la structure.

Une référence sur un objet instance d'une \classe peut être
représentée par un pointeur sur une variable de type la structure
correspondante à la \classe.

Une \methode de \classe possède un argument implicite~: l'objet
sur lequel s'applique la \methode (\fc{this} en~C++).
Dans un langage non objet comme le~C, cet argument doit être rendu explicite.

Les \methodes relatives à une \classe peuvent être transformées en~C
sous la forme de pointeurs de fonction, membres de la structure
correspondante à la \classe.
On retrouve de cette façon la notation pointée du~C++~:
\fc{objet.méthode()}.\\
La création de pointeurs de fonction pour implémenter
les \methodes de \classe peut s'avérer lourde à mettre en place
et leur emploi systématique lourd à utiliser.\\
Une autre solution consiste à utiliser une convention de nommage
pour les fonctions~:
par exemple, en préfixant le nom des fonctions liées à une structure
par le nom de la structure.

\paragraph{Encapsulation et masquage de l'information%
\label{sec:implementation.C.encapsulation}}

Le langage~C offre la possibilité de déclarer un nouveau type structure,
sans en donner sa définition.\\
Dans un fichier, une instruction du type\\
\hspace*{2truecm}\fc{struct \_structure;}\\
est valide en~C, même si le type \fc{\_structure}
n'est pas défini dans ce fichier.

Dans tous les fichiers où ce type est déclaré mais dont la définition
reste inconnue, il ne sera possible que d'utiliser des pointeurs
sur des variables ayant ce type.\\
Cela n'est en rien gênant~: on utilisera toujours un pointeur
sur une variable de type structure,
même dans les fonctions qui extraient simplement
de l'information d'une structure, sans la modifier. D'ailleurs, en~C,
il est toujours plus efficace de passer en argument un pointeur
sur une structure plutôt que la structure elle-même.

Bien entendu, dans les fichiers qui contiennent les fonctions
créant ou modifiant une variable de ce type,
il faudra nécessairement que ce type soit défini.

Le \masquage peut donc être assuré en~C~:
dans un fichier qui contient les implémentations des \methodes de la \classe,
on inclura la définition de la nouvelle structure implémentant
la \classe~; inversement, la définition de la nouvelle structure
ne sera incluse que dans les fichiers contenant les implémentations
des \methodes.\\
Dans le fichier à inclure jouant le rôle d'interface et contenant les
déclarations des \methodes, ne figurera que la déclaration de la nouvelle
structure.


\subsubsection{Implémentation de l'approche objet dans le \pcs%
\label{sec:implementation.env}}


\paragraph{Masquage de l'information%
\label{sec.implementation.env.encapsulation}}

L'implémentation d'une classe et du principe de \masquage,
suit une méthode identique pour toutes les classes répertoriées
au chapitre~\ref{cha:classe}.

Par conséquent, on décrit ci-dessous la méthode d'implémentation
pour une classe de nom générique \Classe.
À cette classe, correspond la structure~C~: \classet.

\begin{enumerate}
\item On déclare la structure \classet dans un fichier \og .h \fg
dit public (\classet est en fait défini sous la forme
d'un alias sur la structure proprement dite (\fc{\_\classet})
grâce à l'instruction \fc{typedef},
de manière à s'affranchir du mot clé \fc{struct}). On a dans
{\tt ecs\_classe.h}~:

\begin{quote}
\begin{alltt}
#ifndef _ECS_CLASSE_H_
#define _ECS_CLASSE_H_
/*
 * Declaration de la structure
 */
typedef struct _ecs_classe_t ecs_classe_t;

#endif /* _ECS_CLASSE_H_ */
\end{alltt}
\end{quote}

\item On définit la structure \classet dans un fichier \og .h \fg dit privé
({\tt ecs\_classe\_\_priv.h})~:

\begin{quote}
\begin{alltt}
#ifndef _ECS_CLASSE_PRIV_H_
#define _ECS_CLASSE_PRIV_H_
#include "ecs_classe.h"
/*
 *  Definition de la structure
 */
struct _ecs_classe_t \{
   type_membre1 membre1;
   type_membre2 membre2;
   \( /* etc. */ \)
\};
#endif /* _ECS_CLASSE_PRIV_H_ */
\end{alltt}
\end{quote}

\item Tout fichier incluant \classepriv aura accès aux membres de la structure
\classet~: ce fichier doit donc être forcément un fichier \og .c \fg
implémentant les \methodes de la \classe \Classe.

\item Tout fichier incluant \classepubl pourra utiliser un pointeur
sur une variable de type \classet.

\item Une structure ou classe simple ne comportant pas d'élément privé sera
définie dans un fichier \og .h \fg global ({\tt ecs\_classe\_\_glob.h}).

\end{enumerate}


\paragraph{Relations entre classes%
\label{sec.implementation.env.relation}}

On donne ici un bref aperçu sur la manière dont sont implémentées
les relations entre \classes. Dans la section~\ref{sec:structure}
on explicitera pour chaque \classe, les implémentations des
relations de la \classe.

\underline{Relation de composition%
\label{sec.implementation.env.relation.composition}}

Exemple~: relations entre la \classe \Maillage et les \classes
\Entite et \Famille.\\
C'est le type de relation le plus fréquemment utilisé entre les \classes
du \pcs.

Implémentation~: la \classe composite référence
explicitement la \classe composante
(la structure composite référence explicitement le pointeur sur
la structure composante).

\underline{Relation d'agrégation%
\label{sec.implementation.env.relation.agregation}}

Les seules relations d'\agreg sont les relations qui
mettent en jeu la \classe \Descripteur.

Elles seront implémentées sous forme de relations de \compo
comme on l'indique dans la section~\ref{sec:structure.descr}.


\underline{Relation d'association%
\label{sec.implementation.env.relation.association}}

Deux relations d'\assoc ont été mentionnées dans les
diagrammes de relations de \classes~:
\begin{liste}
\item la relation entre la \classe \Famille et la \classe \ChampFam~;
\item la relation entre la \classe \Champ et la \classe \Vect.
\end{liste}

Ces relations d'\assoc lient faiblement les \classes
concernées et ne sont pas implémentées.\\
La contrepartie de ce choix impose de s'assurer que les \classes
associées n'existent que si la \classe ayant la multiplicité 1 existe.

\underline{Relation de généralisation%
\label{sec.implementation.env.relation.gener}}


L'\herit ne sera pas implémenté en tant que tel dans le \pcs,
pour les raisons déjà évoquées dans l'introduction du chapitre.

On précisera, pour chaque structure~C comment
les relations de \gener entre super-\classe et sous-\classes
ont été résolues.

La méthode consistera~:
\begin{liste}
\item soit à supprimer un niveau de \gener,
\item soit à remonter les \attributs des sous-\classes dans la super-\classe~;\\
  (Dans ce cas, si l'\attribut ne concerne pas une \classe concrète,
  il lui sera affecté une valeur par défaut.
  Par exemple pour les pointeurs, les \attributs non utilisés
  dans une structure~C se verront affecter un pointeur NULL.)
\item soit à créer un nouvel \attribut permettant de différencier
  les sous-\classes.
\end{liste}

\subsection{Configuration logicielle\label{sec:config}}


\subsubsection{Organisation du \pcs en sous-systèmes\label{sec:config.sssys}}


Le système \pcs est organisé en quatre sous-systèmes~:
\begin{liste}
\item \Application~: contient essentiellement
le point d'entrée de l'application
(programme principal \fc{main()})~;
\item \Base~: contient l'ensemble des fichiers
servant à modéliser la représentation interne des données du \pcs~;
\item \Prepost~: contient l'ensemble des fichiers
servant, soit à convertir la représentation interne des données du \pcs
dans un format de sortie, soit, inversement, à convertir un format de données
d'entrée dans la représentation interne des données du \pcs~;
\item \Utilitaire~: contient l'ensemble des fichiers
implémentant les fonctions utilitaires de bas-niveau.
\end{liste}

Dans le schéma ci-dessous,
un sous-système est représenté sous forme de \paquet \uml.

\begin{figfloat}
\begin{center}
\includegraphics*[width=3.349in]{\repgraphics/uml_sous-systeme.\extgraphics}
\captionfloat{Organisation du \pcs en sous-systèmes
\label{fig:config.sssys}}
\end{center}
\end{figfloat}

Les relations de dépendance entre sous-systèmes sont des relations
stéréotypées \fcla{\og importe \fg}.

Les sous-systèmes ont des relations de visibilité,
dans le sens où un fichier du sous-système
qui importe un autre sous-système a la possibilité
d'inclure des fichiers de déclaration du sous-système importé.

Le cas du \paquet \Utilitaire est particulier, sa valeur marquée
\fcla{\{global\}} indique qu'il est visible
de tous les autres sous-systèmes.


\subsubsection{Visibilité des classes\label{sec:config.visibilite}}


Afin d'affiner l'architecture logicielle du \pcs,
chacun des deux sous-systèmes \Base et \Prepost
est organisé de façon à ce qu'une structure n'ait qu'une visibilité
restreinte sur les autres structures.

A chaque structure on associe un \paquet contenant les fichiers
qui déclarent et définissent les structures, ainsi que les fichiers
qui implémentent les \methodes.

Le sous-système \Base se décompose de la manière indiquée
sur la Figure~\ref{fig:config.sssys.base}, page \pageref{fig:config.sssys.base}.
Les \paquets sont nommés de manière à rappeler qu'ils contiennent les fichiers
implémentant les \classes définies au chapitre~\ref{cha:classe}.

Les dépendances entre \paquets sont matérialisées par des
relations de dépendance \textbf{non transitives}
(stéréotypées par défaut avec le stéréotype prédéfini par \uml,
\fcla{\og accède \fg}).\\
Certaines sont explicitement stéréotypées \fcla{\og association \fg}.
La signification de ce stéréotype non prédéfini est donné plus loin.

Chaque \paquet englobant les fichiers liés à une structure n'a la
connaissance que des interfaces des \paquets auxquels il accède~:
par exemple, un fichier du \paquet \Entite ne pourra inclure
que les fichiers déclarés visibles des \paquets \Famille et \Champ.

Le \paquet \Maillage est quant à lui directement relié
au sous-système \Application, par l'intermédiaire du programme principal
\reffig{fig:config.sssys}.

\begin{figfloat}
\begin{center}
\includegraphics*[width=5.787in]
  {\repgraphics/uml_sous-systeme_base.\extgraphics}
\captionfloat{Relations de dépendances entre structures
  \label{fig:config.sssys.base}}
\end{center}
\end{figfloat}


\paragraph{Règles de visibilité intra-\paquet%
\label{sec:config.visibilite.intra}}

Un \paquet lié à une structure de nom générique \classet,
est composé des fichiers types suivants~:

\begin{figfloat}
\begin{center}
\includegraphics*[width=1.984in]
  {\repgraphics/uml_visibilite_classe_intra.\extgraphics}
\captionfloat{Fichiers types d'un \paquet
  \label{fig:visibilite.classe.intra}}
\end{center}
\end{figfloat}

Les fichiers du \paquet \Classe, visibles par un \paquet qui accède
au \paquet \Classe, sont précédés du caractère~$+$.
Les fichiers précédés du caractère~$-$ ne sont jamais visibles
à l'extérieur du \paquet.

Le fichier \classesuffc
représente de manière générique l'ensemble
des fichiers \og .c \fg implémentant les fonctions liées à la structure
\classet (les \methodes de la \classe \Classe).
Son fichier \fc{include} associé, \classesuffh, déclare
les prototypes des fonctions du fichier \classesuffc (et implémente
l'interface de la \classe).

On donne ci-dessous les règles précises de visibilité entre fichiers
du \paquet.

\begin{regle}{Règle}
\item le fichier \classepubl n'inclut aucun fichier
\item le fichier \classepriv peut inclure \classepubl\\
  (si \classepubl contient des énumérations utiles\\
  à \classepriv et utilisées en dehors du \paquet)
\item les fichiers du type
  \classesuffh n'incluent que \classepubl
\item les fichiers du type
  \classesuffc incluent~:
  \begin{liste}
    \item \classepubl,
    \item \classepriv,
    \item \classesuffh.
    \end{liste}
\end{regle}


\paragraph{Règles de visibilité inter-\paquets%
\label{sec:config.visibilite.inter}}



Considérons le cas suivant d'un \paquet \Classe qui accède
au \paquet \Classeacc~:

\begin{figfloat}
\begin{center}
\includegraphics*[width=5.827in]
  {\repgraphics/uml_visibilite_classe_inter.\extgraphics}
\captionfloat{Relation type de dépendance entre \paquets
  \label{fig:visibilite.classe.inter}}
\end{center}
\end{figfloat}

La figure~\ref{fig:config.sssys.base} montre 2 types de relation entre
\paquets~:
\begin{liste}
\item une relation de dépendance non stéréotypée représente
  une relation forte entre les 2 \paquets~:
  la structure \classet contient explicitement une référence à la
  structure \classeacct~;
\item une relation de dépendance stéréotypée \fcla{\og association \fg}
  représente une relation faible entre les 2 \paquets~:
  la structure \classet ne référence pas \classeacct, seules les fonctions
  liées à \classet référencent en argument la structure \classeacct.
\end{liste}

Les règles d'inclusion pour les fichiers de \Classe
par rapport aux fichiers de \Classeacc sont plus ou moins fortes
suivant l'un ou l'autre type de relation de dépendance.

Les règles d'inclusion pour les fichiers de \Classe
par rapport aux fichiers de \Classeacc
sont les suivantes~:

\begin{regle}{Règle}
\item le fichier \classepubl n'inclut aucun fichier de \Classeacc
\item le fichier \classepriv n'inclut
  \begin{liste}
    \item pour une relation de dépendance non stéréotypée~:\\
      que \classeaccpubl

    \item pour une relation de dépendance stéréotypée
      \fcla{\og association \fg}~:\\
      aucun fichier de \Classeacc
      \end{liste}
\item les fichiers du type \classesuffh n'incluent que\\ \classeaccpubl
\item les fichiers du type \classesuffc n'incluent que~:
  \begin{liste}
    \item \classeaccpubl
    \item \classeaccsuffh
    \end{liste}
\end{regle}


Certaines relations indiquées sur la figure~\ref{fig:config.sssys.base}
représentent une dépendance très faible entre les \paquets.
C'est le cas des 2 relations stéréotypées \fcla{\og association \fg}
suivantes~:
\begin{liste}
\item \paquet \Champ dépendant du \paquet \Famille~;
\item \paquet \Entite dépendant du \paquet \Famille.
\end{liste}
Dans ces 2 cas, seules 2 fonctions des \paquets dépendants
utilisent une structure \famillet en argument.


\subsection{Correspondance entre structures~C et classes\label{sec:structure}}


Cette section décrit les structures~C qui ont été choisies
pour implémenter les \classes.

Pour établir le parallèle entre \classe et structure~C,
on se référera constamment au chapitre~\ref{cha:classe}.


\subsubsection{Types de base\label{sec:struct.base}}


On donne ci-dessous les types de base définis dans le \pcs.

Ils serviront à typer les membres des structures~C.

Le premier cadre regroupe les types de base qui ne sont qu'une redéfinition
des types primitifs du~C, ainsi que les énumérations globales au code.

Le second cadre introduit un type \tableau pour chacun des 4 types fondamentaux
(entier, réel, chaîne de caractères et booléen)
qui permet d'associer à un tableau de valeurs le nombre de valeurs du tableau.


\begin{structure}{Types de base (1)}{\typepriv\label{struct:type}}
typedef int        ecs_int_32_t;   /* Entier sur 4 octets */
typedef double     ecs_real_32_t;  /* Réel (virgule flottante) sur 4 octets */
typedef int        ecs_int_t;      /* Entier (taille par défaut) */
typedef unsigned   ecs_size_t;     /* Taille pour les index */
typedef double     ecs_real_t;     /* Réel (virgule flottante,
                                            double par défaut) */
typedef char       ecs_byte_t;     /* Octet (unité de mémoire non typée) */
typedef ecs_real_t ecs_point_t[3]; /* Points ou vecteurs en 3D */

typedef enum \{ ECS_TYPE_char,
               ECS_TYPE_bool,
               ECS_TYPE_ecs_int_t,
               ECS_TYPE_ecs_int_32_t,
               ECS_TYPE_ecs_point_t
               ECS_TYPE_ecs_real_t,
               ECS_TYPE_ecs_real_32_t,
               ECS_TYPE_void,
             \} ecs_type_t;          /* Énumération des différents types */

\end{structure}


\begin{structure}{Types de base (2)}{\tabglob\label{struct:type.tab}}
typedef struct \{ size_t        nbr;
                 ecs_int_t    *val;
\} ecs_tab_int_t;

typedef struct \{ size_t        nbr;
                 ecs_real_t   *val;
\} ecs_tab_real_t;

typedef struct \{ size_t        nbr;
                 char        **val;
\} ecs_tab_char_t;

typedef struct \{ size_t         nbr;
                 ecs_bool_t   *val;
\} ecs_tab_bool_t;

\end{structure}


\subsubsection{Maillage\label{sec:structure.maillage}}

La composition de la structure~C implémentant un \maillage est la suivante~:

\begin{structure}{Structure \maillaget}{\maillagepriv\label{struct:maillage}}
struct _ecs_maillage_t \{
  ecs_maillage_connect_t   typ_connect;
  ecs_entmail_t           *entmail[ECS_ENTMAIL_FIN];
  ecs_famille_t           *famille[ECS_FAMILLE_FIN];

\};
\end{structure}

On donne ci-dessous une représentation graphique
du contenu de la structure \maillaget en développant les tableaux
statiques des membres de la structure.

\begin{figfloat}
\maillaget~:

\begin{tabular}[top]{l|l|}
\multicolumn{1}{l}{\fc{typ\_connect}}  \\
\multicolumn{1}{l}{\fc{entmail}} \\\cline{2-2}
             & \fc{ECS\_ENTMAIL\_SOM}\\\cline{2-2}
             & \fc{ECS\_ENTMAIL\_FAC}\\\cline{2-2}
             & \fc{ECS\_ENTMAIL\_CEL}\\\cline{2-2}
\multicolumn{1}{l}{\fc{famille}}\\\cline{2-2}
             & \fc{ECS\_FAMILLE\_SOM}\\\cline{2-2}
             & \fc{ECS\_FAMILLE\_FAC}\\\cline{2-2}
             & \fc{ECS\_FAMILLE\_CEL}\\\cline{2-2}
\end{tabular}

\captionfloat{Tableaux des membres de la structure \maillaget
  \label{fig:tab.maillage}}
\end{figfloat}


La structure contient en puissance une référence à toutes
les \entites~: si une \entite n'existe pas, la référence est le pointeur NULL.

Par exemple, pour un \maillage surfacique, on aura~:
\begin{quote}
\begin{alltt}
maillage->entmail[ECS_ENTMAIL_CEL] = NULL
\end{alltt}
\end{quote}

De la même façon, la structure \maillaget contient en puissance une référence
à toutes les \familles.


\subsubsection{Entité de maillage\label{sec:structure.entmail}}

La composition de la structure~C implémentant une \entite est la suivante~:

\begin{structure}{Structure \entmailt}{\entmailpriv\label{struct:entmail}}
struct _ecs_entmail_t \{
  ecs_champ_t  *champ[ECS_CHAMP_FIN];
\};

\end{structure}

On donne ci-dessous une représentation graphique
du contenu du membre \fc{champ} de la structure \entmailt
en développant les tableaux statiques.

La structure \entmailt contient les têtes de listes chaînées des différents
types de \champ. Afin de donner une généralité de structure
à tous les types de \champ, même le \champpal
sont constitués en liste chaînée~:
les têtes de liste sont, pour ces \champs, les seuls maillons de la chaîne.
Une fin de liste chaînée est toujours spécifiée par un pointeur NULL.

\begin{figfloat}

\begin{tabular}[top]{l|ll|l}
\multicolumn{1}{l}{\fc{champ}}\\\cline{2-3}
    & \fc{ECS\_CHAMP\_DEF} & \parbox[c][1.2truecm]{3.3truecm}{\mbox{\fbox{\parbox{3.0truecm}{\champdef}}}}   & \hspace{-3truemm}$\longrightarrow$ NULL\\\cline{2-3}
    & \fc{ECS\_CHAMP\_ATT} & \parbox[c][1.2truecm]{3.3truecm}{\mbox{\fbox{\parbox{3.0truecm}{\champatt 1}}}} & \hspace{-3truemm}$\longrightarrow$\mbox{\fbox{\parbox{3.0truecm}{\champatt 2}} \dots $\longrightarrow$ NULL}\\\cline{2-3}
\end{tabular}

\captionfloat{Tableau des \champs d'une \entite
  \label{fig:tabchamp.entite}}
\end{figfloat}

On voit bien sur ce schéma que
la hiérarchie des \champs \reffig{fig:classe.classification.champ}
a été \og aplatie \fg~:
\begin{liste}
\item le \champpal étant connu, il est directement mentionné
  dans le tableau ci-dessus;
\item il ne reste dans la hiérarchie des \champauxs que catégorie
  des \champatts;
\end{liste}


\subsubsection{Famille\label{sec:structure.fam}}

La composition de la structure~C implémentant une \famille est la suivante~:

\begin{structure}{Structure \famillet}{\famillepriv\label{struct:fam}}
struct _ecs_famille_t \{
  ecs_descr_t            *descr;
  struct _ecs_famille_t  *l_famille_sui;
\};

\end{structure}


La collection des \descrs décrivant une \famille
\reffig{fig:classe.relation.fam} est implémentée
sous la forme d'une liste chaînée de \descrs dont la tête de liste \fc{descr}
est référencée dans la structure \famillet.


\subsubsection{Champ\label{sec:structure.champ}}


\paragraph{Description de la structure\label{sec:structure.champ.descrip}}


La composition de la structure~C implémentant un \champ est la suivante~:

\begin{structure}{Structure \champt}{\champpriv\label{struct:champ}}
struct _ecs_champ_t \{
  size_t                 nbr_elt;
  ecs_type_t             typ_val;
  ecs_size_t             pos_pas;
  ecs_int_t             *pos_tab;
  void                  *val_tab;
  char                  *nom;
  ECS_CHAMP_STATUT_E     statut_e;
  ecs_descr_t           *descr;
  struct _ecs_champ_t   *l_champ_sui;
\};

\end{structure}


Les \attributs \fcla{nombre d'éléments} et \fcla{type}
\refpar{sec:classe.champ.attrib} sont directement impléméntés par
les membres respectifs \fc{nbr\_elt} et \fc{typ\_val}. De même, 
les \attributs \fcla{nom} et \fcla{statut} \refpar{sec:classe.champ.attrib}
sont directement implémentés par les membres respectifs \fc{nom}
et \fc{statut\_e}. Le membre \fc{statut\_e} est de type énuméré~:
\begin{quote}
\begin{alltt}
typedef enum \{
  ECS_CHAMP_STATUT_INDEFINI     = -1,
  ECS_CHAMP_STATUT_REF_ELT,
  ECS_CHAMP_STATUT_HERITABLE
\} ECS_CHAMP_STATUT_E;
\end{alltt}
\end{quote}

Les \tablposval qui composent la \classe \Champ \reffig{fig:classe.relation.champ}
sont directement référencées dans la structure \champt~:
\begin{liste}
\item \fc{pos\_tab} est un pointeur sur la \tablpos~; si celle-ci peut être
      définie par une \regl, ce pointeur est nul, et on utilise l'attribut
      \fc{pos\_pas}.
\item \fc{val\_tab} est un pointeur sur la \tablval.
\end{liste}

La collection des \descrs décrivant les \props du \champprop
est implémentée
sous la forme d'une liste chaînée de \descrs dont la tête de liste \fc{descr}
est référencée dans la structure \champt.
Si le \champ n'est pas un \champprop, \fc{descr} est le pointeur NULL.


\paragraph{Caractéristiques des champs\label{sec:structure.champ.caract}}

Dans cette section, on fait pour chaque type de \champ, un bilan
des différentes valeurs que prennent les membres de la structure \champt.


\noindent
%\begin{tabular}{|l|l|l|}
\begin{tabular}{|p{5cm}|p{3cm}|>{\PreserveBackslash\raggedright\hspace{0pt}}p{7cm}|}
\hline
\hline
\multicolumn{3}{|c|}{Caractéristiques du \champdef}\\
\hline
nom                        & \fc{nom}           & \fc{\og definition \fg}\\
statut du \champ           & \fc{statut\_e}     & \fc{ECS\_CHAMP\_STATUT\_HERITABLE}\\
\tablpos                   & \fc{pos\_pas}      & \regl ou non\\
                           & \fc{pos\_tab}      & \\
\tablval                   & \fc{val\_tab}      & valeurs entières ou réelles\\
\descr de \champpal        & \fc{descr}         & NULL\\
lien sur un \champ suivant & \fc{l\_champ\_sui} & NULL\\
\hline
\hline
\end{tabular}

\noindent
%\begin{tabular}{|l|l|l|}
\begin{tabular}{|p{5cm}|p{3cm}|>{\PreserveBackslash\raggedright\hspace{0pt}}p{7cm}|}
\hline
\hline
\multicolumn{3}{|c|}{Caractéristiques d'un \champatt}\\
\hline
nom                        & \fc{nom}           & \fc{\og couleur \fg},
                                                  \fc{\og groupe \fg},\\
                           &                    & \fc{\og famille \fg} ou
                                                  \fc{\og filiation \fg}\\
statut du \champ           & \fc{statut\_e}     & \fc{ECS\_CHAMP\_STATUT\_INDEFINI} ou\\
                           &                    & \fc{ECS\_CHAMP\_STATUT\_HERITABLE} ou\\
                           &                    & \fc{ECS\_CHAMP\_STATUT\_REF\_ELT}\\
\tablpos                   & \fc{pos\_tab}      & \regl ou non\\
\tablval                   & \fc{val\_tab}      & valeurs entières\\
\descr de \champatt        & \fc{descr}         & pointeur sur \descr tête\\
lien sur un \champ suivant & \fc{l\_champ\_sui} & pointeur sur \champ suivant ou NULL\\
\hline
\hline
\end{tabular}

\noindent


\paragraph{Répartition des fonctions dans les fichiers\label{sec:structure.champ.repart}}


Les \methodes relatives à la super-\classe \Champ,
sont implémentées sous forme de fonctions dans le fichier \verb=ecs_champ.c=~:
elles s'appliquent à n'importe quel type de \champ.

Les \methodes relatives aux sous-\classes de \Champ,
sont implémentées sous forme de fonctions dans un fichier
correspondant à la sous-\classe.
Le tableau ci-dessous donne la correspondance entre
les types de \champs et leur fichier associé~:

\begin{center}
\begin{tabular}{|l|l|l|}
\hline
\multicolumn{1}{|c}{Type de champ} & \multicolumn{1}{|c}{Énumérateur}
& \multicolumn{1}{|c|}{Fichier associé}\\
\hline
\champdef & \verb=ECS_CHAMP_DEF= & \verb=ecs_champ_def.c=\\
\champatt & \verb=ECS_CHAMP_ATT= & \verb=ecs_champ_att.c=\\
\hline
\end{tabular}
\end{center}


Les \methodes dépendantes de la \classe associée \Vect,
sont réparties dans les fichiers suivants~:
\begin{liste}
\item les fonctions référençant la structure \vecintt sont contenues
  dans le fichier \verb=ecs_vec_int.c=~;
\item les fonctions référençant la structure \vecrealt sont contenues
  dans le fichier \verb=ecs_vec_real.c=~;
\item les fonctions référençant à la fois les structures
 \vecintt et \vecrealt sont contenues dans le fichier \verb=ecs_vec.c=.
\end{liste}


Enfin, les fonctions gérant les listes chaînées de \champs
sont placées dans le fichier {\tt ecs\_champ\_chaine.c}.


\subsubsection{Descripteur\label{sec:structure.descr}}

La composition de la structure~C implémentant un \descr est la suivante~:

\begin{structure}{Structure \descrt}{\descrpriv\label{struct:descr}}
struct _ecs_descr_t \{
  ecs_int_t             num;
  ECS_DESCR_TYP_E       typ_e;
  ecs_int_t             ide;
  char                 *nom;
  struct _ecs_descr_t  *l_descr_sui;
\};

\end{structure}

Le membre \fc{num} de la structure représente le numéro
du \descr qui intervient~:
\begin{liste}
\item soit dans le \champfam si c'est un \descr intervenant dans la définition
  d'une \famille;
\item soit dans le \champprop si c'est un \descr intervenant dans la définition
  d'une \prop.
\end{liste}

Une nouvelle fois, la \gener des \descrs
\reffig{fig:classe.classification.descripteur}
est implémentée en aplatissant la hiérarchie des \classes~:
pour différencier le type de \descr (\descr de \couleur ou \descr de \groupe)
le membre \fc{typ\_e} a un type énuméré~:
\begin{quote}
\begin{alltt}
typedef enum \{
  ECS_DESCR_TYP_COULEUR,
  ECS_DESCR_TYP_GROUPE
\} ECS_DESCR_TYP_E;
\end{alltt}
\end{quote}

Un \descr de \couleur n'ayant pas de nom, il aura le membre \fc{nom} à NULL.

Le numéro identifiant la \couleur (ou le \groupe)
est stocké dans le membre \fc{ide}.


La \classe \Descripteur n'intervient, dans les diagrammes de relations entre
\classes, que dans des relations d'\agreg, comme
le montre la figure~\ref{fig:classe.relation.descripteur}.
Le choix des relations d'\agreg sous-entendait qu'un même \descr 
pouvait appartenir, d'une part
à l'ensemble des \descrs participant à la définition d'une \famille,
d'autre part
à l'ensemble des \descrs participant à la définition d'un \champprop.\\
De plus, un même \descr pouvait participer à la définition
de plusieurs \familles.


\subsection{Structures Vecteur Indexé\label{sec:table}}


Les \vect n'ont pas fait l'objet
d'une description en termes de \classe, car ce sont
des structures d'implémentation~: 
Les valeurs d'un \champ sont stockées dans la \tablval,
et sont accessibles grâce au couple des \tablposval.
La structure \vect réimplémente le stockage de ces valeurs
de façon à ce qu'elles soient plus facilement accessibles.

L'objectif qui a prévalu à la conception de la structure \champ,
a été de limiter au maximum l'encombrement mémoire du stockage de
ses valeurs.

Une contrainte pour la construction du stockage des valeurs,
était de limiter les appels à l'allocation mémoire.
La solution consistant
à créer deux tableaux uni-dimensionnels, l'un contenant
les valeurs à stocker, l'autre les indices de début
des valeurs associées à chaque élément,
ne nécessite que deux appels à la fonction système d'allocation dynamique.

Si le rangement des valeurs coïncide avec un tableau rectangulaire
$n\times m$,
le tableau contenant les indices de début et fin pour chaque élément
sera une suite arithmétique de raison $m$ et ne consommera pas de place
mémoire.

À une \tablval sur un ensemble d'éléments,
il sera donc toujours associée une \tablpos, qui
contient les indices de début des valeurs associées à l'élément
(l'indice de fin correspondant à l'indice de début associé
à l'élément suivant $-1$).

De façon générale, les valeurs d'un champ sont stockées dans un tableau,
ainsi que l'index (où tableau des positions) associé à ces valeurs.
Cependant, si le tableau des positions constitue une suite arithmétique,
plutôt que d'allouer un tableau des positions sur tous les éléments du \champ,
on ne stockera que la raison arithmétique de cette suite (son pas).
En procédant de cette manière,
le gain de place mémoire peut être très important.

Par exemple, pour un \champ indiquant le numéro de famille associé
à chacun de 999 éléments, on aura une famille et une seule par élément,
d'où un pas de la table des positions égal à 1, comme suit~:
\begin{alltt}
 pos_pas  1
 pos_tab  NULL
 val_tab  <...>
\end{alltt}

On n'utilise les \tablpos que pour les champs d'entiers, les
champs réels rencontrés (coordonnées des \soms) ne pouvant que très
rarement s'exprimer sous cette forme. Pour un champ
réel, on aura toujours une \regl pour les positions.


\subsubsection{Vecteur Indexé\label{sec:structure.vec}}

La composition de la structure~C implémentant un \vectint est la suivante~:

\begin{structure}{Structure \vecintt}{\vecintpriv\label{struct:vecint}}
struct _ecs_vec_int_t \{
  size_t       pos_nbr;
  ecs_size_t  *pos_tab;
  ecs_int_t   *val_tab;
\};

\end{structure}


La composition de la structure~C implémentant un \vectreal est la suivante~:

\begin{structure}{Structure \vecrealt}{\vecrealpriv\label{struct:vecreal}}
struct _ecs_vec_real_t \{
  size_t       pos_nbr;
  ecs_size_t   pos_pas;
  ecs_real_t  *val_tab;
\};

\end{structure}


Le \vectint réimplémente le couple des \tablposval en une seule structure.
Elle contient le nombre de positions, un tableau des positions entier
et un tableau des valeurs typé.
Si la \tablpos n'est pas une \regl, le tableau de la \tablpos correspond à
celui du \vect.
si la \tablpos est une \regl, la suite arithmétique
est développée en un tableau pour le \vect.
De même, le tableau de la \tablval correspond à celui du \vect, mais
ce dernier est typé.

Dans le cas du \vectreal, la \tablpos est une \regl dans tous les
cas envisagés.
On ne définit donc pas le tableau des positions pour un \vectreal, mais
directement le pas, la première position étant toujours égale à 1.

La structure \champt a été conçue comme une structure de stockage de données
et n'est pas forcément commode à utiliser en pratique, notamment
pour l'implémentation des algorithmes~:
\begin{liste}
\item elle nécessiterait de différencier le cas où la \tablpos
  est une \regl du cas où la \tablpos n'est pas une \regl~;
\item la \tablval nest pas typée (plus précisément, elle a le type
  \verb=void *=), il faudrait donc commencer par
  réaliser une conversion de type sur ce tableau pour l'utiliser.
\end{liste}

Un \vect (de type \vecintt ou \vecrealt) permet de définir un \champ
mais a une existence propre~:
\begin{liste}
\item un \vect associé à un \champ peut être créé et détruit à tout moment;
\item si le \champ est détruit, le \vect n'est pas détruit (on prendra
      garde justement à ce qu'il n'existe plus de \vect associé au \champ
      à détruire)~;
\item un \vect peut être créé sans être associé à un \champ.
\end{liste}

Autrement dit, la structure \vecintt a été conçue pour avoir
une durée de vie temporaire
(le temps de l'exécution de quelques fonctions)
alors que la structure \champt a une durée de vie plus longue.


Les sections~\ref{sec:util.champ}~et~\ref{sec:util.vect} contiennent
des compléments d'information sur l'utilisation d'un \vect.


\subsubsection{Lien entre les \og positions \fg et les \og valeurs \fg
\label{sec:lienposval}}

Le but de cette section est de préciser le lien entre les \og positions \fg et
les \og valeurs \fg.
Ce lien existe de manière équivalente~:
\begin{liste}
\item soit entre la \tablpos et la \tablval;
\item soit entre les tableaux \fc{pos\_tab} et \fc{val\_tab}
  des structures \vecintt.
\end{liste}

On commence par décrire ce lien dans le cas général,
puis on l'illustrera sur 2 exemples représentatifs.

Pour les explications qui suivent, qu'il s'agisse du tableau de la \tablpos
(éventuellement construit à partir de la suite arithmétique)
ou du tableau des positions du \vect, on appelle $pos\_tab$
le tableau des positions.\\
Pour connaître les positions des valeurs d'un élément d'indice $iE$,
on cherche l'indice $iP=iE$ du tableau des positions $pos\_tab$.
Le nombre de valeurs associées à l'élément $iE$ est donné
par $pos\_tab[iP+1] - pos\_tab[iP]$.
L'indice, dans le tableau des valeurs, de la 1ère valeur est
$pos\_tab[iP]-1$, et celui de la dernière valeur est $pos\_tab[iP+1] - 2$.

La 1ère valeur du tableau des positions est toujours égale à 1~:
$pos\_tab[0]=1$,
et si on a $N$ éléments,
le tableau des positions a la dimension $pos\_nbr=N+1=nP+1$.

La dimension du tableau des valeurs est donnée par
$pos\_tab[pos\_nbr-1]-1=pos\_tab[nP]-1$.

On représente ci-dessous les liens entre le tableau des positions
et le tableau des valeurs~:
le tableau des positions est placé en dessous
du tableau des valeurs, $iP$ est un indice du tableau des positions,
$iV$ est un indice du tableau des valeurs.

\newsavebox{\tablegen}
\setlength{\unitlength}{3.5truecm}
\savebox{\tablegen}(0,1.3){%
  \put(0,0){\framebox(3.6,0.3){}}
  \put(0.2,0.15){\makebox(0,0){        }}\put(0.40,0){\line(0,1){0.3}}
  \put(0.6,0.15){\makebox(0,0){\dots   }}\put(0.79,0){\line(0,1){0.3}}\put(0.81,0){\line(0,1){0.3}}
  \put(1.0,0.15){\makebox(0,0){        }}\put(1.20,0){\line(0,1){0.3}}
  \put(1.4,0.15){\makebox(0,0){\dots   }}\put(1.60,0){\line(0,1){0.3}}
  \put(1.8,0.15){\makebox(0,0){        }}\put(1.99,0){\line(0,1){0.3}}\put(2.01,0){\line(0,1){0.3}}
  \put(2.2,0.15){\makebox(0,0){        }}\put(2.40,0){\line(0,1){0.3}}
  \put(2.6,0.15){\makebox(0,0){\dots   }}\put(2.79,0){\line(0,1){0.3}}\put(2.81,0){\line(0,1){0.3}}
  \put(3.0,0.15){\makebox(0,0){\dots   }}\put(3.20,0){\line(0,1){0.3}}
  \put(3.4,0.15){\makebox(0,0){        }}\put(3.60,0){\line(0,1){0.3}}
  \put(3.8,0.15){\makebox(0,0){        }}\put(3.62,0){\dashbox{0.01}(0.4,0.3)}

  \put(0.2,-0.10){\makebox(0,0){0}}
  \put(1.0,-0.10){\makebox(0,0){$iV-1$}}
  \put(1.8,-0.10){\makebox(0,0){$jV-2$}}
  \put(2.2,-0.10){\makebox(0,0){$jV-1$}}
  \put(3.4,-0.10){\makebox(0,0){$nV-2$}}
  \put(3.8,-0.10){\makebox(0,0){$nV-1$}}

  \put(0.8,-0.8){\framebox(2.4,0.3){}}
  \put(1.0,-0.65){\makebox(0,0){1}    }\put(1.20,-0.80){\line(0,1){0.3}}
  \put(1.4,-0.65){\makebox(0,0){\dots}}\put(1.60,-0.80){\line(0,1){0.3}}
  \put(1.8,-0.65){\makebox(0,0){$iV$} }\put(2.00,-0.80){\line(0,1){0.3}}
  \put(2.2,-0.65){\makebox(0,0){$jV$} }\put(2.40,-0.80){\line(0,1){0.3}}
  \put(2.6,-0.65){\makebox(0,0){\dots}}\put(2.80,-0.80){\line(0,1){0.3}}
  \put(3.0,-0.65){\makebox(0,0){$nV$} }

  \put(1.0,-0.90){\makebox(0,0){0}}
  \put(1.8,-0.90){\makebox(0,0){$iP$}}
  \put(2.2,-0.90){\makebox(0,0){$iP+1$}}
  \put(3.0,-0.90){\makebox(0,0){$nP$}}

 \dashline{0.02}(1.0,-0.48)(0.2,-0.15)
 \dashline{0.02}(1.8,-0.48)(1.0,-0.15)
 \dashline{0.02}(2.2,-0.48)(2.2,-0.15)
 \dashline{0.02}(3.0,-0.48)(3.8,-0.15)
% \dashline{0.02}(1.9,-0.48)(2.9,-0.15)
}

\begin{picture}(4,1.3)
\usebox{\tablegen}
\end{picture}

\bigskip
On illustre le lien entre les tableaux des positions et des valeurs
dans un cas concret.
\bigskip

\newsavebox{\maildoc}
\setlength{\unitlength}{1.5truecm}
\savebox{\maildoc}(4.3,2.5){%
  \put(0,0){\framebox(2,2){}}
  \put(0,1){\line(1,0){4}}
  \put(2,0){\line(2,1){2}}
  \put(4,1){\line(-2,1){2}}
  \put(-0.15,-0.15){\makebox(0,0){1}}
  \put(1.85,-0.15){\makebox(0,0){2}}
  \put(-0.15,0.85){\makebox(0,0){3}}
  \put(1.85,0.85){\makebox(0,0){4}}
  \put(-0.15,1.85){\makebox(0,0){5}}
  \put(1.85,1.85){\makebox(0,0){6}}
  \put(4.15,0.95){\makebox(0,0){7}}
  \put(0.95,0.55){\makebox(0,0){1}}
  \put(2.45,0.55){\makebox(0,0){2}}
  \put(0.95,1.45){\makebox(0,0){3}}
  \put(2.45,1.45){\makebox(0,0){4}}
}

\begin{minipage}{6truecm}
Considérons l'exemple du \maillage surfacique plan ci-contre~:
\end{minipage}\hspace{1truecm}
\begin{minipage}{7truecm}
  \begin{picture}(4.3,2.5)
    \usebox{\maildoc}\label{fig:lienposval.maillage}
  \end{picture}
\end{minipage}


\bigskip
Ce \maillage (très simple!) est composé de 2 quadrangles (numérotés 1 et 3)
et de 2 triangles (numérotés 2 et 4).
On construit les tableaux des positions et des valeurs correspondants
à la définition des éléments en fonction des \soms (numérotés de 1 à 7)~:
\bigskip

\newsavebox{\titretab}
\setlength{\unitlength}{4truecm}
\savebox{\titretab}(0,1.3){%
  \put(0.25,0.20){\makebox(0,0){Tableau des}}
  \put(0.25,0.10){\makebox(0,0){valeurs}}

  \put(0.25,-0.60){\makebox(0,0){Tableau des}}
  \put(0.25,-0.70){\makebox(0,0){positions}}
}

\newsavebox{\tableexu}
\setlength{\unitlength}{4truecm}
\savebox{\tableexu}(3,1.3){%
  \put(0,0){\framebox(2.8,0.3){}}
  \put(0.1,0.15){\makebox(0,0){1}}\put(0.20,0){\line(0,1){0.3}}
  \put(0.3,0.15){\makebox(0,0){2}}\put(0.40,0){\line(0,1){0.3}}
  \put(0.5,0.15){\makebox(0,0){4}}\put(0.60,0){\line(0,1){0.3}}
  \put(0.7,0.15){\makebox(0,0){3}}\put(0.79,0){\line(0,1){0.3}}\put(0.81,0){\line(0,1){0.3}}
  \put(0.9,0.15){\makebox(0,0){2}}\put(1.00,0){\line(0,1){0.3}}
  \put(1.1,0.15){\makebox(0,0){7}}\put(1.20,0){\line(0,1){0.3}}
  \put(1.3,0.15){\makebox(0,0){4}}\put(1.39,0){\line(0,1){0.3}}\put(1.41,0){\line(0,1){0.3}}
  \put(1.5,0.15){\makebox(0,0){3}}\put(1.60,0){\line(0,1){0.3}}
  \put(1.7,0.15){\makebox(0,0){4}}\put(1.80,0){\line(0,1){0.3}}
  \put(1.9,0.15){\makebox(0,0){6}}\put(2.00,0){\line(0,1){0.3}}
  \put(2.1,0.15){\makebox(0,0){5}}\put(2.19,0){\line(0,1){0.3}}\put(2.21,0){\line(0,1){0.3}}
  \put(2.3,0.15){\makebox(0,0){4}}\put(2.40,0){\line(0,1){0.3}}
  \put(2.5,0.15){\makebox(0,0){7}}\put(2.60,0){\line(0,1){0.3}}
  \put(2.7,0.15){\makebox(0,0){6}}\put(2.82,0){\dashbox{0.01}(0.2,0.3)}


  \put(0.1,-0.10){\makebox(0,0){0}}
  \put(0.3,-0.10){\makebox(0,0){1}}
  \put(0.5,-0.10){\makebox(0,0){2}}
  \put(0.7,-0.10){\makebox(0,0){3}}
  \put(0.9,-0.10){\makebox(0,0){4}}
  \put(1.1,-0.10){\makebox(0,0){5}}
  \put(1.3,-0.10){\makebox(0,0){6}}
  \put(1.5,-0.10){\makebox(0,0){7}}
  \put(1.7,-0.10){\makebox(0,0){8}}
  \put(1.9,-0.10){\makebox(0,0){9}}
  \put(2.1,-0.10){\makebox(0,0){10}}
  \put(2.3,-0.10){\makebox(0,0){11}}
  \put(2.5,-0.10){\makebox(0,0){12}}
  \put(2.7,-0.10){\makebox(0,0){13}}
  \put(2.9,-0.10){\makebox(0,0){14}}

  \put(1.0,-0.8){\framebox(1.0,0.3){}}
  \put(1.1,-0.65){\makebox(0,0){1} }\put(1.20,-0.80){\line(0,1){0.3}}
  \put(1.3,-0.65){\makebox(0,0){5} }\put(1.40,-0.80){\line(0,1){0.3}}
  \put(1.5,-0.65){\makebox(0,0){8} }\put(1.60,-0.80){\line(0,1){0.3}}
  \put(1.7,-0.65){\makebox(0,0){12}}\put(1.80,-0.80){\line(0,1){0.3}}
  \put(1.9,-0.65){\makebox(0,0){15}}

  \put(1.1,-0.90){\makebox(0,0){0}}
  \put(1.3,-0.90){\makebox(0,0){1}}
  \put(1.5,-0.90){\makebox(0,0){2}}
  \put(1.7,-0.90){\makebox(0,0){3}}
  \put(1.9,-0.90){\makebox(0,0){4}}

  \dashline{0.02}(1.1,-0.48)(0.1,-0.15)
  \dashline{0.02}(1.3,-0.48)(0.9,-0.15)
  \dashline{0.02}(1.5,-0.48)(1.5,-0.15)
  \dashline{0.02}(1.7,-0.48)(2.3,-0.15)
  \dashline{0.02}(1.9,-0.48)(2.9,-0.15)
}

\noindent
\begin{minipage}{2truecm}
  \begin{picture}(0,1.3)
    \usebox{\titretab}
  \end{picture}
\end{minipage}\hspace{0.5truecm}
\begin{minipage}{12.2truecm}
  \begin{picture}(3,1.3)
    \usebox{\tableexu}
  \end{picture}
\end{minipage}

\bigskip
Supposons maintenant que les quadrangles appartiennent
à un \groupe nommé \og QUAD \fg et portant le numéro 1.
Les triangles sont supposés quant à eux n'appartenir à aucun \groupe.
Les tableaux des positions et des valeurs correspondants
au \champ \groupe sont représentés ci-dessous~:


\newsavebox{\tableexd}
\setlength{\unitlength}{4truecm}
\savebox{\tableexd}(3,1.3){%
  \put(1.2,0){\framebox(0.4,0.3){}}
  \put(1.3,0.15){\makebox(0,0){1}}\put(1.39,0){\line(0,1){0.3}}\put(1.41,0){\line(0,1){0.3}}
  \put(1.5,0.15){\makebox(0,0){1}}\put(1.62,0){\dashbox{0.01}(0.2,0.3)}

  \put(1.3,-0.10){\makebox(0,0){0}}
  \put(1.5,-0.10){\makebox(0,0){1}}
  \put(1.7,-0.10){\makebox(0,0){2}}

  \put(1.0,-0.8){\framebox(1.0,0.3){}}
  \put(1.1,-0.65){\makebox(0,0){1} }\put(1.20,-0.80){\line(0,1){0.3}}
  \put(1.3,-0.65){\makebox(0,0){2} }\put(1.40,-0.80){\line(0,1){0.3}}
  \put(1.5,-0.65){\makebox(0,0){2} }\put(1.60,-0.80){\line(0,1){0.3}}
  \put(1.7,-0.65){\makebox(0,0){3} }\put(1.80,-0.80){\line(0,1){0.3}}
  \put(1.9,-0.65){\makebox(0,0){3} }

  \put(1.1,-0.90){\makebox(0,0){0}}
  \put(1.3,-0.90){\makebox(0,0){1}}
  \put(1.5,-0.90){\makebox(0,0){2}}
  \put(1.7,-0.90){\makebox(0,0){3}}
  \put(1.9,-0.90){\makebox(0,0){4}}

 \dashline{0.02}(1.1,-0.48)(1.3,-0.15)
 \dashline{0.02}(1.5,-0.48)(1.5,-0.15)
}

\noindent
\begin{minipage}{2truecm}
  \begin{picture}(0,1.3)
    \usebox{\titretab}
  \end{picture}
\end{minipage}\hspace{0.5truecm}
\begin{minipage}{12.2truecm}
  \begin{picture}(3,1.3)
    \usebox{\tableexd}
  \end{picture}
\end{minipage}

\bigskip
Cet exemple montre comment est construit le tableau des positions
lorsqu'un élément n'a pas de valeur~: les positions de cet élément 
et de l'élément suivant sont égales.


Pour d'autres exemples de tableaux de position et de valeurs,
et plus généralement d'autres exemples
de contenus de structure \champt,
on se reportera à l'annexe~\ref{an:impressionascii} reproduisant une
transcription complète sur fichier de la structure \maillaget et de
ses sous-structures correspondant à l'exemple de \maillage surfacique
plan décrit dans la présente section
(ici, les \soms ont une \couleur 1 et les \facs ont une \couleur 7)


\subsection{Autres structures\label{sec:autres}}

Les classes principales ne sont pas les seules utilisées.
D'autres structures et classes sont définies, mais leur définition
est plus liée à l'application qu'au modèle de données interne.
Ainsi, on les les décrit pas en détail ici, mais on en énumère
quelques unes~:

\begin{itemize}

\item La classe \cmdt permet de conserver en mémoire les choix
      effectués au moyen des options de la ligne de commande.
      Un seul objet de cette classe est instancié.

\item La structure \postt relative au choix des formats de post-traitement
      contient des listes chaînées de structures décrivant pour
      chaque format de sortie disponible les différents cas actifs.
      Ces structures contiennent elles-mêmes les descripteurs de fichiers
      utilisées, la liste des maillages associés, etc.

\end{itemize}

\passepage

