Slide 5.1
Object-Oriented and
Classical Software
Engineering
Fifth Edition, WCB/McGraw-Hill, 2002
Stephen R. Schach
srs@vuse.vanderbilt.edu
© The McGraw-Hill Companies, 2002
CHAPTER 5
THE TOOLS
OF THE TRADE
© The McGraw-Hill Companies, 2002
Slide 5.2
Overview









Stepwise refinement
Cost–benefit analysis
Software metrics
CASE
Taxonomy of CASE
Scope of CASE
Software versions
Configuration control
Build tools
© The McGraw-Hill Companies, 2002
Slide 5.3
Stepwise Refinement

Slide 5.4
A basic principle underlying many software
engineering techniques
– “Postpone decisions as to details as late as possible
to be able to concentrate on the important issues”

Miller’s law (1956)
– A human being can concentrate on 7±2 items at a
time
© The McGraw-Hill Companies, 2002
Stepwise Refinement Case Study


Slide 5.5
Design a product to update a sequential master
file containing name and address data for
monthly magazine True Life Software Disasters
Three types of transactions
– Type 1: INSERT (new subscriber into master file)
– Type 2: MODIFY (existing subscriber record)
– Type 3: DELETE (existing subscriber record)

Transactions are sorted into alphabetical order,
and by transaction code within alphabetical
order
© The McGraw-Hill Companies, 2002
Typical file of input transactions
© The McGraw-Hill Companies, 2002
Slide 5.6
Decompose Process

No further refinement is possible
© The McGraw-Hill Companies, 2002
Slide 5.7
First Refinement
© The McGraw-Hill Companies, 2002
Slide 5.8
Stepwise Refinement Case Study (contd)

Slide 5.9
Assumption
– We can produce a record when PROCESS requires it


Separate INPUT and OUTPUT, concentrate on
PROCESS
What is this PROCESS?
© The McGraw-Hill Companies, 2002
Second Refinement
© The McGraw-Hill Companies, 2002
Slide 5.10
Third Refinement

This design
has a major
fault
© The McGraw-Hill Companies, 2002
Slide 5.11
Stepwise Refinement Case Study (contd)

Slide 5.12
The third refinement is WRONG
– “Modify JONES” followed by “Delete JONES”

After the third refinement has been corrected
– Details like opening and closing files have been ignored
up to now
– Fix after the logic of the design is complete
– The stage at which an item is handled is vital

Opening and closing files is
– Ignored in early steps, but
– Essential later
© The McGraw-Hill Companies, 2002
Appraisal of Stepwise Refinement

A basic principle used in
– Every phase
– Every representation

The power of stepwise refinement
– The software engineer can concentrate
on the relevant aspects

Warning
– Miller’s Law is a fundamental restriction
on the mental powers of human beings
© The McGraw-Hill Companies, 2002
Slide 5.13
Cost–Benefit Analysis

Compare estimated future benefits, costs
– Estimate costs
– Estimate benefits
– State all assumptions explicitly
© The McGraw-Hill Companies, 2002
Slide 5.14
CASE (Computer-Aided Software Engineering)
Slide 5.15

Scope of CASE
– Can support the entire life-cycle

Graphical display tools (many for PCs)
–
–
–
–
–
Data flow diagrams
Entity-relationship diagrams
Module-interconnection diagrams
Petri nets
Structure charts
© The McGraw-Hill Companies, 2002
Software Metrics


Slide 5.16
To detect problems early, it is essential to measure
Examples:
– LOC per month
– Defects per 1000 lines of code
© The McGraw-Hill Companies, 2002
Different Types of Metrics

Product Metrics
– Examples:
» Size of product
» Reliability of product

Process Metrics
– Example:
» Efficiency of fault detection during
development

Metrics specific to a given phase
– Example:
» Number of defects detected per hour in
specification reviews
© The McGraw-Hill Companies, 2002
Slide 5.17
The Five Basic Metrics

Size
– In Lines of Code, or better

Cost
– In dollars

Duration
– In months

Effort
– In person months

Quality
– Number of faults detected
© The McGraw-Hill Companies, 2002
Slide 5.18
Taxonomy of CASE

UpperCASE versus lowerCASE

Tool versus workbench versus environment
© The McGraw-Hill Companies, 2002
Slide 5.19
Graphical Tool

Additional features
– Data dictionary
– Screen and report generators
– Consistency checker; the various
views are always consistent
» Specifications and design workbench

Online Documentation
– Problems with
» Manuals
» Updating

Essential online documentation
– Help information
– Programming standards
– Manuals
© The McGraw-Hill Companies, 2002
Slide 5.20
Essential Coding Tools

Coding tools
– Products (such as text editors, debuggers, and
pretty printers) designed to
» Simplify programmer’s task
» Reduce frustration
» Increase programmer productivity

Conventional coding scenario for
programming-in-the-small
– Editor-compiler cycle
– Editor-compiler-linker cycle
– Editor-compiler-linker-execute cycle

“There must be a better way”
© The McGraw-Hill Companies, 2002
Slide 5.21
Syntax-directed Editor

Slide 5.22
“Understands” language
– Speeds up implementation
– User interface of an editor is different to that of a compiler
» There is no need to change thinking mode
» No mental energy is wasted on these adjustments
– One piece of system software, two languages
» High-level language of module
» Editing command language
– Pretty-printer
© The McGraw-Hill Companies, 2002
Online Interface Checker

Example
– The programmer tries to call procedure
computeAverage, but the linker cannot find it
– The programmer realizes that the actual name
of the procedure is computeMean

A structure editor must support online
interface checking
– Editor must know name of every procedure

Interface checking is an important part of
programming-in-the-large
© The McGraw-Hill Companies, 2002
Slide 5.23
Online Interface Checker (contd)

Slide 5.24
Example
– The user enters the call
average = computeAverage (dataArray, numberOfValues);
– Editor immediately responds with a message such as
Procedure computeAverage not known

Programmer is given two choices
– Correct the name of the procedure
– Declare new procedure computeAverage and specify
its parameters

Enables full interface checking
© The McGraw-Hill Companies, 2002
Online Interface Checker (contd)

Example
– Declaration of q is
void q (float floatVar, int intVar, String s1, String s2);
– Call (invocation) is
q (intVar, floatVar, s1, s2);
– Online interface checker detects the fault

Help facility
– Online information as to parameters of
method q
– Better: Editor generates a template for the call
» Shows type of each parameter
» Programmer replaces formal by actual parameter
© The McGraw-Hill Companies, 2002
Slide 5.25
Online Interface Checker (contd)

Slide 5.26
Advantages
– No need for different tools with different interfaces
– Hard-to-detect faults are immediately flagged for
correction
» Wrong number of parameters
» Parameters of wrong type

Essential when software is produced by a team
– If one programmer changes the interface specification,
all modules calling that changed module must be
disabled
© The McGraw-Hill Companies, 2002
Online Interface Checker (contd)

Remaining problem
– The programmer still has to exit from the editor to
invoke the compiler (to generate code)
– Then, the linker must be called to link the product
– Must adjust to the JCL, compiler, and linker output
© The McGraw-Hill Companies, 2002
Slide 5.27
Operating System Front-End in Editor

Single command
– go or run
– Use of the mouse to choose icon, or menu
selection

Causes editor to invoke the compiler, linker,
loader, and execute the product
© The McGraw-Hill Companies, 2002
Slide 5.28
Operating System Front-End in Editor (contd)
Slide 5.29

Online documentation
– Help information regarding
» Operating system
» Editor
» Programming language
– Programming standards
– Manuals
» Editor manuals
» Programming manuals
© The McGraw-Hill Companies, 2002
Source Level Debugger

Example:
– Product executes terminates abruptly and prints
Overflow at 4B06, or
Core dumped, or
Segmentation fault
© The McGraw-Hill Companies, 2002
Slide 5.30
Source Level Debugger (contd)

The programmer works in a high-level language,
but must examine
–
–
–
–


Slide 5.31
Machine code core dumps
Assembler listings
Linker listings
Similar low-level documentation
Destroys the advantage of programming in a
high-level language
We need
– Interactive source level debugger (like dbx)
© The McGraw-Hill Companies, 2002
Programming Workbench

Structure editor with
–
–
–
–

Slide 5.32
Online interface checking capabilities
Operating system front-end
Online documentation
Source level debugger
Constitutes a simple programming environment
© The McGraw-Hill Companies, 2002
Programming Workbench (contd)

Slide 5.33
This is by no means new
– All the above features are supported by FLOW (1980)
– The technology has been in place for years

Surprisingly, some programmers still implement
code Ye Olde-Fashioned Way
© The McGraw-Hill Companies, 2002
Software Versions

Slide 5.34
During maintenance, at all times there are at
least two versions of the product:
– The old version, and
– The new version

Two types of versions: revisions and variations
© The McGraw-Hill Companies, 2002
Revisions and Variations

Revision
– Version to fix a fault in the module
– We cannot throw away an incorrect version

Perfective and adaptive maintenance also
results in revisions
© The McGraw-Hill Companies, 2002
Slide 5.35
Revisions and Variations (contd)

Variation
– Version for different operating system–hardware
– Variations are designed to coexist in parallel
© The McGraw-Hill Companies, 2002
Slide 5.36
Configuration Control

Every module
exists in three
forms
– Source code;
object code;
executable load
image

Configuration
– Version of each
module from
which a given
version of a
product is built
© The McGraw-Hill Companies, 2002
Slide 5.37
Version Control Tool

Essential for programming-in-the-many
– First step toward configuration management

Must handle
– Updates
– Parallel versions
© The McGraw-Hill Companies, 2002
Slide 5.38
Version Control Tool (contd)

Slide 5.39
Possible notation
– printerDriver (laser) / 13
– printerDriver (inkJet) / 25

Problem of multiple variations
– Deltas

Version control is not enough—maintenance issues
© The McGraw-Hill Companies, 2002
Configuration Control and Maintenance

Two programmers working on the same module
– mDual / 16
– mDual / 17

Baselines
– Private workspaces
– Freezing

Slide 5.40
Configuration control during development
– Informal testing
– SQA
© The McGraw-Hill Companies, 2002
Build Tools

Example
– UNIX make

Compares the date and time stamp on
– Source code, object code
– Object code, executable load image

Can check dependencies
– Ensures that correct versions/variations are
compiled and linked
© The McGraw-Hill Companies, 2002
Slide 5.41
Productivity Gains with CASE Tools

Survey of 45 companies in 10 industries
[Myers, 1992]
– Half information systems
– Quarter scientific
– Quarter real-time aerospace

Results
– About 10% annual productivity gains
– $125,000 per seat

Justifications for CASE
–
–
–
–
Faster development
Fewer faults
Easier maintenance
Improved morale
© The McGraw-Hill Companies, 2002
Slide 5.42