P1246990949iYJhm

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
• must be complete and detailed
• this is the sole source of information available
  for the design
• Free of omissions, contradictions, ambiguities
• these will be carried into the design and
  implementation

5
Specification Phase

• Goal
• techniques for representing the target product
  in a sufficiently nontechnical to be intelligble
  to the client yet precise enough to result in a
  fault-free product begin delivered to the client
  at the end of the development cycle.

6
Specification Phase

• The specifications document is a contract between
  client and developer.
• contains constraints that the product has to
  satisfy.

7
Specification Document

• Constraints
• Cost
• Time
• A deadline is specified for delivering the
  product
• Parallel running
• Product is normally installed in such a way that
  it can run in parallel with the existing product
  until customer is satisfied.

8
Specification Document

• Constraints (cont)
• Portability
• product might have to run on multiple
  hardware/Oses
• Reliability
• Example 95 of all queries of Type 4 shall be
  answered within 0.25 seconds.
• Normally expressed in probabilistic terms because
  the response time depends on the current load
• Rapid response time

9
Specification Document (contd)

• Acceptance criteria
• must reflect viewpoint of both client and
  developer
• Vital to spell out series of tests
• Product passes tests, deemed to satisfy
  specifications
• Some are restatements of constraints

10
Specification Document (contd)

• Example acceptance criteria
• Client might supply the developer with a
  description of the data that the product will
  handle.
• Appropriate acceptance criteria
• the product correctly processes data of this type
  and filters out nonconforming (that is,
  erroneous) data.

11
Solution Strategy

• once the development team fully understands the
  problem, possible solution strategies can be
  suggested.
• the requirements document is used to inform the
  development team as to what the problem is

12
Solution Strategy

• Solution strategy a general approach to
  building the product.
• Examples
• use an online database
• use a conventional flat file and extract the
  required information using overnight batch runs.

13
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 can justify
  their choices
• To prevent unwise new solutions during the
  maintenance phase

14
Solution Strategy

• After one or more solution strategies are
  identified must make a decision.
• 2-stage decision
• First, whether the client should be advised to
  computerized
• use cost-benefit analysis (section 5.2)
• Second, which solution strategy should be
  adopted.
• client must inform the development team which
  optimization criterion is to be used
• e.g., minimize total cost to client or maximize
  return on investment.
• Developers advise client which solution best
  satisfies the optimization criterion.

15
Solution Strategy

• in your term project, the solution strategy has
  already been developed.
• you will develop a flat file, interactive product

16
Informal Specifications

• Example
• The management of a retail chain sets a target
  sales figure fore each store for each month.
• if a store does not meet this target, a report
  is printed.

17
Informal Specifications

• Example specifications
• If sales for current month are below target
  sales, then 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

18
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

19
Meaning of Specification

• 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

20
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 not what management wanted!

21
But Specifications Do Not Say This

• Difference between target sales and actual
  sales for the current month is under 5
• Again, no mention of difference of percentage
• Ambiguityshould the last clause read percentage
  difference of 5 or difference of
  5,000 or something else entirely?
• Style is poor

22
Informal Specifications (contd)

• Claim
• This cannot arise with professional
  specifications writers
• Refutation
• Text Processing case study

23
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

24
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

25
Episode 3

• 1971 London found 3 more faults
• Including procedure does not terminate unless a
  word longer than maxpos characters is encountered

26
Episode 4

• 1975 Goodenough and Gerhart found 3 further
  faults
• Includinglast word will not be output unless it
  is followed by blank or nl
• Of these 7 faults, 2 are specification faults
• e.g., Naurs specifications do not state what
  happens if the input includes two successive
  adjacent breaks (blank or newline characters)

27
Episode 4

• Goodenough and Gerhart then produced new set of
  specifications, about four times longer than
  Naurs

28
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?

29
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

30
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

31
Structured Systems Analysis

• In 1970s graphical analysis techniques were
  developed and became popular.
• Goal is to informally specify product with
  diagrams.
• informal enough that client can understand the
  pictures
• formal enough that developer can create a design
  based on the diagrams
• formal enough to develop tests that can verify
  that the specifications have been met

32
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

33
Structured Systems Analysis

• In the 90s three of the most well-known OOA
  software engineers got together and combined
  their methodologies.
• Developed UML (unified modeling language) a
  visual notation for representing an
  object-oriented software product.
• this is the most popular language used in almost
  all OOA methodologies

34
Structured Systems Analysis

• The three amigos also developed a UML-based
  software development methodology the Unified
  Software Development Process.
• A different OOA methodology is Catalysis
  developed by DSouze and Wills.

35
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?

36
Structured Systems Analysis Case Study

• Better question
• What sections?
• accounts payable? accounts receivable?
  inventory?
• Still better
• How? Batch, or online? In-house or out-service?

37
Case Study (contd)

• Fundamental issue
• What is Sallys objective in computerizing her
  business?
• Must determine requirements before can determine
  specifications.
• Because she sells software?
• Then she needs an in-house system with sound and
  light effects to show off the possibilities of a
  computer

38
Case Study (contd)

• Because she uses her business to launder hot
  money?
• Then she needs a product that keeps five
  different sets of books, and has no audit trail
• Assume Computerization in order to make more
  money
• Must do a cost/benefit analysis for each section
  of business

39
Case Study (contd)

• The danger of many standard approaches
• First produce the solution, then find out what
  the problem is!
• Once the needs (requirements) are set
• determine the logical data flow (what happens)
• not the physical data flow (how it happens)

40
Case Study (contd)

• Gane and Sarsens method
• Nine-step method
• Stepwise refinement is used in many steps

41
Case Study (contd)

• Draw a Data Flow Diagram. Shows the flow of
  information in a system.
• Decide what sections to computerize and how
  (batch or online).
• Determine the details of the data flows. What
  data items go into each flow.
• Define the logic of the process. What happens
  within each process.

42
Case Study (contd)

• Define the data stores. The exact contents of
  each store and its representation (format).
• Define the physical resources. Blocking factors,
  file name, organization (sequential, indexed,
  etc), storage medium, records down to field
  level, etc.
• Determine the input-output specifications.
  Input/Output form components and screens (not
  necessarily the detailed layout).

43
Case Study (contd)

• Determine the sizing. Volume of input (daily or
  hourly0, frequency of each report and deadline,
  size and number of records of each type that pass
  between CPU and mass storage, size of each file.
• Determine the Hardware requirements. From sizing
  information in step 8 can determine mass storage
  requirements. etc.

44
Case Study (contd)

• Data flow diagram (DFD) shows logical data flow
• what happens, not how it happens
• (DFD) constructed by identifying the data flows
  within the requirements document or rapid
  prototype

45
Case Study (contd)

• Data flow diagram (DFD) shows logical data flow

46
Step 1. Draw the DFD

• First refinement
• Infinite number of possible implementations

47
Step 1. Draw the DFD

• implementation 1 manual system

48
Step 1. Draw the DFD

• implementation 2 computer system

49
Step 1 (contd)

• Second refinement add flow for pending orders
• pending orders scanned daily (by computer or
  manually)

50
Step 1 (contd)

• Portion of third refinement
• Add accounts receivable.

51
Step 1 (contd)

• Final DFD add accounts payable, software
  received, etc.
• Larger, But easily understood by client
• Larger DFDs
• Hierarchy
• Box becomes DFD at lower level

52
Step 1 (contd)

• 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

53
Step 2. Decide What Parts to Computerize

• Depends on how much client is prepared to spend
• do cost-benefit analysis to different strategies
• Example do batch or online for each DFD box?
• Large volumes, tight controls
• Batch
• Small volumes, in-house microcomputer
• Online
• The DFD is compatible with all solutions

54
Step 3. Refine Data Flows

• Data items for each data flow
• Refine each flow stepwise
• In the example, consider the data flow order
• refine this to
• order
• order identification
• customer details
• package details
• Refine further
• Need a data dictionary

55
Step 3. Refine Data Flows (contd)

• Sample data dictionary entries

56
Step 4. Refine Logic of Processes

• Must explore each process
• Example 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 more precise than
  English

57
Step 4 (contd)

• Advantage of decision tree
• Missing items are quickly apparent
• Can also use decision tables
• CASE tools exist for automatic translation into
  code

58
Step 5. Refine Data Stores

• Define exact contents and representation (format)
  of each store
• COBOL specify to pic level
• Ada specify digits or delta
• Specify where immediate access is required
• example want to validate orders online
• Customer may order a package by
• name (MS Office)
• function (accounting packages)
• machine (for a P-4)
• but not by price (what do you have for 149.95?)

59
Step 5. Refine Data Stores

• Specify where immediate access is required
• Data immediate access diagram (DIAD)
• previous slide example access to PACKAGE DATA
  is by name, function or machine.

60
Step 6. Define Physical Resources

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

61
Step 7. Determine Input/Output Specs

• Specify input forms, input screens, printed output

62
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

63
Step 9. Hardware Requirements

• DASD requirements
• Mass storage for back-up
• Input needs
• Output devices
• Is existing hardware adequate?
• If not, recommend buy/lease

64
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

go to testing
65
Entity-Relationship Diagrams

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

66
Entity-Relationship Diagrams (contd)

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

67
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.

go to testing
68
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

69
Finite State Machines (contd)

• Transition table

70
Extended Finite State Machines

• Extend FSM with global predicates
• Transition rules have form
• state and event and predicate Þ new state

71
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

72
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

73
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

74
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)

75
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

76
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

77
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

78
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

79
Elevator Problem FSM (contd)
80
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)

81
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

82
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

83
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

84
Petri Nets

• A major difficulty with specifying real-time
  systems is timing
• Synchronization problems
• Race conditions
• Deadlock
• Often a consequence of poor specifications

85
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

86
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

87
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

88
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

89
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

90
Petri Nets (contd)

• Petri nets are indeterminate
• Suppose t1 fires
• Resulting marking is (2,1,0,0)

91
Petri Nets (contd)

• Now only t2 is enabled
• It fires
• Marking is now (2,0,2,0)

92
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
  )

93
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

94
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

95
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

96
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

97
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

98
Elevator Problem Petri Net (contd)

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

99
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

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

102
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

103
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

104
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

105
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

106
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

107
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)

108
Elevator Problem Z (contd)

• Schema Button_State

109
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!)

110
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

111
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

112
Analysis of Z

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

113
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

114
Other Formal Methods

• Anna
• Ada
• Gist, Refine
• Knowledge-based
• VDM
• Denotational semantics
• CSP
• Sequence of events
• Executable specifications
• High squiggle factor

115
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

116
Comparison of Specification Techniques (contd)
117
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

118
Which Specification Method to Use?

• Depends on the
• Project
• Development team
• Management team
• Myriad other factors
• It is unwise to ignore the latest developments

119
Testing during the Specification Phase

• Specification inspection by inspection team
• Checklist
• have hardware resources been specified?
• Have the acceptance criteria been specified?
• etc.
• Doolan 1992
• 2 million lines of FORTRAN
• 1 hour of inspecting saved 30 hours of
  execution-based testing

120
CASE Tools for the Specification Phase

• Graphical tool
• Data dictionary
• Integrate them
• Specification method without CASE tools fails
• SREM

121
CASE Tools for the Specification Phase

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

122
Metrics for the Specification Phase

• Five fundamental metrics
• Quality
• Fault statistics from inspection
• 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

123
Air Gourmet Case Study Structured Sys. Anal.

• Data flow diagram reflects centrality of SPECIAL
  MEAL DATA

124
Air Gourmet Case Study Structured Sys. Anal.

• step 3. put in the Details of the Data Flows.
• special meal type (child, diabetic, Halaal,
  Kosher, lactose free, low calorie, low
  cholesterol, low fat, low protein, low sodium,
  sea food, vegan, vegetarian)
• passenger details
• reservation identifier (6 uppercase letters)
• passenger name
• first name (up to 15 char)
• middle initial (1 char)
• last name (up to 15 char)
• suffix (up to 5 char)
• etc.

125
Air Gourmet Case Study Structured Sys. Anal.

• step 4. Define the logic of the process.
• enter reservation
• obtain the reservation details from the
  passenger.
• generate and scan onboard meal report
• the flight attendant marks each meal that has
  been loaded. The corresponding meal onboard
  status field later is set to Y.
• generate onboard report
• The special meal requests for a specific flight
  number are printed out.
• etc.

126
Air Gourmet Case Study Structured Sys. Anal.

• step 5. Define the Data Stores.
• Reservation Data (187 bytes)
• reservation identifier (6 uppercase letters)
• flight number (3 digits, right justified, zero
  filled)
• etc.
• Special Meals Data (192 bytes)
• Reservation Data (see earlier)
• was passenger onboard flight? (1 char)
• etc.
• Immediate access to Reservation Data is by
  reservation identifier (primary), also by last
  name and seat number.
• Immediate access to Special Meals Data is by
  reservation identifier (primary) and also by last
  name, seat number, and meal type.

127
Air Gourmet Case Study Structured Sys. Anal.

• step 7. Determine the input/output
  specifications
• Input screens will be designed for the following
  processes
• enter reservation
• Input general reservation details.
• generate caterer report
• Input flight number and flight date.
• generate percentages report
• Input start date and end date
• generate ..
• The following reports will be generated
• onboard report
• passenger name, flight date, flight number
• etc.

128
Air Gourmet Case Study SPMP

• The Software Project Management Plan is given in
  Appendix F

129
Challenges of the Specification Phase

• A specification document must be
• Informal enough for the client and
• Formal enough for the development team
• permanent conflict between these two

130
Challenges of the Specification Phase

• The specification phase (what) should not cross
  the boundary into the design phase (how)
• Example client requires a response time of no
  more than 0.05 seconds when a certain network
  routing computation is performed.
• Spec must only state this fact
• Spec must not state which algorithm must be used
  to achieve this.
• Spec must list all constraints, but never how to
  achieve them

131
Challenges of the Specification Phase

• Do not try to assign modules to process boxes of
  DFDs until the design phase
• Analysis phase can show actions and data
• An action box does not denote an object
• One action box can be broken into several objects
• Also several actions can be combined into one
  object.
• In design phase, must study specifications as a
  whole and decide how to break these down into
  objects.