The Software Process

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 months percentage
  difference (36), do not print report
• Sales target for March was 100,000, actual sales
  were 98,000 (2 below target)
• Percentage difference lt 5, do not print

10
But Specifications Do Not Say This

• Difference 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
• Difference of 5
• Again, no mention of percentage
• Ambiguityshould 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 Paper
• Given 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
• Includinglast 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
  Naurs

16
Case Study (contd)

• 1985 Meyer detected 12 faults in Goodenough and
  Gerharts specifications
• Goodenough and Gerharts specifications
• Were constructed with the greatest of care
• Were constructed to correct Naurs 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 Meyers
  specifications
• Item (2) of Naurs 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

• Sallys 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.
  Sallys 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 Sallys 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 Sarsens 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 L1
• Correct place for sources and destinations of
  data for process P is level L1
• Clients cannot understand DFDsources 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 study
• A 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 buttonsin each elevator, one for each
  floor
• Floor buttonstwo on each floor, one for
  up-elevator, one for down-elevator
• EB(e, f) Elevator Button in elevator e
  pressed to request floor f

47
Elevator Buttons (contd)

• Two states
• EBON(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 events
• EBP(e,f) Elevator Button (e,f) Pressed
• EAF(e,f) Elevator e Arrives at Floor f
• Global predicate
• V(e,f) Elevator e is Visiting (stopped at)
  floor f
• Transition Rules
• EBOFF(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 buttons
• FB(d, f) Floor Button on floor f that requests
  elevator traveling in direction d
• States
• FBON(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)

• Events
• FBP(d, f) Floor Button (d, f) Pressed
• EAF(1..n, f) Elevator 1 or or n Arrives at
  Floor f
• Predicate
• S(d, e, f) elevator e is visiting floor f
• Direction of motion is up (d U), down (d
  D), or no requests are pending (d N)
• Transition rules
• FBOFF(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
Elevator Problem FSM (contd)

• 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
Elevator Problem FSM (contd)
54
Elevator Problem FSM (contd)

• Events
• DC(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 Rules
• If 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, f1)
• 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 P8 is input function, mapping from
  transitions to bags of places
• O T P8 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
Elevator Problem Petri Net (contd)

• 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
Elevator Problem Petri Net (contd)

• 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
Elevator Problem Petri Net (contd)

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

73
Elevator Problem Petri Net (contd)

• Second constraint
• 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 the elevator visits
  the floor, and then moves in desired direction
• Floor buttons represented by places FBuf and FBdf

74
Elevator Problem Petri Net (contd)
75
Elevator Problem Petri Net (contd)

• 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
Elevator Problem Petri Net (contd)

• Third constraint
• C3. 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
Elevator Problem Z (contd)

• 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
Elevator Problem Z (contd)

• Schema Button_State

83
Elevator Problem Z (contd)

• 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
Elevator Problem Z (contd)

• 4. Operations
• Button pushed for first time is turned on, and
  added to set pushed
• Without third precondition, results would be
  unspecified

85
Elevator Problem Z (contd)

• 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