PGT780
CONTENTS
PART 1: Carroll Morgan: Programming from Specifications
(On PGT780 Website)
1 Programs and refinement 1
2 The predicate calculus 16 – Self study
3 Assignment and sequential composition 27
4 Alternation 36
5 Iteration 41
………….
Appendices:
A Some laws for predicate calculation 258
A.1 Some propositional laws 258
A.2 Some predicate laws 262
B Answers to some exercises 266
C Summary of laws 298
PART 2: VARIOUS EXAMPLES TO BE ANNOUNCED
1
Chapter 1
Programs and refinement
1.1 The traditional view
• Programs:
a. collections of detailed instructions to a computer.
b. written in programming language
c. form (syntax) and meaning (semantics) precisely
defined.
d. are easy to execute (computers do that),
e. hard to understand.
• Programming methodology: Specification Program
• Specifications
a. written in English, or in mathematical style.
b. hard to execute
c. easy to understand
d. a contract between a programmer and his client
e. may spawn subspecifications (new client /
programmers)
• Ultimately, programs are contracts between the lowestlevel programmers and the computer.
2
1.2 A novel view
• Spec / subspec / program all seen as programs
o Loss: not all programs are executable (only code)
o Gain: More uniform approach
•
3
1.3 Programs as contracts: refinement
• Client / Programmar Contract
• Each has own interests at heart.
• Client: program must do more (spec more “refined”)
• Programmer wants freedom (spec more “abstract”)
• Result is always a compromise.
• prog1 prog2
• prog2 is better for client than program prog1
• prog2 is a refinement of program prog1
• Refinement process:
prog1 (Start spec)
prog2 prog3 …
pronN (Code)
4
1.4 Abstract programs
1.4.1 Initial and final states
• State of a computer: a collection of named values.
o The names are called variables,
o Values: natural numbers, integers, real numbers,
characters, etc.
• A state maps variables to their values.
5
1.4.2 Description of states
• Pictures are not very useful
o value of every variable must be given
o depicts only one state
• Use formulae instead
o x = 2 y = 17 z = 3 fully describes state0
o state0 satisfies x = 2,
x +z < y,
z ≠ 4,
• A predicate calculus formula (in the relevant variables)
describes a set of states
• true describes the set of all states
o All states satisfy true
• false describes the empty set of states
o No state satisfies false
o Often “no state” is associated with non-termination
• Predicate calculus
o equations (like x = y)
o relations (z < 17),
o the logical connectives
, ∨, ¬, ⇒, ∀, ∃
6
1.4.3 Specifications
• Specification – an abstract program
o Precondition –set of permissible initial states;
o Postcondition - the set of possible final states;
o Frame lists the variables whose values may change.
• If precond, then change frame so that post holds
• If ¬ precond, then ??
o Any final state is permissible
o Including no final state – i.e. non-termination
• Assigns root of x to y, provided x lies between 0 & 9
• Alternative notation
o What if x = 10 initially?
o If x = 4 initially, is y = -2 allowed in final state?
• In general
w: [pre ; post]
7
1.4.4 Refinement of specifications
• (Pre/post) condition represents a set of states
• Condition P stronger than condition Q:
States for Q
P implies Q
States
for P
PQ
• Strengthening postcondition leads to refinement:
refines
8
• “If post’ post …” is called the proviso
• Weakening precondition leads to refinement:
refines
9
1.5 Executable programs
1.5.1 Code
Our language consists of:
• predicate calculus formula
o highly expressive
o for spec
• certain commands (code)
o executable
o for computer
1.5.2 The assignment command
• w :=E
o Changes the state
o Variable w is mapped to the value E
o All other variables are left unchanged.
• Basis of imperative programming languages;
• Easy to execute provided the expression E is
constructed from constants and operators that the
programming language provides
Law 1.3 assignment If pre post[w\E], then
w; x: [pre ; post] w :=E.
• Note:
o Law refines spec to code
o post[w\E] Replace w by E in post
o frame w; x: x may change, not that it must.
10
• Example:
y: [0 x 9 ; y2 = x y 0] y := √x.
Assume √ is code (function). Returns 0
• Proof (of proviso in Law 1.3)
post[w\E]
“post as defined in this problem”
(y2 = x y 0)[y\√x]
“definition of substitution”
((√x) 2 = x √x 0
“definition of √”
((√x) 2 = x “P ”
((√x) 2 = x
However
pre
“pre as defined in this problem”
0 x 9
“x is well-defined in given range"
((√x) 2 = x
11
1.6 Mixed programs
• In general:
o spec mixed0 mixedn code
o Every step considered as “a program”
o Developing programs, in that sense, is the main
topic of this book.
• Typical form of “mixed”:
o Linked by constructors like sequential
composition,
o prog1; prog2
the effect of prog1 followed by the effect
of prog2.
o Example
x :=9;
y: [true ; y2 = x ]
• Sequential composition have their own laws (see later)
12
1.7 Infeasible programs
• Consider the refinement
y: [0 x 9 ; y2 = x y 0]
“Weaken precondition – law 1.2”
y: [true; y2 = x y 0]
• If x < 0 then post can’t be attained
• Spec is infeasible
Definition 1.4 feasibility The specification w: [pre ; post]
is feasible if
pre (∃ w : T • post) ;
where T is the type of the variables w.
• NB: Def 1.4 implies for every state in pre, there must
exist a w in T such that post holds.
• For historical reasons, infeasible programs are
sometimes called miracles.
13
1.8 Some common idioms
Abbreviation 1.5 default precondition
w: [post] w: [true ; post]
• Note
o X Y (X defined to be Y – a definition)
o X = Y (X is equal to Y – a true/false assertion)
o x Y (x from set Y – a definition)
o x Y (x is in set Y – a true/false assertion)
Abbreviation 1.6 assumption
{pre} : [pre ; true] (NB: Frame is empty)
• Note
o {pre} : [pre ; true] : [pre; pre]
(Why?)
o Convention: Leave out semicolon, i.e.
{0 x 9} y := √x instead of
{0 x 9}; y := √x
o “…If x does not fall within that range, then {0 x 9} aborts …” ???
14
Law 1.7 simple specification Provided E contains no w,
w :=E = w: [w = E] :
Law 1.8 absorb assumption An assumption before a
specification can be absorbed directly into its precondition.
{pre’} w: [pre ; post] = w: [pre’ pre ; post].
• Prove that: {0 x 9} y := √x
= y: [0 ≤ x ≤ 9 ; y2 = x x ≥ 0]
• Proof:
{0 x 9} y := √x
= “simple specification 1.7"
{0 x 9} y: [y = √x]
= “absorb assumption 1.8"
y: [0 x 9 ; y = √x]
= “rewrite postcondition"
y: [0 ≤ x ≤ 9 ; y2 = x x ≥ 0]
15
1.9 Extreme programs
• Worst specification (for client)
Abort w: [false ; true]
• It is never guaranteed to terminate (precondition
false); and even when it does, it has complete freedom
in its setting of the variables (postcondition true).
y: [pre; post]
• Slightly better is the program that always terminates,
but guarantees no particular result:
Choose w w: [true ; true] :
• Chooses w randomly
Choose w w: [true; post]
• Better still: program which always terminates,
changing nothing.
Skip : [true ; true]
• Best of all: infeasible program that always terminates
and establishes the impossible false:
Magic w: [true ; false] :
• No computer can execute that program; no contract
based on it could ever be met. Most refined possible
16
1.10 Exercises
Chapter 2: Self study
Small class test on chapter next week: (16th Feb)
Homework for 23rd February
1.3, 1.5, 1.6, 1.9, 1.16, 1.19
17