slide 11.1 chapter 11 specification phase. slide 11.2 overview l the specification document l...

1

CHAPTER 11

SPECIFICATION PHASE

2

Overview

The specification document Informal specifications Structured systems analysis Other semiformal techniques Entity-relationship modeling Finite state machines Petri nets Other formal techniques

3

Overview (contd)

Comparison of specification techniques Testing during the specification phase CASE tools for the specification phase Metrics for the specification phase Air Gourmet Case Study: structured

systems analysis Air Gourmet Case Study: software

project management plan Challenges of the specifications phase

4

Specification Phase

Specification document must be – Informal enough for client– Formal enough for developers– Free of omissions, contradictions, ambiguities

5

Specification Document

Constraints– Cost– Time– Parallel running – Portability– Reliability– Rapid response time

6

Specification Document (contd)

Acceptance criteria– Vital to spell out series of tests– Product passes tests, deemed to satisfy specifications– Some are restatements of constraints

7

Solution Strategy

General approach to building the product Find strategies without worrying about

constraints Modify strategies in the light of constraints, if

necessary Keep a written record of all discarded

strategies, and why they were discarded– To protect the specification team – To prevent unwise new “solutions” during the

maintenance phase

8

Informal Specifications

Example“If sales for current month are below target sales, then a report is to be printed, unless difference between target sales and actual sales is less than half of difference between target sales and actual sales in previous month, or if difference between target sales and actual sales for the current month is under 5%”

9

Meaning of Specification

Sales target for January was $100,000, actual sales were only $64,000 (36% below target)– Print report

Sales target for February was $120,000, actual sales were only $100,000 (16.7% below target)– Percentage difference for February (16.7%) less than

half of previous month’s percentage difference (36%), do not print report

Sales target for March was $100,000, actual sales were $98,000 (2% below target)– Percentage difference < 5%, do not print

10

But Specifications Do Not Say This

“[D]ifference between target sales and actual sales”– There is no mention of percentage difference

Difference in January was $36,000, difference in February was $20,000– Not less than half of $36,000, so report is printed

“[D]ifference … [of] 5%” – Again, no mention of percentage

Ambiguity—should the last clause read “percentage difference … [of] 5%” or “difference … [of] $5,000” or something else entirely?

Style is poor

11

Informal Specifications (contd)

Claim– This cannot arise with professional specifications writers

Refutation– Text Processing case study

12

Episode 1

1969 — Naur PaperGiven a text consisting of words separated by blank or by nl (new line) characters, convert it to line-by-line form in accordance with following rules:

(1) line breaks must be made only where given text has blank or nl ;

(2) each line is filled as far as possible, as long as

(3) no line will contain more than maxpos characters

Naur constructed a procedure (25 lines of Algol 60), and informally proved its correctness

13

Episode 2

1970 — Reviewer in Computing Reviews– First word of first line is preceded by a blank unless the

first word is exactly maxpos characters long

14

Episode 3

1971 — London found 3 more faults– Including: procedure does not terminate unless a word

longer than maxpos characters is encountered

15

Episode 4

1975 — Goodenough and Gerhart found 3 further faults– Including—last word will not be output unless it is

followed by blank or nl Goodenough and Gerhart then produced new set

of specifications, about four times longer than Naur’s

16

Case Study (contd)

1985 — Meyer detected 12 faults in Goodenough and Gerhart’s specifications

Goodenough and Gerhart’s specifications – Were constructed with the greatest of care– Were constructed to correct Naur’s specifications– Went through two versions, carefully refereed– Were written by experts in specifications– With as much time as they needed– For a product about 30 lines long

What chance do we have of writing fault-free specifications for a real product?

17

Episode 5

1989 — Schach found fault in Meyer’s specifications– Item (2) of Naur’s original requirement (“each line

is filled as far as possible”) is not satisfied

18

Informal Specifications

Conclusion– Natural language is not a good way to specify product

Fact– Many organizations still use natural language, especially

for commercial products Reasons

– Uninformed management– Undertrained computer professionals– Management gives in to client pressure– Management is unwilling to invest in training

19

Structured Systems Analysis

Three popular graphical specification methods of ’70s– DeMarco– Gane and Sarsen– Yourdon

All equivalent All equally good Many U.S. corporations use them for commercial

products Gane and Sarsen used for object-oriented design

20

Structured Systems Analysis Case Study

Sally’s Software Store buys software from various suppliers and sells it to the public. Popular software packages are kept in stock, but the rest must be ordered as required. Institutions and corporations are given credit facilities, as are some members of the public. Sally’s Software Store is doing well, with a monthly turnover of 300 packages at an average retail cost of $250 each. Despite her business success, Sally has been advised to computerize. Should she?

Better question– What sections?

Still better– How? Batch, or online? In-house or out-service?

21

Case Study (contd)

Fundamental issue – What is Sally’s objective in computerizing her business?

Because she sells software?– She needs an in-house system with sound and light

effects Because she uses her business to launder “hot”

money?– She needs a product that keeps five different sets of

books, and has no audit trail Assume: Computerization “in order to make more

money” – Cost/benefit analysis for each section of business

22

Case Study (contd)

The danger of many standard approaches – First produce the solution, then find out what the

problem is! Gane and Sarsen’s method

– Nine-step method – Stepwise refinement is used in many steps

23

Case Study (contd)

Data flow diagram (DFD) shows logical data flow – “what happens, not how it happens”

24

Step 1. Draw the DFD

First refinement Infinite number of possible interpretations

25

Step 1 (contd)

Second refinement pending orders scanned daily

26

Step 1 (contd)

Portion of third refinement

27

Step 1 (contd)

Final DFD – Larger, But easily understood by client

Larger DFDs– Hierarchy– Box becomes DFD at lower level

Frequent problem– Process P at level L, expanded at level L+1– Correct place for sources and destinations of data for

process P is level L+1– Clients cannot understand DFD—sources and

destinations of data for P are “missing” Solution

– Draw “correct” DFD, modify by moving sources and destinations of data one or more levels up

28

Step 2. Decide What Parts to Computerize

Depends on how much client is prepared to spend Large volumes, tight controls

– Batch Small volumes, in-house microcomputer

– Online Cost/benefit analysis

29

Step 3. Refine Data Flows

Data items for each data flow Refine each flow stepwise Refine further Need a data dictionary

30

Step 3. Refine Data Flows (contd)

Sample data dictionary entries

31

Step 4. Refine Logic of Processes

Have process give educational discount

– Sally must explain discount for educational institutions– 10% on up to 4 packages, 15% on 5 or more

Translate into decision tree

32

Step 4 (contd)

Advantage of decision tree– Missing items are quickly apparent

Can also use decision tables – CASE tools for automatic translation

33

Step 5. Refine Data Stores

Define exact contents and representation (format) – COBOL: specify to pic level– Ada: specify digits or delta

Specify where immediate access is required– Data immediate access diagram (DIAD)

34

Step 6. Define Physical Resources

For each file, specify– File name– Organization (sequential, indexed, etc.)– Storage medium– Blocking factor– Records (to field level)

35

Step 7. Determine Input/Output Specs

Specify input forms, input screens, printed output

36

Step 8. Perform Sizing

Numerical data for Step 9 to determine hardware requirements– Volume of input (daily or hourly)– Size, frequency, deadline of each printed report– Size, number of records passing between CPU

and mass storage– Size of each file

37

Step 9. Hardware Requirements

DASD requirements Mass storage for back-up Input needs Output devices Is existing hardware

adequate? If not, recommend buy/lease

38

However

Response times cannot be determined Number of I/O channels can only be guessed CPU size and timing can only be guessed Nevertheless, no other method provides these

data for arbitrary products

The method of Gane and Sarsen/De Marco/Yourdon has resulted in major improvements in the software industry

39

Entity-Relationship Diagrams

Semi-formal technique Widely used for specifying databases Used for object-oriented analysis

40

Entity-Relationship Diagrams (contd)

Many-to-many relationship More complex entity-relationship diagrams

41

Formality versus Informality

Informal method– English (or other natural language)

Semiformal methods– Gane & Sarsen/DeMarco/Yourdon– Entity-Relationship Diagrams– Jackson/Orr/Warnier, – SADT, PSL/PSA, SREM, etc.

Formal methods– Finite State Machines– Petri Nets– Z– ANNA, VDM, CSP, etc.

42

Finite State Machines

Case studyA safe has a combination lock that can be in one of three positions, labeled 1, 2, and 3. The dial can be turned left or right (L or R). Thus there are six possible dial movements, namely 1L, 1R, 2L, 2R, 3L, and 3R. The combination to the safe is 1L, 3R, 2L; any other dial movement will cause the alarm to go off

43

Finite State Machines (contd)

Transition table

44

Extended Finite State Machines

Extend FSM with global predicates Transition rules have form

state and event and predicate new state

45

Elevator Problem

A product is to be installed to control n elevators in a building with m floors. The problem concerns the logic required to move elevators between floors according to the following constraints:

1. Each elevator has a set of m buttons, one for each floor. These illuminate when pressed and cause elevator to visit corresponding floor. Illumination is canceled when corresponding floor is visited by elevator

2. Each floor, except the first and the top floor, has 2 buttons, one to request an up-elevator, one to request a down-elevator. These buttons illuminate when pressed. The illumination is canceled when an elevator visits the floor, then moves in the desired direction

3. If an elevator has no requests, it remains at its current floor with its doors closed

46

Elevator Problem: FSM

Two sets of buttons– Elevator buttons—in each elevator, one for each floor– Floor buttons—two on each floor, one for up-elevator,

one for down-elevatorEB(e, f): Elevator Button in elevator e pressed to request

floor f

47

Elevator Buttons (contd)

Two statesEBON(e, f): Elevator Button (e,f) ON

EBOFF(e,f): Elevator Button (e,f) OFF

– If button is on and elevator arrives at floor f, then light turned off

– If light is off and button is pressed, then light comes on

48

Elevator Buttons (contd)

Two eventsEBP(e,f): Elevator Button (e,f) Pressed

EAF(e,f): Elevator e Arrives at Floor f

Global predicateV(e,f): Elevator e is Visiting (stopped at) floor f

Transition RulesEBOFF(e,f) and EBP(e,f) and not V(e,f) EBON(e,f)

EBON(e,f) and EAF(e,f) Þ EBOFF(e,f)

49

Floor Buttons

Floor buttonsFB(d, f): Floor Button on floor f that requests elevator traveling in

direction d

StatesFBON(d, f): Floor Button (d, f) ON

FBOFF(d, f): Floor Button (d, f) OFF

– If floor button is on and an elevator arrives at floor f, traveling in correct direction d, then light is turned off

– If light is off and a button is pressed, then light comes on

50

Floor Buttons (contd)

EventsFBP(d, f): Floor Button (d, f) PressedEAF(1..n, f): Elevator 1 or … or n Arrives at Floor f

PredicateS(d, e, f): elevator e is visiting floor fDirection of motion is up (d = U), down (d = D), or no

requests are pending (d = N)

Transition rulesFBOFF(d, f) and FBP(d, f) and not S(d, 1..n, f) FBON(d, f)FBON(d, f) and EAF(1..n, f) and S(d, 1..n, f) FBOFF(d, f),

d = U or D

51

Elevator Problem: FSM (contd)

State of elevator consists of component substates, including:– Elevator slowing– Elevator stopping– Door opening– Door open with timer running– Door closing after a timeout

52


Assume elevator controller moves elevator through substates– Three elevator states

M(d, e, f): Moving in direction d (floor f is next)

S(d, e, f): Stopped (d-bound) at floor f

W(e,f): Waiting at floor f (door closed)

– For simplicity, three stopped states S(U, e, f), S(N, e, f), and S(D, e, f) are grouped into one larger state

53


54


EventsDC(e,f): Door Closed for elevator e, floor f

ST(e,f): Sensor Triggered as elevator e nears floor f

RL: Request Logged (button pressed)

Transition RulesIf elevator e is in state S(d, e, f) (stopped, d-bound, at floor f), and doors close, then elevator e will move up, down, or go into wait state

DC(e,f) and S(U, e, f) M(U, e, f+1)

DC(e,f) and S(D, e, f)M(D, e, f-1)

DC(e,f) and S(N, e, f) W(e,f)

55

Power of FSM to Specify Complex Systems

No need for complex preconditions and postconditions

Specifications take the simple form current state and event and predicate next state

56

Power of FSM to Specify Complex Systems

Using an FSM, a specification is– Easy to write down– Easy to validate– Easy to convert into design– Easy to generate code automatically– More precise than graphical methods– Almost as easy to understand– Easy to maintain

However– Timing considerations are not handled

57

Who Is Using FSMs?

Commercial products– Menu driven– Various states/screens– Automatic code generation a major plus

System software– Operating system– Word processors– Spreadsheets

Real-time systems– Statecharts are a real-time extension of

FSMs» CASE tool: Rhapsody

58

Petri Nets

A major difficulty with specifying real-time systems is timing– Synchronization problems– Race conditions– Deadlock

Often a consequence of poor specifications

59

Petri Nets (contd)

Petri nets– Powerful technique for specifying

systems with potential timing problems A Petri net consists of four parts:

– Set of places P– Set of transitions T– Input function I

– Output function O

60

Petri Nets (contd)

Set of places P is {p1, p2, p3, p4}

Set of transitions T is {t1, t2}

Input functions:I(t1) = {p2, p4}

I(t2) = {p2}

Output functions:O(t1) = {p1}

O(t2) = {p3, p3}

61

Petri Nets (contd)

More formally, a Petri net is a 4-tuple C = (P, T, I, O)

P = {p1, p2,…,pn} is a finite set of places, n ≥ 0

T = {t1, t2,…,tm} is a finite set of transitions, m ≥ 0, with P and T disjoint

I : T P∞ is input function, mapping from transitions to bags of places

O : T P∞ is output function, mapping from transitions to bags of places

(A bag is a generalization of sets which allows for multiple instances of element in bag, as in example above)

Marking of a Petri net is an assignment of tokens to that Petri net

62

Petri Nets (contd)

Four tokens, one in p1, two in p2, none in p3, and one in p4

– Represented by vector (1,2,0,1)

Transition is enabled if each of its input places has as many tokens in it as there arcs from the place to that transition

63

Petri Nets (contd)

Transition t1 is enabled (ready to fire)– If t1 fires, one token is removed from p2 and one from

p4, and one new token is placed in p1

Important: Number of tokens is not conserved Transition t2 is also enabled

64

Petri Nets (contd)

Petri nets are indeterminate– Suppose t1 fires

Resulting marking is (2,1,0,0)

65

Petri Nets (contd)

Now only t2 is enabled – It fires

Marking is now (2,0,2,0)

66

Petri Nets (contd)

More formally, a marking M of a Petri net C = (P, T, I, O) is a function from the set of places P to the non-negative integers N

M : P N

A marked Petri net is then 5-tuple (P, T, I, O, M )

67

Petri Nets (contd)

Inhibitor arcs– Inhibitor arc is marked by small circle, not arrowhead

Transition t1 is enabled – In general, transition is enabled if at least one token on

each (normal) input arc, and no tokens on any inhibitor input arcs

68

Elevator Problem: Petri Net

Product is to be installed to control n elevators in a building with m floors – Each floor represented by place Ff, 1 f m

– Elevator represented by token

– Token in Ff denotes that an elevator is at floor Ff

69

Elevator Problem: Petri Net (contd)

First constraint 1. Each elevator has a set of m buttons, one for each floor. These illuminate when pressed and cause the elevator to visit the corresponding floor. The illumination is canceled when the corresponding floor is visited by an elevator

Elevator button for floor f is represented by place EBf, 1 f m

Token in EBf denotes that the elevator button for floor f is illuminated

70


A button must be illuminated the first time button is pressed and subsequent button presses must be ignored

If button EBf is not illuminated, no token in place and transition EBf pressed is enabled– Transition fires, new token is placed in EBf

Now, no matter how many times button is pressed, transition EBf pressed cannot be enabled

71


When elevator reaches floor g, token is in place Fg, transition Elevator in action is enabled, and then fires– Tokens in EBf and Fg removed

– This turns off light in button EBf

– New token appears in Ff

– This brings elevator from floor g to floor f

72


Motion from floor g to floor f cannot take place instantaneously– Timed Petri nets

73


Second constraint2. Each floor, except the first and the top floor, has 2 buttons, one to request an up-elevator, one to request a down-elevator. These buttons illuminate when pressed. The illumination is canceled when the elevator visits the floor, and then moves in desired direction

Floor buttons represented by places FBuf and FBd

f

74


75


The situation when an elevator reaches floor f from floor g with one or both buttons illuminated– If both buttons are illuminated, only one is turned off– (A more complex model is needed to ensure that the

correct light is turned off)

76


Third constraintC3. If an elevator has no requests, it remains at its current floor with its doors closed

If no requests, no Elevator in action transition is enabled

77

Petri Nets (contd)

Petri nets can also be used for design Petri nets possess the expressive power

necessary for specifying timing aspects of real-time systems

78

Z (“zed”)

Formal specification language High squiggle factor Z specification consists of four sections:

– 1. Given sets, data types, and constants– 2. State definition– 3. Initial state– 4. Operations

79

Elevator Problem: Z

1. Given Sets

Sets that need not be defined in detail– Names appear in brackets – Here we need the set of all buttons– Specification begins

[Button]

80

Elevator Problem: Z (contd)

2. State Definition

Z specification consists of a number of schemata– Schema consists of group of variable declarations, plus– List of predicates that constrain values of variables

81


Four subsets of Button– The floor buttons– The elevator buttons– buttons (the set of all buttons in the elevator problem)– pushed (the set of buttons that have been pushed)

82


Schema Button_State

83


3. Initial State

State when the system is first turned on

Button_Init [Button_State' | pushed' = ]

– (In the above equation, the should be a = with a ^ on top. Unfortunately, this is hard to type in PowerPoint!)

84


4. Operations

Button pushed for first time is turned on, and added to set pushed

Without third precondition, results would be unspecified

85


If elevator arrives at a floor, the corresponding button(s) must be turned off

The solution does not distinguish between up and down floor buttons

86

Analysis of Z

Most widely used formal specification language– CICS (part)– Oscilloscope– CASE tool– Large-scale projects (esp. Europe)

87

Analysis of Z (contd)

Difficulties– Symbols– Mathematics

Reasons for great success– Easy to find faults in Z specification– Specifier must be extremely precise– Can prove correctness– Only high-school math needed to read Z– Decreases development time– “Translation” clearer than informal

specification

88

Other Formal Methods

Anna – Ada

Gist, Refine– Knowledge-based

VDM – Denotational semantics

CSP – Sequence of events– Executable specifications– High squiggle factor

89

Comparison of Specification Techniques

We must always choose the appropriate specification method

Formal methods– Powerful– Difficult to learn and use

Informal methods– Little power– Easy to learn and use

Trade-off– Ease of use versus power

90

Comparison of Specification Techniques (contd)

91

Newer Methods

Many are untested in practice Risks

– Training costs– Adjustment from classroom to actual project– CASE tools may not work properly

However, possible gains may be huge

92

Which Specification Method to Use?

Depends on the– Project– Development team– Management team– Myriad other factors

It is unwise to ignore the latest developments

93

Testing during the Specification Phase

Specification inspection– Checklist

Doolan [1992]– 2 million lines of FORTRAN– 1 hour of inspecting saved 30 hours of

execution-based testing

94

CASE Tools for the Specification Phase

Graphical tool Data dictionary

– Integrate them Specification method without CASE tools fails

– SREM

95

CASE Tools for the Specification Phase

Typical tools– Analyst/Designer– Software through Pictures– System Architect

96

Metrics for the Specification Phase

Five fundamental metrics Quality

– Fault statistics– Number, type of each fault– Rate of detection

Metrics for “predicting” size of target product– Total number of items in data dictionary– Number of items of each type– Processes vs. modules

97

Air Gourmet Case Study: Structured Sys. Anal.

Data flow diagram reflects centrality of SPECIAL MEAL DATA

See Appendix E for remainder of structured systems analysis

98

Air Gourmet Case Study: SPMP

The Software Project Management Plan is given in Appendix F

99

Challenges of the Specification Phase

A specification document must be– Informal enough for the client; and– Formal enough for the development team

The specification phase (“what”) should not cross the boundary into the design phase (“how”)

Do not try to assign modules to process boxes of DFDs until the design phase

slide 11.1 chapter 11 specification phase. slide 11.2 overview l the specification document l...

Documents