A Unified Formulation of Behavioral Semantics for SysML Models
Christoph Hilken
1
, Jan Peleska
1
and Robert Wille
1,2
1
Institute of Computer Science, University of Bremen, 28359 Bremen, Germany
2
Cyber-Physical Systems, DFKI GmbH, 28359 Bremen, Germany
Keywords:
SysML, State Machines, Transition Relation, Model Checking, Model-based Testing.
Abstract:
In order to cope with the complexity of today’s system designs, higher levels of abstraction are considered.
Modeling languages such as SysML provide adequate description means for an abstract specification of the
structure and the behavior of a system to be implemented. Due to its sufficient degree of formality, SysML
additionally allows for performing several automated test and verification tasks. For these tasks, however, a
formal encoding of the behavioral model semantics is required; this is typically achieved by generating initial
state conditions as well as the transition relation from the model. Since SysML provides a multitude of alter-
native or complementary notations, this poses a significant challenge to the development of corresponding tool
support. In this paper, we therefore propose an alternative approach to the generation of transition relations:
In a first step, a model-to-model transformation is applied which unifies the behavioral descriptions into one
single notation, namely operations allocated in blocks and specified by pre- and post-conditions. Afterwards,
only pre- and post-conditions as well as some auxiliary constraints for fixing semantic variation points need to
be considered when generating the transition relation. The approach presented here has been evaluated in the
development of industrial tools supporting bounded model checking and model-based test generation.
1 INTRODUCTION
The design of systems including hardware as well as
software components has become a cumbersome task.
An increasing number of components, a tighter hard-
ware/software interaction, or the integration of cyber-
physical components such as sensors and actuators
have led to a significant complexity to be tackled.
In the early phases of the design modeling lan-
guages such as UML (Object Management Group,
2011a) and its profiles SysML (Object Management
Group, 2010) and MARTE (Object Management
Group, 2011b), as well as others have shown to be
beneficial. SysML, for example, provides several de-
scription means such as block definition diagrams (for
the structure of a system), activity diagrams (for the
behavior of operations in a system), or state machines
(for control states of a system and their transitions)
to precisely specify the structure and behavior of a
system prior to its implementation. Constraints pro-
vided in OCL (Object Management Group, 2012) al-
low to additionally refine the respective descriptions
with requirements to be satisfied. While this can al-
ways be used as a blueprint for the implementation
phase, the corresponding (formal) descriptions addi-
tionally allow for performing several automated test
and verification tasks, even if an implementation is
not available yet.
As a consequence, several methods and ap-
proaches have been presented in the recent past uti-
lizing these formal descriptions, e.g. (1) to prove that
the specification is free of contradictory requirements
(see e.g. (Gogolla et al., 2009)), (2) to check for un-
wanted behavior to be avoided (see e.g. (Soeken et al.,
2011; Hilken et al., 2014)), or (3) to generate tests for
the actual implementation (see e.g. (Peleska, 2013)).
Indeed, very powerful and complementary solutions
have been investigated, including approaches based
on theorem provers such as Isabelle (Brucker and
Wolff, 2006) or the KeY approach (Beckert et al.,
2007) as well as based on automatic solving engines
such as CSP solvers (Cabot et al., 2008) or SMT
solvers (Soeken et al., 2011).
These methods, however, usually rely on a trans-
lation of the model under consideration to its corre-
sponding transition relation, for the purpose of en-
coding the model’s behavioral semantics. This is a
laborious and, at the same time, highly critical task
in which any error will significantly spoil the verifi-
cation or validation result. Moreover, modeling for-
malisms like SysML provide a multitude of alterna-
tive or complementary notations for behavioral de-
263
Hilken C., Peleska J. and Wille R..
A Unified Formulation of Behavioral Semantics for SysML Models.
DOI: 10.5220/0005241602630271
In Proceedings of the 3rd International Conference on Model-Driven Engineering and Software Development (MODELSWARD-2015), pages 263-271
ISBN: 978-989-758-083-3
Copyright
c
 2015 SCITEPRESS (Science and Technology Publications, Lda.)

scriptions (i.e. state machines, activities, interactions,
use cases, and operations) and existing approaches
need to be provided with a transition relation for each
and every one of those. This poses a significant chal-
lenge to the development of automated approaches for
the verification and validation of models.
In this work, we aim for addressing this issue
by proposing a two-step approach for the genera-
tion of the desired transition relation. First, a syn-
tactic model-to-model transformation of the given
behavioral descriptions into newly added operations
specified by pre- and post-conditions and allocated
in blocks is performed. This unifies the descrip-
tion means of a system’s structure and behavior and,
through this unification, simplifies the generation of
the transition relation to be conducted in the second
step. As a result, support for further behavioral de-
scriptions can be added more easily into approaches
for verification and test.
The effectiveness of the proposed approach is ex-
emplified by translating behavioral state machine de-
scriptions into blocks and operations, and creating
the transition relation from the latter representation.
The approach has been evaluated during the develop-
ment of an industrial-strength tool for bounded model
checking and model-based testing with SysML mod-
els.
The remainder of this paper is structured as fol-
lows: The next section briefly reviews the basic con-
cepts of SysML while Section 3 sketches the problem
formulation as well as the general idea of our solu-
tion. In Section 4 the transformation of state machines
(serving as an example of a formalism for which a
transition relation generator is required) into block di-
agrams and associated operations is described. This
section is complemented by Section 5, where the
transformation of blocks/operations into the propo-
sitional representation of transition relations is ex-
plained. In Section 6, we report on an actual imple-
mentation following the strategy described in this pa-
per. We conclude with a summary in Section 7.
2 BACKGROUND
The OMG Systems Modeling Language SysML (Ob-
ject Management Group, 2010) offers description
means to specify the structure and the behavior of a
system. The structure of a system can be described
by means of Block Definition Diagrams (BDD) con-
sisting of blocks and associations/relations between
blocks. A block has different features, which are
grouped in compartments, such as properties or op-
erations. The former represent the state of the com-
ponent represented by the block, the latter its behav-
ior. Using design-by-contract, the effect of opera-
tions can be expressed by means of pre- and post-
conditions. To this end, the Object Constraint Lan-
guage (OCL) (Object Management Group, 2012) can
be used. The SysML also offers descriptions means
to explicitly specify the behavior of components; ex-
amples are activity diagrams, sequence diagrams, or
state machines. For illustrating the objectives of this
paper, state machines are used.
When referring to the elements of SysML state
machines, some auxiliary functions are needed. In
tool implementations, these functions are typically re-
alized as operations defined on the abstract syntax
tree used for internal model representation. Given
a SysML state machine sm and a transition t
sm
, the
source state of this transition is denoted by t
sm
.source,
and its target state by t
sm
.target. The action associated
with the transition arrow is denoted by t
sm
.effect. The
entry action associated with a state machine state s
is denoted by s.entry, the exit action by s.exit, and
a do activity by s.do. The set of transitions ema-
nating from s is denoted by s.outgoing. For dealing
with composite states s in hierarchic state machines,
function parent(s) returns the immediate parent state
of s. The whole state machine sm is considered as
the root composite state of a hierarchic state machine,
so parent(s) = sm, if s resides on the highest level
of a state hierarchy. Function subs(s) returns the set
of all true sub-states of s, regardless of their position
in the state machine hierarchy. For simple states s,
subs(s) = ∅. Composite states s are characterized by
subs(s) 6= ∅; function sub(s) returns the pseudo ini-
tial state of the composite state’s immediate subma-
chine. sub(sm) is the pseudo initial state of the whole
state machine. If s
0
is a pseudo initial state, then s
0
.t
denotes its single outgoing transition.
Example 1. For the hierarchic state machine de-
picted in Figure 3(a), sub(sm) is represented by the
black bullet point with transition sub(sm).t connect-
ing the pseudo initial state to s
0
. Action s
3
.entry con-
sists of an assignment z = z +1; s
1
.exit of the assign-
ment x = 1. The effect t3.effect of transition t3 is the
assignment r = 0.
In this paper, we only consider single-region
composite states, i.e., each composite state is
associated with a sequential submachine (Object
Management Group, 2011a, 15.3.11)
1
. Compos-
ite states induce state configurations, i.e., sets of
1
Composite states with multiple regions can be repre-
sented in an alternative way by constructing a separate state
machine for each region and associating it with a different
block; this alternative is covered by the approach described
here.
MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment
264

hierarchically related states. The active configura-
tion is the one the state machine currently resides
in. Since we only consider decompositions into
single regions, the active configuration of state
machine sm is already fully defined by its inner-
most active simple state state
sm
and its ancestors
parent(state
sm
), parent(parent(state
sm
)),.. .,sm.
The transitions emanating from hierarchic states
are prioritized (Object Management Group, 2011a,
p. 576): the lower the hierarchy level of a transition,
the higher its priority.
Let state
sm
denote the innermost simple state the
machine sm currently resides in. A transition t be-
tween a source state t.source and a target state t.target
will be taken, if (1) state
sm
is equal to, or a sub-
state of t.source, (2) the transition’s guard t.guard
evaluates to true, and (3) no transition with higher
priority could be taken. To specify the effect of
transition t being taken, the least common ancestor
LCA(t.source,t.target) of source and target state has
to be calculated (Object Management Group, 2011a,
p. 584). This is the lowest composite state containing
both t.source and t.target.
Example 2. Consider again the state machine sm
from Figure 3(a). There LCA(s
2
,s
3
) = s
1
and
LCA(s
0
,s
3
) = sm holds.
The overall effect of executing t is now specified
as follows. (1) All exit actions, starting with state
sm
,
following the parent relation, and ending at the im-
mediate substate of LCA(t.source,t.target) are exe-
cuted in that order. (2) The action associated with
the transition arrow, t.effect, is executed. (3) All en-
try actions, starting with the ancestor of t.target di-
rectly underneath LCA(t.source,t.target), and ending
at t.target are executed. (4) Descending from t.target
until the simple target state – the new value of state
sm
– is reached, the action s
0
.t.effect associated with the
unique outgoing transition t of pseudo initial state s
0
of each submachine is executed, and the entry ac-
tion s
0
.t.target.entry associated with the target state
reached from s
0
is performed. The execution of do ac-
tivities is started after entering a state. Each do activ-
ity either terminates by itself while the state machine
resides in the respective state, or it will be stopped as
soon as this state is left.
3 PROBLEM FORMULATION
AND GENERAL IDEA
Description means as described above allow for a very
precise specification of a system to be realized. The
resulting formal descriptions can already be utilized
to perform automated test and verification tasks. For
this purpose, a variety of (automated) methods and
approaches have been developed in the recent past
(see e.g. (Brucker and Wolff, 2006; Beckert et al.,
2007; Cabot et al., 2008; Soeken et al., 2011; Hilken
et al., 2014)).
A typical step involved in most of these ap-
proaches consists in transforming the model M or
a part thereof into its transition relation Φ
M
. The
transition relation relates model states to their po-
tential post-states. Even for infinite state models,
the transition relation may be represented as a finite
object by choosing its propositional representation
where Φ
M
(σ,σ
0
) is a predicate relating pre-states σ
to post-states σ
0
. In model-based testing and bounded
model checking, for example, this representation is
exploited by solving so-called bounded model check-
ing instances, i.e.
b ≡ I(σ
0
) ∧
k
^
i=1
Φ
M
(σ
i−1
,σ
i
) ∧ G(σ
0
,.. . ,σ
k
) (1)
This constraint specifies a set of suitable pre-states
σ
0
by proposition I(σ
0
). From such a starting
state, the goal G(σ
0
,.. . ,σ
k
) should be fulfilled when
traversing the model for k steps. The conjunction
V
k
i=1
Φ
M
(σ
i−1
,σ
i
) requires that any solution of G
shall be a legal trace through the model: any two
consecutive states (σ
i−1
,σ
i
) in a solution of G have
to be related by the transition relation. For bounded
model checking applications, G typically denotes an
unwanted property (e.g. a safety violation), so that a
solution of b uncovers a modeling error (Biere et al.,
2003). In model-based testing, however, b specifies a
symbolic test case, and the solution of this constraint
solving problem yields a suitable sequence of inputs
to the system under test for covering the test objective
G (Peleska, 2013).
However, following this scheme requires a trans-
formation from the originally given model M to the
transition relation based on the predicates Φ
M
(σ,σ
0
)
2
.
This is a laborious and, at the same time, highly crit-
ical task. Any error in this transformation will lead,
for example, to invalid model checking results and to
test data that is not really suitable for the objective
to be covered. Moreover, modeling formalisms like
SysML do not come with just a single notation for
expressing behavior, but with a multitude of alterna-
tive or complementary notations: state machines (Ob-
ject Management Group, 2010, Section 13), activi-
ties (Object Management Group, 2010, Section 11),
interactions (Object Management Group, 2010, Sec-
tion 12) (e.g. sequence diagrams), use cases (Object
2
Note that we consider this a model-to-text transition in
the following.
AUnifiedFormulationofBehavioralSemanticsforSysMLModels
265

BDD
block
Block B
attributes
operations
block
Block A
attributes
operations
block
Block C
attributes
operations
SM1 SM2
SM3
(a) Source structure
BDD
block
Block B
attributes
state
sm2
: State
operations
op
sm2
t
0
()
op
sm2
t
1
()
...
block
Block A
attributes
state
sm1
: State
operations
op
sm1
t
0
()
op
sm1
t
1
()
...
block
Block C
attributes
state
sm3
: State
operations
op
sm3
t
0
()
op
sm3
t
1
()
...
(b) Target structure
Figure 1: Proposed model-to-model transformation.
Management Group, 2010, Section 14), and opera-
tions (Object Management Group, 2010, Section 8)
allocated in blocks. As a consequence, the corre-
sponding model-to-text transformations usually have
to be developed for each and every of these notations.
In this work, we present an effective approach
which automates those transformations and, at the
same time, makes its validation more reliable. To this
end, we propose a two-step approach:
• First, a syntactic model-to-model transformation
of the formalism under consideration into blocks
and associated operations is performed. The
behavior is then represented in terms of newly
added operations which, in turn, are specified
in OCL (Object Management Group, 2012) by
means of pre- and post-conditions.
• Then, a semantic model-to-text transformation
from blocks/operations into the transition relation
is performed.
Example 3. Fig. 1 illustrates the proposed approach
by means of state machines. Fig. 1(a) provides the
original model in which behavior is provided in terms
of state machines. Those are translated into corre-
sponding operations as shown in Fig. 1(b) which build
the basis for the following translation into a transition
relation.
Following this scheme, the model-to-model trans-
formation (first step) unifies the description means of
a system’s behavior and eventually leads to a model
in which all operations are solely specified by pre-
and post-conditions. Because of this, the translation
into a transition relation only relies on a single no-
tation (namely pre- and post-conditions) rather than
multitude descriptions of behavior. Additional nota-
tions such as activities, interactions, etc. just have to
be syntactically transformed into blocks and associ-
ated operations. Furthermore, many semantic varia-
tion points (Object Management Group, 2011a) can
be implemented in the model-to-text transformation
as well, so that these can also be re-used by means
of alternative “compile switches” applied to the trans-
formation from blocks/operations to Φ
M
(σ,σ
0
). We
illustrate this by showing alternative instantiations
of the concurrency semantics (interleaving or syn-
chronous).
In the following, both steps are described in detail
by means of state machines
3
.
4 MODEL-TO-MODEL
TRANSFORMATION
In this section the model-to-model transformation is
described. First, the generation of the target structure
is introduced. Afterwards, the transformation of state
machines consisting of simple states only is specified.
This is eventually extended further to the transforma-
tion of composite states.
4.1 Generation of the Target Structure
The first step of the transformation is the generation of
the target structure. For this purpose, properties and
operations are added to the structure in order to rep-
resent the state machines’ behavior. More precisely,
given a state machine sm describing the behavior of
a block b, the following properties and operations are
added to b: (1) a property state
sm
representing the cur-
rently active state of sm, and (2) an operation o
sm
t
for
every transition t of sm; o
sm
t
represents the complete
behavior of the transition t, including its associated
entry and exit actions. Note that this transformation
does not consider the behavior of do activities yet.
This will be covered later in Section 4.4.
Example 4. Consider again the given SysML model
shown in Fig. 1(a). The corresponding target
model including the new description means intro-
duced above is shown in Fig. 1(b).
3
Note that state machines have been choosen as a rep-
resentative to illustrate the first step. However, the corre-
sponding model-to-model transformation can similarly be
applied for other notations as well.
MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment
266

As a result of this transformation, each state ma-
chine in the original model has been mapped to prop-
erties and operations extending its associated block,
so that the target model consists of block diagrams
and block specifications only. In the paragraphs be-
low, the transformation details for mapping a given
state machine to block properties and operations are
explained.
4.2 Transformation of State Machines
State machines are transformed into block operations,
one for each state machine transition. In general, the
overall effect of executing a state machine transition is
composed of the effects specified in exit actions, entry
actions, and actions directly associated with the tran-
sition arrow (the latter is called the effect of the transi-
tion (Object Management Group, 2011a, 15.3.14), not
to be confused with the overall effect described here).
If these contributing actions are specified by means
of pre-/post-conditions, their overall effect is given
by the so-called relational composition of these con-
ditions: let C
a
1
,B
a
1
,C
a
2
,B
a
2
be the pre- and post-
conditions associated with actions a
1
,a
2
, referring to
the pre- and post-states of the properties x,y. Then,
the condition whether an action a
1
;a
2
may be invoked
is specified by the following pre-condition:
C
a
1
;a
2
≡ C
a
1
∧ ∃x
0
,y
0
: B
a
1
[x
0
/x,y
0
/y] ∧ C
a
2
[x
0
/x,y
0
/y]
For any predicate p, the notation p[x
0
/x] denotes
p with every free occurrence of x replaced by sym-
bol x
0
. Intuitively speaking, a
1
;a
2
can fire in any pre-
state satisfying the pre-condition of a
1
, and for which
at least one a
1
-post-state exists, such that the pre-
condition of a
2
holds, and, consequently, a
2
can be
executed. The corresponding post-condition for a
1
;a
2
is specified by
B
a
1
;a
2
≡ ∃x
0
,y
0
:
B
a
1
[x
0
/x,y
0
/y] ∧
C
a
2
[x
0
/x,y
0
/y] ∧ B
a
2
[x
0
/x@pre,y
0
/y@pre]
That is, there exists an intermediate state x
0
,y
0
which
is a post-state of a
1
and satisfies the pre-condition of
a
2
. Then, the post-condition of a
1
;a
2
coincides with
the one of a
2
, with the pre-states replaced by the post-
states x
0
,y
0
of a
1
.
Example 5. Suppose C
a
1
≡ x > 0, B
a
1
≡ y > 1/x ∧
x = x@pre, C
a
2
≡ y > 0, and B
a
2
≡ y = y@pre+ x ∧
x = x@pre. Then
C
a
1
;a
2
≡ x > 0 ∧ ∃x
0
,y
0
: y
0
> 1/x
0
∧ x
0
= x ∧ y
0
> 0
≡ x > 0
B
a
1
;a
2
≡ ∃x
0
,y
0
:
y
0
> 1/x
0
∧ x
0
= x@pre ∧
y
0
> 0 ∧ y = y
0
+ x ∧ x = x
0
≡ y > 1/x + x ∧ x = x@pre
Note that for this transformation, we assumed
that all actions were specified by means of pre- and
post-conditions. However, if this is not the case
(e.g. if an action is specified by means of explicit pro-
gramming statements), predicate transformers as de-
scribed in (Huang et al., 2013, Section 11.1.3) can be
used to determine the weakest pre-condition as well as
the strongest post-conditions from these statements.
Example 6. Suppose an action a
1
has been specified
in the C-programming style as follows:
y = 1/x;
y = y + 1;
Then, C
a
1
≡ x 6= 0 is the weakest pre-condition and
B
a
1
≡ y = 1/x + 1 ∧ x = x@pre the strongest post-
condition of a
1
.
Having represented the actions in terms of pre-
and post-conditions, we are now in the position to
translate a complete state machine transition. For the
start it is assumed that machine sm consists solely
of simple states – composite states are considered in
Section 4.3. A transition t from a state t.source can be
performed if (1) the state machine currently resides in
the source state t.source, and (2) the transition guard
t.guard is satisfied. The transition eventually leads
to a successor state t.target. During this transition,
the exit-action of t.source, the transition effect t.effect,
and the entry action of t.target are executed. The re-
sulting pre-condition is
C
o
sm
t
≡ state
sm
= t
sm
.source ∧ t
sm
.guard
For the post-condition, we assume that the state ma-
chines are well-defined in the sense that the pre-
conditions of all entry actions, exit actions, and transi-
tion effects involved are fulfilled if C
o
sm
t
holds. There-
fore we can specify the post-condition of the transi-
tion’s overall effect as
B
o
sm
t
≡ B
t
sm
.source.exit;t
sm
.effect;t
sm
.target.entry
∧
state
sm
= t
sm
.target
That is, executing the transition t
sm
has the effect of an
operation o
sm
t
whose post-condition is given by the re-
lational composition of the exit action from the source
state, the action directly associated with the transition
arrow, and the entry action of the target state. As a re-
sult, the state machine now resides in the target state.
Example 7. Fig. 2(a) shows a state machine com-
posed of two simple states s
1
, s
2
and two transitions.
Applying the translation described above leads to the
pre- and post-conditions shown in Fig. 2(b).
AUnifiedFormulationofBehavioralSemanticsforSysMLModels
267

smsm
exit/y = 1
s
0
exit/y = 1
s
0
entry/z = 6
s
1
entry/z = 6
s
1
[x = 1]/y = y + 1 (t1)
[z > 5]/z = z + 1 (t2)
(a) State machine sm.
C
o
sm
t
1
≡ state
sm
= s
sm
0
∧ x = 1
B
o
sm
t
1
≡ state
sm
= s
sm
1
∧ y = 2 ∧ z = 6
C
o
sm
t
2
≡ state
sm
= s
sm
1
∧ z > 5
B
o
sm
t
2
≡ state
sm
= s
sm
0
∧ z = z@pre + 1
(b) Resulting pre- and post-conditions.
Figure 2: Transformation of state machines.
4.3 Transformation of Composite States
We now introduce the transformation of single-region
composite states (Object Management Group, 2011a,
15.3.11). Their behavioral semantics has already been
described informally in Section 2; we will now con-
struct the pre- and post-conditions associated with
their outgoing transitions.
Pre-condition. Let t
sm
be a transition of state
machine sm. In the following pre-condition for-
mula, let S = subs(t
sm
.source) denote the proper
substates of the transition’s source state, and S
0
=
subs(t
sm
.source) ∪ {t
sm
.source} the set of substates
including t
sm
.source. With these abbreviations, the
pre-condition for a transition execution can be speci-
fied as follows.
C
o
sm
t
≡ state
sm
∈ S
0
∧t
sm
.guard ∧
∀s ∈ S,u ∈ s.outgoing : ¬u.guard
Consistent with the informal description of hierarchic
state machines in Section 2, this condition states that,
in order for t
sm
to be executed, (1) the innermost sim-
ple active state state
sm
must coincide with, or be a
proper substate of t
sm
.source, (2) the guard condi-
tion t
sm
.guard must evaluate to true, and (3) none of
the transitions emanating from lower-level states of
t
sm
.source (if any) must be enabled.
Post-condition. For specifying the post-condition,
the following recursive functions are used for calcu-
lating the innermost simple target state to be reached
by a transition, and for collecting the actions to be ex-
ecuted during a transition execution.
Function ρ
s
(t
sm
.target) calculates the target state
to be reached if t
sm
fires.
ρ
s
(s) ≡
(
s subs(s) = ∅
ρ
s
(sub(s).t.target) otherwise
Starting with the target state s = t
sm
.target of the tran-
sition, it is checked whether the state is simple. If
so, the simple innermost target state of the transition
execution has been reached. Otherwise the uniquely
defined post-state of the submachine’s pseudo initial
state is used in another recursion of ρ
s
.
Let lca = LCA(t
sm
.source,t
sm
.target) be the least
common ancestor of the transition’s source and tar-
get states. Function ρ
↑
(s
0
,lca,seq = ε) calculates the
sequence seq of exit actions to be performed when
leaving the innermost active simple source state s
0
as-
sociated with t
sm
.source and ending at the state under-
neath the least common ancestor of lca. The recursion
starts with the empty sequence seq = ε.
ρ
↑
(s,lca,seq = ε) =
(
seq if s = lca
ρ
↑
(parent(s),lca,(seq; s.exit))
otherwise
Let sseq denote the sequence of states in the state
configuration from lca’s substate down to t
sm
.target.
Function ρ
↓
(sseq,seq = ε) generates the sequence of
entry actions to be performed when traversing sseq
until t
sm
.target is reached.
ρ
↓
(useq,seq) =

seq if useq = ε
ρ
↓
(ut,(seq; s.entry)) if useq = s ◦ ut
Finally,
e
ρ
↓
(t
tm
.target,seq = ε) calculates the entry ac-
tions to be performed after having entered t
tm
.target
until the innermost simple target state of t
tm
’s execu-
tion has been reached.
e
ρ
↓
(s,seq) =





seq if subs(s) = ∅
e
ρ
↓
(sub(s).t.target, (seq; B))
otherwise, with
B = sub(s).t.effect;sub(s).t.target.entry
Using these auxiliary functions, the sequence of
actions accompanying the overall effect of t
sm
’s exe-
cution is
A(s
0
) = ρ
↑
(s
0
,lca,ε);t
sm
.effect;
ρ
↓
(sseq,ε);
e
ρ
↓
(t
tm
.target,ε)
provided that the simple active source state equal to
or sub-ordinate to t
sm
.source equals s
0
.
MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment
268

With these preliminaries the post-condition of the
overall effect is specified by
B
o
sm
t
≡ state
sm
= ρ
s
(t
sm
.target) ∧
_
s
0
∈S
0

s
0
= state
sm
@pre ∧ B
A(s
0
)

The new active state configuration has the simple state
calculated by ρ
s
(t
sm
.target). If s
0
is the uniquely
determined simple active pre-state asociated with
t
sm
.source, then the post condition derived from the
relational composition of the actions which are part
of A(s
0
) is the second conjunct of B
o
sm
t
.
Example 8. Fig. 3(a) shows a state machine includ-
ing one simple state s
0
and one composite state s
1
,
which, in turn, is composed of two simple states s
2
and
s
3
. Applying the translation described above leads to
the pre- and post-conditions shown in Fig. 3(b).
smsm
s
0
s
0
entry/x = 0
exit/x = 1
s
1
entry/x = 0
exit/x = 1
s
1
s
2
s
2
entry/z = z + 1
exit/y = z
s
3
entry/z = z + 1
exit/y = z
s
3
[x = 1]
[x = 0]
/z = 0
[v = 1] (t1)
[v = 0] (t2)
[r = 1]/r = 0 (t3)
(a) Given state machine sm.
C
o
sm
t1
≡ state
sm
= s
0
∧ v = 1
B
o
sm
t1
≡ state
sm
= s
2
∧ x = 0 ∧ z = 0
C
o
sm
t2
≡ state
sm
∈ {s
2
,s
3
} ∧ v = 0 ∧
(state
sm
= s
2
⇒ x 6= 1) ∧
(state
sm
= s
3
⇒ x 6= 0)
B
o
sm
t2
≡ state
sm
= s
0
∧

(state
sm
@pre = s
2
∧ x = 1) ∨
(state
sm
@pre = s
3
∧ y = z ∧ x = 1)

C
o
sm
t3
≡ state
sm
= s
3
∧ r = 1
B
o
sm
t3
≡ state
sm
= s
0
∧ y = z ∧ x = 1 ∧ r = 0
... ... ...
(b) Resulting pre- and post-conditions.
Figure 3: Transformation of composite states.
4.4 Do Activities
Do activities are activated when entering a new active
state configuration s
0
.s
1
... s
k
= sm with active sim-
ple state s
0
. They remain active until they terminate
or until the active configuration changes: if a tran-
sition results in exiting states s
0
... s
k− j
, j ≥ 0, while
s
k− j+1
... s
k
are also part of the new active configu-
ration, then the do activities specified for s
0
... s
k− j
are terminated, while the do activities specified for
s
k− j+1
... s
k
remain active.
The transformation rules specified in Section 4.3
implicitly cover do activities activated from simple
states and specified by means of submachines: their
behavior is identical to that of composite states (Ob-
ject Management Group, 2011a, p. 560). Note, how-
ever, that when several do activities defined in simple
states s
1
,.. . ,s
n
reference the same submachine sm,
the transformation described above will introduce n
copies of sm and add them as single regions to the
states s
1
,.. . ,s
n
, which automatically become com-
posite states.
4.5 Model Inputs
Inputs to the model are represented by operations
writing to one or more input properties only, with pre-
conditions ‘true’ and with post-conditions that only
require that the new value is in the legal range of the
variable type.
Example 9. Consider again the state machine from
Figure 3(a) and assume that v is an input to the model,
with type integer. The associated input operation is
specified by
C
v
≡ true
B
v
≡ v ∈ Integer
5 MODEL-TO-TEXT
TRANSFORMATION: THE
TRANSITION RELATION
In this section the generation of the transition relation
in propositional form Φ
M
is explained. It comes as
no surprise that more than one possibility for gener-
ating such a formula exists: different paradigms of
concurrency, time, and the atomicity of actions are
available. Each selection of paradigms leads to an-
other instance of Φ
M
. The UML has taken this vari-
ety of paradigms into account by introducing seman-
tic variation points in its language specification (Ob-
ject Management Group, 2011a); since the interpre-
tation of SysML state machines is identical to that of
AUnifiedFormulationofBehavioralSemanticsforSysMLModels
269

the “standard” state machines (so-called behavioral
state machines) defined by the UML, all the semantic
variations available there apply to SysML as well.
Let M be the model resulting from the transforma-
tion described in Section 4. Then M consists of block
diagrams only, and each block contains the operations
defined in the original model plus the new operations
generated during the model-to-model transformation.
5.1 Interleaving Semantics
Blocks in M created from different state machines
during the model-to-model transformation described
above execute concurrently. This is the most liberal
assumption; more restrictive ones can be enforced
in the original model by introducing synchronization
properties that are observed by the state machines in-
volved. Here we choose the interleaving semantics
paradigm, where only one block operation is executed
at a time. As a consequence, each operation execution
is automatically atomic, but the sequence of opera-
tion executions is nondeterministic: from any block,
any operation whose pre-condition evaluates to true
can fire. Racing conditions cannot occur, because si-
multaneous writes to the same property never happen,
but the resulting value of a property may be nonde-
terministic, due to different operation execution se-
quences. We interpret post-conditions in such a way
that all variable symbols not occurring in the post con-
dition or only occur with decoration ‘@pre’ remain
unchanged by the operation. Non-deterministic op-
erations that might change a property in an arbitrary
way will at least state that the changed property value
is still an element of the property type. By W (op) we
denote the set of variables that are written to accord-
ing to the post-condition B
op
. If we decorate every
free variable occurring in a pre-condition C
op
by an
‘@pre’ suffix, the resulting proposition is denoted by
C
op
@pre. By V (M) we denote the set of all property
symbols occurring in M. Let B(M) denote the blocks
associated with state machines and Op(b) the oper-
ations of block b implementing state machine tran-
sitions or model inputs. Auxiliary proposition S(H)
(“stable”) states that all variables from set H remain
unchanged during a transition:
S(H) =
^
v∈H
v = v@pre
With these preparations, the transition relation is writ-
ten as follows.
Φ
M
≡
_
b∈B(M)
_
op∈Op(b)

C
op
@pre ∧ B
op
∧ S(V (M) −W (op))

The transition relation is a disjunction over all blocks
representing state machines and all operations therein
that represent transitions. Every operation whose pre-
condition evaluates to true corresponds to a transition
that is enabled. The interleaving semantics triggers
any of these. Observe that at least one of the disjuncts
in Φ
M
always evaluates to true, since input operations
are always enabled.
5.2 Semantic Variations
Due to the usual space limitations, the detailed ex-
position of concurrency-related semantic variations is
not possible in this paper. The variety of model-to-
text transformations that have been constructed in our
group support synchronous semantics, dense and dis-
crete realtime mechanisms, and urgent or non-urgent
transition behavior. Note that the respective con-
straints need to be generated only once and, after-
wards, can simply be re-used.
6 PROOF OF CONCEPT
The two-step approach to specifying behavioral se-
mantics of SysML specifications has been applied in
the development and extension of a model-based test-
ing and bounded model checking tool developed by
Verified Systems International
4
and currently used in
industrial applications in the avionic, automotive, and
railway domains. In initial tool versions, the tran-
sition relation had been generated in one step, and
different generators had been created from scratch
for every supported description technique. The novel
two-step approach reduces the development time for
encoding the behavioral semantics of a new formal-
ism in a considerable way: our effort tracking esti-
mates indicate a reduction of development and verifi-
cation efforts by at least 40%. This is caused by the
fact that new formalisms usually only require a novel
model-to-model transformation, while the model-to-
text transformations dealing with concurrency aspects
can be re-used. Moreover, many verification objec-
tives to be analyzed for the complete transformation
can be verified on the level of block diagrams, blocks,
and operations, without having to debug the “low-
level” transition relation.
7 CONCLUSION
In this paper we have described a two-step approach
4
See www.verified.de.
MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment
270

for generating representations of behavioral SysML
model semantics that are suitable for applications in
model checking and model-based testing. The first
step consists in a model-to-model transformation, and
it aims at the equivalent representation of the source
formalism (e.g., state machines, sequence diagrams,
or activity charts) using block diagrams, blocks, and
their properties and operations only. The second
step consists in a model-to-text transformation, dur-
ing which the behavioral semantics of the intermedi-
ate model obtained in the first step is represented by
means of a transition relation.
Semantic variations concerning the interpretation
of the concrete description technique are handled as
variants of the first transformation, while semantic
variations concerning concurrency and realtime are
handled in the second transformation. We currently
explore the possibility to specify these semantic vari-
ations by means of constraint blocks encapsulated in
packages, so that the selection of concrete semantics
can be realized by means of package import in com-
bination with parametric diagrams enforcing the con-
straints associated with the selected semantic varia-
tion.
ACKNOWLEDGEMENTS
This work was supported by the Graduate School
SyDe (funded by the German Excellence Initiative
within the University of Bremens institutional strat-
egy), the European Union within the FP7 project
COMPASS under grant agreement no. 287829, the
German Federal Ministry of Education and Research
(BMBF) within the project SPECifIC under grant no.
01IW13001, and the German Research Foundation
(DFG) within the Reinhart Koselleck project under
grant no. DR 287/23-1 as well as a research project
under grant no. WI 3401/5-1.
REFERENCES
Beckert, B., H
¨
ahnle, R., and Schmitt, P. H. (2007). Verifica-
tion of Object-Oriented Software: The KeY Approach.
Springer-Verlag New York, Inc., Secaucus, NJ, USA.
Biere, A., Cimatti, A., Clarke, E. M., Strichman, O., and
Zhu, Y. (2003). Bounded model checking. Advances
in Computers, 58:117–148.
Brucker, A. D. and Wolff, B. (2006). The HOL-OCL book.
Technical Report 525, ETH Zurich.
Cabot, J., Claris
´
o, R., and Riera, D. (2008). Verification of
UML/OCL class diagrams using constraint program-
ming. In Int’l Conference on Software Testing Verifi-
cation and Validation Workshop, pages 73–80, Wash-
ington, DC, USA. IEEE Computer Society.
Gogolla, M., Kuhlmann, M., and Hamann, L. (2009). Con-
sistency, independence and consequences in UML and
OCL models. In Tests and Proofs, pages 90–104.
Hilken, C., Seiter, J., Wille, R., K
¨
uhne, U., and Drechsler,
R. (2014). Verifying Consistency between Activity
Diagrams and Their Corresponding OCL Contracts.
In Forum on Specification & Design Languages.
Huang, W., Peleska, J., and Schulze, U. (2013). Test
automation support. Technical Report D34.1,
COMPASS Comprehensive Modelling for Ad-
vanced Systems of Systems. Available under
http://www.compass-research.eu/deliverables.html.
Object Management Group (2010). OMG Systems Mod-
eling Language (OMG SysML
T M
). Technical report,
Object Management Group. OMG Document Num-
ber: formal/2010-06-02.
Object Management Group (2011a). OMG Unified Mod-
eling Language (OMG UML), superstructure, version
2.4.1. Technical report, OMG.
Object Management Group (2011b). UML Profile for
MARTE: Modeling and Analysis of Real-Time Em-
bedded Systems. Technical report, Object Manage-
ment Group. OMG Document Number: formal/2011-
06-02.
Object Management Group (2012). OMG Object Constraint
Language (OCL). Technical report, Object Manage-
ment Group. OMG Document Number: formal/2012-
01-01.
Peleska, J. (2013). Industrial-strength model-based testing
- state of the art and current challenges. In Petrenko,
A. K. and Schlingloff, H., editors, Proceedings Eighth
Workshop on Model-Based Testing, Rome, Italy, 17th
March 2013, volume 111 of Electronic Proceedings
in Theoretical Computer Science, pages 3–28. Open
Publishing Association.
Soeken, M., Wille, R., and Drechsler, R. (2011). Verify-
ing dynamic aspects of UML models. In Design, Au-
tomation and Test in Europe, pages 1077–1082. IEEE
Computer Society.
AUnifiedFormulationofBehavioralSemanticsforSysMLModels
271