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

2. Slide 11C.105 © The McGraw-Hill Companies, 2005 CHAPTER 11 — Unit C CLASSICAL ANALYSIS

3. Slide 11C.106 © The McGraw-Hill Companies, 2005 Continued from Unit 11B

4. Slide 11C.107 © The McGraw-Hill Companies, 2005 11.9 Z l Z (pronounced “zed”) is a formal specification language l There is a high squiggle factor

5. Slide 11C.108 © The McGraw-Hill Companies, 2005 11.9.1 Z: The Elevator Problem Case Study l A Z specification consists of four sections:  1.Given sets, data types, and constants  2.State definition  3.Initial state  4.Operations

6. Slide 11C.109 © The McGraw-Hill Companies, 2005 1. Given sets l Given sets are sets that need not be defined in detail l Names appear in brackets l Here we need the set of all buttons l The specification therefore begins [Button]

7. Slide 11C.110 © The McGraw-Hill Companies, 2005 2. State Definition l Z specification consists of a number of schemata  A schema consists of a group of variable declarations, plus  A list of predicates that constrain the values of variables Figure 11.25

8. Slide 11C.111 © The McGraw-Hill Companies, 2005 Z: The Elevator Problem Case Study (contd) l 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)

9. Slide 11C.112 © The McGraw-Hill Companies, 2005 Schema Button_State Figure 11.26

10. Slide 11C.113 © The McGraw-Hill Companies, 2005 3. Initial State l 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!)

11. Slide 11C.114 © The McGraw-Hill Companies, 2005 4. Operations l A button pushed for the first time is turned on, and added to set pushed l Without the third precondition, the results would be unspecified Figure 11.27

12. Slide 11C.115 © The McGraw-Hill Companies, 2005 Z: The Elevator Problem Case Study (contd) l If an elevator arrives at a floor, the corresponding button(s) must be turned off l The solution does not distinguish between up and down floor buttons Figure 11.28

13. Slide 11C.116 © The McGraw-Hill Companies, 2005 11.9.2 Analysis of Z l Z is the most widely used formal specification language l It has been used to specify  CICS (part)  An oscilloscope  A CASE tool  Many large-scale projects (especially in Europe)

14. Slide 11C.117 © The McGraw-Hill Companies, 2005 Analysis of Z (contd) l Difficulties in using Z  The large and complex set of symbols  Training in mathematics is needed

15. Slide 11C.118 © The McGraw-Hill Companies, 2005 Analysis of Z (contd) l 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

16. Slide 11C.119 © The McGraw-Hill Companies, 2005 11.10 Other Formal Techniques l Anna  For Ada l Gist, Refine  Knowledge-based l VDM  Uses denotational semantics  l CSP  CSP specifications are executable  Like Z, CSP has a high squiggle factor

17. Slide 11C.120 © The McGraw-Hill Companies, 2005 11.11 Comparison of Classical Analysis Techniques l Formal methods are  Powerful, but  Difficult to learn and use l Informal methods have  Little power, but are  Easy to learn and use l There is therefore a trade-off  Ease of use versus power

18. Slide 11C.121 © The McGraw-Hill Companies, 2005 Comparison of Classical Analysis Techniques (contd) Figure 11.29

19. Slide 11C.122 © The McGraw-Hill Companies, 2005 Newer Methods l Many are untested in practice l There are risks involved  Training costs  Adjustment from the classroom to an actual project  CASE tools may not work properly l However, possible gains may be huge

20. Slide 11C.123 © The McGraw-Hill Companies, 2005 Which Analysis Technique Should Be Used? l It depends on the  Project  Development team  Management team  Myriad other factors l It is unwise to ignore the latest developments

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

22. Slide 11C.125 © The McGraw-Hill Companies, 2005 11.13 CASE Tools for Classical Analysis l A graphical tool is exceedingly useful l So is a data dictionary  Integrate them l An analysis technique without CASE tools to support it will fail  The SREM experience

23. Slide 11C.126 © The McGraw-Hill Companies, 2005 CASE Tools for Classical Analysis (contd) l Typical tools  Analyst/Designer  Software through Pictures  System Architect

24. Slide 11C.127 © The McGraw-Hill Companies, 2005 11.14 Metrics for CASE Tools l Five fundamental metrics l Quality  Fault statistics  The number, type of each fault  The rate of fault detection l Metrics for “predicting” the size of a target product  Total number of items in the data dictionary  The number of items of each type  Processes vs. modules

25. Slide 11C.128 © The McGraw-Hill Companies, 2005 11.15 Software Project Management Plan: The Osbert Oglesby Case Study l The Software Project Management Plan is given in Appendix F

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