Formal Methods. CS460 - Senior Design Project I (AY2004)2 Why formal methods? Informal methods are...

39
Formal Methods
  • date post

    20-Dec-2015
  • Category

    Documents

  • view

    215
  • download

    0

Transcript of Formal Methods. CS460 - Senior Design Project I (AY2004)2 Why formal methods? Informal methods are...

Formal Methods

CS460 - Senior Design Project I (AY2004) 2

Why formal methods?• Informal methods are open to interpretation and

ambiguity, and often incomplete and inconsistent.• Formal methods have some basis in mathematics and

allow us to reason about the system we are building.• They help us accurately capture our intent so that it is

precise and clear to others.• There are lots of different formal methods.• Like programming languages, each formal methods has

strengths and weaknesses.• Like programming languages, some formal methods are

tailored to a specific problem domain, e.g., real-time systems requiring a discussion of temporal semantics.

• Formal methods are used to specify aspects of the software system – behavior, data relationship, temporal semantics

CS460 - Senior Design Project I (AY2004) 3

Why aren’t they used everywhere?• Formal methods are controversial. Their advocates

claim that they can revolutionize [software] development. Their detractors think that they are impossibly difficult. Meanwhile, for most people, formal methods are so unfamiliar that it is difficult to judge the competing claims. – Anthony Hall, 1990.

• We will gain an appreciation of formal methods over the next few lectures to understand their impact on software engineering in the years to come.

CS460 - Senior Design Project I (AY2004) 4

Formal methods - limitations• Formal methods have not become mainstream software

development techniques as once predicted.– Other SE techniques have been successful at

increasing software quality, so the need to formalism has decreased.

– Economic pressures make time-to-market a key driver, rather than a low error count. Formal methods do not reduce time to market.

– Formal methods are had to scale to large software systems.

– Scope of formal methods is limited – not well suited to specifying and analyzing user interfaces and user interactions.

• Formal methods have limited practical applicability..• Principle benefit is reduction in number of errors. Main

area of applicability is critical systems.

CS460 - Senior Design Project I (AY2004) 5

Deficiencies of informal methods• Natural language (English) is an example of an informal

method.– It is often ambiguous, incomplete, insufficient, and

contains contradictions and mixed levels of abstractions.

• We often try to address these deficiencies by supplementing the natural language description with diagrams.

• These diagrams often lack structure and have similar deficiencies to natural language.

• Coupled with sloppiness in analysis and design, poor attention to detail and the lack of thorough reviews, the use of informal methods can lead to a software disaster.

CS460 - Senior Design Project I (AY2004) 6

Problems• Contradiction – sets of statements that are in variance

with each other. They are often written by different people and separated by many pages in the specification. They are therefore difficult to detect.

• Ambiguity – statements that can be interpreted in a number of ways. They usually do not appear ambiguous to the author.– The operator identity consists of the operator name

and password; the password consists of six digits. It should be displayed on the security VDU and deposited into the login file when an operator logs into the system.

– What does “it” refer to – the operator or the password?

CS460 - Senior Design Project I (AY2004) 7

Problems• Vagueness – often occurs because the spoecification

document is bulky. Achieving a high level of precision consistently is an almost impossible task.– The interface to the system used by the radar

operators should be user-friendly.– The above statement contains no useful information!

• Incompleteness – missing details such as a failure to specify what should occur in certain conditions.– The system should maintain the hourly level of the

reservoir from depth sensors in the reservoir. These values should be stored for the past six months.

– The function of the AVERAGE command is to display on a PC the average water depth for a particular sensor between two times.

– What happens if the user specifies a period greater than six months?

CS460 - Senior Design Project I (AY2004) 8

Problems• Mixed levels of abstraction – leads to difficulty in seeing

the overall functional architecture of a system.– For example, if the following statements were

intermixed:• The purpose of the system is to track the stock in

a warehouse.• When the loading clerk types in the withdraw

command he or she will communicate the order number, the identity of the item to be removed, and the quantity removed. The system will respond with a confirmation that the removal is allowable.

– This leads to a lack of clarity.

CS460 - Senior Design Project I (AY2004) 9

Elevator problem• Let us define the elevator problem as:

– We need to move n elevators between m floors.1. Each elevator has a set of m buttons, one for each

floor. These illuminate when pressed and cause the elevator to visit the corresponding floor. The illumination is cancelled when the corresponding floor is visited by the elevator

2. Each floor, except the first floor and the top floor has two buttons, one to request an up-elevator, and one to request a down-elevator. These buttons illuminate when pressed. The illumination is cancelled when an elevator visits the floor and then moves in the desired direction.

3. When an elevator has no requests, it remains at tis current floor with its doors closed.

CS460 - Senior Design Project I (AY2004) 10

Finite state machines• In each of the n elevators, there are m buttons – one for

each floor. These are called elevator buttons (EB).• One each floor there are two buttons to request an up

and down elevator. These are called floor buttons (FB).• Let EB(e, f) denote the button in elevator e that is

pressed to request floor f.• EB(e, f) can be in two states:

– EBON(e, f): Elevator Button (e, f) ON.– EBOFF(e, f): Elevator Button (e, f) OFF.

• If the button is on and the elevator arrives at floor f, then the button is turned off. If the button is off, and it is pressed, then the button comes on.

• These two events are:– EBP(e, f): Elevator Button (e, f) Pressed.– EAF(e, f): Elevator e Arrives at Floor f.

CS460 - Senior Design Project I (AY2004) 11

Finite state machines

• The state transition diagram for an elevator button is given above.

• We introduce a predicate:– V(e, f): Elevator e is Visiting floor f.

• A predicate is a boolean function.• If elevator button (e, f) is off (current state) and elevator

button (e, f) is pressed (event) and elevator e is not visiting floor f (predicate), then the button is turned on.EBOFF(e, f) ∧ EBP(e, f) ∧ ⌐V(e, f) ⇒ EBON(e, f)

EBOFF(e, f) EBON(e, f)EBP(e, f)

EAF(e, f)

CS460 - Senior Design Project I (AY2004) 12

Finite state machines• If the elevator is visiting floor f when button (e, f) is

pressed, then nothing happens.• If the elevator arrives at floor f and the button is on,

then it is turned off.EBON(e, f) ∧ EAF(e, f) ⇒ EBOFF(e, f)

• Now we consider the floor buttons.• FB(d, f) denotes the button on floor f that requests an

elevator traveling in direction d.• Each button has two states:

– FBON(d, f): Floor Button (d, f) is ON.– FBOFF(d, f): Floor Button (d, f) is OFF.

CS460 - Senior Design Project I (AY2004) 13

Finite state machines• If the button is on and an elevator arrives at floor f traveling in

direction d, then the button is turned off.• If the button is off, and it is pressed, then the button comes on.• These events are:

– FBP(d, f): Floor Button (d, f) Pressed– EAF(1..n, f): Elevator 1 or … or Elevator n Arrives at floor f.

• Note a..b to denote disjunction. We use P(a, 1..n, b) to denote:P(a, 1, b) ∨ P(a, 2, b) ∨ … ∨ P(a, n, b)

FBOFF(d, f) FBON(d, f)FBP(d, f)

EAF(1..n, f)

CS460 - Senior Design Project I (AY2004) 14

Finite state machines• We define predicate S as follows:

S(d, e, f): Elevator e is visiting floor f and the direction in which it is about to move is either up (d = U), down (d = D), or no requests are pending (d = N)

• This predicate is actually a state.• The transition rules for floor buttons is then:

FBOFF(d, f) ∧ FBP(d, f) ∧ ⌐S(d, 1..n, f) ⇒ FBON(d, f)FBON(d, f) ∧ EAF(1..n, f) ∧ S(d, 1..n, f) ⇒ FBOFF(d, f),

d=D∨U• V(e, f) can be defined in terms of S(d, e, f)

V(e, f) = S(U, e, f) ∨ S(D, e, f) ∨ S(N, e, f)

CS460 - Senior Design Project I (AY2004) 15

Finite state machines• Three elevator states can be defined:

– M(d, e, f): Elevator e is Moving in direction d (floor f is next)

– S(d, e, f): Elevator e is Stopped (d-bound) at floor f– W(e, f): Elevator e is Waiting at floor f (door closed)

• Other interesting events include:– DC(e, f): Door Closed for elevator e at floor f– ST(e, f): Sensor Triggered as elevator e nears floor f– RL: Request Logged (button pressed)

• Rules governing movement are:S(U, e, f) ∧ DC(e, f) ⇒ M(U, e, f+1)S(D, e, f) ∧ DC(e, f) ⇒ M(D, e, f-1)S(N, e, f) ∧ DC(e, f) ⇒ W(e, f)

CS460 - Senior Design Project I (AY2004) 16

Finite state machines

M(U, e, f+1) M(D, e, f)

M(D, e, f-1)M(U, e, f)

W(e, f)

S(U, e, f) S(N, e, f) S(D, e, f)

DC(e, f)ST(e, f)

ST(e, f)RL

RL

RL

DC(e, f) DC(e, f)

RL RL

CS460 - Senior Design Project I (AY2004) 17

Finite state machines• The finite state machine is more precise than a natural

language or graphical representation.• It is almost as easy to understand• It doesn’t scale well to problems with many states.• Finite state machines do not handles the concept of

time. For this one has to use an extension of finite state machines called a statechart,

CS460 - Senior Design Project I (AY2004) 18

Petri nets• A major problem with specifying concurrent systems is

dealing with timing.• The problem manifests itself in many ways:

– Synchronization– Race conditions– Deadlock

• Timing problems can be a result of poor design or implementation, which are in turn a result of poor specification.

• Petri nets are a powerful technique for sepcifying and designing systems with potential timing problems.

• Petri nets were invented by Carl Adam Petri in 1962.

CS460 - Senior Design Project I (AY2004) 19

Petri nets - introduction• A Petri net consists of 4 parts: a set of places P; a set of

transitions T; an input function I; and output function O.• The set of places P = {p1, p2, p3, p4}• The set of transitions T = {t1, t2}• The input functions for the transitions are:

– I(t1) = {p2, p4}– I(t2) = {p2}

• The output functions for the transitions are:– O(t1) = {p1}– O(t2) = {p3, p3}

p1

p4

p2

p3

t2

t1

CS460 - Senior Design Project I (AY2004) 20

Petri nets - introduction• More formally, a Petri net is a 4-tuple, C = (P, T, I, O)

• P = {p1, p2, …, pn} is a finite set of places, n ≥ 0,

• T = {t1, t2, …, tm} is a finite set of transitions, m ≥ 0 P & T are disjoint.

• I: T → P is the input function, a mapping from transitions onto bags of places.

• O: T → P is the output function, a mapping from transitions onto bags of places.

• The marking of a Petri net is the assignment of tokens to that Petri net.

CS460 - Senior Design Project I (AY2004) 21

Petri nets - introduction

• The Petri net above contains 4 tokens.• The marking can be represented by the vector (1, 2, 0, 1).• Transition t1 is enables (ready to fire) because there are

tokens in p2 and p4.• If the transition fires, 1 token is removed from p2 and p4,

and 1 token is added to p1.• Note that the number of tokens if not conserved.

p1

p4

p2

p3

t2

t1

CS460 - Senior Design Project I (AY2004) 22

Petri nets - introduction• Petri nets are nondeterministic. If more than 1 transition

could fire, one is selected arbitrarily.

• In the previous slide, both t1 and t2 are enabled. If t1 fires, the resultant marking becomes (2, 1, 0, 0).

• Formally a marking M of a Petri net C = (P, T, I, O), is a function from the set of places P to te set of non-negative integers:– M: P → (0, 1, 2, …)

• A marked Petri net is then a 5-tuple (P, T, I, O, M).

CS460 - Senior Design Project I (AY2004) 23

Petri net - introduction• An extension to a Petri net is an inhibitor arc.• A transition is enabled if there is a token on each of its

(normal) input arcs, and no token on any inhibitor input arcs.

• Transition t1 is enabled below.

p1

p4

p2

p3

t2

t1

CS460 - Senior Design Project I (AY2004) 24

Petri nets – elevator problem• There are n elevators installed in a building with m floors.

• Each floor is represented by a place, Ff, 1 ≤ f ≤ m.

• An elevator is represented by a token.

• A token in Ff denotes that an elevator is at floor f.

• Constraint– Each elevator has a set of m buttons – one for each

floor.– These are illuminated when pressed, cause the

elevator to travel to that floor, and turned off when the elevator arrives at that floor.

– Additional places are needed to model this.

• The elevator button for floor f in elevator e is denoted EBf,

e with 1 ≤ f ≤ m, 1 ≤ e ≤ n

• For the sake of simplicity we suppress the subscript e denoting the elevator.

CS460 - Senior Design Project I (AY2004) 25

Petri nets – elevator problem• A token in EBf denotes that the elevator button for floor

f is illuminated.

• Assume that EBf is not initially illuminated.

• Note that the button is illuminated the first time it is pressed and subsequent presses do nothing (until elevator arrives that the correct floor).

• Assume that the elevator is currently at floor g.

Fg

EBf is pressed

EBf

Elevator in action Ff

CS460 - Senior Design Project I (AY2004) 26

Petri nets – elevator problem• Each floor has two buttons (except the bottom and top

floors) to represent an up-elevator and a down-elevator. These buttons illuminate when pressed, and are cancelled when an elevator traveling in the right direction arrives at the floor.

• The floor buttons are represented by places FBdf and Fbu

f

• The situation when an elevator reaches floor f from floor g with one or both buttons illuminated is given by:FBu

f is pressed

FBuf

Elevator in action Ff

FBdf is pressed

FBdf Elevator in action

Ff

Fg

CS460 - Senior Design Project I (AY2004) 27

Petri nets – elevator problem• When an elevator has no requests in needs to remain

on the same floor.• This is easily achieved, • If there are no requests, no “Elevator in action” is

enabled.

CS460 - Senior Design Project I (AY2004) 28

Petri nets - properties• Petri nets have some additional useful properties.• It is possible to prove that the system has no deadlocks

or livelocks.• They can be used to perform a proof of correctness.• The system is simple and can be implemented as part of

a tool.

CS460 - Senior Design Project I (AY2004) 29

Z• Z is a popular formal specification language.• See Schach page347 for a discussion on the

pronunciation of Z (zed).• Use of Z requires knowledge of set theory, functions and

discrete mathematics, including first-order logic.• Like the earlier formal systems examined, there are

several variants of Z.• In its simplest form a Z specification consists of 4

sections:1. Given sets, data types, and constants2. State definitions3. Initial state4. Operations

• It uses standard set and logic operators: ∃, ⊃, ⇒• It uses some additional symbols such as ⊕, ↦, ⊲.

CS460 - Senior Design Project I (AY2004) 30

Z• Given sets

– A Z specification begins with a list of given sets. These are sets that need not be defined in detail.

– The names of given sets appears in brackets, e.g., [Button] to represent the set of buttons in the elevator problem.

• State definition– A Z specification consists of a number of schemata.– Each schemata consists of a group of variable

declarations and a list of predicates that constrain the values of the variables.

– A schemata S is defined as:

Sdeclarationspredicates

CS460 - Senior Design Project I (AY2004) 31

Z• For the elevator problem, there are four subsets of Button:

– floor buttons– elevator buttons– buttons (the set of all buttons in the elevator problem)– pushed (the set of buttons that have been pushed and

are therefore on).• The symbol ℙ denotes powerset (the set of all subsets of a

given set).

Button_Statefloor_button elevator_button: ℙ Buttonbuttons: ℙ Buttonpushed: ℙ Buttonfloor_button ⋂ elevator_button = ∅floor_button ⋃ elevator_button = buttons

CS460 - Senior Design Project I (AY2004) 32

Z• Initial state

– The abstract initial state describes the state of the system when it is first turned on.

– For the elevator problem the initial state is:Button_init ≘ [Button_State′ | pushed′ = ∅]

– This is a vertical schema definition (as opposed to a horizontal one).

– The initial state above tells us that when the elevator is first turned on, the set pushed is initially empty; that is, all buttons are off.

CS460 - Senior Design Project I (AY2004) 33

Z• Operations

– If a button is pushed for the first time, then that button is turned on and added to the set pushed.

– The ∆ in the first line of the schema tells us that operation changes the state of Button_State.

– The operation has one input variable, button?. The ? symbol denotes an input variable, whereas the ! symbol denotes an output variable.

Push_Button∆Button_Statebutton?: Button(button? ∈ buttons) ∧(((button? ∉ pushed) ∧ (pushed′ = pushed ∪ {button?})) ∨((button? ∈ pushed) ∧ (pushed′ = pushed)))

CS460 - Senior Design Project I (AY2004) 34

Z• The predicate part of the operation consists of a group

of preconditions that must hold before the operation is invoked, and a group of postconditions that must hold after the operation is complete.

• If the operation is invoked without the preconditions being satisfied, then unspecified (read unpredictable) results occur.

• pushed′ denotes an updated value of pushed.

CS460 - Senior Design Project I (AY2004) 35

Z• When an elevator arrives at a floor, if the corresponding

floor button is on, then it must be turned off, similarly for the corresponding elevator button.

• The symbol \ denotes set difference• The solution below is an oversimplification on that it

does not distinguish between up and down floor buttons.

Floor_Arrival∆Button_State

button?: Button(button? ∈ buttons) ∧(((button? ∈ pushed) ∧ (pushed′ = pushed \ {button?})) ∨((button? ∉ pushed) ∧ (pushed′ = pushed)))

CS460 - Senior Design Project I (AY2004) 36

Z• Z is fairly widely used and has been employed on some large

scale projects.1. Easy to find faults in Z specifications, especially during

inspections of the specification, and inspection of the design and/or code against the formal specification.

2. Need to be precise when using Z, resulting in fewer ambiguities, contradictions and omissions than an informal specification.

3. Can use Z to perform a formal proof of correctness.4. Professionals with high school math can be taught to write Z

specifications (although more mathematical sophistication is required to do the proof).

5. Use of Z decreases software cost by decreasing overall development time.

6. Natural language specifications (for the customer for example) derived from a Z specification has fewer problems than a natural language description written from scratch without a formal description to act as a guide.

CS460 - Senior Design Project I (AY2004) 37

Z, Petri nets and beyond• Z, like Petri nets, is still undergoing development. • Researchers are constantly extending Z and Petri nets to

provide greater functionality, power and flexibility.• There are temporal versions of Z which allow the predicates to

cover time dependant semantics.• There are many other formalisms including:

– Anna– Gist– VDM– CSP– Hoare axiomatics– Operational semantics– Denotational semantics– Larch– OBJ– Lotos

CS460 - Senior Design Project I (AY2004) 38

Formal methodsCost

With formal methodsWithout formal methods

Specification

Design andImplementation

Validation

Specification

Design andImplementation

Validation

CS460 - Senior Design Project I (AY2004) 39

Conclusion• Even if you don’t think formalism is needed for your

project, it often helps to think in terms of a formalism to ensure that the informal (natural language) specification you write is as clear as possible.

• Formalisms often allow us to mathematically check specific properties of the specification.

• They can sometimes be used to automatically generate parts of the software system.

• Petri nets and Z are probably the two most popular formalisms at the present.