Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach srs@vuse.vand

1. Object-Oriented and Classical Software EngineeringFifth Edition, WCB/McGraw-Hill, 2002Stephen R. Schachsrs@vuse.vanderbilt.edu

2. CHAPTER 11 SPECIFICATION PHASE

3. Overview • The specification document • Informal specifications • Structured systems analysis • Other semiformal techniques • Entity-relationship modeling • Finite state machines • Petri nets • Other formal techniques

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

5. Specification Phase • Specification document must be • Informal enough for client • Formal enough for developers • Free of omissions, contradictions, ambiguities

6. Specification Document • Constraints • Cost • Time • Parallel running • Portability • Reliability • Rapid response time

7. Specification Document (contd) • Acceptance criteria • Vital to spell out series of tests • Product passes tests, deemed to satisfy specifications • Some are restatements of constraints

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

9. 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%”

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

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

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

13. Episode 1 • 1969 — Naur Paper Given a text consisting of words separated byblankor bynl(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 blankor 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

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

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

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

17. 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?

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

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

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

21. 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?

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

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

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

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

26. Step 1 (contd) • Second refinement • pending orders scanned daily

27. Step 1 (contd) • Portion of third refinement

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

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

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

31. Step 3. Refine Data Flows (contd) • Sample data dictionary entries

32. Step 4. Refine Logic of Processes • Have processgive educational discount • Sally must explain discount for educational institutions • 10% on up to 4 packages, 15% on 5 or more • Translate into decision tree

33. Step 4 (contd) • Advantage of decision tree • Missing items are quickly apparent • Can also use decision tables • CASE tools for automatic translation

34. 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)

35. Step 6. Define Physical Resources • For each file, specify • File name • Organization (sequential, indexed, etc.) • Storage medium • Blocking factor • Records (to field level)

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

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

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

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

40. Entity-Relationship Diagrams • Semi-formal technique • Widely used for specifying databases • Used for object-oriented analysis

41. Entity-Relationship Diagrams (contd) • Many-to-many relationship • More complex entity-relationship diagrams

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

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

44. Finite State Machines (contd) • Transition table

45. Extended Finite State Machines • Extend FSM with global predicates • Transition rules have form state and event and predicateÞnew state

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

47. 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-elevator EB(e, f): Elevator Button in elevator e pressed to request floor f

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

49. 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)

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