Wiki

Clone wiki

scenariotools-sml / Executing domain model code

Summary

The ScenarioTools™ runtime uses generated code to evaluate domain model functions. The code must generated before simulation or synthesis with help of the EMF code generator.

Motivation

Currently, there are two features of the language that require evaluation of domain object functions.

Dynamic roles may be played by multiple (arbitrary) objects. For example, consider the parking lot example. A scenario may specify, that after a driver pays the fees, her car should drive out to the exit. The concrete object that plays the car role here, should be dependent of a reference or a function of the object playing the driver role.

Another language feature where functions are important are (boolean) expressions. Expressions may be used for restricting the iteration of loops and for declaring state conditions. Again, for evaluating expressions, the runtime has to invoke functions of domain level objects.

The SDL specification only references model elements of the domain meta model. This is fine for structural elements(references/attributes), but poses a problem for method evaluation, since no implementation exists yet for these methods.

Solution

The user generates code from the domain models with help of an EMF generator. After that, she implements the required method bodies. The code is compiled automatically by eclipse. During runtime initialiation, the runtime searches for the compiled classes and loads them. Whenever an instance of a domain model class is created, the generated code is used instead of dynamic EObjects.

Notes

In order to obtain a correct simulation result, all method implementations must be "pure".

At the moment, there is an issue with the classloader (it is not so trivial to "unload" classes).

Currently, only one domain package is supported.

Implementation Details

The class loader helper loads all domain packages. Before doing anything else, the runtime must replace the package proxies in the specification with the loaded package instances. Otherwise, two instances of each package exist:

  • the dynamic package referenced by the specification
  • the generated package instantiated by the class loader

Mixing elements from both will lead to errors. For example, the eSet operation may not be called on a generated instance with an EStructuralFeature instance from the dynamic package.

Updated