Slide 11C.1

© The McGraw-Hill Companies, 2005

Object-Oriented and Classical Software

Engineering

Sixth Edition, WCB/McGraw-Hill, 2005

Stephen R. Schachsrs@vuse.vanderbilt.edu

Slide 11C.2

© The McGraw-Hill Companies, 2005

CHAPTER 11 — Unit C

CLASSICAL ANALYSIS

Slide 11C.3

© The McGraw-Hill Companies, 2005

Continued from Unit 11B

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.9

© The McGraw-Hill Companies, 2005

Schema Button_State

Figure 11.26

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