01 introduction and process

7/30/2019 01 Introduction and Process

1/91

TIVDM1 Introduction, Development Process and Overture 1

Introduction, Development Process and

Introduction to Overture

Peter Gorm Larsen

([email protected])
mailto:[email protected]:[email protected]


2/91


Agenda

Administrative information about the course

Selected Industrial VDM Projects

What are VDM models and how are they validated?

Suggested Projects to undertake The Process using the VDM++ and UML combination



3/91


Who is the teacher?

Peter Gorm Larsen; MSc, PhD

20+ years of professional experience

year with Technical University of Denmark

13 years with IFAD

3 years with Systematic

4 years with Engineering College of Aarhus

Consultant for most large defence contractors on large complexprojects (e.g. Joint Strike Fighter)

Relations to industry and academia all over the world

Has written books and articles about VDM

See http://pglconsult.dk/private/peter.htm for details
http://pglconsult.dk/private/peter.htmhttp://pglconsult.dk/private/peter.htm


4/91


The most convenient way - email

[email protected]

Or see me in my office. I live in at IHA in Room 423b.

Contacting Details
mailto:[email protected]:[email protected]


5/91


Teaching Material

John Fitzgerald, Peter Gorm Larsen, PaulMukherjee, Nico Plat and Marcel Verhoef:Validated Designs for Object-oriented Systems.Springer Verlag, 2005.

Tool used during the course is the Overturetools on the Eclipse platform(https://sourceforge.net/projects/overture/)

Possibly also VDMTools but that is not certain

Also possible to use Enterprise Architect (using30 days free trial)
https://sourceforge.net/projects/overture/https://sourceforge.net/projects/overture/


6/91


VDM Examples

Existing examples can be imported in Overture if one downloads from

https://sourceforge.net/projects/overture/files/Examples

Note that there exists 3 different VDM dialects

Right now you should be interested in VDM++ and in the next course

VDM-RT models will be used also
https://sourceforge.net/projects/overture/files/Exampleshttps://sourceforge.net/projects/overture/files/Examples


7/91


All information concerning this course includinglecture notes, assignments announcements, etc. canbe found on the TIVDM1 web pageshttp://kurser.iha.dk/eit/tivdm1/

You should check this site frequently for newinformation and changes. It will be your main sourceof information for this unit. The layout of theWebPages should be fairly self explanatory

Campus WebPages will be used only for mailinginformation

TIVDM1 web pages
http://kurser.iha.dk/eit/tivdm1/http://kurser.iha.dk/eit/tivdm1/


8/91


Confrontation with the teacher Thursdays 8:00 16:00 in Room 316

Read in advance of each lecture

Combination of

Lessons teaching theory

Strategy for lessons: quick intro to concepts and then usage in

larger examples

Projects where theory is turned into practice

Using Overture for projects

Exam form 15 minutes oral examination without preparation + 5 minutes for

evaluation week 12, 2010

Oral examination will be centered around projects performed

Projects will be reused and extended further in TIVDM2

Education Form


9/91


Focus in this course

Focus is on

Abstract modeling of realistic systems

Understanding the VDM concepts

Learning how to read models made in VDM++/UML

Learning how to write models in VDM++/UML Learning how to validate these models

Focus is not on

Toy examples

Concurrency Real-time requirements

Implementation


10/91


Why have this course?

To understand the underlying primitives for being able

to model complex computer systems

To be able to comprehend the formulation of

important desirable properties precisely

To be able to express important desirable properties

precisely

To enable the formulation of abstract models in an

industrially applicable formal notation

To validate those models to increase confidence in

their correctness


11/91


Learning Objectives

The participants must at the end of the course be able to: explain and compare advantages and disadvantages with

alternative abstractions in relation to the purpose of a precise

model.

explain constructs and concepts in the sequential subset of the

modelling language VDM++ and the connection to UML classdiagrams.

define and explain syntax and semantics for the sequential

subset of VDM++.

apply VDM++ and UML with the associated tool support for

abstract and precise modelling and validation of systems.

evaluate practical use of VDM++ for the validation of concrete

system descriptions.


12/91


Where is this used?

Modeling critical computer systems e.g. for industriessuch as

Avionics

Railways

Automotive

Nuclear

Defense

I have used this industrially for example at:

Boeing, Lockheed-Martin (USA)

British Aerospace, Rolls Royce, Adelard (UK) Matra, Dassault, Aerospatiale (France)


13/91


Industrially Inspired Examples

Chemical Plant Alarm Management

System

A Robot Controller

A Road Congestion Warning System


14/91


Structure of the course

1. Introduction, Overture and the development process(chap 1+2 + VDM++ tutorial instead of chapter 3)

2. Real Time process, Abstract Syntax Trees and logic

(notes)

3. Defining data and functionality (chap 4 + 5)4. Modeling using unordered collections (chap 6)

5. Modeling using ordered collections (chap 7)

6. Modeling relationships (chap 8)

7. Course evaluation and repetition


15/91


An email from an old (very good)

student

At that time I understood that a formal specification would be an advantagefor big projects but I had no idea how desperately this is also needed insmaller projects when there are many people involved. Today I do know:

At the moment I am working at BMW in the communications department.We work on the integration of the car telephone (including a telematics unitwith GPS coordinates) into the overall car. There is a lot of interaction

between the telephone and the HMI of the car and there are differentversions and types of all the involved devices. There are also fivecompanies (BMW, Motorola, Siemens VDO, Harmann-becker, Alpine) whodevelop the different units. The system should not be so complex becausemany of the devices should (!) behave similarly. But the specifications wewrite are English plain text (hundreds of pages), in our department morethan 10 people are involved and we do not know anymore how the deviceswill behave ourselves...every external company has an own interpretation ofthe specs and this interpretation changes over time. If you ask the sameperson twice you get different answers (I frankly admit that I am noexception)... You can imagine how "efficient" everything is and its a miraclethat the system still works (with a number of bugs though)...


16/91


Agenda







17/91


ConForm (1994)

Organisation: British Aerospace (UK) Domain: Security (gateway)

Tools: The VDM-SL Toolbox

Experience:

Prevented propagation of error

Successful technology transfer

At least 4 more applications without support

Statements:

Engineers can learn the technique in one week

VDMTools

can be integrated gradually into a

traditional existing development process


18/91


DustExpert (1995-7)

Organisation: Adelard (UK) Domain: Safety (dust explosives)


Experience:

Delivered on time at expected cost

Large VDM-SL specification

Testing support valuable

Statement:

Using VDMTools

we have achieved a productivity

and fault density far better than industry norms for

safety related systems


19/91


Adelard Metrics

31 faults in Prolog and C++ (< 1/kloc)

Most minor, only 1 safety-related

1 (small) design error, rest in coding

Initial requirements 450 pages

VDM specification 16kloc (31 modules)12kloc (excl comments)

Prologimplementation 37kloc16kloc (excl comments)

C++ GUIimplementation

23kloc18kloc (excl comments)


20/91


CAVA (1998-)

Organisation: Baan (Denmark) Domain: Constraint solver (Sales Configuration)


Experience:

Common understanding

Faster route to prototype

Earlier testing

Statement: VDMTools

has been used in order to increase

quality and reduce development risks on high

complexity products


21/91


Dutch DoD (1997-8)

Organisation: Origin, The Netherlands Domain: Military


Experience:

Higher level of assurance

Mastering of complexity

Delivered at expected costand on sch edule

No errors d etected in code after del ivery

Statement:

We chose VDMTools

because of high demands on

maintainability, adaptability and reliability


22/91


DoD, NL Metrics (1)

Estimated 12 C++ loc/h with manual coding!

kloc hours loc/hour

spec 15 1196 13

manual impl 4 471 8.5

automatic impl 90 0 NA

test NA 612 NA

total code 94 2279 41.2totAL


23/91


DoD - Comparative Metrics

CODING TESTING

CODING TESTINGANALYSIS &

DESIGN

Traditional:

VDMTools:

Cost

ANALYSIS &

DESIGN

900 2000 700

1200 500 600

0% 64%100%


24/91


BPS 1000 (1997-)

Organisation: GAO, Germany Domain: Bank note processing


Experience: Better understanding of sensor data

Errors identified in other code

Savings on maintenance

Statement:

VDMTools provides unparalleled support for design

abstraction ensuring quality and control throughout

the development life cycle.


25/91


Flower Auction (1998)

Organisation: Chess, The Netherlands

Domain: Financial transactions

Tools: The VDM++ Toolbox

Experience: Successful combination of UML and VDM++

Use iterative process to gain client commitment

Implementers did not even have a VDM course

Statement:

The link between VDMTools and Rational Rose is

essential for understanding the UML diagrams


26/91


TradeOne, CSK, 2000 - 2001

Full TradeOne system is 1.3 MLOC system

Mission-critical backbone system keeping track of

financial transactions conducted

Used by securities companies and brokerage houses

Tax exemption subsystemhas particularly complexregulations to implement.Modelled in VDM++.

Options Subsystemhandles the businessprocess for tradingoptions. Modelled inVDM++


27/91


TradeOne Cost Effectiveness

Subsystem COCOMOestimate

Real time Time saving

Tax exemption Effort:38.5 PM

Schedule:9M

Options Effort:147.2 PM

Schedule:14.3M

Effort:14 PM

Schedule: 3.5 M

Effort:74%

Schedule:61%

Effort: 60.1 PM

Schedule:7M

Effort: 60%

Schedule: 51%


28/91


The FeliCa Mobile Chip Project

Mobile FeliCa IC chips can be embedded insidemobile phones

Used for different on-line services including payment

Uses Near-Field-Communication technology

Used for example for metro ticketing in Tokyo The IC Chips contains an operating system as

firmware

This is fully developed using the VDM++ technology

More than 50 people in total on the project

Used inside more than 125 million mobile phones

23.5 mm


29/91


Specification and

Implementation Growth

/ /

0

10,000

20,000

30,000

40,000

50,000

60,000

70,000

80,000

90,000

100,000

110,000

120,000

130,000

140,000

2004/7

2004/8

2004/9

2004/10

2004/11

2004/12

2005/1

2005/2

2005/3

2005/4

2005/5

2005/6

2005/7

2005/8

2005/9

2005/10

2005/11

2005/12

2006/1

2006/2

2006/3

2006/4

0

10

20

30

40

50

60

70

80

90

100

1. 1.

OS

1.

R

R

1.

RR2.0

RR3.0

RR4.0

RR5.0

2+

RR7.0

(3M ) (8M ) (6M ) (6M )

Specification v.1.0

Specification Phase Implementation Phase

0.

9

2004/7 2006/4

Specification

Implementation140

0

70

100

kLOC

The average productivity of

VDM++ code for the formalspecifications was about

1,900 LOC per engineer per

month.


30/91


Number of Changes

/ /

0

10,000

20,000

30,000

40,000

50,000

60,000

70,000

80,000

90,000

100,000

110,000

120,000

130,000

140,000

2004/7

2004/8

2004/9

2004/10

2004/11

2004/12

2005/1

2005/2

2005/3

2005/4

2005/5

2005/6

2005/7

2005/8

2005/9

2005/10

2005/11

2005/12

2006/1

2006/2

2006/3

2006/4

0

10

20

30

40

50

60

70

80

90

100

1. 1.

OS

1.

R

R

1.

RR2.0

RR3.0

RR4.0

RR5.0

2+

RR7.0

(3M ) (8M ) (6M ) (6M )

0.

9

Specification v.1.0

Specification Phase Implementation Phase

2004/7

Number of Changes

0

50

2006/4


31/91


Agenda







32/91


Vienna Development Method

Invented at IBMs labs in Vienna in the 70s

VDM-SL and VDM++

ISO Standardisation of VDM-SL

VDM++ is an object-oriented extension

Model-oriented specification:

Simple, abstract data types

Invariants to restrict membership

Specification of functionality:

Referentially transparent functions

Operations with side effects on state variables

Implicit specification (pre/post)

Explicit specification (functional or imperative)


33/91


VDM-SL Module Outline

module

definitions

end

Definitions

Interface

state

types

values

functions

operations

...

imports

exports

...


34/91


VDM++ Class Outline

class

end

instance variables

...

types

values

functions

operations

thread

...

sync...

Internal object state

Definitions

Dynamic behaviour

Synchronization control

traces

...Test automation support


35/91


Validation Techniques

Inspection: organized process of examining the modelalongside domain experts.

Static Analysis: automatic checks of syntax & type

correctness, detect unusual features.

Testing: run the model and check outcomes againstexpectations.

Model Checking: search the state space to find states

that violate the properties we are checking.

Proof: use a logic to reason symbolically about wholeclasses of states at once.


36/91


Validation via Animation

Execution of the model through an interface. Theinterface can be coded in a programming language of

choice so long as a dynamic linkfacility (e.g. CORBA)

exists for linking the interface code to the model.

Formalmodel

Interpreter

Interface

C++ orJavainterfacecode

Testing can increase confidence, but is only as good as

the test set. Exhaustive techniques could give greater

confidence.


37/91


Agenda




Suggested Projects to undertake

The Process using the VDM++ and UML combination



38/91


Possible projects

1. Traffic light controller

2. Robot arm controller in connection to production cell for example

3. Helicopter hover control with sensors for sudden down draft,

engine failure etc.

4. Math notation print of ASCII expressions: AST

5. Static and dynamic semantics for a small language6. Human health alarm, a number of different sensors on a person

and a remove alarm station

7. Home control, connection between embed controllers for switches

and multilevel devices

8. Conveyor belt from Automation BSc course

9. Projects from Distributed Real-Time Systems

10. Projects from Specification of IT Systems

11. Suggest your own project


39/91


Production Cell Overview


40/91


Production Cell References

Citations for the book about this

Project assignment from AUC/DTU about this

Slides about Production cell in different formalism

A book with a comparative study
http://citeseer.ist.psu.edu/context/124400/0http://www.cs.auc.dk/~kgl/DTU00/PROJECT/project.htmlhttp://www.di.unipi.it/AsmBook/LectureSlides/ProdCell/ProdCell.ppthttp://www.di.unipi.it/AsmBook/LectureSlides/ProdCell/ProdCell.ppthttp://www.cs.auc.dk/~kgl/DTU00/PROJECT/project.htmlhttp://citeseer.ist.psu.edu/context/124400/0


41/91


Conveyor belt

Speed guard

SP1

Bar code

reader

Photoelectric

sensor

LE1

Cylinder 1 out

SW1

Cylinder 1 in

SW2Cylinder 2 out

SW3

Cylinder 2 in

SW4

Motor

M1

Discard 1 Discard 2

Overview

Cylinder 1 Cylinder 2

Photoelectric

sensor

LE1

Photoelectric

sensor

LE1


42/91


Components and Control

Components

M1: Engine to pull the belt forward or backward.

Speed control: Indication that the belt is running.

Cylinder 1 and 2: Pneumatic cylinders for moving off bricks.

Switch 1 and 2: Indication of cylinder 1s position.

Switch 3 and 4: Indication of cylinder 2s position.

Barcode reader: Reads the bar code on a brick. Photo cell 1: Register a brick right after the bar code reader.

Photo cell 2: Register a brick right before discard 1.

Photo cell 3: Register a brick right before discard 2

Control

Operator selection of sorting principles Alarms for cylinders

Alarm if the belt stops while processing is ongoing

Alarm is photo cell discover bricks that have not been processed bybar code reader


43/91


System-level functionality

in VDM-SL

typesStream = seq of Brick;

Brick ::

code : Code

color : | | ;

Code =token

;

functions

ConveyorBelt: Stream * Code * Code -> Stream * Stream * Stream

ConveyorBelt(input,code1,code2) ==

mk_([input(i) | i in set inds input & input(i).code = code1],

[input(i) | i in set inds input & input(i).code = code2],

[input(i) | i in set inds input& input(i).code not in set {code1,code2}])


44/91


BNF for Simple 1

::= { }

::= |

::= =

::= a VDM-10 Unicode name

::= real | int | nat | bool |

::= ( {, } ) ==

::= :


45/91


BNF for Simple 2

-- Note that the expression operator precedence and associativity-- is expressed in the recursive structure of the grammar

::=

-- The least binding operators are right-associative...

::= [ ]

::= [ => ]

::= [ or ]

::= [ and ]

::= | not


46/91


BNF for Simple 3

::=

[ ]

::= < | | >= | | =

-- The arithmetic operators are left-associative...

::= + |

- |

::=

* |

/ | mod |

rem |

div |


47/91


BNF for Simple 4

::= |

::= + | -

::=

|

( [ {, } ] )

::=

( ) |

|

|

|

|

|

|

true |

false


48/91


BNF for Simple 5

::=let { , } in

::= =

::=cases :

{ , }

[, ]

end

::= ->

::= others ->


49/91


BNF for Simple 6

::=

if then

[ { elseif then } ]

else

::= {digit}

::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

::=

[ . ][ e [+ | -] ]


50/91


Establishments of Groups

For each of these possible projects the participants

should go together to form small groups of 2 to 3

persons per group

Groups should decide this week which project to work

on during this course

Every week (2 6) every group will present to the

entire class how their project is getting along

The project will be further extended and analyzed with

concurrency and real-time aspects in the TIVDM2course for RT like projects and with further static

checks for AST related projects


51/91


Anticipated Plan with Projects

Week 2: Read existing material about the project andformulate a new requirements definition for the project

to undertake with focus on the purpose of the model

to develop

Week 3: Complete UML class diagram for the projectwith signatures for operations/functions

Week 4+5: Model and validate functionality using

VDM++

Week 6: Report with the project is handed in to theteacher

Week 7: Evaluation of insight gained by using the

model-driven approach combining VDM++ and UML


52/91


Agenda








53/91


Steps to Develop a Formal Model1. Determine the purpose of the model.

2. Read the requirements.3. Analyze the functional behavior from the requirements.

4. Extract a list of possible classes or data types (often from nouns) andoperations (often from actions). Create a dictionary by giving explanations toitems in the list.

5. Sketch out representations for the classes using UML class diagrams. Thisincludes the attributes and the associations between classes. Transfer thismodel to VDM++ and check its internal consistency.

6. Sketch out signatures for the operations. Again, check the model'sconsistency in VDM++.

7. Complete the class (and data type) definitions by determining potentialinvariant properties from the requirements and formalizing them.

8. Complete the operation definitions by determining pre- and post conditions

and operation bodies, modifying the type definitions if necessary.9. Validate the specification using systematic testing and rapid prototyping.

10. Implement the model using automatic code generation or manual coding.


54/91


A Chemical Plant

alarmexpert


55/91


A Chemical Plant Requirements

1. A computer-based system is to be developed to manage the alarms of thisplant.

2. Four kinds of qualifications are needed to cope with the alarms: electrical,mechanical, biological, and chemical.

3. There must be experts on duty during all periods allocated in the system.

4. Each expert can have a list of qualifications.

5. Each alarm reported to the system has a qualification associated with italong with a description of the alarm that can be understood by the expert.

6. Whenever an alarm is received by the system an expert with the rightqualification should be found so that he or she can be paged.

7. The experts should be able to use the system database to check when theywill be on duty.

8. It must be possible to assess the number of experts on duty.


56/91


The Purpose of the VDM++ Model

The purpose of the model is to clarify the rulesgoverning the duty roster and calling out of

experts to deal with alarms.


57/91


Creating a Dictionary

Potential Classes and Types (Nouns)

Alarm: required qualification and description

Plant: the entire system

Qualification (electrical, mechanical, biological, chemical)

Expert: list of qualifications

Period (whatever shift system is used here) System and system database? This is probably a kind of

schedule.

Potential Operations (Actions)

Expert to page: when an alarm appears (what's involved?

Alarm operator and system) Expert is on duty: check when on duty (what's involved?

Expert and system)

Number of experts on duty: presumably given period(what's involved? operator and system)


58/91


Guideline 1

Nouns from a dictionary should be modeled as types if, forthe purposes of the model, they need have only trivial

functionality in addition to read/write.


59/91


Sketching an Alarm

Defined as a VDM++ class:

class Alarm

instance variables

reqQuali: Expert`Qualification

descr : String;

endAlarm


60/91


Alternative Alarm

Alarm could also have been defined as a composite

type:

Alarm :: reqQuali : Expert`Qualification

descr : String

a.descr is the description ofa

a.descr : String

a.reqQuali : Expert`Qualification

Then ifa is of typeAlarm:


61/91


Guideline 2

Create an overall class to represent the entire system so

that the precise relationships between the different

classes and their associations can be expressed

there.


62/91


Guideline 3 and 4

Whenever an association is introduced consider its

multiplicity and give it a rle name in the direction in

which the association is to be used.

If an association depends on some value, a qualifier

should be introduced for the association. The name of

the qualifier must be a VDM++ type.


63/91


Initial Class Diagram

class Plant

instance variables

public alarms : set of Alarm;

public schedule :map Period to set of Expert;

endPlant


64/91


Guideline 5

Declare instance variables to beprivate orprotectedto keepencapsulation. If nothing is specified by the user,private is

assumed automatically.

class Expertinstance variables

private quali: set of Qualification;

endExpert

class Alarm

instance variables

private descr : String;

private reqQuali: Qualification;

endAlarm


65/91


Guideline 6 and 7

Use VDMTools to check internal consistency as soon asclass skeletons have been completed and before any

functionality has been introduced.

Definition of types missing

To be updated in the respective classes Resynchronized with the UML model

class Plant

types

Period = token;endPlant

Tokens are useful for abstract models where unspecifiedvalues are to be used.


66/91


Adding Quantification and String

class Experttypes

Qualification = | | |

endExpert

class Alarm

types

public String = seq of char;

instance variables

descr : String;

reqQuali : Expert`Qualification;

endAlarm


67/91


Guideline 8

Think carefully about the parameter types and the resulttype as this often helps to identify missing connectionsin the class diagram.


68/91


Updated UML Class Diagram


69/91


Guideline 9

class Plant

...

instance variables

alarms : set of Alarm;

schedule:map Period to set of Expert;inv forall p in setdomschedule & schedule(p) {};

endPlant

Document important properties or constraints asinvariants.


70/91


Guideline 10

ExpertToPage: Alarm * Period ==> Expert

ExpertToPage(a, p) ==

is not yet specified

pre a in set alarms and

p in set domschedule

postlet expert = RESULTin

expert in set schedule(p) and

a.GetReqQuali() in set expert.GetQuali();

When there are several alternative ways of performingsome functionality, use an implicit definition so thatsubsequent development work is not biased.


71/91


Will the Qualification exist?

How can we be sure that an expert with the requiredqualification exists in the required period?

We need to add an invariant to the instance variables

of the Plantclass

That is using guideline 11


72/91


Guideline 11

instance variables

alarms : set of Alarm;

schedule:map Period to set of Expert;

inv forall p in set domschedule & schedule(p) {};

inv forall a in set alarms &

forall p in set domschedule &

exists expert in set schedule(p) &a.GetReqQuali() in set expert.GetQuali();

When defining operations, try to identify additional

invariants.


73/91


Further Operations inside Plant

class Plantoperations

public NumberOfExperts: Period ==> nat

NumberOfExperts(p) ==

return cardschedule(p)pre p in set domschedule;

public ExpertIsOnDuty: Expert ==> set of Period

ExpertIsOnDuty(ex) ==

return {p | p in set domschedule &

ex in set schedule(p)};

endPlant


74/91


Guideline 12

import java.util.*;

class Plant {

Map schedule;

Set ExpertIsOnDuty(Integer ex) {

TreeSet resset = new TreeSet();

Set keys = schedule.keySet();

Iterator iterator = keys.iterator();

while(iterator.hasNext()) {

Object p = iterator.next();

if ( ( (Set) schedule.get(p)).contains(ex))

resset.add(p);

}

return resset;

}

}

Try to make explicit operation definitions precise and clear

and yet abstract compared to code written in aprogramming language.


75/91


Final UML Class Diagram


76/91


Guideline 13

functions

PlantInv: set of Alarm *map Period to set of Expert ->

bool

PlantInv(as,sch) ==

(forall p in set domsch & sch(p) {}) and(forall a in set as &

forall p in set domsch &

exists expert in set sch(p) &

a.GetReqQuali() in set expert.GetQuali());

Whenever a class has an invariant on its instance

variables and it has a constructor, it is worth placing theinvariant in a separate function if the constructor needsto assign values to the instance variables involved in

the invariant.

T b d i id Pl t


77/91


To be used inside Plant

Constructor

class Plant

public Plant: set of Alarm *

map Period to set of Expert ==>

Plant

Plant(als,sch) ==

( alarms := als;

schedule := sch

)

pre PlantInv(als,sch);

endPlant


78/91


Review Requirements (1)

R1: A computer-based system managing this plant is tobe developed.

R2: Four kinds of qualifications are needed to copewith the alarms: electrical, mechanical, biological,

and chemical.

R3: There must be experts on duty at all times during

all periods which have been allocated in the system.

Considered in the Plant class definition and the

operation and function definitions.

Considered in the Qualificationtype definition

of the Expertclass.

Invariant on the instance variablesof class Plant.


79/91


Review Requirements (2)

R4: Each expert can have a list of qualifications.

R5: Each alarm reported to the system must have a

qualification associated with it and a description whichcan be understood by the expert.

R6: Whenever an alarm is received by the system an

expert with the right qualification should be paged.

Assumption: non-empty set instead of list in class

Expert.

Considered in the instance variables of the Alarm

class definition assuming that it is precisely one

qualification.

The ExpertToPage operation with additional invariant

on the instance variables of the Plant class definition.


80/91


Review the Requirements (3)

R7: The experts should be able to use the system

database to check when they will be on duty.

R8: It must be possible to assess the number ofexperts on duty.

The ExpertOnDuty operation.

The NumberOfExperts with assumption for a

given period.


81/91


Testing The Model

Examine the file Test.vdmpp. This is a test driverclass.

Start up Overture with the projectAlarm++Traces.

Start up the debugger with different test arguments

and debug your model...


82/91


Running Tests

Execute your model to answer the following questions:

How many experts are on duty during Tuesday day(period p3)?

Which period has the most experts on duty?

Is John on duty on Monday night?

Is Ringo qualified to deal with electrical alarms?


83/91


Agenda







Changingti


84/91

TIVDM1 Introduction, Development Process and Overture 84 84

Overture Perspective

Project explorer

with VDM modelfiles

Outline of VDMmodel

Errors andwarnings

perspective

VDM Editors


85/91


Debug Perspective

Call traces in

debug

Inspecting

variables

Editor

Interactive

console

Outline

Combinatorial Testing Perspective


86/91


Regularexpression

Overview ofresults

Detailed test caseand results

P f Obli i P i


87/91


Proof Obligation Perspective

Proof obligation view

(let expert:Expert = RESULTin

p in set dom schedule)

Real-Time Log View


88/91


Real Time Log View


89/91


Exercise using Overture

Install Overture fromhttps://sourceforge.net/projects/overture/

Download ExamplesPP.zip from

https://sourceforge.net/projects/overture/files/Examples

Import only theAlarm

andAlarmErr

projects

Fix the errors in the AlarmErr project

Add operations to add and remove experts from the

schedule

Test these with the debugger Try to write a trace that can test them and use the

combinatorial testing feature

Inspect and understand the proof obligations for the project
https://sourceforge.net/projects/overture/https://sourceforge.net/projects/overture/files/Exampleshttps://sourceforge.net/projects/overture/files/Exampleshttps://sourceforge.net/projects/overture/


90/91


Summary

What have I presented today?


An overview of selected industrial VDM projects

An intro about VDM and validation techniques

Potential projects to work on in this course

A first glimpse of the process of constructing a model

What do you need to do now?

Read chapter 1 to 3 of the book

Install Overture and work through the Overture VDM++

tutorial

Form groups for the projects

Select the project to work on


91/91

Quote of the day

Abstraction, difficult as it is, is thesource of practical power.

Bertrand Russell

(1872 - 1970)

01 introduction and process

Documents