Formal Specification

1
Formal Specification

• Techniques for the unambiguous specification of
  software

2
Specification in the Software Process

• Specification and design are inextricably
  intermingled.
• Architectural design is essential to structure a
  specification.
• Formal specifications are expressed in a
  mathematical notation with precisely defined
  vocabulary, syntax and semantics.

3
Specification and Design
4
Formal Specification on Trial

• Formal techniques are not widely used in
  industrial software development.
• Given the relevance of mathematics in other
  engineering disciplines, why is this the case?

5
Why Arent Formal Methods Used?

• Inherent management conservatism. It is hard to
  demonstrate the advantages of formal
  specification in an objective way.
• Many software engineers lack the training in
  discrete math necessary for formal
  specification.
• System customers may be unwilling to fund
  specification activities.
• Some classes of software (particularly
  interactive systems and concurrent systems) are
  difficult to specify using current techniques.

6
Why Arent Formal Methods Used?

• There is widespread ignorance of the
  applicability of formal specifications.
• There is little tool support available for formal
  notations.
• Some computer scientists who are familiar with
  formal methods lack knowledge of the real-world
  problems to which these may be applied and
  therefore oversell the technique.

7
Advantages of Formal Specification

• It provides insights into the software
  requirements and the design.
• Formal specifications may be analyzed
  mathematically for consistency.
• It may be possible to prove that the
  implementation satisfies the specification.

8
Advantages of Formal Specification

• Formal specifications may be used to guide the
  tester of the component in identifying
  appropriate test cases.
• Formal specifications may be processed using
  software tools. It may be possible to animate
  the specification to provide a software prototype.

9
Seven Myths of Formal Methods

• Perfect software results from formal methods
• Nonsense - the formal specification is a model of
  the real-world and may incorporate
  misunderstandings, errors and omissions.
• Formal methods means program proving
• Formally specifying a system is valuable without
  formal program verification as it forces a
  detailed analysis early in the development
  process.
• Formal methods can only be justified for
  safety-critical systems.
• Industrial experience suggests that the
  development costs for all classes of system are
  reduced by using formal specification.

10
Seven Myths of Formal Methods

• Formal methods are for mathematicians
• Nonsense - only simple math is needed.
• Formal methods increase development costs
• Not proven. However, formal methods definitely
  push development costs towards the front-end of
  the life cycle.
• Clients cannot understand formal specifications
• They can if they are paraphrased in natural
  language.
• Formal methods have only been used for trivial
  systems
• There are now many published examples of
  experience with formal methods for non-trivial
  software systems.

11
The Verdict!

• The reasons put forward for not using formal
  specifications and methods are weak.
• However, there are good reasons why these methods
  are not used
• The move to interactive systems. Formal
  specification techniques cannot cope effectively
  with graphical user interface specification.
• Successful software engineering. Investing in
  other software engineering techniques may be more
  cost-effective.

12
Use of Formal Methods

• These methods are unlikely to be widely used in
  the foreseeable future. Nor are they likely to be
  cost-effective for most classes of system.
• They will become the normal approach to the
  development of safety critical systems and
  standards.
• This changes the expenditure profile through the
  software process.

13
Development Costs with Formal Specification
14
Specifying Functional Abstractions

• The simplest specification is function
  specification. There is no need to be concerned
  with global state.
• The formal specification is expressed as input
  and output predicates (pre and post conditions).
• Predicates are logical expressions which are
  always either true or false .
• Predicate operators include the usual logical
  operators and quantifiers such as for-all and
  exists.

15
Specification with Pre and Post Conditions

• Set out the pre-conditions
• A statement about the function parameters stating
  what is invariably true before the function is
  executed
• Set out the post-conditions
• A statement about the function parameters stating
  what is invariably true after the function has
  executed
• The difference between the pre and post
  conditions is due to the application of the
  function to its parameters. Together the pre and
  post conditions are a function specification.

16
Specification Development

• Establish the bounds of the input parameters.
  Specify this as a predicate.
• Specify a predicate defining the condition which
  must hold on the result of the function if it
  computes correctly.
• Establish what changes are made to the input
  parameters by the function and specify these as
  a predicate.
• Combine the predicates into pre and post
  conditions.

17
The Specification of a Search
function Search ( X array 1 .. N of INTEGER
Key INTEGER ) return INTEGER Pre
exists i in 1..N X(i) Key Post X (Search
(X, Key)) Key and X X
18
Formal Specification Approaches

• Algebraic approach
• The system is described in terms of interface
  operations and their relationships.
• Model-based approach
• A model of the system acts as a specification.
  This model is constructed using well-understood
  mathematical entities such as sets and sequences.

19
Formal Specification Languages
20
Set Theory Review

• teacher(Mary)
• student(John)
• x Î T Û teaches(x)
• x Î S Û student(x)
• x Î O Û Øteaches(x) Ù Østudent(x)
• teacher(x) Þ Østudent(x)
• student(x) Þ Øteacher(x)
• teacher(x) Û Østudent(x) Ù Øother(x)

• Mary Î T Û teaches(Mary)
• teaches(Mary) Þ Østudent(Mary)
• Û Østudent(Mary) Ù Øother(Mary)
• x Î P teaches(x)
• "x Î S student(x)
• Øx Î S teaches(x) gt "x Î S Ø teaches(x)
• "x Î S y Î T student(x)
• Ù teaches(y)
• Ù supervises(y,x)

21
Implication

• a Þ b
• If (p.o.p gt 50) then (take an umbrella)
• a 0 Ù b 0
• If (p.o.p 50) then Ø (take an umbrella)
• 1
• a 0 Ù b 1
• If (p.o.p 50) then (take an umbrella)
• 1
• a 1 Ù b 0
• If (p.o.p gt 50) then Ø(take an umbrella)
• 0
• a 1 Ù b 1
• If (p.o.p gt 50) then (take an umbrella)
• 1

• a possibility of precipitation (p.o.p) gt 50
• b take an umbrella

So Þ informally means if the p.o.p is greater
than 50 I will take an umbrella, but if the
p.o.p is less than or equal to 50, I may or may
not take an umbrella
22
Model-based Specification

• Formal specification of software by developing a
  mathematical model of the system

23
Model-based Specification

• Defines a model of a system using well-understood
  mathematical entities such as sets and functions.
• The state of the system is not hidden (unlike
  algebraic specification).
• State changes are straightforward to define.
• VDM and Z are the most widely used model-based
  specification languages.

24
Z as a Specification Language

• Based on typed set theory.
• Probably now the most widely-used specification
  language.
• Includes schemas, an effective low-level
  structuring facility.
• Schemas are specification building blocks.
• Graphical presentation of schemas make Z
  specifications easier to understand.

25
Z Schemas

• Introduce specification entities and defines
  invariant predicates over these entities.
• A schema includes
• A name identifying the schema.
• A signature introducing entities and their types.
• A predicate part defining invariants over these
  entities.
• Schemas can be included in other schemas and may
  act as type definitions.
• Names are local to schemas.

26
Z Schema Highlighting
S
c
h
e
m
a

n
a
m
e
S
c
h
e
m
a

s
i
g
n
a
t
u
r
e
S
c
h
e
m
a

p
r
e
d
i
c
a
t
e
Container
contents
capacity
contents lt capacity
27
An Indicator Specification
Indicator
light
of
f
, on
reading

danger_le
v
el

light on

Û

reading gt danger_level
28
Storage Tank Specification
Stor
age_tank
Container
Indicator
reading contents
capacity 5000
danger_le
v
el 50
29
Full Specification of a Storage Tank
Stor
age_tank
contents

capacity

reading

danger_le
v
el

light
of
f
, on
contents gt capacity
light on
Û
reading gt danger_level
reading contents
capacity 5000
danger_le
v
el 50
30
Z Conventions

• A variable name decorated with a quote mark (N)
  represents the value of the state variable N
  after an operation.
• A schema name decorated with a quote mark
  introduces the dashed values of all names defined
  in the schema.
• A variable name decorated with a ! represents an
  output.

31
Z Conventions

• A variable name decorated with a ? represents an
  input.
• A schema name prefixed by the Greek letter Xi (?)
  means that the defined operation does not change
  the values of state variables.
• A schema name prefixed by the Greek letter Delta
  (?) means that the operation changes some or all
  of the state variables introduced in that schema.

32
Operation Specification

• Operations may be specified incrementally as
  separate schema then the schema combined to
  produce the complete specification.
• Define the normal operation as a schema.
• Define schemas for exceptional situations.
• Combine all schemas using the disjunction (or)
  operator.

33
A Partial Specification of a Fill Operation
Fill-OK
D Stor
age_tank
amount?

contents amount? lt capacity
contents
contents amount?
34
Storage Tank Fill Operation
Fill
Fill-OK Ov
erFill
35
The Z Specification Process
36
Data Dictionary Specification

• A data dictionary will be used as an example.
  This is part of a CASE system and is used to keep
  track of system names.
• Data dictionary structure
• Item name
• Description
• Type
• Creation date

37
Given Sets

• Z does not require everything to be defined at
  specification time.
• Some entities may be given and defined later.
• The first stage in the specification process is
  to introduce these given sets.
• NAME, DATE
• We dont care about these representations at this
  stage.

38
Type Definitions

• There are a number of built-in types (such as
  INTEGER) in Z.
• Other types may be defined by enumeration
• Sem_model_types relation, entity, attribute
• Schemas may also be used for type definition. The
  predicates serve as constraints on the type.

39
Specification Using Functions

• A function is a mapping from an input value to an
  output value.
• SmallSquare 1 ? 1, 2 ? 4, 3 ? 9, 4 ? 16, 5 ?
  25, 6 ? 36, 7 ? 49
• The domain of a function is the set of inputs
  over which the function has a defined result.
• dom SmallSquare 1, 2, 3, 4, 5, 6, 7
• The range of a function is the set of results
  which the function can produce.
• rng SmallSquare 1, 4, 9, 16, 25, 36, 49

40
The Function SmallSquare
41
Data Dictionary Modeling

• A data dictionary may be thought of as a mapping
  from a name (the key) to a value (the
  description in the dictionary).
• Operations are
• Add Makes a new entry in the dictionary or
  replaces an existing entry
• Lookup Given a name, returns the description.
• Delete Deletes an entry from the dictionary.
• Replace Replaces the information associated with
  an entry.

42
Data Dictionary Entry
DataDictionar
yEntr
y
entr
y
NAME
desc
seq char
type
Sem_model_types
creation_date
D
A
TE
descr
iption lt 2000
43
Data Dictionary as a Function
DataDictionary
DataDictionaryEntry
ddict NAME

DataDictionaryEntry
44
Data Dictionary - Initial State
Init-DataDictionary
D DataDictionary
ddict
Ø
45
Add and Lookup Operations
Add_OK
D DataDictionar
y
name?
NAME
entr
y?
DataDictionar
yEntr
y
name?
Ï
dom ddict
ddict
ddict
È
name?

entr
y?
Lookup_OK
X
DataDictionar
y
name?
NAME
entr
y!
DataDictionar
yEntr
y
name?
Î
dom ddict
entr
y! ddict (name?)
46
Add and Lookup Operations
Add_Error
X
DataDictionar
y
name?
NAME
error!
seq char
name?
Î
dom ddict
error!
Name already in dictionar
y
Lookup_Error
X
DataDictionar
y
name?
NAME
error!
seq char
name?
Ï
dom ddict
error!
Name not in dictionar
y
47
Function Overriding Operator

• ReplaceEntry uses the function overriding
  operator (written ?). This adds a new entry or
  replaces and existing entry.
• phone Ian ? 3390, Ray ? 3392, Steve ? 3427
• The domain of phone is Ian, Ray, Steve and the
  range is 3390, 3392, 3427.
• newphone Steve ? 3386, Ron ? 3427
• phone ? newphone Ian ? 3390, Ray ? 3392,
  Steve ? 3386, Ron ? 3427

48
Replace Operation
Replace_OK
D DataDictionar
y
name?
NAME
entr
y?
DataDictionar
yEntr
y
name?
Î
dom ddict
? name?
ddict


entr
y?
49
Deleting an Entry

• Uses the domain subtraction operator which, given
  a name, removes that name from the domain of the
  function.
• phone Ian ? 3390, Ray ? 3392, Steve ? 3427
• Ian phone
• Ray ? 3392, Steve ? 3427

50
Delete Entry
Delete_OK
D DataDictionar
y
name?
NAME
name?
Î
dom ddict
ddict
name? ddict
51
Specifying Ordered Collections

• Specification using functions does not allow
  ordering to be specified.
• Sequences are used for specifying ordered
  collections.
• A sequence is a mapping from consecutive integers
  to associated values.

52
A Z Sequence
53
Data Dictionary Extract Operation

• The Extract operation extracts from the data
  dictionary all those entries whose type is the
  same as the type input to the operation.
• The extracted list is presented in alphabetical
  order.
• A sequence is used to specify the ordered output
  of Extract.

54
The Extract Operation
Extr
act
DataDictionar
y
yEntry
rep!
seq DataDictionar
in_type?
Sem_model_types
"
n
dom ddict ddict(n).
type in_type?
Þ
ddict (n)
Î
r
ng rep!
"
i
1 lt i lt rep! rep! (i).type in_type?
"
i
1 lt i lt rep! rep! (i)
Î
rng ddict
"
i , j
dom rep! (i lt j)
Þ
rep
.
name(i) lt
rep
.name (j)

NAME
55
Extract Predicate

• For all entries in the data dictionary whose type
  is in_type?, there is an entry in the output
  sequence.
• The type of all members of the output sequence is
  in_type?
• All members of the output sequence are members of
  the range of ddict.
• The output sequence is ordered.

56
Data Dictionary Specification
The_Data_Dictionar
y
DataDictionar
y
Init-DataDictionar
y
Add
Lookup
Delete_OK
Replace_OK
Extract
57
Z Examples
pump CAR
58
Z Examples (2)
Serviced
59
Z Examples (3)
60
Z Examples (4)
RCheckIn (Checkin Ù Success) Ú CheckInError
CheckInError StaffIn Ú NotUser
Ù
61
Symbol Cheat Sheet