ECSE 6780- Software Engineering 1I - 1 - HO 3 © HY 2012 Lecture 3 Formal Methods through an...

29
ECSE 6780- Software Engineering 1I - 1 - HO 3 © HY 2012 Lecture 3 Formal Methods through an Introduction to Formal Methods A notation for formal specification of systems and a formal tool for precise design of software Z (pronounced Zed), uses mostly familiar mathematical notation and properties to precisely specify the system under description

Transcript of ECSE 6780- Software Engineering 1I - 1 - HO 3 © HY 2012 Lecture 3 Formal Methods through an...

ECSE 6780- Software Engineering 1I

- 1 -HO 3

© HY 2012

Lecture 3

Formal Methods through an Introduction to Z

Formal Methods

A notation for formal specification of systems and a formal tool for

precise design of software

Z (pronounced Zed), uses mostly familiar mathematical notation and properties to

precisely specify the system under description

ECSE 6780- Software Engineering 1I

- 2 -HO 3

© HY 2012

Lecture 3

Formal Methods

Formal Methods (in the plural), is a collective term applied to mathematical methods and techniques used to specify, design and verify systems. Their use has been prevalent in software and complex electronic hardware development.

A formal method (in the singular), is a coherent set of such mathematical techniques and notations used as a methodology to specify, design and/or verify a system. Zed is one such formal method.

ECSE 6780- Software Engineering 1I

- 3 -HO 3

© HY 2012

Lecture 3

Formal MethodsFormal Methods come under multiple scopes and uses:

Level 0: Formal Specification. This is when mathematical rigor is used to only specify the requirements of a system

Level 1: Formal Specification and Derivation. This is when mathematical rigor is used to not only specify a system but also used that specification to derive mathematically, that is, translate the specification to a program

Level 2: Fully Formal. This is when the derivation (as per a level 1 method) is proven for correctness against the original specification.

ECSE 6780- Software Engineering 1I

- 4 -HO 3

© HY 2012

Lecture 3

Formal Methods

Formal methods may be grouped into three general categories:

Axiomatic Methods: where the system is specified in terms of state changes defined in terms of pre- and post-conditions, variants and invariants. Propositional and predicate logic are an important feature of such methods. Z belongs to this category.

Operational Methods: where the operation of the system is formally specified as a sequence of operations.

Denotational Methods: where the system is specified using domain theory.

ECSE 6780- Software Engineering 1I

- 5 -HO 3

© HY 2012

Lecture 3

Z Specification

As all other formal methods, Z uses the powerful notion of abstraction.

Z specifies a system using:

Mathematically defined data types

and

Decompositions called Schemas

ECSE 6780- Software Engineering 1I

- 6 -HO 3

© HY 2012

Lecture 3

Z Specification

A schema describes both the static and the dynamic aspects of a system.

StaticIndividual states

Invariants maintained

DynamicState Transitions

Events (operations)Transformations

(relationship of input to output)

ECSE 6780- Software Engineering 1I

- 7 -HO 3

© HY 2012

Lecture 3

Z Specification

The Z language also allows us to combine and relate separately defined schemas in a mathematically logical fashion.

Z also permits a progression of decomposition. We can construct a progression of related specifications that eventually arrives at the API or the equivalent of the API of an implementation façade.

ECSE 6780- Software Engineering 1I

- 8 -HO 3

© HY 2012

Lecture 3

Z SpecificationTo learn how to speak any language, we first need to learn some vocabulary and some simple rules of grammar. Both the vocabulary and the grammar of Z should be largely familiar to you. Over the next few pages, we will cover some of these (without necessarily going into the details and subtleties of their definitions and uses).

Some of these symbols and concepts are unique to Z but most are in general use elsewhere in mathematics.

In this treatment we use the ObjectZ dialect of Z, one that allows for the notion of class, inheritance and a few other OO “nice to have”s.

ECSE 6780- Software Engineering 1I

- 9 -HO 3

© HY 2012

Lecture 3

Sets and Types

[X] Type X data type ::=m1|m2|…..|mn

X = = Y Y stands for X Z Set of Integers

N Set of natural numbers (0)

N1 Set of positive integers (1)

t S t is an element of set S

t S t is not an element of set S

S T S is contained in T

Z Specification

ECSE 6780- Software Engineering 1I

- 10 -HO 3

© HY 2012

Lecture 3

ST S is strictly contained in T (ST)

S T S is not contained in T

S T Set of intersection of S and T

S T Set of the union of S and T

PS Powerset of S: the set of all subsets of S

FS Finite powerset of S: the set of all finite subsets of S

SS The distributed intersection of all sets in SS

SS The distributed union of all sets in SS

Or { } The null or empty set

Z Specification

ECSE 6780- Software Engineering 1I

- 11 -HO 3

© HY 2012

Lecture 3

S\T Difference: elements that are in S but not in T

#S Size or cardinality: number of elements in S

{D|p.t} Set of t’s such that given declaration D, P holds

disjoint Sq the sets in the sequence sq are disjoint

sq partition S the sets in sq partition the set S

Logic

true, false logical constants

P not P

Z Specification

ECSE 6780- Software Engineering 1I

- 12 -HO 3

© HY 2012

Lecture 3

PQ conjunction: “P and Q”

PQ disjunction: “P or Q”

PQ implication: “If P then Q”

PQ equivalence: : “If P then Q and if Q then P”

t=r term t is equal to term r

tr term t is not equal to term r, that is: (t=r)

Predicates:

x:T.P for all x of type T, P holds

x: T.P there exists an x of type T, for which P holds

Z Specification

ECSE 6780- Software Engineering 1I

- 13 -HO 3

© HY 2012

Lecture 3

Relations:

XY the set of ordered pairs of X’s and Y’s

XY the set of relations from X to Y; = =P(XY)

x R y x is related to y by R; (x,y) R

dom R the domain of relation R; = ={x:X | (x:X . x R y) . x}

ran R the range of a relation R; = ={y:Y | (x:X . x R y) . y}

SR the relation R is domain restricted to S

RS the relation R is range restricted to S

R~ the inverse of R

Z Specification

ECSE 6780- Software Engineering 1I

- 14 -HO 3

© HY 2012

Lecture 3

Functions:

X Y the set of partial functions from X to Y

= ={f:XY | (x:X | x dom f. (1y:Y.x f y))}

X Y the set of total functions from X to Y

= ={f: X Y| dom f = X.f}

fx or f(x) function f is applied to x

Z Specification

ECSE 6780- Software Engineering 1I

- 15 -HO 3

© HY 2012

Lecture 3

Sequences:

seq X the set of sequences with elements drawn from X

= ={S:N X | dom S= 1…#S}

seq1 X set of non-empty sequences of X

iseq X set of non-duplicate sequences of X

#S the length of sequence X

< > the empty sequence

<x1,…xn> the sequence of x1 through to xn

Z Specification

ECSE 6780- Software Engineering 1I

- 16 -HO 3

© HY 2012

Lecture 3

<x1,…xn>^<y1,…yn> concatenation

= = <x1,…xn,y1,…yn>

head S = = S 1

last S = = S #S

tail S^S1 = = S

frontS^<x> = = S where <x>= =last S

rev S the sequence S in reverse order

Z Specification

ECSE 6780- Software Engineering 1I

- 17 -HO 3

© HY 2012

Lecture 3

Schemas:

Class Schema:

Class Name[generic parameter]inherited classes

type definitions

constant definitions

state schema

initial state schema

operation schemas

history invariant

Z Specification

ECSE 6780- Software Engineering 1I

- 18 -HO 3

© HY 2012

Lecture 3

State Schema

items: seq T

#items max

declaration predicate

Z Specification

ECSE 6780- Software Engineering 1I

- 19 -HO 3

© HY 2012

Lecture 3

items = = < >

Initial State Schema:

INIT

Operational schemas

declarations

predicates

Operation name

Z Specification

ECSE 6780- Software Engineering 1I

- 20 -HO 3

© HY 2012

Lecture 3

Schema decorations:

| name: T name is a constant of type T

item ?: T item is an input or accepts input

item !: T item is an output or holds an output

item’ new state of item after change

(item) the schema effects change on item

(item) item is left unchanged by schema

Z Specification

Ξ

ECSE 6780- Software Engineering 1I

- 21 -HO 3

© HY 2012

Lecture 3

Z SpecificationA simple case example will help bring these concepts together

We will develop a specification for a very simple library management system. In this

system, each book will be assigned to a shelf location, designated by a number. A shelf location of course may house many books.

ECSE 6780- Software Engineering 1I

- 22 -HO 3

© HY 2012

Lecture 3

A Library System

We introduce the types we need: [BOOK], [SHELF]

We do not for the moment specify what exact type the book variable would be. The book may be identified by an alphanumeric string, such as by the book title; alphabetic, such as by author’s name; numeric, such as by ISBN, etc. It does not matter for the moment.

The shelf we decide is simply numbered from 1 to whatever.

[SHELF], SHELF ::=N1

ECSE 6780- Software Engineering 1I

- 23 -HO 3

© HY 2012

Lecture 3

A Library SystemSo now we can think of an ordered pair of [BOOK,SHELF] which is generic in with respect to BOOK and specified wrt SHELF. This renders the whole ordered pair structure generic, in that it would have to be set to a type (book has to be set to a type) before it can be instantiated.

Now we can create a simple class, let us call it Library. We do so by creating a class schema:

Libraryonshelf : P BOOKlocation: BOOK SHELF

onshelf =dom location

ECSE 6780- Software Engineering 1I

- 24 -HO 3

© HY 2012

Lecture 3

A Library System

Note that we have not placed a limit on the number of records that may be stored nor the order in which they are to be stored.

Because location is in a functional relationship with onshelf, there will always be only one location for a book but many books may be placed on the same shelf.

But what can this simple system do? How about adding a book/location pair?

ECSE 6780- Software Engineering 1I

- 25 -HO 3

© HY 2012

Lecture 3

A Library System

Library

abook? onshelflocation’ = location {abook? aspot?}

abook?: BOOKaspot? : SHELF

AddtoLibrary

We have read two variables abook and aspot and

ECSE 6780- Software Engineering 1I

- 26 -HO 3

© HY 2012

Lecture 3

A Library SystemA bit of proof (you probably don’t need to do this but it is a good simple demonstration

of the proof capability of Z):

Prove that onshelf’ = onshelf {abook?}

Proof:onshelf’ = dom location’ [by invariant after]

= dom (location {abook? aspot?} [Spec of AddtoLibrary]

= dom location dom{abook? aspot?} [fact about dom]

= dom location {abook?} [fact about functions]

= onshelf {abook?} [invariant before}

ECSE 6780- Software Engineering 1I

- 27 -HO 3

© HY 2012

Lecture 3

A Library System

Let’s add another operation:

Add an operation that given the name of a book, it finds its shelf

Ξ Library

abook? onshelfaspot! = location(abook?)

abook?: BOOKaspot! : SHELF

FindLocation

ECSE 6780- Software Engineering 1I

- 28 -HO 3

© HY 2012

Lecture 3

A Library System

The new symbol Ξ indicates that the operation FindLocation has induced no change of state. It is in this sense mathematically equivalent to:

(onshelf’ = onshelf) (location’ = location)

Which due to rules of precedence of symbols may be written as:

(onshelf’ = onshelf) (location’ = location)

ECSE 6780- Software Engineering 1I

- 29 -HO 3

© HY 2012

Lecture 3

A Library System

Another operation may be to find the contents of a shelf. That is, given the number of the shelf, find out what books are on that shelf.

Ξ Library

ashelf? dom locationbooks! = {n: onshelf | location(n) = ashelf?}

ashelf?: SHELFbooks! : BOOK

ShelfContents