FORMAL SPECIFICATION

Presented by:
Neha Adhikari
Rupesh Shrestha
 Formal Method
More than 30 years of research into the use of mathematical techniques in the software
process, these techniques have had a limited impact.
Not widely used in industrial software development.
Do not considered cost-effective to apply them in software development processes by most
software development companies.
Refers to any activities that rely on mathematical representations of software including formal
system specification, specification analysis and proof, transformational development, and
program verification.
Formal software specification is a specification expressed in a language whose vocabulary,
syntax and semantics are formally defined.
Specification languages must be based on mathematical concepts (discrete mathematics)
whose properties are well understood. The mathematical concepts are drawn from set theory,
logic and algebra.
 Acceptance of Formal Method
 In 1980s, software engineering researchers proposed that formal development methods
• lead to programs with fewer errors,
• more suited to users’ needs,
• the best way to improve software quality,
• by the 21st century, a large proportion of software would be developed using formal methods.
 Clearly, this prediction has not come true. There are four main reasons for this:

1. Successful Software Engineering:

• Use of other software engineering methods such as structured methods, configuration management and information hiding in
software design and development processes have resulted improvements in software quality.

2. Market Changes
• Critical issue for many classes of software development is not quality but time-to-market.
• Software must be developed quickly, and customers are sometimes willing to accept software with some faults if rapid
delivery can be achieved.
• Rapid software development do not work effectively with formal specifications.
 Acceptance of Formal Method cont.
3. Limited scope of formal methods
• Formal methods are not well suited to specifying user interfaces and user interaction.
• Use formal methods when developing the other parts of the system.

4. Limited scalability of formal methods

• Formal methods have mostly been concerned with relatively small, critical kernel systems. As systems increase in size,
the time and effort required to develop a formal specification grows disproportionately.

 Most software development companies have been unwilling to risk using formal methods in their development process.
 However, formal specification is an excellent way of
discovering specification errors
presenting the system specification in an unambiguous way.
minimizing errors in the delivered software without an increase in development costs.
 Formal methods can be cost-effective if their use is limited to core parts of the system and if companies are willing to
make the high initial investment in this technology.
 Use of Formal Method
 The area of critical systems development, where emergent system properties such as safety, reliability and security are very
important.
 The high cost of failure in these systems means that companies are willing to accept the high introductory costs of formal methods
to ensure that their software is as dependable as possible.
 Criticalsystems have very high validation costs and the costs of system failure are large and increasing. Formal methods can
reduce these costs.
 Critical systems where formal methods have been applied successfully:
Air traffic control information system (Hall, 1996)
Railway signaling systems (Dehbonei and Mejia, 1995)
Spacecraft systems (Easterbrook, et al., 1998)
Medical control systems (Jacky, 1995, Jacky, et al., 1997).
 They have also been used for :
Software tool specification (Neil, et al., 1998),
Specification part of IBM’s CICS system (Wordsworth, 1991)
Real-time system kernel (Spivey, 1990).
Advantages of formal specification
 It provides insights into the software requirements and the design.
 Formal specifications may be analyzed mathematically and the consistency and
completeness of the specification demonstrated. It may be possible to prove that the
implementation corresponds to the 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
Formal Comes after the system requirements have been
specified but before the detailed system design.

Specification A tightfeedback loop between the detailed

requirements specification and the formal specification.
in Software The specification should be ‘customer-oriented’ at early
Process stage.
 Formal Specification in Software Process cont.
The involvement of the client decreases, and the involvement of the contractor increases as more
detail is added to the system specification.
The final stage, which is the construction of a complete, consistent and precise specification, and
system implementation is principally intended for the software contractor.
Use a formal language at this stage to avoid ambiguity in the software specification.
The specification stages shown in the above Figure are not independent nor are they necessarily
developed in the sequence shown.
Formal Specification in Software Process cont.

 Two-way relationship between each stage in the process. Information is fed from the specification to the
design process and vice versa.
 Detail development of the specification, increases understanding of that specification.
 Detailed systems analysis reveals errors and inconsistencies in the informal requirements specification.
 The error detection (potent argument) helps you discover requirements problems that can be very
expensive to correct later.
Development Cost with Formal Specification
 Development Cost with Formal Specification cont.
Specification problems discovered during formal analysis might influence changes to the
requirements specification if this has not already been agreed.
If the requirements specification has been agreed and is included in the system development
contract, you should raise the problems that you have found with the customer. It is then up to the
customer to decide how they should be resolved before you start the system design process.
 Developing and analyzing a formal specification front-loads software development costs.
When a conventional process is used, validation costs are about 50% of development costs, and
implementation and design costs are about twice the costs of specification.
With formal specification, specification and implementation costs are comparable and system
validation costs are significantly reduced.
Rework to correct requirements problems, after the system has been designed is avoided.
 Formal Specification Approach
1. Algebraic approach
• The system is described in terms of operations and their relationships.

2. Model-based approach
• A model of the system is built using mathematical constructs such as sets, and sequences and the system
operations are defined by how they modify the system state.
 Different languages to specify sequential and concurrent systems
 Sub-system Interface Specification
 Large systems are decomposed into sub-systems 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.
Structure of Thealgebraic approach defines abstract data type
(ADT) interfaces.

Algebraic The ADT is defined by specifying the type operations

with relationships between them rather than the type
Specification representation.
 Components of Algebraic Specification
1. An Introduction Part
• declares the sort (the type name) of the entity being specified
• may declare an ‘imports’ declaration, where the names of other sorts are declared that makes these sorts
available for use.
2. A Description Part
• describes operations informally for understanding formal specification easily.
• provides an unambiguous syntax and semantics for the type operations.
3. A Signature Part defines the
• syntax of the interface to the ADT.
• operation names, number and sorts of their parameters, sort of operation results
4. The Axioms Part
defines the semantics of the operations by defining a set of axioms that characterize the behavior of the ADT.
These axioms relate the entity constructor operations with value inspection operations.
 Formal Specification Development Process of Sub-
system Interface
1. Specification structuring
• organize the informal interface specification into a set of ADTs or object classes.
• define the operations associated with each class.

2. Specification naming
• establish a name for each abstract type specification.
• decide whether or not ADTs require generic parameters.
• decide on names for the sorts identified.

3. Operation selection
• Choose a set of operations for each specification based on the identified interface functionality.
• You should include operations to
create instances of the sort
modify the value of instances
inspect the instance values.
 Process cont.
4. Informal operation specification
• describe how each operation affects the defined sort.

5. Syntax definition
• define the syntax of the operations and the parameters to each operation.
• update the informal specification at this stage if necessary.

6. Axiom definition
• define the semantics of the operations by describing what conditions are always true for different operation
combinations.
 Specification Operations
1. Constructor operations
• Operations which create entities of the type being specified.
• Example: Create, Update, Add etc.

2. Inspection operations
• Operations which evaluate entities of the type being specified.
• Example: Eval, Get etc.

 establish the constructor operations and write down an axiom for each inspection operation over each
constructor.
 For m constructor operations and n inspection operations there should be m * n axioms defined.
 Operations on List ADT
• Linked List is an ordered data structure.
• Name of the specification is written in uppercase (LIST) and sort name is written in lowercase
(List).
• Generic parameter (Ele) may represent integer, string, list, and so on.
• Constructor Operations: Create, Cons and Tail.
• Inspection Operations: Head , Length.
• Tail can be defined using the simpler constructors Create and Cons. No need to define Head and
Length with Tail.
Algebraic
Specification
of List
 Recursion in List Specification
• Operations are often specified recursively
• list [5, 7] where 5 is the front of the list and 7 the end of the list.
• The operation Cons ([5, 7], 9) should return a list [5, 7, 9]
• The operation Tail ([5, 7, 9]) applied to this should return the list [7, 9] excluding head.
• The sequence of equations which results from substituting the parameters in the above
specification with these values
Interface Specification in Critical System: Sector
An air traffic control system, an object has been designed to represent a controlled sector of
airspace.
Assume each controlled sector may include several aircrafts, having unique aircraft identifier,
must be separated by at least 300 meters in height. (warns if the height constraint is breached)
The critical operations on the object are:
1. Enter adds an aircraft to the airspace at a specified height. (no aircraft at that height or within
300 m)
2. Leave removes the specified aircraft from the controlled sector.
3. Move moves an aircraft from one height to another (vertical separation of aircraft 300 m).
4. Lookup returns the current height of that aircraft in the sector.
Other Interface Operations to Sector
1. Create causes an empty instance (no aircraft) of the type to be created.
2. Put adds an aircraft to the sector without any associated constraint checking. (simpler version of
the Enter operation)
3. In-space Boolean operation returns true if the aircraft (given aircraft call sign) is in the controlled
sector, false otherwise.
4. Occupied Boolean operation returns true if there is an aircraft within 300 meters of that height
(given), false otherwise.
 More about Occupied and Move Operations
 Occupied operation specification states that:

•Inan empty sector (one that has been create by a Create operation) every level is vacant. The operation returns false
irrespective of the value of the height parameter.

•Ina non-empty sector (one where there has been previous Put operations) the Occupied operation checks whether the
specified height (parameter H) is within 300 m of the height of aircraft that was last added to the sector by a Put operation.
If so, that height is already occupied so the value of Occupied is true.

•Ifit is not occupied, the operation checks the sector recursively. If the height is not within range of the height of that
aircraft, the operation then checks against the previous aircraft that has been put into the sector and so on. Eventually, if
there are no aircraft within range of the specified height, the check is carried out against an empty sector so returns false.

 Move operation specification states that:

• If a Move operation is applied to an empty airspace (the result of Create), the airspace is unchanged. (exception: specified
aircraft is not in the airspace.)

• In a non-empty sector, the operation first checks (using In-space) whether the given aircraft is in the sector. If it is not, an
exception is raised. If it is in the sector, the operation checks that the specified height is available (using Occupied), raising
an exception if there is already an aircraft at that height.

• If the specified height is available, the Move operation is equivalent to the specified aircraft leaving the airspace (so the
operation Leave is used) and being put into the sector at the new height.
Algebraic
Specification
of Sector
 Behavioral Specification
Algebraic techniques can be used to describe interfaces where the object operations are independent
of the object state. When the results of applying an operation depend on the results of previous
operations algebraic technique is replaced by model-based specification.
You can specify the system operations by defining how they affect the state of the system model
which defines the overall behavior of the system.
Maturenotations for developing model-based specifications are VDM (Jones, 1980, Jones, 1986),
B (Wordsworth, 1996) and Z (Hayes, 1987) (Spivey, 1992).
InZ notation specifications are presented as informal text supplemented with formal descriptions
which is included as small, easy-to-read chunks (called schemas).
Schemas are used to introduce state variables and to define constraints and operations on the state.
Schemas can themselves be manipulated using operations such as schema composition, schema
renaming and schema hiding.
Z Schema The schema signature defines the entities that make up
the state of the system.
The schema predicate sets out conditions that must
always be true for these entities. Where a schema defines
an operation, the predicate may set out pre- and post-
conditions. These define the state before and after the
operation.
 An Insulin Pump
Monitors the blood glucose level of diabetics and automatically injects insulin as required.
 Modelling the Insulin Pump: Input Variable
Input variable followed by ? symbol.
Switch? (models the on/off switch of pump)
ManualDeliveryButton? (manul delivery of insulin)
Reading? (reading from the blood sugar sensor)
HardwareTest? (running hardware test program)
InsulinReservoir? (presence of insulin reservoir)
Needle? (presence of needle)
clock? (current time)
 Modelling the Insulin Pump: Output Variable
Output variable followed by ! symbol.
alarm! (model pump alarm)
display1!, display2! (alphanumeric displays)
clock! (display current time)
dose! (dose of the insulin to be delivered)
 Modelling the Insulin Pump: State Variable
State variables used for dose computation
status (status of device)
r0, r1, r2 (blood sugar levels)
capacity (capacity of insulin reservior)
insulin_available (insulin currently available)
max_daily_dose, max_single_dose, minimum_dose, safemin, safemax (insulin dose
limits)
compDose, cumulative_dose (dose computation)
 N (non-negative number)
 INSULIN_PUMP_STATE Schema Invariants
The dose must be less than or equal to the capacity of the insulin reservoir. (impossible
to deliver more insulin than is in the reservoir)
The cumulative dose is reset at midnight (12 am) each day.
 The cumulative dose delivered over a 24-hour period may not exceed max_daily_dose.
display2! always shows the value of the last dose of insulin delivered and clock1! always
shows the current clock time.
<logical expression 1> ⇒ <logical expression 2> same as
if <logical expression 1> then <logical expression 2>.
INSULIN
PUMP STATE
Schema
 RUN schema
• Insulin is delivered if the rate of change of blood glucose is increasing.
• The delta schema Δ INSULIN_PUMP_STATE reuses INSULIN_PUMP_STATE in scope as
are a set of other variables.
• Schema composition — SUGAR_LOW, SUGAR_OK and SUGAR_HIGH
• When the amount of insulin available is greater than the maximum single dose that may be
delivered.
• Three schemas are then ‘ored’ that represent different blood sugar levels and, these define a
value for the state variable CompDose which represents the amount of insulin that has been
computed for delivery, based on the blood sugar level.
• Last two predicates define the changes to the value of insulin_available and cumulative_dose.
RUN
Schema
 SUGAR_OK Schema
• Dose of insulin is computed assuming that the level of sugar in the diabetic’s blood lies within safe
zone.
• Insulin is only delivered if the blood sugar level is rising and the rate of change of blood sugar level is
increasing.
• The other schemas SUGAR_LOW and SUGAR_HIGH define the dose to be delivered if the sugar
level is outside the safe zone.
• The initial predicate defines the safe zone, that is, r2 must lie between safemin and safemax.
• If the sugar level is stable or falling, indicated by r2 (the later reading) being equal to or less than r1
(an earlier reading) then the dose of insulin to be delivered is zero.
• If the sugar level is increasing (r2 > r1) but the rate of increase is falling, then the dose to be delivered
is zero.
• If the sugar level is increasing and the rate of increase is stable, then a minimum dose of insulin is
delivered.
• If the sugar level is increasing and the rate of increase is increasing, then the dose of insulin to be
delivered is derived by applying a simple formula to the computed values.
Sugar_OK
Shema
 Conclusions
• 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
• 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 or ADTs. These techniques conceal the system state and specify the system in terms of
relationships between the interface operations.

• Model-based techniques model the system using sets and functions. This simplifies some types
of behavioural specification. You define the operations in a model-based specification by defining pre-
and post-conditions on the system state.
References
Software Engineering, “ Ian Sommerville”, ninth edition