Topic 5 Summer 2003 1

ICS 52: Introduction to Software Engineering

Lecture Notes for Summer Quarter, 2003

Michele Rousseau

Topic 5Partially based on lecture notes written by Sommerville, Richard N. Taylor, André van der Hoek, Dan Frost and Doris Tonne. Duplication of course material for any commercial purpose without the written permission of the lecturers is prohibited

Topic 5 Summer 2003 2

Today’s Lecture

Problems in RE Formal Methods

Topic 5 Summer 2003 3

Some Problems with RE Social and organisational factors

– Can dominate the system reqs– Not 1 viewpoint, but many– No systematic way to tackle these factors

Example– Consider a system which allows senior

management to access information without going through middle managers

• Managerial responsibilities. Managers may have no uninterrupted time where they can learn to use the system

• Organisational resistance. Middle managers who will be made redundant may deliberately provide misleading or incomplete information so that the system will fail

Ethnographic studies can help

Topic 5 Summer 2003 4

Domain Requirements

Derived from the application domain and describe system characterisics and features that reflect the domain

Example :Library System– There shall be a standard user interface to all

databases which shall be based on the Z39.50 standard.

– Because of copyright restrictions, some documents must be deleted immediately on arrival. Depending on the user’s requirements, these documents will either be printed locally on the system server for manually forwarding to the user or routed to a network printer.

Topic 5 Summer 2003 5

Domain requirements problems

Understandability– Requirements are expressed in the

language of the application domain– This is often not understood by software

engineers developing the system Implicitness

– Domain specialists understand the area so well that they do not think of making the domain requirements explicit

Topic 5 Summer 2003 6

Requirements change management

Should apply to all proposed changes to the requirements

Principal stages– Problem analysis. Discuss requirements problem

and propose change– Change analysis and costing. Assess effects of

change on other requirements– Change implementation. Modify requirements

document and other documents to reflect change

Topic 5 Summer 2003 7

Enduring and volatile requirements

Enduring requirements. Stable requirements derived from the core activity of the customer organisation. E.g. a hospital will always have doctors, nurses, etc. May be derived from domain models

Volatile requirements. Requirements which change during development or when the system is in use. In a hospital, requirements derived from health-care policy

Topic 5 Summer 2003 8

Problems with NL Specification

Ambiguity– The readers and writers of the requirement must interpret

the same words in the same way. NL is naturally ambiguous so this is very difficult

– Lack of rigor Over-flexibility

– The same thing may be said in a number of different ways in the specification

Lack of modularisation– NL structures are inadequate to structure system

requirements Difficult to Prove Correctness

Topic 5 Summer 2003 9

How Can We Ensure Completeness?

Traceability is concerned with the relationships between requirements, their sources and the system design

Source traceability– Links from requirements to stakeholders

Requirements traceability– Links between dependent requirements

Design traceability– Links from the requirements to the design

Topic 5 Summer 2003 10

Example: Traceability Matrix

U=> Uses , R=>Relates

Topic 5 Summer 2003 11

Alternatives to NL specificationNotation DescriptionStructurednaturallanguage

This approach depends on defining standard forms ortemplates to express the requirements specification.

Designdescriptionlanguages

This approach uses a language like a programming languagebut with more abstract features to specify the requirementsby defining an operational model of the system.

Graphicalnotations

A graphical language, supplemented by text annotations isused to define the functional requirements for the system.An early example of such a graphical language was SADT(Ross, 1977; Schoman and Ross, 1977). More recently, use-case descriptions (Jacobsen, Christerson et al., 1993) havebeen used. I discuss these in the following chapter.

Mathematicalspecifications

These are notations based on mathematical concepts suchas finite-state machines or sets. These unambiguousspecifications reduce the arguments between customer andcontractor about system functionality. However, mostcustomers don’t understand formal specifications and arereluctant to accept it as a system contract. I discuss formalspecification in Chapter 9.

Topic 5 Summer 2003 12

Structured language specifications

A limited form of natural language may be used to express requirements

Removes Ambiguity and Flexibility Imposes Uniformity Often bast supported using a forms-

based approach

Topic 5 Summer 2003 13

Form-based specifications

Definition of the function or entity Description of inputs and where they

come from Description of outputs and where they go

to Indication of other entities required Pre and post conditions (if appropriate) The side effects (if any)

Topic 5 Summer 2003 14

Form-based node specificationECLIPSE/Workstation/Tools/DE/FS/3.5.1

Function Add node

Description Adds a node to an existing design. The user selects the type of node, and its position.When added to the design, the node becomes the current selection. The user chooses the node position bymoving the cursor to the area where the node is added.

Inputs Node type, Node position, Design identifier.

Source Node type and Node position are input by the user, Design identifier from the database.

Outputs Design identifier.

Destination The design database. The design is committed to the database on completion of theoperation.

Requires Design graph rooted at input design identifier.

Pre-condition The design is open and displayed on the user's screen.

Post-condition The design is unchanged apart from the addition of a node of the specified typeat the given position.

Side-effects None

Definition: ECLIPSE/Workstation/Tools/DE/RD/3.5.1

Topic 5 Summer 2003 15

PDL-based requirements definition Requirements may be defined operationally using a language like a

programming language but with more flexibility of expression Most appropriate in two situations

– Where an operation is specified as a sequence of actions and the order is important

– When hardware and software interfaces have to be specified Disadvantages are

– The PDL may not be sufficiently expressive to define domain concepts– The specification will be taken as a design rather than a specification

Topic 5 Summer 2003 16

Part of an ATM specification

class ATM {// declarations herepublic static void main (String args[]) throws InvalidCard {

try {thisCard.read () ; // may throw InvalidCard exceptionpin = KeyPad.readPin () ; attempts = 1 ;while ( !thisCard.pin.equals (pin) & attempts < 4 )

{ pin = KeyPad.readPin () ; attempts = attempts + 1 ;}if (!thisCard.pin.equals (pin))

throw new InvalidCard ("Bad PIN");thisBalance = thisCard.getBalance () ;do { Screen.prompt (" Please select a service ") ;

service = Screen.touchKey () ;switch (service) {

case Services.withdrawalWithReceipt:receiptRequired = true ;

Topic 5 Summer 2003 17

PDL disadvantages

PDL may not be sufficiently expressive to express the system functionality in an understandable way

Notation is only understandable to people with programming language knowledge

The requirement may be taken as a design specification rather than a model to help understand the system

Topic 5 Summer 2003 18

Formal Specification

Techniques for the unambiguous specification of software

Topic 5 Summer 2003 19

Formal methods

Formal specification is part of a more general collection of techniques that are known as ‘formal methods’

Formal Method (FM) =– specification language + formal reasoning

Body of techniques supported by– precise mathematics– powerful analysis tools

Topic 5 Summer 2003 20

Formal Specifications: what and why?

Use of formalisms– e.g., logic, discrete mathematics, formal languages

To describe systems– e.g., system models, constraints, requirements, designs

For broad range of effects– e.g., highly reliable, secure, safe systems and more effective

production With varying levels of use

– guidance: structuring what to say– documentation: unambiguous communication– rigor: formal specification and proofs– mechanisms: proof assistance, testing

Topic 5 Summer 2003 21

Formal Specification inSoftware Development

Formal specifications ground the software development process in the well-defined basis of computer science

Orientation goes from customer to developer Formal specification expressed in language whose

syntax and semantics are formally defined– hierarchical decomposition– mathematical foundation– graphical presentation– accompanied by informal description

Topic 5 Summer 2003 22

Goals and Objectives Requirements Specification

– clarify customer's requirements

– reveal ambiguity, inconsistency, incompleteness System/Software Design

– module identification and decomposition from structural specifications of component relations and behavioral specification of components

– refinement demonstrating that next level of abstraction satisfies higher level

Verification

– proving an implementation satisfies its specification Validation

– testing and debugging Documentation

– communication between specifier, implementor, customer, clients

Topic 5 Summer 2003 23

Benefits of UsingFormal Specifications and Methods

higher quality software verifiability of implementation insight and understanding minimized maintenance and cost automated assistance formal analysis guidance for testing transformation technology reduced liability and risks promotes reusability

Topic 5 Summer 2003 24

Formal Methods are not yet widely used

Reasons– emerging technology with unclear payoff– little experience– lack of automated support– not especially user friendly– too many in-place techniques and tools

Excuses

– high learning curve– mathematical sophistication required– techniques not widely applicable– ignorance of advances

Topic 5 Summer 2003 25

Desirable Properties ofFormal Specifications Consistency

– an implementation exists that satisfies a specification Complete (incrementally)

– all required aspects are specified Unambiguous

– all implementations that satisfy the specification are satisfactory (tradeoffs with completeness)

Inference– the ability to prove properties about implementations that

satisfy a specification– the ability to prove that an implementation satisfies a

specification

Topic 5 Summer 2003 26

Types of Formal Specifications

Behavioral specifications describe constraints on behavior of implementation – e.g.,– functionality– safety– security– performance

Structural specifications describe constraints on internal composition of implementation– module interconnection– uses and is-composed-of– dependence relations

Topic 5 Summer 2003 27

Characteristics of Specification & Support

Model-oriented specifications– specify system behavior by constructing a model in terms of well-defined

mathematical constructs Property-oriented specifications

– specify system behavior in terms of properties that must be satisfied Visual specifications

– specify system behavior and structure by graphical depictions Executable specifications

– specify system behavior completely enough that specifications can run on a computer

Tool support– syntactic checking– model checking– proof checking

Topic 5 Summer 2003 28

Basic Types of Behavioral Specification

Abstract Model Specifications– defines operations in terms of well-defined mathematical

model

Algebraic Specifications– defines a system using a heterogeneous algebra

State Transition Specifications– defines operations in terms of states and transitions

Axiomatic Specifications– defines operations by logical assertions

Topic 5 Summer 2003 29

Formal Specification Languages:Clock Example

+ Initially, the time is midnight, the bell is off, and the alarm is disabled.

+ Whenever the current time is the same as the alarm time and the alarm is enabled, the bell starts ringing.This is the only condition under which the bell begins to ring.

+ The alarm time can be set at any time.+ Only when the alarm is enabled can it be disabled.

+ If the alarm is disabled while the bell is ringing, the bell stops ringing.+ Resetting the clock and enabling or disabling the

alarm are considered to be done instantaneously.

Topic 5 Summer 2003 30

Abstract Model Specifications Explicitly describes behavior in terms of a model using well-defined

types (sets, sequences, relations, functions) and defines behavior by showing effects on model– State is explicit in the model– Objects can be built hierarchically

Specification includes– type definition: syntax of object being specified– model: underlying structure– invariants: properties of modeled object– pre/post conditions: semantics of operations

Pros and Cons– may suggest an implementation– widely applicable because of modeling orientation

Various notations: VDM, Z, RAISE

Topic 5 Summer 2003 31

Abstract Model Specifications:Process using Z

Specification using Z abstract model specifications– 1. Given sets, data types, and constants– 2. State definitions and invariants– 3. Initial state– 4. Operations

Topic 5 Summer 2003 32

Abstract Model Specifications:the Z Notation

specification name [generic parameters]

declaration

predicate

a Z specification is a collection of schemas a schema introduces some sets, data types, constants, and invariant

properties the schema declaration defines each variable's name and type

(syntax) the predicate defines the relationships between the entities that must

always hold (semantics)

Topic 5 Summer 2003 33

Abstract Model Specifications:Z ClockBellStatus: {quiet, ringing}, AlarmStatus: {disabled, enabled}

Clocktime, alarm_time: Nbell: BellStatusalarm: AlarmStatus

InitClockClock

(time = midnight) (bell = quiet) (alarm = disabled)

Tick

Clock

(time = succ(time)) (alarm_time = time) (alarm = enabled) => (bell = ringing)(~((alarm_time = time) (alarm = enabled)) => (bell = bell)(alarm = alarm) (alarm_time = alarm_time)

Topic 5 Summer 2003 34

SetAlarmTimeClocknew_time

alarm_timenew_time?)((alarm_time = time) (alarm = enabled) => (bell = ringing) (~((alarm_time = time) (alarm = enabled)) => (bell = bell)(time = time) (alarm = alarm)

EnableAlarm Clock

(alarm = disabled) => (alarm = enabled) ( (alarm_time= time) => (bell = ringing) (~(alarm_time = time)) => (bell= bell) ) (time= time) (alarm_time= alarm_time)

DisableAlarm Clock

(alarm = enabled) => (alarm = disabled) (bell = quiet) (time = time) (alarm= alarm) (alarm_time= alarm_time)

Topic 5 Summer 2003 35

State Transition Specifications Explicitly describes system behavior by a set of states and defines

operations as transitions between states or observations on state Specification includes

– states: possible values– transitions: semantics by state transformations and observations

Pros and Cons– free of representational details (except augmentations)– state explosion is common– extensions to minimize states and modularize– particularly applicable to control systems, languages, hardware

Graphical as well as textual notations: StateCharts, ASLAN, Paisley,InaJo, Special

Topic 5 Summer 2003 36

State Transition Specifications:State Charts Clock

off

ringing

CLOCK

tick alarm

up

quiet

on

[alarm_time = time]

enabled disabled

time':= succ(time)

time' := midnight

gettime

disabled

Topic 5 Summer 2003 37

Algebraic Specification Objects specified as algebraic sorts in terms of axiomatic relations

between associated operations– State is concealed in objects– Objects can be built hierarchically

Specification includes– sets and functions: syntax and legal constructions– relations between functions

Pros and Cons– only pure functions described (no side effects)– supports extensibility of data abstractions– often hard to comprehend and construct

Various notations: OBJ, Larch, Clear, Anna

Topic 5 Summer 2003 38

Algebraic Specifications: Process

Specification using heterogeneous algebras– 1. establish the sorts (sets) (objects and

attributes)– 2. establish the necessary operations along

with their domains and ranges• constructor operations

• access operations

– 3. establish the axiomatic relations