Slide 11 A 1 ObjectOriented and Classical Software

Slide 11 A. 1 Object-Oriented and Classical Software Engineering Sixth Edition, WCB/Mc. Graw-Hill, 2005 Stephen R. Schach srs@vuse. vanderbilt. edu © The Mc. Graw-Hill Companies, 2005

CHAPTER 11 — Unit A Slide 11 A. 2 CLASSICAL ANALYSIS © The Mc. Graw-Hill Companies, 2005

Overview l l l l l The specification document Informal specifications Structured systems analysis: The Osbert Oglesby case study Other semiformal techniques Entity-relationship modeling Finite state machines Petri nets Z © The Mc. Graw-Hill Companies, 2005 Slide 11 A. 3

Overview (contd) l l l l Slide 11 A. 4 Other formal techniques Comparison of classical analysis techniques Testing during classical analysis CASE tools for classical analysis Metrics for classical analysis Software project management plan: The Osbert Oglesby case study Challenges of classical analysis © The Mc. Graw-Hill Companies, 2005

The Specification Document Must Be l Slide 11 A. 5 Informal enough for the client 4 The client is generally not a computer specialist l Formal enough for the developers 4 It is the sole source of information for drawing up the design l These two requirements are mutually contradictory © The Mc. Graw-Hill Companies, 2005

11. 1 The Specification Document Slide 11 A. 6 l The specification document is a contract between the client and the developers l Typical constraints 4 Deadline 4 Parallel running 4 Portability 4 Reliability 4 Rapid response time l For real-time software 4 Hard real-time constraints must be satisfied © The Mc. Graw-Hill Companies, 2005

Specification Document (contd) l Slide 11 A. 7 Acceptance criteria 4 It is vital to spell out a series of tests l If the product passes the tests, it is deemed have satisfied its specifications l Some acceptance criteria are restatements of constraints © The Mc. Graw-Hill Companies, 2005

Solution Strategy Slide 11 A. 8 l A general approach to building the product l Find strategies without worrying about constraints 4 Then modify the strategies in the light of the constraints, if necessary l Keep a written record of all discarded strategies, and why they were discarded 4 To protect the analysis team 4 To prevent unwise new “solutions” during postdelivery maintenance © The Mc. Graw-Hill Companies, 2005

11. 2 Informal Specifications l Slide 11 A. 9 Informal specifications are written in a natural language 4 Examples: English, Mandarin, Kiswahili, Hindi l 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%” © The Mc. Graw-Hill Companies, 2005

The Meaning of This Specification l Slide 11 A. 10 The sales target for January was $100, 000, but actual sales were only $64, 000 (36% below target) 4 Print the report l The sales target for February was $120, 000, the actual sales were only $100, 000 (16. 7% below target) 4 The percentage difference for February (16. 7%) is less than half of the previous month’s percentage difference (36%), so do not print the report © The Mc. Graw-Hill Companies, 2005

The Meaning of This Specification (contd) Slide 11 A. 11 l The sales target for March was $100, 000, the actual sales were $98, 000 (2% below target) 4 The percentage difference is under 5%, so do not print the report © The Mc. Graw-Hill Companies, 2005

But the Specifications Do Not Say This Slide 11 A. 12 l “[D]ifference between target sales and actual sales” 4 There is no mention of percentage difference in the specifications l The difference in January was $36, 000, the difference in February was $20, 000 4 Not less than half of $36, 000, so the report is printed l “[D]ifference … [of] 5%” 4 Again, no mention of percentage © The Mc. Graw-Hill Companies, 2005

But the Specifications Do Not Say This (contd) Slide 11 A. 13 l Ambiguity—should the last clause read “percentage difference … [of] 5%” or “difference … [of] $5, 000” or something else entirely? l The style is poor 4 The specifications should state when the report should be printed … 4… Rather than when it should not be printed © The Mc. Graw-Hill Companies, 2005

Informal Specifications (contd) l Slide 11 A. 14 Claim 4 This cannot arise with professional specifications writers l Refutation 4 Text processing case study © The Mc. Graw-Hill Companies, 2005

11. 2. 1 Correctness Proof Case Study l Slide 11 A. 15 Naur text-processing problem Given 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 © The Mc. Graw-Hill Companies, 2005

Episode 1 Slide 11 A. 16 l 1969 — Naur Paper l Naur constructed a procedure (25 lines of Algol 60), and informally proved its correctness © The Mc. Graw-Hill Companies, 2005

Episode 2 l Slide 11 A. 17 1970 — Reviewer in Computing Reviews 4 The first word of the first line is preceded by a blank unless the first word is exactly maxpos characters long © The Mc. Graw-Hill Companies, 2005

Episode 3 l Slide 11 A. 18 1971 — London found 3 more faults 4 Including: The procedure does not terminate unless a word longer than maxpos characters is encountered © The Mc. Graw-Hill Companies, 2005

Episode 4 l Slide 11 A. 19 1975 — Goodenough and Gerhart found 3 further faults 4 Including: The last word will not be output unless it is followed by a blank or newline l Goodenough and Gerhart then produced a new set of specifications, about four times longer than Naur’s © The Mc. Graw-Hill Companies, 2005

Episode 5 l Slide 11 A. 20 1985 — Meyer detected 12 faults in Goodenough and Gerhart’s specifications © The Mc. Graw-Hill Companies, 2005

Episode 5 l Slide 11 A. 21 Goodenough and Gerhart’s specifications 4 Were constructed with the greatest of care 4 Were constructed to correct Naur’s specifications 4 Went through two versions, carefully refereed 4 Were written by experts in specifications, 4 With as much time as they needed, 4 For a product about 30 lines long l So, what chance do we have of writing fault-free specifications for a real product? © The Mc. Graw-Hill Companies, 2005

Episode 6 l Slide 11 A. 22 1989 — Schach found a fault in Meyer’s specifications 4 Item (2) of Naur’s original requirement (“each line is filled as far as possible”) is not satisfied © The Mc. Graw-Hill Companies, 2005

Informal Specifications (contd) l Slide 11 A. 23 Conclusion 4 Natural language is not a good way to specify a product © The Mc. Graw-Hill Companies, 2005

11. 3 Structured Systems Analysis l Slide 11 A. 24 Three popular graphical specification methods of ’ 70 s 4 De. Marco 4 Gane and Sarsen 4 Yourdon l All are equivalent l All are equally good © The Mc. Graw-Hill Companies, 2005

11. 3 Structured Systems Analysis (contd) Slide 11 A. 25 l Many U. S. corporations use them for commercial products l Gane and Sarsen’s method is taught here because it is so widely used © The Mc. Graw-Hill Companies, 2005

11. 3. 1 Sally’s Software Shop Mini Case Study Slide 11 A. 26 l 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? © The Mc. Graw-Hill Companies, 2005

Sally’s Software Shop Mini Case Study (contd) Slide 11 A. 27 l A better question 4 What business functions should she computerize » Accounts payable » Accounts receivable » Inventory l Still better 4 How? Batch, or online? In-house or outsourcing? © The Mc. Graw-Hill Companies, 2005

Sally’s Software Shop Mini Case Study (contd) Slide 11 A. 28 l The fundamental issue 4 What is Sally’s objective in computerizing her business? l Because she sells software? 4 She needs an in-house system with sound and light effects l Because she uses her business to launder “hot” money? 4 She needs a product that keeps five different sets of books, and has no audit trail © The Mc. Graw-Hill Companies, 2005

Sally’s Software Shop Mini Case Study (contd) Slide 11 A. 29 l We assume: Sally wishes to computerize “in order to make more money” 4 We need to perform cost–benefit analysis for each section of her business © The Mc. Graw-Hill Companies, 2005

Sally’s Software Shop Mini Case Study (contd) Slide 11 A. 30 l The danger of many standard approaches 4 First produce the solution, then find out what the problem is! l Gane and Sarsen’s method 4 Nine-step method 4 Stepwise refinement is used in many steps © The Mc. Graw-Hill Companies, 2005

Sally’s Software Shop Mini Case Study (contd) Slide 11 A. 31 l The data flow diagram (DFD) shows the logical data flow 4“What happens, not how it happens” l Symbols: Figure 11. 1 © The Mc. Graw-Hill Companies, 2005

Step 1. Draw the DFD l Slide 11 A. 32 First refinement 4 Infinite number of possible interpretations Figure 11. 2 © The Mc. Graw-Hill Companies, 2005

Step 1 (contd) l Slide 11 A. 33 Second refinement 4 PENDING ORDERS is scanned daily Figure 11. 3 © The Mc. Graw-Hill Companies, 2005

Step 1 (contd) l Slide 11 A. 34 Portion of third refinement © The Mc. Graw-Hill Companies, 2005 Figure 11. 4

Step 1 (contd) l The final DFD is larger 4 But it is easily understood by the client l When dealing with larger DFDs 4 Set up a hierarchy of DFDs 4 A box becomes a DFD at a lower level © The Mc. Graw-Hill Companies, 2005 Slide 11 A. 35

Step 2. Decide What Parts to Computerize and How Slide 11 A. 36 l It depends on how much client is prepared to spend l Large volumes, tight controls 4 Batch l Small volumes, in-house microcomputer 4 Online l Cost/benefit analysis © The Mc. Graw-Hill Companies, 2005

Step 3. Determine the Details of the Data Flows Slide 11 A. 37 l Determine the data items for each data flow l Refine each flow stepwise 4 Example; order: order_identification customer_details package_details l We need a data dictionary for larger products © The Mc. Graw-Hill Companies, 2005

Sample Data Dictionary Entries Slide 11 A. 38 Figure 11. 5 © The Mc.

Step 4. Define the Logic of the Processes Slide 11 A. 39 l We have process give educational discount 4 Sally must explain the discount she gives to educational institutions » 10% on up to 4 packages » 15% on 5 or more © The Mc. Graw-Hill Companies, 2005

Step 4. Define the Logic of the Processes (contd) Slide 11 A. 40 l Translate this into a decision tree Figure 11. 6 © The Mc. Graw-Hill Companies, 2005

Step 4. Define the Logic of the Processes (contd) Slide 11 A. 41 l The advantage of a decision tree 4 Missing items are quickly apparent Figure 11. 7 © The Mc. Graw-Hill Companies, 2005

Step 5. Define the Data Stores l Slide 11 A. 42 Define the exact contents and representation (format) 4 COBOL: specify to pic level 4 Ada: specify digits or delta © The Mc. Graw-Hill Companies, 2005

Step 5. Define the Data Stores (contd) Slide 11 A. 43 l Specify where immediate access is required 4 Data immediate-access diagram (DIAD) Figure 11. 8 © The Mc. Graw-Hill Companies, 2005

Step 6. Define the Physical Resources Slide 11 A. 44 l For each file, specify 4 File name 4 Organization (sequential, indexed, etc. ) 4 Storage medium 4 Blocking factor 4 Records (to field level) 4 Table information, if a DBMS is to be used © The Mc. Graw-Hill Companies, 2005

Step 7. Determine Input/Output Specifications Slide 11 A. 45 l Specify 4 Input forms 4 Input screens 4 Printed output © The Mc. Graw-Hill Companies, 2005

Step 8. Determine the Sizing l Slide 11 A. 46 Obtain the numerical data needed in Step 9 to determine the hardware requirements 4 Volume of input (daily or hourly) 4 Size, frequency, deadline of each printed report 4 Size, number of records passing between CPU and mass storage 4 Size of each file © The Mc. Graw-Hill Companies, 2005

Step 9. Determine the Hardware Requirements Slide 11 A. 47 l Mass storage requirements l Mass storage for back-up l Input needs l Output devices l Is the existing hardware adequate? 4 If not, recommend whether to buy or lease additional hardware © The Mc. Graw-Hill Companies, 2005

However Slide 11 A. 48 l Response times cannot be determined l The number of I/O channels can only be guessed l CPU size and timing can only be guessed l Nevertheless, no other method provides these data for arbitrary products © The Mc. Graw-Hill Companies, 2005

Overall l Slide 11 A. 49 The method of Gane and Sarsen/De Marco/ Yourdon has resulted in major improvements in the software industry © The Mc. Graw-Hill Companies, 2005

11. 4 Structured Systems Analysis; The Osbert Oglesby Case Study Slide 11 A. 50 Figure 11. 9 © The Mc. Graw-Hill Companies, 2005

11. 4 Structured Systems Analysis; The Osbert Oglesby Case Study (contd) Slide 11 A. 51 l Process buy accesses AUCTION_PAINTING data to compute the maximum price for a masterpiece or masterwork l Process buy accesses FASHIONABALITY data to compute the maximum price for an “other” painting l If an offer is accepted, sales information is then stored in GALLERY_PAINTING © The Mc. Graw-Hill Companies, 2005

11. 4 Structured Systems Analysis; The Osbert Oglesby Case Study (contd) Slide 11 A. 52 l Process sell accesses GALLERY_PAINTING data to compute the target selling price l Process print_report accesses GALLERY_PAINTING data to obtain the relevant information © The Mc. Graw-Hill Companies, 2005

11. 5 Other Semiformal Techniques l Slide 11 A. 53 Semiformal (graphical) techniques for classical analysis include 4 PSL/PSA 4 SADT 4 SREM © The Mc. Graw-Hill Companies, 2005