Object-Oriented and Classical Software Engineering

Transcription

1 Slide 11.1 Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach

2 CHAPTER 11 Slide 11.2 SPECIFICATION PHASE

3 Overview Slide 11.3 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) Slide 11.4 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 Slide 11.5 Specification document must be Informal enough for client Formal enough for developers Free of omissions, contradictions, ambiguities

6 Specification Document Slide 11.6 Constraints Cost Time Parallel running Portability Reliability Rapid response time

7 Specification Document (contd) Slide 11.7 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

8 Solution Strategy Slide 11.8 A 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 Slide 11.9 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%

10 Meaning of Specification Slide 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

11 But Specifications Do Not Say This Slide [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

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

13 Episode 1 Slide Naur Paper 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 Naur constructed a procedure (25 lines of Algol 60), and informally proved its correctness

14 Episode 2 Slide 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

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

16 Episode 4 Slide 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

17 Case Study (contd) Slide 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 Slide 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

19 Informal Specifications Slide 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 Slide Three popular graphical specification methods of 70s DeMarco Gane and Sarsen Yourdon All are equivalent All are equally good Many U.S. corporations use them for commercial products Gane and Sarsen s method is taught here because it is so widely used.

21 Structured Systems Analysis Case Study Slide 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?

22 Case Study (contd) Slide 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

23 Case Study (contd) Slide 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

24 Case Study (contd) Slide 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

25 Case Study (contd) Slide Data flow diagram (DFD) shows the logical data flow what happens, not how it happens Notation:

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

27 Step 1 (contd) Slide Second refinement PENDING ORDERS is scanned daily

28 Step 1 (contd) Slide Portion of third refinement

29 Step 1 (contd) Slide 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

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

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

32 Step 3. Refine Data Flows (contd) Slide Sample data dictionary entries

33 Step 4. Refine Logic of Processes Slide 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

34 Step 4 (contd) Slide Advantage of a decision tree Missing items are quickly apparent Can also use decision tables CASE tools for automatic translation

35 Step 5. Refine Data Stores Slide 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)

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

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

38 Step 8. Perform Sizing Slide 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

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

40 However Slide 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

41 Entity-Relationship Diagrams Slide Semi-formal technique Widely used for specifying databases Used for object-oriented analysis

42 Entity-Relationship Diagrams (contd) Slide Many-to-many relationship More complex entity-relationship diagrams

43 Formality versus Informality Slide 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.

44 Finite State Machines Slide 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

45 Finite State Machines (contd) Slide Transition table

46 Extended Finite State Machines Slide Extend FSM with global predicates Transition rules have form state and event and predicate new state

47 Elevator Problem Slide 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 elevator 2. 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

48 Elevator Problem: FSM Slide 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

49 Elevator Buttons (contd) Slide Two states EBON(e, f): EBOFF(e,f): Elevator Button (e,f) ON 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

50 Elevator Buttons (contd) Slide 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)

51 Floor Buttons Slide Floor buttons FB(d, f): Floor Button on floor f that requests elevator traveling in direction d States FBON(d, f): FBOFF(d, f): Floor Button (d, f) ON 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

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

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

54 Elevator Problem: FSM (contd) Slide Assume elevator controller moves elevator through substates Three elevator states M(d, e, f): S(d, e, f): W(e,f): Moving in direction d (floor f is next) Stopped (d-bound) at floor 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

55 Elevator Problem: FSM (contd) Slide 11.55

56 Elevator Problem: FSM (contd) Slide Events DC(e,f): ST(e,f): Door Closed for elevator e, floor f Sensor Triggered as elevator e nears floor f RL: Transition Rules Request Logged (button pressed) 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)

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

58 Power of FSM to Specify Complex Systems Slide 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

59 FSMs and Real-Time Systems Slide Statecharts are a real-time extension of FSMs CASE tool: Rhapsody

60 Petri Nets Slide A major difficulty with specifying real-time systems is timing Synchronization problems Race conditions Deadlock Often a consequence of poor specifications

61 Petri Nets (contd) Slide Petri nets Powerful technique for specifying systems that have potential problems with interrelations A Petri net consists of four parts: Set of places P Set of transitions T Input function I Output function O

62 Petri Nets (contd) Slide Set of places P is {p 1, p 2, p 3, p 4 } Set of transitions T is {t 1, t 2 } Input functions: I(t 1 ) = {p 2, p 4 } I(t 2 ) = {p 2 } Output functions: O(t 1 ) = {p 1 } O(t 2 ) = {p 3, p 3 }

63 Petri Nets (contd) Slide More formally, a Petri net is a 4-tuple C = (P, T, I, O) P = {p 1, p 2,,p n } is a finite set of places, n 0 T = {t 1, t 2,,t m } is a finite set of transitions, m 0, with P and T disjoint I : T P is input function, mapping from transitions to bags of places O : 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

64 Petri Nets (contd) Slide Four tokens, one in p 1, two in p 2, none in p 3, and one in p 4 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

65 Petri Nets (contd) Slide Transition t 1 is enabled (ready to fire) If t 1 fires, one token is removed from p 2 and one from p 4, and one new token is placed in p 1 Important: Number of tokens is not conserved Transition t 2 is also enabled

66 Petri Nets (contd) Slide Petri nets are indeterminate Suppose t 1 fires Resulting marking is (2,1,0,0)

67 Petri Nets (contd) Slide Now only t 2 is enabled It fires Marking is now (2,0,2,0)

68 Petri Nets (contd) Slide 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 )

69 Petri Nets (contd) Slide Inhibitor arcs An inhibitor arc is marked by a small circle, not an arrowhead Transition t 1 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

70 Elevator Problem: Petri Net Slide A product is to be installed to control n elevators in a building with m floors Each floor represented by place F f, 1 f m Elevator represented by token Token in F f denotes that an elevator is at floor F f

71 Elevator Problem: Petri Net (contd) Slide 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 EB f, 1 f m A token in EB f denotes that the elevator button for floor f is illuminated

72 Elevator Problem: Petri Net (contd) Slide A button must be illuminated the first time button is pressed and subsequent button presses must be ignored If button EB f is not illuminated, no token in place and transition EB f pressed is enabled Transition fires, a new token is placed in EB f Now, no matter how many times the button is pressed, transition EB f pressed cannot be enabled

73 Elevator Problem: Petri Net (contd) Slide When elevator reaches floor g, token is in place F g, transition Elevator in action is enabled, and then fires Tokens in EB f and F g removed This turns off light in button EB f New token appears in F f This brings elevator from floor g to floor f

74 Elevator Problem: Petri Net (contd) Slide Motion from floor g to floor f cannot take place instantaneously Timed Petri nets

75 Elevator Problem: Petri Net (contd) Slide Second constraint 2. 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 FB u f and FB d f

76 Elevator Problem: Petri Net (contd) Slide 11.76

77 Elevator Problem: Petri Net (contd) Slide 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)

78 Elevator Problem: Petri Net (contd) Slide Third constraint C 3. 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

79 Petri Nets (contd) Slide Petri nets can also be used for design Petri nets possess the expressive power necessary for specifying synchronization aspects of real-time systems

80 Z ( zed ) Slide Formal specification language High squiggle factor Z specification consists of four sections: 1. Given sets, data types, and constants 2. State definition 3. Initial state 4. Operations

81 Elevator Problem: Z Slide 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]

82 Elevator Problem: Z (contd) Slide 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

83 Elevator Problem: Z (contd) Slide 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)

84 Elevator Problem: Z (contd) Slide Schema Button_State

85 Elevator Problem: Z (contd) Slide 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!)

86 Elevator Problem: Z (contd) Slide Operations A button pushed for the first time is turned on, and added to set pushed Without the third precondition, the results would be unspecified

87 Elevator Problem: Z (contd) Slide If an elevator arrives at a floor, the corresponding button(s) must be turned off The solution does not distinguish between up and down floor buttons

88 Analysis of Z Slide Most widely used formal specification language CICS (part) Oscilloscope CASE tool Large-scale projects (esp. Europe)

89 Analysis of Z (contd) Slide 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

90 Other Formal Methods Slide Anna Ada Gist, Refine Knowledge-based VDM Denotational semantics CSP Sequence of events Executable specifications High squiggle factor

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

92 Comparison of Specification Techniques (contd) Slide 11.92

93 Newer Methods Slide Many are untested in practice Risks Training costs Adjustment from classroom to actual project CASE tools may not work properly However, possible gains may be huge

94 Which Specification Method to Use? Slide Depends on the Project Development team Management team Myriad other factors It is unwise to ignore the latest developments

95 Testing during the Specification Phase Slide Specification inspection Checklist Doolan [1992] 2 million lines of FORTRAN 1 hour of inspecting saved 30 hours of execution-based testing

96 CASE Tools for the Specification Phase Slide Graphical tool Data dictionary Integrate them Specification method without CASE tools fails SREM

97 CASE Tools for the Specification Phase Slide Typical tools Analyst/Designer Software through Pictures System Architect

98 Metrics for the Specification Phase Slide Five fundamental metrics Quality 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

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

100 Air Gourmet Case Study: SPMP Slide The Software Project Management Plan is given in Appendix F

101 Challenges of the Specification Phase Slide 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