CHAPTER 5 THE TOOLS OF THE TRADE

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

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

Sequential master file update product 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 Number of faults detected per hour in specification reviews

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

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

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

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

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 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) 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 www.merant.com MS SourceSafe Configuration control tool for MS Windows http://msdn.microsoft.com/ssafe/

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

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