3

VDMTools Lite

Aims
The aim of this chapter is to introduce VDMTools Lite, the development
environment for VDM-SL models. This is done by providing a “hands-on” tour
of the tool’s functionality using the alarm example introduced in Chapter 2.
This chapter should enable the reader to use VDMTools Lite for exercises in the
remaining part of this book.

3.1 Introduction
Models in VDM are formal in the sense that their semantics are very
precisely described. This formality makes it possible to analyse models in order
to confirm or refute claims about them. Such an analysis often reveals gaps in the
understanding of the system, allowing these to be resolved before an expensive
commitment is made to program code. The process of analysing claims about
systems modelled in this way is termed validation and is discussed in greater
depth in Chapter 10.
Software tools play an important role in supporting validation. This book is
accompanied by an educational version of the VDM-SL version of VDMTools,
called VDMTools Lite, that provides most of the functionality of the commercial
tool1 .
This chapter introduces VDMTools Lite as a preparation for the examples and
exercises of later chapters. It takes the form of a tour through the facilities for
performing syntax checking, type checking, integrity checking, testing and de-
bugging of models, using the alarm example which was presented in Chapter 2.
The reader is encouraged to use the VDMTools Lite or the full VDM-SL version
of VDMTools for all the exercises in this and subsequent chapters.
VDMTools Lite exists for several operating system platforms including Win-
dows, Linux and MacOS. In the remainder of this book, we assume that the
1
Some features of the full version have been removed in the Lite version. These are
the CORBA-based Application Programmer Interface; the Dynamic Link facility in the
interpreter; and the automatic C++ code generation feature.

35
36 3 VDMTools Lite

reader is using the Windows platform; users of other platforms may notice mi-
nor deviations from the user interface screens shown.

3.2 Installing VDMTools Lite

At http://www.vdmtools.jp/en it is possible to register and
subsequently download a setup.exe application which can be executed. This
will automatically install VDMTools Lite onto the hard-disk. The user must
choose the desired working directory during the installation. Files containing
the VDM-SL source for the examples and exercises used in this book are avail-
able from http://www.vdmbook.com. Copy these source files to a local
examples directory.

3.3 Configuring the alarm example

In order to start VDMTools Lite, select it from the All programs entry in
the Windows start menu. The main VDMTools window as shown in Figure 3.1
will appear. The menu bar at the top of the main window allows the user to
invoke the actions available on models. The graphical buttons in the toolbars just
below the top menu bar provide ready access to the most frequently used actions.
Below the toolbars, the main part of the window contains sub-windows that
communicate information about the model being analysed. When VDMTools
is started up for the first time, a manager sub-window and a log sub-window
appear as shown in Figure 3.1.
In VDMTools, models are structured in units called projects, each of which is
composed of one or more files containing VDM-SL source text. These source
files can be edited by any external text editor tool chosen by the user. VDMTools
offers a number of actions that can be performed on the project files. Particular
actions, such as the execution of a model using the interpreter tool, use spe-
cialised sub-windows that appear when the action is invoked.
In the remainder of this chapter, we will introduce areas of the VDMTools
functionality. As each area is introduced, we will show a reference table indi-
cating the relevant toolbar buttons. However, hovering the mouse cursor over a
button on the screen will bring up a message indicating the intended usage of
that button.
At the top of the main VDMTools window are six pull-down menus (labelled
“Project”, “File”, “Windows”, “Actions”, “Interpreter” and “Help”). When the
Project menu is selected it is possible to load and save the current project or to
change its configuration. The buttons listed in Table 3.1 are simply shortcuts to
 3.3 Configuring the alarm example 37

Figure 3.1 Startup window for VDMTools Lite

the items in the “Project” menu. However, the menu additionally contains an
entry for recently accessed projects that may be convenient on occasion.
Initially an empty project will be present, so we need to add selected files to
the project. Pressing the small icon with a “+” sign will cause a file browser
will appear. Since we are following the chemical plant alarm example, select
alarm.vdm. The file name alarm.vdm will appear in the Project part of the
Manager sub-window. VDMTools performs a syntax check on the file when
loading it, so now that the check is complete, it is possible to press the Module
tab in the Manager sub-window to see whether the loaded model is structured
into any special module units. The symbol DefaultMod is used to indicate that
the alarm example has been presented as a collection of definitions without any
use of modular structuring. Modules are primarily intended for structuring large
models with re-usable components and is reviewed in Chapter 12. Modular
structuring will not be used in the majority of examples in this book. This com-
pletes the project setup of VDMTools Lite to the alarm example file. It is now
possible to start analysing the definitions made in this model.
38 3 VDMTools Lite

Table 3.1 VDMTools project buttons

Button Explanation

Create a new project

Load an existing project

Save the current project

Save the current project under a new name

Add selected files to project

Remove selected files from project

Show and edit current project options

Select tool options

3.4 Syntax and type checking models

Returning to the Manager sub-window we will now consider the facil-
ities in VDMTools Lite that allow us to analyse the VDM-SL models in the
project that has just been created. Select alarm.vdm in the Project pane or
DefaultMod in the Module pane by clicking on it. Because syntax checking was
automatically carried out when the file was added to the project in the Modules
tab, a letter S shows that this file has been successfully syntax checked. This
means that the definitions presented in the alarm.vdm file follow the syntax
rules for VDM-SL.
After successful syntax checking it is possible to perform a type check on the
model, invoked through the Type Check button. If this button is pressed a T will
appear in the Module tab of the Manager sub-window. This indicates that the
model has been type checked without any errors (see Figure 3.2). This means
that, in addition to fulfilling the syntax rules of VDM-SL, the use of the different
operators etc. in the definitions has satisfied the scope and type rules provided
for VDM-SL. In our example, the file was both syntactically correct and type
correct right from the beginning. This is not surprising because this file has
been developed and analysed separately. However, most developers make errors
in early versions of models. It is therefore worth examining the facilities for
 3.4 Syntax and type checking models 39

Figure 3.2 Having both syntax and type checked alarm.vdm

Figure 3.3 Syntax errors in the error tool

reporting and correcting errors in VDMTools Lite. To illustrate this, a file called
alarmerr.vdm, containing deliberate mistakes, has also been supplied.
In order to examine this file we need to configure VDMTools Lite again. In
order to get rid of the definitions from alarm.vdm, select the file name in the
Project tab of the Manager sub-window and press the icon with the small minus
sign. Then alarmerr.vdm can be added instead using the icon with the small
plus sign. When this is done the alarmerr.vdm file will be parsed directly.
Since this version contains errors the Error List sub-window will pop up with
four error messages as shown in Figure 3.3. We can traverse through the errors
using the > and < buttons. The Source sub-window in Figure 3.4 will in-
dicate the precise location of the error indicated in the Error List sub-window.
In each case the syntax checker indicates what kind of construct was expected
and provides a qualified guess at how the error can be corrected. The suggested
corrections are often, but not always, correct. Note that the Source sub-window
is not an editor – the file should be modified with your preferred external edi-
40 3 VDMTools Lite

Figure 3.4 Source sub-window with indication of error

tor. In Section 3.8 we will see how it is possible to set up VDMTools Lite to
automatically invoke a favourite editor when required.
Exercise 3.1 Correct all the errors that have been discovered by the syntax
checker on the alarmerr.vdm file and syntax check your corrected file again
until no syntax errors appear. 

When no more syntax errors are present the model can be type-checked. This
model contains some type errors, as is indicated by the slash through the T in the
 3.4 Syntax and type checking models 41

Table 3.2 VDMTools action buttons

Button Explanation

Perform syntax check on selected classes

Perform type check on selected classes

Generate integrity properties for the selected classes

Generate C++ code for selected classes

Pretty print the selected classes

Table 3.3 VDMTools file buttons

Button Explanation

Open selected files in external editor

Close selected file from source sub-window

Close all files from source sub-window

Module tab of the Manager sub-window. In addition, the Error List sub-window
will appear again, this time containing type errors as shown in Figure 3.6. The
first one says: Error : Function is applied with wrong number of parameters.
This is because QualificationOK has been called with three parameters
instead of just two as indicated in its definition. The next error (Error : Un-
known identifier exss) is due to a typographical error which is easy to correct.
Altogether four errors and two warnings are reported. The type checker distin-
guishes between errors which are things that are definitely wrong and must be
corrected by the user, and warnings which are hints about things that could be
wrong.
Exercise 3.2 Correct all the errors that have been discovered by the type
checker on the alarmerr.vdm file and syntax and type check your corrected
file again until no syntax or type errors appear. 
42 3 VDMTools Lite

Figure 3.5 Tool options in VDMTools

3.5 Interpreting and debugging models

Syntax and type checking are static analyses, meaning that they are per-
formed without executing the model. VDMTools also supports dynamic anal-
ysis, allowing insight to be gained into the behaviour described by models by
testing them. We call this interpreting the models because they are not compiled
into a general-purpose assembly language as many programs are, but instead are
executed directly by an abstract machine (an interpreter). The VDMTools Lite
interpreter allows execution and debugging of models written in a subset of the
VDM-SL notation. To see this in action, take the third pull-down menu called
Windows and select the Interpreter item (or use the small debug icon button).
An overview of the window icons is provided in Table 3.4. When the interpreter
is selected, a sub-window like that shown in Figure 3.7 will appear.
 3.5 Interpreting and debugging models 43

Figure 3.6 Type errors in the Error List sub-window

To access the definitions that have been read into the current project, first press
the button that Initialises the interpreter (see Table 3.5) with all the definitions
from the current VDM-SL model. Whenever updates have been made to the
VDM-SL model, syntax checking the newest version does not update the inter-
preter’s internal representation. Thus, whenever the model has been modified, it
is necessary to press this initialisation button again.
The internal representation in the interpreter includes type definitions, func-
tions, as well as any value (constant) definitions and global state variables present
(we discuss state definitions in Chapter 11). The alarm example only has type
definitions and function definitions. Now that the interpreter has been initialised,
these definitions are all available for testing.
The top two panes of the interpreter sub-window are, respectively, the Re-
sponse and Dialogue panes. Commands are entered directly in the interpreter
in the Dialogue pane and output from the interpreter appears in the Response
pane. Commands are typed in the Dialogue pane and are submitted to the inter-
44 3 VDMTools Lite

Table 3.4 VDMTools sub-window buttons

Button Explanation

Allow user to view text

Close selected file from source sub-window

Show project log

Open the VDM++ interpreter sub-window

List all errors that occurred

Show integrity properties

preter by hitting the return key on the keyboard. Typing functions will get
a list of explicit functions which have been read into VDMTools. For the alarm
example we provided three explicit function definitions and one implicit func-
tion definition. However, the list provided here contains nine function names.
The extra ones have special prefixes (inv , pre and post ). These functions
are automatically generated “for free” from the definitions containing invari-
ants, pre-conditions and post-conditions. We will describe them in more detail
in Chapter 5. Any of these functions returned using the functions command
can be executed if arguments are provided for them.
The file testalarm.vdm contains some value definitions for the alarm ex-
ample. The schedule used in these definitions reflects the schedule presented
in Figure 2.1 on page 20. All components from this figure have been given
a name as a value definition in testalarm.vdm and below we will refer
to these names. In order to get access to these definitions, the file contain-
ing them must be included in the project in the same way that alarm.vdm
and alarmerr.vdm were. In adding this file, do not remove the corrected
alarmerr.vdm file from the project setup. The new testalarm.vdm file
can be added using the small + icon button again (see Table 3.1). Then this file
can be syntax checked and type checked and we can reinitialise the interpreter
by pressing the Init button again (i.e. the flag icon in Table 3.5). In this way we
also get access to the value definitions provided by testalarm.vdm. In the
dialog part of the interpreter sub-window we can type values to see the list of
value definitions which are available.
 3.5 Interpreting and debugging models 45

Figure 3.7 Start up sub-window for the VDM-SL Interpreter

RESPONSE PANE

DIALOG PANE

CALL STACK PANE

BREAKPOINTS PANE

As an example of the use of the VDMTools interpreter, type the print

NumberOfExperts(p1,plant) command in the Dialog part of the inter-
preter sub-window and press return. In this command, the name plant stands
for the mapping representing the plant as shown in Figure 2.1, and p1 corre-
sponds to the period “Monday day.” The interpreter responds by printing 3,
indicating that three experts are on duty in period p1.
Exercise 3.3 Use the interpreter to evaluate the following expressions:
NumberOfExperts(p2,plant)
NumberOfExperts(p3,plant)
ExpertIsOnDuty(e1,plant)
ExpertIsOnDuty(e2,plant)
ExpertIsOnDuty(e3,plant)

Sometimes it is not clear why a function is returning a particular result when

applied with some input values. In such cases it is valuable to be able to debug
46 3 VDMTools Lite

Table 3.5 VDMTools window buttons

Button Used Explanation

Yes Initialise the interpreter

Yes Perform a step

No Step inside

No Perform a single step

No Continue the execution

No Stop the interpreter

No Jump to where the current function or operation was called

No Jump to where the current subfunction was called

No Finish the execution

the model by setting up break points. A break point is a point in the model
at which we wish the execution to be interrupted during interpretation. Set
up a break point by typing break NumberOfExperts. The consequence
of this break point is that the name DefaultMod’NumberOfExperts ap-
pears in the Break Points part of the interpreter sub-window. Type debug
NumberOfExperts(p3,plant) in the Dialogue pane and press return. The
Source sub-window will pop up and show where the execution has been stopped,
as shown in Figure 3.82 . Press Single Step a few times to see how the body of
the function is evaluated step by step. While debugging an expression, subex-
pressions can be evaluated by using the print command in the Dialog part of
the interpreter sub-window. When execution does not deliver the expected re-
sults, break points provide a useful aid to debugging models at the expression
level.
During debugging the stack trace of functions called is displayed in the Trace
2
The only difference between print and debug is that debug will stop when a break
point is reached whereas print will ignore break points.
 3.5 Interpreting and debugging models 47

Figure 3.8 Debugging the VDM model

part of the interpreter sub-window (see Figure 3.7). The arguments to a function
are initially compressed into an ellipsis (three dots). An ellipsis can be unfolded
by clicking the left mouse button with the cursor on top of the dots; the value
can be folded back by pressing the left mouse button again. Press the Continue
button (the green arrow pointing forward) to end debugging. The interpreter will
continue either until the next break point is encountered or until the execution is
finished.
Notice that ExpertToPage did not appear in the list of functions returned
by the functions command. This is because it is an implicit function and
such functions cannot be executed directly3 . However, it is possible to execute

3
The only other kind of construct that cannot be executed by the interpreter is a type
binding which we will illustrate in the next chapter.
48 3 VDMTools Lite

Figure 3.9 Test coverage information

pre-conditions and post-conditions of implicit functions. These functions return

Boolean values as described by the logical expressions inside the pre- and post-
conditions. We discuss them in more detail in Sections 5.8.3 and 6.4.3.

3.6 Test coverage

It is often useful to know how much of a model has been exercised
by a set of tests. This gives some insight into the thoroughness of a test suite
and may also help to identify parts of the model that have not been assessed,
allowing new tests to be devised to cover these. VDMTools has a facility to
support this kind code coverage, similar to the tools that already exist for many
programming languages. In VDMTools Lite, special commands can be used in
the Dialog part of the interpreter sub-window. There is a command called tcov
that can be used with arguments to reset the coverage information, to read and
write the coverage information to a file. The rtinfo command takes such a
coverage file for the VDM model in question and presents information about
the percentage of coverage for each function, as well as data on the number of
 3.7 Integrity checking 49

times each function is called. Figure 3.9 illustrates how this can be done with the
alarm example. Even more detailed information at subexpression level can be
shown if the VDM model is pretty-printed but this requires special commands
depending upon the format used for the VDM model. In order to see how this is
done, refer to the user manual for VDMTools [UserMan].

3.7 Integrity checking

Another way to increase confidence in the internal consistency of a
VDM-SL model is to use the integrity examiner from VDMTools. This extends
the static checking capabilities of the VDMTools by scanning through VDM-SL
models for potential sources of internal inconsistencies or integrity violations.
The checks include the violation of data type invariants, pre-conditions, post-
conditions, sequence bounds and map domains. Each integrity property is pre-
sented as a VDM-SL expression that should evaluate to true – if it evaluates to
false instead, this indicates that there is a potential problem with the correspond-
ing part of the VDM-SL model. The only fully general technique for ensuring
that integrity properties are satisfied is formal proof. Proof is beyond the scope
of this book, but the underlying principles are explained in Chapter 10.
Pressing the integrity checking button (see Table 3.2) when the alarm.vdm
file is selected will bring up an Integrity properties sub-window (see Figure 3.10).
The Integrity properties sub-window is divided into three areas. The area at
the top lists the integrity properties currently in view in the Source sub-window.
Initially this will show all the integrity properties for the modules that have been
checked (here we only have a default module). To the left of the list are four
buttons. The first two are for scrolling through the list. The third marks the
currently highlighted property as having been checked manually. The fourth
button activates a filter that can be used to limit the view to certain kinds of
integrity property. The second pane of the integrity properties sub-window is
used to define the filtering criteria. The bottom pane of the integrity properties
sub-window shows the currently selected property. This property should hold at
the given position in the source sub-window.
Integrity checking can be valuable in the late stages of a model’s development.
Checking each property can help to identify potential run-time errors. The use
of this feature will be taken up again in Chapter 10.
Figure 3.10 shows one of the integrity properties generated for the alarm ex-
ample. The specific property is generated by the mapping application to be
found in the body of the ExpertToPage function. Mapping applications can
50 3 VDMTools Lite

be undefined if the value being applied to the mapping is not in the domain of
the mapping itself (this is equivalent to a run-time error). The integrity property
states that, in the context where it occurs in the body of the ExpertToPage
function, the period must be in the domain of the schedule mapping. This
requirement is stated as a logical expression:
forall a : Alarm, peri : Period, plant : Plant &
peri in set dom (plant.schedule) and
a in set plant.alarms =>
(forall r : Expert &
peri in set dom (plant.schedule))

This requires that, for all combinations of alarms, periods and plants, the period
must be in the domain of the plant’s schedule. This property is already guaran-
teed by the pre-condition, so the integrity property is trivially satisfied. If we
had omitted the requirement from the pre-condition, we would have discovered
the mistake by examining the integrity property in this way.

3.8 Setting options

We have already seen that invariants, pre-conditions and post-conditions
give rise to automatically generated Boolean functions that can be called during
the analysis of models. In addition, the tools support optional run-time (dy-

Figure 3.10 Integrity properties for the Alarm example

 3.8 Setting options 51

Figure 3.11 The interpreter options

namic) checking of invariants, pre-conditions and post-conditions. The relevant

options are set using the Project Options entry in the Project pull-down menu.
This brings up the project options sub-window (Figure 3.11), allowing the rele-
vant options to be selected. Clicking OK causes the options to be saved.
As an exercise, make sure pre-condition checking is switched on. Now se-
lect the Interpreter item under the Tools menu. Go to the dialogue pane and
type “print NumberOfExperts(p5,plant)”. The response is “Run-
Time Error 58: The pre-condition evaluated to false”. This indicates that the
call of the function NumberOfExperts has violated the pre-condition from
its definition. In this case a violation has occurred because p5 is not incor-
porated in the domain of the schedule from plant. Such dynamic checks of
properties provide an additional way of gaining confidence in a model as it is
developed.
The Project pull-down menu also contains a Tool Options entry. This allows
the user to select a preferred editor. If this has been done it is possible to click
the editor icons present over the files in the Manager sub-window of the main
VDMTools window to automatically start up the editor with the correct file. This
52 3 VDMTools Lite

is particularly convenient if one is using Microsoft Word as the main editor, in

which case the VDM-SL source file needs to be in rich text format (rtf). This
is possible using special macros: more information about the choice of differ-
ent formats is provided in the VDMTools user manual [UserMan]. Throughout
this book, and in the example files available on-line, we use the ASCII syn-
tax, so these files may be processed by any ASCII editor such as Crimson
or Emacs. For both of these editors, it is possible to install setups specif-
ically for VDM source editing (available from the www.vdmportal.com
web pages).

Summary
We have introduced the following features of VDMTools Lite:
• project setup of selected VDM-SL files;
• syntax checking of VDM-SL models;
• type checking of VDM-SL models;
• error reporting;
• executing and debugging VDM-SL models;
• checking the integrity of VDM-SL models; and
• setting options for projects and different actions.
Exercise 3.4 Imagine an extension to the alarm example which would en-
able experts to swap duties. This function is called ChangeExpert. Given a
plant, two experts and a period it will yield a new plant where the plan has been
changed so that the first expert will be replaced by the second expert in the given
period. A first version of this function could be formulated as
ChangeExpert: Plant * Expert * Expert * Period -> Plant
ChangeExpert(mk_Plant(plan,alarms),ex1,ex2,peri) ==
mk_Plant(plan ++ {peri |-> plan(peri)\{ex1} union {ex2}},
alarms)

where the \ symbol removes the ex1 value from the schedule for the given
period peri and union adds the ex2 value.
Do you see any problems with this function? This definition is placed in the
file changeexpert.vdm so you should configure your project once again by
adding this file. When it has been syntax checked and type checked (the latter
is not strictly required) the interpreter can be initialised again. Now use the
interpreter to inspect the plant value returned from calls such as
ChangeExpert(plant,e4,e7,p3)
ChangeExpert(plant,e3,e7,p3)
 3.8 Setting options 53

Will the invariant on the Plant data type be violated? Test this by setting the
option for invariant checking. If the invariant is broken it is possible to make
a break point for the invariant inv Plant itself and call that with a Plant
value which possibly satisfies the invariant. By single stepping inside this it
becomes easier to discover how the invariant is broken. If necessary, add the
pre-condition needed to complete the function.