Introduction, Development Process and
Introduction to Overture
Peter Gorm Larsen
(pgl@iha.dk)
TIVDM1
Introduction, Development Process and Overture
1
Agenda

•
•
•
•
•
TIVDM1
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
Introduction, Development Process and Overture
2
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
TIVDM1
Introduction, Development Process and Overture
3
Contacting Details
• The most convenient way - email
pgl@iha.dk
• Or see me in my office. I live in at IHA in Room 423b.
TIVDM1
Introduction, Development Process and Overture
4
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)
TIVDM1
Introduction, Development Process and Overture
5
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
TIVDM1
Introduction, Development Process and Overture
6
TIVDM1 web pages
• 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
Introduction, Development Process and Overture
7
Education Form
• 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
TIVDM1
Introduction, Development Process and Overture
8
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
•
•
•
•
TIVDM1
Toy examples
Concurrency
Real-time requirements
Implementation
Introduction, Development Process and Overture
9
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
TIVDM1
Introduction, Development Process and Overture
10
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.
TIVDM1
Introduction, Development Process and Overture
11
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:
•
•
•
•
TIVDM1
Boeing, Lockheed-Martin (USA)
British Aerospace, Rolls Royce, Adelard (UK)
Matra, Dassault, Aerospatiale (France)
…
Introduction, Development Process and Overture
12
Industrially Inspired Examples
• Chemical Plant Alarm Management
System
• A Robot Controller
• A Road Congestion Warning System
TIVDM1
Introduction, Development Process and Overture
13
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
TIVDM1
Introduction, Development Process and Overture
14
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)...
TIVDM1
Introduction, Development Process and Overture
15
Agenda


•
•
•
•
TIVDM1
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
Introduction, Development Process and Overture
16
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”
TIVDM1
Introduction, Development Process and Overture
17
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”
TIVDM1
Introduction, Development Process and Overture
18
Adelard Metrics
Initial requirements 450 pages
VDM specification
16kloc (31 modules)
12kloc (excl comments)
Prolog
implementation
37kloc
16kloc (excl comments)
C++ GUI
implementation
23kloc
18kloc (excl comments)
• 31 faults in Prolog and C++ (< 1/kloc)
• Most minor, only 1 safety-related
• 1 (small) design error, rest in coding
TIVDM1
Introduction, Development Process and Overture
19
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”
TIVDM1
Introduction, Development Process and Overture
20
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”
TIVDM1
Introduction, Development Process and Overture
21
DoD, NL Metrics (1)
kloc
spec
hours
loc/hour
15
1196
13
4
471
8.5
automatic impl
90
0
NA
test
NA
612
NA
total code
94
2279
41.2
manual impl
tot AL
• Estimated 12 C++ loc/h with manual coding!
TIVDM1
Introduction, Development Process and Overture
22
DoD - Comparative Metrics
Traditional:
900
2000
ANALYSIS &
DESIGN
CODING
700
TESTING
VDMTools®:
1200
ANALYSIS &
DESIGN
500
CODING
600
TESTING
100%
0%
TIVDM1
64%
Introduction, Development Process and Overture
Cost
23
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.
TIVDM1
Introduction, Development Process and Overture
24
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”
TIVDM1
Introduction, Development Process and Overture
25
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
Options Subsystem
handles the business
process for trading
options. Modelled in
VDM++
Tax exemption subsystem
has particularly complex
regulations to implement.
Modelled in VDM++.
TIVDM1
Introduction, Development Process and Overture
26
TradeOne Cost Effectiveness
Subsystem
COCOMO
estimate
Tax exemption
Effort:38.5 PM
Schedule:9M
Effort:14 PM
Effort:74%
Schedule: 3.5 M Schedule:61%
Options
Effort:147.2 PM
Schedule:14.3M
Effort: 60.1 PM
Schedule:7M
TIVDM1
Real time
Introduction, Development Process and Overture
Time saving
Effort: 60%
Schedule: 51%
27
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
TIVDM1
Introduction, Development Process and Overture
28
Specification and
Implementation Growth
kLOC
Specification v.1.0
コミットした累計行数
140
140,000
仕様変更
形式仕様
実装
130,000
仕様変更数
形式仕様と実装のコミットした累計行数 / 仕様変更数 / 各種イベント
100
Implementation
90
120,000
80
TIVDM1
R R 4.0 パイロット移動機メーカ
R R 7.0 全移動機メーカ
R R 5.0 全移動機メーカ
R R 3.0 パイロット移動機メーカ
O S定義書1.0
R R 1.0
Development Process and Overture
Specification Introduction,
Phase
Implementation Phase
本開発準備フェーズ (3M )
本開発フェーズ (8M )
60
50
40
内部リリース後フェーズ (6M )
外部リリース後フェーズ (6M )
2006/4
2006/3
2005/5
2005/4
2005/3
2005/2
2005/1
2004/12
2004/11
2004/10
2004/7
2004/9
2004/8
2004/7
0
2006/2
2課+椎木さんレビュー
α版評価
2006/1
0
2005/12
10,000
2005/11
20,000
2005/9
30,000
2005/8
40,000
70
The average productivity of
VDM++ code for the formal
specifications was about
1,900 LOC クロスチェ
per ッengineer
per
ク評価 ・カバレッジ評価
設計者・
評価者レビュー
month.
2005/7
50,000
形式仕様書1.0
60,000
Specification
2005/6
70
70,000
設計構想会議
80,000
外部仕様書1.0
90,000
形式仕様書0.9
形式仕様本開発スタート
100,000
2005/10
100
R R 2.0 パイロット移動機メーカ
110,000
30
20
10
0
2006/4
29
Number of Changes
Specification v.1.0
コミットした累計行数
140,000
仕様変更数
形式仕様と実装のコミットした累計行数 / 仕様変更数 / 各種イベント
100
仕様変更
形式仕様
実装
130,000
90
120,000
80
50,000
40,000
R R 4.0 パイロット移動機メーカ
70
R R 7.0 全移動機メーカ
R R 5.0 全移動機メーカ
R R 3.0 パイロット移動機メーカ
O S定義書1.0
R R 1.0
60,000
形式仕様書1.0
70,000
設計構想会議
80,000
外部仕様書1.0
90,000
形式仕様書0.9
形式仕様本開発スタート
100,000
R R 2.0 パイロット移動機メーカ
110,000
60
50
50
40
Number of Changes
30,000
30
20
20,000
10
クロスチェック評価 ・カバレッジ評価
10,000
設計者・
評価者レビュー
2課+椎木さんレビュー
α版評価
0
TIVDM1
Development Process and Overture
Specification Introduction,
Phase
Implementation Phase
本開発準備フェーズ (3M )
本開発フェーズ (8M )
内部リリース後フェーズ (6M )
外部リリース後フェーズ (6M )
2006/4
2006/3
2006/2
2006/1
2005/12
2005/11
2005/10
2005/9
2005/8
2005/7
2005/6
2005/5
2005/4
2005/3
2005/2
2005/1
2004/12
2004/11
2004/10
2004/7
2004/9
2004/8
2004/7
0
0
2006/4
30
Agenda



•
•
•
TIVDM1
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
Introduction, Development Process and Overture
31
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:
•
•
•
•
TIVDM1
Referentially transparent functions
Operations with side effects on state variables
Implicit specification (pre/post)
Explicit specification (functional or imperative)
Introduction, Development Process and Overture
32
VDM-SL Module Outline
module <module-name>
imports
exports
...
Interface
definitions
state
types
values
Definitions
functions
operations
...
end <module-name>
TIVDM1
Introduction, Development Process and Overture
33
VDM++ Class Outline
class <class-name>
instance variables
Internal object state
...
types
values
Definitions
functions
operations
thread
Dynamic behaviour
...
sync
Synchronization control
...
traces
Test automation support
...
end <class-name>
TIVDM1
Introduction, Development Process and Overture
34
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.
TIVDM1
Introduction, Development Process and Overture
35
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.
TIVDM1
Introduction, Development Process and Overture
36
Agenda




•
•
TIVDM1
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
Introduction, Development Process and Overture
37
Possible projects
1.
2.
3.
Traffic light controller
Robot arm controller in connection to production cell for example
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
TIVDM1
Introduction, Development Process and Overture
38
Production Cell Overview
TIVDM1
Introduction, Development Process and Overture
39
Production Cell References
•
•
•
•
TIVDM1
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
Introduction, Development Process and Overture
40
Conveyor belt
Overview
Discard 1
Speed guard
SP1
Photoelectric
sensor
LE1
Bar code
reader
Photoelectric
sensor
LE1
Photoelectric
sensor
LE1
Cylinder 1
Cylinder 1 in
SW2
TIVDM1
Discard 2
Motor
M1
Cylinder 2
Cylinder 1 out
SW1
Introduction, Development Process and Overture
Cylinder 2 in
SW4
Cylinder 2 out
SW3
41
Components and Control
•
Components
•
•
•
•
•
•
•
•
•
•
Control
•
•
•
•
TIVDM1
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
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
Introduction, Development Process and Overture
42
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}])
TIVDM1
Introduction, Development Process and Overture
43
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>
TIVDM1
Introduction, Development Process and Overture
44
BNF for ”Simple” 2
-- 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>
TIVDM1
Introduction, Development Process and Overture
45
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>
TIVDM1
Introduction, Development Process and Overture
46
BNF for ”Simple” 4
<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
TIVDM1
Introduction, Development Process and Overture
47
BNF for ”Simple” 5
<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>
TIVDM1
Introduction, Development Process and Overture
48
BNF for ”Simple” 6
<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> ]
TIVDM1
Introduction, Development Process and Overture
49
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
TIVDM1
Introduction, Development Process and Overture
50
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
TIVDM1
Introduction, Development Process and Overture
51
Agenda





•
TIVDM1
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
Introduction, Development Process and Overture
52
Steps to Develop a Formal Model
1.
2.
3.
4.
Determine the purpose of the model.
Read the requirements.
Analyze the functional behavior from the requirements.
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.
TIVDM1
Introduction, Development Process and Overture
53
A Chemical Plant
alarm
TIVDM1
expert
Introduction, Development Process and Overture
54
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.
TIVDM1
Introduction, Development Process and Overture
55
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.
TIVDM1
Introduction, Development Process and Overture
56
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)
TIVDM1
Introduction, Development Process and Overture
57
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.
TIVDM1
Introduction, Development Process and Overture
58
Sketching an Alarm
Defined as a VDM++ class:
class Alarm
instance variables
reqQuali: Expert`Qualification
descr
: String;
end Alarm
TIVDM1
Introduction, Development Process and Overture
59
Alternative Alarm
Alarm could also have been defined as a composite
type:
Alarm :: reqQuali : Expert`Qualification
descr
: String
Then if a is of type Alarm:
a.descr is the description of a
a.descr : String
a.reqQuali : Expert`Qualification
TIVDM1
Introduction, Development Process and Overture
60
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.
TIVDM1
Introduction, Development Process and Overture
61
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.
TIVDM1
Introduction, Development Process and Overture
62
Initial Class Diagram
class Plant
instance variables
public alarms
: set of Alarm;
public schedule : map Period to set of Expert;
end Plant
TIVDM1
Introduction, Development Process and Overture
63
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 Expert
instance variables
private quali: set of Qualification;
end Expert
class Alarm
instance variables
private descr
: String;
private reqQuali: Qualification;
end Alarm
TIVDM1
Introduction, Development Process and Overture
64
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 Plant
types
Period = token;
end Plant
Tokens are useful for abstract models where unspecified
values are to be used.
TIVDM1
Introduction, Development Process and Overture
65
Adding Quantification and String
class Expert
types
Qualification = <Mech> | <Chem> | <Bio> | <Elec>
end Expert
class Alarm
types
public String = seq of char;
instance variables
descr
: String;
reqQuali : Expert`Qualification;
end Alarm
TIVDM1
Introduction, Development Process and Overture
66
Guideline 8
Think carefully about the parameter types and the result
type as this often helps to identify missing connections
in the class diagram.
TIVDM1
Introduction, Development Process and Overture
67
Updated UML Class Diagram
TIVDM1
Introduction, Development Process and Overture
68
Guideline 9
Document important properties or constraints as
invariants.
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
TIVDM1
Introduction, Development Process and Overture
69
Guideline 10
When there are several alternative ways of performing
some functionality, use an implicit definition so that
subsequent development work is not biased.
ExpertToPage: Alarm * Period ==> Expert
ExpertToPage(a, p) ==
is not yet specified
pre a in set alarms and
p in set dom schedule
post let expert = RESULT
in
expert in set schedule(p) and
a.GetReqQuali() in set expert.GetQuali();
TIVDM1
Introduction, Development Process and Overture
70
Will the Qualification exist?
• How can we be sure that an expert with the required
qualification exists in the required period?
• We need to add an invariant to the instance variables
of the Plant class
• That is using guideline 11
TIVDM1
Introduction, Development Process and Overture
71
Guideline 11
When defining operations, try to identify additional
invariants.
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();
TIVDM1
Introduction, Development Process and Overture
72
Further Operations inside Plant
class Plant
operations
…
public NumberOfExperts: Period ==> nat
NumberOfExperts(p) ==
return card schedule(p)
pre p in set dom schedule;
public ExpertIsOnDuty: Expert ==> set of Period
ExpertIsOnDuty(ex) ==
return {p | p in set dom schedule &
ex in set schedule(p)};
end Plant
TIVDM1
Introduction, Development Process and Overture
73
Guideline 12
Try to make explicit operation definitions precise and clear
and yet abstract compared to code written in a
programming language.
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;
}
}
TIVDM1
Introduction, Development Process and Overture
74
Final UML Class Diagram
TIVDM1
Introduction, Development Process and Overture
75
Guideline 13
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.
functions
PlantInv: set of Alarm * map Period to set of Expert ->
bool
PlantInv(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());
TIVDM1
Introduction, Development Process and Overture
76
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);
end Plant
TIVDM1
Introduction, Development Process and Overture
77
Review Requirements (1)
R1: A computer-based system managing this plant is to
be developed.
Considered in the Plant class definition and the
operation and function definitions.
R2: Four kinds of qualifications are needed to cope
with the alarms: electrical, mechanical, biological,
and chemical.
Considered in the Qualification type definition
of the Expert class.
R3: There must be experts on duty at all times during
all periods which have been allocated in the system.
Invariant on the instance variables of class Plant.
TIVDM1
Introduction, Development Process and Overture
78
Review Requirements (2)
R4: Each expert can have a list of qualifications.
Assumption: non-empty set instead of list in class
Expert.
R5: Each alarm reported to the system must have a
qualification associated with it and a description which
can be understood by the expert.
Considered in the instance variables of the Alarm
class definition assuming that it is precisely one
qualification.
R6: Whenever an alarm is received by the system an
expert with the right qualification should be paged.
The ExpertToPage operation with additional invariant
on the instance variables of the Plant class definition.
TIVDM1
Introduction, Development Process and Overture
79
Review the Requirements (3)
R7: The experts should be able to use the system
database to check when they will be on duty.
The ExpertOnDuty operation.
R8: It must be possible to assess the number of
experts on duty.
The NumberOfExperts with assumption for a
given period.
TIVDM1
Introduction, Development Process and Overture
80
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...
TIVDM1
Introduction, Development Process and Overture
81
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?
TIVDM1
Introduction, Development Process and Overture
82
Agenda






TIVDM1
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
Introduction, Development Process and Overture
83
Changing
perspective
Overture Perspective
VDM Editors
Project explorer
with VDM model
files
Outline of VDM
model
Errors and
warnings
TIVDM1
Introduction, Development Process and Overture
84
84
Debug Perspective
Call traces in
debug
Inspecting
variables
Editor
Outline
Interactive
console
TIVDM1
Introduction, Development Process and Overture
85
85
Combinatorial Testing Perspective
Overview of
results
Regular
expression
Detailed test case
and results
TIVDM1
Introduction, Development Process and Overture
86
Proof Obligation Perspective
Proof obligation view
(let expert:Expert = RESULT in
p in set dom schedule)
TIVDM1
Introduction, Development Process and Overture
87
87
Real-Time Log View
TIVDM1
Introduction, Development Process and Overture
88
88
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
TIVDM1
Introduction, Development Process and Overture
89
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
TIVDM1
Introduction, Development Process and Overture
90
Quote of the day
Abstraction, difficult as it is, is the
source of practical power.
Bertrand Russell
(1872 - 1970)
TIVDM1
Introduction, Development Process and Overture
91