Initializing the mdb

26-2-25 MX factor out Model Debugger

When we fire up our execution environment, we aren’t going to load an initial scenario or even a context.

We do load the populated metamodel:

mmdb_elevator.ral as db=mmdb

This effectively maps MX to the Metamodel domain

The basic thread is:

main -> xe (execution environment) xe -> system system ->> domain

Interaction from debugger interface:

set syspath ~/SDEV/Python/PyCharm/ModelExecution/src/mx/examples

show syspath ~/SDEV/Python/PyCharm/ModelExecution/src/mx/examples

show systems elevator_system wets_system

load elevator_system

show contexts one_bank_one_shaft one_bank_no_stops

populate one_bank_one_shaft

Before we can do any debugging we need to load a system. This consists of a populated metamodel.

Afterwards we need to load a context for each modeled domain.

Before we can do any of that, we need to know where the system data is located and that means that we need to set a path. The path can be set either by supplying an argument when starting up the debugger, or by manually setting it after te debugger starts up.

26-3-3

The next step is to exchange control between the system and the mdb.

The mdb will call a function on the system:

s.inject( stimulus, responses ) : response

The system picks up the thread and processes any stimuli. If no stimuli are provided, this functions as a ‘resume’ command.

When any of the responses occurs, it is returned. We need to return it since sometimes we are waiting on multiple possibilities and we need to know which one happened.

Now the mdb picks up the thread and the cycle repeats.

If multiple responses were requested and only one occurred, the mdb must repeat the request if it is still looking for the remaining response since the system does not retain memory of it. This allows the mdb to manage and/or response logic without putting that burden on the MX.