The Tools of the Trade: Stepwise Refinement, Cost-Benefit Analysis, Software Metrics, and More

1. Object-Oriented and Classical Software EngineeringFifth Edition, WCB/McGraw-Hill, 2002Stephen R. Schachsrs@vuse.vanderbilt.edu

2. CHAPTER 5 THE TOOLS OF THE TRADE

3. Overview • Stepwise refinement • Cost–benefit analysis • Software metrics • CASE • Taxonomy of CASE • Scope of CASE • Software versions • Configuration control • Build tools

4. Stepwise Refinement • 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

5. 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 code within alphabetical order

6. Typical file of input transactions

7. Decompose Process • No further refinement is possible

8. First Refinement

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

10. Second Refinement

11. Third Refinement • This design has a major fault

12. Stepwise Refinement Case Study (contd) • 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

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

14. Cost–Benefit Analysis • Compare estimated future benefits, costs • Estimate costs • Estimate benefits • State all assumptions explicitly

15. 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 • Module-interconnection diagrams • Petri nets • Structure charts

16. Software Metrics • To detect problems early, it is essential to measure • Examples: • LOC per month • Defects per 1000 lines of code

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

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

19. Taxonomy of CASE • UpperCASE versus lowerCASE • Tool versus workbench versus environment

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

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

22. Syntax-directed Editor • “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

23. Online Interface Checker • Example • The programmer tries to call procedurecomputeAverage, 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

24. 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 procedurecomputeAverageand specify its parameters • Enables full interface checking

25. Online Interface Checker (contd) • Example • Declaration ofqis 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 methodq • Better: Editor generates a template for the call • Shows type of each parameter • Programmer replaces formal by actual parameter

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

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

28. Operating System Front-End in Editor • Single command • goorrun • Use of the mouse to choose icon, or menu selection • Causes editor to invoke the compiler, linker, loader, and execute the product

29. Operating System Front-End in Editor (contd) • Online documentation • Help information regarding • Operating system • Editor • Programming language • Programming standards • Manuals • Editor manuals • Programming manuals

30. Source Level Debugger • Example: • Product executes terminates abruptly and prints Overflow at 4B06, or Core dumped, or Segmentation fault

31. 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 • We need • Interactive source level debugger (like dbx)

32. Programming Workbench • Structure editor with • Online interface checking capabilities • Operating system front-end • Online documentation • Source level debugger • Constitutes a simple programming environment

33. Programming Workbench (contd) • 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

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

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

36. Revisions and Variations (contd) • Variation • Version for different operating system–hardware • Variations are designed to coexist in parallel

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

38. Version Control Tool • Essential for programming-in-the-many • First step toward configuration management • Must handle • Updates • Parallel versions

39. Version Control Tool (contd) • Possible notation • printerDriver (laser) / 13 • printerDriver (inkJet) / 25 • Problem of multiple variations • Deltas • Version control is not enough—maintenance issues

40. Configuration Control and Maintenance • Two programmers working on the same module • mDual / 16 • mDual / 17 • Baselines • Private workspaces • Freezing • Configuration control during development • Informal testing • SQA

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

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