Lecture 6 & 7

Lecture 6 & 7:
Structured Analysis
Anita S. Malik
anitamalik@umt.edu.pk

Adapted from Schach (2004) Chapter 11

CS540 Software Design Lecture 6 & 7 1

Specifications Phase
 Specification document must be
 Informal enough for client
 Formal enough for developers
 Free of omissions, contradictions, ambiguities
 Specification techniques include
 Informal specifications
 Structured systems analysis
 Object Oriented analysis
 Entity-relationship modeling
 Finite state machines
 Petri nets
 Other formal techniques such as Z specification

Informal Specifications
 Example
“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%”


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


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


Informal Specifications (contd)
 Claim
 This cannot arise with professional specifications
writers
 Refutation
 Text Processing case study


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)


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


Episode 3

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


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


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?

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


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


Structured Systems Analysis
 Three popular graphical specification methods of ’70s
 DeMarco
 Gane and Sarsen
 Yourdon
 All equivalent
 All equally good
 Many corporations use them for commercial products
 Gane and Sarsen used for object-oriented design


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?


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


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


Case Study (contd)
 Data flow diagram (DFD) shows logical data flow
 “what happens, not how it happens”


Step 1. Draw the DFD
 First refinement
 Infinite number of possible interpretations


Step 1 (contd)
 Second refinement
 pending orders scanned daily


Step 1 (contd)

 Portion of third
refinement


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


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


Step 3. Refine Data Flows
 Data items for each data flow
 Refine each flow stepwise
 Refine further
 Need a data dictionary


Step 3. Refine Data Flows (contd)

 Sample data dictionary entries

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


Step 4 (contd)
 Advantage of decision tree
 Missing items are quickly apparent

 Can also use decision tables
 CASE tools for automatic translation


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)


Step 6. Define Physical Resources
 For each file, specify
 File name

 Organization (sequential, indexed, etc.)

 Storage medium

 Blocking factor

 Records (to field level)


Step 7. Determine Input/Output Specs
 Specify input forms, input screens, printed output


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


Step 9. Hardware Requirements
 DASD requirements
 Mass storage for back-up
 Input needs
 Output devices
 Is existing hardware adequate?
 If not, recommend buy/lease


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


Structured Analysis (Summary)
Nine Steps:
1. Draw the Data Flow Diagram (DFD)
2. Decide what section to computerize
3. Determine the details of the data flows
4. Define the logic of the processes
5. Define the data stores
6. Define the physical resources
7. Determine input-output specifications
8. Perform sizing
9. Determine the hardware requirements


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


Testing during the Specification Phase
 Walkthrough of the document
 Inspect the document against a checklist. A study done on
inspections showed each hour invested in inspections at analysis
stage saved 30 hrs of execution-based fault detection and
correction.


Metrics for Analysis Phase
 Size, cost, duration, effort and quality
 Size: number of pages in the specification document
 Quality: note the number of faults of each type found during
inspection
 Duration and effort: number of items in the data dictionary,
number of files, data items, processes etc.


Challenges of Analysis Phase
 The documents generated during the analysis phase should be
informal enough for the client to understand and formal enough
for the development team to use as the description of the
product to be built
 To keep within the ‘what’ boundary and not cross to the ‘how’
boundary


Lecture 6 & 7

More Related Content

Similar to Lecture 6 & 7 (20)

Recently uploaded (20)

Lecture 6 & 7