Information Technology Reference
In-Depth Information
ensuring the scientific validity of the conclusions. To evaluate the use of the tool, we
have used it to build a suite of benchmarks and compared the performance of JavaMop
[7] and polyLarva [2] under di
ff
erent mocked scenarios.
2
The Architecture and Design of SMock
SMock has been built in such a manner so as to enable the easy generation of families
of transaction systems with two levels of configurability: (
i
) the form of the underlying
transactions (possibly including variations); and (
ii
) the scenarios depicting transaction
firing as distributed over time. To enable us to achieve this goal, SMock takes a script
describing these options and generates a Java mock system behaving in the prescribed
manner, generating events which can be captured by monitoring tools. Such a system
is then typically monitored using a specification script in a runtime monitoring tool,
enabling the measurement of overheads induced by the monitors in such a setting. Since
the mock system may include parts which are randomly generated (e.g., launch between
100 and 120 transactions in the first 10 seconds), its execution also tracks information
to allow exact replayability. This enables, for instance, comparison of the performance
of the di
ff
erent versions of a runtime verification tool, or its performance against that
of other tools, or as a regression test following a bug fix. The general usage pattern of
SMock is shown below:
3
Scripting Behaviours
One of the strengths of SMock is that it allows users to script scenarios to be used
for testing. The scripts are written in a small domain-specific language which provides
a number of constructors to enable the description of processes and how they are to
be launched. Basic processes are individual actions which are characterised by three
parameters — their duration, memory consumption and CPU usage. These parameters
can be exact values or probability distributions
3
, to enable the mock system to behave
within a range of possible behaviours. Actions can be named if one would want to be
able to monitor their moment of entry and exit, but can also be left unnamed.
Processes can be combined using the following operators: (
i
) sequential composition;
(
ii
) probability weighted choice between processes; and (
iii
) parallel composition of
processes. The combinators come in a binary form and also generalised versions which
allow the combination of multiple processes together.
3
The tool currently supports uniform and normal distributions.
