S
OFTWARE
D
EVELOPMENT
Such a mock object is trivial and implies only
less implementing logic, thus fulfilling its pur-
pose to deliver data for the MUT. After multiple
repetitions the mock object reacts differently
to the MUT by checking the dynamic behavior
of the MUT. This is most interesting if multiple
mock objects are used for data delivery.
As mentioned already, mock objects are used
as facade to simulate external behavior. That
means to react on data and signals and to de-
liver input data or signals for these purposes.
In an easy-use case, mock objects can be as
trivial as delivering pre-defined data (e.g. true
and false) according to a pre-defined distribu-
tion. But they can also do more complex cal-
culations for the data/signal coming from the
MUT. Depending on the modeling domain
mock objects are trivial or filled with more
logic (figure 2). However, the user has to con-
sider that mock objects are software systems
and they have to be tested to avoid logic
failures in their behavior. If the mock object
does not behave like the real system, this might
result in an inaccurate system despite the valid
simulation of the MUT (figure 2).
Whole applications may also be used as mock
objects. If so, the whole executable implemen-
tation of an application is used. The MUT in-
teracts with this application and simulates the
system in development. If this application has
no own API, a so-named wrapper API must
be applied to enable the MUT to address the
functions of the application (figure 2, external
libraries, in the middle). The system engineer
may also use external systems as mock objects.
The benefit of this approach is to involve ex-
ternal hardware directly, meaning that the de-
signed models can be used to exchange data/sig-
nals with external systems. If the external
system has no built-in control logic, the model
can be used to simulate the behavior of the
control logic. Thus external hardware can be
addressed and controlled without major pro-
gramming efforts. Only an interface for the
external system is needed (figure 2, external li-
braries, below). Thereby the results of the sim-
ulated model are visible in the external system,
but the logic is simulated in the model and
can be changed easily. This setting allows for
applying all model-based tests.
Attention should be given to time-critical con-
trols, because the simulation of the model is far
away from the performance of a hardware-
based logic. This might result in synchronization
problems in the interaction of the simulation
and the real system. To make time-critical con-
ceptual models capable of simulation, the sim-
ulation time can be normalized through fake
retardation. Thus the shortest critical time span
can be stretched to a time span capable of sim-
ulation in the model, all other time spans adapt
relatively to this stretching. With this, the prob-
lem of time-critical interaction with real systems
is not solved; it only allows simulating the
logical behavior of time-critical models.
In non-time-critical systems the simulation
time has a minor role and might be neglected.
For the visual study of model changes, a high-
performance simulation is not suitable and
must be slowed down. To be able to debug a
simulation, break points have to be set where
the simulation stops automatically and can be
conducted step-by-step. Due to tracing pur-
poses, jumping back in the simulation process
is possible; either step-by-step or directly to a
break point. Finally, the author would like to
point out, that the model simulation engine
can not only be used for the test of the model.
The execution of models can also be used to
guide an external system. Thus the model plays
the role of code, and the model simulation en-
gine plays the role of the interpreter of the lan-
guage or of the controller of an application.
Tests based on models are not a new topic.
There are some concepts and tools that allow
for executing and simulating conceptual mod-
els. The flexibility of a model simulation engine
for graphical models with its interfaces to ex-
ternal libraries is most interesting. This concept
enables the system engineer to simulate models
of any abstraction level while using mock ob-
jects. Model unit tests may be realized with de-
termined input data and the resulting output
data, ensuring consistency in models that are
in an ongoing development process. Models
may evolve continually by tracing the simula-
tion steps and by reviewing the model restric-
tions, even if there is no determined input
and output data. Figure 3 shows the correlation
between model, system, test data und the sim-
ulation. The model includes all pre-defined
requirements; the system is based on the model
and implements all requirements as well. Test
data is detected based on requirements and re-
strictions in the model. The simulation uses
test data and the model to validate it.
All mock objects correlate to the external sys-
tems they represent. Hence, the system engineer
receives a verified conceptual model after fin-
ishing the test (simulation). The real system
should behave like the simulated model, with
the mentioned restrictions for real-time systems.
The test data of the simulation process may
also be reused for the test of the real system.
Thus, the development of executable models is
similar to early prototyping. Conceptual (logi-
cal) mistakes in the system may be pinpointed
and eliminated during the development of the
model. Depending on quality and effort put
into mock objects, one may also detect plat-
form-specific problems at an early stage.
