Le comportement du système simulé est déterminé par deux ensembles d'informations :
- Les connaissances générales sur la structure du système et les processus en jeu. Pour l'essentiel, ces informations sont codées dans les constructeurs des classes d'entités et de processus. Les constructeurs sont eux-mêmes invoqués dans des modules supervisés par un module particulier, connu sous le nom de programme principal (c'est la fonction main()). Ce programme fixe en outre tout ou partie des directives de la simulation : typiquement et sommairement, les instructions de lecture des données en entrée, le lancement de la simulation et la récupération des résultats. Toutes ces informations sont compilées, c'est-à-dire qu'elles ne sont pas modifiables par l'utilisateur. Elles constituent, solidairement, le simulateur.
- Les données spécifiques à un cas d'étude faisant l'objet d'une simulation du comportement du système. Ces données sont modifiées par l'utilisateur d'une simulation à l'autre. Puisque le simulateur compilé est fermé, ces données spécifiques sont placées en dehors de lui, sur des fichiers externes.
A tout moment du développement d'un simulateur, le modélisateur doit décider si une connaissance est générale à son domaine ou bien spécifique à un cas d'étude.
C'est notamment le cas de la structure du système à simuler : faut-il la fixer par le code des constructeurs du système et de ses composants ou éléments ? Ou bien laisse-t-on l'utilisateur du simulateur la décrire au cas par cas dans un fichier externe ?
C'est aussi le cas des critères d'analyse du comportement du système : l'évolution de quelles variables d'état est un critère général ? L'évolution de quelles autres n'est intéressant que dans un cas d'étude particulier.
Noter que chaque connaissance ne fait normalement l'objet d'une déclaration externe que si le développeur a choisi de ne pas les inclure dans la partie compilée. Si des informations sont placées à la fois dans la partie compilée et sur fichier externe, cette dernière forme annulera et remplacera la première.
Chaque type de connaissance "externalisée" fait l'objet d'un fichier différent, avec un format spécifique. On peut les classer en trois ensembles :
- les données en entrée de la simulation, qui sont elles-mêmes de quatre types :
- les paramètres du système, c'est-à-dire la valeur de constantes intervenant, n'importe où, dans le code du simulateur : par exemple, la latitude du lieu d'étude, un paramètre d'ajustement d'une courbe de croissance, etc. Ils sont déclarés dans un fichier de paramètres unique, exploité en tout début du programme principal par un appel à ParseParameterFile. Cette exploitation génère la création d'instances (une par paramètre) de la classe Parameter. Les valeurs affectées (celles figurant dans le fichier externe) sont alors accessibles par les services Get..ParameterValue.
- les aspects structurel, fonctionnel et dynamique du système simulé : quelles entités sont composants ou éléments de telle autre, quelle est la valeur initiale de tel descripteur de telle entité ; quels événements programme-t-on ex ante, quand et avec quelle priorité, quels processus sont en jeu dans ces événements, sur quelles entités vont-ils porter. Ces déclarations sont faites dans un unique fichier de la structure présenté dans le lien ' Les fichiers en entrée de type déclaratif', et exploité par un appel à ParseStructureFile avant l'invocation de la méthode Run (que celle-ci soit programmée dans la fonction main() ou déclarée dans le fichier des directives de simulation (voir ci-dessous)). La lecture et l'interprétation de ces informations provoque l'invocation de services de DIESE, notamment les constructeurs des classes de l'application, les services d'affectation de valeurs, etc.
- les paramètres de la simulation elle-même : les dates de début et de fin, l'entité qui tient le rôle d'"entité simulée", le nom du répertoire où sont classés les différents fichiers externes, etc. Ces informations sont déclarés dans un fichier unique exploité par un appel à ParseSimulationFile, avant l'invocation de la méthode Run, de quelque manière qu'elle soit réalisée.
- la dynamique de l'environnement du système simulé. L'état de l'environnement évolue dans le temps, et on dispose d'un vecteur de valeurs en plusieurs instants de la simulation. Une option d'externalisation est que chaque vecteur constitue un enregistrement d'un fichier ; une simulation accède alors à une séquence d'enregistrements. L'enregistrement peut comporter certains champs qui définissent le moment auquel les valeurs se rapportent. Ces champs peuvent etre ignorés, ou bien remplir la fonction de clé d'accès pour un accès indexé aux données, ou bien encore permettre une vérification de concordance de temps entre la donnée accédée et l'instant courant de la simulation.
Les descripteurs dynamiques de l'environnement figurent dans des fichiers en série d'enregistrements externes. A chacun, le développeur du simulateur fait correspondre une instance de la classe SerialDataFile, typiquement en début de simulation, avant l'appel au Run.De façon générale, les informations dans le fichier des paramètres du système peuvent être exploitées dans les autres fichiers en entrée. Par exemple, le fichier de déclaration de la structure du système pourra faire référence à une valeur de paramètre pour fixer le nombre d'éléments à ajouter à une certaine entité. De même, ce fichier pourra contenir des informations utiles à l'exploitation d'un fichier en série d'enregistrements (par exemple, le nom physique du fichier).
- Les "spécifications de sortie" : les "sorties" de la simulation sont une trace sélective du comportement du système simulé. C'est l'utilisateur qui établit la sélection sous la forme de spécifications écrites dans un fichier externe au simulateur. Ce fichier de spécifications de sorties est présenté avec la classe OutputSpec (voir page 'Les spécifications de sortie'). DIESE propose des services pour lire ce fichier (par un appel à ParseOuputSpecFile normalement au début du programme principal), l'interpréter et générer automatiquement les sorties sur un ou plusieurs autres fichiers qui seront exploitables après la fin de la simulation (voir la classe OutputSpec).
- Les directives de simulation : il s'agit des actions que doit entreprendre le moteur pour initialiser une simulation, afficher la structure initiale du système, exécuter la simulation et exploiter ses sorties. Ces directives de calcul figurent dans un unique fichier de directives de simulation présenté dans le lien ' Les fichiers en entrée de type déclaratif'.
Bien noter ici encore que le développeur du simulateur peut décider de rendre générale tout ou partie de la série d'actions à entreprendre, et la coder dans le programme compilé (plus précisément dans la fonction main()). Quel que soit l'ensemble des directives externalisées sur fichier, sa lecture et son interprétation sont lancées, dans le programme principal, par une unique instruction ParseDirectiveFile.
Remarques :
- Le mot fichier peut désigner, selon le contexte, l'une ou l'autre des deux entités bien distinctes suivantes :
- le lieu physique où les données sont stockées, avec une certaine organisation (c'est la notion classique de fichier),
- la structure de données, instance d'une sous-classe de File, qui encapsule les informations sur le lieu physique et l'organisation des données.
- Aucune classe propre au domaine ne peut être une sous-classe directe de la classe générique File et aucune instance directe de cette classe ne doit être créée.
- La présente version ne propose de services prédéfinis que pour la lecture de données. Quant aux services d'écriture sur fichier, ceux qui exécutent les spécifications de sorties de la simulation sont inclus dans les méthodes de OutputSpec et inaccessibles directement. Au-delà de ça, les procédures répondant à des besoins spécifiques dans tel ou tel domaine d'application sont à programmer entièrement, avec les outils de plus bas niveau.