1 / 42

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

This chapter explores the tools used in the software engineering process, including stepwise refinement, cost-benefit analysis, software metrics, computer-aided software engineering (CASE), and coding tools.

cushing
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related