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

Phone Bo ok Exam ple John Rushb y Com puter Science Lab o rato ry SRI International Menlo P a rk CA USA Phone Bo ok 1

Phone Bo ok Exam ple Requirem ents fo r an electronic phone b o ok � Phone b o ok shall sto re the phone num b ers of a cit y � It shall b e p ossible to retrieve a phone num b er given a nam e � It shall b e p ossible to add and delete entries from the phone b o ok Phone Bo ok 2

F o rm al Requirem ents Sp eci�cation Ho w do w e rep resent the phone b o ok m a them a tic ally? 1. A set of ( 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 of p ossible nam es and whose range is the space of all phone num b er s. Adding and deleting entries via m o di�cat ion of function values 3. A pa rtial function whose dom a in is just the nam es currently in phone b o ok and whose range is the space of all phone num b er s. Adding and deleting entries via m o di�cat ion of the function dom a in and values Let's sta rt with app roach 2 Phone Bo ok 3

Sp ecifying the Bo ok � In traditional m a them ati cal notation, w e w ould write: Let N : t yp e (of nam es) P : t yp e (of phone num b ers) b o ok : 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 ossible nam e s, only fo r nam es of real p eople? Decide to use a sp ecial num b er, that could never really o ccur in real life, e.g. 000-0000; don't have to sp ecify the value of this num b er w e can just give it a nam e (e.g., n ) 0 � No w can de�ne an em pt y phone b o ok: em pt yb o ok : [ N ! P ] n : P 0 nm : va r N axiom : 8 nm : em pt yb o ok ( nm ) = n 0 Phone Bo ok 4

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 ok 5

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 0 nm; x : va r N pn : va r P bk : va r B AddPhone : [ B � N � P ! B ] 8 < bk ( x ) if x 6 = nm axiom : AddPhone ( bk ; nm; pn )( x ) = : pn if x = nm DelPhone : [ B � N ! B ] 8 < bk ( x ) if x 6 = nm axiom : DelPhone ( bk ; nm )( x ) = : n if x = nm 0 Phone Bo ok 6

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

Challenging the Requirem ent Sp eci�cation � If y ou add a nam e and num b er and then lo ok it up, do y ou get the right answ er? lem m a : FindPhone ( AddPhone ( bk ; nm; pn ) ; nm ) = pn � If y ou add an entry and then delete it, is the phone b o ok unchanged? lem m a : DelPhone ( AddPhone ( bk ; nm; pn ) ; nm ) = bk � Not true unless bk ( name ) = n b efo rehand 0 � Is this what w as intended? � Should w e m o dify the sp eci�cation of 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 ok 8

An Aside on Axiom s � Supp ose w e w ant to sepa rate the functions of adding and changing a num b er � T o de�ne these, useful to have a p redicate Kno wn ? : [ B � N ! b o ol ] axiom : Kno wn ?( bk ; nm ) i� bk ( nm ) 6 = n 0 � Supp ose 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 only where necessa ry; b est to use de�nitional fo rm s of sp eci�cation (gua ranteed not to intro duce inconsistencies) � PVS m a y generate p ro of obligations (TCCs) to ensure this gua rantee Phone Bo ok 9

Som e De�ciencies of First Sp eci�cation 1. Our sp eci�cation do es not rule out the p ossibilit y of som eone having a \ n " phone num b er 0 2. W e have not allo w ed m ult iple phone num b ers p er nam e 3. Our sp eci�cation do es not sa y anything ab out whether o 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 o p eople Ho w do w e rem edy these de�ciencies? Phone Bo ok 10

De�ciency 1 Our sp eci�cation do es not rule out the p ossibilit y of som eone having a \ n " phone num b e r 0 There a re several w a ys to overcom e this p roblem � Use a \disjoint union" fo r the range t yp e of the phone b o ok, so that n is not an o rdina ry num b er 0 � Use a \p redicate subt yp e" to identify the phone num b er s di�erent to n and allo w only the subt yp e in AddPhone 0 � Use one of the other rep resentations fo r the phone b o ok (e.g., pa rtial functions|requires a di�erent sp eci�cation language) � Reconsider requirem ent s Phone Bo ok 11

Predicate Subt yp es � Can de�ne the t yp e GP of Go o d Phone Num b er s : GP : t yp e = f pn : P j pn 6 = n g 0 � Then de�ne AddPhone de�nitionally 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 ossible p ro of obligation 8 pn : pn 6 = n ) 0 � But the follo wing is a p rovably true Kno wn ? ( AddPhone ( bk ; nm; g p ) ; nm ) Phone Bo ok 12

De�ciency 2 � W e have not allo w ed m ult iple phone num b ers p er nam e � The o riginal requirem ents did not sp ecify whether this is needed o r not � Supp ose, after conferring with the custom er, w e decide to allo w m ult iple num b ers � Change the range t yp e of the phone b o ok to a set of num b ers � This solves De�ciency 1 as w ell (em pt y set of num b ers indicates nam e not in the b o ok) Phone Bo ok 13

New Sp eci�cation (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 o ok ( 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 ) [ f pn g ] DelPhone ( bk ; nm ) : B = bk with [( nm ):= � ] P Phone Bo ok 14

Som e Observations � Our sp eci�cation is abstract; the functions a re de�ned over uninterp reted dom ains. � The axiom s and de�nitions used here a re constructive|w e could execute them (could also use pseudo co de fo r these kinds of sp eci�cations, but w ould lack an assertion language fo r challenges, and the deductive appa ratus to fo rm al ly check their p ro ofs) � Other sp eci�cations and rep resentations m a y involve nonconstructive axiom s e.g., set of pairs: FindPhone ( bk ; nm ) = f pn j ( nm; pn ) 2 bk g � And m o re sophisticated (not directly im plem e ntable) t yp es Phone Bo ok 15

Mo re Observations � As requirem ents a re fo rm alize d, m a ny things that a re usually left out of English sp eci�cations a re encountered and explicitly do cum e nted � The fo rm a l p ro cess exp oses am biguities and de�ciencies in the requirem ents| m ust chose b et w een book : [ N ! P ] book : [ N ! setof [ P ]] � Challenges and scrutiny reveal de�ciencies in the fo rm a l sp eci�cation � The p ro cess of fo rm ali zing the requirem e nts can reveal p roblem s and de�ciencies and lead to a b etter English requirem ents do cum e nt as w ell Phone Bo ok 16