Slide 5.

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 Slide 5.2

THE TOOLS
OF THE TRADE

© The McGraw-Hill Companies, 2002

 Overview Slide 5.3

● 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

 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 Slide 5.6

© The McGraw-Hill Companies, 2002

 Decompose Process Slide 5.7

● No further refinement is possible

© The McGraw-Hill Companies, 2002
First Refinement Slide 5.8

© The McGraw-Hill Companies, 2002

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 Slide 5.10

© The McGraw-Hill Companies, 2002

 Third Refinement Slide 5.11

● This design
has a major
fault

© The McGraw-Hill Companies, 2002

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 Slide 5.13

● 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

 Cost–Benefit Analysis Slide 5.14

● Compare estimated future benefits, costs

– Estimate costs
– Estimate benefits
– State all assumptions explicitly

© The McGraw-Hill Companies, 2002

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 Slide 5.17

● 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

 The Five Basic Metrics Slide 5.18

● 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

 Taxonomy of CASE Slide 5.19

● UpperCASE versus lowerCASE

● Tool versus workbench versus environment

© The McGraw-Hill Companies, 2002
 Graphical Tool Slide 5.20

● 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
 Essential Coding Tools Slide 5.21

● 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

 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 Slide 5.23

● 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

 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) Slide 5.25

● 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

 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) Slide 5.27

● 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

 Operating System Front-End in Editor Slide 5.28

● 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

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 Slide 5.30

● Example:
– Product executes terminates abruptly and prints
Overflow at 4B06, or
Core dumped, or
Segmentation fault

© The McGraw-Hill Companies, 2002

 Source Level Debugger (contd) Slide 5.31

● The programmer works in a high-level language,

but must examine
– 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 Slide 5.32

● Structure editor with

– 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 Slide 5.35

● 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

 Revisions and Variations (contd) Slide 5.36

● Variation
– Version for different operating system–hardware
– Variations are designed to coexist in parallel
© The McGraw-Hill Companies, 2002
 Configuration Control Slide 5.37

● 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
 Version Control Tool Slide 5.38

● Essential for programming-in-the-many

– First step toward configuration management
● Must handle
– Updates
– Parallel versions

© The McGraw-Hill Companies, 2002

 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 Slide 5.40

● Two programmers working on the same module

– mDual / 16
– mDual / 17
● Baselines
– Private workspaces
– Freezing
● Configuration control during development
– Informal testing
– SQA

© The McGraw-Hill Companies, 2002

 Build Tools Slide 5.41

● 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

 Productivity Gains with CASE Tools Slide 5.42

● 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