1. Slide 11.1 CHAPTER 11 SPECIFICATION PHASE

2. Slide 11.2 Overview l The specification document l Informal specifications l Structured systems analysis l Other semiformal techniques l Entity-relationship modeling l Finite state machines l Other formal techniques

3. Slide 11.3 Overview (contd) l Comparison of specification techniques l Testing during the specification phase l CASE tools for the specification phase l Metrics for the specification phase l Air Gourmet Case Study: structured systems analysis l Air Gourmet Case Study: software project management plan l Challenges of the specifications phase

4. Slide 11.4 Specification Phase l Specification document must be –Informal enough for client –Formal enough for developers –Free of omissions, contradictions, ambiguities

5. Slide 11.5 Specification Document l Constraints –Cost –Time –Parallel running –Portability –Reliability –Rapid response time

6. Slide 11.6 Specification Document (contd) l Acceptance criteria –Vital to spell out series of tests –Product passes tests, deemed to satisfy specifications –Some are restatements of constraints

7. Slide 11.7 Solution Strategy l General approach to building the product l Find strategies without worrying about constraints l Modify strategies in the light of constraints, if necessary l 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

8. Slide 11.8 Informal Specifications l Example “If sales for current month are below target sales, then a 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%”

9. Slide 11.9 Meaning of Specification l Sales target for January was $100,000, actual sales were only $64,000 (36% below target) –Print report l 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 l Sales target for March was $100,000, actual sales were $98,000 (2% below target) –Percentage difference < 5%, do not print

10. Slide 11.10 But Specifications Do Not Say This l “[D]ifference between target sales and actual sales” –There is no mention of percentage difference l Difference in January was $36,000, difference in February was $20,000 –Not less than half of $36,000, so report is printed l “[D]ifference … [of] 5%” –Again, no mention of percentage l Ambiguity—should the last clause read “percentage difference … [of] 5%” or “difference … [of] $5,000” or something else entirely? l Style is poor

11. Slide 11.11 Informal Specifications (contd) l Claim –This cannot arise with professional specifications writers l Refutation –Text Processing case study (Section 11.2.1)

12. Slide 11.12 Informal Specifications l Conclusion –Natural language is not a good way to specify product l Fact –Many organizations still use natural language, especially for commercial products l Reasons –Uninformed management –Undertrained computer professionals –Management gives in to client pressure –Management is unwilling to invest in training

13. Slide 11.13 Structured Systems Analysis l Three popular graphical specification methods of ’70s –DeMarco –Gane and Sarsen –Yourdon l All equivalent l All equally good l Many U.S. corporations still use them for commercial products

14. Slide 11.14 Gane and Sarsen’s 9-step Specification Method 1.Draw the data flow diagram 2.Decide what sections to computerize and how 3.Determine the details of the data flows 4.Define the logic of the processes 5.Define the data stores 6.Determine the physical resources 7.Determine the input-output specifications 8.Perform the sizing 9.Determine the hardware requirements

15. Slide 11.15 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? l Better question –What sections? l Still better –How? Batch, or online? In-house or out-service?

16. Slide 11.16 Case Study (contd) l Fundamental issue –What is Sally’s objective in computerizing her business? l Because she sells software? –She needs an in-house system with sound and light effects l Assume: Computerization “in order to make more money” –Cost/benefit analysis for each section of business

17. Slide 11.17 Data Flow Diagram (DFD) l DFD shows logical data flow –“what happens, not how it happens”

18. Slide 11.18 Step 1. Draw the DFD l First refinement l Infinite number of possible interpretations

19. Slide 11.19 Step 1 (contd) l Second refinement l pending orders scanned daily

20. Slide 11.20 Step 1 (contd) l Portion of third refinement

21. Slide 11.21 Step 1 (contd) l Final DFD –Larger, but easily understood by client l Larger DFDs –Hierarchy –Box becomes DFD at lower level l 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” l Solution –Draw “correct” DFD, modify by moving sources and destinations of data one or more levels up

22. Slide 11.22 Step 2. Decide What Parts to Computerize l Depends on how much client is prepared to spend l Large volumes, tight controls –Batch l Small volumes, in-house microcomputer –Online l Cost/benefit analysis

23. Slide 11.23 Step 3. Refine Data Flows l Determine data items for each data flow l Refine each flow stepwise l Refine further – each of the preceding components is refined further l Need a data dictionary

24. Slide 11.24 Sample data dictionary entries (Fig. 11.5)

25. Slide 11.25 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 l Translate into decision tree

26. Slide 11.26 Step 4 (contd) l Advantage of decision tree –Missing items are quickly apparent l Can also use decision tables –CASE tools for automatic translation

27. Slide 11.27 Step 5. Refine Data Stores l Define exact contents and representation (format) –COBOL: specify to pic level –Ada: specify digits or delta l Specify where immediate access is required –Data immediate access diagram (DIAD)

28. Slide 11.28 Step 6. Define Physical Resources l For each file, specify –File name –Organization (sequential, indexed, etc.) –Storage medium –Blocking factor –Records (to field level) l If DBMS is to be used, then specify –The relevant information for each table

29. Slide 11.29 Step 7. Determine Input/Output Specs l Specify input forms, input screens, printed output

30. Slide 11.30 Step 8. Perform Sizing l 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

31. Slide 11.31 Step 9. Hardware Requirements l DASD (Direct Access Storage Disk) requirements l Mass storage for back-up l Input needs l Output devices l Is existing hardware adequate? l If not, recommend buy or lease

32. Slide 11.32 However l Response times cannot be determined l 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 l The method of Gane and Sarsen, DeMarco, Yourdon has resulted in major improvements in the software industry

33. Slide 11.33 Entity-Relationship (Modeling) Diagrams l A semi-formal data-oriented (as opposed to structured systems analysis’ action-oriented) technique for specifying a product l Widely used for specifying databases l One element of object-oriented analysis l One-to-Many relationship

34. Slide 11.34 Entity-Relationship Diagrams (contd) l Many-to-many relationship l Many-to-many-to-many relationship

35. Slide 11.35 Formality versus Informality l Informal method –English (or other natural language such as 한글 ) l Semiformal methods –Structured Systems Analysis (Gane & Sarsen/DeMarco/Yourdon) –Entity-Relationship Diagrams –Jackson/Orr/Warnier, –SADT, PSL/PSA, SREM, etc. l Formal methods –Finite State Machines (section 11.6) –Petri Nets (section 11.7) –Z (section 11.8) –ANNA, VDM, CSP, etc. (section 11.9)

36. Slide 11.36 Finite State Machines l 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 State Transition Diagram (STD)

37. Slide 11.37 Finite State Machines (contd) Transition table

38. Slide 11.38 Extended Finite State Machines l Extend FSM with global predicates (condition or state) l EFSM transition rules have form: current state and event and predicate  new state

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

40. Slide 11.40 Elevator Problem: FSM l 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

41. Slide 11.41 Elevator Buttons (contd) l 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 is turned off –If light is off and button is pressed, then light comes on

42. Slide 11.42 Elevator Buttons (contd) l Two events EBP(e,f):Elevator Button (e,f) Pressed EAF(e,f):Elevator e Arrives at Floor f l Global predicate V(e,f): Elevator e is Visiting (stopped at) floor f l 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)

43. Slide 11.43 Floor Buttons l Floor buttons FB(d, f): Floor Button on floor f that requests elevator traveling in direction d l 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

44. Slide 11.44 Floor Buttons (contd) l Events FBP(d, f): Floor Button (d, f) Pressed EAF(1..n, f): Elevator 1 or … or n Arrives at Floor f l Predicate S(d, e, f):elevator e is visiting floor f and the direction of motion is up (d = U), down (d = D), or no requests are pending (d = N) l 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

45. Slide 11.45 Elevator Problem: FSM (contd) l State of elevator consists of component substates, including: –Elevator slowing –Elevator stopping –Door opening –Door open with timer running –Door closing after a timeout

46. Slide 11.46 Elevator Problem: FSM (contd) l 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

47. Slide 11.47 Elevator Problem: FSM (contd) l 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) l 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, 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)

48. Slide 11.48 Elevator Problem: FSM (contd)

49. Slide 11.49 Power of FSM to Specify Complex Systems l No need for complex preconditions and postconditions l Specifications take the simple form current state and event and predicate  next state

50. Slide 11.50 Power of FSM to Specify Complex Systems l 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 l However –Timing considerations are not handled

51. Slide 11.51 Who Is Using FSMs? l Commercial products –Menu driven –Various states/screens –Automatic code generation a major plus l System software –Operating system –Word processors –Spreadsheets l Real-time systems –Statecharts are a real-time extension of FSMs »CASE tool: Rhapsody

52. Slide 11.52 Comparison of Specification Techniques l We must always choose the appropriate specification method l Formal methods –Powerful –Difficult to learn and use l Informal methods –Little power –Easy to learn and use l Trade-off – Ease of use versus power

53. Slide 11.53 Comparison of Specification Techniques (contd)

54. Slide 11.54 Which Specification Method to Use? l Depends on the –Project –Development team –Management team –Myriad other factors

55. Slide 11.55 Testing during the Specification Phase l Specification inspection –A team of inspectors reviews the specifications against a checklist »Have all the required functions been specified? »Have the required hardware resources been specified? »Have the acceptance criteria been specified?

56. Slide 11.56 CASE Tools for the Specification Phase l Graphical tool –DFD tool –ER Diagram tool –STD tool l Data dictionary –Usually provided in a case tool l Specification method without CASE tools can easily fail

57. Slide 11.57 CASE Tools for the Specification Phase l Typical tools –Analyst/Designer –Software through Pictures –System Architect

58. Slide 11.58 Metrics for the Specification Phase l Size –Number of pages in the specification document l Quality –Fault statistics –Number, type of each fault –Rate of detection l Metrics for “predicting” size of target product –Total number of items in data dictionary –Number of items of each type –Number of files, processes

59. Slide 11.59 Air Gourmet Case Study: Structured Sys. Anal. l Data flow diagram reflects centrality of SPECIAL MEAL DATA l See Appendix E for remainder of structured systems analysis

60. Slide 11.60 Air Gourmet Case Study: SPMP l The Software Project Management Plan is given in Appendix F

61. Slide 11.61 Challenges of the Specification Phase l A specification document must be –Informal enough for the client; and –Formal enough for the development team l The specification phase (“what”) should not cross the boundary into the design phase (“how”) l Read Chapter 11