Home

Welcome to the model-execution (MX) wiki!

Here we will execute the models we have built using Python.

The goal here is not to implement a system, but to execute it for the purposes of testing, validation, inspection, and experimentation.

Why not implement? Well, there are a variety of model compilers that can deliver an implementation of the models on a target platform such as an embedded ARM processor. (See the great work being done at Model Realization, for example).

Concepts

Let's see how all this works with the Elevator Case Study.

The Elevator domain models are defined in a system package. The structure of this package is defined in the readme file of the xuml-populate repository.

The xuml-populate tool parses the content of the system package and populates an SM Metamodel schema.

It yields a <system>.ral file containing a text serialization of a TclRAL database. This database has a metamodel schema populated with one or more modeled domains.

If you only want to execute one domain, provide a single domain system to xuml-populate.

Execution Environment

We need a name for the execution environment we are creating to run our elevator domain(s).

In fact, we'll just call it that: Execution Environment (XE).

So the XE represents a workspace where you load your model components (classes, states, activities) so that you can run them against various scenarios that you've defined.

Scenario

That gets us to the next term: Scenario.

A Scenario defines an initial population of instances (Shafts, Doors, Cabins, Banks, etc) and a set of interactions among those instances and any external domains.

Now we need a name or a specific sequence of interactions.

In fact, let's refer to the initial instance population of a model as a Context. We then define a set of scenarios that operate within the context we've established.