La classe des simulations


o Simulation

Une fois le système modélisé, par l'écriture des sous-classes appropriées d'entités, de descripteurs, de processus et d'événements, la simulation du système repose simplement sur :

  1. La création d'une instance de la classe Simulation par un constructeur de la classe, et la liaison de la variable globale pCurrentSim à l'adresse de cette instance :
      Simulation* pCurrentSim = new Simulation();
    
    L'horloge du temps simulé, un des attributs de la classe, est mise à zéro.

  2. L'affectation explicite de valeurs à certains de ses attributs.

    L'unité pour le temps simulé est fixée par des instructions telles que :

      pCurrentSim->ClockTimeUnit(SECOND);
      ClockTimeUnitQuantity(1);
    

    Il est aussi obligatoire d'insérer au moins un événement dans l'agenda. Par exemple :

      Event* pMyEvent = new Event();
      pCurrentSim->InsertInAgendaEvents(pMyEvent);
    

    Les événements sont rangés dans l'agenda selon l'ordre défini dans une fonction d'ordre sur les événements de l'agenda. La fonction standard BeforeByDatePriority (voir page 'Fonctions globales/Fonctions diverses') est affectée par défaut, mais elle peut être surchargée par une fonction écrite par l'utilisateur :

      pCurrentSim->AssignBeforeInAgendaMethod(myFunction);
    

    Il est aussi recommandé d'associer à la simulation, par la méthode SimulatedEntity, une "entité simulée", choisie parmi celles de plus haut niveau d'intégration, c'est-à-dire qui ne sont ni composant ni élément d'une autre entité. Cette entité est normalement celle qui représente le système à simuler. L'intérêt est de disposer de manière simple d'un point d'entrée dans le réseau des entités, à partir duquel on peut "naviguer" en utilisant des services prédéfinis :

      Entity* pPS = ...;
      pCurrentSim->SimulatedEntity(pPS);
      Entity* pE_ref = pCurrentSim->SimulatedEntity(pPS);
      Entity* pMan = pE_ref->GetComponent(MANAGER);
    

    Cette désignation devient nécessaire quand on utilise la version du simulateur équipée pour une utilisation interactive.

  3. L'envoi à cette instance du message d'exécution de la simulation :
      pCurrentSim->Run(); // ou pCurrentSim->Run(n);
    

    n est un nombre entier positif ou une variable entière qui peut être gMaxNbIterations. La méthode Run contrôle la simulation en répétant la série d'instructions suivante, au maximum n fois et tant que (i) il y a au moins un événement dans l'agenda, (ii) la date de fin de simulation éventuellement spécifiée par l'utilisateur (méthode SetEndClock ou SetEndDate) n'est pas atteinte, (iii) un message explicite d'arrêt de la simulation (méthode Stop) n'a pas été adressé :

         [a]      Dépilement de l'événement de tête de l'agenda, et avancement de l'horloge de la simulation à la date de cet événement.
         [b]      Application des conséquences de l'événement sur le système simulé, en termes de directives (ou actions) sur une liste de processus. Chaque couple {processus, action} est traité dans l'ordre d'apparition dans la liste. Si la précondition de l'action est satisfaite, celle-ci est réalisée. Sinon, soit l'exécution est abandonnée, soit la même action sur le même processus est à nouveau programmée dans un événement ultérieur spécialement généré à cet effet par DIESE (l'action sur le processus est donc mise en attente).
         [c]      Déclenchement d'une fonction éventuellement définie par l'utilisateur pour coder des conséquences de l'événement qui ne peuvent pas s'exprimer en termes de directives sur des processus. Si une telle fonction (désignée par le terme de postconséquence) existe, elle ne sera déclenchée qu'une fois que tous les processus auront été effectivement traités, que ce soit lors de l'événement initial ou lors des événements reprogrammés à une date ultérieure pour cause de non-satisfaction de la précondition.
         [d]      Dans le cas où l'utilisateur l'a définie, une autre fonction est déclenchée qui génère un événement de la même classe pour une date ultérieure (on parle d'autogénération). Cette fonctionnalité permet de définir une série d'événements, sans les énumérer tous explicitement. Le nouvel événement généré est inséré dans l'agenda, par la fonction d'ordre évoquée plus haut.
         [e]      Enfin, l'événement dépilé est détruit (récupération de la mémoire qu'il occupait). En ce qui concerne les processus associés, les règles de suppression sont les suivantes. Un processus continu est détruit si l'événement dépilé comportait (normalement) une directive d'arrêt du processus. Un processus discret est détruit si l'événement dépilé comportait une directive d'exécution et que, soit celle-ci a effectivement été réalisée soit le processus a été définitivement abandonné (voir la méthode AssignPreconditionMethod de la classe Process). Dans les autres cas, le processus n'est pas détruit par le système.

  4. Une fois terminée l'exécution de la méthode Run, la récupération des résultats de la simulation. DIESE fournit un service d'écriture, sur des supports externes, d'informations sur l'état du système, collationnées en cours de simulation en fonction de directives exprimées avant le lancement du calcul (voir la page 'Les spécifications de sortie').

  5. La suppression de l'instance de simulation :
      delete pCurrentSim; 
    
    Cette suppression entraîne celle des événements restant dans l'agenda et de tous les processus en cours ou en attente, mais pas celle des entités sur lesquelles ils portent, ni des descripteurs et des moniteurs attachés.
    Et l'appel éventuel aux fonctions DeleteEntityInstances et DeleteMonitors, pour libérer la mémoire occupée par les entités (et leurs descripteurs) et les moniteurs. Ceci peut être nécessaire, par exemple dans le cas d'un enchaînement d'un grand nombre de simulations portant sur des entités différentes.


This page was generated with the help of DOC++.