Formal Algebraic Specification Techniques | CEN 5035, Study notes of Software Engineering

Download Formal Algebraic Specification Techniques | CEN 5035 and more Study notes Software Engineering in PDF only on Docsity!

©Ian Sommerville 2000^

Software Engineering, Chapter 10

Slide 1

Chapter 10 Formal Specification

©Ian Sommerville 2000^

Software Engineering, Chapter 10

Slide 2

Objectives l^ To explain why formal specification helps^ discover problems in system requirements

l^ To describe the use of:^ §^ Algebraic

specification techniques, and § Model-based^ specification techniques(including simple pre- and post-conditions).

©Ian Sommerville 2000^

Software Engineering, Chapter 10

Slide 4

Formal methods (cont’d) l^ Formal methods include:^ §^ Formal specification^ §^ Specification analysis and property proofs^ §^ Transformational development^ §^ Program verification

(program correctness proofs) l Specifications are expressed withprecisely defined vocabulary, syntax, andsemantics.

©Ian Sommerville 2000^

Software Engineering, Chapter 10

Slide 5

Acceptance and use l^ Formal methods have not become^ main-stream

as was once predicted,

especially in the US.

Some reasons

why:^ 1. Less costly techniques

(e.g., inspections / reviews) have beensuccessful at increasing systemquality. (Hence, the

need^ for formal methods has been reduced.)

(Cont’d)

©Ian Sommerville 2000^

Software Engineering, Chapter 10

Slide 7

Acceptance and use (cont’d)^ 4. Formal methods are

hard to scale up for very large systems. (Although thisis rarely necessary.)5. Start-up costs are high.6. Thus, the^ risks

of adopting formal methods^ on most projects

outweigh the benefits.

©Ian Sommerville 2000^

Software Engineering, Chapter 10

Slide 8

Acceptance and use (cont’d) l^ However, formal specification is an excellentway to^ find (at least some types of)^ requirements errors

and to^ express requirements unambiguously

l^ Projects which use formal methodsinvariably report

fewer errors

in the delivered software.

©Ian Sommerville 2000^

Software Engineering, Chapter 10

Slide 10

Formal specification in thesoftware process^ Requirementsspecification

Formalspecification Systemmodelling

Ar chitecturaldesign Requirementsdefinition

High-le veldesign

elicitation

©Ian Sommerville 2000^

Software Engineering, Chapter 10

Slide 11

Formal specificationtechniques l^ Algebraic approach

-^ system is specified in terms of its operations and their relationships via axioms. l Model-based approach

(including simple pre- and post-conditions) –

system is specified in terms of a^ state model

and operations are defined in terms of

changes to system state.

©Ian Sommerville 2000^

Software Engineering, Chapter 10

Slide 13

Use of formal specification l^ Formal specification is a rigorous process^ and^ requires more effort in the early^ phases^ of software development. l^ This reduces requirements errors asambiguities

, incompleteness

, and inconsistencies

are discovered and resolved. l Hence,^ rework

due to requirements problems^ is greatly reduced.

©Ian Sommerville 2000^

Software Engineering, Chapter 10

Slide 14

Development costs with formalspecification Design andImplementation^ Specification

Validation Specification

ValidationDesign andImplementation Cost Without formalspecification

With formalspecification

©Ian Sommerville 2000^

Software Engineering, Chapter 10

Slide 16

Sub-system interfaces^ Sub-systemA^

Sub-systemB Interface^ objects

©Ian Sommerville 2000^

Software Engineering, Chapter 10

Slide 17

The structure of an algebraicspecification^ sort^ < name >^ imports^ < LIST OF SPECIFICATION NAMES >^ Informal description

of the sor t and its operations Operation signatures

setting out the names and the types of < SPECIFICATION NAME > (Gener ic Parameter)the parameters to the operations defined over the sort Axioms^ defining the operations over the sort

©Ian Sommerville 2000^

Software Engineering, Chapter 10

Slide 19

Types of operations l^ Constructor operations

:^ operations which create / modify^

entities of the type l^ Inspection operations

:^ operations which evaluate^ entities of the type being specified l Rule of thumb

for defining axioms:

define an axiom which sets out what is always true for each^ inspection

operation over each (primitive) constructor^ operation.

©Ian Sommerville 2000^

Software Engineering, Chapter 10

Slide 20

Operations on a (FIFO linear)“List” abstract data type l^ Constructor operations

which create or modify sort List:

Create ,^ Cons

and^ Tail l^ Inspection operations

which discover attributes of sort List:

Head^ and^ Length (LISP^ fans:LISP^ fans:LISP^ fans:LISP^ fans:

Tail^ =^ CDR,

Head^ =^ CAR) l^ Tail is not a

primitive^ operation since it canbe defined using Create and Cons. (Thus,axioms are not required for Head andLength over Tail.)