La page consacrée à l'utilisation par ligne de commande a déjà mentionné la possibilité de placer certaines données en entrée du simulateur (c'est-à-dire en externe par rapport à celui-ci). On a notamment dit que la connaissance sur la structure initiale du système pouvait être exprimée, dans un langage approprié, dans un fichier qui sera lu et interprété au début de l'exécution. Il s'agit là de la connaissance structurale que possède l'utilisateur sur le système. Elle lui a été transférée normalement par le développeur du simulateur, qui a rédigé une version initiale (on peut aussi dire 'par défaut', ou encore 'standard') du fichier de la structure.
Le développeur possède aussi des connaissances fonctionnelles sur le système : celles qu'il code dans les méthodes des classes d'objets, et notamment des classes d'entités, de processus, d'événements, de spécifications d'ensembles d'entités et de démons. On peut citer, en exemples typiques, les fonctions d'initialisation, d'avancée et d'arrêt d'un processus continu, ou la fonction d'exécution d'un processus ponctuel. Le développeur est aussi amené à coder des fonctions ordinaires, non attachées à une classe d'objets (à ce stade, on n'a évoqué que la fonction d'interprétation de la ligne de commande, mais il y a de meilleurs exemples de fonctions sujettes à externalisation). Pour chaque granule de connaissance (autrement dit chaque corps de fonction), le développeur peut choisir entre trois options :
La présente version de DIESE supporte, en entrée des simulateurs, des fichiers écrits en perl. La mise en oeuvre de l'interpréteur est documentée dans une page dédiée (voir page dédiée), en complémentarité avec la présentation d'un outil (SWIG) qui permet d'invoquer les services de DIESE à l'intérieur du code perl des fonctions externalisées. On montre enfin dans la page en question comment l'utilisation de la classe Method permet de simplifier considérablement la mise en uvre de l'externalisation de fonctions.
- Donner à ce corps le statut de fonction membre d'une classe, (au sens de C++ : elle en est alors ce qu'on appelle une méthode), ou bien de fonction non membre (fonction C classique), puis compiler ce corps et le lier à d'autres dans le module exécutable. Il est clair qu'une modification de la connaissance fonctionnelle contenue dans le corps de la fonction passe par une nouvelle compilation du simulateur.
- Externaliser la fonction, c'est-à-dire placer son corps dans un fichier en entrée du simulateur, lequel l'exploitera. Une modification de la connaissance passe seulement par une édition du fichier externe, et ne nécessite pas une nouvelle compilation du code. Cette exploitation dynamique demande que la fonction soit rédigée dans un langage, non pas compilé, mais interprété (au sens des langages informatiques).
- A la fois compiler le corps dans une version standard et documentée, et en placer une version interprétable sur un fichier externe. Ceci donne à l'utilisateur la possibilité de modifier le code s'il le souhaite, mais aussi d'utiliser la version compilé (normalement plus rapide) si la documentation correspond à son attente.