Upload
meghan-patterson
View
219
Download
0
Embed Size (px)
Citation preview
Slide 11C.1
© The McGraw-Hill Companies, 2005
Object-Oriented and Classical Software
Engineering
Sixth Edition, WCB/McGraw-Hill, 2005
Stephen R. [email protected]
Slide 11C.4
© The McGraw-Hill Companies, 2005
11.9 Z
Z (pronounced “zed”) is a formal specification language
There is a high squiggle factor
Slide 11C.5
© The McGraw-Hill Companies, 2005
11.9.1 Z: The Elevator Problem Case Study
A Z specification consists of four sections:1. Given sets, data types, and constants2. State definition3. Initial state4. Operations
Slide 11C.6
© The McGraw-Hill Companies, 2005
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]
Slide 11C.7
© The McGraw-Hill Companies, 2005
2. State Definition
Z specification consists of a number of schemataA schema consists of a group of variable declarations,
plusA list of predicates that constrain the values of variables
Figure 11.25
Slide 11C.8
© The McGraw-Hill Companies, 2005
Z: The Elevator Problem Case Study (contd)
In this problem there are four subsets of Button
The floor buttonsThe elevator buttons buttons (the set of all buttons in the elevator problem) pushed (the set of buttons that have been pushed)
Slide 11C.10
© The McGraw-Hill Companies, 2005
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!)
Slide 11C.11
© The McGraw-Hill Companies, 2005
4. 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
Figure 11.27
Slide 11C.12
© The McGraw-Hill Companies, 2005
Z: The Elevator Problem Case Study (contd)
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
Figure 11.28
Slide 11C.13
© The McGraw-Hill Companies, 2005
11.9.2 Analysis of Z
Z is the most widely used formal specification language
It has been used to specifyCICS (part)An oscilloscopeA CASE toolMany large-scale projects (especially in Europe)
Slide 11C.14
© The McGraw-Hill Companies, 2005
Analysis of Z (contd)
Difficulties in using ZThe large and complex set of symbolsTraining in mathematics is needed
Slide 11C.15
© The McGraw-Hill Companies, 2005
Analysis of Z (contd)
Reasons for the great success of Z It is easy to find faults in Z specificationsThe specifier must be extremely preciseWe can prove correctness (we do not have to)Only high-school math needed to read ZZ decreases development timeA “translation” of a Z specification into English (or
another natural language) is clearer than an informal specification
Slide 11C.16
© The McGraw-Hill Companies, 2005
11.10 Other Formal Techniques
Anna For Ada
Gist, RefineKnowledge-based
VDM Uses denotational semantics
CSP CSP specifications are executableLike Z, CSP has a high squiggle factor
Slide 11C.17
© The McGraw-Hill Companies, 2005
11.11 Comparison of Classical Analysis Techniques
Formal methods arePowerful, butDifficult to learn and use
Informal methods haveLittle power, but areEasy to learn and use
There is therefore a trade-off Ease of use versus power
Slide 11C.18
© The McGraw-Hill Companies, 2005
Comparison of Classical Analysis Techniques (contd)
Figure 11.29
Slide 11C.19
© The McGraw-Hill Companies, 2005
Newer Methods
Many are untested in practice
There are risks involvedTraining costsAdjustment from the classroom to an actual projectCASE tools may not work properly
However, possible gains may be huge
Slide 11C.20
© The McGraw-Hill Companies, 2005
Which Analysis Technique Should Be Used?
It depends on theProjectDevelopment teamManagement teamMyriad other factors
It is unwise to ignore the latest developments
Slide 11C.21
© The McGraw-Hill Companies, 2005
11.12 Testing during Classical Analysis
Specification inspectionAided by fault checklist
Results of Doolan [1992]2 million lines of FORTRAN1 hour of inspecting saved 30 hours of execution-based
testing
Slide 11C.22
© The McGraw-Hill Companies, 2005
11.13 CASE Tools for Classical Analysis
A graphical tool is exceedingly useful
So is a data dictionary Integrate them
An analysis technique without CASE tools to support it will failThe SREM experience
Slide 11C.23
© The McGraw-Hill Companies, 2005
CASE Tools for Classical Analysis (contd)
Typical toolsAnalyst/DesignerSoftware through PicturesSystem Architect
Slide 11C.24
© The McGraw-Hill Companies, 2005
11.14 Metrics for CASE Tools
Five fundamental metrics
QualityFault statisticsThe number, type of each faultThe rate of fault detection
Metrics for “predicting” the size of a target productTotal number of items in the data dictionaryThe number of items of each typeProcesses vs. modules
Slide 11C.25
© The McGraw-Hill Companies, 2005
11.15 Software Project Management Plan: The Osbert Oglesby Case Study
The Software Project Management Plan is given in Appendix F
Slide 11C.26
© The McGraw-Hill Companies, 2005
11.16 Challenges of Classical Analysis
A specification document must be Informal enough for the client; butFormal 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