Architecture

Separation between data, logic, and presentation

Many conventional simulation tools offer a what-you-see-is-what-you-get-approach where data, model logic, and model presentation are intertwined and mixed within a single artifact, like shown on the picture below.

Conventional tools architecture

This approach allows modelers to build simple models fast and easily. However, the exact same approach impedes the creation and usage of a big complex simulation models. Amalgama Platform offers separation of data from model logic, and logic from the presentation.

Amalgama architecture concept

Such separation results in flexibility and reusability of simulation models due to:

  • The model does not contain any hard-coded numbers – its parameters are well-structured and stored separately in the input data

  • The model logic is independent of outside world that provides the freedom of abstractions and algorithms used for modeling

  • Several different presentations can be plugged-in to provide a view of the model from different perspectives. For example, these can include 2D-animation, 3D-animation, dynamic charts, and textual logs

  • Isolating the model logic makes it more testable

Minimalistic example

Let us look at a minimalistic simple example of the simulation model – console application with API for parameterization (see this example). Input data for such model is set by the model’s API whereas the model’s output is just printing to the console:

Minimalistic example of Amalgama simulation model

Basic model architecture

In the majority of cases, the real model will be much more complex than the example above. The standard model created by Amalgama’s model wizard and has the following structure:

Architecture of Amalgama desktop application

The tutorial models also have this structure. Let us look at the element of this diagram:

  • The “model” itself is a multi-platform desktop application that works on Windows, Mac, and Linux

  • The data model describes the structure and parameters of the simulation model’s input data. Basically, data model is an entity-relationship diagram describing the domain being simulated. The platform allows to automatically map these diagrams to many actual storages, most popular being Excel files.

  • The model logic is the set of classes that use simulation engine to replicate the dynamic of the system being modeled

  • The model animation shows the behavior of the system in either 2D or 3D view

  • The charts and tables help users understand and analyze the system’s behavior

  • The model application opens and runs different scenario files similar to how a text processor opens and allows users to edit the text files

Enterprise model architecture

Desktop application is very useful for building, verification, and validation stages of simulation project because it allows to achieve a very short iteration time between changing the logic and seeing the results. Desktop app is sufficient for most of the models that are built for support of once-off decisions.

However, some models are intended for regular use or even working as a service inside a corporate IT-landscape. For such cases, enterprise architecture can be used as shown on the figure below:

Architecture of Amalgama enterprise application

Note that the same code is used for both data model and model logic. This architecture supports the 2-loops of model life cycle:

  • The top loop is model building, testing and evolution. This is done by simulation modelers who use desktop application to constantly analyze and verify the results produced by the model

  • The bottom loop is model operationalization, where the model can be run as a service that gets the input data and provide the simulation results that are passed on to the external systems