1. Slide 11.1 © The McGraw-Hill Companies, 2007 CHAPTER 11 CLASSICAL ANALYSIS

2. Slide 11.2 © The McGraw-Hill Companies, 2007 Overview  The specification document  Informal specifications  Structured systems analysis  Structured systems analysis: The MSG Foundation case study  Other semiformal techniques  Entity-relationship modeling  Finite state machines  Petri nets  Z

3. Slide 11.3 © The McGraw-Hill Companies, 2007 The Specification Document Must Be  At the end of the analysis workflow – the specification document should be produced  Specification - contract  Informal enough for the client  The client is generally not a computer specialist  Formal enough for the developers  It is the sole source of information for drawing up the design  These two requirements are mutually contradictory

4. Slide 11.4 © The McGraw-Hill Companies, 2007 Specification Client programmer Software Engineer

5. Slide 11.5 © The McGraw-Hill Companies, 2007 11.1 The Specification Document  The specification document is a contract between the client and the developers  Typical constraints on the product must be included in the specification  Deadline – for delivery  Parallel running with existing product  Portability – can run under different operating systems  Reliability  Rapid response time  For real-time software  Hard real-time constraints must be satisfied

6. Slide 11.6 © The McGraw-Hill Companies, 2007 Specification Document (contd)  Acceptance criteria – how the client accept the software  It is vital to spell out a series of tests  If the product passes the tests, it is deemed have satisfied its specifications  Some acceptance criteria are restatements of constraints such as the response time should be 1 sec, and system can run under Linux and WindowsXP etc

7. Slide 11.7 © The McGraw-Hill Companies, 2007 Acceptance constraints  As a constraint  The system must run under the windows XP  As a test condition  The system will be tested under the windows XP operating system

8. Slide 11.8 © The McGraw-Hill Companies, 2007 Exercise  Derive one acceptance test based on specification from your group’s mini-project

9. Slide 11.9 © The McGraw-Hill Companies, 2007 11.2 Informal Specifications  Informal specifications are written in a natural language  Examples: English, Mandarin, Kiswahili, Hindi  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. Slide 11.10 © The McGraw-Hill Companies, 2007 Case study  The management of a retail chain sets a target sales figure for each shop for each month; and if a shop does not meet this target, a report is to be printed. Consider the following scenario: Suppose that the January sales target for one particular shop is $100,000 but actual sales are only $64,000, that is, 36% below target. In this case, a report must be printed. Now suppose further that the February target figure is $120,000 and the actual sales are only $100,000, 16.7% below target. Although sales are below the target figure, the % difference for February, is less than half of the previous month’s % difference; management believes that an improvement has been made, and no report is to be printed. If in March, the target is again $100,000 but the shop makes $98,000, only 2% below target. Because the % difference is small (5%), no report should be printed.

11. Slide 11.11 © The McGraw-Hill Companies, 2007 The Meaning of This Specification  The sales target for January was $100,000, but actual sales were only $64,000 (36% below target)  Print the report  The sales target for February was $120,000, the actual sales were only $100,000 (16.7% below target)  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

12. Slide 11.12 © The McGraw-Hill Companies, 2007 The Meaning of This Specification (contd)  The sales target for March was $100,000, the actual sales were $98,000 (2% below target)  The percentage difference is under 5%, so do not print the report

13. Slide 11.13 © The McGraw-Hill Companies, 2007 But the Specifications Do Not Say This  “[D]ifference between target sales and actual sales”  There is no mention of percentage difference in the specifications  The difference in January was $36,000, the 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

14. Slide 11.14 © The McGraw-Hill Companies, 2007 But the Specifications Do Not Say This (contd)  Ambiguity—should the last clause read “percentage difference … [of] 5%” or “difference … [of] $5,000” or something else entirely?  The style is poor  The specifications should state when the report should be printed …  … Rather than when it should not be printed

15. Slide 11.15 © The McGraw-Hill Companies, 2007 11.3 Structured Systems Analysis  Use of graphics to specify software was an important technique  Three popular graphical specification methods of 1970s  DeMarco  Gane and Sarsen  Yourdon  All are equivalent  All are equally good

16. Slide 11.16 © The McGraw-Hill Companies, 2007 11.3 Structured Systems Analysis (contd)  Many U.S. corporations use them for commercial products  Gane and Sarsen’s method is taught here because it is so widely used

17. Slide 11.17 © The McGraw-Hill Companies, 2007 11.3.1 Sally’s Software Shop Mini Case Study  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?

18. Slide 11.18 © The McGraw-Hill Companies, 2007 Sally’s Software Shop Mini Case Study (contd)  A better question  What business functions should she computerize Accounts payable Accounts receivable Inventory  Still better  How? Batch, or online? In-house or outsourcing?

19. Slide 11.19 © The McGraw-Hill Companies, 2007 Sally’s Software Shop Mini Case Study (contd)  The 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

20. Slide 11.20 © The McGraw-Hill Companies, 2007 Sally’s Software Shop Mini Case Study (contd)  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

21. Slide 11.21 © The McGraw-Hill Companies, 2007 Sally’s Software Shop Mini Case Study (contd)  The danger of many standard approaches  First produce the solution, then find out what the problem is! The software should run on an IBM mainframe  Gane and Sarsen’s method  Nine-step method to analyze the client’s need  Stepwise refinement is used in many steps

22. Slide 11.22 © The McGraw-Hill Companies, 2007 Structured system analysis  Nine steps  Step 1  Draw the data flow diagram to determine the logical data flow  What happens to the data!

23. Slide 11.23 © The McGraw-Hill Companies, 2007 Sally’s Software Shop Mini Case Study (contd)  The data flow diagram (DFD) shows the logical data flow  “What happens, not how it happens”  After you have determined the requirements  Only 4 symbols: Figure 11.1

24. Slide 11.24 © The McGraw-Hill Companies, 2007 Data flow diagram  DFD will be huge for complex system  Developed iteratively  Each flow of data starts and ends either at a source or destination or at a data store  Data are transformed by processes  Diagram refined by adding new flow of data or an existing flow is refined with more details

25. Slide 11.25 © The McGraw-Hill Companies, 2007 Step 1. Draw the DFD  First refinement  Infinite number of possible interpretations  Process_order – worker Figure 11.2

26. Slide 11.26 © The McGraw-Hill Companies, 2007 Step 1 (contd)  Second refinement  PENDING ORDERS is scanned daily Figure 11.3

27. Slide 11.27 © The McGraw-Hill Companies, 2007 Step 1 (contd)  Portion of third refinement Figure 11.4

28. Slide 11.28 © The McGraw-Hill Companies, 2007 Exercise  Apply DFD to define operations in a library  For example how books are being borrowed or returned

29. Slide 11.29 © The McGraw-Hill Companies, 2007 Step 1 (contd)  The final DFD is larger  But it is easily understood by the client  When dealing with larger DFDs  Set up a hierarchy of DFDs  Use proper symbol (such as a box) to represent DFD at lower level  A box becomes a DFD at a lower level

30. Slide 11.30 © The McGraw-Hill Companies, 2007 Step 2. Decide What Parts to Computerize and How  It depends on how much client is prepared to spend  Large volumes of data, tight controls  Batch (collect sufficient order and then process together)  Small volumes of data, in-house microcomputer  Online  Cost/benefit analysis – to determine what to computerize

31. Slide 11.31 © The McGraw-Hill Companies, 2007 Step 3. Determine the Details of the Data Flows  Determine the data items for each data flow  Refine each flow stepwise  Example; order: order_identification customer_details package_details  We need a data dictionary for larger products – to keep track of all the data elements.

32. Slide 11.32 © The McGraw-Hill Companies, 2007 Sample Data Dictionary Entries Figure 11.5

33. Slide 11.33 © The McGraw-Hill Companies, 2007 Step 4. Define the Logic of the Processes  We have process give educational discount  Sally must explain the discount she gives to educational institutions 10% on up to 4 packages 15% on 5 or more

34. Slide 11.34 © The McGraw-Hill Companies, 2007 Step 4. Define the Logic of the Processes (contd)  Translate this into a decision tree Figure 11.6

35. Slide 11.35 © The McGraw-Hill Companies, 2007 Step 5. Define the Data Stores  Define the exact contents and representation (format)  Specify where immediate access is required  Data immediate-access diagram (DIAD)  How the data stored can be searched – by name, by machine and by function

36. Slide 11.36 © The McGraw-Hill Companies, 2007 Step 6. Define the Physical Resources  For each file, specify  File name  Organization of the file (sequential, indexed, etc.)  Storage medium – in DVD, tape, or RAID  Blocking factor – how large is a block of data  Records (to field level)  Table information, if a DBMS (Data Base Management System) is to be used

37. Slide 11.37 © The McGraw-Hill Companies, 2007 Step 7. Determine Input/Output Specifications  Specify  Input forms – the paper form  Input screens - GUI  Printed output

38. Slide 11.38 © The McGraw-Hill Companies, 2007 Step 8. Determine the Sizing  Obtain the numerical data that are needed in Step 9 to determine the 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. Slide 11.39 © The McGraw-Hill Companies, 2007 Step 9. Determine the Hardware Requirements  Mass storage requirements – to store the data  Mass storage for back-up  Input needs – scanner, keyboard  Output devices – printer, monitor  Is the existing hardware adequate?  If not, recommend whether to buy or lease additional hardware

40. Slide 11.40 © The McGraw-Hill Companies, 2007 Steps to perform structured systems analysis  Draw the data flow diagram  Decide what sections to computerize and how (batch processing or online)  Determine the details of the data flows  Define the logic of the processes  Define the data stores  Define the physical resources  Determine the input-output specifications  Perform the sizing  Determine the hardware requirements

41. Slide 11.41 © The McGraw-Hill Companies, 2007 However  Response times cannot be determined  The 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

42. Slide 11.42 © The McGraw-Hill Companies, 2007 Overall  The method of Gane and Sarsen/De Marco/ Yourdon has resulted in major improvements in the software industry

43. Slide 11.43 © The McGraw-Hill Companies, 2007 11.4 Structured Systems Analysis: The MSG Foundation Case Study Figure 11.9  Data flow diagram

44. Slide 11.44 © The McGraw-Hill Companies, 2007 Structured Systems Analysis: The MSG Foundation Case Study (contd)  As reflected in the DFD, the user can perform three different types of operations:  1.Update investment data, mortgage data, or operating expenses data:  The USER enters an update_request  To update investment data, process perform_selected_update solicits the updated_investment_details from the USER, and sends then to the INVESTMENT_DATA store of data  Updating mortgage data or expenses data is similar

45. Slide 11.45 © The McGraw-Hill Companies, 2007 Structured Systems Analysis: The MSG Foundation Case Study (contd)  2.Print a listing of investments or mortgages:  To print a list of investments, the USER enters an investment_report_request. Process generate_listing_of_investments then obtains investment data from store INVESTMENT_DATA, formats the report, and then prints the report  Printing a listing of mortgages is similar

46. Slide 11.46 © The McGraw-Hill Companies, 2007 Structured Systems Analysis: The MSG Foundation Case Study (contd)  3.Print a report showing available funds for mortgages for the week:  The USER enters a funds_availability_report_request.  To determine how much money is available for mortgages for the current week, process compute_availability_of_funds_and_generate_funds_report then obtains (see next slide):

47. Slide 11.47 © The McGraw-Hill Companies, 2007 Structured Systems Analysis: The MSG Foundation Case Study (contd)  investment_details from store INVESTMENT_DATA and computes the expected total annual return on investments  mortgage_details from store MORTGAGE_DATA and computes the expected income for the week, expected mortgage payments for the week, and expected grants for the week  annual_operating_expenses from store EXPENSES_DATA and computes the expected annual operating expense

48. Slide 11.48 © The McGraw-Hill Companies, 2007 Structured Systems Analysis: The MSG Foundation Case Study (contd)  Process compute_availability_of_funds_and_ generate_funds _ report then uses these results to compute available_funds_for_week, and format and print the report

49. Slide 11.49 © The McGraw-Hill Companies, 2007 11.6 Entity-Relationship Modeling  Semi-formal technique  Widely used for specifying databases  Example: Figure 11.10

50. Slide 11.50 © The McGraw-Hill Companies, 2007 Entity-Relationship Diagrams (contd)  Many-to-many relationship Figure 11.11

51. Slide 11.51 © The McGraw-Hill Companies, 2007 Entity-Relationship Diagrams (contd)  More complex entity-relationship diagrams Figure 11.12

52. Slide 11.52 © The McGraw-Hill Companies, 2007 Exercise  Apply ERD to define something in a University

53. Slide 11.53 © The McGraw-Hill Companies, 2007 Finite state machine  Finite state machine is a formal specification technique  A system is defined by different states  It is based on the  State  Input  Transition function  Initial state  Final state  A diagram or a table is used to describe how a state is transited to another state

54. Slide 11.54 © The McGraw-Hill Companies, 2007 11.7 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 Figure 11.13

55. Slide 11.55 © The McGraw-Hill Companies, 2007 Finite State Machines (contd)  The set of states J is { Safe Locked, A, B, Safe Unlocked, Sound Alarm }  The set of inputs K is { 1L, 1R, 2L, 2R, 3L, 3R }  The transition function T is on the next slide  The initial state J is Safe Locked  The set of final states J is { Safe Unlocked, Sound Alarm }

56. Slide 11.56 © The McGraw-Hill Companies, 2007 Figure 11.14 Finite State Machines (contd)  Transition table

57. Slide 11.57 © The McGraw-Hill Companies, 2007 Extended Finite State Machines  FSM transition rules have the form (for a menu driven GUI) current state [menu] and event [option selected]  new state  Extend the standard FSM by adding global predicates ( a term designating a property or relation )  Predicate is something either “true” or “false”  Transition rules then take the form current state and event and predicate  new state

58. Slide 11.58 © The McGraw-Hill Companies, 2007 11.7.1 Finite State Machines: The Elevator Problem Case Study 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

59. Slide 11.59 © The McGraw-Hill Companies, 2007 Finite State Machines: The Elevator Problem Case Study (contd)  There are 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

60. Slide 11.60 © The McGraw-Hill Companies, 2007 Elevator Buttons  EB (e, f):  Elevator Button in elevator e pressed to request floor f

61. Slide 11.61 © The McGraw-Hill Companies, 2007 Elevator Buttons (contd)  Two states EBON (e, f): Elevator Button (e,f) ON EBOFF (e,f):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 Figure11.15

62. Slide 11.62 © The McGraw-Hill Companies, 2007 Elevator Buttons (contd)  Two events EBP (e,f):Elevator Button (e,f) Pressed EHAF (e,f):Elevator e Has Arrived 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 EHAF (e,f)  EBOFF (e,f)

63. Slide 11.63 © The McGraw-Hill Companies, 2007 Floor Buttons  FB (d, f):  Floor Button on floor f that requests elevator traveling in direction d  Direction “Up” or “Down”

64. Slide 11.64 © The McGraw-Hill Companies, 2007  States FBON (d, f):Floor Button (d, f) ON FBOFF (d, f):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 Floor Buttons (contd) Figure 11.16

65. Slide 11.65 © The McGraw-Hill Companies, 2007 Floor Buttons (contd)  Events FBP (d, f):Floor Button (d, f) Pressed EHAF (1..n, f):Elevator 1 or … or n Has Arrived at Floor f  Predicate S (d, e, f):Elevator e is visiting floor f Direction of motion is up (d = U), down (d = D), or no requests are pending (d = N)  Transition rules FBOFF (d, f) and FBP (d, f) and not S (d, 1..n, f)  FBON (d, f) FBON (d, f) and EHAF (1..n, f) and S (d, 1..n, f)  FBOFF (d, f), d = U or D

66. Slide 11.66 © The McGraw-Hill Companies, 2007 Finite State Machines: The Elevator Problem Case Study (contd)  The state of the elevator consists of component substates, including:  Elevator slowing  Elevator stopping  Door opening  Door open with timer running  Door closing after a timeout

67. Slide 11.67 © The McGraw-Hill Companies, 2007 Elevator Problem: FSM (contd)  We assume that the elevator controller moves the elevator through the 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, the three stopped states S (U, e, f), S (N, e, f), and S (D, e, f) are grouped into one larger state

68. Slide 11.68 © The McGraw-Hill Companies, 2007 State Transition Diagram for Elevator Figure 11.17

69. Slide 11.69 © The McGraw-Hill Companies, 2007 Elevator Problem: FSM (contd)  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)  Transition Rules If the elevator e is in state S (d, e, f) (stopped, d -bound, at floor f ), and the doors close, then elevator e will move up, down, or go into the 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)

70. Slide 11.70 © The McGraw-Hill Companies, 2007 Finite State Machines (contd)  The power of an FSM to specify complex systems  There is no need for complex preconditions and postconditions  Reading the FSM diagram can determine the conditions  Specifications take the simple form current state and event and predicate  next state

71. Slide 11.71 © The McGraw-Hill Companies, 2007 Finite State Machines (contd)  Using an FSM, a specification is  Easy to write down  Easy to validate  Easy to convert into a design  Easy to convert into code automatically  More precise than graphical methods  Almost as easy to understand  Easy to maintain  However  Timing considerations are not handled

72. Slide 11.72 © The McGraw-Hill Companies, 2007 Exercise  Apply FSM to design a dialing action of a mobile phone

73. Slide 11.73 © The McGraw-Hill Companies, 2007 Petri Net  Invented by Carl Adam Petri  Currently has wide applications in computer science in fields including performance evaluation, operating systems, and software engineering  Able to describe concurrent interrelated activities

74. Slide 11.74 © The McGraw-Hill Companies, 2007 Petri Nets Example

75. Slide 11.75 © The McGraw-Hill Companies, 2007 Petri Nets basic elements  Four parts  A set of places P {p1, p2, p3, p4}  A set of transitions T {t1, t2}  An input function I I(t1) = {p2, p4} i(t2) = {p2}  An output function O O(t1) = {p1} O(t2) = {p3, p3} as there are 2 arrows

76. Slide 11.76 © The McGraw-Hill Companies, 2007 Petri Nets  Marking – assignment of tokens to a Petri Net  Token is represented by a  The marking can be represented by a vector (1,2,0,1) based on the sequence and number of tokens in the places  A transition is enabled if each of its input places has as many tokens in it as there are arcs from the place to that transition  Tokens will be moved from input places to an output when a transition is fired

77. Slide 11.77 © The McGraw-Hill Companies, 2007 Petri Net

78. Slide 11.78 © The McGraw-Hill Companies, 2007 Petri Net

79. Slide 11.79 © The McGraw-Hill Companies, 2007 Petri Net

80. Slide 11.80 © The McGraw-Hill Companies, 2007 Transition fire  T1 fires – one token would be removed from p2 an one from p4; one new token would be placed in p1  T2 fires – one token would be removed from p2, and 2 new tokens would be placed in p3  The number of tokens is not conserved  Petri Nets are nondeterministic – if more than one transition can fire, then any one of them can be fired

81. Slide 11.81 © The McGraw-Hill Companies, 2007 Petri Net  Inhibitor arc – marked by a small circle  No token is needed on an inhibitor input arcs

82. Slide 11.82 © The McGraw-Hill Companies, 2007 Petri Nets example  Based on the elevator system  There are n elevator and m floors  Each floor is represented by a place F f where 1<=f<=m  An elevator is represented by a token  A token in F f denotes that an elevator is at floor f  The elevator button for floor f is represented in the Petri Net by place EB f  A token in EB f denotes that the elevator button for floor f is illuminated

83. Slide 11.83 © The McGraw-Hill Companies, 2007 Elevator problem  If the button EB f is not illuminated, due to the inhibitor arc, the transition EB f pressed is enabled and a token is in EB f  When the button is pressed again, EB f pressed will not fire because of the inhibitor arc (as there is now token in EB f )  If the elevator is to travel from floor g to floor f, transition Elevator in action is enabled because token in F g and EB f  Token in EB f and F g will be removed and a new token is placed in F f

84. Slide 11.84 © The McGraw-Hill Companies, 2007 Petri Net example

85. Slide 11.85 © The McGraw-Hill Companies, 2007 Petri Net

86. Slide 11.86 © The McGraw-Hill Companies, 2007 11.9 Z  Z is a formal specification language  Requires knowledge in set theory, functions, mathematics etc  A Z specification consists of four sections:  1.Given sets, data types, and constants  2.State definition  3.Initial state  4.Operations

87. Slide 11.87 © The McGraw-Hill Companies, 2007 1. Given sets  Given sets are sets that need not be defined in detail  Names appear in brackets  Here we need the set of all buttons  The specification therefore begins [Button]

88. Slide 11.88 © The McGraw-Hill Companies, 2007 2. State Definition  Z specification consists of a number of schemata  A schema is an outline of a theory  A schema is used to introduce the state variables  A schema consists of a group of variable declarations, plus  Declarations – the names and types of the entities introduced in the schema  A list of predicates that constrain the values of variables and relationships between the entities in declarations Figure 11.25

89. Slide 11.89 © The McGraw-Hill Companies, 2007 Z: The Elevator Problem Case Study (contd)  In this problem there are 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)

90. Slide 11.90 © The McGraw-Hill Companies, 2007 Symbols used in Z schema

91. Slide 11.91 © The McGraw-Hill Companies, 2007 Schema Button_State Figure 11.26

92. Slide 11.92 © The McGraw-Hill Companies, 2007 3. Initial State  The state when the system is first turned on Button_Init ^= [Button_State' | pushed' =  ] (The caret ^ should be on top of the first equals sign =. Unfortunately, this is hard to type in PowerPoint!) Pushed’ = the updated set

93. Slide 11.93 © The McGraw-Hill Companies, 2007 4. Operations  ΔButton_state – the operation changes the state  A button pushed for the first time is turned on, and added to set pushed  Without the third precondition, the results would be unspecified

94. Slide 11.94 © The McGraw-Hill Companies, 2007 Z: The Elevator Problem Case Study (contd)  If an elevator arrives at a floor, the corresponding button(s) must be turned off or removed from the set pushed  Pushed \ {button?}  The solution does not distinguish between up and down floor buttons Figure 11.28

95. Slide 11.95 © The McGraw-Hill Companies, 2007 11.9.2 Analysis of Z  Z is the most widely used formal specification language  It has been used to specify  CICS (part) – a software system of IBM  An oscilloscope  A CASE tool  Many large-scale projects (especially in Europe)

96. Slide 11.96 © The McGraw-Hill Companies, 2007 Analysis of Z (contd)  Difficulties in using Z  The large and complex set of symbols  Training in mathematics is needed

97. Slide 11.97 © The McGraw-Hill Companies, 2007 Analysis of Z (contd)  Reasons for the great success of Z  It is easy to find faults in Z specifications  The specifier must be extremely precise  We can prove correctness (we do not have to)  Only high-school math needed to read Z  Z decreases development time  A “translation” of a Z specification into English (or another natural language) is clearer than an informal specification

98. Slide 11.98 © The McGraw-Hill Companies, 2007 11.10 Other Formal Techniques  Anna  For Ada  Gist, Refine  Knowledge-based  VDM  Uses denotational semantics   CSP  CSP specifications are executable  Like Z, CSP has a high squiggle factor

99. Slide 11.99 © The McGraw-Hill Companies, 2007 11.11 Comparison of Classical Analysis Techniques  Formal methods are  Powerful, but  Difficult to learn and use  Informal methods have  Little power, but are  Easy to learn and use  There is therefore a trade-off  Ease of use versus power

100. Slide 11.100 © The McGraw-Hill Companies, 2007 Comparison of Classical Analysis Techniques (contd) Figure 11.29

101. Slide 11.101 © The McGraw-Hill Companies, 2007 Which Analysis Technique Should Be Used?  It depends on the  Project  Development team  Management team  Myriad other factors  It is unwise to ignore the latest developments

102. Slide 11.102 © The McGraw-Hill Companies, 2007 11.12 Testing during Classical Analysis  Specification inspection  Aided by fault checklist  Results of Doolan [1992]  2 million lines of FORTRAN  1 hour of inspecting saved 30 hours of execution-based testing

103. Slide 11.103 © The McGraw-Hill Companies, 2007 11.16 Challenges of Classical Analysis  A specification document must be  Informal enough for the client; but  Formal enough for the development team  Analysis (“what”) should not cross the boundary into design (“how”)  Do not try to assign modules to process boxes of DFDs until the classical design phase

104. Slide 11.104 © The McGraw-Hill Companies, 2007 FSM example  Use FSM to describe the operation of a lamp with a push switch.  Consider the control of a small part of a chemical plant. Temperature and pressure levels must be monitored for safety reasons. Sensors are installed to generate appropriate signals when either of these levels exceeds some predefined values. A trivial policy for managing the plant is the following: when either one of the signals is raised by the corresponding sensor, the control system shuts the plant off and raises an alarm signal; the system is restarted manually when the cause of the failure has been rectified.

105. Slide 11.105 © The McGraw-Hill Companies, 2007 Z example  Apply Z specification to describe part of the library system  Identify the set  State definition  Initial state  Operation of book return