State Transition Diagrams (STDs) are used along with specifications to define the functional detail for a system.
Unlike data processes, control processes have a specialised role: enforcing sequencing over environmental control stimuli to the system, and the internal operation of the system. A control process is defined on an STD that represents the definition of the control process as a finite-state-machine. The number of the STD is the same as the number of the control process it defines.
The finite-state-machine enters an initial state when activated, either notionally at system startup or when the control process is activated by an enable or trigger prompt. In entering this initial state, it may perform some actions, defined below.
Once in a state, the finite-state-machine may only enter another state by making a transition to the new state. A transition is only possible when its condition is satisfied, and in moving to the new state the finite-state-machine may perform zero or more actions. Every state must be the destination of at least one transition. A transition may cause the finite-state-machine to return to the same state, i.e. the old and new states resulting from a transition may be the same.
Transition conditions consist of one or more expressions combined with any of the operators AND, OR and NOT. The transition only occurs when the condition is true, that is, when the input event flow(s) is/are present. The finite-state-machine makes transitions between states in response to some internal (to the system) or external (from the environment) event. Environmental control-related events are often modelled as input event flows to a control process, that in turn cause transitions (and consequential actions) in the control process’s STD.
A transition action can take one of three forms:
ENABLE process name - enable the named processENABLE: process name - enable the named processD: process name - disable the named processDISABLE process name - disable the named processDISABLE: process name - disable the named processT: process name - trigger the named processTRIGGER process name - trigger the named processTRIGGER: process name - trigger the named process
R: flow name - raise the named continuous flowRAISE flow name - raise the named continuous flowRAISE: flow name - raise the named continuous flowL: flow name - lower the named continuous flowLOWER flow name - lower the named continuous flowLOWER: flow name - lower the named continuous flowS: flow name - signal the named discrete flowSIGNAL flow name - signal the named discrete flowSIGNAL: flow name - signal the named discrete flow
You can put algebraic expressions in conditions and actions, e.g.:
I < 10
for a condition and
for an action.
Elements of algebraic expressions are not consistency checked, e.g. we do not look for a data definition called I or i in the above examples. The presence of < > + - * / triggers something being recognised as an algebraic expression.
STDs are not hierarchical. Their connectivity is:
STDs are available in models in both in the Essential and Implementation Domains.
A condition is used on a transition to indicate that something is being acted on to move the system from one state to another.
While there should be one condition that causes this transition to take place, a number of conditions may be required, or be acted on, at the same time.
There are three logical operators that can be used in the condition to group conditions together. These are the logical operators:
These can be used to combine conditions together (AND and OR), or change the test that is made for the conditions (NOT).
In Cradle, the conditions using logical operators are still drawn as a separate condition. They are often positioned close to each other to give the appearance of a single condition using logical operators.
It is the use of logical operators in the name of the condition that distinguishes this condition from a normal condition. The positioning of the conditions relative to each other has no bearing on the way in which Cradle treats them.
In certain cases it can be useful to use literal expressions within the condition used on a transition. For example, when testing an enumerated type for one of its values as the indication of the state which should be transitioned to. In the enumerated set, the literals do not have data definitions’ definitions, as they are alternative values for the data definition.
Assignments are made in literal expressions as follows:
output = “Blue”
The assignments must be used in an action on an STD, they cannot be used as a condition. The literal which is being assigned should be one of the components in the composition for the variable being assigned.
Tests are made in literal expressions as follows:
Output == “Blue”
This is used in the condition on a transition in an STD, not in an action. Again, the literal that is being tested for should be part of the composition of the item being tested.
When using literal expressions, the conditions and actions are drawn in the same way as for other conditions and actions, it is the names given to the conditions and actions that differentiate them.
The numbering system for STDs is dot-decimal. STDs cannot exist in a hierarchy and so no STD symbol can be expanded into a lower-level diagram. It may, however, be the case that control processes in two DFDs in the DFD hierarchy expand into STDs whose numbers give the illusion of a hierarchy with a DFD-like numbering system. While the decomposition of control into a control hierarchy is a normal element of many systems, such hierarchical numbering of STDs will be purely coincidental and neither should, nor does, have any significance to Cradle.
An example STD is:
The symbols available in STDs are: