Introduction, Development Process and Introduction to Overture

1
Introduction, Development Process and
Introduction to Overture

• Peter Gorm Larsen
• (pgl_at_iha.dk)

2
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

3
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

4
Contacting Details

• The most convenient way - email
• pgl_at_iha.dk
• Or see me in my office. I live in at IHA in Room
  423b.

5
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/p
  rojects/overture/)
• Possibly also VDMTools but that is not certain
• Also possible to use Enterprise Architect (using
  30 days free trial)

6
VDM Examples

• Existing examples can be imported in Overture if
  one downloads from https//sourceforge.net/project
  s/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

7
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

8
Education Form

• Confrontation with the teacher
• Thursdays 800 1600 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

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

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

13
Industrially Inspired Examples

• Chemical Plant Alarm Management System
• A Robot Controller
• A Road Congestion Warning System

14
Structure of the course

1. Introduction, Overture and the development
   process (chap 12 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
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)...

16
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

17
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
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

19
Adelard Metrics

• 31 faults in Prolog and C (lt 1/kloc)
• Most minor, only 1 safety-related
• 1 (small) design error, rest in coding

20
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

21
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

22
DoD, NL Metrics (1)

• Estimated 12 C loc/h with manual coding!

23
DoD - Comparative Metrics
24
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.

25
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
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.
27
TradeOne Cost Effectiveness
Subsystem COCOMO estimate Real time Time saving
Tax exemption Effort38.5 PM Schedule9M
Options Effort147.2 PM Schedule14.3M
Effort14 PM Schedule 3.5 M
Effort74 Schedule61
Effort 60 Schedule 51
Effort 60.1 PM Schedule7M
28
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
29
Specification and Implementation Growth
kLOC
Specification v.1.0
140
Implementation
100
Specification
70
?????0.9
The average productivity of VDM code for the
formal specifications was about 1,900 LOC per
engineer per month.
0
2004/7
2006/4
Specification Phase
Implementation Phase
30
Number of Changes
Specification v.1.0
50
?????0.9
Number of Changes
0
2004/7
2006/4
Specification Phase
Implementation Phase
31
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

32
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
VDM-SL Module Outline
module ltmodule-namegt definitions en
d ltmodule-namegt
imports exports ...
Interface
state types values functions operations ...
Definitions
34
VDM Class Outline
class ltclass-namegt end
ltclass-namegt
instance variables ...
Internal object state
types values functions operations
Definitions
thread ...
Dynamic behaviour
sync ...
Synchronization control
traces ...
Test automation support
35
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.

36
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
Interface
Interpreter
Testing can increase confidence, but is only as
good as the test set. Exhaustive techniques could
give greater confidence.
37
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

38
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 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

39
Production Cell Overview
40
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

41
Conveyor belt
42
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 by bar code reader

43
System-level functionality in VDM-SL

• types
• Stream seq of Brick
• Brick
• code Code
• color ltRedgt ltGreengt ltYellowgt
• Code token
• functions
• ConveyorBelt Stream Code Code -gt 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
BNF for Simple 1

• ltspecificationgt ltdefinitiongt
• ltdefinitiongt lttype definitiongt ltfunction
  definitiongt
• lttype definitiongt ltidentifiergt lttypegt
• ltidentifiergt a VDM-10 Unicode name
• lttypegt real int nat bool ltidentifiergt
• ltfunction definitiongt
• ltidentifiergt ( ltparametergt , ltparametergt )
  ltexpressiongt
• ltparametergt ltidentifiergt lttypegt

45
BNF for Simple 2

• -- Note that the expression operator precedence
  and associativity
• -- is expressed in the recursive structure of the
  grammar
• ltexpressiongt ltequivalent expressiongt
• -- The least binding operators are
  right-associative...
• ltequivalent expressiongt ltimplies expressiongt
  ltgt ltequivalent expressiongt
• ltimplies expressiongt ltor expressiongt gt
  ltimplies expressiongt
• ltor expressiongt ltand expressiongt or ltor
  expressiongt
• ltand expressiongt ltnot expressiongt and ltand
  expressiongt
• ltnot expressiongt ltrelational expressiongt
  not ltnot expressiongt

46
BNF for Simple 3

• ltrelational expressiongt
• ltplus minus expressiongt ltrelopgt ltnot
  expressiongt
• ltrelopgt lt lt gt gt ltgt
• -- The arithmetic operators are
  left-associative...
• ltplus minus expressiongt
• ltplus minus expressiongt ltmult div expressiongt
  
• ltplus minus expressiongt - ltmult div expressiongt
  
• ltmult div expressiongt
• ltmult div expressiongt
• ltmult div expressiongt ltunary expressiongt
• ltmult div expressiongt / ltunary expressiongt
• ltmult div expressiongt mod ltunary expressiongt
• ltmult div expressiongt rem ltunary expressiongt
• ltmult div expressiongt div ltunary expressiongt
• ltunary expressiongt

47
BNF for Simple 4

• ltunary expressiongt
• ltapplication expressiongt ltunaryopgt ltunary
  expressiongt
• ltunaryopgt -
• ltapplication expressiongt
• ltbasic expressiongt
• ltbasic expressiongt ( ltexpressiongt ,
  ltexpressiongt )
• ltbasic expressiongt
• ( ltexpressiongt )
• ltlet expressiongt
• ltcases expressiongt
• ltif expressiongt
• ltinteger literalgt
• ltreal literalgt
• ltidentifiergt
• true
• false

48
BNF for Simple 5

• ltlet expressiongt
• let ltlocal definitiongt , ltlocal definitiongt
  in ltexpressiongt
• ltlocal definitiongt ltidentifiergt
  ltexpressiongt
• ltcases expressiongt
• cases ltexpressiongt
• ltcase alternativegt , ltcase alternativegt
• , ltothersgt
• end
• ltcase alternativegt ltexpressiongt -gt
  ltexpressiongt
• ltothersgt others -gt ltexpressiongt

49
BNF for Simple 6

• ltif expressiongt
• if ltexpressiongt then ltexpressiongt
• elseif ltexpressiongt then ltexpressiongt
• else ltexpressiongt
• ltinteger literalgt ltdigitgt digit
• ltdigitgt 0 1 2 3 4 5 6 7 8 9
• ltreal literalgt
• ltinteger literalgt . ltinteger literalgt e
  - ltinteger literalgt

50
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

51
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 45 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

52
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

53
Steps to Develop a Formal Model

• 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.
• 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.
• Sketch out signatures for the operations. Again,
  check the model's consistency in VDM.
• Complete the class (and data type) definitions by
  determining potential invariant properties from
  the requirements and formalizing them.
• Complete the operation definitions by determining
  pre- and post conditions and operation bodies,
  modifying the type definitions if necessary.
• Validate the specification using systematic
  testing and rapid prototyping.
• Implement the model using automatic code
  generation or manual coding.

54
A Chemical Plant
alarm
expert
55
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.

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

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

59
Sketching an Alarm
Defined as a VDM class
class Alarm instance variables reqQuali
ExpertQualification descr String end Alarm
60
Alternative Alarm
Alarm could also have been defined as a composite
type
Alarm reqQuali ExpertQualification
descr String
Then if a is of type Alarm
a.descr is the description of a a.descr
String a.reqQuali ExpertQualification
61
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
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.
63
Initial Class Diagram

• class Plant
• instance variables
• public alarms set of Alarm
• public schedule map Period to set of Expert
• end Plant

64
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
65
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.
66
Adding Quantification and String

• class Expert
• types
• Qualification ltMechgt ltChemgt ltBiogt
  ltElecgt
• end Expert
• class Alarm
• types
• public String seq of char
• instance variables
• descr String
• reqQuali ExpertQualification
• end Alarm

67
Guideline 8

• Think carefully about the parameter types and the
  result type as this often helps to identify
  missing connections in the class diagram.

68
Updated UML Class Diagram
69
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) ltgt
  
• end Plant

70
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 gt 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()

71
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

72
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) ltgt
  
• inv forall a in set alarms
• forall p in set dom schedule
• exists expert in set schedule(p)
• a.GetReqQuali() in set
  expert.GetQuali()

73
Further Operations inside Plant

• class Plant
• operations
• public NumberOfExperts Period gt nat
• NumberOfExperts(p)
• return card schedule(p)
• pre p in set dom schedule
• public ExpertIsOnDuty Expert gt set of Period
• ExpertIsOnDuty(ex)
• return p p in set dom schedule
• ex in set schedule(p)
• end Plant

74
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

75
Final UML Class Diagram
76
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 -gt
• bool
• PlantInv(as,sch)
• (forall p in set dom sch sch(p) ltgt ) and
• (forall a in set as
• forall p in set dom sch
• exists expert in set sch(p)
• a.GetReqQuali() in set
  expert.GetQuali())

77
To be used inside Plant Constructor

• class Plant
• public Plant set of Alarm
• map Period to set of Expert gt
• Plant
• Plant(als,sch)
• ( alarms als
• schedule sch
• )
• pre PlantInv(als,sch)
• end Plant

78
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.
79
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.
80
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.
81
Testing The Model

• Examine the file Test.vdmpp. This is a test
  driver class.
• Start up Overture with the project AlarmTraces.
• Start up the debugger with different test
  arguments and debug your model...

82
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
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

84
Overture Perspective
Changing perspective
VDM Editors
Project explorer with VDM model files
Outline of VDM model
Errors and warnings
84
85
Debug Perspective
Call traces in debug
Inspecting variables
Editor
Outline
Interactive console
85
86
Combinatorial Testing Perspective
Overview of results
Regular expression
Detailed test case and results
87
Proof Obligation Perspective

• Proof obligation view
• (let expertExpert RESULT in
• p in set dom schedule)

87
88
Real-Time Log View
88
89
Exercise using Overture

• Install Overture from https//sourceforge.net/proj
  ects/overture/
• Download ExamplesPP.zip from https//sourceforge.n
  et/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

90
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

91
Quote of the day

• Abstraction, difficult as it is, is the source of
  practical power.
• Bertrand Russell
• (1872 - 1970)