Sequence Based Specifications - Key Concepts and Best Practices © 2013 Verum
1
Triggers and actions are important concepts to understand when creating a
sequence based specification.
Trigger: a Call Event, Notification Event or Reply Event that is input to the
component
Action: a Call Event, Notification Event or Reply Event that is output to the
component
Triggers and actions have call & return-style semantics; a trigger is analogous to a
call and an action is analogous to a return.
Triggers and actions are as seen from the component perspective. In a client-server
relation between two components, an action from the client is a trigger to the
component and vice versa.
Sequence Based Specifications - Key Concepts and Best Practices © 2013 Verum
2
It is possible that a trigger cannot or may not occur:
• In ASD, if a trigger cannot occur, i.e. a system cannot observe the trigger and/or
the environment cannot generate it, such a trigger is called Blocked. For example,
when a component A has invoked a request at some other component B, it can only
“see” the synchronous reply value as an incoming trigger. In ASD such a reply value
is called a Reply Event. Since component A has to preserve run-to-completion
semantics, it cannot handle requests performed at its application interface and
neither can it process notification requests. In other words, these are blocked. (We‟ll
discuss this in more detail later.)
• If a trigger can occur, but it is not allowed to occur, then it is illegal by design.
Note that in this case, the environment could generate such triggers. In ASD, such a
trigger is called Illegal. For example, when a component offers an initialization
method on its interface, it is required that initialization is only to be performed once.
In such a case, the initialization method will be illegal after initialization has been
performed. (We‟ll discuss this too, in more detail later.)
Sequence Based Specifications - Key Concepts and Best Practices © 2013 Verum
3
ASD identifies five special actions. The first two are:
• Illegal, which means that in that particular state a trigger is not allowed. (However,
as explained earlier, the environment could generate it.) It is an observable error.
Code is generated for this. When generating code, assertions are used to check
whether triggers are illegal or not. For example, the following row in a sequence
based specification means that the trigger would be illegal in that state and is
regarded as an observable error:
Initialize
Illegal
-
• NoOp, which means that there is no action at all as a reaction on a trigger. This
also means that no code is generated for that action. For example, the following row
in a sequence based specification means that the trigger may occur but that there is
no observable action:
Initialize
NoOp
NewState
Sequence Based Specifications - Key Concepts and Best Practices © 2013 Verum
4
The next two ASD special actions are:
• VoidReply, which means a trigger has a “void” reply value. Not all triggers need to
have synchronous reply values, like OK, NotOK, etc. However, since triggers are
regarded as synchronous calls to other components which block the calling
component, it is necessary to have an action that unblocks the calling component.
This is comparable to the action you take in C++ where you indicate that the function
ends using “return”. The following ASD example shows a row in a sequence based
specification that indicates the trigger has a synchronous “void” reply value:
Initialize
VoidReply
NewState
• Disabled, which means that in this particular state, the internal trigger represented
as modelling event will not occur and thus will not lead to observable behaviour on
the external interface of the component (by specification i.e. choice of the user). To
limit the state space for verification, disabled modelling events are not included in the
formal model. For example, the following row in a sequence based specification
would indicate that the trigger will not occur:
InitializeDone
Disabled
-
Sequence Based Specifications - Key Concepts and Best Practices © 2013 Verum
5
The last ASD special action is:
• Blocked, which means that in this particular state, the trigger cannot be observed by
the component because it is impossible due to the ASD execution semantics. This
action is typically used when a component has invoked a method to another
component and is waiting for the synchronous reply value. In such a case, this
component cannot observe a trigger call to itself and neither can it observe a call to
notifications. To limit the state space for verification, blocked events are not included
in the formal model. For example, the following row in a sequence based specification
would indicate that the trigger cannot be observed:
Initialize
Blocked
-
The ASD:Suite will ensure correct use of the Blocked action; “Blocked” will be filled in
automatically whenever it is applicable.
Sequence Based Specifications - Key Concepts and Best Practices © 2013 Verum
6
In a sequence based specification we distinguish:
• Rule case – a rule case specifies one specific case of behaviour.
• This may be prefaced by a guard expression indicating under what
condition the rule case is executed.
• A rule case is represented by one single row in the SBS.
• Rules – a rule specifies the complete behaviour for a specific trigger in a
specific state.
• A rule contains one or more rule cases and consists of one or more
rows in the SBS.
• All rule cases within a rule together specify the complete behaviour for
that trigger in that state for all conditions .
Sequence Based Specifications - Key Concepts and Best Practices © 2013 Verum
7
We mentioned earlier that a component maps every sequence of triggers to a set
of actions, a “set” being defined as containing one or more actions. Objectives
for a sequence based specification map quite nicely to this principle, as a
sequence based specification ensures that indeed each sequence of triggers is
mapped onto one single set of actions. Furthermore, when building up the
sequence based specification, each trigger-action pair has to be justified by one
or more requirements.
The sequence of triggers that has occurred before another trigger occurs is
captured in a state machine. If a trigger occurs in a specific state, the associated
action may differ from the action on that trigger in another state. The following
examples will make this more clear.
Sequence Based Specifications - Key Concepts and Best Practices © 2013 Verum
8
Let‟s have a look at a small example. In the SBS above, several trigger
sequences can be identified. The first sequence that we address is the emptysequence. No triggers have been fed into the system yet. This resembles the
initial state of the component at creation with a state “Uninitialized”.
Now for each trigger we have to specify what the behaviour will be, or in other
words, what the action(s) will be on each trigger. Furthermore, we have to
identify a requirement that justifies that behaviour (not shown in the figure to
save space). If no requirement can be found, we have to talk to the stakeholders
and find out what the behaviour should be.
Here, it is assumed that if nothing has happened to the system, we must first
initialize it before we can do anything else with it.
When the client invokes the Initialise method and the „Initialise‟ trigger occurs, a
defined set of actions occurs. First, the component calls the Initialise method of
all used components and then replies to the client call with a „InitialisationOK‟.
After that, the transition to the new state „Initialized‟ is made.
We continue the explanation of the SBS in this next state in the following
example.
Sequence Based Specifications - Key Concepts and Best Practices © 2013 Verum
9
This part of the SBS shows the state just after the system has seen the Initialise
trigger. Again, all triggers must be explored to see what the behaviour should
be. Requirements must be linked justifying the transition.
When „Terminate‟ is called, we go back to the first state. So this means that the
sequence “Initialise, Terminate” is equal to the empty sequence. All behaviour
after the “Initialise, Terminate” triggers is the same as after the empty
sequence. This is an easy way to identify behaviour that has already been
seen.
When „Calibrate‟ is called, a defined set of actions is followed. First the
component replies to the client call with a „VoidReply‟ (previously NullRet) and
then calls the Calibrate function of the used components „XStageTrack‟ and
„YStageTrack‟. After that, the transition to the new state „Calibrating‟ is made.
We continue the explanation of the SBS in this next state in the following
example.
Sequence Based Specifications - Key Concepts and Best Practices © 2013 Verum
10
In the state „Calibrating‟ a number of triggers may again occur, either initiated by
the client (Initialise, Terminate, Start, LoadWafer, UnloadWafer, Stop), or by a
used component (Calibrated, Arrived). Each trigger is explicitly dealt with in the
SBS, even if it is not allowed to occur, in which case the action is set to „Illegal‟.
Note: Illegal and Blocked triggers have been filtered out in this example.
By defining the behaviour for each trigger, the sequence based specification is
built up step-by-step. At a certain point no more new states will be discovered;
every sequence of triggers will lead to an already existing state. This approach
leads to a complete description of the behaviour of a component.
Sequence Based Specifications - Key Concepts and Best Practices © 2013 Verum
11