1. CHAPTER 5
THE TOOLS
OF THE TRADE

2. Overview Analytical Tools Software metrics CASE Taxonomy of CASE
Stepwise refinement
Cost–benefit analysis
Software metrics
CASE
Taxonomy of CASE
Scope of CASE
Software versions
Configuration control
Build tools

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

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

5. Typical file of input transactions

6. Sequential master file update product
Decompose Process
Sequential master file update product

7. First Refinement

8. 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?

9. Second Refinement

10. Third Refinement This design has a major fault What is it?
“Modify JONES” followed by “Delete JONES”

11. 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)

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

13. 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)

14. 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)

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

16. Software Metrics To detect problems early, it is essential to measure
Examples:
Lines of code (LOC) per month
Faults per 1000 lines of code

17. 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
Number of faults detected per hour in specification reviews

18. The Five Basic Metrics Size Cost Duration Effort Quality
In Lines of Code
Cost
In dollars
Duration
In months
Effort
In person-months
Quality
Number of faults detected

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

20. Tool vs. workbench vs. environment
Taxonomy of CASE
UpperCASE (or front-end) versus lowerCASE (back-end) tools
Tool vs. workbench vs. environment

21. Graphical Tool Additional features Online Documentation
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

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

23. 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”

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

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

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

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

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

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

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

31. Source Level Debugger Example:
Product executes terminates abruptly and prints
Overflow at 4B06, or
Core dumped, or
Segmentation fault
What do these mean?

32. 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)

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

34. Revisions and Variations
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

35. Revisions and Variations (contd)
Version for different operating system or hardware
Variations are designed to coexist in parallel
Figure shows (a) revisions, (b) variations

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

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

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

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

40. 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
MS SourceSafe
Configuration control tool for MS Windows

41. Build Tools Example Compares the date and time stamp on
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

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