METHODS: The VDM ++ Approach

This paper describes methods integration techniques and tools developed for the VDM formal specification language. Case studies which have been carried out for the language using tool support for the integrated development method are also described. The original features of the method are its use of highly abstract initial specifications to avoid the design bias of object-oriented structuring, and the formal treatment of structural transformations.


Introduction
Object-oriented specification languages are an area of significant potential within software engineering, and aim to combine the benefits of precise mathematical notations with the advantages of object-oriented structuring mechanisms.
Languages in this field include Object-Z [6], ZEST [4], VDM ++ [7], Z ++ [16] and MooZ [23]. In a separate line of development are object-oriented analysis and design methods which incorporate some elements of formality. Fusion [2] and Syntropy [3] are the two main methods of this form.
Object-orientation and formal techniques are highly compatible in a number of ways: object-orientation encourages the creation of abstractions, and formal techniques provide the means to precisely describe such abstractions; object-orientation provides the structuring mechanisms and development disciplines needed to scale up formal techniques to large systems; formal techniques allow a precise meaning to be given to complex object-oriented mechanisms such as aggregation or statecharts.
There are two alternative ways of integrating diagrammatic and formal methods which have been proposed and used in practice by groups and companies working in this area: covert formality, in which mathematical notation and an explicitly formal specification language may be avoided, but with a mathematical semantics being provided for structured English or diagrammatic specification forms; overt formality, involving translation processes from a diagrammatic notation into a formal notation, and sometimes in the reverse direction as well, and the use of development steps within the formal specification and design language.
The Fusion method of Hewlett-Packard epitomises the former approach, whilst the VDM ++ method described in this paper adopts the latter.
Methods Integration Workshop, 1996 2. Translation of object models into initial VDM ++ class specifications (this step is automated by the Venus toolset for the language). The initial (Model 0 ) specification can consist of a single class which describes the required operations with no assumptions about the classes that will exist in the design or the decompositions of operations into method calls; 3. Identification of VDM ++ classes and their dynamic behaviour specifications and method definitions. This step involves localisation of system operations into a collection of methods located in particular classes -a Model 1 specification; 4. Refinement and design in VDM ++ . This step uses both conventional VDM-SL data refinement concepts and new concepts such as annealing -refining one class by a collaborating collection of several classes. It yields a series of models related by refinement; 5. Code generation in C++ or other OO programming languages. At present a C++ code generator exists [29], and an Ada95 generator is under development. Code generation can either be used to support animation via an executable prototype at the specification stage, or to produce production quality code from specifications which have been refined into a fully procedural form.
Internal consistency proof obligations can be generated and checked at specification and refinement stages, to ensure that formal classes actually have models and can be implemented. A description of these conditions is given in [15]. Proof obligations for subtyping and for refinement steps can also be generated, based on those for conventional VDM-SL refinement. These obligations ensure that a development step does represent progress towards an executable implementation. They are described in [15]. Diagrammatically, the process and tool-supported actions are as shown in Figure 1.
As with Fusion and Syntropy, IFDM emphasises the need to separate models of real-world situations from models of the required software. It extends these methods with the capability to define mathematical relationships between such models.
The key aspect of VDM ++ is that it allows all the separate requirements upon an entity to be combined in a single textual class description. Thus the static data requirements, described in OMT object models, yield a specification of the data elements of a VDM ++ class, whilst the timing and state-transition behavior requirements, described in timed statecharts, yield definitions of the synchronisation and thread parts of a VDM ++ class. Operation (functional) models of OMT, and object interaction graphs, which express processing requirements and initial designs, can be used to define methods and threads of a class. This integration of the separate aspects of an entity is a natural step towards implementation in a programming language (such as Ada) where these aspects are combined in the description of single modules. It also enhances the capability for consistency checking between these aspects. This paper will consider the formalisation of the object model and dynamic models of OMT. Formalisation of object interaction diagrams is covered in [18].

Tool Architecture
The Venus toolset combines an established CASE tool for OMT, LOV, produced by Verilog, with a toolset for VDM ++ notation. The latter, known as VPP, has been developed by IFAD and is based on their established VDM-SL toolset. The two tools are linked by a coupling module which provides translations between the different internal representations used by the tools. The level of integration is quite high, in that the translation process covers most of the OMT object model notation and the VDM ++ notations, but is not complete, because of the use of two different representations. Both tools use a Motif or Motif-like interface, and provide similar ways of working, so that it is not difficult to combine their use.
Constructs in VDM ++ which have no counterpart in OMT (such as the detailed definitions of methods) are translated into special purpose "notes" in the LOV representations. This permits them to be viewed and edited via the LOV tool and to be translated back into the appropriate VDM ++ constructs. Certain constructs in OMT have no counterpart in VDM ++ , and are not translated. For instance, the distinction between inclusive and exclusive subtyping is not made in VDM ++ . In addition, only the strongest form of aggregation (bound, unreplaceable, unsharable containment) is represented in VDM ++ [15].

VDM ++ : Syntax and Semantics
VDM ++ is a concurrent object-oriented extension of the VDM specification language [8,7]. The aim of defining the language was to use the concepts of object-orientation to provide structuring facilities for VDM specifications. In addition it was intended to extend the capabilities of VDM to a wider range of systems, including concurrent, reactive and real-time systems. VDM ++ is one of the most advanced of the present generation of object-oriented formal languages [14].
VDM ++ has been adopted by a major European software firm, CAP, and has also been industrially trialed in the AFRODITE ESPRIT project. Industrial case studies of the language include a minimum safe altitude warning component for an air traffic control system, ship load planning and monitoring, and elements of the next generation of particle detector devices at CERN.
Applications of the language have made essential use of the extended capabilities of VDM ++ . In particular, the CERN case study has extremely stringent timing requirements, whilst the use of inheritance and subtyping in the air traffic control system was believed to have improved the ability to validate the system [17].

end C
A class is a generalisation of the VDM module concept (eg, as implemented in the IFAD VDM toolbox). It uses methods in place of operations, and method invocation in place of "quoting" operation pre and post conditions. As such, it has a more systematic basis for its structuring mechanisms, and one that is more familiar to industrial practitioners.
The types, values and functions components define types, constants and functions as in conventional VDM (although class reference sets @D for class names D can be used as types in these items -such classes D are termed suppliers to C, as are instances of these classes. C is then a client of D). The instance variables component defines the attributes of the class, and the inv defines an invariant over a list of these variables: objectstate is used to include all the attributes. The init statement defines a set of initial states in which an object of the class may be at object creation.
Object creation is achieved via an invocation of the operation C!new, which returns a reference to a new object of type C as its result.
The methods of C are listed in the methods clause. The list of method names of C, including inherited methods, will be referred to as methods(C) in the following. The subset of methods(C) which may be used by external clients of C is extmethods(C), whilst the subset that can be only used internally is intmethods(C). The union of extmethods(C) and intmethods(C) is methods(C). Internal methods arise as a result of inheritance steps (controlled inheritance) that remove ancestor methods from the external interface of the descendent.
Methods can be defined in an abstract declarative way, using specification statements, or by using a hybrid of specification statements, method calls and procedural code. Input parameters are indicated within the brackets of the method header, and results after a value keyword. Preconditions of a method are given in the pre clause. The form of a specification statement is: [ext wr write frame rd read frame pre precondition post postcondition] In the postcondition the value of an attribute att at initiation of execution of the specification statement is denoted by (

att.
Other clauses of a class definition control how C inherits from other classes: the optional is subclass of clause in the class header lists classes which are being extended by the present class -that is, all their methods become exportable facilities of C. An inherits clause in C lists classes which are being included via controlled inheritance: whereby some inherited methods are made internal to C.
Dynamic behaviour of objects of C is specified in the sync and thread clauses, which must not conflict. In the sync clause, which describes the behaviour of passive objects, either an explicit history of an object can be given, as a trace expression involving regular expressions in terms of method names, or as a set of permission statements of the form: per Method ) Cond restricting the conditions under which methods can initiate execution. Threads describe the behaviour of active objects, and can involve general statements, including a select statement construct allowing execution paths to be chosen on the basis of which messages are received first by the object, similar to the select of Ada or ALT of OCCAM. A typical thread using a select statement is: thread while true do sel x 10 answer m1 ! a!m(x 10); x 10 answer m2 ! a!m(x); x = 10 ! self!m3() An object whose behaviour is specified by this thread waits for the first request of m1 or m2 to be recieved, unless x = 1 0 , when it may directly proceed to execute the m3 method on itself, provided there are no outstanding requests for m1 or m2. If x > 10 then it must wait for a request for m1, and will then execute a!m(x 10) on the supplier object a. If x < 10 then it must wait for a request for m2, and will then execute a!m(x) on the supplier object a.
Having completed the execution of the statement associated with the select clause, the thread of control will return to the loop and this behaviour will be repeated until the object is destroyed. A set of internal consistency requirements are associated with a class, which assert that its state space is non-empty, and that the definition of each method maintains the invariant of the class, and that the initialisation establishes the invariant. The syntax of traces and threads is given in [8].
The aux reasoning section can contain additional logical specifications, for example, of temporal relationships. Examples are given in the following sections. The method definition of move asserts that the value of error at termination of move is either 0, and that in this case the values of partition and lestore are set to the input values yin and xin respectively, or it is 1, and the values of partition and lestore are non-deterministically set to elements of N.
The sync constraint indicates that a move invocation can only begin execution if at least one set owner invocation has already completed. (#n(m) counts the number of terminations of m to date.) This is distinct from the concept of a precondition of an operation, which only indicates under what conditions the postconditionof the operation can be assumed at its termination.

Semantics
There are two levels of semantics for VDM ++ [13]: the object-oriented extension of VDM-SL can be described in a modal action logic extending the logic of partial functions (LPF) that underlies VDM-SL. The real-time and concurrent aspects require a further extension, to an RTL-based formalism [16] which uses concepts of events and event times to define the meaning of the duration and delay constraints that can be asserted in VDM ++ .
An example axiom, describing the state-transformation effect of a method on the local state of an object, is: The axiom asserts that the values v C~# (m; i) of the object attributes at the time #(m; i) that the i-th invocation of m terminates, and the values v C~" (m; i) of the object attributes at initiation of the invocation, are related by the postcondition at termination, provided that the object exists at initiation: self 2 C and the method precondition holds then.
The theory of a class C is then a collection of axioms in a language L C in extended RTL. Subtyping between classes is defined in terms of theory extension of these theories: Class C is a supertype of class D via a retrieve function R : T D ! T C between the respective states, and a renaming of methods of C to those of D, if, for every ' must map internal methods of C to internal methods of D, and external methods to external methods. The notation C v ;R D is used to denote this relation.
D is a refinement of C if it is a subtype of C and the retrieve function R satisfies the condition of adequacy: That is, R is onto. In addition, no new external methods can be introduced in D, so that is onto when restricted to extmethods(C).
Problems arise from the interaction of subtyping and frame rules such as the locality principle: that the state of an object can only change during the execution of an invocation of a method of its class. Alternatives to this principle are discussed in [20].

Formalisation of Analysis Models
The OMT notation of [27] will be used here, with the dynamic models being extended to the full timed statechart language of [11].

Formalisation of Object Models
The static data model of OMT, called the Object Model, specifies classes together with their attributes and operation signatures, and associations or relationships between classes. Inheritance and aggregation can be specified in addition.
The formalisation process for the object model is largely a mechanical process. In order to generate the Model 0 specification a single VDM ++ class for the complete data model is produced, in which the entities E of the object model are expressed using sets EID of tokens for object identities, and attributes and associations are expressed as maps based on these sets. If we know that only a fixed set of objects are needed, then we can represent their data in a static manner as a set of variables, without the need to introduce a type of identities for these objects (the traffic-light system of Section 5 is an example of this case).
Production of the Model 1 specification consists of defining VDM ++ classes C for each entity C in the object model, with attributes as specified in the object model (with VDM ++ types being used). Associations from C become attributes in C of type @D, F(@D) or seq(@D), depending on the cardinality of the association with respect to the entity D at the other end. It may not be necessary to formalise both directions of every association: the Venus toolset provides configuration facilities which let the user identify which parts of an association or object model they wish to be formalised for a particular application.
Inheritance is represented by is subclass of clauses. Aggregation with a fixed multiplicity is represented by indexed inheritance in VDM ++ .

Formalisation of Dynamic Models
Again, two levels of translation are used. For the Model 0 specification the (statechart) state of an object is simply represented as an additional attribute of an object, of an enumerated type.
The interpretation of transitions uses the whenever construct of VDM ++ : This asserts that the predicate ' must be true at some time point in each interval of the form [t; t+],where t is a time where the predicate becomes true (ie., changes from being false or undefined to true).
Thus in case that we have a statechart state S1 as the source of an automatic transition with guard condition E and time specification [l; u], the appropriate whenever statement is: whenever state = S1^residence(S1) ur esidence(S1) l^E also from ==> state = S2 where S2 is the target state of , and is the duration of (negligible but non-zero). residence(S)denotes the amount of time that state = S has held from the most recent time that this became true. It is zero if the state is not currently S.
For a transition triggered by an external event t, we have: whenever state = S1^residence(S1) ur esidence(S1) l^E^#waiting(t) > 0 also from t ==> state = S3 The actions which take place as a result of the transitions can be defined separately. If there are several transitions away from the same state, then care should be taken to ensure that only one whenever clause for this state can have a true premise at any time: ie, transitions should be prioritised.
For the translation to Model 1 assume that statecharts are given by pairs (S; T) of sets S of states and T of transitions. Then the translation steps for the Model 1 level are: 1. For an entity C with statechart (S; T) the VDM ++ class C is extended with methods for each transition t in T, parameterised with formal parameters taken from those of t, with types added (input from the user may be needed to identify these types); 2. Create an enumerated type SE with elements for each state of S, and a variable svar : SE representing the current state of an object from the class C; 3. Each method m representing a transition with source s 1 and destination s 2 has the outline specification m(p : PType) == [ext wr svar post svar = < s 2 >]; (p would be used explicitly in a refinement of this specification) and corresponding permission statement where action(m; s 1) expresses any remote transition invocations associated with transition m from s 1, on the appropriate supplier objects: if the chart for C invokes operations on supplier chart instances g 1 : D 1 , : : : , g m :D m , then these suppliers need to be declared as instance variables g i : @D i . Automatic transitions are invoked (on self)in the statement part of a guarded command, and do not appear in the answer statement part of a select clause. Notice that transition actions take place in the target state of the transition, as in the interpretation of [3].
The above approach omits consideration of time-dependency in enabling conditions, or time bounds on transitions (or state residence). The general form of a timed transition is given in Figure 2. E represents an additional enabling condition which must hold before t can fire, l is a lower bound on the time for which t can be enabled before it fires, whilst u is an upper time bound (which might be infinity 1). We assume the existence of the global time-valued variable now, which gives the current time, and a time-valued variable lastentered local to each class, both initialised to 0. Constraints [l; u] on the delay of a method m from the time that its enabling condition holds until it fires become expressed as inequalities: (now lastentered + u)^(lastentered + l now) -S1 The equality lastentered = now is added to the postcondition of every method specification. Constraints on the duration of activities can be expressed using the value of now ( now.

t[E][l,u]/actions
Other statechart constructs, such as nesting and AND composition, can also be translated into VDM ++ class constructs. Details are in [15]. A logical interpretation of statecharts, suitable for proof, is given in [16].

Example Development: A Traffic Control System
In this section we will examine a small real-time system specification case study, of a traffic control system, to illustrate the above development process on a non-trivial example.

Requirements Identification
The components of the controlled system are: maxfrred is greater than maxmrred.
Since this system is primarily a reactive event-based system, rather than being concerned with data, operations are identified in connection with events on the dynamic model, rather than on the object model. These operations are: to react to the monitor reporting that the traffic on the farm road has cleared, and to react to the monitor reporting that traffic on the farm road has approached.

INTEGRATED FORMAL and OBJECT-ORIENTED METHODS: The VDM ++ Approach
The initial Model 0 specification is expressed in terms of the states of the monitor and traffic lights without factorisation into separate objects (cf. Fusion operation schemas or Syntropy essential models). In particular, we do not yet define a controller object to carry out the required reactions or execute a state machine devised to implement the desired behaviour, but only specify the desired reactions by using whenever statements: class Model 0 types MState = < no trac > j < trac moving > j < trac blocked >; TLState = < red > j < green > j < amber red > j < amber green > whenever mstate = < trac moving >r esidence(< trac moving >) = maxmrred also from 2 inamber + 3 ==> mstate = < trac blocked >; whenever mstate = < no trac >^#waiting(approach) > 0 also from 2 inamber + approach ==> mstate = < trac moving >; whenever mstate = < trac blocked >r esidence(< trac blocked >) = maxfrred also from 2 inamber + 4 ==> mstate = < trac moving > end Model 0 The first formula in the aux reasoning section expresses the first requirement that at all times one or other traffic light set is red. This is a stronger assertion than simply placing the formula frlightstate = < red > _ mrlightstate = < red > in a class invariant, since class invariants may fail to be true during the execution of a method, ie, in this case, during a transition of the controller. The second constraint is expressed by the first two whenever statements and by the definition of clear. The values should be derived as maximum allowable delays from the requirements.
Requirements three to five are expressed by the corresponding whenever statements and by the definition of approach.

Requirements Formalisation
In the initial design, we invent a controller object to link the traffic light and monitor objects in accordance with the required behaviour constraints. The object model of this design is shown in Figure 3. The TracLights class is empty except for a declaration of inamber: Nas a constant.
The statechart of the traffic lights is shown in Figure 4, and that of the monitor in Figure 5. self!tau1()); tlstate = < red > answer go green ! (delay(inamber); self!tau2()) end TracLights The delay statements are an alternative way of expressing time lags between the enabling of a transition (here, tau1 and tau2) and their execution. This could also be specified using a lastentered variable and two additional select clauses, as described in Section 4.2 above.
The thread describes a process which allows the object to be either initialised to the red state or to the green state, and then continually loops, testing each select condition (to the left of the ! symbol), until a true condition is found.
An answer m with a true condition is selected if there are outstanding requests to execute m. The corresponding select clause is then executed by executing m and then the statement to the right of the !.
Verification of the internal consistency of this class will include proving that the thread ensures that the methods are always invoked within their permission guards. This is a liveness requirement: since we know that a traffic light object cannot be shared between two clients in the system, any invocation of a method outside its guard condition will result in deadlock.
The monitor is formalised as a client of the controller, since it only sends events to the controller, and does not receive data or events from it. Similarly the traffic lights are formalised as suppliers of the controller. The trac level variable of Monitorindicates the number of cars on a suitable section of the farm road. When this changes from being zero to being non-zero an approach signal should be sent to the controller. When it changes in the opposite direction a clear signal should be sent: where old tl is set to trac level initially. The Model 1 specification of the controller, using a thread to implement the whenever constraints, is then:

self!trac moving entry()) end Controller
The abstract state is closely related to this initial design. For instance, mstate is implemented by cstate, and mrlightstate is implemented by mrlights:tlstate.
Since TracLights is a class, objects of the class are declared by using the type @TracLights of references to this class. The init objectstate clause defines the initial state of the component -in this case the < no trac > state.
The statechart expressing the design of the system is shown in Figure 6. The use of a translation process has helped to establish a good traceability between the requirements and the implementation: that is, it is direct to relate the requirements through the intermediate stages of their realisation to features of the eventual implementation. This therefore improves the maintainability, assessability and the capability for validating the developed system.

Industrial Case Studies
A number of case studies have been carried out using the methods integration process described here, and using versions of the Venus toolset. These include: Ship-loading systems for bulk and chemical carriers; A minimum safe altitude warning system for an air traffic control network; Data acquisition from particle accelerators; Translation into a hardware description language.
The second case study will be described here.

Minimum Safe Altitude Warning (MSAW)
This system is part of a projected revision of the French air-traffic control network. VDM ++ has been trialed on this component of the system in order to evaluate its possible wider application within the ATC application. The prime function of the MSAW subsystem is to extrapolate the current trajectory of a plane, and to predict potential collisions with known static obstacles (eg, mountains or tall buildings). A warning signal to an ATC operator is given in the case that a high probability of collision is identified.
VDM ++ was used at several different levels. An initial formal model provided an abstract and concise description of the main entities of the system (formalised as classes Obstacle,Radar, etc.) and the required functions, formalised as methods of these classes. This model was then elaborated towards a logical design, incorporating implementation details such as the need to delay the giving of an alarm as long as possible (to avoid spurious warnings). A succession of models of increasing refinement was developed. An advantage of the object-oriented structuring facilities was that the specification could be refined by refining each of the abstract classes separately, and by adding in new classes: it was not necessary to eliminate the conceptually clear entities defined in the initial model. Inheritance was also used to specify natural hierarchies such as the range of possible shapes (cones, cylinders, etc) for obstacles.
The top-level processing of the system is defined in the Workspace class, parts of the Model 1 specification of this class are shown as follows: class WorkSpace is subclass of MSAWTypes functions OrderOfTreatment : F( @Terrain j @Obstacle) ! seq( @Terrain j @Obstacle) OrderOfTreatment(obstacles) == let s : seq( @Terrain j @Obstacle) be st elems(s) = obstaclesl en(s) = card(obstacles) in s = This function denes an ordering on the set of obstacles = instance variables obstacles : F @Obstacle; terrain : @Terrain; = This method is the main operation of the system it calculates the risk of intersection of the prediction segment of each plane with each obstacle: The following thread asserts that it is performed repeatedly with period RadarInterval: = thread periodic(RadarInterval)(CalculateCollisions) end WorkSpace A problem related to this case study which can be addressed using VDM ++ is the need to avoid multiple hierarchies of classes. This arises from the use of particular shapes to represent the layout of different forms of obstacle. An obstacle can be of one of several classes (eg, a military zone, a building or tower, an airport zone, etc), and each kind of obstacle may be further subdivided into types depending on its shape (cylinder, cone, inverted cone, etc). Rather than creating a hierarchy formed out of all combinations of obstacle type and shape (thus leading to classes conical building, cylindrical building, etc), the shape(s) of which an obstacle are constructed can be defined as attributes of the obstacle, and operations dependent on both the type of obstacle and the shape performed as methods of the obstacle class, using delegation. For instance a method intersects could be defined as follows in the class MilitaryObstacle: is defined as an attribute of Obstacle, and the intersects method is inherited and redefined from Obstacle. In classes representing other types of obstacle a different algorithm could be used to calculate the intersects method, utilising the polymorphic intersects method of Shape. This permits dynamic binding to be used on both the Obstacle and Shape hierarchies, without introducing a combinatorial explosion of classes. This is an example of a structural design pattern [9].
The case study was perceived as being a success, in that a description of the system at both an abstract level, comprehensible to the domain experts, and at implementation level, close to executable code, was produced. The Venus toolset was used extensively to keep the formal specifications and diagrammatic models mutually consistent.
The main problem concerned the absence of tool support for the real-time extensions of the language, which are now in place. Training took approximately 10% of the development time, however this should be reduced for future applications using the language. The language is now being further considered for use within larger elements of the ATC application.
Some statistics from the development are as follows: Analysis model size: 934 lines of LOV class description files; Specification size: 18 classes comprising 530 lines of VDM ++ text files; Prototype implementation size: 1776 lines of ".cc" files, and 639 lines of ".h" files.
The growth of the system from specification the prototype is directly due to the use of library classes by the code generator. A similar growth occurs for the implemented code, although in this case additional complexity is introduced during the VDM ++ refinement and design process.

Comparison with other approaches
Methods integration approaches involving formal and diagrammatic methods have ranged from a highly focused use of formal techniques to verify a security critical or safety critical kernel of a system (eg., [5]), to extensive combination at several life cycle stages [12,26]. In addition the translation between diagrammatic and formal notations ranges from being precisely defined and automatable to being intuitive and dependent on user understanding. Venus does not mandate either a localised or broad use of formal notations throughout a development: it is possible to use the formal notation and tool support for a small part of a system, which is then integrated via the LOV tool into the remainder of a conventional OO development. Alternatively the formal notations can be used to catch semantic errors that are not detectable via the OMT notation (such as a claimed subtyping relationship not being mathematically valid), as part of a rigorous review process. Venus provides an automated but configurable translation from object models to formal specifications, thus combining the benefits of precise and user-controllable translation processes. The translation process for statecharts is at present manual, although it is systematically defined and automation is envisaged in future versions of the toolset. No automated translation for functional models or Booch interaction diagrams is envisaged, as these do not have a precise semantics. The benefits of the high degree of integration provided by Venus include being able to switch between formal or diagrammatic views of a system as required, in order to gain greater understanding of a system description, or to conduct specific forms of analysis. Some forms of transformation are more easily performed using the diagrammatic notations (for example, restructuring a complex data model by using a diagram editor) than by using formal textual equivalents, and a close integration allows appropriate tools to be used at each stage.
In contrast to Syntropy and Fusion, the IFDM method of VDM ++ does not add formal notations directly to diagrams, but instead combines diagrams and formal text via translation steps. Placing formal text directly on diagrams can lead to excessive complexity in these diagrams, so hindering their usefulness in giving an abstract presentation of requirements.
Tool support exists for the rigorous review technique at BT [28] and for the Fusion method [2]. Venus provides comparable support for diagrammatic methods to these tools, and more extensive support for formal notations. The main omission from Venus at present are tools for proof, although the axiomatic semantics needed to support such tools has been established [15].

Conclusions
The VDM ++ language and the combination of VDM ++ with OMT via the Venus toolset provides a pragmatic integration of formal and object-oriented techniques. Experience in industrial trials of the toolkit has suggested that it may be well-suited for the introduction of formality into existing object-oriented development.
The language and method permits existing expertise and techniques for object-oriented software development to be reused (for example, the use of delegation in the MSAW case study to avoid combining multiple hierarchies of classes), whilst providing a more rigorous basis for verifying development steps and the internal consistency of classes. Specialisations of the IFDM presented here have been given for process control systems [19] and distributed systems [18].
Training courses have been given for the language and tools to industrial clients, with a high degree of success resulting directly from the use of a CASE tool "front end" for formal specifications. This meant that excessive emphasis on formal text and mathematical notation could be avoided at the beginning of the course, with general abstraction and modelling principles being emphasised instead.