1 / 42

CHAPTER 5

CHAPTER 5. THE TOOLS OF THE 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.

josh
Download Presentation

CHAPTER 5

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. CHAPTER 5 THE TOOLS OF THE TRADE

  2. Overview • Analytical Tools • 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 ondetails 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. 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 todetermine 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 • Example: • Number of faults detected per hour in specification reviews

  18. The Five Basic Metrics • Size • 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. Taxonomy of CASE • UpperCASE (or front-end) versus lowerCASE (back-end) tools Tool vs. workbench vs. environment

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

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

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

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

  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 • goorrun • 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 • 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

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

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

  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] • 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

More Related