Post on 14-Mar-2020
Slide 11.1
© The McGraw-Hill Companies, 2002
Object-Oriented and Classical Software
Engineering
Fifth Edition, WCB/McGraw-Hill, 2002
Stephen R. Schachsrs@vuse.vanderbilt.edu
Slide 11.3
© The McGraw-Hill Companies, 2002
Overview
The specification documentInformal specificationsStructured systems analysisOther semiformal techniquesEntity-relationship modelingFinite state machinesPetri netsOther formal techniques
Slide 11.4
© The McGraw-Hill Companies, 2002
Overview (contd)
Comparison of specification techniquesTesting during the specification phaseCASE tools for the specification phaseMetrics for the specification phaseAir Gourmet Case Study: structured systems analysisAir Gourmet Case Study: software project management planChallenges of the specifications phase
Slide 11.5
© The McGraw-Hill Companies, 2002
Specification Phase
Specification document must be – Informal enough for client– Formal enough for developers– Free of omissions, contradictions, ambiguities
Slide 11.6
© The McGraw-Hill Companies, 2002
Specification Document
Constraints– Cost– Time– Parallel running – Portability– Reliability– Rapid response time
Slide 11.7
© The McGraw-Hill Companies, 2002
Specification Document (contd)
Acceptance criteria– Vital to spell out series of tests– If the product passes the tests, it is deemed have
satisfied its specifications– Some acceptance criteria are restatements of
constraints
Slide 11.8
© The McGraw-Hill Companies, 2002
Solution Strategy
A general approach to building the product Find strategies without worrying about constraints Modify strategies in the light of constraints, if necessaryKeep 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
Slide 11.9
© The McGraw-Hill Companies, 2002
Informal Specifications
Example“If the sales for the current month are below the target sales, then a report is to be printed, unless the difference between target sales and actual sales is less than half of the difference between target sales and actual sales in the previous month, or if the difference between target sales and actual sales for the current month is under 5%”
Slide 11.10
© The McGraw-Hill Companies, 2002
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%) is less than
half of the previous month’s percentage difference (36%), so do not print report
Sales target for March was $100,000, actual sales were $98,000 (2% below target)– Percentage difference is under 5%, so do not print
report
Slide 11.11
© The McGraw-Hill Companies, 2002
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 the 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?The style is poor
Slide 11.12
© The McGraw-Hill Companies, 2002
Informal Specifications (contd)
Claim– This cannot arise with professional specifications writers
Refutation– Text Processing case study
Slide 11.13
© The McGraw-Hill Companies, 2002
Episode 1
1969 — Naur PaperGiven a text consisting of words separated by blank or by newline characters, convert it to line-by-line form in accordance with the following rules:(1) line breaks must be made only where the given text contains a blank or newline;(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
Slide 11.14
© The McGraw-Hill Companies, 2002
Episode 2
1970 — Reviewer in Computing Reviews– The first word of the first line is preceded by a blank
unless the first word is exactly maxpos characters long
Slide 11.15
© The McGraw-Hill Companies, 2002
Episode 3
1971 — London found 3 more faults– Including: procedure does not terminate unless a word
longer than maxpos characters is encountered
Slide 11.16
© The McGraw-Hill Companies, 2002
Episode 4
1975 — Goodenough and Gerhart found 3 further faults– Including—last word will not be output unless it is
followed by blank or newline
Goodenough and Gerhart then produced new set of specifications, about four times longer than Naur’s
Slide 11.17
© The McGraw-Hill Companies, 2002
Case Study (contd)
1985 — Meyer detected 12 faults in Goodenough and Gerhart’s specificationsGoodenough 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?
Slide 11.18
© The McGraw-Hill Companies, 2002
Episode 5
1989 — Schach found a fault in Meyer’s specifications– Item (2) of Naur’s original requirement (“each line is
filled as far as possible”) is not satisfied
Slide 11.19
© The McGraw-Hill Companies, 2002
Informal Specifications
Conclusion– Natural language is not a good way to specify product
Fact– Many organizations still use natural language,
especially for commercial productsReasons– Uninformed management– Undertrained computer professionals– Management gives in to client pressure– Management is unwilling to invest in training
Slide 11.20
© The McGraw-Hill Companies, 2002
Structured Systems Analysis
Three popular graphical specification methods of ’70s– DeMarco– Gane and Sarsen– Yourdon
All are equivalentAll are equally goodMany U.S. corporations use them for commercial products Gane and Sarsen’s method is taught here because it is so widely used.
Slide 11.21
© The McGraw-Hill Companies, 2002
Structured Systems Analysis Case Study
Sally’s Software Shop 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 Shop 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?
Slide 11.22
© The McGraw-Hill Companies, 2002
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
effectsBecause she uses her business to launder “hot” money?– She needs a product that keeps five different sets of
books, and has no audit trail
Slide 11.23
© The McGraw-Hill Companies, 2002
Case Study (contd)
We assume: Sally wishes to computerize “in order to make more money” – We need to perform cost/benefit analysis for each
section of her business
Slide 11.24
© The McGraw-Hill Companies, 2002
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
Slide 11.25
© The McGraw-Hill Companies, 2002
Case Study (contd)
Data flow diagram (DFD) shows the logical data flow – “what happens, not
how it happens”Notation:
Slide 11.26
© The McGraw-Hill Companies, 2002
Step 1. Draw the DFD
First refinementInfinite number of possible interpretations
Slide 11.27
© The McGraw-Hill Companies, 2002
Step 1 (contd)
Second refinementPENDING ORDERS is scanned daily
Slide 11.29
© The McGraw-Hill Companies, 2002
Step 1 (contd)
Final DFD – Larger, but it is easily understood by the client
Larger DFDs– Hierarchy– A box becomes a DFD at a lower level
Frequent problem– A process P at level L is expanded at level L+1– The correct place for sources and destinations of data
for process P is level L+1– Clients cannot understand the DFD—sources and
destinations of data for P are “missing”Solution– Draw the “correct” DFD, modify it by moving sources
and destinations of data one or more levels up
Slide 11.30
© The McGraw-Hill Companies, 2002
Step 2. Decide What Parts to Computerize
Depends on how much client is prepared to spendLarge volumes, tight controls– Batch
Small volumes, in-house microcomputer– Online
Cost/benefit analysis
Slide 11.31
© The McGraw-Hill Companies, 2002
Step 3. Refine Data Flows
Data items for each data flowRefine each flow stepwiseRefine furtherNeed a data dictionary
Slide 11.32
© The McGraw-Hill Companies, 2002
Step 3. Refine Data Flows (contd)
Sample data dictionary entries
Slide 11.33
© The McGraw-Hill Companies, 2002
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
Slide 11.34
© The McGraw-Hill Companies, 2002
Step 4 (contd)
Advantage of a decision tree– Missing items are quickly apparent
Can also use decision tables – CASE tools for automatic translation
Slide 11.35
© The McGraw-Hill Companies, 2002
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)
Slide 11.36
© The McGraw-Hill Companies, 2002
Step 6. Define Physical Resources
For each file, specify– File name– Organization (sequential, indexed, etc.)– Storage medium– Blocking factor– Records (to field level)
Slide 11.37
© The McGraw-Hill Companies, 2002
Step 7. Determine Input/Output Specs
Specify input forms, input screens, printed output
Slide 11.38
© The McGraw-Hill Companies, 2002
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
Slide 11.39
© The McGraw-Hill Companies, 2002
Step 9. Hardware Requirements
DASD requirementsMass storage for back-upInput needsOutput devices Is existing hardware adequate?If not, recommend buy/lease
Slide 11.40
© The McGraw-Hill Companies, 2002
However
Response times cannot be determinedNumber of I/O channels can only be guessedCPU size and timing can only be guessedNevertheless, 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
Slide 11.41
© The McGraw-Hill Companies, 2002
Entity-Relationship Diagrams
Semi-formal techniqueWidely used for specifying databasesUsed for object-oriented analysis
Slide 11.42
© The McGraw-Hill Companies, 2002
Entity-Relationship Diagrams (contd)
Many-to-many relationshipMore complex entity-relationship diagrams
Slide 11.43
© The McGraw-Hill Companies, 2002
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.
Slide 11.44
© The McGraw-Hill Companies, 2002
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
Slide 11.46
© The McGraw-Hill Companies, 2002
Extended Finite State Machines
Extend FSM with global predicatesTransition rules have form
state and event and predicate ⇒ new state
Slide 11.47
© The McGraw-Hill Companies, 2002
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 the elevator to visit the corresponding floor. The illumination is canceled when the corresponding floor is visited by the elevator2. Each floor, except the first and the top floor, has two 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
Slide 11.48
© The McGraw-Hill Companies, 2002
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
Slide 11.49
© The McGraw-Hill Companies, 2002
Elevator Buttons (contd)
Two statesEBON(e, f): Elevator Button (e,f) ONEBOFF(e,f): Elevator Button (e,f) OFF
– If an elevator button is on and the elevator arrives at floor f, then the elevator button is turned off
– If the elevator button is off and the elevator button is pressed, then the elevator button comes on
Slide 11.50
© The McGraw-Hill Companies, 2002
Elevator Buttons (contd)
Two eventsEBP(e,f): Elevator Button (e,f) PressedEAF(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)
Slide 11.51
© The McGraw-Hill Companies, 2002
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) ONFBOFF(d, f): Floor Button (d, f) OFF
– If the floor button is on and an elevator arrives at floor f, traveling in the correct direction d, then the floor button is turned off
– If the floor button is off and the floor button is pressed, then the floor button comes on
Slide 11.52
© The McGraw-Hill Companies, 2002
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 f
Direction 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
Slide 11.53
© The McGraw-Hill Companies, 2002
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
Slide 11.54
© The McGraw-Hill Companies, 2002
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
Slide 11.56
© The McGraw-Hill Companies, 2002
Elevator Problem: FSM (contd)
EventsDC(e,f): Door Closed for elevator e, floor fST(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)
Slide 11.57
© The McGraw-Hill Companies, 2002
Power of FSM to Specify Complex Systems
No need for complex preconditions and postconditionsSpecifications take the simple form
current state and event and predicate ⇒ next state
Slide 11.58
© The McGraw-Hill Companies, 2002
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
Slide 11.59
© The McGraw-Hill Companies, 2002
FSMs and Real-Time Systems
Statecharts are a real-time extension of FSMs– CASE tool: Rhapsody
Slide 11.60
© The McGraw-Hill Companies, 2002
Petri Nets
A major difficulty with specifying real-time systems is timing– Synchronization problems– Race conditions– Deadlock
Often a consequence of poor specifications
Slide 11.61
© The McGraw-Hill Companies, 2002
Petri Nets (contd)
Petri nets– Powerful technique for specifying systems that have
potential problems with interrelationsA Petri net consists of four parts: – Set of places P– Set of transitions T– Input function I
– Output function O
Slide 11.62
© The McGraw-Hill Companies, 2002
Petri Nets (contd)
Set of places P is {p1, p2, p3, p4}
Set of transitions Tis {t1, t2}
Input functions:I(t1) = {p2, p4}I(t2) = {p2}
Output functions:O(t1) = {p1}O(t2) = {p3, p3}
Slide 11.63
© The McGraw-Hill Companies, 2002
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 Pand T disjointI : T → P∞ is input function, mapping from transitions to bags of placesO : 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
Slide 11.64
© The McGraw-Hill Companies, 2002
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
Slide 11.65
© The McGraw-Hill Companies, 2002
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 conservedTransition t2 is also enabled
Slide 11.66
© The McGraw-Hill Companies, 2002
Petri Nets (contd)
Petri nets are indeterminate– Suppose t1 fires
Resulting marking is (2,1,0,0)
Slide 11.67
© The McGraw-Hill Companies, 2002
Petri Nets (contd)
Now only t2 is enabled – It fires
Marking is now (2,0,2,0)
Slide 11.68
© The McGraw-Hill Companies, 2002
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 a 5-tuple (P, T, I, O, M )
Slide 11.69
© The McGraw-Hill Companies, 2002
Petri Nets (contd)
Inhibitor arcs– An inhibitor arc is marked by a small circle, not an
arrowhead
Transition t1 is enabled – In general, a transition is enabled if there is at least one
token on each (normal) input arc, and no tokens on any inhibitor input arcs
Slide 11.70
© The McGraw-Hill Companies, 2002
Elevator Problem: Petri Net
A product is to be installed to control nelevators 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
Slide 11.71
© The McGraw-Hill Companies, 2002
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
A token in EBf denotes that the elevator button for floor f is illuminated
Slide 11.72
© The McGraw-Hill Companies, 2002
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, a new token is placed in EBf
Now, no matter how many times the button is pressed, transition EBf pressed cannot be enabled
Slide 11.73
© The McGraw-Hill Companies, 2002
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
Slide 11.74
© The McGraw-Hill Companies, 2002
Elevator Problem: Petri Net (contd)
Motion from floor g to floor f cannot take place instantaneously– Timed Petri nets
Slide 11.75
© The McGraw-Hill Companies, 2002
Elevator Problem: Petri Net (contd)
Second constraint2. Each floor, except the first and the top floor, has two 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
Slide 11.77
© The McGraw-Hill Companies, 2002
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)
Slide 11.78
© The McGraw-Hill Companies, 2002
Elevator Problem: Petri Net (contd)
Third constraintC3. If an elevator has no requests, it remains at its current floor with its doors closed
If there are no requests, no Elevator in action
transition is enabled
Slide 11.79
© The McGraw-Hill Companies, 2002
Petri Nets (contd)
Petri nets can also be used for designPetri nets possess the expressive power necessary for specifying synchronization aspects of real-time systems
Slide 11.80
© The McGraw-Hill Companies, 2002
Z (“zed”)
Formal specification languageHigh squiggle factorZ specification consists of four sections:– 1. Given sets, data types, and constants– 2. State definition– 3. Initial state– 4. Operations
Slide 11.81
© The McGraw-Hill Companies, 2002
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– The specification begins
[Button]
Slide 11.82
© The McGraw-Hill Companies, 2002
Elevator Problem: Z (contd)
2. State Definition
Z specification consists of a number of schemata– A schema consists of group of variable declarations,
plus– A list of predicates that constrain values of variables
Slide 11.83
© The McGraw-Hill Companies, 2002
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)
Slide 11.85
© The McGraw-Hill Companies, 2002
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!)
Slide 11.86
© The McGraw-Hill Companies, 2002
Elevator Problem: Z (contd)
4. Operations
A button pushed for the first time is turned on, and added to set pushedWithout the third precondition, the results would be unspecified
Slide 11.87
© The McGraw-Hill Companies, 2002
Elevator Problem: Z (contd)
If an elevator arrives at a floor, the corresponding button(s) must be turned offThe solution does not distinguish between up and down floor buttons
Slide 11.88
© The McGraw-Hill Companies, 2002
Analysis of Z
Most widely used formal specification language– CICS (part)– Oscilloscope– CASE tool– Large-scale projects (esp. Europe)
Slide 11.89
© The McGraw-Hill Companies, 2002
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– A “translation” is clearer than informal specification
Slide 11.90
© The McGraw-Hill Companies, 2002
Other Formal Methods
Anna – Ada
Gist, Refine– Knowledge-based
VDM – Denotational semantics
CSP – Sequence of events– Executable specifications– High squiggle factor
Slide 11.91
© The McGraw-Hill Companies, 2002
Comparison of Specification Techniques
We must always choose the appropriate specification methodFormal methods– Powerful– Difficult to learn and use
Informal methods– Little power– Easy to learn and use
Trade-off– Ease of use versus power
Slide 11.93
© The McGraw-Hill Companies, 2002
Newer Methods
Many are untested in practiceRisks – Training costs– Adjustment from classroom to actual project– CASE tools may not work properly
However, possible gains may be huge
Slide 11.94
© The McGraw-Hill Companies, 2002
Which Specification Method to Use?
Depends on the– Project– Development team– Management team– Myriad other factors
It is unwise to ignore the latest developments
Slide 11.95
© The McGraw-Hill Companies, 2002
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
Slide 11.96
© The McGraw-Hill Companies, 2002
CASE Tools for the Specification Phase
Graphical toolData dictionary– Integrate them
Specification method without CASE tools fails– SREM
Slide 11.97
© The McGraw-Hill Companies, 2002
CASE Tools for the Specification Phase
Typical tools– Analyst/Designer– Software through Pictures– System Architect
Slide 11.98
© The McGraw-Hill Companies, 2002
Metrics for the Specification Phase
Five fundamental metricsQuality– 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
Slide 11.99
© The McGraw-Hill Companies, 2002
Air Gourmet Case Study: Structured Sys. Anal.
Data flow diagram reflects the centrality of SPECIAL MEAL DATA
See Appendix E for the remainder of the structured systems analysis
Slide 11.100
© The McGraw-Hill Companies, 2002
Air Gourmet Case Study: SPMP
The Software Project Management Plan is given in Appendix F
Slide 11.101
© The McGraw-Hill Companies, 2002
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