slide1 l.
Skip this Video
Loading SlideShow in 5 Seconds..
Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach srs@vuse.vand PowerPoint Presentation
Download Presentation
Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach srs@vuse.vand

Loading in 2 Seconds...

play fullscreen
1 / 42

Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach srs@vuse.vand - PowerPoint PPT Presentation

  • Uploaded on

Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach CHAPTER 5. THE TOOLS OF THE TRADE. Overview. Stepwise refinement Cost–benefit analysis Software metrics CASE Taxonomy of CASE Scope of CASE

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach srs@vuse.vand' - spencer

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Object-Oriented and Classical Software EngineeringFifth Edition, WCB/McGraw-Hill, 2002Stephen R.

chapter 5



  • Stepwise refinement
  • Cost–benefit analysis
  • Software metrics
  • CASE
  • Taxonomy of CASE
  • Scope of CASE
  • Software versions
  • Configuration control
  • Build tools
stepwise refinement
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
stepwise refinement case study
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
decompose process
Decompose Process
  • No further refinement is possible
stepwise refinement case study contd
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?
third refinement
Third Refinement
  • This design has a major fault
stepwise refinement case study contd12
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
appraisal of stepwise refinement
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
cost benefit analysis
Cost–Benefit Analysis
  • Compare estimated future benefits, costs
    • Estimate costs
    • Estimate benefits
    • State all assumptions explicitly
case computer aided software engineering
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
software metrics
Software Metrics
  • To detect problems early, it is essential to measure
  • Examples:
    • LOC per month
    • Defects per 1000 lines of code
different types of metrics
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
the five basic metrics
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
taxonomy of case
Taxonomy of CASE
  • UpperCASE versus lowerCASE
  • Tool versus workbench versus environment
graphical tool
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
essential coding tools
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”
syntax directed editor
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
online interface checker
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
online interface checker contd
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
online interface checker contd25
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
online interface checker contd26
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 contd27
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
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
operating system front end in editor contd
Operating System Front-End in Editor (contd)
  • Online documentation
    • Help information regarding
      • Operating system
      • Editor
      • Programming language
    • Programming standards
    • Manuals
      • Editor manuals
      • Programming manuals
source level debugger
Source Level Debugger
  • Example:
    • Product executes terminates abruptly and prints

Overflow at 4B06, or

Core dumped, or

Segmentation fault

source level debugger contd
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)
programming workbench
Programming Workbench
  • Structure editor with
    • Online interface checking capabilities
    • Operating system front-end
    • Online documentation
    • Source level debugger
  • Constitutes a simple programming environment
programming workbench contd
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
software versions
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
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
revisions and variations contd
Revisions and Variations (contd)
  • Variation
    • Version for different operating system–hardware
    • Variations are designed to coexist in parallel
configuration control
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
Version Control Tool
  • Essential for programming-in-the-many
    • First step toward configuration management
  • Must handle
    • Updates
    • Parallel versions
version control tool contd
Version Control Tool (contd)
  • Possible notation
    • printerDriver (laser) / 13
    • printerDriver (inkJet) / 25
  • Problem of multiple variations
    • Deltas
  • Version control is not enough—maintenance issues
configuration control and maintenance
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
build tools
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
productivity gains with case tools
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