Concepts

The purpose of the Model Debugger is to observe, experiment with, and detect problems in a modeled system.
This is not a testing domain, though we could use it to run tests. This is analogous with code debuggers vs testing environments.

What’s the difference?

With a test we define initial conditions, some things to do, and we assess final conditions to see if they match the expected result.

Let’s imagine how you might set up a test for an xUML system.

Testing

We would define an end condition in terms of the instances, states, and attribute values as well as pending events that exist at the end of the test. We might be interested in the status of the entire population of one or more domains

In our terminology, we would define the actors and the conditions that exist at the end of the test.

Debugging

Now let’s contrast an execution (debugging) session

Here we we take the perspective that we’ll just poke around interactively to see what’s going on. We don’t know what we’ll want to look at until we start running things.

We generally start off by stimulating the system by interacting with it. There should be a set of actions that we might execute to kick things off. In the case of xUML this will almost always be an event. Or we might invoke a synchronous service.

But we might want to set the value of some attribute. We won’t do this directly through our debugger, but via the MX. (So the MX is a service to the MDB)

After the initial action, we let the system run. We can suspend it at any time. We direct suspension via stepping or by running until some condition is reached.

If we are stepping, we need to set the scope. What are we stepping over? In the case of xUML we step over state entry, individual actions.

The MX gives us the ability to run and suspend.

In addition or instead of stepping, we run to the next condition.

The MDB knows nothing about xUML or Shlaer-Mellor and makes no modeling language assumptions.
But it is aware that there are such things as conditions (a thing that can happen) and actions (a thing we can inject into the system)
In xUML we often want to inject an event. MDB refers to this as an action.
An actor is an active element within the modeling system.

The MDB need only be aware of those active elements of interest in the debugging session.

Let’s say that we want to know when cabin S1 has entered the [MOVING] state. To set a condition for notification, we need to know that there is some actor Cabin. Furthermore, we need its full address within the system, EVMAN:Cabin and for convenience we could just assign a unique value such as A1 (actor 1). Now there may be two other cabin instances, but if they do not participate in our scenario, we don’t need to know about them.

The domains of interest are: [Model Debugger] [Metamodel] [MX]

The metamodel supports whatever has been modeled, but MX gives us the ability to manipulate the context independently.

—

Let’s look at our inject action

UI >|| EVMAN : Stop request -> ASLEV <S1-3>

The action type is signal
The source actor is UI
The target actor is EVMAN:ASLEV<S1-3>
The name of the action is Stop request

A Scenario consists of multiple steps and a Step is characterized as either a Stimulus or a Condition. A Step is associated with an Action. A Stimulus has a delay specified. This is an interval that must pass before injecting the Action.

Let’s move on to the next Step which happens to be a Condition. A Condition is an Action we are interested in. When a Condition occurs we can react by printing some kind of notification or some other task. So the opposite of injecting is to react in some way.

EVMAN >|| UI : XFER<S1> Set destination( Floor=3 )

The action is external event
The source actor is EVMAN:XFER<S1>~UI
The target actor is UI
The name of the action is Set destination
There is a parameter: Floor=3

EVMAN ~|| UI, SIO : Door<S1> [ OPENING ]

The action is bridgeable condition state entry
The source is EVMAN:Door<S1>
The targets are [ UI, SIO ]
The name is OPENING

This last one is interesting for two reasons.

1. The action is not just state entry since the system is actually communicating the condition across domain boundaries (this means that for every bridgeable condition we may define a separate MDB action
2. There are multiple targets

—

Populating Actor/Roles

...inject
1) UI >|| EVMAN : Stop request -> ASLEV <S1-3>
...running
2) EVMAN >|| UI : XFER<S1> Set destination( Floor=3 )
3) EVMAN >|| TRANS : Cabin<S1> Go to floor( Floor=3 )
...delay 7 sec
...inject
4) TRANS >|| EVMAN : Arrived at floor -> Cabin<S1>
...running
5) EVMAN ~|| UI, SIO : Door<S1> [ OPENING ]
...delay 3 sec
...inject
6) SIO >|| EVMAN : Door opened -> Door<S1>
...completed

Interaction

Number	Action type	Name
1	signal instance	Stop request
2	external event	Set destination
3	external event	Go to floor
4	signal instance	Arrived at floor
5	bridgeable condition state entry	OPENING
6	signal instance	Door opened

System Input

Number	Target actor	Target role	Delay
1	EVMAN:ASLEV	R1	0 sec
4	EVMAN:Cabin	R1	7 sec
6	EVMAN:Door	R1	3 sec

System Output

Number	Source actor	Source role
2	EVMAN:XFER	R1
3	EVMAN:Cabin	R1
5	EVMAN:Door	R1

Supplied Parameter

Name	Interaction	Value
Floor	2	3
Floor	3	3

Actor

Address
EVMAN:ASLEV
UI
EVMAN:XFER
TRANS
EVMAN:Cabin
EVMAN:Door
SIO

Role

Actor	Interaction	Role
EVMAN:ASLEV	1	R1
UI	1	R1
EVMAN:XFER	2	R1
UI	2	R1
TRANS	3	R1
EVMAN:Cabin	3	R1
TRANS	4	R1
EVMAN:Cabin	4	R1
EVMAN:Door	5	R1
UI	5	R1
SIO	5	R1
SIO	6	R1
EVMAN:Door	6	R1

Input Source

Actor	Role	Interaction
EVMAN:ASLEV	R1	1
TRANS	R1	4
SIO	R1	6

Input Target

Actor	Role	Interaction
UI	R1	1
EVMAN:Cabin	R1	4
EVMAN:Door	R1	6

Output Source

Actor	Role	Interaction
EVMAN:XFER	R1	2
TRANS	R1	3
EVMAN:Door	R1	5

Output Target

Actor	Role	Interaction
UI	R1	2
EVMAN:Cabin	R1	3
UI	R1	5
SIO	R1	5