TIVDM1Introduction, Development Process and Overture1 Introduction, Development Process and...

TIVDM1 Introduction, Development Process and Overture 1

Introduction, Development Process and Introduction to Overture

Peter Gorm Larsen

([email protected])


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• Introduction to Overture


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 complex projects (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


• The most convenient way - email

[email protected]• Or see me in my office. I live in at IHA in Room 423b.

Contacting Details


Teaching Material

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

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

• Possibly also VDMTools but that is not certain

• Also possible to use Enterprise Architect (using 30 days free trial)


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


• All information concerning this course including lecture notes, assignments announcements, etc. can be found on the TIVDM1 web pages http://kurser.iha.dk/eit/tivdm1/

• You should check this site frequently for new information and changes. It will be your main source of information for this unit. The layout of the WebPages should be fairly self explanatory

• Campus WebPages will be used only for mailing information

TIVDM1 web pages


• 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


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


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


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 class diagrams.

• 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.


Where is this used?

• Modeling critical computer systems e.g. for industries such 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)• …


Industrially Inspired Examples

• Chemical Plant Alarm Management System

• A Robot Controller• A Road Congestion Warning System


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


An email from an old (very good) student

… At that time I understood that a formal specification would be an advantage for big projects but I had no idea how desperately this is also needed in smaller 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 unit with GPS coordinates) into the overall car. There is a lot of interaction between the telephone and the HMI of the car and there are different versions and types of all the involved devices. There are also five companies (BMW, Motorola, Siemens VDO, Harmann-becker, Alpine) who develop the different units. The system should not be so complex because many of the devices should (!) behave similarly. But the specifications we write are English plain text (hundreds of pages), in our department more than 10 people are involved and we do not know anymore how the devices will behave ourselves...every external company has an own interpretation of the specs and this interpretation changes over time. If you ask the same person twice you get different answers (I frankly admit that I am no exception)... You can imagine how "efficient" everything is and its a miracle that the system still works (with a number of bugs though)...


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• Introduction to Overture


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”


DustExpert (1995-7)

• Organisation: Adelard (UK)• Domain: Safety (dust explosives)• Tools: The VDM-SL Toolbox • 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”


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)


CAVA (1998-)

• Organisation: Baan (Denmark)

• Domain: Constraint solver (Sales Configuration)

• Tools: The VDM-SL Toolbox

• 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”


Dutch DoD (1997-8)

• Organisation: Origin, The Netherlands

• Domain: Military

• Tools: The VDM-SL Toolbox

• Experience:

• Higher level of assurance

• Mastering of complexity

• Delivered at expected cost and on schedule

• No errors detected in code after delivery

• Statement:

• “We chose VDMTools because of high demands on maintainability, adaptability and reliability”


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


DoD - Comparative Metrics

CODING TESTING

CODING TESTINGANALYSIS &

DESIGN

Traditional:Traditional:

VDMToolsVDMTools®®::

CostCost

ANALYSIS & DESIGN

900900 20002000 700700

12001200 500500 600600

0% 64%

100%


BPS 1000 (1997-)• Organisation: GAO, Germany• Domain: Bank note processing• Tools: The VDM-SL Toolbox• 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.


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”


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 subsystem has particularly complex regulations to implement. Modelled in VDM++.

Options Subsystem handles the business process for trading options. Modelled in VDM++


TradeOne Cost Effectiveness

Subsystem COCOMO estimate

Real time Time saving

Tax exemption

Effort:38.5 PM

Schedule:9M

Options Effort:147.2 PM

Schedule:14.3M

Effort:14 PMSchedule: 3.5 M

Effort:74%Schedule:61%

Effort: 60.1 PMSchedule:7M

Effort: 60%Schedule: 51%


The FeliCa Mobile Chip Project

• Mobile FeliCa IC chips can be embedded inside mobile 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


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.0

外部仕様書

形式仕様本開発スタート

1.0

形式仕様書

OS

1.0

定義書

RR

1.0

RR

2.0 パイロット移動機メーカ

RR


RR


RR

5.0 全移動機メーカ

2 +課椎木さんレビュー設計者・評価者レビューα 版評価

クロスチェック評価・カバレッジ評価

RR


設計構想会議

(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 formal specifications was about 1,900 LOC per engineer per month.


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.0

外部仕様書

形式仕様本開発スタート

1.0

形式仕様書

OS

1.0

定義書

RR

1.0

RR


RR


RR


RR


2 +課椎木さんレビュー設計者・評価者レビューα 版評価

クロスチェック評価・カバレッジ評価

RR


設計構想会議

(3M)本開発準備フェーズ (8M)本開発フェーズ (6M)内部リリース後フェーズ (6M)外部リリース後フェーズ

形式

仕様

書0.

9

Specification v.1.0

Specification Phase Implementation Phase2004/7

Number of Changes

0

50

2006/4


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• Introduction to Overture


Vienna Development Method

• Invented at IBM’s labs in Vienna in the 70’s• 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)


VDM-SL Module Outline

modulemodule <module-name><module-name>

definitionsdefinitions

endend <module-name><module-name>

DefinitionsDefinitions

InterfaceInterface

statestate

typestypes

valuesvalues

functionsfunctions

operationsoperations

......

importsimports

exportsexports

......


VDM++ Class Outline

classclass <class-name><class-name>

endend <class-name><class-name>

instance variablesinstance variables

......

typestypes

valuesvalues

functionsfunctions

operationsoperations

threadthread

......

syncsync

......

Internal object stateInternal object state

DefinitionsDefinitions

Dynamic behaviourDynamic behaviour

Synchronization controlSynchronization control

tracestraces

......Test automation supportTest automation support


Validation Techniques• Inspection: organized process of examining the model

alongside domain experts. • Static Analysis: automatic checks of syntax & type

correctness, detect unusual features.• Testing: run the model and check outcomes against

expectations. • Model Checking: search the state space to find states

that violate the properties we are checking. • Proof: use a logic to reason symbolically about whole

classes of states at once.


Validation via Animation

Execution of the model through an interface. The interface can be coded in a programming language of choice so long as a dynamic link facility (e.g. CORBA) exists for linking the interface code to the model.

Formal model

Interpreter

Interface

C++ or Java interface code

Testing can increase confidence, but is only as good as the test set. Exhaustive techniques could give greater confidence.


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• Introduction to Overture


Possible projects1. 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 language

6. 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


Production Cell Overview


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


Conveyor belt

Speed guardSP1

Bar code reader

Photoelectric sensor

LE1

Cylinder 1 out SW1

Cylinder 1 in SW2

Cylinder 2 out SW3

Cylinder 2 in SW4

Motor M1

Discard 1 Discard 2

Overview

Cylinder 1 Cylinder 2


LE1


LE1


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 1’s position. • Switch 3 and 4: Indication of cylinder 2’s 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 by

bar code reader


System-level functionality in VDM-SL

types Stream = seq of Brick; Brick :: code : Code color : <Red> | <Green> | <Yellow>; 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}])


BNF for ”Simple” 1

<specification> ::= { <definition> }

<definition> ::= <type definition> | <function definition>

<type definition> ::= <identifier> = <type>

<identifier> ::= ”a VDM-10 Unicode name”

<type> ::= real | int | nat | bool | <identifier>

<function definition> ::=<identifier> ( <parameter> {, <parameter>} ) == <expression>

<parameter> ::= <identifier> : <type>



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

<expression> ::= <equivalent expression>

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

<equivalent expression> ::= <implies expression> [ <=> <equivalent expression> ]

<implies expression> ::= <or expression> [ => <implies expression> ]

<or expression> ::= <and expression> [ or <or expression> ]

<and expression> ::= <not expression> [ and <and expression> ]

<not expression> ::= <relational expression> | not <not expression>


BNF for ”Simple” 3<relational expression> ::=

<plus minus expression> [ <relop> <not expression> ]

<relop> ::= < | <= | > | >= | <> | =

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

<plus minus expression> ::=<plus minus expression> + <mult div expression> |<plus minus expression> - <mult div expression> |<mult div expression>

<mult div expression> ::=<mult div expression> * <unary expression> |<mult div expression> / <unary expression> |<mult div expression> mod <unary expression> |<mult div expression> rem <unary expression> |<mult div expression> div <unary expression> |<unary expression>



<unary expression> ::=<application expression> | <unaryop> <unary expression>

<unaryop> ::= + | -

<application expression> ::=<basic expression> |<basic expression> ( [ <expression> {, <expression>} ] )

<basic expression> ::=( <expression> ) |<let expression> |<cases expression> |<if expression> |<integer literal> |<real literal> |<identifier> |true |false



<let expression> ::=let <local definition> { , <local definition> } in <expression>

<local definition> ::= <identifier> = <expression>

<cases expression> ::=cases <expression> :<case alternative> { , <case alternative> }[, <others>]end

<case alternative> ::= <expression> -> <expression>

<others> ::= others -> <expression>



<if expression> ::=

if <expression> then <expression>

[ { elseif <expression> then <expression> } ]

else <expression>

<integer literal> ::= <digit> {digit}

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

<real literal> ::=

<integer literal> [ . <integer literal> ][ e [+ | -] <integer literal> ]


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 TIVDM2 course for RT like projects and with further static checks for AST related projects


Anticipated Plan with Projects

• Week 2: Read existing material about the project and formulate 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 project with signatures for operations/functions

• Week 4+5: Model and validate functionality using VDM++

• Week 6: Report with the project is handed in to the teacher

• Week 7: Evaluation of insight gained by using the model-driven approach combining VDM++ and UML


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• Introduction to Overture


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) and

operations (often from actions). Create a dictionary by giving explanations to items in the list.

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

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

7. Complete the class (and data type) definitions by determining potential invariant 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.


A Chemical Plant

alarmalarmexpertexpert


A Chemical Plant Requirements

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

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 it

along 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 right

qualification 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 they

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


The Purpose of the VDM++ Model

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

experts to deal with alarms.


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)


Guideline 1

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

functionality in addition to read/write.


Sketching an Alarm

Defined as a VDM++ class:Defined as a VDM++ class:

classclass Alarm Alarminstance variablesinstance variables reqQuali: Expert`QualificationreqQuali: Expert`Qualification descr : String;descr : String;endend Alarm Alarm


Alternative Alarm

AlarmAlarm could also have been defined as a composite could also have been defined as a composite type:type:

Alarm :: reqQuali : Expert`QualificationAlarm :: reqQuali : Expert`Qualification descr : Stringdescr : String

a.descra.descr is the description of is the description of aa

a.descr : Stringa.descr : String

a.reqQuali : Expert`Qualificationa.reqQuali : Expert`Qualification

Then if Then if aa is of type is of type AlarmAlarm::


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.


Guideline 3 and 4

Whenever an association is introduced consider its multiplicity and give it a rôle 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.


Initial Class Diagram

class Plantinstance variablespublic alarms : set of Alarm;public schedule : map Period to set of Expert;

end Plant


Guideline 5

Declare instance variables to be private or protected to keep encapsulation. If nothing is specified by the user, private is

assumed automatically.

class Expertinstance variablesprivate quali: set of Qualification;end Expert

class Alarminstance variablesprivate descr : String;private reqQuali: Qualification;end Alarm


Guideline 6 and 7

Use VDMTools to check internal consistency as soon as class 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 Planttypes Period = token;end Plant

Tokens are useful for abstract models where unspecified values are to be used.


Adding Quantification and String

class Experttypes Qualification = <Mech> | <Chem> | <Bio> | <Elec>end Expert

class Alarmtypespublic String = seq of char;instance variables descr : String; reqQuali : Expert`Qualification;end Alarm


Guideline 8

Think carefully about the parameter types and the result type as this often helps to identify missing connections

in the class diagram.


Updated UML Class Diagram


Guideline 9

class Plant...

instance variables

alarms : set of Alarm;schedule: map Period to set of Expert;inv forall p in set dom schedule & schedule(p) <> {};

end Plant

Document important properties or constraints asinvariants.


Guideline 10

ExpertToPage: Alarm * Period ==> ExpertExpertToPage(a, p) == is not yet specifiedpre a in set alarms and p in set dom schedulepost let expert = RESULT in expert in set schedule(p) and a.GetReqQuali() in set expert.GetQuali();

When there are several alternative ways of performing some functionality, use an implicit definition so that

subsequent development work is not biased.


Will the Qualification exist?

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

• We need to add an invariant to the instance variables We need to add an invariant to the instance variables of the of the PlantPlant class class

• That is using guideline 11That is using guideline 11


Guideline 11

instance variables

alarms : set of Alarm;schedule: map Period to set of Expert;inv forall p in set dom schedule & schedule(p) <> {};inv forall a in set alarms & forall p in set dom schedule & exists expert in set schedule(p) & a.GetReqQuali() in set expert.GetQuali();

When defining operations, try to identify additionalinvariants.


Further Operations inside Plant

class Plantoperations…

public NumberOfExperts: Period ==> natNumberOfExperts(p) == return card schedule(p)pre p in set dom schedule;

public ExpertIsOnDuty: Expert ==> set of PeriodExpertIsOnDuty(ex) == return {p | p in set dom schedule & ex in set schedule(p)};

end Plant


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 a

programming language.


Final UML Class Diagram


Guideline 13

functions

PlantInv: set of Alarm * map Period to set of Expert -> boolPlantInv(as,sch) == (forall p in set dom sch & sch(p) <> {}) and (forall a in set as & forall p in set dom sch & 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 the invariant in a separate function if the constructor needs to assign values to the instance variables involved in

the invariant.


To be used inside Plant Constructor

class Plant…public Plant: set of Alarm * map Period to set of Expert ==> PlantPlant(als,sch) ==( alarms := als; schedule := sch)pre PlantInv(als,sch);end Plant


Review Requirements (1)

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

R2: Four kinds of qualifications are needed to cope with 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 Qualification type definition of the Expert class.

Invariant on the instance variables of class Plant.


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 which can 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.


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 of experts on duty.

The ExpertOnDuty operation.

The NumberOfExperts with assumption for a

given period.


Testing The Model

• Examine the file Test.vdmpp. This is a test driver class.

• Start up Overture with the project Alarm++Traces.• Start up the debugger with different test arguments

and debug your model...


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?


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 Introduction to Overture


Overture Perspective

Project explorer with VDM model files

Outline of VDM model

Errors and warnings

Changing perspective

VDM Editors


Debug Perspective

Call traces in debug

Inspecting variables

Editor

Interactive console

Outline


Combinatorial Testing Perspective

Regular expression

Overview of results

Detailed test case and results


Proof Obligation Perspective

Proof obligation view

(let expert:Expert = RESULT in

p in set dom schedule)


Real-Time Log View


Exercise using Overture

• Install Overture from https://sourceforge.net/projects/overture/ • Download ExamplesPP.zip from https://sourceforge.net

/projects/overture/files/Examples • Import only the Alarm and AlarmErr 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


Summary• What have I presented today?

• Administrative information about the course

• 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


Quote of the day

Abstraction, difficult as it is, is the source of practical power.

Bertrand Russell

(1872 - 1970)

TIVDM1Introduction, Development Process and Overture1 Introduction, Development Process and...

Documents

Transcript of TIVDM1Introduction, Development Process and Overture1 Introduction, Development Process and...