Acceptance and use

1
Acceptance and use

• Formal methods have not become main-stream as was
  once predicted, especially in the US.
• Other, less costly software engineering
  techniques (e.g., inspections / reviews) have
  been successful at increasing system quality.
  (Hence, the need for formal methods has been
  reduced.)

2
Acceptance and use

• Market changes have made time-to-market rather
  than quality the key issue for many systems.
  (Formal methods do not reduce time-to-market.)
• The scope of formal methods is limited. They are
  not well-suited to specifying user interfaces.
  (Many interactive applications are GUI-heavy
  today.)

3
Acceptance and use

• Formal methods are hard to scale up to very large
  systems. (Although this is rarely necessary.)
• The costs of introducing formal methods are
  high.
• Thus, the risks of adopting formal methods on
  most projects outweigh the benefits.

4
Acceptance and use

• However, formal specification is an excellent way
  to find requirements errors and to express
  requirements unambig-uously.
• Projects which use formal methods invariably
  report fewer errors in the delivered software.

5
Acceptance and use

• In systems where failure must be avoided, the use
  of formal methods is justified and likely to be
  cost-effective.
• Thus, the use of formal methods is increasing in
  critical system development where safety,
  reliability, and security are important.

6
Formal specification languages
7
Development costs with formal specification
8
The structure of an algebraic specification
lt SPECIFICA
TION NAME gt (Gener
ic P
ar
ameter)
sort
lt name gt
imports
lt LIST
OF SPECIFICA
TION NAMES gt
Inf
or
mal descr
iption of the sor
t and its oper
ations
Oper
ation signatures setting out the names and the
types of
the parameters to the operations defined over the
sort
Axioms defining the oper
ations o
v
er the sor
t
9
List specification
LIST
( Elem )
A FIFO linear list
sort
List
imports
INTEGER
Defines a list where elements are added at the
end and removed from the front. The operations
are Create, which brings an empty list into
existence Cons, which creates a new list with an
added member Length, which evaluates the list
size Head, which evaluates the front element of
the list and Tail, which creates a list by
removing the head from its input list. Undefined
represents an undefined value of type Elem.

Create ? List
Operator names type info for argument(s)
result
Cons (List, Elem) ? List
Head (List)
?
Elem
Length (List)
?
Integer
T
ail (List)
?
List
1 2 3 4 5 6
Head (Create) Undefined
exception
(empty list)
Head (Cons (L, v))
if
L
Create
then
v
else
Head (L)
Length (Create) 0
Length (Cons (L, v)) Length (L) 1
T
ail (Create ) Create
T
ail (Cons (L, v))
if
L
Create
then
Create
else
Cons (T
ail (L), v)
10
Recursion in specifications

• Tail (Cons (L, v)) if LCreate then Create
  else Cons (Tail (L), v)
• Tail (Cons ( 5, 7, 9)) Cons (Tail ( 5,
  7 ), 9)
• Cons (Tail
  (Cons (5, 7) ) , 9)
• Cons (Cons
  (Tail (5), 7) , 9)
• Cons (Cons
  (Tail (Cons (, 5) ), 7) , 9)
• Cons (Cons
  (Create, 7) , 9)
• Cons (
  7, 9)
• 7, 9

11
Exercise

• What does Head (Tail (L)) do?
• L Head (Tail (L))
• a
• a, b
• a, b, c

12
Exercise

• Are axioms 1-6 sufficient to prove ANY true
  assertion of the form
• Head (Tail (L) ) v ?
• Consider ONE EXAMPLE
• Head (Tail (a, b) b

13
Proof that Head (Tail (a, b) b

• Head (Tail (a, b)) Head (Tail (Cons (a,
  b)))
• By axiom 6,
• Head (Tail (Cons (a, b))) Head (Cons (Tail
  (a), b))
• Head (Cons (Tail (a), b)) Head (Cons (Tail
  (Cons ( , a)), b))
• By axiom 6,
• Head (Cons (Tail (Cons ( , a)), b)) Head
  (Cons ( , b))
• By axiom 2,
• Head (Cons ( , b)) b

14
Model-based specification

• Algebraic specification can be cumber-some when
  object operations are not independent of object
  state (i.e., previous operations).
• (System State) Model-based specification exposes
  the system state and defines operations in terms
  of changes to that state.

15
The structure of a Z schema
Natural numbers (0, 1, 2, )
Defines schema state
invariants, pre- post- conditions

16
An insulin pump
insulin
delivery
glucose level
text messages
dose delivered
17
Modelling the insulin pump

• The schema models the insulin pump as a number of
  state variables
• reading? from sensor
• dose, cumulative_dose
• r0, r1, r2 last 3 readings
• capacity pump reservoir
• alarm! signals exceptional conditions
• pump! output for pump device
• display1!, display2! text messages dose
• Names followed by a ? are inputs, names followed
  by a ! are outputs.

18
Schema invariant

• Each Z schema has an invariant part which defines
  conditions that are always true (schema
  predicates)
• For the insulin pump schema, it is always true
  that
• The dose must be less than or equal to the
  capacity of the insulin reservoir.
• No single dose may be more than 5 units of
  insulin and the total dose delivered in a time
  period must not exceed 50 units of insulin. This
  is a safety constraint.
• display1! shows the status of the insulin
  reservoir.

19
Insulin pump schema

dose capacity dose 5 cumulative_dose
50 capacity 40 gt display1! capacity 39
capacity 10 gt display1! Insulin
low capacity 9 gt alarm! on display1!
Insulin very low r2 reading?
every 10 minutes
20
The dosage computation

• The insulin pump computes the amount of insulin
  required by comparing the current reading with
  two previous readings.
• If these suggest that blood glucose is rising
  then insulin is delivered.
• Information about the total dose delivered is
  maintained to allow the safety check invariant to
  be applied.
• Note that this invariant always applies there
  is no need to repeat it in the dosage computation.

21
DOSAGE schema
operations change state
imports state predicates
(( r1 r0) ( r2 r1)) V (( r1 gt r0) ( r2 lt
r1)) V (( r1 lt r0) ((r1-r2) gt (r0-r1)))
(( r1 r0) (r2 r1)) V (( r1 lt r0) ((r1
r2) (r0 r1)))
(( r1 r0) (r2 gt r1)) V (( r1 gt r0) ((r2
r1) (r1 r0)))
x' - value of x after operation
22
Output schemas

• The output schemas model the system displays and
  the alarm that indicates some potentially
  dangerous condition.
• The output displays show the dose computed and a
  warning message.
• The alarm is activated if blood sugar is very low
  this indicates that the user should eat
  something to increase his blood sugar level.

23
Output schemas
conversion
Note conflict with insulin low msg.
3
30

AND


24
Schema consistency

• It is important that schemas be consistent.
  Inconsistency suggests a problem with system
  requirements.
• The INSULIN_PUMP schema and the DISPLAY are
  inconsistent
• display1! shows a warning message about the
  insulin reservoir (INSULIN_PUMP)
• display1! Shows the state of the blood sugar
  (DISPLAY)
• This must be resolved before implemen-tation of
  the system.

25
Specification via Pre- and Post-Conditions

• Predicates that (when considered together)
  reflect a programs intended functional behavior
  are defined over its state variables.
• Pre-condition expresses constraints on program
  variables before program execution. An
  implementer may assume these will hold BEFORE
  program execution.

26
Specification via Pre- and Post-Conditions

• Post-condition expresses conditions /
  relationships among program variables after
  execution. These capture any obligatory
  conditions AFTER program execution.
• Language (first order) predicate calculus
• Predicates (Xgt4)
• Connectives ( , V, ?, ?, NOT)
• Universal and existential quantifiers (for
  every, there exists)
• Rules of inference (if A (A ? B) then B)

27
Example 1

• Sort a non-empty array LIST1..N into increasing
  order.
• Pre-cond N 1
• Post-cond For_Every i, 1 i N-1, LISTi
  LISTi1 PERM(LIST,LIST)

28
Example 2

• Search a non-empty, ordered array LIST1..N for
  the value stored in KEY. If present, set found
  to true and J to an index of LIST which
  corresponds to KEY. Otherwise, set FOUND to
  false.

29
Example 2

• Pre-cond N 1 (LIST is in increasing
  order) V (LIST is in decreasing order)
• (Exercise express the ordered predicate above
  FORMALLY.)
• Post-cond (FOUND There_Exists i, 1 i N
  Ji LISTJKey) V (NOT FOUND For_Every i, 1
  i N, LISTi?KEY) UNCH(LIST,KEY)