IS301 – Software Engineering mailto:mkabay@norwich.edu V: 802.479.7937 Formal Specification IS301 – Software Engineering Lectures # 11&12 – 2004-09-24&27 M. E. Kabay, PhD, CISSP Assoc. Prof. Information Assurance Division of Business & Management, Norwich University mailto:mkabay@norwich.edu V: 802.479.7937 M. E. Kabay, PhD, CISSP Copyright © 2004 M. E. Kabay. All rights reserved.

Objectives To explain why formal specification techniques help discover problems in system requirements To describe the use of algebraic techniques for interface specification To describe the use of model-based techniques for behavioral specification We will work on this chapter for two sessions: today and Monday. Homework is due a week from Monday.

More on Friday during the Formal Specification Workshop. Topics Formal specification in the software process Sub-system interface specification Behavioral specification We will use __ of Prof Sommerville’s slides today in our overview of this topic. More on Friday during the Formal Specification Workshop.

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

Poor Acceptance of Formal Methods Have not become mainstream software development techniques (as was once predicted) Other software engineering techniques have been successful at increasing system quality Market changes  time-to-market rather than software with low error count as key factor Scope of formal methods limited – not well-suited to specifying and analyzing user interfaces and user interaction Formal methods hard to scale up to large systems

Use of Formal Methods Formal methods have limited practical applicability Principal benefits: Reducing number of errors in systems Main area of applicability: critical systems In this area, use of formal methods most likely to be cost-effective

Specification in the Software Process Specification and design inextricably intermingled Architectural design essential to structure specification Formal specifications Expressed in mathematical notation Precisely defined vocabulary syntax semantics Copyright © 2004 M. E. Kabay. All rights reserved.

Specification and Design Copyright © 2004 M. E. Kabay. All rights reserved.

Specification in the Software Process Copyright © 2004 M. E. Kabay. All rights reserved.

Specification Techniques Algebraic approach System specified in terms of Its operations and Their relationships Model-based approach System specified in terms of state model Constructed using mathematical constructs; e.g., Sets Sequences Operations defined by modifications to system’s state

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.

Cost profile The use of formal specification means that the cost profile of a project changes There are greater up front costs as more time and effort are spent developing the specification; However, implementation and validation costs should be reduced as the specification process reduces errors and ambiguities in the requirements.

Development Costs With Formal Specification Copyright © 2004 M. E. Kabay. All rights reserved.

Specification techniques Algebraic specification The system is specified in terms of its operations and their relationships. Model-based specification 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.

Interface Specification Large systems decomposed into subsystems Well-defined interfaces between these subsystems Specification of subsystem interfaces allows independent development of different subsystems Interfaces may be defined as abstract data types or object classes Algebraic approach to formal specification particularly well-suited to interface specification

Sub-System Interfaces

WE STOP HERE FRIDAY You absolutely have to read the chapter carefully before Monday. The rest of this material is extremely challenging and you must be prepared before class.

Structure of Algebraic Specification <SPECIFICATION NAME > (Generic Parameter) class* < name > Imports < LIST OF SPECIFICATION NAMES > Informal description of class and its operations Operation signatures setting out names and types of parameters to operations defined over class Axioms defining operations over class *In Figure 10.6 and discussion on page 224ff, Sommerville uses the word “sort” where US specialists would use the word “class.” Copyright © 2004 M. E. Kabay. All rights reserved.

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 characterize behavior.

Systematic algebraic specification Algebraic specifications of a system may be developed in a systematic way Specification structuring; Specification naming; Operation selection; Informal operation specification; Syntax definition; Axiom definition.

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 behavior, define the inspector operations for each constructor operation.

Operations on a list ADT Constructor operations which evaluate to type List Create, Cons (construct) and Tail. Inspection operations which take type list as a parameter and return some other type Head and Length. Copyright © 2004 M. E. Kabay. All rights reserved.

List specification (1) LIST (Elem) Type List Imports INTEGER Defines a list where elements are added at the end and removed from the front. The operations Create, which brings an empty list into existence, Cons, which creates a new list with an added member, Length, which valuates the size, Head, which valuates 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.

List specification (2) Operation signatures: Create  List Cons (List, Elem)  List Head (List)  Elem Length (List)  Integer Tail (List)  List

List specification (3) Axioms defining operations over class 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 Tail (Create) = Create Tail (Cons (L, v) = if L = Create then Create else Cons (Tail (L), v)

Recursion in specifications Operations are often specified recursively. Tail (Cons (L, v)) = if L = Create then Create else Cons (Tail (L), v). Cons ([5, 7], 9) = [5, 7, 9] Tail ([5, 7, 9]) = 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] Copyright © 2004 M. E. Kabay. All rights reserved.

Interface Specification in Critical Systems Consider air traffic control system where aircraft fly through managed sectors of airspace Each sector may include number of aircraft but, for safety reasons, these must be separated In this example, simple vertical separation of 300m proposed The system should warn controller if aircraft instructed to move so that separation rule breached

A Sector Object (Air-Traffic System) Critical operations on object representing controlled sector Enter: Add aircraft to controlled airspace Leave: Remove aircraft from controlled airspace Move: Move aircraft from one height to another Lookup: Given aircraft identifier, return its current height

Primitive Operations (Air-Traffic System) Sometimes necessary to introduce additional operations to simplify specification Other operations can then be defined using these more primitive operations Primitive operations Create: Bring instance of sector into existence Put: Add aircraft without safety checks In-space: Determine if given aircraft in sector Occupied: Given height, determine if aircraft within 300m of that height

Sector Specification (1) This diagram is broken down into more readable sections on following slides.

Sector Specification (2) Sort Sector Imports INTEGER, BOOLEAN ______________________________________________________ Enter – adds an aircraft to the sector if safety conditions are satisfied Leave – removes an aircraft from the sector Move – moves an aircraft from one height to another if safe to do so Lookup – Finds the height of an aircraft in the sector Create – creates an empty sector Put – adds an aircraft to a sector with no constraint checks In-space – checks if an aircraft is already in a sector Occupied – checks if a specified height is available

Sector Specification (3) _____________________________________________________Enter (Sector, Call-sign, Height)  Sector Leave (Sector, Call-sign)  Sector Move (Sector, Call-sign, Height)  Sector Lookup (Sector, Call-sign)  Height Create  Sector Put (Sector, Call-sign, Height)  Sector In-space (Sector, Call-sign)  Boolean Occupied (Sector, Height)  Boolean _____________________________________________________

Sector Specification (4)

Sector Specification (5)

Specification Commentary Use basic constructors Create and Put to specify other operations Define Occupied and In-space using Create and Put and use them to make checks in other operation definitions All operations that result in changes to sector must check that safety criterion holds

Behavioral Specification Algebraic specification can be cumbersome when object operations not independent of object state Model-based specification Exposes system state and Defines operations in terms of changes to that state Z notation Mature technique for model-based specification. Combines formal and informal description and Uses graphical highlighting when presenting specifications

Structure of Z Schema 

Insulin Pump

Modeling Insulin Pump Schema models insulin pump as number of state variables reading? dose, cumulative_dose r0, r1, r2 capacity alarm! pump! display1!, display2! Names followed by ? = inputs, Names followed by ! = outputs

Schema Invariant Each Z schema has invariant part which defines conditions always true For insulin pump schema always true that Dose must be less than or equal to capacity of insulin reservoir No single dose may be more than 5 units of insulin and Total dose delivered in time period must not exceed 50 units of insulin. Display1! shows status of insulin reservoir.

Insulin Pump Schema  

State invariants

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.

RUN schema (1)

RUN schema (2)

Sugar OK schema

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. Formal specification techniques are most applicable in the development of critical systems and standards.

Key points 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 behavioral specification. Operations are defined in a model-based spec. by defining pre and post conditions on the system state.

Homework Required By Fri 1 Oct 2004 For a total of 25 points, answer fully: 10.2 (5 pts), 10.5 (10), 10.6 (10) Optional By Fri 8 Oct 2004 For up to 12 extra points, answer any or all of the following: 10.7 (5), 10.8 (5), 10.10 (2)

Copyright © 2004 M. E. Kabay. All rights reserved. DISCUSSION Copyright © 2004 M. E. Kabay. All rights reserved.