1. Formal Specification - Techniques for the unambiguous specification of software
Objectives:
To explain why formal specification techniques help discover problems in system requirements
To describe the use of
algebraic techniques (for interface specification) and
model-based techniques(for behavioural specification)
To introduce Abstract State Machine Model

2. Formal methods
Formal specification is part of a more general collection of techniques that are known as ‘formal methods’
These are all based on mathematical representation and analysis of software
Formal methods include
Formal specification
Specification analysis and proof
Transformational development
Program verification

3. Notations For Formal Specification
Any notation with precise semantics can be used
Formalism typically applied to just part of a specification
Notations use discrete mathematics, some with graphics
Several notations are sometimes used in the same specification:
Z or VDM for data manipulation
Statecharts for system states and transitions
Natural language for non-functional specifications

4. Formal Specification Goals of formal specification:
Complete
Consistent
Concise
Unambiguous
Valid—state exactly what the user wants
Specifications based on formal semantic model
What is/are semantics?
What is a formal semantic model?

5. Formal Semantics Semantics means “meaning” Formal semantics:
Meaning expressed in mathematics
Formal semantic model:
Complete semantic definition of a language in mathematics
What mathematics?
Discrete mathematics!
Formal semantics permit dependable communication between all parties

6. Types Of Languages Procedural: Declarative: Functional:
Computation defined by desired sequence of actions computer is to perform
Most high-level languages are procedural
Declarative:
Computation defined by desired state that computer should be in
Many specification languages are declarative
Functional:
Computation defined as desired function computer is to evaluate
Most functional languages derive from LISP

7. Types Of Languages
High-level language programs are actually specifications!
Compilers write the program for you
So you have been specifying programs, not writing them
The big difference in languages is:
Declarative:
Says nothing about HOW, just WHAT
Procedural:
Says nothing about WHAT, just HOW

8. Types Of Languages—Examples
Procedural:
read (x);
y := x;
while y**2 > x loop
y := y – 1;
end loop;
print (y);
Declarative:
y**2 <= x AND (y+1)**2 > x

9. Formal Methods Activities
Write a specification using a formal notation
Validate the specification
Inspect it with domain experts
Perform automated analysis to prove theorems
Refine the specification to an implementation
Semantics-preserving transformations to code
Verify that the implementation matches the spec
Mathematical argument

10. Library Example: Informal Statement
A book can either be in the stacks, on reserve, or loaned out
If a book is in the stacks or on reserve, then it can be requested
We want to
formalize the concepts and the statements
prove some theorems to gain confidence that the spec is correct

11. Library Example: Formalization (1/2)
First let’s formalize some concepts
S: the book is in the stacks
R: the book is on reserve
L: the book is on loan
Q: the book is requested

12. Library Example: Formalization (2/2)
If a book is requested, then it is on the shelf or
on reserve

13. Library Example: Proof of a Theorem

14. Library Example: Proof By Contradiction

15. Use of formal methods
Their principal benefits are in reducing the number of errors in systems so their main area of applicability is critical systems:
Air traffic control information systems,
Railway signalling systems
Spacecraft systems
Medical control systems
In this area, the use of formal methods is most likely to be cost-effective
Formal methods have limited practical applicability

16. Use of formal specification
Formal specification involves investing more effort in the early phases of software development
This reduces requirements errors as it forces a detailed analysis of the requirements
Incompleteness and inconsistencies can be discovered and resolved !!!
Hence, savings as made as the amount of rework due to requirements problems is reduced

17. Acceptance of formal methods
Formal methods have not become mainstream software development techniques as was once predicted
Other software engineering techniques have been successful at increasing system quality. Hence the need for formal methods has been reduced
Market changes have made time-to-market rather than software with a low error count as the key factor. Formal methods do not reduce time to market
The scope of formal methods is limited. They are not well-suited to specifying and analysing user interfaces and user interaction
Formal methods are hard to scale up to large systems

18. Two specification techniques
Algebraic approach
The system is specified in terms of its operations and their relationships
Model-based approach
The system is specified in terms of a state model that is constructed using mathematical constructs such as sets and sequences.
Operations are defined by modifications to the system’s state

19. Interface specification
Large systems are decomposed into subsystems with well-defined interfaces between these subsystems
Specification of subsystem interfaces allows independent development of the different subsystems
Interfaces may be defined as abstract data types or object classes
The algebraic approach to formal specification is particularly well-suited to interface specification

20. Sub-system interfaces

21. The structure of an algebraic specification
TION NAME > (Gener
ic P ar
ameter)
sort
< name >
imports
< LIST
OF SPECIFICA
TION NAMES >
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 operations over the sort. Axioms relate
the operations used to construct entities with operations used
to inspect their values.

22. Specification components
Introduction
Defines the sort (the type name) and declares other specifications that are used
Description
Informally describes the operations on the type
Signature
Defines the syntax of the operations in the interface and their parameters
Axioms
Defines the operation semantics by defining axioms which characterise behaviour

23. Specification operations
Constructor operations. Operations which create entities of the type being specified
Inspection operations. Operations which evaluate entities of the type being specified
To specify behaviour, define the inspector operations for each constructor operation

24. Interface specification in critical systems
Consider an air traffic control system where aircraft fly through managed sectors of airspace
Each sector may include a number of aircraft but, for safety reasons, these must be separated
In this example, a simple vertical separation of 300m is proposed
The system should warn the controller if aircraft are instructed to move so that the separation rule is breached

25. A sector object
Critical operations on an object representing a controlled sector are
Enter. Add an aircraft to the controlled airspace
Leave. Remove an aircraft from the controlled airspace
Move. Move an aircraft from one height to another
Lookup. Given an aircraft identifier, return its current height

26. Primitive operations
It is sometimes necessary to introduce additional operations to simplify the specification
The other operations can then be defined using these more primitive operations
Primitive operations
Create. Bring an instance of a sector into existence
Put. Add an aircraft without safety checks
In-space. Determine if a given aircraft is in the sector
Occupied. Given a height, determine if there is an aircraft within 300m of that height

28. Behavioural specification
Algebraic specification can be cumbersome when the object operations are not independent of the object state
Model-based specification exposes the system state and defines the operations in terms of changes to that state

29. Abstract State Machine Language (AsmL)
AsmL is an executable specification language for modelling the structure and behaviour of digital systems
AsmL can be used to faithfully capture the abstract structure and step-wise behaviour of any discrete systems, including very complex ones such as:
Integrated circuits, software components, and devices that combine both hardware and software

30. Abstract State
An AsmL model is said to be abstract because it encodes only those aspects of the system’s structure that affect the behaviour being modelled
The goal is to use the minimum amount of detail that accurately reproduces (or predicts) the behaviour of the system
Abstraction helps us reduce complex problems into manageable units and prevents us from getting lost in a sea of details
AsmL provides a variety of features that allow you to describe the relevant state of a system in a very economical, high-level way

31. Abstract State Machine and Turing Machine
An abstract state machine is a particular kind of mathematical machine, like the Turing machine (TM)
But unlike a TM, ASMs may be defined a very high level of abstraction
An easy way to understand ASMs is to see them as defining a succession of states that may follow an initial state

32. State transitions
The behaviour of a machine (its run) can always be depicted as a sequence of states linked by state transitions
paint in green
paint in red A B
Moving from state A to state B is a state transition

33. Configurations
Each state is a particular “configuration” of the machine
The state may be simple or it may be very large, with complex structure
But no matter how complex the state might be, each step of the machine’s operation can be seen as a well-defined transition from one particular state to another

34. Evolution of state variables
We can view any machine’s state as a dictionary of
(Name, Value)
pairs, called state variables
paint in green
paint in red A B
(Colour, Red) is a variable, where “Colour” is the name of variable, “Red” is the value

35. Evolution of state variables
Names are given by the machine’s symbolic vocabulary
Values are fixed elements, like numbers and strings of characters
The run of a machine is a series of
states and state transitions that
results form applying operations
to each state in succession

36. Each transition operation:
Example
Diagram shows the run of a machine that models how orders might be
processed S1
Mode = “Initial”
Orders = 0
Balance = £0
Initialise
Process All Orders S3
Mode = “Final”
Balance = £500 S2
Mode = “Active”
Orders = 2
Balance = £200
Each transition operation:
can be seen as the result of invoking the machine’s control logic on the current state
calculates the subsequence state as output

37. Control Logic Typical form of the operational text is:
The machine’s control logic
behaves like a fix set of transition
rules that say how state may evolve
Typical form of the operational text is:
“ if condition then update ”
We can think of the control logic as a text that precisely specifies, for any given state, what the values of the machine’s variables will be in the following step

38. Control Logic as a Black Box
The machine control logic is a black box that takes as input a state dictionary S1 and gives as output a new dictionary S2
input
mode
“Initial”
orders
balance £0
The Machine’s Control Logic …
if mode = “Initial”
then mode := “Active”
output
Mode
“Active”
orders 2
balance
£200
The two dictionaries S1 and S2 have the same set of keys, but the values associated with each variable name may differ between S1 and S2

39. Run of the Machine
The run of the machine can be seen as what happens when the control logic is applied to each state in turn
The run starts form initial state
S1  S2  S3  …
S1 is given to the black box yielding S2, processing S2 results in S3,
and so on …
When no more changes to state are possible, the run is complete

40. For example: mode:=“Active”
Update operations
We use the symbol
“: =” (reads as “gets”)
to indicate the value that a name will have in the resulting state
For example: mode:=“Active”
Update can be seen only during the following step (this is in contrast to Java, C, Pascal, …)
All changes happen simultaneously, when you moving from one step to another. Then, all updates happen at once.(atomic transaction)

41. Programs Example 1. Hello, world Main()
step WriteLine(“hello, world!”)
ASML uses indentations to denote block structure, and blocks can be places inside other blocks
Statement block affect the scope of variables
Whitespace includes blanks and new-line character, ASML does not recognize tab character for indentation !!!!!!!
Main() is like main() in Java and C

42. Example 2. Reading a file var F as File? = undef
var Fcontents as String = “”
var Mode as String = “Initial”
Main()
step until fixpoint
if Mode = “Initial” then
F :=open(“mfile.txt”)
Mode :=“Reading”
if Mode = “Reading” and length(FContents) =0 then FContents :=fread (F,1)
if Mode = “Reading” and length(FContents) =1 then FContents := FContents + fread (F,1)
if Mode = “Reading” and length(FContents) >1 then
WriteLine (FContents)
Mode :=“Finished”

43. Example 2. Graph representation
Step 1
Step 2 S1
F= undef
Fcontents =“”
Mode = Initial S2
F= <open file 1>
Fcontents =“”
Mode = Reading S3
F= <open file 1>
Fcontents =“a”
Mode = Reading
Step 3 S4
F= <open file 1>
Fcontents =“ab”
Mode = Reading S5
F= <open file 1>
Fcontents =“ab”
Mode = Finished
Step5
Step 4

44. Key points
Formal system specification complements informal specification techniques
Formal specifications are precise and unambiguous. They remove areas of doubt in a specification
Formal specification forces an analysis of the system requirements at an early stage. Correcting errors at this stage is cheaper than modifying a delivered system

45. Key points
Formal specification techniques are most applicable in the development of critical systems and standards.
Algebraic techniques are suited to interface specification where the interface is defined as a set of object classes
Model-based techniques model the system using sets and functions. This simplifies some types of behavioural specification