Long-living systems often cope with fast-changing trends in the current market. Changes originating from new features or bug xes can create great e ort. Therefore, it is desirable to know the impact of the changes on quality aspects of a system beforehand. Simulating the system allows estimating the impact of a change without the time and cost investment of an actual implementation. Nevertheless, the code quality of simulations is often neglected. This results in increased development cycles for the simulation until the cycle time is no longer sustainable. Therefore, we propose using a metamodel to describe modular simulations. This will allow reusing simulations and because of the modularity, the simulations will be composable. Consequently, it will also reduce maintenance and development e orts because simulations can be smaller designed and reused. Smaller means that a simulation could serve only one purpose. In this paper, we propose an excerpt of our metamodel with the focus on coupling and interoperability of simulations.
In software engineering designing and running long-living systems is a hot topic.
Software is getting older. Distinct releases with long development cycles are
disappearing. Instead, short development cycles and incremental releases are
advancing. Companies like Microsoft (O ce365) or Adobe (CreativeCloud) use
subscription models for their software portfolio. Therefore, maintenance and
implementing new features while not breaking the code are getting more
important. To achieve short development cycles without breaking the software
system, the impact of these changes should be known beforehand. A simulation
allows analyzing impacts to a software system without actually implementing
these changes [
As a motivational example, we will introduce two independent simulations. One simulation analyzes a public transport system with bus stops and buses. Each bus has a xed number of seats and is part of a bus line. A bus line consists of a number of bus stops. These bus stops must be visited in a given order. Furthermore, people waiting at a bus stop will enter a bus if not all seats are occupied. If all seats of a bus are occupied, the remaining people will wait for the next bus to arrive. The second simulation simulates a person's daily routine. However, the routine is simpli ed and does not represent a real person's life. A person has a xed home and workplace. The way to work can be walked or driven by public transportation. Each person has two bus stops which have to be used on their way to work. Whether a person walks or drives can be random, xed or also be in uenced by the weather. The di erence between random and weather is that the rst is individual for each person and the second a ects a batch of people. Nevertheless, bus stops are present in both simulations. The population of the bus stops of the bus simulation is normally generated within the bus simulation. However, now the bus stops will be populated by the people of the life simulation. Therefore, the two simulations will a ect each other. We will introduce how these two simulations can be coupled. Hence, in this paper, we focus on the coordination of the data exchange of these two simulations. 3
Approaches to improve the evolution of software simulations are divided into two categories. The composition of simulations and the interoperability between simulations, and the modeling of simulations. Approaches to composition and interoperability are presented together.
Simulation Composition and Interoperability Reusing a simulation or
parts of a simulation require composability and interoperability. The Distributed
Interactive Simulation (DIS) [
Simulation Modeling Data and behavior of an HLA simulation has been
modeled by Topcu et al. [
If a simulation has to be coupled with other simulations the coupling and
communication have to be managed. In [
Modular Simulation Environment
1 Service Interface
Coordinator +
Connector + Management Service 1 *
1 Data Specification
Container *
Ann*otation Container 1 *
* Ad*apter * Annotation Interface
Annotation * exchange between simulations. Even if these simulations are developed independently. Conversion information necessary for the Coordinator is de ned in the Service Interface. The Service Interface provides a set of coordinator functions callable by the connected simulations.
Connector The Connector enables communication between a simulation and the MSE. Each simulation and the Coordinator have to implement a Connector. The Connector of a simulation invokes functions of the Coordinator. These functions are provided by the Connector. However, an existing simulation will not have a Connector automatically built in. Therefore, a wrapper has to provide the Connectors functionality. The Wrapper will encapsulate the simulation. If changes will occur either for the simulation or the MSE, it will only a ect the wrapper but not the whole system. A concrete realization of a Connector is not part of our metamodel, because the actual implementation is depending on the domain. Each simulation has to implement a Connector in order to access the Connector. Regarding the motivating example, a Coordinator has to be implemented. Otherwise, no data could be received or sent by the simulations. Adapter In order to combine di erent simulations, the required and provided data of these simulations need to be aligned. The problem is that each simulation can require and provide di erent data types. As a result, a simulation has to know what data types are provided by the other simulations to enable a data exchange. However, reusing simulations may require a change when it will be coupled with new simulations. Therefore, we propose the Adapter. An Adapter can be developed independently of the used simulations and the MSE. For instance, two simulations using time information but one calculates in hours and the other in seconds. Thus, if these two simulations need to exchange time information the transformation can be de ned in the Adapter. The motivating example needs one Adapter. The adapter transforms the walking distance of the human simulation from a oating point value to an integer value. Annotation Interface Data provided by a simulation must have context information, so that the data can be processed by the Coordinator. Therefore, we introduce the Annotation Interface to allow annotating context information to a datum. Annotations are a part of the Annotation Interface. These Annotations can be divided into two categories. The Scheduling Annotation de nes in which order data has to be sent by the Coordinator to the receiving simulation. Further, the Update Annotation de nes under which circumstances a datum has to be sent by the simulation. Three types of Update Annotation can be speci ed. Either on a xed time interval, if a prede ned condition occurs, or if a simulation requests a datum. Regarding the motivating example, we de ned one Annotation for the incoming data order, which is ordered by timestamp.
Management Service The Management Service is responsible for the internal processes of the coordinator. For instance, a dedicated time management service is responsible for the advancing time of the simulation. Another Management Service may handle data in the Coordinator, it creates and destroys data if necessary. In order to handle data, the de ned annotations which are stored in the Annotation Container, are accessible by the management services. The Annotation Container is stored in the Coordinator, thus an Annotation can be de ned at a central point and reused if necessary. Also, the ownership of the data can be supervised by a Management Service. Each Management Service ful lls one purpose and can be reused by other coordinators. For the motivating example, three Management Services have to be implemented. A publishing service sends events to the right receiver (e.g., number of waiting persons at a bus station when a new person arrives). A subscribing service allows the subscription for events and a time advancing service manages the triggering of events regarding the time advancement.
Data Speci cation Container All data types present in the Coordinator are de ned in the Data Speci cation Container. A central speci cation allows reusing the de ned data types for di erent simulations. Furthermore, if a change requires to modify a data type then the modi cation can be made at the Data Speci cation Container. The Data Speci cation Container of our motivating example contains an Integer (number of seats, occupied seats, waiting persons and distances), a String (bus line name, person name, etc.), and a Bool (is raining) data type. 5
In this paper, we proposed the metamodel for a modular simulation environment. We introduced a motivating example with a bus and a human simulation. These two simulations had to be coupled to create a more detailed simulation. Based on these two simulations, we described the necessity of the Modular Simulation Environment Metamodel. The purpose and functionality of each metamodel element were explained. We have shown that our metamodel allows describing the coupling and interoperability on an architectural level. However, the metamodel has not been used for an actual coupling scenario. Therefore, we have to evaluate our metamodel as the next step. We have to ensure that the behavior of the two simulations is not negatively a ected by the coupling. Thus, the behaviour of a simulation must be integrated in the metamodel. Currently we are working on a Domain Speci c Language which uses the metamodel as base. Our goal is to allow a automated generation of the code which is necessary for the coupling.
This work was partially supported by the MWK (Ministry of Science, Research and the Arts Baden-Wurttemberg) in the funding line Research Seed Capital (RiSC). We would like to thank Prof. Shmuel Tyszberowicz for his valuable input.