slide 5.1 object-oriented and classical software...
TRANSCRIPT
Slide 5.1
© The McGraw-Hill Companies, 2007
Object-Oriented andClassical Software
Engineering
Seventh Edition, WCB/McGraw-Hill, 2007
Stephen R. [email protected]
Slide 5.2
© The McGraw-Hill Companies, 2007
CHAPTER 5
THE TOOLSOF THE TRADE
Slide 5.3
© The McGraw-Hill Companies, 2007
Overview
Stepwise refinement Cost–benefit analysis Software metrics CASE Taxonomy of CASE Scope of CASE Software versions Configuration control Build tools Productivity gains with CASE technology
Slide 5.4
© The McGraw-Hill Companies, 2007
5.1 Stepwise Refinement
A basic principle underlying many softwareengineering 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
Slide 5.5
© The McGraw-Hill Companies, 2007
5.1.1 Stepwise Refinement Mini Case Study
Design a product to update a sequential masterfile containing name and address data for themonthly magazine True Life Software Disasters
Three types of transactionsType 1: INSERT (a new subscriber into the master file)Type 2: MODIFY (an existing subscriber record)Type 3: DELETE (an existing subscriber record)
Transactions are sorted into alphabetical order,and by transaction code within alphabetical order
Slide 5.6
© The McGraw-Hill Companies, 2007
Typical File of Input Transactions
Figure 5.1
Slide 5.7
© The McGraw-Hill Companies, 2007
Decompose Process
No further refinement is possible Figure 5.2
Slide 5.8
© The McGraw-Hill Companies, 2007
First Refinement
Figure 5.3
Slide 5.9
© The McGraw-Hill Companies, 2007
Stepwise Refinement Case Study (contd)
AssumptionWe can produce a record when PROCESS requires it
Separate INPUT and OUTPUT, concentrate onPROCESS
Slide 5.10
© The McGraw-Hill Companies, 2007
Stepwise Refinement Case Study (contd)
What is this PROCESS? Example:
Figure 5.4
Slide 5.11
© The McGraw-Hill Companies, 2007
Stepwise Refinement Case Study (contd)
More formally:
Figure 5.5
Slide 5.12
© The McGraw-Hill Companies, 2007
Second Refinement
Figure 5.6
Slide 5.13
© The McGraw-Hill Companies, 2007
Third Refinement
This designhas a majorfault
Figure 5.7
Slide 5.14
© The McGraw-Hill Companies, 2007
Stepwise Refinement Case Study (contd)
The third refinement is WRONG“Modify JONES” followed by “Delete JONES” is
incorrectly handled
Slide 5.15
© The McGraw-Hill Companies, 2007
Stepwise Refinement Case Study (contd)
After the third refinement has been correctedDetails like opening and closing files have been ignored
up to nowFix these after the logic of the design is completeThe stage at which an item is handled is vital
Opening and closing files isIgnored in early steps, butEssential later
Slide 5.16
© The McGraw-Hill Companies, 2007
Appraisal of Stepwise Refinement
A basic principle used inEvery workflowEvery representation
The power of stepwise refinementThe software engineer can concentrate on the relevant
aspects
WarningMiller’s Law is a fundamental restriction on the mental
powers of human beings
Slide 5.17
© The McGraw-Hill Companies, 2007
5.2 Cost–Benefit Analysis
Compare costs and future benefitsEstimate costsEstimate benefitsState all assumptions explicitly
Slide 5.18
© The McGraw-Hill Companies, 2007
Cost–Benefit Analysis (contd)
Example: Computerizing KCEC
Figure 5.8
Slide 5.19
© The McGraw-Hill Companies, 2007
Cost–Benefit Analysis (contd)
Tangible costs/benefits are easy to measure
Make assumptions to estimate intangiblecosts/benefitsImproving the assumptions will improve the estimates
Slide 5.20
© The McGraw-Hill Companies, 2007
5.3 Software Metrics
To detect problems early, it is essential tomeasure
Examples:LOC per monthDefects per 1000 lines of code
Slide 5.21
© The McGraw-Hill Companies, 2007
Different Types of Metrics
Product metricsExamples:
Size of product Reliability of product
Process metricsExample:
Efficiency of fault detection during development
Metrics specific to a given workflowExample:
Number of defects detected per hour in specification reviews
Slide 5.22
© The McGraw-Hill Companies, 2007
The Five Basic Metrics
SizeIn lines of code, or better
CostIn dollars
DurationIn months
EffortIn person months
QualityNumber of faults detected
Slide 5.23
© The McGraw-Hill Companies, 2007
5.4 CASE (Computer-Aided Software Engineering)
Scope of CASECASE can support the entire life-cycle
The computer assists with drudge workIt manages all the details
Slide 5.24
© The McGraw-Hill Companies, 2007
5.5 Taxonomy of CASE
UpperCASE (front-end tool)versus
LowerCASE (back-end tool)
Slide 5.25
© The McGraw-Hill Companies, 2007
Some Useful Tools
Data dictionaryComputerized list of all data defined within the product
Consistency checker
Report generator, screen generator
Slide 5.26
© The McGraw-Hill Companies, 2007
Taxonomy of CASE (contd)
(a) Tool versus (b) workbench versus (c)environment
Figure 5.9
Slide 5.27
© The McGraw-Hill Companies, 2007
5.6 Scope of CASE
Programmers need to have:Accurate, up-to-date versions of all project documentsOnline help information regarding the
Operating system Editor Programming language
Online programming standardsOnline manuals
Editor manuals Programming manuals
Slide 5.28
© The McGraw-Hill Companies, 2007
Scope of CASE (contd)
Programmers need to have:E-mail systemsSpreadsheetsWord processorsStructure editorsPretty printersOnline interface checkers
Slide 5.29
© The McGraw-Hill Companies, 2007
Online Interface Checker
A structure editor must support online interfacecheckingThe editor must know the name of every code artifact
Interface checking is an important part ofprogramming-in-the-large
Slide 5.30
© The McGraw-Hill Companies, 2007
Online Interface Checker (contd)
ExampleThe user enters the call
average = dataArray.computeAverage (numberOfValues);
The editor immediately respondsMethod computeAverage not known
The programmer is given two choicesCorrect the name of the method to computeMeanDeclare new procedure computeAverage and specify
its parameters
This enables full interface checking
Slide 5.31
© The McGraw-Hill Companies, 2007
Online Interface Checker (contd)
ExampleDeclaration of q isvoid q (float floatVar, int intVar, String s1, String s2);
Call (invocation) isq (intVar, floatVar, s1, s2);
The online interface checker detects the fault
Help facilityOnline information for the parameters of method qBetter: Editor generates a template for the call
The template shows type of each parameter The programmer replaces formal by actual parameters
Slide 5.32
© The McGraw-Hill Companies, 2007
Online Interface Checker (contd)
AdvantagesThere is no need for different tools with different
interfacesHard-to-detect faults are immediately flagged for
correction Wrong number of parameters Parameters of the wrong type
Essential when software is produced by a teamIf one programmer changes an interface specification,
all components calling that changed artifact must bedisabled
Slide 5.33
© The McGraw-Hill Companies, 2007
Online Interface Checker (contd)
Even when a structure editor incorporates anonline interface checker, a problem remainsThe programmer still has to exit from the editor to
invoke the compiler (to generate code)Then, the linker must be called to link the productThe programmer must adjust to the JCL, compiler, and
linker output
Solution: Incorporate an operating system front-end into the structure editor
Slide 5.34
© The McGraw-Hill Companies, 2007
Operating System Front-End in Editor
Single command go or runUse of the mouse to choose
An icon, or A menu selection
This one command causes the editor to invoke thecompiler, linker, loader, and execute the product
Slide 5.35
© The McGraw-Hill Companies, 2007
Source Level Debugger
Example:Product executes terminates abruptly and prints
Overflow at 4B06
orCore dumped
orSegmentation fault
Slide 5.36
© The McGraw-Hill Companies, 2007
Source Level Debugger (contd)
The programmer works in a high-level language,but must examineMachine-code core dumpsAssembler listingsLinker listingsSimilar low-level documentation
This destroys the advantage of programming ina high-level language
We needAn interactive source level debugger (like dbx)
Slide 5.37
© The McGraw-Hill Companies, 2007
Source Level Debugger (contd)
Output from a typical source-level debugger
Figure 5.10
Slide 5.38
© The McGraw-Hill Companies, 2007
Programming Workbench
Structure editor withOnline interface checking capabilitiesOperating system front-endOnline documentationSource level debugger
This constitutes a simple programmingenvironment
Slide 5.39
© The McGraw-Hill Companies, 2007
Programming Workbench (contd)
This is by no means newAll the above features are supported by FLOW (1980)The technology has been in place for years
Surprisingly, some programmers still implementcode the old-fashioned way
Slide 5.40
© The McGraw-Hill Companies, 2007
5.7 Software Versions
During maintenance, at all times there are atleast two versions of the product:The old version, andThe new version
There are two types of versions: revisions andvariations
Slide 5.41
© The McGraw-Hill Companies, 2007
5.7.1 Revisions
RevisionA version to fix a fault in the artifactWe cannot throw away an incorrect version
The new version may be no better Some sites may not install the new version
Perfective and adaptive maintenance also result inrevisions
Slide 5.42
© The McGraw-Hill Companies, 2007
5.7.2 Variations
A variation is a version for a different operatingsystem–hardware
Variations are designed to coexist in parallel
Figure 5.11
Slide 5.43
© The McGraw-Hill Companies, 2007
5.8 Configuration Control
Every code artifactexists in three formsSource codeCompiled codeExecutable load image
ConfigurationA version of each
artifact from which agiven version of aproduct is built
Figure 5.12
Slide 5.44
© The McGraw-Hill Companies, 2007
Version-Control Tool
Essential for programming-in-the-manyA first step toward configuration management
A version-control tool must handleUpdatesParallel versions
Slide 5.45
© The McGraw-Hill Companies, 2007
Version-Control Tool (contd)
Notation for file name, variation, and version
Figure 5.13
Slide 5.46
© The McGraw-Hill Companies, 2007
Version-Control Tool (contd)
Problem of multiple variationsDeltas
Version control is not enough — maintenanceissues
Slide 5.47
© The McGraw-Hill Companies, 2007
5.8.1 Configuration Control during Postdelivery Maintenance
Two programmers are working on the sameartifact mDual/16
The changes of the first programmer are containedin mDual/17
The changes of the second programmer arecontained in mDual/18The changes of the first programmer are lost
Slide 5.48
© The McGraw-Hill Companies, 2007
5.8.2 Baselines
The maintenance manager must set upBaselinesPrivate workspaces
When an artifact is to be changed, the currentversion is frozenThereafter, it can never be changed
Slide 5.49
© The McGraw-Hill Companies, 2007
Baselines (contd)
Both programmers make their changes to mDual/16
The first programmerFreezes mDual/16 and makes changes to itThe resulting revision is mDual/17After testing, mDual/17 becomes the new baseline
The second programmerFreezes mDual/17 and makes changes to itThe resulting revision is mDual/18After testing, mDual/18 becomes the new baseline
Slide 5.50
© The McGraw-Hill Companies, 2007
5.8.3 Configuration Control during Development
While an artifact is being codedThe programmer performs informal testing
Then the artifact is given to the SQA group formethodical testingChanges from now on can impact the product
An artifact must be subject to configuration controlfrom the time it is passed by SQA
Slide 5.51
© The McGraw-Hill Companies, 2007
Configuration-Control Tools
UNIX version-control toolssccsrcscvs
Popular commercial configuration-control toolsPVCSSourceSafe
Open-source configuration-control toolcvs
Slide 5.52
© The McGraw-Hill Companies, 2007
5.9 Build Tools
ExampleUNIX make
A build tool compares the date and time stamp onSource code, compiled codeIt calls the appropriate compiler only if necessary
The tool then compares the date and time stamp onCompiled code, executable load imageIt calls the linker only if necessary
Slide 5.53
© The McGraw-Hill Companies, 2007
5.10 Productivity Gains with CASE Tools
Survey of 45 companies in 10 industries (1992)Half information systemsQuarter scientific softwareQuarter real-time aerospace software
ResultsAbout 10% annual productivity gainsCost: $125,000 per seat
Slide 5.54
© The McGraw-Hill Companies, 2007
Productivity Gains with CASE Tools (contd)
Justifications for CASEFaster developmentFewer faultsEasier maintenanceImproved morale
Slide 5.55
© The McGraw-Hill Companies, 2007
5.10 Productivity Gains with CASE Tools
Newer results on fifteen Fortune 500companies (1997)
It is vital to haveTraining, andA software process
Results confirm that CASE environmentsshould be used at CMM level 3 or higher
“A fool with a tool is still a fool”
Slide 5.56
© The McGraw-Hill Companies, 2007
Summary of Tools in Chapter 5
Figure 5.14