Information Technology Reference
In-Depth Information
Example 1.
Consider a document management system which allows users to login,
browse, upload documents, edit these documents, etc. The resources used by some of
these actions can be characterised as follows:
df
=
login
action
duration
=
uniform(3
,
5)
,
memory
=
normal(20
,
40)
,
cpu
=
0
.
1
df
=
browse
action
duration
=
normal(5
,
8)
,
memory
=
300
,
cpu
=
normal(0
.
5
,
0
.
7)
df
=
logout
action
duration
=
normal(1
,
3)
,
memory
=
normal(20
,
40)
,
cpu
=
0
.
1
One can now generate 300 users acting in one of two possible ways — browsing or
editing a number of files:
df
=
usertype1
login; browse; logout
df
=
usertype2
login;
seq foreach document
do
open; edit; save; edit; close;
logout
∈{
1
...
3
}
df
=
system
par foreach user
∈{
1
...
300
}
do
choice
0
.
9
→
usertype
1
0
.
1
→
usertype
2
In practice, for a more realistic scenario, we would not want the user transactions
to be launched all together at a single point in time, so we would add an (unnamed)
action preceding each user transaction, which takes some time to terminate, but does
not consume CPU or memory resources.
As seen in the above simple example, when writing a script, one would usually want
to be able to define and reuse transactions, requiring further (non-functional) constructs
in the language. Similarly, one may want to add compile-time computations which cal-
culate constants to be used in the rest of the script (e.g., memory usage of a class of
actions could be automatically calculated as a function of CPU usage and duration). To
avoid having to extend the language with such constructs, we have chosen to build the
scripting language as an embedded language [6] in Python. This allowed us to avoid
having to build a parser and type-checker for the language, and also allows the user to
use Python for function definitions and computation.
4
An Application of SMock
SMock supports the generation of mock systems written in the Java language. As a case
study SMock has been used to generate a mock document management system — an
extension of the example given in Section 3.
In this case study, the generated system was used in conjunction with existing run-
time verification tools in order to analyse the e
ects these tools have on the overall
performance of concurrent systems, of which the document management system is an
example. Two runtime verification tools, JavaMop [7] and polyLarva [2] were used in
this case study. In both instances a sample property:
an edited document must always
be saved before closing
, has been monitored.
ff
