0:00
Normally state machine diagrams are drawn in a deterministic way.
You have a state and event pair and that goes to one state.
In general, a component controls multiple variables that evolve in parallel.
For example, in our train system,
the train controller might control the variables of
doors state and also be looking at the movement state in parallel.
We want to say things like open,
open on emergency, closed, stopped, accelerating, decelerating.
If we consider each of those,
that leads to nine states just to represent all combinations of values.
Thus, we actually need 27 states to show all possible transitions.
To represent concurrent behaviors,
it's much nicer to define state machine diagrams as parallel compositions.
You have one diagram per variable and those evolve in parallel.
Then you only need to show M x N states explicitly.
These parallel state machine charts are called State Charts.
Your statechart trace is then a list of the sequence of
successive aggregated state machine states.
For example, here, we're looking again at
our train system and we have two variables evolving in parallel.
For simplicity, we're just going to consider
two possible states in each diagram. Keep it nice and simple.
This also gives us a way to represent
real concurrency as it will naturally occur in the system.
The dashed line in between these two subdiagrams shows parallel composition.
Again, this is a state chart and is made up of two state machine diagrams.
So take a look at this diagram and let's figure out what's going on.
In the top part we're dealing only with the variable of doors state.
We start initial state with the doors closed.
Then, when the speed is at zero,
this is our guard, the doors open.
Then the event closing happens,
moving us back to the state of doors closed.
The bottom state machine diagram is very similar.
The trace is then computed as a parallel composition of the successive aggregate states.
For example, one trace here would be doors closed and the train has stopped.
That goes to doors closed and the train is moving,
which moves to doors closed and the train is stopped,
and then doors open and the train stopped.
When state machine diagrams are fully formalized,
tools can automatically check desired properties and generate counterexample traces,
using these interleaving semantics,
so we don't have to go through it all by hand.
These reveal non-deterministic choices where
they are needed and often help in finding errors.
State machine diagrams are often used to specify reactive systems and user interfaces.
They provide a convenient notation for specifying the system's dynamics overall.
So user interfaces can be represented,
using almost exactly the same structure.
You can show things like states that are achieved by pressing a function key,
clicking a link, filling in a dialog box button.
You might also have invalid user input leading to error messages,
may detect that the printer is out of paper,
or you type in a menu option number and then press enter.
The event is pressing enter, then what happens.
The SRS section on user interfaces should specify functionality,
but dialog maps provide an uncluttered way to
demonstrate all of these functional techniques.
They are more detailed than those UI diagrams and more precise
and they are more precise than the general storyboards.
The last diagram type that we're going to discuss is the R-net diagram.
It is sometimes desirable to document in a diagram all of
the required responses to a single stimulus.
This help us to identify decision points and see
how the application should operate under certain conditions.
R-net diagrams are really good at getting into those "what if" questions.
They also show the required software reactions to those environment events.
In an R-net diagram you enter the input stimulus,
give precedence and define the response operations.
Now some responses have decision points.
This kind of looks like a flow chart,
but based on responses and precedences.
For example here, we have the input stimulus of a new meeting request.
Then we create a directed tree with arrows to indicate the precedence.
The root hexagon shows the input stimulus,
boxes indicate operations needing to be applied as
responses and we've got circles going through here showing decision points.
Traces can be created through R-nets too,
further expanding our event trace diagrams.
These can clarify state machine diagrams based on
a single input stimulus and most people also find these quite a bit easier to read.
The operations may evaluate data,
produce output or generate events,
all of which could be stimuli for other R-nets.