MODULE: SOFTWARE ENGINEERING

TOPIC 4: TOOLS OF TRADE

Overview

• Analytical Tools
‒ Stepwise refinement
‒ Cost–benefit analysis
• Software metrics
• CASE
• Taxonomy of CASE
• Scope of CASE
• Software versions
• Configuration control
• Build tools
Stepwise Refinement

• A basic principle underlying many software

engineering techniques
‒ “Postpone decisions on details until as late as
possible to concentrate on the important
issues”

• Miller’s law (1956)

‒ A human being can concentrate on at most
7±2 items at a time
Stepwise Refinement Case Study

• 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 type within alphabetical order
Typical file of input transactions
Decompose Process

Sequential master file update product

First Refinement
Stepwise Refinement Case Study (contd)
• Assumption
‒ We can produce a record when PROCESS
requires it
• Separate INPUT and OUTPUT, concentrate on
PROCESS
• What is this PROCESS?
Second Refinement
Third Refinement
• This design has a
major fault
• What is it?
‒ “Modify
JONES”
followed by
“Delete
JONES”
Stepwise Refinement Case Study (contd)

• It is necessary to check each successive refinement before

proceeding to the next

• So, how do we fix this fault?

‒ By using level 1 lookahead
‒ A transaction record is processed only after the next
transaction record has been analyzed

• Do Problem 5.1 (pg. 132)

Stepwise Refinement Case Study (contd)

• After the third refinement has been corrected

‒ Details like opening and closing files have been ignored up to
now
‒ Add such details after the logic of the design is complete

• Opening and closing files is

‒ Ignored in early steps, but essential later
Appraisal of Stepwise Refinement

• This basic principle can be used in

‒ Every phase
‒ Every representation
• The power of stepwise refinement
‒ The software engineer can concentrate on
the relevant aspects of the current phase
• Warning
‒ Miller’s Law is a fundamental restriction on
the mental powers of human beings (7±2
items at a time)
Cost–Benefit Analysis
• Another SE technique that can be used
throughout the software life cycle to determine
whether an action would be profitable
• Compare estimated benefits against costs
‒ Estimate costs
‒ Estimate benefits

• If benefits > costs then GO AHEAD!

else DON’T!

• See KCEC Case Study (pg. 113)

Cost–Benefit Analysis (contd)

• Cost-benefit analysis it not always straightforward

‒ How can one measure the cost of someone trying
to adjust to computerization?
• Tangible benefits/costs are easy to measure but
intangible benefits/costs can be hard to quantify
directly
• A practical way of assigning a dollar value to
intangible benefits/costs is to make assumptions
Software Metrics

• To detect problems early, it is essential to measure

• Examples:
‒ Lines of code (LOC) per month
‒ Faults per 1000 lines of code
Different Types of Metrics

• Product Metrics
‒ Examples:
• Size of product (LOC)
• Quality of product (faults per 1000 LOC)
• Process Metrics
‒ Example:
• Efficiency of fault detection during
development
• Metrics specific to a given phase
‒ Example:
• Number of faults detected per hour in
specification reviews
The Five Basic Metrics

• Size
‒ In Lines of Code
• Cost
‒ In dollars
• Duration
‒ In months
• Effort
‒ In person-months
• Quality
‒ Number of faults
detected
CASE (Computer-Aided Software Engineering)

• Scope of CASE
‒ Can support the entire life-cycle

• Graphical display tools (many for PCs)

‒ Data flow diagrams
‒ Entity-relationship diagrams
‒ Structure charts
‒ Stage diagrams
‒ Class diagrams
‒ Interactions diagrams
Taxonomy of CASE

• UpperCASE (or front-end) versus lowerCASE (back-

end) tools

Tool vs. workbench vs. environment

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
• Documenting Manually
• Updating
• Essential online documentation
‒ Help information
‒ Programming standards
‒ Manuals
Essential Coding Tools

• Coding tools (text editors, debuggers, and pretty

printers) designed to
‒ Simplify programmer’s task
‒ Reduce frustration
‒ Increase programmer productivity
• Programming-in-the-small: refers to s/w
development at the level of the code of a single
module
• Programming-in-the-large: s/w development at
the module level
• Programming-in-the-many: s/w development by
a team of s/w engineers
Essential Coding Tools (contd)

• 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”
Syntax-Directed Editor
• “Understands” the implementation 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 is usually included
• Indentations to increase readability
• Boldface for reserved words
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
Online Interface Checker (contd)

• 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
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
Online Interface Checker (contd)

• 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
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
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
Source Level Debugger

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

‒ What do these mean?

Source Level Debugger (contd)
• 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
• It would be nice to have error messages as shown
in Figure 5.9
• We need
‒ Interactive source level debugger (e.g., dbx –
UNIX debugger)
Software Versions

• 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
Revisions and Variations

• Revision
‒ Version to fix a fault in the module
(corrective maintenance)
‒ The new version is called a revision
‒ We cannot throw away an incorrect
version

• Perfective and adaptive maintenance also

results in revisions
Revisions and Variations (contd)

• Variation
‒ Version for different operating system or
hardware
‒ Variations are designed to coexist in parallel
‒ Figure shows (a) revisions, (b) variations
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
Version Control Tool

• Essential for programming-in-the-many

• First step toward configuration management
‒ Which version of each module is compiled and
linked to the product?
‒ Given an executable load image, which version of
each module went into it?
• Must handle
‒ Updates
‒ Parallel versions
Version Control Tool (contd)

• Possible notation
‒ printerDriver (laser) / 13
‒ printerDriver (inkJet) / 25
• Problem of multiple variations
‒ A solution: store just one variation and then store
a delta (the list of differences) for each variation
• Version control is not enough – due to additional
problems associated with maintaining multiple
variations
Configuration Control and Maintenance

• Two programmers working on the same module

‒ mDual / 16 (current version)
‒ mDual / 17 & mDual / 18
• Baselines
‒ A baseline: a configuration (set of versions) of all
the modules in the product
‒ Copies any needed modules into private
workspace
‒ After making changes, the programmer freezes
the current version of the module – no other
programmer may make changes to any frozen
version
‒ Thus, only one programmer is allowed to make
any changes to a module at any one time
Version and Configuration Control Tools

• UNIX version control tools

‒ SCCS (source code control system)
‒ RCS (revision control system)
‒ CVS (concurrent versions system)

• PVCS
‒ Popular commercial configuration control tool
‒ [Link]

• MS SourceSafe
‒ Configuration control tool for MS Windows
‒ [Link]
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
Productivity Gains with CASE Tools

• Survey of 45 companies in 10 industries [Myers, 1992]

‒ 50% information systems
‒ 25% scientific
‒ 25% real-time aerospace
• Results
‒ About 10% annual productivity gains
• Justifications for CASE
‒ Faster development
‒ Fewer faults
‒ Easier maintenance
‒ Improved morale

• Read Chapter 5
THANK YOU