October 2013
18
S
OFTWARE
D
EVELOPMENT
a pre-defined break point. The model unit
tests can be used similar to code unit tests to
validate the model continuously, and thus to
achieve an evolutionary development process.
To allow an analysis and an evaluation of the
MUT, all actions within the simulated model
are traced. The traced data is used to calculate
metrics for the simulation of the MUT. Typical
of the interesting information from this analysis
is e.g. when and how often an element (activity,
action, state) was applied and which parts of
the model remain inactive. A user-friendly
analysis of the model is supported by a graph-
ical visualization, e.g. by highlighting active
modeling elements and by using different
colors for reapplication. Thus, the model can
be checked continuously during simulation
and each violation of pre-defined model
constraints stops the simulation process
automatically. UML offers users complete free-
dom in modeling. Models can be defined in
an incomplete manner, with different levels of
granularity and in an informal (natural) lan-
guage. To be ready for simulation, models
must have a certain degree of formality and
completeness. A simulation tool shows some
similarity with the interpreter of a program-
ming language, e.g. VisualBasic, JavaScript,
Python etc. These programming languages
have to be consistent with a formal syntax to
be readable and they have to use a formal se-
mantic definition to be interpretable. It is the
same regarding the interpretation of models,
thus not all degrees of freedom of the concep-
tual modeling can be utilized. For the simula-
tion of models the syntax of the modeling lan-
guage must be readable for the simulation en-
gine. The correctness of the syntax is guaran-
teed by static tests, if not applied it will produce
an exception during simulation. To interpret
models they must have a clear formal semantic.
UML defines this by applying its formal meta-
model. However, there are certain semantic
variation points within the UML specification.
Thus, the interpretation of certain model ele-
ments must be defined during simulation.
UML ADs are used to describe processes, either
common workflows or detailed algorithms.
UML StMs are used to describe the states of
an object or a whole system. The more detailed
the model is defined, the easier the simulation
will run. That is why all information concerning
data producing and processing is integrated
in the model. This reduces the degrees of free-
dom of the modeling process even more and
means higher effort. If the models are used to
generate code at the end of the modeling
process, detailed models are welcome. But not
all models are used to generate code, thus the
model simulation engine allows simulating
abstract models in correlation with external li-
braries (or mock objects).
Figure 1 illustrates the correlation between
the abstract model and the external libraries
used for simulation. The more abstract the
conceptual model is, the more detailed the ex-
ternal libraries must be defined. To give an ex-
ample: the process to draw money out of a
cash point can be defined in three steps. Insert
card, choose amount of money, and take
money out. To simulate this process the simu-
lation engine has to detect whether the activity
insert card was performed correctly or not.
This information must be delivered by an ex-
ternal program (the mock object). The same
process may also be described in more detail,
e.g., by modeling the examination of the card
or the PIN. In most cases, a mock object will
be needed. To describe the process “draw
money out of a cash point” a PIN must be
physically entered or simulated. In the first
case the simulation is interactive (PIN entered
by the user), in the alternate case the simulation
is automated (the mock object simulates the
user and enters the PIN). Another mock object
would be requested to simulate the server of
the involved bank institution. With this exam-
ple we have shown that the complexity of the
system will be preserved. Using the divide-
and-conquer-principle the complexity may
only be divided between the mock object and
the model, thus making it manageable. The
author therefore proposes the “law of conser-
vation of complexity”, thus mock objects should
be constructed trivial.
To be able to work with this concept in an ef-
fective and cost-saving manner, mock objects
should be defined as generic, configurable and
easy to reuse libraries. Mock objects could be
used as a facade for whole external systems, to
generate input data and to require data for the
MUT. The modification of mock objects can
be seen as a degree of the dynamic of external
systems, e.g. delivered data will be picked up
from a certain area according to a pre-defined
distribution. In the process “draw money out
of a cash point” the mock object represents
the bank server reacting on the PIN to be
valid or invalid. The distribution could be e.g.
70% true and 30% false, thus simulating via
mock object, that 30% of PIN feed has failed.
Figure 2. Depending on the modeling domain, mock objects are trivial or filled with more logic.
Figure 3. Correlation between model, system, test data and the simulation
