tivdm1introduction and development process1 peter gorm larsen

72
TIVDM1 Introduction and Development Process 1 Introduction and Development Process Peter Gorm Larsen

Upload: priscilla-walsh

Post on 02-Jan-2016

230 views

Category:

Documents


3 download

TRANSCRIPT

Page 1: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 1

Introduction and Development Process

Peter Gorm Larsen

Page 2: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 2

Agenda

Administrative information about the course• What are VDM models and how are they validated?• Suggested Projects to undertake• The Process using the VDM++ and UML combination

Page 3: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 3

Who is the teacher?

• Peter Gorm Larsen; MSc, PhD• 18 years of professional experience

• ½ year with Technical University of Denmark• 13 years with IFAD• 3,5 years with Systematic• 3/4 year with University College of Aarhus

• Consultant for most large defence contractors on large complex projects (e.g. JSF)

• Relations to industry and academia all over the world• Has written books and articles about VDM• See http://home0.inet.tele.dk/pgl/peter.htm for details

Page 4: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 4

• The most convenient way - email

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

Contacting Details

Page 5: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 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 http://www.vdmbook.com/tools.php

• Setup.exe files and documentation can also be found under K:\from eit_staff to eit_stud\PGL

• Rational Rose for UML models to be requested from K:\from eit_staff to eit_stud\PGL

• Run hostinfo.exe and send me the host name and hostid such that I can generate a license file for you

Page 6: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 6

• 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

Page 7: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 7

• Confrontation with the teacher• Tuesdays 14:30 – 15:45 in Room 424• Thursdays 13:00 – 15:45 in Room 424• 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 VDMTools for projects

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

evaluation on the 7th of June 2006• Oral examination will be centered around projects performed• Projects will be reused and extended further in TIVDM2

Education Form

Page 8: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 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• Toy examples• Concurrency• Real-time requirements• Implementation

Page 9: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 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

Page 10: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 10

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)• …

Page 11: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 11

Industrially Inspired Examples

• Chemical Plant Alarm Management System

• A Robot Controller• A Road Congestion Warning System

Page 12: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 12

Structure of the course

1. Introduction and development process (chap 1+2)

2. VDMTools and logic (chap 3)

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

Page 13: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 13

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

Page 14: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 14

Agenda

Administrative information about the course What are VDM models and how are they validated?• Suggested Projects to undertake• The Process using the VDM++ and UML combination

Page 15: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 15

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• Functional specification:

• Referentially transparent functions• Operations with side effects on state variables • Implicit specification (pre/post)• Explicit specification (functional or imperative)

Page 16: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 16

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.

Page 17: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 17

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.

Page 18: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 18

Agenda

Administrative information about the course What are VDM models and how are they validated? Suggested Projects to undertake• The Process using the VDM++ and UML combination

Page 19: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 19

Possible projects

1. SAFER

2. Production Cell

3. Cash Dispenser

4. CyberRail

5. Conveyor belt from “Automation BSc course”

6. Projects from “Distributed Real-Time Systems”

7. Projects from “Specification of IT Systems”

8. Suggest your own project

Page 20: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 20

SAFER Overview

Page 21: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 21

SAFER References

• Simplified Aid For EVA Rescue• Presentation about mishap for SAFER• A 25 pages description of the system• Modelling SAFER using VDM-SL• Article about the SAFER VDM-SL model• VDM-SL + Mathematica simulation• Another CORBA interface to the VDM-SL model• A VDM++ model of SAFER• Article about the VDM++ model of SAFER

Page 22: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 22

Production Cell Overview

Page 23: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 23

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

Page 24: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 24

Cash Dispenser Overview

Page 25: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 25

The Cash Dispenser Model

• Model of a system of tills and a central resource.• Customers interact with tills by inserting a card and

entering a PIN• Central resources contains detailed records of

customers’ bank accounts• “Illegal” cards are kept by the till.

Page 26: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 26

A Cash Dispenser Example

TillsTillsCentral Central RepositoryRepository

Page 27: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 27

Requirement Specification

There are many tills which can access a central resource containing the detailed records of customers’ bank accounts. A till is used by inserting a card and typing in a PIN (Personal Identification Number) which is encoded by the till and compared with a code stored on the card. After successfully identifying themselves to the system, customers may try to:

1. view the balance of their accounts2. make a withdrawal of cash3. ask for a statement of their account to be sent by post.

Information on accounts is held in a central database and may be unavailable. In that case 1) above may not be possible. If the database is available, any amount up to the total in the account may be withdrawn, subject to a fixed daily limit on withdrawals. This means that the amount withdrawn within the day must be stored on the card. “Illegal” cards are kept by the till.

Page 28: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 28

Development Process

• Analysis (using VDM-SL with API animation)

• alternative to use cases

• abstraction from multiple tills• Design (using Rose VDM++ Link with systematic

testing and API animation)

• abstraction from possible failures of tills• Implementation (with concurrent VDM++ model and

automatic Java code generation combined with user interface)

Page 29: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 29

Letter

date : Clock`Date

name : Cardholder`Name

address : Cardholder`Address

balance : nat

transactions : seq of Account`Transaction

Create()

Card

code : Code

cardId : CardId

accountId : Account`AccountId

GetCode()

GetCardId()

GetAccountId()

Create()

Cardholder

name : Name

address : Address

Create()GetName()

GetAddress()

Clock

date : Date

GetDate()

SetDate()

Letterbox

PostStatement()

GetLastStatement()

0..*-statements 0..*

{ordered}

Till

cardOk : bool = false

Create()

Validate()CardInside()

GetBalance()

InsertCard()

ReturnCard()

IsLegalCard()

CardValidated()

MakeWithdrawal()

RequestStatement()

Encode()

0..1

-curCard

0..1 0..*-retainedCards0..*

Account

balance : nat

transactions : seq of Transaction = []

dailyLimit : nat = 2000

Create()

AddCard()

GetBalance()GetCardIds()

Withdrawal()

MakeStatement()

ValidTransaction()

Sum()

TransactionsInvariant()

DateTotal()

Card`CardId

-cards

Card`CardId

CentralResource

illegalCards : set of Card`CardId = {}

numberOfTries : map Card`CardId to nat = {|->}

maxNumberOfTries : nat = 3

Create()AddAccount()

GetBalance()

Withdrawal()

IsLegalCard()

PostStatement()

AddIllegalCard()

IncrNumberOfTries()

ResetNumberOfTries()

NumberOfTriesExceeded()

-clock

-letterbox-resource

Account`AccountId

-accounts

Account`AccountId

UML Class Diagram

Page 30: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 30

Cash Dispenser References

• The Cash Dispenser Example at different abstraction levels

• The VDM++ non-concurrent version of the Cash Dispenser model

• The VDM++ Concurrency version of the Cash Dispenser model

Page 31: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 31

CyberRail Overview

Page 32: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 32

CyberRail References

• The CyberRail web page• CyberRail, Concept and Future• CyberRail articles from web page

Page 33: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 33

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

Photoelectric sensor

LE1

Photoelectric sensor

LE1

Page 34: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 34

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

Page 35: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 35

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}])

Page 36: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 36

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

Page 37: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 37

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

Page 38: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 38

Agenda

Administrative information about the course What are VDM models and how are they validated? Suggested Projects to undertake The Process using the VDM++ and UML combination

Page 39: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 39

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.

Page 40: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 40

A Chemical Plant

alarmalarmexpertexpert

Page 41: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 41

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.

Page 42: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 42

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.

Page 43: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 43

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)

Page 44: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 44

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.

Page 45: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 45

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

Page 46: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 46

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

Page 47: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 47

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.

Page 48: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 48

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.

Page 49: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 49

Initial Class Diagram

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

end Plant

Page 50: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 50

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

Page 51: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 51

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.

Page 52: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 52

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

Page 53: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 53

Guideline 8

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

in the class diagram.

Page 54: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 54

Updated UML Class Diagram

Page 55: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 55

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.

Page 56: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 56

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.

Page 57: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 57

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

Page 58: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 58

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.

Page 59: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 59

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

Page 60: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 60

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.

Page 61: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 61

Final UML Class Diagram

Page 62: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 62

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.

Page 63: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 63

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

Page 64: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 64

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.

Page 65: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 65

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.

Page 66: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 66

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.

Page 67: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 67

Testing The Model

• Examine the file Test.rtf using MS Word. This is a test driver class.

• Start up VDMTools with the project alarm.prj.• Go to the Project configuration menu (found at

Project->Configure) and add the files Test.rtf, Plan.rtf, Expert.rtf and Alarm.rtf

• Syntax and type check the entire project.• Start up the interpreter and initialize the model.

You are now ready to test and debug your model...

Page 68: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 68

Executing the model

• In the interpreter window, at the vdm> prompt, create a test driver object named t using the create command:

create t := new Test()• Now call t’s Main operation using the print command

print t.Main()• Since this yields a reference to a Plant object, we

can use the result for testing. For instance

print t.Main().NumberOfExperts( mk_token("Monday day"))

Page 69: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 69

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?

Page 70: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 70

Potential for using CORBA API

• VDMTools has a CORBA API that can be used for example to make a GUI for other stakeholders

• Easy validation of understanding at early stages

Page 71: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 71

Summary

• What have I presented today?• Administrative information about the course

• 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

• Get VDMTools installed and start looking at the manuals

• Get Rational Rose installed and run hostinfo and send email

• Form groups for the projects

• Select the project to work on

Page 72: TIVDM1Introduction and Development Process1 Peter Gorm Larsen

TIVDM1 Introduction and Development Process 72

Quote of the day

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

Bertrand Russell

(1872 - 1970)