Program Dynamics

This section provides a more in-depth examination of the overall program’s dynamics by highlighting the previously introduced user’s perspective through a UML sequence diagram (see Figure 4.5 and Appendix C.3).

From the user’s perspective, the application data model first must be con- structed and initialized. The construction (see Figure 4.6) consists of the load- ing of data files required in the subsequent simulation process. The data that is added to the model is optional but highly dependant on the simulation’s purpose. Here it is defined which model segments are used as modules for the description of the geometry and the activity.

The initialization (see Figure 4.7) of the model then links the previously loaded data together. This makes sure that every segment of the model knows which data has to be applied and how it is going to be used. After the linking of data has terminated, the simulation engine is instantiated and further connected to the data model. This accounts for possible errors that could occur, if the data was either incompletely or improperly linked together. Therefore, the initialization is also a data-verification and data-linkage verification mechanism.

Figure 4.5: Sequence diagram: User perspective. The given figure is a UML se- quence diagram representation of the user’s perspective use-case as described in the previous Section (4.1.3.1). Here, the function calls for the creation of data objects and the triggering of a simulation are outlined. It can be seen that in addition to ordinary function calls with a synchronous return of approval, there is an additional incidence of an asynchronous return event: This repetitive event call states the availability of simulation output data that can be collected by the user. The model construction (Figure 4.6), initial- ization (Figure 4.7), and destruction (Figure 4.8) are out-sourced for better clarity and readability.

Hence a simulation can only occur if the initial data is complete and properly linked.

If the model was loaded and found acceptable by the initialization routines, the actual simulation can begin. By doing so the simulation engine is invoked to iterate over the given data through the use of the given algorithms in defined time steps (see Figure 4.5). After each iteration output data is produced which can be further used as a base for the next iteration cycle and is returned to the

Figure 4.6: Sequence diagram reference: Model construction. The construc- tion of the application’s data model consists of the addition of data segments as of the geometry description, the activity description, re- action, as well as diffusion algorithms. The adding of such segments is optional and highly depends on the purpose of the simulation. At this stage the data is loaded but not further connected to each other. This connection process will be executed during data initialization (see Figure 4.7).

user for subsequent analysis. To ensure that the running simulation does not block any user interactions, it is set up as a separate thread. Hence the user is informed of newly created output data via asynchronous calls from that thread. The output data itself is continuously saved to the connected permanent storage of the systems hardware.

Next either the user is able to stop the simulation manually or simply waits until the previously defined number of iterations have been processed and the simulation engine auto-terminates. With either suspension mode, the user is able to continue simulation since the output data can be reused as new input

Figure 4.7: Sequence diagram reference: Model initialization. After the appli- cation model data was loaded and set to the program’s internal data sets it has to be connected to each other. This is done iteratively by searching the geometry descriptions for compartments that give further clues on what other definitions have to be linked.

Figure 4.8: Sequence diagram reference: Model destruction. If the currently loaded model is no longer needed, it has to be destroyed before other (new) models can be loaded. The process of destruction is highly dependant on the chronology of what object has to be deleted first. It is of major importance to remove the simulation engine instance first and then destroy the input description and the algorithms in this order. Doing so ensures that the data is removed from its link-

data. Here no reinitialization is necessary because all data remains complete and linked until model destruction.

The destruction of data (see Figure 4.8) has to be then performed to avoid possible memory leakage or the overcrowding of physical memory. The de- struction is an ordered process of chronological data model segment instance removal. First the simulation engine is destroyed since the destruction will fi- nally invalidate the given data thereby making the simulation engine obsolete. At this point the data is removed from top to bottom by first deleting the input descriptions and then also the loaded algorithms from memory. It should be noted that no data is finally lost at this point due to the automatic saving of output data by the simulation engine. If the user decides to remove such stored files as well, then the data is definitely lost and can only be reproduced by a repeated simulation.