[PPT] - Phone Bo ok Exam ple John Rushb y Com puter Science Lab o PowerPoint Presentation

SLIDE 1 Phone Bo

k

Exam ple John Rushb y Com puter Science Lab

rato

ry SRI International Menlo P a rk CA USA Phone Bo

k

1

SLIDE 2 Phone Bo

k

Exam ple Requirem ents fo r an electronic phone b

k
Phone

b

k

shall sto re the phone num b ers

f

a cit y

It

shall b e p

ssible

to retrieve a phone num b er given a nam e

It

shall b e p

ssible

to add and delete entries from the phone b

k

Phone Bo

k

2

SLIDE 3 F

rm

al Requirem ents Sp ecication Ho w do w e rep resent the phone b

k

m a them a tic ally? 1. A set

f

(nam e , num b er ) pairs. Adding and deleting entries via set addition and deletion 2. A total function (i.e., a rra y) whose dom ain is the space

f

p

ssible

nam es and whose range is the space

f

all phone num b er s. Adding and deleting entries via m

dicat

ion

f

function values 3. A pa rtial function whose dom a in is just the nam es currently in phone b

k

and whose range is the space

f

all phone num b er s. Adding and deleting entries via m

dicat

ion

f

the function dom a in and values Let's sta rt with app roach 2 Phone Bo

k

3

SLIDE 4 Sp ecifying the Bo

k
In

traditional m a them ati cal notation, w e w

uld

write: Let N : t yp e (of nam es) P : t yp e (of phone num b ers) b

k

: t yp e (of functions) [N ! P ]

Ho

w do w e indicate that w e do not have a phone num b er fo r all p

ssible

nam e s,

nly

fo r nam es

f

real p eople? Decide to use a sp ecial num b er, that could never really

ccur

in real life, e.g. 000-0000; don't have to sp ecify the value

f

this num b er w e can just give it a nam e (e.g., n )

No

w can dene an em pt y phone b

k:

em pt yb

k

: [N ! P ] n : P nm : va r N axiom : 8 nm : em pt yb

k

(nm) = n Phone Bo

k

4

SLIDE 5 Accessing an Entry N : t yp e (of nam es) P : t yp e (of phone num b er s) B : t yp e (of functions) [N ! P ] FindPhone : [B

N

! P ] nm : va r N bk : va r B axiom : FindPhone (bk ; nm) = bk (nm) Note that FindPhone is a higher-o rder function since its rst a rgum ent is a function Phone Bo

k

5

SLIDE 6 Sp ecifying Adding/Deleting an Entry N : t yp e (of nam e s) P : t yp e (of phone num b er s) B : t yp e (of functions) [N ! P ] n : N nm; x : va r N pn : va r P bk : va r B AddPhone : [B

N
P

! B ] axiom : AddPhone (bk ; nm; pn)(x) = 8 < : bk (x) if x 6= nm pn if x = nm DelPhone : [B

N

! B ] axiom : DelPhone (bk ; nm)(x) = 8 < : bk (x) if x 6= nm n if x = nm Phone Bo

k

6

SLIDE 7 PVS Notation phone_1: THEORY BEGIN N: TYPE % names P: TYPE % phone numbers B: TYPE = [N

>

P] % phone books n0: P emptybook: B emptyax: AXIOM FORALL (nm: N): emptybook(nm) = n0 FindPhone: [B, N

>

P] Findax: AXIOM FORALL (bk: B), (nm: N): FindPhone(bk, nm) = bk(nm) nm: VAR N pn: VAR P bk: VAR B AddPhone: [B, N, P

>

B] Addax: AXIOM AddPhone(bk, nm, pn) = bk WITH [(nm) := pn] DelPhone: [B, N

>

B] Delax: AXIOM DelPhone(bk, nm) = bk WITH [(nm) := n0] END phone_1 Phone Bo

k

7

SLIDE 8 Challenging the Requirem ent Sp ecication

If

y

u

add a nam e and num b er and then lo

k

it up, do y

u

get the right answ er? lem m a : FindPhone (AddPhone (bk ; nm; pn); nm) = pn

If

y

u

add an entry and then delete it, is the phone b

k

unchanged? lem m a : DelPhone (AddPhone (bk ; nm; pn); nm) = bk

Not

true unless bk (name) = n b efo rehand

Is

this what w as intended?

Should

w e m

dify

the sp ecication

f

AddPhone ?

Do

w e need a function ChangePhone ?

Should

w e allo w m ultiple num b e rs p er nam e? Phone Bo

k

8

SLIDE 9 An Aside

n

Axiom s

Supp
se

w e w ant to sepa rate the functions

f

adding and changing a num b er

T
dene

these, useful to have a p redicate Kno wn ? : [B

N

! b

l

] axiom : Kno wn ?(bk ; nm) i bk (nm) 6= n

Supp
se

w e also had axiom axiom : Kno wn ? (AddPhone (bk ; nm; pn); nm)

W

e get an inconsistency|can p rove anything

Use

axiom s

nly

where necessa ry; b est to use denitional fo rm s

f

sp ecication (gua ranteed not to intro duce inconsistencies)

PVS

m a y generate p ro

f
bligations

(TCCs) to ensure this gua rantee Phone Bo

k

9

SLIDE 10 Som e Deciencies

f

First Sp ecication 1. Our sp ecication do es not rule

ut

the p

ssibilit

y

f

som eone having a \n " phone num b er 2. W e have not allo w ed m ult iple phone num b ers p er nam e 3. Our sp ecication do es not sa y anything ab

ut

whether

r

not w e should w a rn the user if AddPhone results in the sam e num b er b eing assigned to t w

p

eople Ho w do w e rem edy these deciencies? Phone Bo

k

10

SLIDE 11 Deciency 1 Our sp ecication do es not rule

ut

the p

ssibilit

y

f

som eone having a \n " phone num b e r There a re several w a ys to

vercom

e this p roblem

Use

a \disjoint union" fo r the range t yp e

f

the phone b

k,

so that n is not an

rdina

ry num b er

Use

a \p redicate subt yp e" to identify the phone num b er s dierent to n and allo w

nly

the subt yp e in AddPhone

Use
ne
f

the

ther

rep resentations fo r the phone b

k

(e.g., pa rtial functions|requires a dierent sp ecication language)

Reconsider

requirem ent s Phone Bo

k

11

SLIDE 12 Predicate Subt yp es

Can

dene the t yp e GP

f

Go

d

Phone Num b er s: GP : t yp e = fpn : P jpn 6= n g

Then

dene AddPhone denitionally as: g p : va r GP AddPhone (bk ; nm; g p) : B = if Kno wn ?(bk ; nm) then bk else bk with [(nm):= g p] endif

Notice

the a w ed axiom w e had b efo re is no longer adm issible axiom : Kno wn ? (AddPhone (bk ; nm; pn); nm) (PVS generates the im p

ssible

p ro

f
bligation

8pn : pn 6= n )

But

the follo wing is a p rovably true Kno wn ? (AddPhone (bk ; nm; g p); nm) Phone Bo

k

12

SLIDE 13 Deciency 2

W

e have not allo w ed m ult iple phone num b ers p er nam e

The
riginal

requirem ents did not sp ecify whether this is needed

r

not

Supp
se,

after conferring with the custom er, w e decide to allo w m ult iple num b ers

Change

the range t yp e

f

the phone b

k

to a set

f

num b ers

This

solves Deciency 1 as w ell (em pt y set

f

num b ers indicates nam e not in the b

k)

Phone Bo

k

13

SLIDE 14 New Sp ecication (sets) N : t yp e (of nam es) P : t yp e (of phone num b e rs) B : t yp e (of functions) [N ! setof [P ]] nm; x : va r N em pt yb

k

(nm) : setof [P ] =

P

pn : va r P bk : va r B FindPhone (bk ; nm) : setof [P ] = bk (nm) AddPhone (bk ; nm; pn) : B = bk with [(nm):= bk (nm) [ fpng] DelPhone (bk ; nm) : B = bk with [(nm):=

P

] Phone Bo

k

14

SLIDE 15 Som e Observations

Our

sp ecication is abstract; the functions a re dened

ver

uninterp reted dom ains.

The

axiom s and denitions used here a re constructive|w e could execute them (could also use pseudo co de fo r these kinds

f

sp ecications, but w

uld

lack an assertion language fo r challenges, and the deductive appa ratus to fo rm al ly check their p ro

fs)
Other

sp ecications and rep resentations m a y involve nonconstructive axiom s e.g., set

f

pairs: FindPhone (bk ; nm) = fpnj(nm; pn) 2 bk g

And

m

re

sophisticated (not directly im plem e ntable) t yp es Phone Bo

k

15

SLIDE 16 Mo re Observations

As

requirem ents a re fo rm alize d, m a ny things that a re usually left

ut
f

English sp ecications a re encountered and explicitly do cum e nted

The

fo rm a l p ro cess exp

ses

am biguities and deciencies in the requirem ents| m ust chose b et w een book : [N ! P ] book : [N ! setof [P ]]

Challenges

and scrutiny reveal deciencies in the fo rm a l sp ecication

The

p ro cess

f

fo rm ali zing the requirem e nts can reveal p roblem s and deciencies and lead to a b etter English requirem ents do cum e nt as w ell Phone Bo

k

16

SLIDE 17 Deciency 3

Supp
se

w e wish to avoid ever assigning the sam e num b er to t w

p

eople

Could

\p rogram " this into the sp ecication

f

each function that changes the phone b

k
But

really w ant to establish the p rop ert y as an inva riant

f

the sp ecication

Could

system at icall y generate the p ro

f
bligations

to ensure this is so, but the activit y w

uld

b e erro r-p rone

Could

build a to

l

to do it, but that w

uld

b e sp ecial-purp

se
Solution:

do it with p redicate subt yp es Phone Bo

k

17

SLIDE 18 PVS Notation: subt yp e inva riant phone_4 : THEORY BEGIN N: TYPE % names P: TYPE % phone numbers B: TYPE = [N

>

setof[P]] % phone books VB: TYPE = fb:B | (FORALL (x,y:N): x /= y => disjoint?(b(x), b(y)))g nm, x: VAR N pn: VAR P bk: VAR VB FindPhone(bk,nm): setof[P] = bk(nm) UnusedPhoneNum(bk,pn): bool = (FORALL nm: NOT member(pn,FindPhone(bk,nm))) AddPhone(bk,nm,pn): VB = IF UnusedPhoneNum(bk,pn) THEN bk WITH [(nm) := add(pn, bk(nm))] ELSE bk ENDIF Phone Bo

k

18

SLIDE 19 PVS Notation: Pro

f

Obligation AddPhone_TCC1: OBLIGATION (FORALL (bk: VB, nm: N, pn: P): UnusedPhoneNum(bk, pn) IMPLIES (FORALL (x, y: N): x /= y => disjoint?[P](bk WITH [(nm) := add[P](pn, bk(nm))](x), bk WITH [(nm) := add[P](pn, bk(nm))](y)))); Phone Bo

k

19

SLIDE 20 Y et Mo re Observations

There

a re m any dierent w a ys to write fo rm a l sp ecications

Som

e w a ys

f

writing them bias the feasible im plem enta tion m

re

than

thers
One

goal is to m inim ize this bias, and y et b e com plete

Abstract

sp ecications a re m

re

lik ely to highlight substance than those cluttered with im plem entat ion concerns

But

requires real judgm ent and exp erience to pick right level

Constructive

sp ecications m a y b e executable as p rotot yp es|useful in som e dom a ins, distraction in

thers
Mechanized

supp

rt

allo ws p

w

erful checks

n

consistency , and active validation through \challenges" to the sp ecication Phone Bo

k

20