dr.s.sridhar, ph.d., raci(paris, nice), rmr(usa), rzfm(germany) lmcsi, lmiste, rieeeproc., rietcom...

Dr.S.Sridhar, Ph.D., RACI(Paris, NICE), RMR(USA),

RZFM(Germany)LMCSI, LMISTE, RIEEEProc., RIETComPRINCIPAL, CREC, TIRUPATHI (AP)

What is What is Software?Software?

Software is a set of items or objects that form a “configuration” that includes • programs • documents • data ...

What is What is Software?Software?

software is engineeredsoftware is engineered software doesn’t wear outsoftware doesn’t wear out software is complexsoftware is complex software is a software is a

‘differentiator’‘differentiator’ software is like an ‘aging software is like an ‘aging

factory’factory’

Wear vs. Wear vs. DeteriorationDeterioration

idealized curve

change

actual curve

Failurerate

Time

increased failurerate due to side effects

The Cost of The Cost of ChangeChange

Definition Development After release

1x

1.5-6x

60-100x

Software Software ApplicationsApplications system softwaresystem software

real-time softwarereal-time software business softwarebusiness software engineering/scientific engineering/scientific

softwaresoftware embedded softwareembedded software PC softwarePC software AI softwareAI software WebApps (Web applications)WebApps (Web applications)

Software Poses Software Poses ChallengesChallenges

How do we ensure the quality of the software that we produce? How do we meet growing demand and still maintain budget control? How do we upgrade an aging "software plant?" How do we avoid disastrous time delays? How do we successfully institute new software technologies?

Chapter 2Chapter 2The The

ProcessProcess

Software Engineering

A Layered A Layered TechnologyTechnology

Software Engineering

a “quality” focusa “quality” focus

process modelprocess model

methodsmethods

toolstools

A Common Process A Common Process FrameworkFramework

Common process frameworkCommon process framework

Framework activitiesFramework activities

work taskswork tasks

work productswork products

milestones & deliverablesmilestones & deliverables

QA checkpointsQA checkpoints

Umbrella ActivitiesUmbrella Activities

Umbrella Umbrella ActivitiesActivities

Software project managementSoftware project management Formal technical reviewsFormal technical reviews Software quality assuranceSoftware quality assurance Software configuration Software configuration

managementmanagement Document preparation and Document preparation and

productionproduction Reusability managementReusability management MeasurementMeasurement Risk managementRisk management

Process as Problem Process as Problem SolvingSolving

statusquo

problemdefinition

technicaldevelopment

solutionintegration

The Process The Process Model:Model:

AdaptabilityAdaptability the framework activities will the framework activities will alwaysalways be applied on be applied on everyevery project ... BUTproject ... BUT

the tasks (and degree of rigor) for the tasks (and degree of rigor) for each activity will vary based on:each activity will vary based on:

the type of project (an “entry point” to the type of project (an “entry point” to the model)the model)

characteristics of the projectcharacteristics of the project common sense judgment; concurrence of common sense judgment; concurrence of

the project teamthe project team

The Primary The Primary Goal:Goal:

High QualityHigh QualityRemember:Remember:

High quality = project timelinessHigh quality = project timeliness

Why?Why?

Less rework!Less rework!

The Linear The Linear ModelModel

analysis design code test

System/informationengineering

Iterative Iterative ModelsModels

listento

customerbuild/revise

mock-up

customertest-drivesmock-up

businessmodeling

datamodeling

processmodeling

applicationgeneration

testing&

turnover

businessmodeling

datamodeling

processmodeling


testing&

turnover

businessmodeling

datamodeling

processmodeling


testing&

turnover

team #1

team #2team #3

60 - 90 days

Prototyping

RAD

The Incremental The Incremental ModelModel


System/informationengineering




increment 2

increment 3

increment 4

increment 1

delivery of1st increment

delivery of2nd increment

delivery of3rd increment

delivery of4th increment

calendar time

An Evolutionary (Spiral) An Evolutionary (Spiral) ModelModel

CustomerCommunication

Planning

Construction & ReleaseCustomerEvaluation

Engineering

Risk Analysis

Still Other Process Still Other Process ModelsModels

Component assembly modelComponent assembly model—the process to —the process to apply when reuse is a development objectiveapply when reuse is a development objective

Concurrent process modelConcurrent process model—recognizes that —recognizes that different part of the project will be at different part of the project will be at different places in the processdifferent places in the process

Formal methodsFormal methods—the process to apply when a —the process to apply when a mathematical specification is to be developedmathematical specification is to be developed

Cleanroom software engineeringCleanroom software engineering—emphasizes —emphasizes error detection error detection beforebefore testing testing

Chapter 13 Chapter 13 Design Concepts and Design Concepts and

PrinciplesPrinciples

Analysis to Analysis to DesignDesign

Entity-Relationship

Diagram

Data FlowDiagram

State-TransitionDiagram

Data Dictionary

Process Specification (PSPEC)

Control Specification (CSPEC)

Data Object Description

THE ANALYSIS MODEL

proceduraldesign

interfacedesign

architecturaldesign

datadesign

THE DESIGN MODEL

Where Do We Where Do We Begin?Begin?

Spec

PrototypePrototype

DesignDesign

modeling

Design Design PrinciplesPrinciples The design process should not suffer from ‘tunnel vision.’ The design process should not suffer from ‘tunnel vision.’

The design should be traceable to the analysis model. The design should be traceable to the analysis model. The design should not reinvent the wheel. The design should not reinvent the wheel. The design should “minimize the intellectual distance” [DAV95] between The design should “minimize the intellectual distance” [DAV95] between

the software and the problem as it exists in the real world. the software and the problem as it exists in the real world. The design should exhibit uniformity and integration. The design should exhibit uniformity and integration. The design should be structured to accommodate change. The design should be structured to accommodate change. The design should be structured to degrade gently, even when aberrant The design should be structured to degrade gently, even when aberrant

data, events, or operating conditions are encountered. data, events, or operating conditions are encountered. Design is not coding, coding is not design. Design is not coding, coding is not design. The design should be assessed for quality as it is being created, not after The design should be assessed for quality as it is being created, not after

the fact. the fact. The design should be reviewed to minimize conceptual (semantic) errors.The design should be reviewed to minimize conceptual (semantic) errors.

From Davis [DAV95]

Fundamental Fundamental ConceptsConcepts abstractionabstraction—data, procedure, control—data, procedure, control

refinementrefinement—elaboration of detail for all —elaboration of detail for all abstractionsabstractions

modularitymodularity—compartmentalization of data and —compartmentalization of data and functionfunction

architecturearchitecture—overall structure of the software—overall structure of the software Structural propertiesStructural properties Extra-structural propertiesExtra-structural properties Styles and patternsStyles and patterns

procedureprocedure—the algorithms that achieve function—the algorithms that achieve function hidinghiding—controlled interfaces—controlled interfaces

Data Data AbstractionAbstraction

door

implemented as a data structure

manufacturermodel numbertypeswing directioninsertslights type numberweightopening mechanism

Procedural Procedural AbstractionAbstraction

open

implemented with a "knowledge" of the object that is associated with enter

details of enter algorithm

Stepwise Stepwise RefinementRefinementopen

walk to door;reach for knob;

open door;

walk through;close door.

repeat until door opensturn knob clockwise;if knob doesn't turn, then take key out; find correct key; insert in lock;endifpull/push doormove out of way;end repeat

Modular Modular DesignDesigneasier to build, easier to change, easier to fix ...

Modularity: Modularity: Trade-offsTrade-offsWhat is the "right" number of modules What is the "right" number of modules

for a specific software design?for a specific software design?

optimal numberoptimal number of modulesof modules

cost ofcost of softwaresoftware

number of modulesnumber of modules

modulemoduleintegrationintegration

costcost

module development cost module development cost

Sizing Modules: Two Sizing Modules: Two ViewsViews

MODULE

What's inside??

How big is it??

Functional Functional IndependenceIndependence

COHESION - the degree to which a module performs one and only one function. COUPLING - the degree to which a module is "connected" to other modules in the system.

ArchitectuArchitecturere““The overall structure of the software and the The overall structure of the software and the

ways in which that structure provides ways in which that structure provides conceptual integrity for a system.” [SHA95a]conceptual integrity for a system.” [SHA95a]

Structural properties.Structural properties. This aspect of the architectural design This aspect of the architectural design representation defines the components of a system (e.g., modules, representation defines the components of a system (e.g., modules, objects, filters) and the manner in which those components are packaged objects, filters) and the manner in which those components are packaged and interact with one another. For example, objects are packaged to and interact with one another. For example, objects are packaged to encapsulate both data and the processing that manipulates the data and encapsulate both data and the processing that manipulates the data and interact via the invocation of methods .interact via the invocation of methods .Extra-functional properties.Extra-functional properties. The architectural design description should The architectural design description should address how the design architecture achieves requirements for address how the design architecture achieves requirements for performance, capacity, reliability, security, adaptability, and other system performance, capacity, reliability, security, adaptability, and other system characteristics.characteristics.Families of related systems.Families of related systems. The architectural design should draw upon The architectural design should draw upon repeatable patterns that are commonly encountered in the design of repeatable patterns that are commonly encountered in the design of families of similar systems. In essence, the design should have the ability families of similar systems. In essence, the design should have the ability

to reuse architectural building blocks.to reuse architectural building blocks.

Information HidingInformation Hiding

modulemodulecontrolledcontrolledinterfaceinterface

"secret""secret"

• • algorithmalgorithm

• • data structuredata structure

• • details of external interfacedetails of external interface

• • resource allocation policyresource allocation policy

clientsclients

a specific design decisiona specific design decision

Why Information Why Information Hiding?Hiding?

reduces the likelihood of “side reduces the likelihood of “side effects”effects”

limits the global impact of local limits the global impact of local design decisionsdesign decisions

emphasizes communication emphasizes communication through controlled interfacesthrough controlled interfaces

discourages the use of global datadiscourages the use of global data leads to encapsulation—an leads to encapsulation—an

attribute of high quality designattribute of high quality design results in higher quality softwareresults in higher quality software

Chapter 15Chapter 15User Interface User Interface

DesignDesign

Interface DesignInterface Design

Easy to use?Easy to use?

Easy to understand?Easy to understand?

Easy to learn?Easy to learn?

Interface DesignInterface Design

lack of consistencylack of consistencytoo much memorizationtoo much memorizationno guidance / helpno guidance / helpno context sensitivityno context sensitivitypoor responsepoor responseArcane/unfriendlyArcane/unfriendly

Typical Design ErrorsTypical Design Errors

Golden Golden RulesRules

Place the user in controlPlace the user in control Reduce the user’s memory Reduce the user’s memory

loadload Make the interface consistentMake the interface consistent

Place the User in Place the User in ControlControl

Define interaction modes in a way that does not force a user Define interaction modes in a way that does not force a user into unnecessary or undesired actions. into unnecessary or undesired actions.

Provide for flexible interaction. Provide for flexible interaction.

Allow user interaction to be interruptible and undoable. Allow user interaction to be interruptible and undoable.

Streamline interaction as skill levels advance and allow the Streamline interaction as skill levels advance and allow the interaction to be customized. interaction to be customized.

Hide technical internals from the casual user. Hide technical internals from the casual user.

Design for direct interaction with objects that appear on the Design for direct interaction with objects that appear on the screen.screen.

Reduce the User’s Memory Reduce the User’s Memory LoadLoad

Reduce demand on short-term memory. Reduce demand on short-term memory.

Establish meaningful defaults. Establish meaningful defaults.

Define shortcuts that are intuitive. Define shortcuts that are intuitive.

The visual layout of the interface should be based on a The visual layout of the interface should be based on a real world metaphor. real world metaphor.

Disclose information in a progressive fashion.Disclose information in a progressive fashion.

Make the Interface Make the Interface ConsistentConsistent

Allow the user to put the current task into a meaningful Allow the user to put the current task into a meaningful context. context.

Maintain consistency across a family of applications. Maintain consistency across a family of applications.

If past interactive models have created user If past interactive models have created user expectations, do not make changes unless there is a expectations, do not make changes unless there is a compelling reason to do so.compelling reason to do so.

User Interface Design User Interface Design ModelsModels

System perceptionSystem perception — the user’s — the user’s mental image of what the interface ismental image of what the interface is

User modelUser model — a profile of all end users — a profile of all end users of the systemof the system

System imageSystem image — the “presentation” of — the “presentation” of the system projected by the complete the system projected by the complete interfaceinterface

Design modelDesign model — data, architectural, — data, architectural, interface and procedural interface and procedural representations of the softwarerepresentations of the software

User Interface Design User Interface Design ProcessProcess

Task Analysis and Task Analysis and ModelingModeling

All human tasks required to do the job All human tasks required to do the job (of the interface) are defined and (of the interface) are defined and classifiedclassified

Objects (to be manipulated) and Objects (to be manipulated) and actions (functions applied to objects) actions (functions applied to objects) are identified for each taskare identified for each task

Tasks are refined iteratively until the Tasks are refined iteratively until the job is completely definedjob is completely defined

Interface Design Interface Design ActivitiesActivities

1. Establish the goals and intentions for each task.

2. Map each goal/intention to a sequence of specific actions.

3. Specify the action sequence of tasks and subtasks, also called a user scenario, as it will be executed at the interface level.

4. Indicate the state of the system, i.e., what does the interface look like at the time that a user scenario is performed?

5. Define control mechanisms, i.e., the objects and actions available to the user to alter the system state.

6. Show how control mechanisms affect the state of the system.

7. Indicate how the user interprets the state of the system from information provided through the interface.

Design Evaluation Design Evaluation CycleCyclepreliminary

design

buildprototype #1

interface

evaluationis studied by

designer

designmodifications

are made

buildprototype # n

interface

userevaluate'sinterface

Interface designis complete

Chapter 17Chapter 17Software Testing Software Testing

TechniquesTechniques

Software Software TestingTesting

Testing is the process of exercising aTesting is the process of exercising aprogram with the specific intent of findingprogram with the specific intent of findingerrors prior to delivery to the end user.errors prior to delivery to the end user.

TestabilTestabilityity OperabilityOperability—it operates cleanly—it operates cleanly

ObservabilityObservability—the results of each test —the results of each test case are readily observedcase are readily observed

ControlabilityControlability—the degree to which —the degree to which testing can be automated and optimizedtesting can be automated and optimized

DecomposabilityDecomposability—testing can be targeted—testing can be targeted SimplicitySimplicity—reduce complex architecture —reduce complex architecture

and logic to simplify testsand logic to simplify tests StabilityStability—few changes are requested —few changes are requested

during testingduring testing UnderstandabilityUnderstandability—of the design—of the design

What Testing ShowsWhat Testing Shows

errorserrors

requirements conformancerequirements conformance

performanceperformance

an indicationan indicationof qualityof quality

Who Tests the Who Tests the Software?Software?

developerdeveloper independent testerindependent tester

Understands the system Understands the system

but, will test "gently"but, will test "gently"

and, is driven by "delivery"and, is driven by "delivery"

Must learn about the system,Must learn about the system,but, will attempt to break itbut, will attempt to break itand, is driven by qualityand, is driven by quality

Exhaustive TestingExhaustive Testing

loop < 20 Xloop < 20 X

There are 10 possible paths! If we execute oneThere are 10 possible paths! If we execute onetest per millisecond, it would take 3,170 years totest per millisecond, it would take 3,170 years totest this program!!test this program!!

1414

Selective TestingSelective Testing

loop < 20 Xloop < 20 X

Selected pathSelected path

Software TestingSoftware Testing

Methods

Strategies

white-boxmethods

black-box methods

Test Case Test Case DesignDesign

"Bugs lurk in corners "Bugs lurk in corners and congregate at and congregate at boundaries ..."boundaries ..."

Boris BeizerBoris Beizer

OBJECTIVEOBJECTIVE

CRITERIACRITERIA

CONSTRAINTCONSTRAINT

to uncover errorsto uncover errors

in a complete mannerin a complete manner

with a minimum of effort and timewith a minimum of effort and time

White-Box White-Box TestingTesting

... our goal is to ensure that all ... our goal is to ensure that all statements and conditions have statements and conditions have been executed at least once ...been executed at least once ...

Why Why Cover?Cover?

logic errors and incorrect assumptions logic errors and incorrect assumptions are inversely proportional to a path's are inversely proportional to a path's execution probabilityexecution probability

we often we often believebelieve that a path is not that a path is not likely to be executed; in fact, reality is likely to be executed; in fact, reality is often counter intuitiveoften counter intuitive

typographical errors are random; it's typographical errors are random; it's likely that untested paths will contain likely that untested paths will contain some some

Basis Path Basis Path TestingTesting

First, we compute the cyclomatic complexity:

number of simple decisions + 1

or

number of enclosed areas + 1

In this case, V(G) = 4

Cyclomatic Cyclomatic ComplexityComplexityA number of industry studies have indicated A number of industry studies have indicated

that the higher V(G), the higher the probability that the higher V(G), the higher the probability or errors.or errors.

V(G)V(G)

modulesmodules

modules in this range are modules in this range are more error pronemore error prone

Basis Path Basis Path TestingTestingNext, we derive the Next, we derive the

independent paths:independent paths:

Since V(G) = 4,Since V(G) = 4,there are four pathsthere are four paths

Path 1: 1,2,3,6,7,8Path 1: 1,2,3,6,7,8Path 2: 1,2,3,5,7,8Path 2: 1,2,3,5,7,8Path 3: 1,2,4,7,8Path 3: 1,2,4,7,8Path 4: 1,2,4,7,2,4,...7,8Path 4: 1,2,4,7,2,4,...7,8

Finally, we derive testFinally, we derive testcases to exercise these cases to exercise these paths.paths.

11

22

3344

55 66

77

88

Basis Path Testing Basis Path Testing NotesNotesyou don't need a flow chart, you don't need a flow chart, but the picture will help when but the picture will help when you trace program pathsyou trace program paths

count each simple logical test, count each simple logical test, compound tests count as 2 or compound tests count as 2 or moremore

basis path testing should be basis path testing should be applied to critical modulesapplied to critical modules

Loop TestingLoop Testing

Nested Nested LoopsLoops

Concatenated Concatenated LoopsLoops UnstructuredUnstructured

LoopsLoops

Simple Simple looploop

Loop Testing: Simple Loop Testing: Simple LoopsLoops

Minimum conditions—Simple LoopsMinimum conditions—Simple Loops

1. skip the loop entirely1. skip the loop entirely

2. only one pass through the loop2. only one pass through the loop3. two passes through the loop3. two passes through the loop4. m passes through the loop m < n4. m passes through the loop m < n5. (n-1), n, and (n+1) passes through 5. (n-1), n, and (n+1) passes through the loopthe loop

where n is the maximum number where n is the maximum number of allowable passesof allowable passes

Loop Testing: Nested Loop Testing: Nested LoopsLoops

Start at the innermost loop. Set all outer loops to their Start at the innermost loop. Set all outer loops to their minimum iteration parameter values.minimum iteration parameter values.

Test the min+1, typical, max-1 and max for the Test the min+1, typical, max-1 and max for the innermost loop, while holding the outer loops at their innermost loop, while holding the outer loops at their minimum values.minimum values.Move out one loop and set it up as in step 2, holding all Move out one loop and set it up as in step 2, holding all other loops at typical values. Continue this step until other loops at typical values. Continue this step until the outermost loop has been tested.the outermost loop has been tested.

If the loops are independent of one another If the loops are independent of one another then treat each as a simple loopthen treat each as a simple loop else* treat as nested loopselse* treat as nested loopsendif* endif*

for example, the final loop counter value of loop 1 is for example, the final loop counter value of loop 1 is used to initialize loop 2.used to initialize loop 2.

Nested LoopsNested Loops

Concatenated LoopsConcatenated Loops

Black-Box TestingBlack-Box Testing

requirementsrequirements

eventseventsinputinput

outputoutput

Equivalence Equivalence PartitioningPartitioning

useruserqueriesqueries mousemouse

pickspicks

outputoutputformatsformats

promptsprompts

FKFKinputinput

datadata

Sample Equivalence Sample Equivalence ClassesClasses

user supplied commandsuser supplied commandsresponses to system promptsresponses to system promptsfile namesfile namescomputational datacomputational data physical parameters physical parameters bounding valuesbounding values initiation valuesinitiation valuesoutput data formattingoutput data formattingresponses to error messagesresponses to error messagesgraphical data (e.g., mouse picks)graphical data (e.g., mouse picks)

data outside bounds of the program data outside bounds of the program physically impossible dataphysically impossible dataproper value supplied in wrong placeproper value supplied in wrong place

Valid dataValid data

Invalid dataInvalid data

Boundary Value Boundary Value AnalysisAnalysis

useruserqueriesqueries mousemouse

pickspicks

outputoutputformatsformats

promptsprompts

FKFKinputinput

datadata

outputoutputdomaindomaininput domaininput domain

Other Black Box TechniquesOther Black Box Techniques

error guessing methodserror guessing methods decision table techniquesdecision table techniques cause effect graphingcause effect graphing

Chapter 18Chapter 18Software Testing Software Testing

StrategiesStrategies

Testing StrategyTesting Strategy

unit testunit test integrationintegrationtesttest

validationvalidationtesttest

systemsystemtesttest

Unit TestingUnit Testing

modulemoduleto beto betestedtested

test casestest cases

resultsresults

softwaresoftwareengineerengineer

Unit TestingUnit Testing

interface interface local data structureslocal data structures

boundary conditionsboundary conditionsindependent pathsindependent pathserror handling pathserror handling paths

modulemoduleto beto betestedtested


Unit Test Unit Test EnvironmentEnvironment

ModuleModule

stubstub stubstub

driverdriver

RESULTSRESULTS

interface interface

local data structureslocal data structures

boundary conditionsboundary conditions

independent pathsindependent paths

error handling pathserror handling paths


Integration Testing StrategiesIntegration Testing Strategies

Options:Options:•• the “big bang” approachthe “big bang” approach•• an incremental construction strategyan incremental construction strategy

Top Down IntegrationTop Down Integration

top module is tested with top module is tested with stubsstubs

stubs are replaced one at stubs are replaced one at a time, "depth first"a time, "depth first"

as new modules are integrated, as new modules are integrated, some subset of tests is re-runsome subset of tests is re-run

AA

BB

CC

DD EE

FF GG

Bottom-Up IntegrationBottom-Up Integration

drivers are replaced one at a drivers are replaced one at a time, "depth first"time, "depth first"

worker modules are grouped into worker modules are grouped into builds and integratedbuilds and integrated

AA

BB

CC

DD EE

FF GG

clustercluster

Sandwich TestingSandwich Testing

Top modules areTop modules aretested with stubstested with stubs

Worker modules are grouped into Worker modules are grouped into builds and integratedbuilds and integrated

AA

BB

CC

DD EE

FF GG

clustercluster

High Order TestingHigh Order Testing

validation testvalidation test

system testsystem test

alpha and beta testalpha and beta test

other specialized testingother specialized testing

Debugging: Debugging: A Diagnostic A Diagnostic

ProcessProcess

The Debugging The Debugging ProcessProcess


resultsresults

DebuggingDebugging

suspectedsuspectedcausescauses

identifiedidentifiedcausescauses

correctionscorrections

regressionregressionteststests

new testnew testcasescases

Debugging EffortDebugging Effort

time requiredtime requiredto diagnose theto diagnose thesymptom andsymptom anddetermine thedetermine thecausecause

time requiredtime requiredto correct the errorto correct the errorand conductand conductregression testsregression tests

Symptoms & CausesSymptoms & Causes

symptomsymptomcausecause

symptom and cause may be symptom and cause may be geographically separated geographically separated

symptom may disappear when symptom may disappear when another problem is fixedanother problem is fixed

cause may be due to a cause may be due to a combination of non-errors combination of non-errors

cause may be due to a system cause may be due to a system or compiler erroror compiler error

cause may be due to cause may be due to assumptions that everyone assumptions that everyone believesbelieves

symptom may be intermittentsymptom may be intermittent

Consequences of BugsConsequences of Bugs

damagedamage

mildmild annoyingannoying

disturbingdisturbingseriousserious

extremeextremecatastrophiccatastrophic

infectiousinfectious

Bug TypeBug Type

Bug Categories:Bug Categories: function-related bugs, function-related bugs, system-related bugs, data bugs, coding bugs, system-related bugs, data bugs, coding bugs, design bugs, documentation bugs, standards design bugs, documentation bugs, standards violations, etc.violations, etc.

Debugging Debugging TechniquesTechniques

brute force / testingbrute force / testing

backtrackingbacktracking

inductioninduction

deductiondeduction

Debugging: Final Debugging: Final ThoughtsThoughts

Don't run off half-cocked, Don't run off half-cocked, thinkthink about the about the symptom you're seeing.symptom you're seeing.

Use toolsUse tools (e.g., dynamic debugger) to gain (e.g., dynamic debugger) to gain more insight.more insight.

If at an impasse, If at an impasse, get helpget help from someone else.from someone else.

Be absolutely sure to Be absolutely sure to conduct regression testsconduct regression tests when you do "fix" the bug.when you do "fix" the bug.

1.1.

2.2.

3.3.

4.4.

Chapter 20Chapter 20Object-Oriented Object-Oriented

ConceptsConceptsand Principlesand Principles

The OO Process The OO Process ModelModel

CustomerCommunication

Planning

Construction & ReleaseCustomerEvaluation

Engineering,

Risk Analysis look-upclasses

in library

extractclasses

if available

engineerclasses

if unavailable

constructnth iterationof system

put newclasses

in library

OO analysisOO designOO programmingOO testing

identifycandidateclasses

The OO The OO MindsetMindset

problem domainproblem domain

objectsobjects

Key Key ConceptsConcepts

• classes and class hierarchiesclasses and class hierarchies– instancesinstances– inheritanceinheritance– abstraction and hidingabstraction and hiding

• objectsobjects– attributesattributes– methodsmethods– encapsulationencapsulation– polymorphismpolymorphism

• messagesmessages

ClasseClassess• object-oriented thinking begins with object-oriented thinking begins with

the definition of a class often defined the definition of a class often defined as:as:

– templatetemplate– generalized descriptiongeneralized description– patternpattern– “ “blueprint” ... describing a collection of blueprint” ... describing a collection of

similar itemssimilar items

• a metaclass (also called a superclass) a metaclass (also called a superclass) is a collection of classesis a collection of classes

• once a class of items is defined, a once a class of items is defined, a specific instance of the class can be specific instance of the class can be defined defined

Building a Building a ClassClass

class name

attributes:

operations:

attributes:

operations

What is a What is a Class?Class?

external entities

things

occurrences roles

organizational units

places

structures

class name

attributes:

operations:

Encapsulation/Encapsulation/HidingHidingThe object encapsulates

both data and the logicalprocedures required tomanipulate the data

Achieves “information hiding”

method # 1

data

method # 2

method # 4

method # 5

method # 6

Class Class HierarchyHierarchy

chairtable desk "chable"

instances of chair

furniture (superclass)

subclasses of thefurniture superclass

MethodsMethods(a.k.a. Operations, (a.k.a. Operations,

Services)Services)An executable procedure that is encapsulated in a class and is designed to operate on one or more data attributes that are defined as part of the class.A method is invoked via message passing.

MessagMessagesessender object

attributes:

operations:

receiver object

attributes:

operations:

message: [receiver, operation, parameters]

message: [sender, return value(s)]


AnalysisAnalysis

Domain Domain AnalysisAnalysis

DOMAINANALYSIS

SOURCES OFDOMAIN

KNOWLEDGE

DOMAINANALYSIS

MODEL

techncial literature

existing applications

customer surveys

expert advice

current/future requirements

class taxononmies

reuse standards

functional models

domain languages

OOA- A Generic OOA- A Generic ViewView

• define use cases• extract candidate classes• establish basic class relationships• define a class hierarchy• identify attributes for each class• specify methods that service the attributes• indicate how classes/objects are related• build a behavioral model • iterate on the first five steps

Use Use CasesCases

a scenario that describes a “thread of a scenario that describes a “thread of usage” for a systemusage” for a system

actorsactors represent roles people or represent roles people or devices play as the system functionsdevices play as the system functions

usersusers can play a number of different can play a number of different roles for a given scenarioroles for a given scenario

Developing a Use Developing a Use CaseCase What are the main tasks or functions that What are the main tasks or functions that

are performed by the actor?are performed by the actor? What system information will the the actor What system information will the the actor

acquire, produce or change?acquire, produce or change? Will the actor have to inform the system Will the actor have to inform the system

about changes in the external about changes in the external environment?environment?

What information does the actor desire What information does the actor desire from the system?from the system?

Does the actor wish to be informed about Does the actor wish to be informed about unexpected changes?unexpected changes?

Selecting Classes—Selecting Classes—CriteriaCriteria

needed servicesneeded services

multiple attributesmultiple attributes

common attributescommon attributes

common operationscommon operations

essential requirementsessential requirements

retained informationretained information

Unified Modeling Language Unified Modeling Language (UML)(UML)

User model view.User model view. This view represents the system (product) This view represents the system (product) from the user’s (called “actors” in UML) perspective.from the user’s (called “actors” in UML) perspective.

Structural model view.Structural model view. Data and functionality is viewed from Data and functionality is viewed from inside the system. That is, static structure (classes, objects, inside the system. That is, static structure (classes, objects, and relationships) is modeled.and relationships) is modeled.

Behavioral model view.Behavioral model view. This part of the analysis model This part of the analysis model represents the dynamic or behavioral aspects of the system. represents the dynamic or behavioral aspects of the system.

Implementation model view.Implementation model view. The structural and behavioral The structural and behavioral aspects of the system are represented as they are to be built.aspects of the system are represented as they are to be built.

Environment model view.Environment model view. The structural and behavioral The structural and behavioral aspects of the environment in which the system is to be aspects of the environment in which the system is to be implemented are represented.implemented are represented.

UML: Use-Case UML: Use-Case DiagramDiagram

CRC CRC ModelingModeling

class name:

class type: (e.g., device, property, role, event, ...)

class characterisitics: (e.g., tangible, atomic, concurrent, ...)

responsibilities: collaborators:

Guidelines for Guidelines for Allocating Allocating

Responsibilities to Responsibilities to ClassesClasses

1. System intelligence should be evenly distributed. 1. System intelligence should be evenly distributed.

2. Each responsibility should be stated as generally as 2. Each responsibility should be stated as generally as possible. possible.

3. Information and the behavior that is related to it 3. Information and the behavior that is related to it should reside within the same class. should reside within the same class.

4. Information about one thing should be localized with a 4. Information about one thing should be localized with a single class, not distributed across multiple classes.single class, not distributed across multiple classes.

5. Responsibilities should be shared among related 5. Responsibilities should be shared among related classes, when appropriate.classes, when appropriate.

Reviewing the CRC Reviewing the CRC ModelModel1. All participants in the review (of the CRC model) are given a 1. All participants in the review (of the CRC model) are given a

subset of the CRC model index cards. subset of the CRC model index cards.

2. All use-case scenarios (and corresponding use-case 2. All use-case scenarios (and corresponding use-case diagrams) should be organized into categories.diagrams) should be organized into categories.

3. The review leader reads the use-case deliberately. As the 3. The review leader reads the use-case deliberately. As the review leader comes to a named object, she passes the token review leader comes to a named object, she passes the token to the person holding the corresponding class index card. to the person holding the corresponding class index card.

4. When the token is passed, the holder of the class card is 4. When the token is passed, the holder of the class card is asked to describe the responsibilities noted on the card. The asked to describe the responsibilities noted on the card. The group determines whether one (or more) of the responsibilities group determines whether one (or more) of the responsibilities satisfies the use-case requirement.satisfies the use-case requirement.

5. If the responsibilities and collaborations noted on the index 5. If the responsibilities and collaborations noted on the index cards cannot accommodate the use-case, modifications are cards cannot accommodate the use-case, modifications are made to the cards. made to the cards.

UML: Class UML: Class DiagramsDiagrams

Generalization-specialization Composite

aggregates

UML: Package UML: Package ReferenceReference

Relationships between Relationships between ObjectsObjects

Object-Behavior Object-Behavior ModelModel

1. Evaluate all use-cases to fully understand the 1. Evaluate all use-cases to fully understand the sequence of interaction within the system.sequence of interaction within the system.

2. Identify events that drive the interaction sequence 2. Identify events that drive the interaction sequence and understand how these events relate to specific and understand how these events relate to specific objects.objects.

3. Create an event trace [RUM91] for each use-case.3. Create an event trace [RUM91] for each use-case.

4. Build a state transition diagram for the system4. Build a state transition diagram for the system

5. Review the object-behavior model to verify 5. Review the object-behavior model to verify accuracy and consistencyaccuracy and consistency

UML: State UML: State TransitionTransition

UML: Event UML: Event TraceTrace


DesignDesign

Object-Oriented Object-Oriented DesignDesign

responsibilitiesdesign

messagedesign

class and objectdesign

subsystemdesign

OOA and OOA and OODOOD

Object-relationship

model

Object-BehaviorModel

CRCIndex Cards

Attributes, operations,collaborators

THE ANALYSIS MODEL

responsibilitiesdesign

messagedesign

Class and objectdesign

subsystemdesign

THE DESIGN MODEL

Use cases

OOA and OOA and OODOOD

classesclassesattributesattributesmethodsmethodsrelationshipsrelationshipsbehaviorbehavior

Analysis ModelAnalysis Model

objectsobjectsdata structuresdata structuresalgorithmsalgorithmsmessagingmessagingcontrolcontrol

Design ModelDesign Model

Design Design IssuesIssues decomposability—the facility with which a design method decomposability—the facility with which a design method

helps the designer to decompose a large problem into helps the designer to decompose a large problem into subproblems that are easier to solve;subproblems that are easier to solve;

composability—the degree to which a design method composability—the degree to which a design method ensures that program components (modules), once ensures that program components (modules), once designed and built, can be reused to create other systems;designed and built, can be reused to create other systems;

understandability—the ease with which a program understandability—the ease with which a program component can be understood without reference to other component can be understood without reference to other information or other modules;information or other modules;

continuity—the ability to make small changes in a program continuity—the ability to make small changes in a program and have these changes manifest themselves with and have these changes manifest themselves with corresponding changes in just one or a very few modules;corresponding changes in just one or a very few modules;

protection—a architectural characteristic that will reduce protection—a architectural characteristic that will reduce the propagation of side affects if an error does occur in a the propagation of side affects if an error does occur in a given module.given module.

Generic Components for Generic Components for OODOOD

Problem domain component—the subsystems that Problem domain component—the subsystems that are responsible for implementing customer are responsible for implementing customer requirements directly;requirements directly;

Human interaction component —the subsystems Human interaction component —the subsystems that implement the user interface (this included that implement the user interface (this included reusable GUI subsystems);reusable GUI subsystems);

Task Management Component—the subsystems Task Management Component—the subsystems that are responsible for controlling and that are responsible for controlling and coordinating concurrent tasks that may be coordinating concurrent tasks that may be packaged within a subsystem or among different packaged within a subsystem or among different subsystems;subsystems;

Data management component—the subsystem that Data management component—the subsystem that is responsible for the storage and retrieval of is responsible for the storage and retrieval of objects.objects.

Process Flow for Process Flow for OODOOD

System Design System Design ProcessProcess• • Partition the analysis model into subsystems.Partition the analysis model into subsystems.

• • Identify concurrency that is dictated by the problem.Identify concurrency that is dictated by the problem.

• • Allocate subsystems to processors and tasks.Allocate subsystems to processors and tasks.

• • Develop a design for the user interface.Develop a design for the user interface.

• • Choose a basic strategy for implementing data Choose a basic strategy for implementing data management.management.

• • Identify global resources and the control Identify global resources and the control mechanisms required to access them.mechanisms required to access them.

• • Design an appropriate control mechanism for the Design an appropriate control mechanism for the system, including task management.system, including task management.

• • Consider how boundary conditions should be Consider how boundary conditions should be handled.handled.

• • Review and consider trade-offs.Review and consider trade-offs.

System System DesignDesign

requestclientsubsystem

contract

contract contract

request

request

serversubsystem

peersubsystem

peersubsystem

Subsystem Subsystem ExampleExample

assign to zonetest status

request for alarm notificationperiodic check-inrequire for configuration update

request for statusControlpanel

subsystem

Sensorsubsystem

Centralcommunication

subsystem

request for system statusspecification of type of alarm

periodic status check

Subsystem Design Subsystem Design CriteriaCriteria• The subsystem should have a well-defined

interface through which all communication with the rest of the system occurs.

• With the exception of a small number of “communication classes,” the classes within a subsystem should collaborate only with other classes within the subsystem.

• The number of subsystems should be kept small.

• A subsystem can be partitioned internally to help reduce complexity.

Subsystem Collaboration Subsystem Collaboration TableTable

Object Object DesignDesign A A protocol descriptionprotocol description establishes the establishes the

interface of an object by defining each interface of an object by defining each message that the object can receive and the message that the object can receive and the related operation that the object performs related operation that the object performs

An An implementation descriptionimplementation description shows shows implementation details for each operation implementation details for each operation implied by a message that is passed to an implied by a message that is passed to an object. object.

information about the object's private partinformation about the object's private part internal details about the data structures that describe internal details about the data structures that describe

the object’s attributesthe object’s attributes procedural details that describe operationsprocedural details that describe operations

Design Design PatternsPatterns

... you’ll find recurring patterns of classes and communicating objects in many object-oriented systems. These patterns solve specific design problems and make object-oriented design more flexible, elegant, and ultimately reusable. They help designers reuse successful designs by basing new designs on prior experience. A designer who is familiar with such patterns can apply them immediately to design problems without having to rediscover them.

Gamma and his colleagues [GAM95]

Design Pattern Design Pattern AttributesAttributes

The design pattern name is an abstraction that The design pattern name is an abstraction that conveys significant meaning about it applicability conveys significant meaning about it applicability and intent. and intent.

The problem description indicates the environment The problem description indicates the environment and conditions that must exist to make the design and conditions that must exist to make the design pattern applicable. pattern applicable.

The pattern characteristics indicate the attributes The pattern characteristics indicate the attributes of the design that may be adjusted to enable the of the design that may be adjusted to enable the pattern to accommodate into a variety of pattern to accommodate into a variety of problems. problems.

The consequences associated with the use of a The consequences associated with the use of a design pattern provide an indication of the design pattern provide an indication of the ramifications of design decisions.ramifications of design decisions.


TestingTesting

Object-Oriented Object-Oriented TestingTesting

begins by evaluating the correctness and begins by evaluating the correctness and consistency of the OOA and OOD modelsconsistency of the OOA and OOD models

testing strategy changestesting strategy changes the concept of the ‘unit’ broadens due to the concept of the ‘unit’ broadens due to

encapsulationencapsulation integration focuses on classes and their execution integration focuses on classes and their execution

across a ‘thread’ or in the context of a usage across a ‘thread’ or in the context of a usage scenarioscenario

validation uses conventional black box methodsvalidation uses conventional black box methods

test case design draws on conventional test case design draws on conventional methods, but also encompasses special methods, but also encompasses special featuresfeatures

Broadening the View of Broadening the View of “Testing”“Testing”

It can be argued that the review of OO analysis and It can be argued that the review of OO analysis and design models is especially useful because the same design models is especially useful because the same semantic constructs (e.g., classes, attributes, operations, semantic constructs (e.g., classes, attributes, operations, messages) appear at the analysis, design, and code level. messages) appear at the analysis, design, and code level. Therefore, a problem in the definition of class attributes Therefore, a problem in the definition of class attributes that is uncovered during analysis will circumvent side that is uncovered during analysis will circumvent side effects that might occur if the problem were not effects that might occur if the problem were not discovered until design or code (or even the next iteration discovered until design or code (or even the next iteration of analysis). of analysis).

Testing the CRC Testing the CRC ModelModel1. Revisit the CRC model and the object-relationship model.

2. Inspect the description of each CRC index card to determine if a delegated responsibility is part of the collaborator’s definition.

3. Invert the connection to ensure that each collaborator that is asked for service is receiving requests from a reasonable source.

4. Using the inverted connections examined in step 3, 4. Using the inverted connections examined in step 3, determine whether other classes might be required or whether determine whether other classes might be required or whether responsibilities are properly grouped among the classes.responsibilities are properly grouped among the classes.

5. Determine whether widely requested responsibilities might 5. Determine whether widely requested responsibilities might be combined into a single responsibility.be combined into a single responsibility.

6. Steps 1 to 5 are applied iteratively to each class and 6. Steps 1 to 5 are applied iteratively to each class and through each evolution of the OOA model.through each evolution of the OOA model.

OOT OOT StrategyStrategy

class testing is the equivalent of unit class testing is the equivalent of unit testingtesting

operations within the class are testedoperations within the class are tested the state behavior of the class is examinedthe state behavior of the class is examined

integration applied three different integration applied three different strategiesstrategies

thread-based testing—integrates the set of classes thread-based testing—integrates the set of classes required to respond to one input or eventrequired to respond to one input or event

use-based testing—integrates the set of classes use-based testing—integrates the set of classes required to respond to one use caserequired to respond to one use case

cluster testing—integrates the set of classes cluster testing—integrates the set of classes required to demonstrate one collaborationrequired to demonstrate one collaboration

OOT—Test Case OOT—Test Case DesignDesignBerard [BER93] proposes the following approach:

1. Each test case should be uniquely identified and should be explicitly associated with the class to be tested,

2. The purpose of the test should be stated,

3. A list of testing steps should be developed for each test and should contain [BER94]:

a. a list of specified states for the object that is to be tested

b. a list of messages and operations that will be exercised as a consequence of the test

c. a list of exceptions that may occur as the object is tested

d. a list of external conditions (i.e., changes in the environment external to the software that must exist in order to properly conduct the test)

e. supplementary information that will aid in understanding or implementing the test.

OOT Methods: Random OOT Methods: Random TestingTesting

Random testingRandom testing identify operations applicable to a classidentify operations applicable to a class define constraints on their usedefine constraints on their use identify a miminum test sequenceidentify a miminum test sequence

an operation sequence that defines the an operation sequence that defines the minimum life history of the class (object)minimum life history of the class (object)

generate a variety of random (but valid) test generate a variety of random (but valid) test sequencessequences

exercise other (more complex) class exercise other (more complex) class instance life historiesinstance life histories

OOT Methods: Partition OOT Methods: Partition TestingTesting Partition TestingPartition Testing

reduces the number of test cases required to test a reduces the number of test cases required to test a class in much the same way as equivalence class in much the same way as equivalence partitioning for conventional softwarepartitioning for conventional software

state-based partitioningstate-based partitioning categorize and test operations based on their categorize and test operations based on their

ability to change the state of a classability to change the state of a class attribute-based partitioningattribute-based partitioning

categorize and test operations based on the categorize and test operations based on the attributes that they useattributes that they use

category-based partitioningcategory-based partitioning categorize and test operations based on the categorize and test operations based on the

generic function each performsgeneric function each performs

OOT Methods: Inter-Class OOT Methods: Inter-Class TestingTesting Inter-class testingInter-class testing

For each client class, use the list of class operators For each client class, use the list of class operators to generate a series of random test sequences. The to generate a series of random test sequences. The operators will send messages to other server operators will send messages to other server classes.classes.

For each message that is generated, determine the For each message that is generated, determine the collaborator class and the corresponding operator collaborator class and the corresponding operator in the server object.in the server object.

For each operator in the server object (that has For each operator in the server object (that has been invoked by messages sent from the client been invoked by messages sent from the client object), determine the messages that it transmits.object), determine the messages that it transmits.

For each of the messages, determine the next level For each of the messages, determine the next level of operators that are invoked and incorporate these of operators that are invoked and incorporate these into the test sequenceinto the test sequence