Software Engineering: Modern Approaches

Brief Contents Prefa C X IV Acknowledgmen ls Part I Part II •• XVII Introduction to Software Engineering Software ...

Author: Eric J. Braude | Michael E. Bernstein

1860 downloads 6844 Views 147MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!

Report copyright / DMCA form

DOWNLOAD PDF

characlers will need to be displayed, we ca n actua ll y ensure thIS re q ulTeme nt by g IvIng the ba,e cia Gam,O,"raelt' a dlsplay (J metho d .) The ,equcnce dia g ram shows Ellco""""Gam, c reating the fore Ig n haractet (Step 1.2) and also an Engage men t o bject, and th en ca lling d"piay() An engagemcnt" to take place, and a good design is to capture Ihis by creat ing an EII9a9Cl"ClII object Th,s IS ill ustrated", F,gure 19 17

2 ThiS tcp

10

the usc ca~C' Indicates [hat we need a n cxrcutr() melhod

E"!1agcmnlt

In

2. 1 Th i step requires that Freddie and th e main playn c harac ter be able to hange thelT qua lo ty va lues Inee th is capab ll, ty i<; comm o n to al l fucol/'Ilrr Char.:lCic". w (' prOVide the base EII(.olmfr r(JJararlrr clas WIth a wQuallly () me th od

:Encounter game

:Encounter Cast

-'-'-"----'

freddie: Foreign Character

engagement: Engagement

1 1 dlsplayForolgnCharO

1.2 dlsplayO

1 3 new Engagemo:..n=-I"O--_ _ _ _ _ _ _ _ _ __ I •

Figure 19.17 BegInning of sequence diagram for Encourl! r ForeJgn CharaCler USC case

487

0188

CHAP tER 19 DETAILED DESIGN

:Encounter arne

:Encounter Cast

engagement: En a ement

freddie: Foreign Character

I I I I

1.1 displayFore'gnChorO 1.2 d,splayO

I I I

1;] ~

1.3 new Engagemenl()

~

2. execute()

:Engagement Displa

!

J

2.1 setPlayerOual,lyO

:Player's • maIO character

I I I I

I I I I I

2.2 setOuai,tyO

I

t 2.3 setForeignOuality()

I 3.1 new Engagemenl0ispiayO

2.4 selOuaiityO

3.2 displayResul t()

Figure 19.18 Sequence diagram for Encounter Foreign Character use case 3. This step requires that the re ult of the engageme nt be shown. The following two substeps constitute one way to do th is. 3. 1 Fu'St Engage ment crea tes an E"9a9"""' tD;,play o bject. 3.2 Now we show the engagemen! dISplay by calling its d;,playR<suliO metho d .

Si nce the me thods required to execute this usc case arc now known . we can include them on the class model , as in Figure 19 . 19 . Con tinuin g ,his process , the class mo de l and the use case mo del (in the form of seq uence dia g rams) arc complet ed in detail , a show n in ,he case study. T he state model (if app lica ble) mus t al 0 be completed in derail. A data flow di agra m is ye t ano,her possibly u efu l mo d el, and IS discussed next. Engagement

executeQ

EngagementOisplay displayResultO

EncounterGame

EncounlerCast disptayForelgnCharO setPlayerOuailtyO setForelgnQuality()

FIgure 19.19 Classes for Encounter Foreign Character use case

PlaverCharacter setOuality() ForeignCharader selOualityO

SEQUENCE AND DATA FLOW DIAGRAMS FOR DETAILED DESIGN

19.7.2 Detailed Data Flow Diagrams To relate dala flo'" model, to I."e•. we ca n map ('ach proce sIng elemenl 10 a meth o d of • cla.s. F,gure 19 .20 shows a h'gh ·level VIew of a dala flow d,a gra m fran ATM banking appilcaHon Dala flow mo dels can be lc/mop,.1 For example. F,gure 19 2 1 exponds proce"In!! clement< tro m lhe DFD In F,gure 19 20 T ele, op ing allows us 10 show a hlgh · level VICW, fo llowed by successIve 'tages co nta in Ing as much delJl1 as we WI h. Th. " aVOid .. overwhel ming the viewer Each pro e"~ ln g tlt'mem IS expanded Into a mo re detailed DFD. a nd thI S expa nsion proccs~ is continued unl .! the lowest level prace . sin s l'!ement are reached The latter are typically ,nd,VI dual ftlnct lo ns, pOSSIbl y of dIfferent cla<St< For example, lhe g"D,poSl'() fun c lio n IS expanded in lO lhree un tlons (gelllnl! lhe I)asswo rd, verify,ng II , and makIn g a dISplay ). T wo o f lhese Inleract WIth dala Slore> (a local log of lransa lIons, a lISt of problem users, and a templale for
Account.

Balance

Customer.

User 1--

getDepositO

getDetailsO

Customer

Logical (unction (software or hardware)

Figure 19.20 Detailed data flow dIagram for bankIng application, 1 of 2- hlgh level

.'~'

f"

.. , .' . ,.'

Customer

Account.

",

'·'1~1::.:'.'"

getDepositO ""

. • '

,

Balance

.

,"

", '

..

".

,..::.:------,

'

.

'..

........ ~----Customer.

,.f'

'" •

'"

Expand details "" ".

...~...

Balance

"'" .''%...,.

• , ,.

getDetails()

User •

".

•

".

. .... " ........ '

.. datastore ,.

.. datasloren

Screen template

Local log

",

. -. ....,.

"

Customer

,

- -----; ",'" '." ,~, .. datas tore,·

Unacceptable

-. "',

'-

ATM users

•

--.

,

--

•

Deposit-

Account.

Account.

screen .

verifyPass·

getPass-

display()

wordO status

Password

wordO

•

" ,.

I,U

Figure 19.21 Detailed data flow diagram for banking appllcallon, 2 of 2- wllh details

• •

489

490

CHAPTER 19

Ea h

DETAILED DESIGN

processln~ elemenl " expanded

1111 0

a mo rc de,ailed DFD, and 'h" cxpan>lon proce" " con ·

tlnlled unt" the 10\ c-.t ·lcvel pro C"'~ '" 8 clements Jre rca hed 11,c IJuer Me tYPICall y Indi vidual (unction,»,

ro"ibl of d,fleren, cla"e For example . Ihe gr,D,pos, l() lun I,on ,s expanded ,n lO [hree lun lion' II(CltinK 'he p.,sword, venlyong i', and making a display ) Two 01 theats (rom the detailed cxpancolons malc..h tho C In the vC~ l o n ~ from whl h they arc expanded DFDs arc nol hclphil for .11 appiocal,on . For example, rhey do nol add mu h Ihe Encoun ,er case study

'0

19.8 DETAILED DESIGN AND AGILE PROCESSES Ag,le procc<scs, descnbed in

hapler 4 and referred ' 0 throu g ho ut Ihis book . ernph", zc work,ng code and

place documentation at a lower pnority The lauer includes dctai Icd d('s l ,gn~ An cx tTcmc I nterprctat Io n of thiS IS thJt detaIled de: ign countS (or very little, but a more mca lIrcd Interpretation is lh~H an agile process would

crca!'e detaolcd designs for o nl y t hose parts of app lieation< where the effort to produce them is worth the beneht An example is a complica,ed bUI important algon'hm . A non ·agile developmen, effort , on the o the r hand, may document every method For large development erforts, Ieavon!; ,t to ,he judgmen' of hundreds 01 sorrware engooeers as 10 whe ther deSIgn de'ails should be documented o r no' may nOt be favored by projec i managers

It is obvious that oftware cnglllcers should not engage in ~ cti v lt ies with Insu ffiC ient benefits. One issue that makes this less than clear, however, is whether one a . esses benefi ls in the shon tem1 or the long lerm

Good , deta,led design doeumen'ation of a class ,hat supports the code (possibly as comme nts) would help ma,ntainers. I, would also have 10 be kep' up· to· date by main,ainers. This is probab ly a long· tem, bencfir ,hal is not as clear in the hon term

19.9 DESIGN IN THE UNIFIED DEVELOPMENT PROCESS Recall ,hat 'he unified development approach 01 Jacobso n 01' aI. , described on Chapter 3, groups iterarions ,n lO the "Inception: "Elaboration ." "Construction ," and "Tran
U. P. Term

Inception Elaboratlonl

Construction

Transition

I

ReQu1rements

I I

Analysis

I Design

I

Implementatlon

I I I I

I

I

Test Prelim.

Iter.

lIerations

.1

Iter. Iter. Wn 'n+1

.....

Figure 19.22 Unified software developlllent method process-deslgn

Iter.

Itor

• m I'm. 1

..... Uer . _k

UPDAn NG A PROJECT WITH DETAILED DESIGN

1. Introduction 1 1 Purpose

4. Dependency description

A.,I:",,..,,

1 2 . Scope 1.3. Oef,nitlons . acronyms. and abbreviations 2. References .,. 3. Decomposition description

3 .1. Module decomposl1ion 3 1 1 Module I descnptlon 3.1 1 Module 2 descnptlon 3 ,2 Concurrent procoss

decomposition 3 .2 1 Process 1 description 3.2,2 Process 2 description 3 .3 Data decomposItion

3.3 1 Data entry 1 description

3 3.2 Data enlry 2 descnp~on

4 1 Intermodule dependencies 4 2 Interprocess dependencies 4 3 Da ta dependencies 5, Interlace description 5 1 Module Intertace S 1 1 Module 1 description 5 1 2 Module 2 descnpt 'on 5 2 Process Interface 5.2 .1 Process I description 5 2 2 Process 2 descnptlon

6. Detailed design 6.1 Module dela lled design 6 .1.1 Module 1 detail 6.2.2 Module 2 deta il 6.2 Data detailed design 6.2.1 Data entity 1 detail 6.2.2 Data enllty 2 detail

Figure 19.23 IEEE 1016· 1998 Software Design Document table of contents. With focus on detailed design section SGut:e' IEEE 10' 6-1998

that most of [he requ"e m~nt < wdl have been gat hered by tho e sta ge, An "Analy"s" pha,e " freq uentl y identified a part of the waterfa ll proce s omp.red with the term ino logy of thi s boo k. the Ana lys " phase cons! (s partly of requiremen t. aniliysis and panl)' of ilfchitt'crurc elc::ctlon The unified process encourages three types ("stereo types") of classes althe analYSIS level · "'lity bou"dary and (antral classes, wherea Lhere I no or;;:uch n:slriction on deSign clas cs Entity classes exprc~" th e es cnce of the concept. and arc ur.likely to req uire c han ge ove r time or between al>plo c olions Boundary cI.sse, h andle communication with entity objects, and control c1ilssC' contain methods th at pertain to th e C'ntlty ObJl'c t but Ihat are Iyplcally speCia l to th e app li ca ti o n in which th e en tity class is beong used . Bo unda ry clas e' are typically like the M,d,.'or objet! on the Mcdoator de ign pattern descnbed In Chapter t 6 The umned proce promotes VI ual tools for deSig n An example o f th" " Ihe Rat io na l Ro<e tool sold by IB I\\

19.10 IEEE STANDARD 890 FOR DETAILED DESIGN Recall IEEE ta ndard 10 16 · 1998 for olt ware DeSign D ocument, , how n on hapt er I o n 'olt",. rc architecture. ae; shown In Figurt' 19 23 Thl~ format for tht' dc·taded d<.: or; : lgn \CC[ lon of thle; documcnt co nsl<;ts of speclfyon~ a desuipllon o f each mo dufc (po ka g l' ) In turn , With a det.oIed desulptlon 01eoch d a la part Fo r 00 deSign , . the lalter c. n be repl aced with a detaded de,c nptlon 01 each cia"

19.11 UPDATING A PROJECT WITH DETAILED DESIGN On(: a detadc:d uco., lgn I ~

hand, the projC t pl;)n ca n I c mJde morc '11<'CdlC In ')(."vcral rce; pl'C ts III partl ubr (.ost estimation Cil n he made.' mu h more pre I':;C , chcdul co., an be brfJk t' l1 cl own Into tJ,k,. and tJ,k .. an be .lIocated to ond,vldual, r ,,,!urc 1924 In( lllCle, mO
design" <: Inl ~rr~d f"lm Ih e " Z.l· II ~lI rc t 'l 25 , h ow< line ",aj' o f orrylng th" lit

491

.92

CHAPTER 19 DETAilED DESIGN

I Make ,u"" Ihe SDD renect< I.te,t version of dctadl'd de,i~n , ., Set lied on after Impcclions 2 G,W complele delall 10 Ihe ,chedule ( PMP) 3 Allocale precise lasks to team members (SPMP) 4 Improve projeci co I and time C limates (sec below). 5 Update the CMP to renect the new parts. 6. Review proce s by which Ihe detailed design w. crealed, and determine Improvement< Include

•

• time taken . broken down to include • preparation of the de igns • Inspection

• change • defect summary

• number remaining open, fou nd at detailed desig n, closed at detailed design • whe"" injected; include previous phases and detailed design stages Figure 19.24 Bringing the project up·to·date after completing detailed design

The COCOMO model can now be used again to refine the estimate of job durati o n. It IS be t to usc personal data to eSlimate th e LOC for very small , sman , and such jobs. In the absence of these data, department, division, o r corporate data can be used. Otherwise, Humphrey's table (Figure 19 .26) [6] may be usefully applied. Figure 19.26 applies to C+ + LOC per method. On the average, Java and C. + requ ire the same number of LOC to implement si milar functionaliry [7, 8]. Calculation methods perform numerical comput.tion; data methods manipulate data (e .g .. reformat· tlng); logic methods consist mainly of branching; setup methods initialize situati o ns; text methods manipulate text Estimates for methods that combine several of these can be computed by averaging. For example, an unexceptional ("medium") method that performs calculations but also has a substantial logic component can be estima ted as having ( 11.25 • 15.98 )/2 = 13.62 lines of code. Descriptors such as V'ry Small and Sm.1I are "fuzzy" in that they describe ranges rather than precise amounts. These ranges can overlap. in which case an aVCr.lgc of the correspondi ng table values can

(This

IS

be used.

actually a simpli fication of fuzziness . but adequate for our purpose.) Fuzzy descriptors arc practical

I. Start with the list of methods.

• ensure completeness, otherwise underestimate will result

2. ESlimate the lines of code (LOC) for each . • classify as IJfry ' ",nil, 'mall, m,dium . "',g', "'ry I.,g, • normall y in ± 7%/24%/ 38%/24%/7% proportions • usc per onal data to covert to LOC • o therwise usc Humphrey's t,ble below 3. Sum the LOC. 4. Covert LOC to pe,,;on·hou,,;. • use personal conversion (actor,

if

possible

• otherwise usc published factor 5. Ensure thar your estlmales of method sizes ,nd time will be compared and saved at prOject end. Figure 19.25 Estimating size and time·to·complete from detailed designs

UPDAnNG A PROJECT WITH DETAILED DESIGN

Calegory

Very small

Small

Med ium

Large

Very large

2 34 2 .60 90 1 7.55 3.88 3.75

5 13 479 12 06 10 .98 5 0·1 800

1 1 25 8.84 16. 15 15.98

24 66 16 .3 1 21 62 2325 853 364 1

54 .04 3009 28 .93 33 83 11 09 77 67

Calculation Data Metho d type

VO Logic Set-up Text

6.56 1707

Figure 19.26 Lines of code .sc:ure Humphrey. Watts S. A Otsclplcoe lor SOltware Englneenng (SE! SolEs In SOftware Englr'leenng), AdcJlSkln-We<'Jpy, 1m

~cause they arc ca'\y to understand They ca n be made more precIse.: by ca te gorization \\Inh the normal

distributi on, as shown in Fi gure 19.27 On Ihe average, about 38 percent of the meth od sho uld be claSSified as "medium ," 24 percent "<mall ," and 7 percent "very small: a< illustrated in Figure 19.27 These numbers arc oblalnod from the fac llhat about 38 percent of the va lues in a normal d, tributlo n arc wilhin a half of a standard deviation of Ihe mean In practical tenns, If the fract ion of metho ds yo u e lilll ale as "very large" differs much front 7 percent , for example, Ihen you shou ld be satisned that yo ur app lica lio n rea ll y does have a n unu sua l numbe r of very large methods. O lhc lwi ' e , yo u sho uld revise your es tllnales. As an ,,"ample, lei's <Stlmale the size of the <xccul<() metho d of th e Eng"gem"'l clas l111s mel hod Involvo< the recalculation

or qua li ry va lues, which is th e cssenria l mechanism of executing the engagement process

For this reason , we could clasSify Ih e ",tmltO met ho d a, a "calculati o n.' The size of the "'t(ultO mel hod is not particularly remarkable, since it consi ts of a fairl y straightforward co mputat io n of va lues, so we'll cla<>.fy II as ' medium : Thus , the e timated co ntribution of "'t(ult O is 11 .25 LOC A level 5 orga nizatio n (sec C hapter 5 o n the Capabilit y Maturity M o del ) would IYPlcali y pl o t method size estimates against acrual Sizes In o rder to improve thi S es timJtlon process. In th t- ca ... e study , these estimates arc app li ed to the Encou nter Video ga me .

Approximate percentage of methods classified with this description

s 24 %

7%

M

L

38% 24 %

v -2

7%

v -1

o

1

2

Standard devia tions Irorn the moan

Fl&ure 19,27 Normal chSlllbuUon of "small," " medium," and " large"

493

.94

CIiAPITR 19

DETAILED DESIGN

19.12 CASE STUDY: DETAILED DESIGN OF ENCOUNTER the l,audl,E.CIlIO method of Its al!grel!ated Ga",Slal, ob)e t. The seque nce d ,al!cam for th is IS shown In Figure 19,29. For th e current fe lease , the methods arc

\'\fhat follow> ISthe detailed de. llln for Encounter, based on th e architecture speciRcd earlier 10 dHS book, and

lOll the IEEE standard E.ch use case is rea!.zed a< a sequence diagram by dl'CldlOg, for cach u
either trivlJI or arc 'ihow n

Figure 19 29

Pseudocode (or selec ted method within se · lected classes may be included he re. In addi · tion , detailed usc cases can be included. Si nce the methods and thei r detai ls arc still o ne or two lines in rhis case, it is sufficien t' to elab· orate o n the (barely) nontnvial me thods wllh the no tatIOn shown in Figure 19.28 .

6. Detailed Design of Role-Playing Game Framework

6.1 Module Detailed Design Note to the Student· These sections give all of the nontrivial required details on each of the modules described in Section 3.1 in this SOD for the game framework.

6.1.2 The Characters package This section elabora tes on Section 3, 1.2 of this SOD. There is one clilSSin the Characltr package, Ga..tCharadtr.

6.1.2.1 GameCharacter Class Methods of Ga .. ,Charac/cr

6.1.1 Role-Playing Game package All mouse eve nts are liSle ned for by objects of the

setName ( ) . Pr eco ndition s : n o n e ; p ostco nd itio n s : none; invar iants : no n e

RPGMollScEvrn IUsto1Cr, which Inherits (To m Mou"L "",,, as shown in Figure 19.28. Each object

class

that is

In

cns ltivc to mOllse eve nt's Jsks an

RPGa mr

object to ha ndle the eve nt. RPGa .. , passe control to

MouseListener ( rPGameS .handleEvent():

I I

rPGameS

RPGMouse£ventListener mouseEnlerO

RPGame handleEventO

slateS

( stateS.handleEventO: )

Figure 19.28 Derailed design of RolePlayfngGame package

handleEvenlO

CASE STUDY' DETAILED DESIGN OF ENCOUNTER

user

eventTarget

:RPGame

:GameState

:RPGMouseEventListener

1. mouse-+(-, action

2. mouseChckedO

3. handle Event

( Event) 4 . handle Event

( Event)

Figure 19.29 Sequence diagram for handling mouse events

Pseudocode, IF aNam~ parameter OR max umChars ln ameO make no ense er name to default va lue and ,how thiS

In

system window

ELSE IF parameter stri ng too long truncate at max 'urn hars lll

ame()

6.1 Module Detailed Design for Encounter Th~se

sections give ali of the reqUired detail on each of the modules descnbed In cct,on 3.1 in thi s SDD (i.e ., for Encounter).

6.1.1 The EncounterGame Package

ELSE aSSign the parameter nam e

6.1.3 The GameEnvironment pacKage This package IS descnbed completely by F'l(urc 19 .3 1 in Section 3 I of thiS DO (C hapter 18)

6.1.4 The Artifacts Package Ot appltc.ble ,n thiS ,ter. lI on

This section glve< ali of ,he required detat!, on Section 3 I I In thl DO. It descnbe com· pletely the classes of the Ell pack· age, and .11 of thelt nontnvial behaVIOr. Mosl of ,hI< " desc ribed b , ,he state tranSition diagram In the Inlerest of keeping ,he cia model fre~ of ciuller. we do not show all oblecl

o,,,,'uGa,,,,

referen ces

6. DETAILED DESIGN OF ENCOUNTER The

The ove rall arc.hllc:<.tur 0, ,howlng the r 'IJlIOn,hlp"

amonl! the package, .nd th domain d."e, dc· 'iCnbed In th" seCllon, " shown tn I' Hure I') ~(I

,lille

,"aJ.;rJIll lor Ell ounter

1'"

... hoWI)

In

SeUinn 2 I I (JI the RS (h Mure I I 2{) I (hopter I I ) To rt"al ,zc lhc,c tl" l il l l'" and lI~n' llI o n , the E 'I(C'IIIIltT(;,IIIH" l)atbgc tI " mod·1 " dC"Rned ." l,gIII'<: I'l 1 1

II'

495

496

CHAPTER 19 DETAILED DESIGN

RolePlaylngG.me . f_work package w

Characters

- U~6S •

EncountorGame EncounterCharaclers

-application package -

.. use

I

- application package-

I

EncounterCharacter

-z;;-

Ir

I

EngagementDisplay

I

GameEnvironment

PlayerCharacter r

I Engagement I I

EncounterGame

- framework package-

ForeignCharacter

PlayerOualityWindow

- u~es w

EncounterEnVlronment

I

..application package ..

Area

Gam8Art~acts

.framework packsge-

I I

EncounterAreaConnection

Con nectioflHype rI ink

I

I

Figure 19.30 Encounter game architecture packages, showing domain classes only

, : ,,

,,

~------- ------------

,,

RolePlayingGame

,, ,, ,,,

-,- ------------------- --------------------------------- ------------- --,,

RPGMouseEventustener

RPGame

GameState

notilyOfEventO

handleEventO

handleEventO

,,, ,, --- -------------- -------------------------------- --------- -- ------- ---- ----- -

,, ,,, ,, ,, , ,

~

--1-------£------------------- -- ---- -- ---- - -- -- ~ ---- -, I I

EncounterGame

I I

«singleton»

I

I I

I

I I I I I I I

Engagement

t

--------

<>l

I

Engaging

Wailing

handleEventO

handleEventO

I

I EngagementDlsplay I t fL.. _ _ _ _ _ _ _ _

Figure 19.31 Detailed design of EncounterGame package

I

I I I I

Reporting

Preparing

handleEvenlO

handleEventO

----------~-------

EncounlerEnvironment

I

-------

EncounterCast

I

I I I I I I

,I, ,, , EncounlerGame , ----- ----- -- ----- '

- - - -I

CASE STUDY: DETAILED DESIGN OF ENCOUNTER

n ,crc ,.. {''(actly one 1O,,{a n l' of the E"tOUlltrrClltn(

c1as n,e
Q"alVal,,,DlSpl " a rcad ·o nly tex i box fo r d,s-

01 Ih, obJecl rene I Ihe ; Iale, . nd In

pl .y ing the value of a qual,ty.

the above tatc· transltlon diagram

"Q".lValll,D ..pl " an ed'i able lex I box fo r

The fncou"tm"9 'laic aggregale all E"909""",1 obJecl

ellong Ihe value of a qua l,lY

that en ap ... ula tcs the cllgilgcmcnt of th e gJmc charac -

lers

n,e E"gogm,,,,1

lass aggfl'galCS a d,splay called f"g.!I"",,,IDospl.y . The laller IS m u<e ·sensollve. reg's. lenng w'lh an RPGA IOll" E"noILslno" obJe I When Ihe Encounter game

IS

Enco'lIIlrrD;splayllrm ab
execulcd , thl li stener 0 1 Jeet rder-

EIlgagcmrt" D,spl"y

ences Ihe E"co,mlrrGano, obJecl (an RPC."" obJe I) Th" enables E"co,,,,trrG.m, to handle all evenl< acco rd ing 10 the game's tate. uSIng Ihe I.IC dl'<'gn pa llCIn The E"counlrrG.m, package ha, Ihe «'Spon ,bolllY 01 d, recl ·

6.1.1.1 The EncounterGameO;splays Subpac kage of the EncounterGame Pa c kage Di splays correspo nd ,ng to some of Ihe tales arc hand led by a separa te: ubpackage , Ellcou"ter ,(JmcD,splf1Ys, w hi h IS shown on F'gu re 19.32

des'gned to do< play the

current va lue.: of any selec ted qualIfY·

S"Q,wl,tyD,splay , dc
Ing the movement of th e fo rc-ig:"} charactcr over l ime.

Th, , perlom,ed by melhods of the cia, ham 1,,MOV<mml. which os a thread class tale classes need to rdert n e other package on orderto ,mplcment IJall,Il,EIJtI,tf), and th,s is done th rough the Fdcadr objects EncolUlkrCn!lt and E,,(OlltlttTftlViromnnl f

IS

10

SCI Ihe va lue of any qua lilY

Ell o""!r,DlSplay ab traclS Ihe propcrt,c of Ihese dosp la s and IS. med,.to r base lass Th, document does not prov,de further dCloois of Ihe deSIg n of the,e lasses

6 .1.1.2 Se quence Diagrams for Event Ha ndli ng 6.1.1.2.1 Player Dism isses Event

Report Window Fi gure 1933 hows the wqllence ,,,volved

i n di sm ISS i ng th e cngagc:mem d,o;;pla

QualLslD;splos a lost box conSIstin g of Ihe qual,, · ICS

or Encounter ch ar.'l ctcrs

II

,,I , ,, ,I

IS

~ h wn

on

-- --- ------

-_..... - ....... _..... _.. _--

EncounterDisplayltem 0

I I

EncounterOisplay

~

: ~ EncounterCast

I

I

Oual listDispl

I II

SetOualValueDispl

..,

OualValueDlspl

I I I

,I

Reporting

EngagemenlDisplay

I I

,I

SetOualityDisplay

- -

-

-

-- -

Figure 19.32 DeUllle
i '!. _-1

handleEvonlO

Preparing handloEvonl()

di .

the ,IJtC - tran Il io n

d,agram .)

MouseListener

r-

m ls' al eve nl

tTh,<;

I

497

.98

CHAPTER 19

DETAILED DESIGN

user

:EngagemenlDisplay

1 • hI!

dismiss bunon

:RPGMouse EvenlUslener 2. mouS
:ReportingEncounler :EncounlerGame

3 handleEvenlO

4, handleEventO 5. solVlsible( lalse ) 6. setState (new Walling ())

Figure 19.33 Sequence diagram for dismissing engagemenl display

6.1.1.2.2 Player Completes Setup Event

Fig.

ure 19 .34 ~hows the scque nc(' Involved when the player completes the SC:l"Up . (Th is di missa l event is shown on th e ~tatc ' lransition diagram .)

6.1.1.2.3 Player Moves to Adjacent Area Event Figure 19 .35 shows the sequence when the playe r moves

to

an

adjacent area

user

by cl icking o n a

connec tio n hy perl ink. (Th is dismissa l event IS shown o n the state· transi ti o n diagram .)

6.1.1.2.4 Sequence Diagrams for Remaining Events The remai nong eve nts are handled very sim ilarly 10 th ose described in Sectio ns 6 . 1 1.1 Ihrough 6. 1.1. 3.

:PlayerOualityWindow :RPGMouse EventListener

1. hIt

dismiss

bunon

:SettingUp

-l

2. mouseClickedO

:EncounterGame 3. handleEvenlO

or 4. handleEvenlO

"r'1 5. setVisible( false )

r'r

Figure 19.34 seQuence diagram for Player Completes Setup use case

6. selSlate (new WaltingOi

CASE STUDY DETAILED DESIGN OF ENCOUNTER

Us er

:AreaConnectionHyperl ink

,

:Waiting

:EncounterCast L

l.h area

"

con neetion

:EncounterEnvironment

:RPGMouse EventListener

-+n

...J

:EncounterGame

hype rlmk

...J

2. mouseChckedO 3. handleEventO 4. handleEventO

+0-,

5. selVislble( lalse )

-+n

6. d,splayAreaO U'

I

7. d,splayPlayerCharacterO

________ J___ __l ___________ ___ _______ ,,----- ------------ -- --------------, , ~ ____________ _________ ___ J!!9!'!!.Jl'! _c'!.<}~c'er present --- ---- , -----r-- ---------------- -----

8. dlsplayFore'gnCharacterO

U

9. setState (new Engag,ngUi

Figure 19.35 Sequence diagram for Player Moves to Adjacent Area use case

6.1.1 . CM The CharacterMovement Class

As in the SRS, we arc UStng an alphabetical "numbenng" scheme to make It eaSlcr to find and tnsert classc . There is . 1 0 a be nefit 10 being able to trace the requireme nts to the

6.1.2. EG The EncounterGame Class ThIS " the faca de , IOgltton lor th t E" o""'rrG"",, package Inherit ance 1l1is cia 0;; in hents from RPGafl1( 10 the r..ln1cwork

Aunblltc"> of Ell olwlcrGflmr

SRS.

EncounterGame encounterGameS :

11" s .s thl.: ",nglcton Th is cia." co nlrol~ the movc:men l of the fon: lg n

o n ' lrlJ C l or~

character

Methods of (haradrrMov,""H I

obJc

t

of E"loll"lcrGtlmc

pr ivate EncounterGame () :

Inheritance

Th is cia'> Inhent< from Java 1""9 Thread

EtlCOlltllrrGmnc

Precondition.:; none

Post ndillon...

Mcthod"

rcJ t (~ I n EII(Olmtcr(,(lrtlc In,l"J,nte

of E",outllcr(,mnr

publi c static EncounterGame run ( ) ; public static EncounterGame

Slart, the foreign ~ h .ract"r ,n th" dung""n Muve, the f",elgn haractor Irom arCJ to area

getTheEncounterGame() :

Via area ('onnC('II()n<. , cha n~l!l~ area.., to a ran

PretO lH.h l IOn\ no ne

domly ,cI~~led n ' Ighbnr, at random IIme<

11o\ltOlldlll n,

a\,("raKln~ f..:vc:ry two \ccond ...

I

ttlco lHllrrC,tltnrS not

e turr)«; ('It CO IIPlI('(hl "' t'~

nlill

499

500

CHAPTl:R , 9

DETAILED DESIGN

6.1.3. EN The Engagement Class ThIS clas< n Jpsulatco;. cnHagcmcn ls bct\..,1 ccn the players char· aCter and th e fore lg" c harac ter. and corresponds to

Each of Ihe« cla< e' Implements Its hand/,tDatIO method in a corda nee WIth the sequence dIagrams of ection 6 I. I I,

reqUIrement 3 2.EN .

6.1.2 The EncounterCharacters package public void eng_geO;

II

This section elaborates on Section 3. 1.2 in this

SOD.

orresponds to reqUIrement 3 2.EN .3. 1 Precond,ti ons, The player's character and the foreign charJctcr arc in Ihe amc area. Postcondition,>: Th e valul"'S of th e characters'

qualitlcs are as reqUIred by SRS requirement 3.2.EN .3 Ii the player's character and the for·

TI,e deSIgn of the tllcoun l,rCharaclm package is shown in Figure 1936. It is implemented by the Facade desig n pattern , with EllcounltrCn" as the fa · cade object .

cign character arc in random but different areas.

6.1.4. ll. The Engaging, Waiting, preparing, and Reporting Classes The '7:z." numbering is used to collect classes that arc not specified individually.

6.1 .5. EC The EncounterCharacter Class This class encapsulates the requirements for El1coul1ttr

charac ters that arc not covered by R.PGam,Characlm . It satisfies requirements SRS 3.2.EC. Class invariant, The va lues of qlla/lla/ur/ arc nonnegative (see lfattnbulcS" below (or the deAni ·

tions of qua/lla/",n . Inheritance

Inheritance

The e classcs inherit from Gam,Slal, in the framework package.

This class mherits from GameCharacter in the framework package.

Characters . Iramework package"

GameCharacter

EncounterCharacters ..application package-

EncounterCharacter

.·facade-

PlayerCharacter

EncounterCast ForeignCharacter FIpIre 19.36 Detailed design of Encountercharacters package

CASE STUDY: DETAILED DESIGN OF ENCOUNTER

Attnbutc of

EI1C'Olmltr

These att~.f

requ irement

Set Ihe stated q uality to the destred amount

baraclcr

32ECI

private static final String[ J qualityTypeS

IF the caller adjusts the on ly nonzero qual · ity value , divide the adjustment amount

equally among all other qualtttes

This represem the qualities that EnCouHlu char-

EL E change the remalOlng qualttic., re o

acters pas ess. These arc conCe ntrati o n, sta·

tainlng their murual proportiOn,

mlna , Inlclhgcnce, patience, and strength .

private float [J qualvalueI 11u IS an array qualtttcs.

COnt3 1nlflg

the valuec; of the

Constructors of EnC"ounlrrCI){zracrrr

These satisfy reqUIrement' 3.2 EC3 of the SRS Null constructor Po tconditton The qualit lc arc all equa l fracttons of 100

Sct each quality whose va lue is now less than 0.5 to zero.

public float qetQualityVillue ( Str ing qualityP ) Preco nditions qua lt tyP IS a val,d q"altty string Returns the va lue of qua lt tyP

pub 1 ic f loa t qetToleranc e ( ) Return , thc value below whIch quality values cannOl go

protected EncounterCharacter ( St ring nameP )

protected int maxNumCharsInName ()

Pos tcond l Lions ·

Rerurns: t'he max imum number of charJcter In

( I) the qualities arc all equa l fnct ions of 100.

th e names

(2) the character's name

public float sumOfQualities ()

IS

ameP

Methods of EncolI" I"Charact"

public synchronized void adjustQuali ty

( String qualityP , float qualityValueP ) TIll method ,.ttsfle< requirement 3.2 E .3 2 Invananls none

Precond,tIons, qualltyP I< In qualttyT ypc<S[ J AND qualltyValue l > =0 AND quahtyV. lueP < = the sum of the quality values Pcxlcondl t lon\

quahtyP has the value qualtty Value P AND the remaining quality values arc tn the qmc proportion 3\ prt()r to Invocallon , exc.ep t th at va lue:, I c,,~

than 0.5 arc zero The followIng" the p<cudo ode for the method aJ)u"Oua/IIY()

of Encounrer characters

Returns, the sum of the value< of the qualltlc, Thi s meth od sallshes requireme nt 32 EC3 2

public void showCharacter ( Component componentP , Graphics drawP , Point posP , int heightPixP , boolean faceLeftP ) Displays the character in cO"'PO,,"'IP. with ccn· tcr at posP, wit h heI ght l)
at"Res requirement, 3.2 r C I

pr ivate void setQuality ( Str ing quali tyP , float va lueP ) Prc onditlo ns, qlla/ltyP " a va hd qualir' 'trlng e " the qua ),ty ,nd, . ted by Ih e pM.meter t Vllilltp th e latter t< > = 0.5. oth e rwi$~ sets oal",P to Zero TI,l" method 'aw.he, r~qll1n:n1t.·nt 3 2 2 (lower Im1lt t) llll onZt>ro qUiJhlV value, )

.r

SOl

502

CHAPTER 19 DElAILED DESIGN

6.1.6. ES

The

EncounterCast

Class n e me thod ,pe ,A Jt,o ns for thos inglcton . interfa e

cia ... , af(' given

In

Section 5 of dll s document

6.1.8. AR Area Class This clas< encapsu late< the place in wh ,c h the chJractcrs eXISt , and corresponds to reqUIrement 3 2.AR Inhent ance

6.1.7. FC The ForeignCharacter Class n is

Thi S d.,o;s Inhents (rom

clas. i analogou to Plnycr(l",raclrr. described nex t, and ,s designed to sa tisfy the SR 3.2.FC

GnmtA rra

Attributes,

6.1.8. PC The PlayerCharacter Class This class

pri vate St ring nam eI ; I I corresponding to requirement

,s desig ned to satISfy the requirements 3.2.PC

3 . 2 . AR. 1. 1

Inhcrirance Thl c1asc; Inherits fro m Attnb utes,

private Image i mageI ; II cor r espo nd i ng t o requirement 3 . 2 . AR . 1.2

E'ICOlilllt rCha ra clcr.

private Stri ng [ J qu alitiesI ; II co rr es pond ing to requireme nt

private static final Play e r Cha racter playerCharacterS ;

3 . 2 . AR . 1. 3

pr ivate Vector co nn ect io n HyperlinksI;

This is the si ngkton object representing the player's charac te r.

Metho ds

Methods,

pub lic v o id display ( ) I I shows the area objec t's image on the mo nitor.

public static final Player Characte r getPlayerCharacter( ) ;

public static Area geUrea (String areaNameP )

nis me thod returns play,rCharaclcrS.

return s the area correspondin g to MtaNamtP

according to requirement 3.2 AR.2.2.

6.1.7 The EncounterEnvironment package The classes of thiS package describe th e environment

public static AreaConnection getAreaConnection ( St ring area ConnectionNameP )

In which the game takes place. It is shown in F,gure 19.37.

GameEnvlronment

-..f GameCharacler

GameArea

~

GameAreaConnection

Area

EfiOO' mterErMn.",·. fLe,lI

rC

I EncounterAreaConnectlon ConnectlonHypeftlnk oJ

EncountetEnvlron,icent

FIgure 1'.37 EncounterEnllironment package

CASE STUDY DETAILED DESIGN OF ECUPSE

rerum~ the areJ

object co rTcspo ndlng to ,lrc.1CO""KhoPiNIll1ttP ZI ordr l1g to reqUIrement ' 2 AR 2 2 0,,"((11011

6.1.9. CO EncounterAreaConnection Class This la cncap ulatc.:; the way~ to get rrorn areas to adjacent a~as. It Inh erits (rom ArWCOtltl(( tJOIi and COrTe pond. to requirement 3.2 0

Inhentance This cia" Inhents rTom Gmll(A,rn Co.l ~ "crholl I n the framework package Aunbulc); pr .lv ate Ar ea f irst Areal :

/ I con esp ond lng tor equ l r erne-ot 3 . . CO . 1 . 1

Atlnbutcs:

private Connection connectionI ; 11 the corresponding connection Methods·

The only mean~ngful method is mou s eC li ck ( ) "

6.2 Data Detai led Design There arc no data structures beSides lhoc;c mentioned as part of the ela ~e) 111 e tlon 6 1

19.13 CASE STUDY: DETAILED DESIGN OF ECLIPSE

pr l va t e Ar ea seco ndAreaI ;

//co rr espondLnq t o requir<.'rne n t 3 . 2.(0 . 1. 1

I-Icthods Th~se are acce sors for the attnbute. above

Rdercnce, The lavaDoc for Eclipse IS at http /l "'w\vx hpse org/d cumcnlatlon/ html/ plugln or" eclipse platform .doc Isv/ do reference/api overview -summ ary ,hlm1 ~

6.1.10. EE EncounterEnvironment Class ThiS is the facad~ cia s (or the E"colll1lnE,wlfolHllnll package.

Attributes,

private EncounterEnvironment encounter EnvironmentS; l i the singleton Facade object II {Area name] {Area connection Ii name] {' ' North " I ' ' South " I I I " East " I " West " ] , private String[3] lay o utS; 1ethod, pub l~c

static Encount e rEnvironment

getEncounterEnvi ronme nt ( )

Retutns: enc o un te rEnvironmentS public static S tr i ng{ 3 ] g etLa y o u t{ ) Returns : layo u t S The rema1l1111~ metho d, arc ,pecdl d,n Sett lon 5

,>I

No te to the tudent· Eclipse i a large project, and this ca e study docs not attempt to dcscnbe its des.gn in detai l-merely to provide excerpt from a small example of how detailed de ign IS some times speCified in the ca l' of Eclipse. The co mplete document would be based on the archltect\lrc decomposi tion describ ed preViously It would have a section on ca h of the Plaifo,," , the Java DWc/Ol'm,"1 Ellvlrollmrnl, and ,he Pluglll Dn",'o"m",' EHVlrOHmrnl. \'(Ilthln the Plaifo,," <eClion , It would have a Workspllrr and a Corr ,cClion \'(Iltll1n the Corr "cellon , It would have a RlUllmt( t:C1lOn Part of lilt, lauc.:r IS shovm next.

Platform. Core. Runtime

th" dowment

6,1.11 CH ConnectionHyperlink C lass 11", cia., encapsulate. the wa y ' to Het fWIll area' to adJac..cnt areas It <.orrcspo(1d lO to n: flUlrClnCl1l l 2 C.H Tim da~s Impl ' mcn" the M OlI srLulrlltr Intcrfac t'

Ideally , th" ' C tl o n ould be t",u'd to the Ecll!,'e requirem e nt> Although the re~der 'he Eclip'c documentation C~ n undcraan I the tm e In gencr~ 1 h:nn .. , It ,\ not \rr.llt-;hLl f\\fard (0 IOC~' tc.- lilt"

r

eXilet r feren <" to rl'qulrl'ml~nt~ ,c tlon,

503

S04

CHAPTER 19

DETAILED DESIGN

All maU oodo

am1lc

1\

IT' ,

Platform

Plugin s.ngIolon 1

getlnstance() getPluginPrelerences() /

/ /

/

/

getCommandLineArgs() gelPlugln()

,, ,, ,

/

Eclipse command line opIiOnS •• • by Idoolificatlon

\ ~

r-_-',I'-----,

Palh

Preferences

Figure 19.38 Core classes of Eclipse

PI.ifo,," Corc.R""'i,", is o rganized around a smal1 set of core classes, as sho wn," Figure 19.38 . The classes in F'gure 19.38 are described next.

Features include :

• the platfo rm regIStry o f instal1ed plug·ins

PLA TFORM CLASS

• the platform adapter manager

The fol1owing is from the Eclipse ja"adoc
I/ Th e centr a l c l ass of the Eclipse Pla t form IIRun time •

•

• the platform log • the auth o rizat io n info management

The platfo rm is in o ne o f two states, ""IH'"9 o r 1101 num iHg , at all times. The o nl y wa ys to stan the platform running, o r to shut it down. are o n the boo tstrap BeolLoad" class.

•

pu blic f i n al c lass

Pl.tfo~

e xte nd s Obje c t

(

In other words, the methods that sta" or shut down the platform arc found in the class

p ubli c st a t ic ge t Instance ( ) () - n o c ontent

Be.d.oad".

-. .. }

publi c final cla ss Pl.ttoJ:a extends Object

Thecentral cla.ss of the Eclipse Platform Runtime, This class cannot be instantiated or subclassed by clientsl al1 functionality is provided by static mel hods.

If a clns is 10 haw no instances, all ilS methods an: made Slatic.

Code in plug . ins will only observe the platform in the running state. The platform cannOt be shutdown from inside (code," plug-ins have no access to

BoorLoad,,). •

•

•

•

public static Plugin getPlugin(StTing id ) R~rum the plug-in runtime object for the identified plug. in or null if no such plU8-in can be found. If the plug-in is defined but not yet activated. the plug-in will be acrivated before beong returned.

SUMMARY

Parameters. Id - ,he unIque Idenllr.er of ,he desl",d plug -II, (e g , "<-om .example .acme") Re, urns_ ,he plug-on run"l11e obJec" or null •

We have provided Just a '.s'e of the beglnnong of the Eclipsc design . Th, example provIdes a

sense of how documentatIOn reads that

I

generated (via Javadoc) from source code comment An advantage of uSIng Javadoc is that it lend, to ren'liUn up-lo -da te a long as ,he progr.Jmmcr comments the code accordmg to

the standard

19.14 SUMMARY DetaIled de Ign IS an actiVIty In whIch components su has clas c, and me' hods are denned

In

enough de,aol

so th at implementation ca n comme nce We Start \\1 1th the domain lassc!t from requlremcnb analysi and add the necessary deSign classes to complete the design DeSign patterns arc Introduced as reqUIred to Implement any comm onl y n.:curring deSign prob lems.

Dunng detailed design, l!lterface functions \ ../ith spec ified names, parameter types, and rerurn rype, arc

de fi ned The program eicments USi ng these func'ions can [hen be designed wllhou, haVing '0 know how ,he fu nctionality I Implemented-all ,hey need '0 know IS how '0 usc [he Interface Th,s faclllla ,es ,he develop me n' of each design clement epara,dy. The Facade deSIgn pattern lone way of prov,d,n g an intcrface to

(l

package of clas cs

When designing o bjec, -oriented software. severa l wc ll -esta bli,hed de>lgn pnnclpies help en,ure a robust and extenSIble design : Slngle · re

Invariants: The values of q ua lVal ueI(J are >= 0 * @author Er ic Braude , Tom VanCour t • @ve rsion 0 . 2

*/

575

576

CHAPTER 22

PRINCIPLES OF IMPLEMENTATION

publ i c cla!!. Encounte rChara cta r e xte nds Gam. Cha r a cte r

{

/ ** Total quality point s at initialization . * / private static final float QUAL_TOTAL_ INIT= lOO . Of ; / / Symbols used when other classes ref er to specif ic qualit ies . / ** Symbol for o n e of a character ' s qu al i ties * / public stat ic final String QUAL_CONCENTRATION = " concentrati on" ; / ** Symbol for o ne of a character ' s quali ties * / public static final Stri ng QUAL_ INTELLIGENCE = "intelligence " ; / ** Symbol for o ne of a character ' s qualities * / public static final String QUAL_ PATIENCE = "patience" ; / ** Symbol for o ne of a character ' s qualiti es * / public static final String QUAL_STAMINA = "stamjna ', ; / ** Symbol for one of a character ' S qualities * / publi c st at ic final String QUAL_STRENGTH = "strength ' , ; / * * Quali ties that each enc ounter character posesses Req : 3 . 2 . EC . 1 . 2 * / pr ivate static final String[J qualityTypeS = ( QUAL_CONCENTRATION , QUAL_STAMINA , QUAL_INTELLIGENCE , QUAL_PATIENCE, QUAL_STRENGTH )

/*

INSTANCE VARIABLES

*/

/ ** Values of the qualities Requirement 3 . 2 . EC . 1.2 */ private float [1 qualValuaI = new lloat[ qualityTypeS . length J;

/ ** Name o f the GIF file containing the character ' s image .

* The

* *

*

character i n this image is assumed to be facing left . Select this character ' s height , relative to heights of other charac ter s , by padding the top and bot tom wi th t r anspar en t pixe Is . No padding gives the tallest possible character .

*/ pr ivate Strinq imageFileNa-eI

= null ;

/ * CONSTRUCTORS * / / * * Allocate ini tial total quality po ints equally among the qualit ie s.

*

Requirement : 3 . 2 . EC .1. 2 (quality value initialization) */ protected EncounterCharacter () ( super() ; for ( int i = 0; i < qualityTyp4lS.1ength; ++1 ) qualValueI [lJ QUAL_TOTAL_INIT / qualityTneS . len'lth : &

)

CODE USnNGS REFERRED TO IN THIS CHAPTER

/** Construct a new character using the given name and *

Requirement: 3.2.EC.l.l (character naming ) * @param nameP Printable name for t h e character . *@param imageFilep * character image.

image f i le.

Filename, relative to document base, .... for

*/ protected EncounterCharacter ( Str ing nameP, Str ing imageFileP ) {

tIlia () ; •• tNama ( na=eP ) ;

ip'g8Fi.leNam er = im,qeFileP;

}

/ ** Construct a new character using the given name. *

Requ ireme nt: 3 . 2 . EC . 1 . 1 (character naming ) * @param nameP Pr intable name for the character . */ protected Encount erC hara cter ( Str ing nam eP ) { this ( oaceP , null ) ; }

/ * METHODS */ / *. Requir eme nt 3.2.EC.3.2: " Configurability of £ncounterc haracter * quality va lues. ' , * Synchron i zati on holds qualit yVal u eI constant even wi th o ther threads * running. *

SDDreference: 6.1.2.1.1 * Invar iants: see the class invar i ants *

Preconditions: qualityP is in qualityTypesS(}

* * *

AND qualityValueP> =O AND qualityValueP < = the sum o f the quality values

Postconditions: qual i typ has the value qualityValueP

*

AND the remaining quality values are in the same pr oport ionas pr ior * to invocation, except that val u es less than some tolerance are * zero. • @param qual ityP Quality whose value is to be adjusted . * @paramqualityValuePThe value t o set this quality to . * / public synchr onized voi d adjustQuality (String qualityP, Iloat qualityValueP) (

/ / Value of the quality to be changed float qualityValuaM = qualValuaI[ indexOf( qualityP) 1 ; / / Save the sum of the values float originalSnmM = ."mOfQualitiu () ; / / pc Set the stated quality to the desired amount , adjusted to the // threshold value . HtQuality( qualityP , qualityValuaP) ;

// pc If the caller adj u sts the only n o n-zero quali ty value , / / divid e the adjustment a mo unt e qually among all other qualit ies .

S77

578

CHAPTER 22

PRINCIPLES OF IMPLEMENTATION

if ( originalS"mH == qu a lityValue H ) {

float qualityDiffEa ch = (origi nalSumH - quali tyValue P) / (qua li tyTyp e S . length - 1) ; for ( int i = 0 ; i < qualityType S . length ; ++ i ) if ( ! qualityTyp e S[ i ] . equal s IgnonC. . e ( qud i tyP ) ) se tQuality ( qu a lityType S t i l , qua lityDiffEacb ) ;

}

else ( / * Co mpute factor ( "pr oport i onM" ) by which all other qualities mu st * change . * Example : ifthevalueswere 1 , 3 , 5 (i . e . sum9) , and the first quality * is ch anged * fro m 1 to 2 , th en "" 3 " and " 5 " chang e from 8 / 9 of the t otal to 7 / 9 * of the total , so each should be mult ip l ied by 7/ 8 , i. e . , by (9 - 2 ) /

*

(9 - 1) .

*/ float proporti on)( = (originalS"mH - qualityValueP) / (original.S"mMquali tyVal.ueM) ;

l /pcAdjusttheremaining q ualities , retainingtheirmutualproportion for ( int i = 0 ; i < qualityTypaS . l.ength; ++i ) if ( ! qualityTypaS[i] . equalslqnoreCase( qualityp) ) setQuaHty ( qualityTypeS [i] , qualValueI til • proportion)() ; }

}

/ ** Get a copy of the list o f names of qual ity values . * @retu rn working copies of name strings representing qualities . */ public static String[] getQuaHtyType. () (

String [] returnListH = new String [ qualityTypeS . length ] ;

string array . for ( int i= 0 ; i < qualityTypeS.length ; i ++ )

/1 Copy the //

Copy each strin g .

returnLiatM(i] :: new Stri.nq( qualityTypeS[i] ) ;

return returnListM ;

// Return the copy .

}

/ * * Returns the value of the specified qua lity . * Precondition : qualityp is a valid membe r of * @param qua lityp

* @ret urn

The quality we want the value for . The value of the specified quality .

*/ pub 1 ic float getQual.ityValue ( String qualityP ) { ret urn qual.Valuer ( inMxOf ( quali tyP ) ]; }

quali tyTypeS (]

CODE USTINGS REFERRED TO IN THIS CHAP I ER

1** Quality va l u e s below th i s threshold are set to zero to avoid having

*

the game go on f or an indetermi n ate a mo·unt of time . *

Requ i r e me n t : e . g . 3 . 2 . EC . 1.2 (lower limit on n on - zero quality * values ) * @return Toleran ce value

*1 ataUc!ina! float g8tTolerance () { return O.5f ; )

1** Retu r ns t h e ind ex of the specified quality . * Precondi tio n: q ual1tyP is in qua 1ltyTypeS[J , give or take • c api t aliz a t ion . • @param * @re t urn

q u alityp The quality we are searching for . The quality index .

*1

private stati c i n t i n dexOf( Stri n g qualityP ) {

int returnlndexM= -1; II Default to "missing " value . f o r ( int i = 0; i < qualityTypeS . length ; ++ i ) I I Sear ch qual i ty name table . if ( qualityTypeS [ i 1 . equals IgnoreCase ( qualityp» I I Quali ty name match? { returnlndexM = i ;

I I Note the i ndex value .

break; )

return returnlndexM; )

1** Set d ef a ult ma x imum allowable number of characters in names of

* char acters .

*

Re q ui r ement : * @r eturn

3 . 2 . EC . l . l (limit on character name length ) Maximum number of characters allowed in a char acter name

*1 protected int m'xNumCharslnName ()

{ )

return IS;

I H Set a quality value without regard to the values of other qualities .

* Tru n cate

• • • ' •

any value below the threshold value down to zero . Synchronization prevents cha n ges to qualityValueI while other threads are using it . Requirements : 3 . 2 . EC . 2 (lower limit on no n- zero quality values) ,

Precondition : qUillHYP is a valid me mb e r of qualieyTYP"sll

579

580

CHAPTER 22

PRINCIPLES OF IMPLEMENTATION

* Postcondition:

* *

* @pa ram * @param */

Quality values are greater than tolerance orareD .

qualityP The quali ty to set the value of . valueP The value to set the quality to .

public synchronized void

setQuality( String qualityP , float value P )

{ i f ( valueP < gatTolerance () )

qualValueI( indexOf( qualityP) 1 = O. Of ; e lse qualValueI( i ndexOf( qualityP) 1 =value P ;

}

/ ** Display the char acter * Requirements : 2 . 1 . 2 . 1 (character displayed in game Area ) , * 3 . 2 . PC.1 (c haracter image selection ) , * 3 . 2 . PQ . l (c haracter image in quality update window) * @p aram compP UI component in which to draw the character * @param drawP Graphics co n text for doing the drawi n g . * @par am posP Pixel coo r dinates within compP for the center of * the image . * @pa ram he ightP ixP Desired image height , in pixels . * @par am faceLeftP true if character faces left , < tt> f alse if faces right . *

*/

public void showCharacter (Component compP , Graphics drawP , Point posP , int beightPixP , boolean faceLeftP) { if ( ;m " geFileN"meI == nu 11)

{

/ / No image file name . Pr int the character name instead . dravP . aetColor (Color . .... genta) ; / / Normally a visible color .

=

FontMetrica fm drawP. qatFontMetrics () ; dr • .,P . drawString ( qa tNeme () ,

pos P . x - fIR . otrin<J1fidth (getNne () ) poo P . Y - fIR. g e taeigbt () / 2 ) ;

/ / Pr int the name , centered /2 , / / at the character location .

)

e lae {

/ / File name was provided . Draw the image file . Image chImeg.

int int int

= CompP . q _ tToolki t

() . q_ tlmaq. ( jm. qaFile Nep.I ) ;

Im"ge"idth = cblmoge. getWi dth ( ChUpP) ; / / ;m" g e Be igbt = cbI_ge.ge taeigbt( compP) ;

Raw size of the image .

acale dWidth ~ I m"ge"idth· b e igbtPixP / ;m"ge Beigbt ; / /

Scale width same as height . / / Assume that the normal image faces left . De'c ide whether to reverse the image .

EXERCISES

if (

fac:eIAftP )

Draw the image a s g i v e n , h eightPixP/2 , / / scaled a nd ce nt e r e d .

dravP . dravImaqe ( chImaga ,

//

po.P . x - acaledWidth/2 , po o P . y pooP . x + ocaledWidth/2 , po s P . y + heightPixP/2 , 0,0, i·.ge Width-l , i mage Re ight-l , compP) ;

el s e dr ••P.drawlm.aqe( chI.aage ,

1/ Draw the image revers ed ,

pooP.x + acaladNidth/2 , pos P . y - heightPixP/2 , / / pooP . x - scaledWidth/2 , posP . y + heightP i xP/2 ,

scaled and cente r e d .

0 , 0 , im e qeWidth-l, jmage Re i ght - l , compP) ;

}

}

// End o f showCharacter . / ** Computes the sum of the quali ty values . * Syn chr o niza tio n ma k es sure that another thread won ' t change * qual ityValu e I * whi le t h is th read i s p art - way through computing the total . *

Requirements: SRS 3.2. EC

Design: SDD 6.2. 1

Invariants: <01 >

encounterCharacterS contains all objects of this class

The values of qualValueI [1 are >= 0 * *
Design issues:
*
Character images are switched freely between right- and * left-handed forms. That means that sword fighter swill swi tch * hands; scabbards will swing back and forth; scars, tattoos, etc. * will move around, hair styles will f lop back and for th, etc. * It's good enough for now, though. *
* @author Er ic Br aude, Tom VanCourt *@versionO.2

*1 public cl •••

EncounterCharacter extends GameCharacter

{

1** Total quality points at initialization .

*
Requirement

3 . 2 . EC. 1. 2

*/ public atatic tlnalllo.t OUAL_TOTAL_INIT

= 100. Of ;

// Symbols used when other classes refer to specif ic qualities.

/** Symbol f or one of a charac ter ' s quali ties * / publ.1c ataticflnal String

OUACCONCENTRATION=

"concentration";

653

654

CHAPT1:R 26 UNIT TESTING

/ **

Symbol for one of a character's qualiti e s */ public static lind Str ing QUAL_INTEL LIGENCE = "in te lligenc e " ;

/ ** Symbol for one of a character's qualities * / public static lind Str ing

QUAL_PATI ENCE =

"pat ience" ;

/** Symbol for one of a character's qualities * / public static final St ring QUAL_STAMI NA = "stamina" ; /** Symbol for one of a character 's qualities * / publl.c static final String QUAL_STRENGTH: "strength";

/ ** Qualities that each Encounter character possesses.

*

Reg: 3.2. EC. 1. 2

*/ protacted static final Str ing [1 qualityTypeS = (

QUAL_ CONCENTRATION,

QUAL_STAMINA,

QUAL_INTEL LIGENCE,

QUAL_PATIENCE,

QUAL_ STRENGTH

) ;

/** Root directory for graphics files. */ static find String

FI LE_ROOT

= "edu/bu/braude/SWEngExample/";

/*

INSTANCE VARIABLES * / / ** Values of the qualities.
Requirement 3.2. EC. 1. 2 protectad float[ 1 qualValueI : n•• fIoat [qual it yTypeS . length 1 ;

*/

/** Quality values before the last engagement *
Requirement: 3.2.AR.4.6

*/ protectad float [ 1 oldValueI = n•• fIoat[qualValueI.lengthl;

/** Name of GIF file containing the character image. * The character in this image is assumed to be facing left. * Select this character's height, relative to heights of other * char acter s, * by padding the to~ and bottomwith transparent pixels. No padding gives * the tallest posslble character.

*/ prohct.ad String imageFileNameI: null;

/** Displayable image for the character. Initialized when used. */

pri.Yata Image chImage I = ma.ll;

/*

CONSTRUCTORS

*/

CASE STUDY: ENCOUNTER VIDEO GAME

655

/ ** Allocate initial total qualitv oints

. . "
Requ irement . 3 2 E - p . equally among the quall.t:les. "/ . . . C.1.2 (qual:ltyvalue initialization)

~uct.1

{

EncounterCharacter ()

Lupn ( ) ;

for( int i = 0 ; i < quali t yTypeS . length· ++ i) qualValue I til = QUAL_ TO TAL_ I NIT / qu'ah. tyTy peS . length; . saveQual:ltyValues() ; }

{"* Construct a new character using the given name .
Requ:lr emen t : 3 . 2 . EC . 1 . 1 (char act e r naming ) * @param nameP Printable name for the character .

*/ Encount erChar ac ter (St ring nameP ) this (nameP, null ) ;

protected {

}

/ ** Construct a n ew character using the give n name and i mage file . *
Requirement: 3 . 2 .E C.l.l (c haracter naming ) * @param nameP Pr intable name for the character . *@param imageFileP Filename , relative to docume n t base, * f or the character image file .

*/ protect.d {

Encoun terChar acter ( Str ing nameP, Str ing imageF ileP )

thia ( ) ;

setName (nameP) ; imageF ileNameI =

FILE_ ROOT +

imageF ileP;

}

/ * KETHOOS * / /** Adjust qual ity values , normally retaining a co n stant total. * Synchr o nizat ion holds qualityValueI constant even with other * threads running . ..
Invariants: see the class invariants ..
Preconditions : qualityp is in qualityTypesS [1 .. ANO q ualityValueP >= 0 .. AND qua lityValueP <= the sum of the quality values *
Postcond itio ns: qualityp has the value qualityValueP .. AND the rema ining quali ty values ar e i n the same proport ion as pr ior to .. invocation , except that values less tha n some tolerance are zero . ..
SOD : 6 . 1 . 2 . 1 . 1 ..
SRS : 3 . 2 . EC . 3 . 2 : " Conf igurab ili ty of Encounter character qua li ty .. values. " "@param qualityp Quality whose value is to be adjusted .

I

656

CHAP! fR 26 UNITTfSnNG

* @param

qualityValueP

The value to set this quality to .

*/ public ayncbronizad void adjustQuality (Str ing qualityP, float qual i tyValueP) { / / Value of the quality to be changed float quali tyValueM = qual Value I [indexOf ( qual i tyP) J ; / / Save the sum of the values float or iginalSumM = sumOfQualit ies ( ) ; / / Set the stated quality to the desired amount, / / adjusted to the threshold value. setQuality(qualityP, qualityValueP); / / If the caller adjusts the only non-zero quali ty value, / / divide the adjustment amount equally among all other quali ties. if (or iginalSumM == quali tyValueM ) {

float quaU tyDiffEach = (or iginalSUmM - quali tyValueP) / (qualityTypes.length - 1); for(int i = 0; i < qualityTypes.length; ++i ) if( ! qualityTypeS[ iJ . equalsIgnoreCase ( qualityP ) ) setQuality(qualityTypeS [ iJ, qualityDiffEach ) ; } ala. {

/* Compute factor ("proportionM" ) bywhich all other qualities must change. * Example: if the valueswere 1,3 , 5 (i . e . sum9) and the first * qualities changed from 1 to 2, then "3" and "5" change from B/9 of * the total to 7/9 of the total, so each should be mul tiplied by 7/B , * Le., by (9 -2 )/(9-1).

*/ Coat proportionM = (or iginalSumM - qualityValuep ) / (or iginalSumM - qualityValueM ) ; / /Adjust remaining qualities, retain i ng their mutual proportion for(Uiti=O; i
/** Get a copy of the list of names of quality values. *@returnworkingcopiesofnamestringsr eprese ntingqual . t ' */ ~ ~es public aUtic Str ing[ 1 getQualityTypes () {

.

CASE STUDY; ENCOUNTER VIDEO GAME

Str ing ' [] r eturnListM = // Copy the s t rlng . . array . IIZ1I St r l.ng [ quaIl tyTypes . length J ; for(1Ilt i = a'; i < ~ali
/* * Returns the value of the specified quality . quali tyP is a valid member of qualityTypeS [J *
precondit ion: * @param qualityp The quality we want the value for. • @return The value of the specif ied quali ty .

*/ pablicf!olt

getQualityValue (St ring qualityp)

(

return qualValueI [ JndexOf( qualityp ) ] ; }

/** Quality values below this threshold are set to zer o to * avoid having the game go on for an indeterminate amount of tim e . *
Requirement:e.g.3.2.EC.l.2 ( 10werlimitonnon- zeroqualityvalues ) *@return Tolerancevalue

*/ atat.icflndfioatgetTolerance () { HturnO. Sf; }

/** Returns the index of the the specif ied quality . •
Precondi t ion: qual i tyP is in qualityTypeS [ ] , * give or take capitalizat ion . *@param qualityp The quality we are searching for . *@return Thequalityindex.

*/ protlctlcl.tatic int

indexOf ( Str ing qualityp)

(

//Default to "missing" value. iIIt r e tur nlndexM = - 1 ; // Search quality name table and not e t ,he i nd ex value. fo,. (illti =O · i < qualJtyTypes . length; ++1.) 1f (qua l1ty~s [i] . equalSlgnoreCase(qualityP» { return lndexM = i; } zoetum

}

returnlnd e xM;

657

658

CHAPTER 26

UNIT TESTING

/ ** Set default max imum number of characters in names of charact e rs . *
Requir ement : 3 . 2 . EC. 1 . 1 (1 iroi t on char acter name l e ngth) *@return Maximum number of characters allowed in a character name

*/ protect odint maxNumCharslnName () {

return

15 ;

}

/ ** Preserve the current quality valu es . * / publl.csynchronizedvoid saveQualityValues ( ) (

(i nt i=O ; i < qualValueI . len gth ; i++) oldValueI [i) = qualValueI [i) ;

for

}

/ ** Set a quality value without regard to the values of other qualities . * Truncate any value below the threshold value down to zero . * Synchronizatio n prevents cha nges to qualityValueI while other * threads ar e using it . 3 . 2 . EC . 2 ( l ower limitonnon- zero qualityvalue s ) , *
Requirements : *
Precondition : qualityp is a valid member of qualityTypeS [ ) *
Postcondition : Quality values are greater than to l eran ce or are O.

*

*@param * @param

qualityp valueP

The quality to s e t the val u e of . The valu e to set t h e qua l. ity to .

*/ publicayncbronizeclvoid setQuality (Str ing qualityp, Coat valueP) { i t (valueP

< getTolerance ( ) ) qualValueI[ indexof (qualityp») =O . Of ;

.1_

qualValueI [ i ndexOf (qualityP) I =valueP ; }

/** Computes the sumo f the quality values . * Synchronization mak es sure t h at a n other thr ead wo n' t c h a n ge * qualityValueI wh il e th is th r ead ispart -way thro ugh computing the * total . *
Requireme nts : 3 . 2 . EC . 3 . 2 (proport ions among quali tyval ) * S RS 3 .2. EC .3. 1 Ll.vl.ngp0l. ., . nts ues , * @return The sumof t h e player ' squalities , a value 0 or great */ er . publ1cayl>cbronlzodfloat sumOfQualit ies ( ) { float sum!! = O. Of ;

CASE STUDY' ENCOUNTER VIDEO GAME

forCint i=O; i
} / / end of EncounterChar acter

26.5.2 Unit Tests for the Encountercharacter Class ote to the Student: The format of this docllm ent is derived from the IEEE Standard lor Software Test Docu mentation This document applies to the tes t· ing 01 one class. JUnit was not lIsed in tillS case but could have been .

For si mpl,ci ry , thi s unit re t includes teS t data with the method . Normally , ho,,'cver, the Input data and the expected output are rc · tri eved from a Ale .

3. Test Procedure Specification TI, e unl! test' for E"co",,'rrCbnfllCltr arc IOltiated by execut ing the ",mil O method of EncounlrrClJn rncttr

The parameter su pplied to mni" O speCifiC the fl le

UNIT TEST FOR THE

to wh ich th e rc ult are wnncl1

ENCOUNTERCHARACTER CLASS

1. Test Design Specification The unit te~l (or Eli collnlerClJnraclrr co n

1St ....

of rwo

public methods as follows.

This is a si mple procedure . H owever, the procedure becomes can iderably more complex when sourCe flies and u er interaction arc involved For example , this will be the case in unit tes tin g the class E" o""'trG",",

ItSIE"co""lrrOlflracltrM"hod.O teSt- cach of the methods in rurn

ItsIE"co""'trChararl,, 1a sO test<
4. Test Results Documentation The test re lilt documentatio n o n"5r, of the te t log , tt·
The,c methods ca n be executed by E"co",,',,Cha"",d, mamO method or by an external ob)cLl

4.1 Test Log

2. Test Case Specification The i.est cases for £"(0""'''( /",,"(/tr are bu d t

1111 0

InIEHco""'trCha"'
IrP( 1us.(J

Till I< an ac ount of the tt' 1', result. eX' l1lrle helow

et, the

65.

660

CHAPTER 26

UNIT TESTING

1l\1~ IS co ntained in RIc Etlcolmlcr bllradt,_

4.2 Test Incident Report This Includes any occurrences or noteworrhy ~vc:nrs that occur during te ting Sec the exam-

ple below

In

file E",oulllrrCl}fIrtlClt,_Ttsl_

1n""Jntf_da)' _molll" Jcnr doc

4.3 Test summary Report This

IS

contained in fi le

f" co,m l,rCharael"_T",-Sum'M'Y_R,porCdQ)'_ lI1otllh-ywr. doc EX > > > GetChorocler T est I: nom,nol vo lue ««< querry < - - Obtained querry < - - Required > > > > GetCharactcr Test 2: Outside porame· ler values « « < ddoultNamc < - - Obrarned ddaultName < - - Required > > > > EncounlerChoractcr Test 3: limil po· rametcr values <

< < <<

1234567890 12 345 < - - Obtained 1234567890 12 345 < - - Requ ired Expect one name

rOT

each charactcr

Querry defaultName 1234567890 12345 » » i ndexOfO Test I: valid quolity nome ««< Actual tntc:gcr

=

I

nominol volue

««< Ac tual Ooal = expecled Aool. » » selQuolityO Tesl 2: nominal value

Tnl_Lo!l_dllY _molllh-J,tnr doc

Thi s IS co ntained

» » setQuoIIlYO Test

««< Actual Aoal = expecled Aoal. > > > > adj ustQuahty() lest 0: verify that values add 10 100 « « < AClual Aoat = expected floal. > > > > adjustQ uali tyO lest 1: ve ri fy values sum to 100 afrer adj u l,ng « « < Actuol Aoat = expected Aoar. > > > > adjusrQua l,ty{} tesr 2: verify values adjusred as commanded « « < AClual floal = expected Aoar. » » adjusrQuo li ty() tcS! 3: verify low va lue reve rts to zero « « < AClual Aoat = expected Aoal. > > > > odjustQuality() ICS! 4: veri fy values sum 10 100 ofrer odJusring < < < < < ACluol Aoat = expected Aoat. C lass test : » » Class ICS! ge-aq-so « « < 100.0 < - - Ob lained 100.0 < - - Required » » Cl055 test ge·aq·aq-gq ·so: part I «< « 20.9876 < - - Obtained 20.9876 < - - Required » » Closs test gc ·aq-aq-gq-so, part 2 «< « 100.0 < - - Oblained 100.0 < - - Required » » Class lest for Ihe invariant '_q uaIValue [iJ >= 0'« « < true < - - Obta ined tn'e < - - Required The leS! log example doc:s not show failed t~ts. These can be delailed in Ihe log, transmitted 10 a separale fi le, and con ge nerale monilor leXI.

expected in teger.

» » lndexOfO Test 2: volid qualilY name ««< Actual Integer = expected integer.

Example of a Test Inc,dent Report ( eelion 4 2 of the Pe"onal Soflware Do ume nrion ): f"co.,.;"

Cbarael"_T" '_/lIcidtlll_26_Jul_199. dO<'

CASE STUDY: ENCOUNTER VIDEO GAME

Th( test was allemptcd With version 7.2. I of &. o"."rCbarael" using version 2.3 of the TrslUliiilits package . On th e first try , the test fa ded to run . We think that t his wa due to the fact that we did not really have version 2.3 of Ttl/liIiiilit! . When we ~Ioaded this package , the test ran without Incident. This is a good place to mention mistakes made dunng testing. These are particularly prevalent when user actions are required, and it is impractical to rerun the e ntire test.

Example of a T est Summary Report (Section 4.3 of the Personal Softwa re Docume nti o n): Elleoll.'''' CbaraeICT_T lSI_Summary _26_111'_' 999 doe This test was executed by Joh n Jones at 2:00 P.M. using release 1. 1.6 of Sun's virtual machine . Subject to the anomalie in the test incident report , the results were 100 percent pass o n the bui lt -in unit t<st methods. These met hods were inserted by

E. Braude in version 6.5.2. They are due to ~ expanded in later versions of EHeO"HltrCbaraCltr. Example of Unit Test Source Code: The fo llOWi ng code, for the EHcowHlrrCharaCltr class, includes self- test methods. The class TtslEx
listing 26.11: Control for testing EncounterCharacter

1** To test th is class

* @param

argsP destinatian .of methad test lag, class test lag * respectively *l public static void main ( S t ring [J ar gsP ) {

II Default files an which ta write test .output

run tests Str ing methadOutputF ileNameM = "methodOutput. txt" ; Str ing classOutputF ileNameM= "c lassOutput. txt" ;

i f (argsp !

= null

&&

argsP . length == 2)

&

I I use defaults if input

• lmpraper { methadOutputF ileNameM = argsP [OJ ; classOutputFileNameM = argsp[lJ ;

}

I l l . EXECUTE TESTS WHICH DO NOT REQUIRE HUMAN INTERVENTION I I Test methads individually , then test class try

{

testEncounterCharacterMethods(methodOutputFil eNameM);

661

662

CHAPTER 26

UNITTESTING

testEncounterCharacterClass(classOutputFileNameM) ; } catch (IOE xc e ption eP) { System . out . println (eP) ; }

//2 . EXECUTE TESTS WHICH DO REQUIRE HUMAN INTERVENTI ON Frame [) imageTests: { // Display test cases new testCharacterImage ( // Missing image new Enc o unt erChar acter ( " GuyWi thNoImage" , null ) ) , new testCha ra cterImage( // Image is present new EncounterChar acter ( "E lena ", " e lena . gif " ) ) } ;

for( i nt i = 0 ; i < imageTests . length ; i ++) (/ / Display each t est window image Tests [i) • setSize (400 , 250) ; // Adequate size for char acter imageTests[i) .setVisible( true ) ; imageTests[i) . show( ) ; }

try {

// Let user examine windows Thread.currentThread() .sl eep(30*lOOO ) ; } catch ( Exception exc) { }

for ( int i = 0 ; i < imageTests.length ; i++) imageTests[i) . dispose();

// Shut the windows

System.exit(O ) ; }

/ ** Tests this class by executing its methods in combination * @param destinationP Location to write results * @exceptio n IOException I f there's a problem opening or accessing * destinationP

*/

Class testing is covered systematically in Chapter 27. It consists largely of testing

combinations of methods The code testing EncOImrtrCbarncftr is given in the cas< study th
26.6 SUMMARY Unir .r"ring ' e IY J fte ' f is conducted by softwa .. develop<" either In conJ'unction w'I th or .1m m ed lat I . a Unit 0 code. Units are typically Ih< methods and cla"es of t L • soft B L L r Imp <menll ng ,,wa.. . Ot" W",re b · d bl k b methods are utilized. ox an ac ox

EXERCISES

Thl! Ilrs! tl!P in unot testmg is Identifying units and dl!termining what they arc intended to do. This comes from one of several sources, the SRS, the SOO . or else a motivation tOO minor to specify in the DO. For methods arising from design, we may not possess explicitly stated requirements against which to pl!rform tests. A systl!matic approach is required to effecti vely implement unit testing. In this way, as man y errors as possibll! at as serious a level as possi ble can be d iscovered within a practical time period and usi ng a prac tical amount of labor. The Arst ste p is o rga nizing the testing-typicall y methods are tested Arst, followed by classes and packages. The extent of testing should be considered and defi ned in advance. Test cases are selected from one or more categories of tests, both fro m no nnal ex pected operation and those judged most likely to fail. Stopping criteria are established in advance; these are concrete conditions at which point this particular testing process will hi! considered done. Depending on the problem space of the software , there is ofte n a set of test data that is pecific to the application . If applicable, obtaining and usi ng this data must be planned . Unit testing is typica lly conducted by deve loper , as they arc the most fa miliar with the structure a nd organization of the code under test. H owever, un it testing is sometimes conducted by a separate organizat io n such as QA because of their object ivity . Th is requires extra time fo r the new o rganization to learn the software desig n so they can successfully executed the tests . As with other phases of development . metrics are co llec ted during un it testmg. Metrics collected include number of test cases, number of tests per test ty pe , a nd percentage of fai led teSts. There are several d iffere nt types of white box and blac k box testing metho do logies empl oyed during UOit testing. White box methods include statem e nt coverage, branch coverage, and path coverage . Black box methods include equivalence partilionin g and boundary va lue analysis . When testing the methods o f a class. a strategy is required to ensure proper test coverage. Humphrey recommends u ing a checklist that includes Ite ms such as usi ng no m1al parameters, parameters at their boundaries, illegal values, handling of error conditions, path coverage, loop termination , timing, and hard,,'are dependencies. After the individual metho ds of a class are tested , the class as a whole is tested . All of the class methods are tested in combina tio n. Th is is because the methods of a class are freque ntl y interrelated as they may alter the values of common class attributes. Focus i placed o n eque nccs likely to be comm o nly used and sequences that appear most likely to contain defects. If an ohject of a class transitions th roug h several states, s!ate·based testing is emp loyed . An effective method fo r performing unit testing . a nd to build q uality IO to a n Impleme ntation, i to specify the tests that an implementation must pass btforr wri ting the code After " 'fi ting a te t, one adds to the Implementation until the test succeeds. This IS called ',s ,·dr",,,, dwt/op,""" (TOD ). T OD IS ofte n associated wi th agile developme nt, but it is usefu l for a ny deve lopme nt p rocess.

26.7 EXERCISES t. In your own words, d escribe t he difference between white box and black box te ting . Why is each Important and ncccss ary ~

2 Why do you think unit lesting is u,ually co nduc ted by lhl' d~vcloper ,vho Impleme nted the unit] 3 a

What is eqUiva le nce pa rt lt ionlng~ \~hy I It Im portant to partitIOn th e te t ,po e into eqUivalence cla sses ~ rlease usc your own wo rd, in re<ponding

b For lhe followll1 /l fun cll o n, de "be five d iffe re nt les t a,cs Jnd for ca h des nbe the type 01 test case II represents The applica tio n i, ha,cd o n Myer, tn ang le prohlem [5 ).

663

6~

CHAPTER 26

UNIT TESTING

Il x, y and z are the lengths of the sides of a tr iangle . This funct io class if ies the Iitriangle and returns either ' ' scalene " , , isosceles" (two sides

Il equal) or "equilat eral "

(all sides unequal ) ,

( all sides equal) . If x, y and z don't

form a tr iangle

II (Le. either (a) x, y or z is <= zero, or ( b) ( x +y ) < z) the null string is returned IIAssumption: x,yandzareinascendingord er ( i.e. x <=y <=z) soyou do not need

li to test for this char. triangle ( int x, int y, int z) { •

•

•

}

4. Explain why testing every line of code for correctness (i.e., 100 percent statement coverage) is generally insufficient for ensuring that a program is bug-free . Give an example of a defect that can go undetected by tests that have 100 percent statement coverage. 5. Why is path coverage a stronger form of testing than statement coverage7 Give an example of a defect that would be detected by path coverage but not by statement coverage. 6. Draw a program control graph for the method adju' IQuality() of listing 26 .4 in this chapter. What is its cyclomatic complexity' Explain your response .

7. Write the code for a class Accou"t with attribute balan", accessor methods, and method add() . Assume that Account has states Sound, Empty, and Arrears, and that these are implemented using the State design pattern . Write a complete set of unit tCSlS for Account, including statc·oncnted tests.

8. In test·first development, why is it imponant to execute a unit test to ensure that it fa,l s before the code it is testing is actually written ]

9. You intend to implement a Recta"gl, class using test-first development . Suppose the class is defined during design with the following characteristics, • Constructor with parameters length and width • Methods getL..:ngthO and getWidthO to retrieve length and width • Method to calculate area of rectangle Write. unit test class to test the as yet unwritten class Rt
BIBUQGRAPHY

unit Tests Perfoml full unll te ts on two signi fica nt methods of your applica ti on. State how long individuals and th~ whole team spe nt o n de velo ping eac h part of these tests. and how the proce s yo u used could have been improved. Evaluation criteria, ( I ) Degr~e of clarity of th e plan (2) Ext~nt to wh ich the plan and test include all relevant aspects of the unit tests (3) Realism of the self·evaluatlon data and improvement plan

BIBLIOGRAPHY I Rapps, Sandra and Elaine

J

W(:yuk~r. "SclC'C IIIl ~

Software Test 1)313 Usmg Datil Flow In (o rm all on," IEEE Trnnsnctto"S on SojlJD,m

&.g'''''"''9. Vol. II . no. 4. 1985 . pp 367-375 1 McCa~. T J.,·A CompleXity Measurc,- IEEf Tr"tI~lCllOtl5 "n 5"jlll.tI(( E"9H1etrltl!/. SE·2, no .. ( 1976), pp 308- 20 3 Humphrey, WaItS S , "MtJI'I49 1119 rl,( Software P'ocr<~ (SEI Srnri m SO/IU)n rc £"9'"(("" 9)," Addr so n·Wt."s lC'y. 1989 4 jUnll org

WW'W

S Myers Gle nford

jun.t org [acccs.:.ed 12/ 14/09 J

J 'Tht

Art of SO/I U1.trt TrS fm9." John Wiley

&

So ns. 1979

665

Module and Integration Testing

Planning

Maintenance Testing The Software Developmen r Ule Cycle

•

How do you test a class?

•

How are stubs and drivers used for testing?

•

What are attribute-oriented lests lor a class? Class invariant-onented lests? State-based tesls?

Requirements analysis

-

Impleifbl nt8tJon

•

What

•

What is big bang Integralton? Incremental? Bottom-up? Top down? Continuous?

•

How do dally bu ilds facilitate

Design

IS

mtegratlon?

continuous Integration?

•

What is interlace testing?

Figure 27 .1 The context and learning goals for this chapter

This chapter dlscuo;",co; tes ti ng beyond Unit IC')llllg-to the module level and to the Inl cgr\luon of modules. Vil e bc:glll by discussing class tl.-sung. Cia'S tc')tmg I con,\1dcred by some to be beyond lImt It''Stln~

and by o thers not so Integration IS the process of assembhng partS to (om, a whole As

3

phYSIcal illustration of thl< o nn.pt .

consider Flgur( 27.2, which IlIuslra tC' the Integ-ration of J ~uspcns l o n bridge . The order of Inlcgr.1tlon and the

STUBS AND DRIVERS

Assembling Ihe parts inlo a whole

Figure 27.2 The meaning of "Integration" -an analogy from bridge·building, steps 1 through 6 manner In which rhe part are te red toget her IS critical for rhe co n,tructio n of the bridge For exampl e, as cmbling ir in the wrong order wdl lead to longer construcrion times, o r worse, a defecti ve bndge u h issues are equally important for the integration of sofrwa re sy tern, likeall engineering artifact , software systems must be bui lt fro m parts. Each part is deve loped and unit · rested separately. The whole i then assembled , /''',gralloll is the process of assembling these parts and te ting the result to ensure that they work together correctl y. A part of a software system to be Integrated can con ist of several lines of code, a whole method . a class, o r an en tire subsystem Aglie melhodo logies use co nti nuous integration and dail y budds as much as possible. We dIScuss th ese on this chapter. An example of a class tc t IS provided In ne case study sectio n. In ano ther, an integratio n plan" descnbed. Both of rhe'e apply to the Video game example u,ed ,n thIS book.

27.1 STUBS AND DRIVERS Consider the coordination issue, a,sociated w,th Integrati ng the parts of an application show n in Figure 27 . ~eral of the part depend on each other yet mu'i be put together ,n some order. \Y/e u'c ,rub, an d drivm for thiS purpo e Simple stubs Were Introduced ,n haptn 26 We e 'amine th em ,n more depth here for Integration t"'"ng, and we also int roduce drivers The left·hand co lumn of F'gu re 27 4 ), which" ,ubqanlla l en u~h 10 ~tr,,'ie Item I but IS otherwt>e as mode't as po" ,hlc. If Our goa l IS top· down Int wa tlon (dC'Lrtbed In detad ,n ctl ,on 27 3 4) then we fiN reate ,Illb, "' Step' TD .• and TD-b These ar ,ubs"tut", (or the Ite.m th at arc ,ul"t. nl,,1 l'nollllh ( r Item I to he lested (,te" Ti). C) but ot hcrw,, ' req",'e as lilt! . dfort ;" pr",, !>lc

..7

• 668

CHAPTER 27

MODULE AND INTEGRAnON TESTING

Home Office Use

Computes pariS 01 a tax return associated with the use 01 pari 01 the home (or business purposes

uses

uses

Tax Retum Creates an entire tax relUm for many kinds of personal and business situations

Computes the depreciation on various types 01 equipment

Depreciation

Figure 27.3 Stubs and drivers-motivation from a tax return example

Eventual conliguration

Boltom-up

:

Top-down

development or integration

I

development or integration

I

I I I I I

I I

I .------, I

Item 2 __- .... BU-b

Item 2 :

driver

I

Item

1

uses

I I I

I I I

I

I

uses

I I

: I I

'-~-::l

I

I I I

I I I

--' -.., Item 3

I I

I I I I

uses

Item 2 stub

'--

Item 1 TD·C

I I

BU·A

Item 3

I I

•

I I I I I

TD·a

Item 3 stub

•

Figure 27 .4 using stubs and drivers for integration and testing

TI,,,,c remarks appl y just as much to the development of items In the first place as to their integration and lesting .

27.2 TESTING A CLASS Ah'er testang the individual methods of a class, we can move on to Ie ling the class as a whole. This amoun ts to executing tts methods in combination or subjecting: objects of th(: class to event such as mouse action. Rt"Call

that the method of a class are frequently interrelated because they may alter the value, of commo n variables For example, in an Aceo",,1 class, the methods J,posil () and Ul.lhdw wO would both alter the Imlun , van.ble. If

TESTING A CLASS

I Exercise methods in combination • 2-5. typica lly • tcst moSt commo n equence Arst • include sequences likely to cause defects 2. Focus tcsts on each attribute • IOitialize, then execute method seque nces that affect it 3. Verily that dass invariants are unchanged • verify invariant true with initia l values • execure a method seq uence

• verily invariant still true 4. Verily that objects transition among expected states • plan the state/transition event • set up the object in the IOitlal state by setti ng variables • execute event and check that transition occu rred Figure 27.5 Performing class

tests-variou~

focus

dtpoiilO "ere coded in terms of flool , for example. but uJi,/,drauJ() in terms of doublt , the tester may not notice anything "rong in testi ng each indiVidually. For this reason . It may not be sufAcient to know that each method has been individually unit·tested . nlere are several complementary ways of tes ling classes, as shown in Figure 27.5. Each is discussed in this seclio n, and several are illustrated in the case stud),.

27.2.1 Example of a Class Test Each method combination test consi sts of a seq uence of function calls. For the class fll eouHltrebornCI", for example, the methods in Table 27. 1 would be tested in sequences. We concentrate our testi ng resource o n the following : I. Sequences likely to be com mon ly used

2. Sequences that appear most hkely to harbor defect Table 27.1 Example of a class test- labeling methods for use in combination Abbreviation

Method prototype

aq

adjustQuality(String qualityP, float qualltyValueP) deleteFromEncounterCharacters(EncounterCharacter encounterCharaC1erP) EncounterCharacter getEncounterCharaC1er(Strlng nameP) float getQualltyValue(Stnng qualityp) float getSumOfQualitlesQ float getTOleranceQ Int IndexOf(String qualltyp) throws Exception InsertlntoEncOunterCharacters(EncounterCharacter encounterCharacterP) Int maxNumCharslnNameO setQuallty(Strlng qualityP, float valuep)

d

ge gq gs gt 10

II

m

sq

669

670

CHAPTER 27

MODULE AND INTEGRATION TESTING

The follow.ng sequences arc common in playing the gamc.

gc-aq-gs /I get character - adjust quali.ies - get sum of qualoties gc-'q-aq-gq II get character - s of methods, because every met hod con be repeated any number of times. A procedure must be employed to make the number feaSible . For example, a tnage approach can be usefu l 10 identifyi ng common sequences. A given sequence of methods ca·n be C<1!ego rized as either most likely or least likely to expose a defect. Otherw.se, the sequence IS consigned to the "neither" category. All of the "most likely" tests are then executed , together with as many of the "neither" category as possible. n,e "least likel y" are executed if there is time. The process 01 adjusting quality va lues in the Encounter video game is relatively complicated. The following is an example of a sequence apparently more likely than many to harbor defects.

g'-"l -aq-'q-aq-gq II g" characler -

sri

a quality - adjusl qualilirs -

sri

a quality - ad!,'" qua/.Urs - g" quality

\'(Ie will assume that the methods have been tested IOdividually, and we'll concentrate o n sequences of methods that aflect the others. Figure 27.6 shows how the methods in the example chosen rdate to each other through their effect on variables. Steps I and 2 affect the value of the conw,'rolion vanable. Step 3 affects the value of " ""gl/'. In Step 4 . the "amina variable is an input to the adju"Qua/ity() method, which uses this value (and the current value of co"crJltrntio~l ) to change the value of Cotlct'llration . Thus, each method in the

sequence sq-aq-,q-aq affects the outcome of a later method. The interaction among seemingly simple method.s can be quite complexi The case study of Chapter 26 shows these tests in action . The sections that follow discuss ways to tame this complexity 01 choices.

27.2.2 Attribute-Oriented Tests Attribute -oriented tests focus on variable changes, and create method sequences that effect them . A simple example for an Acco""t class is to have the balance grow and shrink to zero. To do this, we could execute t he sequence ",Ba/aH"( 50); addToBalan,,( 70) ; d,ducIFromBa/a"er( 120); g,'Ba/aller() . \'(Ie va lidate the predicted balance. The example in Figure 27.6 can be designed as an attribute test, focusing on the variable (O"'"ltraflon .

1. ge: c = getEncounterCharacter( -PlayerCharacter")

3. agoc.adjusIOuaiity( "concentratlon-l 0 )

concentration

4. 5g: c.setOuatity( "stamina"40 ) 5 . agoc.adjustOuatity( "concentration"10 ) 6. gg; c.getOuatity( "COncenlration")

Figure 27.6 selecting melhod sequences ror unll lesting

--retrieve data to validate

TESTING A ClASS

27.2.3 Testing Class Invariants As described in Chapter 22, class invariants are constraint among the attributes of the class that must remain nut alter the execution of every method. A class invariant te t conSists of executing a seque nce 01 methods and validating Ihat the invariant remains lrue. For example, suppose that a rule of the bank is that overdrafts ~re capped at $1 ,000, including the assets in the customer's avings, and IOtal assets per regular account are capped at $10,000,000. The invariant of the Accolml class would be something like the lollowing.

-1000 <= checkBalance + savingsBalance <= 10000000 We would initially set the variables to amounts that honor this invariant, such as chrckBalanCf = - 3000 and SQvin9sBalanCf = 2500. Then we would execute a sequence 01 methods such as deposl( 300); wilhdraw(500 ); deposil(50) and check that the invariant is still true. Languages such as Eillel and Java are equipped With functions that test the validity of assertions. An assertion is a statement that can be true or fa lse: lor example , "x = = y." Assertions are often invariants.

27.2.4 State-Based Tests As we have seen, the instances 01 a class ca n often be usefully thought 01 as transitioning among states in response 10 events. We should therefore test such classes in terms of' their state. For example , let us test the class Enco,,"lrrGame. Figure 27.7 illustrates the first steps In the testing of the application's state transHions . The complete state· transition test is shown in Figure 27.8. The numbered steps denote a typical event sequence for causi ng a meanin gfu l sequence of events. One lest would thus consist 01 sti mulating the system so that it transitions through thi s sequence. The tester would also introduce events that do not apply for panicular Slates 10 ensure that indeed they do not affect the application . To design and execute state·oriented testing requires significan t time, especially because extensIVe user inputs are required. Tools arc available that record user interactions with the system and that can reproduce

test step 1 Preparing

Player dismisses qualities menu

Verify that the game is initiallv in Preparing state (by checking on the class member gameS/a/e/).

Wailing

flcur. 27.7 State-transltlon test sequences, 1 of 2 seve. A5'<WtJon 10( Compuong Madtinery, nup'VIww acm orll... pe(lmarVQUOSliOn cgmorm. PUTQ

671

672

CHAPTER 27

MODULE ANO INTEGRATION TESTING

test step 2 ........... .--/ Dismiss the quality menu, and verily that the game Is in Waiting slale.

"-

test step 3

Preparing

I~

Player dismisses

test step 1 Verily that the game Is Initially In Preparing slate (by checking on the class member gameStatel).

qualiries menu ,./

Move the player character to an adjacent area, and verily that the game is still in Waifjng state.

Move to adjacent - - -

area

---'

Figure 27.8 State-transition test seQuences, 2 of 2

these actions In addi ti o n, assertion checkers ca n be embedded ,n the code to verify that the system is in th e

slate it is supposed to be.

27 .3 INTEGRATION Thi s section discusses and compares various types of Integration , and is summarized in Figure 27.9. It starts by co mpanng b ig bang inlegration with the inc remenlal style that IS generally recommended ( when it's po sible), The extreme (orm of Incremental integration is COll titlU OUS integrati on. The last c1assincl:Ition d iscussed is between to p · down and bottom · up sty les. Projects o ften mi x these ,"teg rati o n and testing styles, depending on the n3rure of rhe projec t

Big bang integration

Test

Incre".entallnlegration

modules IndMdually

Figure 27.9 Module and integration testing

INTEGRATION

IApplication I

'/

Module

Unit

c-

Unit

Unit

Module

Module

• ••• •

• • • ••

.....

Module

•••••

• • •• •

Unit

Unit

Unit

figure 27.10 Big bang integration

27.3.1 Big Bang Integration Big ba.g

integration consists of creating modules in parallel and th en assembling them in one operation . A form of this is illustrated in Figure 27. 10 Although big ban g testing redu ces or eliminates the need for test

drivers and stubs. thi s beneAt is usuall y far outweighed by the complexity and co t of fault isolation. Since many modules are integrated at o nce. i t IS frequ ently difAcult to locate the source of defects . As an example, consider a sys tem that moni tors th e health of at ·ri sk patients as th ey go about their daily lives. As illustrated in Figure 27. 1 I . the application ca n be th ought of as deco mposed into a m odu le that

Individual Health Monitoring Applicalion

Health Data Transmission

Unit

Mobile

Diabetic Analysis

• • ••

• • •••

Cardiac •••••

Analysis

• ••••

Phone

Fleur. 27.11

Big bang Integration of a health monitoring system

Unll

Emergency Notification

Ambulance

Unil

673

674

CHAPTER 27

MODULE AND INTEGRATION TESnNG

Module 1

uses

uses

Module 4

Module 3 uses

uses Module 2

Figure 27.12 Module sell-dependency-conslder Its effect on Integration

handle the collection of data fro m patients, o ne that analyzes data for sp('ci flc diseases, o ne that handles emergency notiRcations such as calls to the po lice, and a o n. it makes a g rea t deal of sense to develo p these modules separa tely For example, \\'!hy no t develop th e diabetic analysIs in an orga nizat ion specia lizing In that

Acid, an d ha ve emergency no ti fica ti o n d eveloped by a company with expe nence in writing such software reliably Some modules may be effectively written b), skilled teams worklllg anywhNe , geograp h ica ll y speaklllg. Although continualllltegra tion , described below, is preferable in gene ral , it ma y not be practical in a case like thi Each h ig h · level mo dule and its subsidiaries ma y ha ve to be devel o ped separately, and then IIltegrated III big bang fas h io n. The Integration and .estin g of mo dules illustrates the wisdom t,f desig ning so that dependenc ies arc noncyelic. In o th e r words, we try to avoid architectures in which a mo dule depe nds o n itself. Figure 27. 12 illustrates suc h an architecture. We can't fully test an y pair of mo dules al o ne, O ur o nly c ho ice is to use stubs or to test all of th em together, which multiplies the po tential for hard· to·R nd and hard -to-Ax defects.

27.3,2 Incremental Integration owa days . software integra tion typica ll y proceeds 10 an incrcmt. ntal manner in whIch softwa re modules are

developed and assembled into progressively larger parts of the system, This is known as i"a"""".1 i""gra'io" ( I ). Gradually building the system means complexity increases incrementall y, making it easier to isolate integra tion problems Incre men tal integration ommences when the first tWo pans of an application arc developed, and continues until all its part s have been integrated into a complete sy tern , at which time system testi~g

comme nces. Stub and drivers arc employed during this process. Throug ho ut th e integration process, software "builds" may be crea ted that foml the e merg ll1g ystem , as Illustrated in Figure 27. 13. Befo re adding new mod ules, integratio n tests arc executed agai n t each build, ensuri ng th at the build ",arks correctl y. Figure 27.2 Implies that mo dules arc developed and integrated in some o rd er, but does no t sugges t how the o rder is determined , We u ually determine the Integration order b)' ba ing it on the desig n of rhe sy tern . Two common met ho ds are bOl/om-up and lop-dOlPH , and eac h must account for dependenCies between the modules mak ing up the desig n.

27.3.3 Bottom-up Integration Suppose that an application consists of the modules and dependenc.es as hown III Figure 27, 14. In bottom-up Integration , modul« that are most depended o n are developed and inte"rated •nrsl. Th en ., the modules that depend on t h em are integrated next, .nd so on In FIGure 27, 1-1 , this implies th.t Module 3 i< developed first , si nce it is at th e "bottom" of the dependency tree Modules I and 2 arc integrated nat with

-. ,. .'. . ~-'~ .•. ~. ; ••.h-

~ "

.... .. RII!'d

BuIld

Un!!

. ....

Uni!

.. ....

Uni!

• •• • •

Figure 27.13 Incremental integration with builds

Module 4

\ uses Module 1 uses

uses

Module 3

Module 5 uses

Module 2

FIgure 27.14 Example of module dependencies

Module 3 since they depend o n II. Modules 4 and 5 arc integrated lasl. Integrating in thi s manner is illustrated In Figure 27. 15. An advantage to th is approach is that It reduce< the need for stub si nce dependent modules are available when needed for integration Let's consi der how we mi ght perform bottom ·up integrat ion testing o n the Encounter vi deo game. Figure 27. 16 shows the relationship among rhe objects of the Encounler ",chlleC[ure , We have three modules (package ) to Int<:grate. and need to determine which modules depend on which. The direction of th e aggre!;ations uggesr an appropriate order, 0 show n in Figure 27. 17. Figure 2718 Ihows the resulllnK "using" reiatlon,llIp between the po kases .

676

CHAPTER 27

MOOULE ANO INTEGRATION TES TING

Third or fourth Module 4

Module 5

usos

Third or fourth

uses Module 1 Module 2

uses

uses

- -I

First or second

Figure 27 .15 Bottom-up integration

EncounterGame EncounterGame .. Iacade ..

--<

Er'I»'Hlt&rChar8cters

c

lr EncounterCast .. facadegetTheEncounterCastO getThePlayerCharacter() getTheForeignCharacterO

getTheEncounterGameO getStateO setStateO handleEvent()

1

EncounterEnvironment

I*EncounterEnvironment .. facado ..

setLocationO

Area

Figure 27.16 Module relationship in Encounter

X depends on Y 50 create and lest Y first Figure 27.17 Dependence and Integration order

INTEGRATION EncounterGame

uses

uses EncounterEnvironment

EncounterCharacters

__------ uses

F"tgUre 2.7.18 Module dependencies in Encounter

Second

EncounterGame uses uses

EncounterEnvironment

uses

EncounterCharacters

F"rgure 27.19 Bottom·up integration testing in Encounter

Next, we apply the principle of bottom · up integration to derive an integration order. Th.s tell s us to firs t te5tthe integratio n of EncoII"'trEnoiromn,,,' with E" Oll"'tr /larnrlcrs , and then to integra te E"colln'trGmnr. Thi s is .lIustrated in Figure 27. 19.

27.3.4 Top-Down Integration Top ·down Integration is the opposite of bottom ·up, Modules at the top of the depende ncy tree are developed first, with integra t.on proceed.ng down the tree . Th.s rype of Intq;ranon requires a cons.derable use of stubs since dependent modules are nOI yet ready for Intcgrallon . The advantage of top·dow n '"tegTalion i that modules at the top of the dependency tree arc typ. ally h.gher level fu nctiona hty of an aDpl. allon , su h a user interfaccs, and are te ted early in the .ntcllratlOn ~y Ie. n,i< prov.des an early fee ling for the appli ation , 1110lolin8 time for .mportant mod.f.cation,. F,gure 27 20 shows the lop ·down .ntegration order of En ounter. Th.s tell s u to Ar t te t the .ntcgrallon of EnCO""'rrG"mr w.th E.ICollnlrrEnviro","tIll , and th en to .ntewale E"(Ollllln Ch"", 1m.

6n

678

CHAPTER 27

MODULE AND INTEGRATION TESTING

EncounterGame

Ar51

uses uses EncounterEnvironment

uses

( second)

EncounterCharacters

Figure 27.20 Top·down integration testing in Encounter

Top-down Implementati on . '"t
,'ruc'u"a

,h,

27.3.5 Sandwich Integration Sandwich Integratio n is a process by w hich o ne integrates from the bottom and to p more o r less at the same time , introduci ng stubs for the intervening classes as o ne does this Suppose. fo r example, that we wa nt to integrate (h e class Forri9nCharacttr, which is at the lowest level in Encou nter, and EnCOUHltrGamt, which is ar the

highest, without havi ng to worry about the intervening components for now. T o have FO"'911Charac1" and E"colmkrG~mt coexis t, we can introduce stubs (or the intervening classes. For example, in Figure 27.21 , we Ars t have Fortl9n Cbaracttr work with a stub (or EncolmlrrCbaracttrs , then one (or E"CO,mlrrE,1IJi,."mmcH', then E"coulflcrGatftt. We don't count the Introduction o( stubs as true integration, so the only step th at's trul y integration i n this

exa mple is the last. It integr.ltes from th. top and bo tto m Simultaneo usly.

27.3.6 Continuous Integration (oll ,illuou, ;II" 9ral;01l is a ty pe of .ncremental integr.ltion in which small amo unts of code are added to rhe baseline (the currentl y state of the application ) on a very freq ue nt basis. Intervals arc often. freque nt.s da.ly (see Section 27.4 ), and the newl y integrated code does not neces arily correspond to a completed met ho d or

DAILY BUILDS

EncounterGame

uses uses \

EneounterEnvlronmentSTUB b

.- uses

EncounterCharaetersSTUB

a

uses

>1ForeignCharaeter I

Figure 27.21 sandwich integration testing in Encounter, in order a, b, c

class but can be smaller. As long as the code is unit-tested and does not introduce errors in the baseline , it can ~ integrated into the baseline. Continuous integration is one of the twelve practices of Extreme Programming (XP), as we described in Chapter 5. However, it can be utilized even if a non-agile process is being followed. 27 ,4 DAILY BUILDS

During incremental integration we build the software and regressio n-test it at regular intervals. Regression testing is designed to ensure that recently added code does not compromise preexisting functionality . Depending on the phase of the project , builds ca n be created weekly or even as often as da ily. Daily builds are often used at the tail end of projects when last·m; nute additi ons and changes are required. They are also used during mai ntenance . Figure 27 .22 shows an example schedule of overnight regressio n testing for an application approaching release . Figure 27.23 illustrates the da ily code integration process. This kind of daily integration and regression teSt schedule was reported by Cusumano and Se lby [3] as being utilized by Microsoft, for example. Referring to Figure 27.23 , a daily code freeze time of, typica lly, 6 PM is established, after which no new code is accepted for that day. The software system is then bUilt and run , and regression tests are executed on

biweekly

weekly builds

week 23

24

25

26

27

28

29

30

3'. release

Key:

'f= overnight regression test

fl&ure 27.22 Example frequency of overnight regression tests

679

680

CHAPTER 27

MODULE AND INTEGRA nON TESTING

Run Regression tests development

development

Confirm baseline or rever! /0 previous baseline

Freeze /0 baseline

Figure 27 .23 Daily builds the new budd between 6 I'M and 7 AM . If a problem is found with the ne'" bui ld , it is assumed the defect lies in the code that was checked in during the previous da y. This makes the job of problem isolallon and resolution easier than If a longer time Interval had elapsed between bu ilds.

27.5 INTERFACE TESTING

l"'''facr

validate the interface of each module from the viewpoint of the ir usage by a client. These can be conducted, to the extent possible , prior to the in tegratio n of a module (with necessary stubs); and then after the integratio n of the module (With, typicall y, a reduced set of stubs). The Facade desig n pattern can be used to faCilitate Interface testing. A faca de object IS created for each class o r package , provi ding an implementa· li on of its public interface . Each method in the facade checks its input pa rameters to e nsure they are passed ItS ls

correc tl y and rc turn ~ a predetermined response. Thu s, the ca ll er can test its interface with a module without

knowledge of whether It is usi ng the facade or the rea l implementati o n. This makes problem discovery and Iso lation easier Let 's n:turn to the: Video store as an example. Figure 27.24 shows the module decomposition

for this appitcation .

DVDs DVDRentals DVDAccess .. f8csde -

VideoStore

DVDsRented

VSCustomers

DVDCustomerAccess

.'.c.,OO,.

Figure 27.24 Video store module interfaces

fE-

o ..n

IPflERFACE TESTING •

Now we will perfoml an interface t h OV a Ii arion ) can be exercIsed by mea n est 0 11 t .e Os module. Its usage by clients (I.e., othc~ pans of the PP L d clas DVDA I s of the facade object o nly. Thus, the interface tests conSIst of testIng thc raCa e s rerss . t exposes meth ods ' uch as t h eo f II oWing: . :1

voi d stockDVD(String aDVDTitle) ; Rentalltem getDVD ( int aDVDID) ; Rentalltem getDVD (S t ring aDVDTitle ) ; StrJ.ng des cr ~beDVD (i nt aDVDID) . . . ' Str~ng descr~b eDVD(String aDVDTitle) ; Note that the metho d griD VD() returns a Rnllalflffl1 o bject. The Rn.tnlItcm class is a public fram ework class, and so IS accessIble to all o bjec ts. Th e9ttDVD() method ca nnot return a DVD object because the DVD class is hidden fro m clie nts of the DVD, package. The interface test executes interface methods with test cases. An example is the fo ll owi ng,

•

DVDgwtw=newDVD ( "Go neWithth eWi nd" ) ; / / Get access to the facad e obj ect DVDAccess dVDs = DVDAccess . getTheDVDAccess ( ) ; / / Now run the tests dVDs. st o ckDVD ( gwtw ) ; Rentalltem rentalItem = getDVD( "Gone With the Wind" ) ; / / Report discrepanc ies between str ings (assume a "compare () , , test utility ) compare ( rental ltem.getTit le() ,gwtw.getTitle () ); / / etc.

For the DVDRnl tais package, which does not use Far(/d, . the interface is the collectio n of meth ods of member classes. For example , the class DVDR,ntnls expo es me thod such as the following fro m the DVDRtntal class.

DVDRental createDVDRental(RentalCustomer aDVDCustomer, Rentalltem aDVD) DVDRental [) getDVDRentals ( RentalCustomer aDVDCustomer ) RentalCustomer getDVDRentalCustomer ( i nt aDVDRe nt alID ) void removeDVDRental ( RentalCustomer aDVDCustomer , Rentalltem aDVD) void r emoveDVDRental( int aDVDRE'ntalID) float getFin e ( RentalCustomer aDVDCusto mer , Rentalltem aDVD ) float getFine( i n t aDVDRentalID) The Interface test IS ,urn marized In FIgure 27.2 .

611

682

CHAPTER 27

MODULE AND INTEGRA nON TESTING

An Interlace Test:

DVDs DVD gwtw • new DVDI "Gone With 'he W.ncf"):

DVDAccess -facade-

1/ GOI access 10 the fO~8de object

DVOAccess dVOs '"' DVOAC.0e55.getTheOVOACO)ssO:

void stockDVD(StringaDVDTilie ): Rentalltem getDVD( intaDVDID): Rentalltem getDVD( StringaDVDTilie ): String describeDVD( IntaDVDID ): String describeDVD( SlringaDVDTnle ):

II Now run the tests dVDs.stockDVDI gwtw ):

AontalUem rentalHem ~ ge,DVDI

"Gone With the Wind") :

/I Report discrepancies between strings

/I (assume a ~compare W test utility) compare( renlall lem.gelTIll eO.gwtw,gotTiUeO); II etc.

Figure 27.25 Interface tests of DVDs package

27.6 MODULE INTEGRATION Once In terface teSlS are completed , we ca n feel conRden< about th e interface between modu les. We are then ready to test their interaction more completel y wit h in tegration Itsts . An integration tcst focuses on the additional functionality gained by assembling modules. Now let's i,llegrate fully functional ve rsi o ns of the DVD, and V5Customm packages . To perfo rm integration tests , we identi fy the added functlonaliry that thi s integration provides-in thi s case, the

additional functionality that the DVD, and V5( ullo",,,, package< provide . In parti cular, the methods of DVDRrnla', wh ich were using stubbed facade meth ods in DVDAccm and f)VI)CullomcrAcctSs , now use fu ll y fu nctional versions . The methods of DVDRtIIln' ca n now be fully tested . The same app lies to all classes in DVDR,"'a', . listing 27. 1 is an example of a met hod in DVDRt>ltn' that IS part of thi s integ-ration test

Ustlng 27.': The getDVDRentalO method, which becomes more operable after some integration Rental getDVDRental ( Rentalltem aDVD . RentalCustomer aDVDRental Customer) {

/ / Check that aDVD is in the inventory DVDAcc ess theDVDAccess = DVDAccess" getTheDVDAccess ( ) ; i f ( ! theDVDAccess" islnlnventory ( aDVD ) ) return null; / / or some other error indicator

CASE STUDY: CLASS TEST FOR ENCOUIIITER

II Check that aDVDRentalCustomer is an actual customer

DVDCustomerAccess theDVDCustomer Access = DVDCustomerAccess getTh e DVDC t () • ( I h . us omerAcce ss ; ~f . t eDVDCustomerAccess . verify( aDVDRentalC ustomer) ) return null; I lo r some other error indicator

I I Check that aDVD is rented to aDVDRentalC ustomer . . .. .

I I Retr ieve and return th e rental . . . . }

27.7 CASE STUDY: CLASS TEST FOR ENCOUNTER Usting 27. 2, whic h fo ll ows, Chapter 26 .

IS

a test fo r th e Enco"n ler llaracler class and comple te the Encou nter case study in

Ustlng 27.2: Tests for EncounterCharacterclass testEn counterC hara eterClass ( Str ing destinationP ) IOExcept ion

public static void throw.

(

/ * Prepar e for the test * / Pr intWr iter outM = new Pr i n tWr iter (new F ileOutpu tS t rearn (destin ationP) ) ; System . out . println ( " \ nEncounterCharacter class test results on " + dest i nati onP + " \ n" ) ;

/* * The f ollowing methods will be tested in sequences :

*

* a . adjustQua lity( Stri ng qualityP , float qualityVa lu eP )

*d . deleteFr omEnco unt erCharacters(E ncount erCh aractere n count erCh aracte rP ) * ge . Encount erCharacter getEncounterCharacte r ( Str ing nameP ) * gq . float getQualityValue ( Stri n g qualityP ) * gt. float getToleranc e() • io . int indexOf( Stri ng qualityP ) * ii . i n sertl ntoEncounterCharacters(EncounterC ha r acterencount erCh aracterP) • m. i nt maxNwnChar sI nNarne ( ) • sq . setQuality( StringqualityP , float qualityvalueP) * 80 . float swnO£Qualities()

• •

The f ollowing seque n ces occur commonly:

683

684

CHAPTl:R 27

MODULE AND INTEGRATION Tl:STING

ge - aq-so qe-sq-a-qq

" "

•

•

•

•

• •

The following sequences have a high potent ial for defects: ge-aq-aq-gq-s

*

"

•

• • • • •

"I I *TestCl:ge-aq-so"1 En counterCharacter eCIM = new

I I method "ge" EncounterCharacter ( "CharForTestCl " ); Il aq eClM. adjustQuality (QUAL_STRENGTH , 40.0f); TestExecution.printReportToFile(outM, "Class test ge - aq-so", eClM. sumOfQualities ( ) , 100.Of ) ; Ii so

I " Test C2 : ge-aq-aq-gq-so" 1 EncounterCharacter eC2M = n."

EncounterCharacter( "CharForTestC2"); Il ge eC2H.adjustQuality (QUAL_STRENGTH,40.0f); Il aq eC2H.adjustQuality(QUAL_STAMINA,20.9876f ); Il aq TestExecut ion .pr intReportToFile ( outM, "Class test ge-aq-aq-gq-so: part 1" , eC2M . getQualityValue ( QUAL_STAMINA) , 20. 9876f ) ; I I gq TestExecut ion .pr intReportToFile ( outM, " Class test ge-aq-aq-gq-so: part 2" , I I so eC2M. sumOfQuali ties ( ) , 100. Of ) ;

1* INVARIANT-ORIENTED TESTS "Check for the invariant "qualValueI [i) >=0 " * -- after executing the sequences of methods executed above

"I bool.'n truthM ::t.l:Uei ~or( in.

{

i = 0; i < qualityTypeS .length; ++i) I " Set trClthM false i f any entry in eClM. qualValueI not >= O· I truthH=truthM&& (eCIM.qualValueI[ij »=O .Of ) ;

)

TestExecution.pr intReportToFile (outH, "Class test for the invar iant qual ValueI [il >=0 I truthM tzue ) ; I

II ,

I

It Cone lude "I outM. close () ; System. out .pr intln( "\nClass tests of EncounterChar class concluded." ) I } II end of testEncounterCharacterClass

I " Tests all the methods of this class one at a time

CASE STUDY: CLASS TEST FOR ENCOUNTER

-@par_ • tellcept ion

dest inat ionP IOException

Location to,",r ite results. If there's aproblemopening or accessingdestinationP

*/ JIIIIb11cI.tatt c oid testEncounterCharacterllethods ( Str ing destinationP ) tlhos. IOExcept ion (

/* Prepare for the test */ PileWriter outM=nzwFileWriter( new File( destinationP) ) , System. out .pI intln ("EncounterCharacter method test resul ts on " + destinationP + " \n " ) , / *TestsforgetEncounterCharacter() */ EncounterCharacter eCNorM = n.wEncounterCharacter ( "qwerty" ), // normal TestExecution.reportToFile(outM, "Get Character Test 1: nominal value", eCNorM . getName( ) , "qwerty" ) , EncounterCharacter eCNullM = new EncounterCharacter (null ) , // null TestExecution.reportToFile( out II , "GetCharact er Test 2 : null parameter" , eCNullll.getName(),GameCharacter . DEFAULT_NAME ) , StringtooLongll="12345678901234567890 1234567890 1234567890 ", EncounterCharacter eCTooLongM= n•• EncounterCharac ter (tooLongM ) , //t oo long TestExecution. reportToF ile ( outll , "Get Character Test 3 : Limit parameter values , " + "max name len = " + eCTooLongM . maxNumChar sInName ( ) , eCTooLongll.getName () , tooLongll.substring (D , eCTooLongM.maxNumCharslnName(») , EncounterCharacter eCZeroM = new EncounterCharacter ( ,," ) ; // zero-len TestExecution. reportToFi1e ( outll , "Get Character Test 4 : zer o- length" , eCZeroM .getName() , GameChar4cter . DEFAULT_NAME), // bad chars EncounterCharacter eCPuncM= new EncounterCharacter ( "a +b" ) , TestExecution. reportToP i1e ( outM, "GetChar acter Test 5 : bad char ' + ' " , eCPuncll .getName() , GameCh a ra cter . DEFAULT_NAME) ,

/* Tests for indexOf ( ) for every valid quality name . */ for ( in~

i= 0, i
/* Tests for indexOf () for an i nvalid quality n a me . */ tcy

{TestExe c ution.r e portToF~le(

outM , " inde xOf () Test 2 : i nv alid name: zorch ", i nd e xOf( " zorch " ) , --1) 1

615

686

CHAPTER 27

MODULE AND INTEGRAnON TESTING

} catch ( Except ion eP )

{TestExecution.reportToFile( outM , "indexOf () Test 2: valid name: compare " , l'indexOf (\ ' 'zolch\ " ) ", , 'with expected _1"

);

}

1* Tests for setQuality () *1 II Set up for test EncounterCharacter hank = new EncounterCharacter ( , 'Hank"

);

II Nominal value hank.setQuality (QUAL_STRENGTH, 10.3f ) ; TestExecution.reportToFile(outM, "setQuality (} Tes tl:nominalvalue", hank.getQualityValue( QUAL_STRENGTH), 10.3f ) ;

II Out of range value hank.setQuality ( QUAL_PATIENCE, -6.2f); TestExecution.reportToFile(outM,"setQuality () Test2:nominalvalue", hank. getQualityValue (QUAL_PATIENCE ) , O.Of ) ;

II Value below close-to-zero threshold. hank. setQuality(QUAL_STAlIINA, getTolerance () * 0.9f); TestExecution.reportToFile(outM,"setQuality()Test3:valueclosetozero", hank. getQualityValue (QUAL_STAMINA) , O.Of);

II Tests for adjustQuality() . II Set up for test and verify: Values should be 20 each. EncounterChar acter harvey = n.. Encounter Char acter ( , Harvey' , ) ; TestExecution.reportToFile( outM, "adjustQuality() test 0: ver ify that values add to 100' , , harvey. sumOfQualit ies ( ) , 100.0f ); II Nominal adjustment II strength 30 rest 70/ 4 each harvey. adjustQuality (QUAL_STRENGTH , 30.0f ); TestExecution.reportToFile(outM, "adjustQuality() test 1: values sum to 100 a£ter adjusting" , harvey.sumOfQualities(), 100.0f ) ; TestExecution.reportToFile ( outM, "adjustQuality () test 2: values adjusted as commanded' , , harvey.getQualityValue(QUAL_STRENGTH), 30.0f); I

II Adjustment resulting in a zero value harvey.adjustQuality( QUAL_STAMINA, 99.0f }; TestExecution.reportToFile(outM, "adjustQuality(} test 3: ver ify low value reverts to zero' , , harvey. getQualityValue ( QUAL_STRENGTH), O. Of ) I

CASE STUDY: ClASS TEST FOR ENCOUNTER

// Conclude outM . close () ; System . out .p rintln( " \nMet h od tests of EncounterCharacter class conc luded . " ); }

/ **Classtotest repainting of characters. Createsawindow, whichwillcontain * * several copies of the character image .

*/ pd.... t.e .t.atlc cl ••• testCharacter Image eztend e Fr arne {

/** Instance attr ib\lte that remembers which character image to display. * / pri_t. EncounterCharacter characterI;

/** Basic constructor -- cr eate a window for test ing some char acter ' s image . *@param characterP Character whose image is to b e tested . */ testCharacterImage ( EncounterCharacter characterP) {

"ljor (c haracterP.getName()) ; characterI=characterP;

// Do all normal Frame initialization. // Rememberwhichcharacterwe ' retesting .

}

/ ** Repaint the display areaof the frame . *@param drawP Graphics context for drawing the c haracter.

*/ public ..oidpaint (Graphics drawP) {

Dimension frameSizeM = getSize () ; / / Size of the window area . / / Co nv enient divisions of window . iJlt widthUnitM = fr ameSizeM . width / 5 ; iDt heightUnitM = frameSizeM . height /5 ; character I. showChar acter ( this, dr awP , / / Dr awn small , fac ing right . n •• Po int (widthUnitM , heightUnitM) , heightUnitM , tab. ) ; char acter 1. showCharacter ( thio, drawP , / / Dr awn large , facing left. now Point(widthUnitM*4 , heightUnitM*3), heightUnitM*2 , tru. ); char acter I . showChar acter ( thia, dr awP , / / Dr awn lat ge , fac ing right . now Point (widthUnitM*2 , heightUnitM*2), heightUnitM*2, lala. ) ; character 1. showChar acter ( thi., drawP, / / Dr awn small. facing left . n •• Point (widthUnitM*3 , heightUnitM*4) , heightUnitM , tru. ) ; }

)

/ / End of tcstCharacterlmage inner class

688

CHAPTER 27

MODULE AND INTEGRATION TESTING

27 .8 CASE STUDY: ENCOUNTER INTEGRATION PLAN APPENDIX FOR ENCOUNTER SCMP: INTEGRATION PLAN

Note to the Student, We need to de eri be the order il1 wh ich the applic.'ltion is to be IIltegr.lted . The S MP is an appropnate location for this descnption , since it describes configurations of th e itera· tions and builds. ThIS could be placed in the SPMP, but it contains design and implemen · tation detail, which are nor rea ll y projec t management irems It could be placed in the SDD , but the integration plan is nOt a design but a way to get to the implementation of the design . A document o n implementation issues alone is a possibi lity . Another possibility is the SCMP , si nce it is concerned with conRgura· tions a the produc t comes toge ther. The Encounter case study selected this optio n.

The irH cf,( ratlon lC tlOg a.;sociated with thiS

Integra ti on plan a urnes that the Ind,yidual c1asse, have been tested (as above ).

2. Construction of Integration Baselines

Referri ng to the va rious integration techniques

discussed aboye, which o ne IS th is, It is largely bOllom · up if you take Ihe ",tS relationship for the hiera rchy. The til o""lrrGo"" package IS then at the top. If the integration process we re to be co ntinuous, a descnption of a dail y build pro· cess would be prOVided , perhaps along with some sense of the order of the integration. This is normall y associated with an agile process.

TIl e three successive bUIlds fo r re lease 1 of Encounter arc show n

In

Figure 27.26. TIle first

budd conS ist of th e GamtC/ulrn Irrs fra mework pack ·

Hi story of versions of this document:

11 / 1/98 E. Braude, Initia l Draft

Jgc and th e Ell cotmtrr bartlctrr5 package . Th e second

build uses rhe fir.; t build. It consi ts of the E"co""I"E"· 11irolUllf l11

pJckagc, irs corresponding fram ework. and

the ("St build . The third build refers to budds I and 2.

4/4/99 E. Braude, Re vised

It

8/23/99 R. Bostwick, Documents reviewed and

consi"it

of

th e

EllcolmlcrGamc

its corre ponding framewo rk, budd

I,

pa ckage,

ond build 2

rccomm enctJtions made

8/ 24/ 1999

E.

Braude,

Recommendatio ns

integrated

8/26/ 1999 E. Braude, Reviewed , comme nts exponded

1 . Introduction Dunng the integration process , the softwa re for

Encounter is co nstructed in sta ges or builds. Thi s

appendi x describes the configuration of the first three builds . Integration testin g i. b •.sed on these builds The last build i the basis for sy tem testi ng .

2.1 Integration Build 1 Build I i illustrated in Figure 27.27. Budd I imple. ment. the Gam,Charnel", frame work pockage and the EII Colmter Imractcrs package.

Imc rfacc testing (see Sectio n 27.5) is performed on this module by identifying all of the methods that its classes make public. (1\·lethod not needed by other modules should be made private to avoid unneeded te. rs of th, kind.) The design is such that these methods are ,,11 p.rt of the f"CO""lrrC,,,, cia ..

CASE STUDY: ENCOUNTER INTEGRATION PLAN

Build 3 EncounterGame

>l EncounterGame

Build 1

-'

EncounterCharacters

EncounterCast

j Build 2 •

./

EncounterEnvironment

I;

\

EncounterEnvironmenY1! .

""

Figure 27.26 Integration plan

Inlegratkm Plan

r,

0

1

GameCharacters

Err.;Q.ltlt~

«framework package»

r _"""

GameCharacter

e,"'(J'''o{",N'''''',.r\~2 -'

&...-....e-,."..Q" . ... I

Encounter Characters

EncounterCharacter

EncounterCast

~

PlayerCharacter

. facade - singleton -

Figure 27.27 Build 1 for the Encounter game

ForeignCharacter

619

690

CHAPTER 2;

MODULE AND INTEGRAT ION TESTING

Integration

r'>L!( . ...

1

~ I

GameEnvironment

(J'!CO 'IW C

Pip" I A

•

,.

GameAreaConnection

•

;<;

t

GameArea I~ 1< L

GameCharacter

~

GameLayout

~

~

Area EncounterEnvironment

~I

«facade » ~

EncounterCast «Iacade~'

EncounterEnvironment Figure 27.28 Build 2 for the construction of Encounter

2.2 Integration Build 2 Build 2 is shown in Figure 27.28 . Bu dd 2 conSlSlS of the

EH CO lltlltrfu pjrollmhlt

0"'"'''/

package and the GtlmtEIIIJlr-

framework package . logelher wil h Ihe first

At Ihe conclusion of build 2, Ihe framework! application decompOsi tion is show n in Figure 2;.29.

The fll CoIIII,,,Gllm, package and its Ro/,P/ayillgGarro, framework package arc no t present because the

a~

part of budd 3.

build. The GamcEHPlfoHmcnt and the En Co lmttrEtlVirorl ,""" packages use the build I Gam,Charac'tr and f" colm'"Cas' classes, respective ly. Courtyard, dun -

2.3 Integration Build 3

geon , and liVing room are examples of areas. Some of Ihesc areas are connecled . For example, there is a connection between Ihe dressing room and Ihe courtyard

The fi nal build, build 3, IS illuslraled in Figure 27.30. Budd 3 consi Is of Ihe fllco""" re""" package, ItS Ro/,P/aYIHgGmnt framework pa kage, build I, and bUIld 1_

CASE STUDY: ENCOUNTER INTEGRATION PlAN

Characters

GameEnvironment

. framework package _

- framework package.

EncounterCharacters

EncounterLayout

Figure 27,29 Status of Encounter after build 2

~--------------------1

L-f!ol~~~~ng~arn~~ _____ _____ ______ __ ____ _______ ________________________________ _' ____ , I

I

RPGMouseEventListener notifyOfEventO

I

I

P>--

RPGame handleEventO

;

i

£

I

GameState handleEventO f\

~

I

I I

«singleton» Engagement

EngagementDisplay

I

--------- --- -"l

Engaglng '

Wal'tl' nn ~

I

handleEventO

handleEventO

I

----'

I1_ _ _--...: '---_ __

I !

__ _ _ __ ______ ____________ •

-~-----=-_£".:==~-=-=-:...-=.:=~---=--=~:.--=--:.==--.:.===--.::--== II~

1 !

I

__-L..._--, ! Reporting handleEventO

Preparing handleEventO

I I

I I

I I

,---;---------------. . --1 - .--- --.- -,,- - -- - ----- - ----- : EncounterGarne : L ____ __ ___ _ ____ _ _ _ _

I

Key: Domain class Figure 27,30 Build 3 for Encounter (Includes bulla' and build 2, not shown)

I

691

692

CHAPTER 27

MODULE AND INTEGRATION TESTING

27.9 SUMMARY Int08"'tion rders to the process of assembling the pans of an app licatio n and testing their Interactions 10 ensure that they work tOKether correc tl y . The parIS that arc integrated can be as small as a few IIIK'S of code or as large a ;} subsystem. Two overa ll strategies for integra ting th e parts are IIIcnlrlrntal and

big bmtg

In incremental integrati o n, th e

system is built step by step in relatively small increments. As soon as a part of the applicatio n is developed it is Integ rated into the basel ine. In big bang integration . the parts of the system are developed first and then are ",tegrated toget her in o ne tep. This approach ca n lead to man y problem s and i usua ll y avoided if at all possible. A com monl y u ed tech nique is to build and test the entire code base on a reg ular basis. Earl y in projects the interval an be weekly, but atthe tail ·end it can be daily. Co nducting daily builds ensu res that any problems that arc uncovered can be isolated to recentl y added code . si mpli fying defect isolation and reso lution The Facade design partern can be used to facilitate interface testing between modules . A facade stub object IS created that implements the public interface of a class or packa ge O ther modules test their interf"ce wi th that module, and the facade object checks that it is being ca lled correctly and retu rns a predetermined respo nse. Once the interface is tested, the faca de is replaced wi th the real modu le and the modules are tested further.

27.10 EXERCISES I . In your own words, describe incremental integrat io n. Name and explain two ben el1ts of

incre menta l integ'ration .

2. In your own words, explain how a project schedule is affected by the method of integration used on the projec:. 2A. Consider the health monitorin g application described in Figure 27. 11 . Describe wit h examples how yo u would integrate it bo tto m· up and how you would test the integra tion process. 3. In yo ur own words, describe how boltom·up integration works. list and ex pl ai n two advantages and dISadva ntages of bottom·up integration . 3A The case study in Section 27.8 does not deSCrIbe a continuous integration process-but suppose that the document did prescribe one instead. What would that document say7 4. In your own words, describe how to p·down integrati on works. list and exp lain two advanta es and disadvantages of top ·down integration. g

5. Consider a poi nt·of·sale system th.t is under developme nt. Assume that th-.... h ard ware p Iatfarm an d device drivers that control it are brand new. The rest of the software 's b . d fr . . Wh " I emg porte am an eXlStmg system . at appropnate method of mtegratio n might you rec d be om me n used and wy7 • h 6. In your own words, explain how daily builds facilitate the isolation

f d ( . a e ects In a build.

7. Figure 27.31 shows the architecture outline of an application th t ' I h . b k P 'd I fo .. a 51 mu ates t e movement of customers In a an . rovi e a pan r bUilding and integratin g th O I" IS app ICtltlOn .

BIBLIOGRAPHY

BankSlm

BankCustomers

I

~

.facade-

BankCustomer

I

Pending Events executeNextEventO Number

~ ufacade» getNumberO

BankLayout

BankLayout -facade » BankEvent

Teller

BankEvent

IQueue I

ccfacade'l executeO

Figure 27.31 Architecture of bank simulation exercise

TEAM EXERCISE

Integration Obtain proj ect speci ficati o ns from two other team s in the cia . s. Speci fy informa.lly a new appl icatio n that contains significant cl ements o f these applicati ons. SpI' cify an integratio n plan to build thi s new applicatIon . Evaluatio n cri ten a: ( I ) Degree of clan ty of th e pl an (2) D egree to which the pl an conlaln an appropriate o rder

BIBUOGRAPHY I

2 i

I>czu . M auro, dod Mlchill l Y(JunH, ., 0/111'£'" Tl\l'''!/II''11 ;\~U lyfl' p ' ()( t1 C, Pm,,,,,,,, jlllJ Trdmlllun," John \'(' ,I c)' ~ S('IO, 2008 U.,kstra, Ed'8C'r, - ( ,I') To t .. teme n, on" den:d " "rm(u ' " COWI III'HIlj, dhOn( 0/ ,/'t AeM Vo l II no 3, I (\8 Pf' 1-t7- 1"1l t...J,."m. no. M . ~ Ild R W Selby. ~ llow M. ro<\oit nUl ld~ ~oft .....arr .· ( O,"I'Ut" '( ""O"~ o} I/It Ar M v I 40 no O. 1997, PI' . l - b l

693

Testing at the System Level

Planning Maintenance

Testing The Software Development Ule Cycle

Require: 118"15 analysis

•

How do functional and nonfunctional lesting differ?

•

How do you conduct performance tests?

•

What is load I stress event testing? ReliabilIty and availability testing? Recoverability testing?

•

How do you lest usability?

•

How do you validate secunty?

•

How do you test when requirements are

sparse or even Ronexistenl?

•

What Is acceptance testing?

•

How does one lesl In agile processes ?

•

What are compatibility, installation. and serviceability testing?

• • Figure 28.1 The context and learning goals for this chapter

How do alpha and beta releases relate to teshng? When Is testing automated?

TESTING AT THE SYSTEM LEVEL

• p~rfonnance . .. Tcst peed of appl,cation

• LoadlSli <55

..•

Test against heavy event Ira ffic • Rdiability and Availability ' " Determine percenlage up · lIme • Recovcnbility ... Test ease with which application recovers from cra h • Usability ... IXrermine degree of user sa ll sfaclion . • Security ... Determine susceptibility to intended and unintended breache • Compatibility .. . Application compatible with ot her systems as required • [nslallability . . . Test ease of installation • Serviceability . . . Test ease of keeping up· to-date at customer si te FIgure 28.2 Principal system tests SySltm Irs ling follows integration teslIng . It consists of black box test. that vali date the en tire system

against its requirements. Once all other system tests arc successfull y com pie led, Ihe application is deemed ready for the customer's acceptance testing (Section 28.4 .2). These are related to the requirements and to metrics in that each test measures one or more metrics. System tests are most often conducted by an independent group such as Quality Assurance . During system testing, compliance with both the functiona l and nonfunctio nal requirements is validated. Recall fro m Chapter 10 that functional requirements specify services Ihat an applicatio n must provide (e.g., ''fhe application shall compute the va lue of the user's tock portfoliO .") . Nonfunctional requirements, o n the o ther hand, descnbe a quality or behavior an application must possess. Examples of no nfunctional requirements include performance , usability , and compatibility . Figure 28 .2 summarizes various types of nonfuncll onal systems tests. Since system tests ensure that the requirements have been mel , the y mu t systematically validate each requirement specified in the SRS , including each of the usc cases. Whenever possible, system tests are performed on the applkation "Inning in its required environment This is not terribly complicated ('or an application that is intended to run on a PC, such a a ca lendar program , although even for simple platforms we sti ll have to be concerned with complicating issues such as the versIons of the operating system . However, many applications ca nnot be fully tested in their eventual environments. This certainly applies to space-based applications, for example, with somc times d,sastrous consequences The Mars Climate Orbiter spacecraft i a case In point. It veered of( course , resuillng In a lo -s of hundreds of millions of dollars. According to Cable Network News, the Investigatin g board's chairman reported that the root cause o( the loss of the spacecraft was a laded tran,lat ion of English units into mctTlc units and a segment of g round . based , navIgation . related nll' ion so ftware . T csting for thiS and other requlreme nls had to take place o n a grou nd -b.-cd Ie t bed. In analogy to the two pronc lpal forms of rcq ulre m c nt ~.f'lll Iiollallnis leSt the fun 1I 0 nai rcqulrtmcn!> of the system, and nonJullclionll/ INl s the qua"lle, and behaVIor o( the sy
695

696

CHAPTER 28 TESTING AT THE SYSTEM LEVEL

the- req ui re ment ha ve been ful fl llcd, makc up th e 111 311'1 functiona l tes t

~ct. The main nonrunctlonal tests arc

In luded in the lon te
28.1 FUNCTIONAL TESTING Functional system tes ts focu o n ho w custo mers will use th e pro duct in real li fe Use cases a rc a primary source of functIOnal requirements As an example of testing a usc case. reca ll the fo llOWin g Encounte r usc case. EHgag(

For(igt'

ClJart1CI(r , from the customer req uirements.

I . Encou nter displays th e fo reig n charac ter in the same area as th e player's.

2. Encoun ter exc hanges quality values between th e two c harac ters. 3. Enco" nter d isplays the results of the engagement. 4. The user h ilS the "OK" buno n. 5 Encounter di plays player's charac ter in a rand o m area. To test th is. we may begin playing the ga me unt il an engage ment tokes place and is o bserved. as In Figure 28.3.

Currenl lif e 001,'11, !IT !I

Test Slep

-.:....:..2.:.•:. .:. :3. and

CUl1'entonJue

so ~ 80fof, lasl encoul'ller" 10 0

-

Step 5

Figure 28.3 System testing of Encounter video game Engage Foreign Character use case

FUNCTIONAl TBTING

As p.111 of te ting thi Us" case, we <eo that In tep 2 quality values are exchanged. We tum to the detailed requirem e nt< (or qua lity va lues and va hdate eac h. The (ollowing is an example , taken from the Encounter SRS . 3.2.EC.1.2 QUALITIE

OF ENCO UNTER C H ARACTE RS

Every game c harac ter has the sa me sct o( qualities. E.ch quality shall be a nonneg.ti ve Aoa tingpoint number w ith at least o ne deci mal of precI sion . These a re all initialized equally so th.t the sum of their values is 100 . The value of a q u. li ty ca nnot be bo th grealer than 0 and less lhan 0.5. For the firs t release , the e qualities wi ll be CO)Jn'" frallotl , mttlligttlct, patitllct, sfa1tlHltl , and

strmgth. This can be decomposed as fo llows, 3.2.ECI .2 . 1 Every ga me charac ter has the same se t of q ualities. Each quality sha ll be a no nnegative Aoati ng ,pOi nt number with at le.st o ne decimal o( preCISion . 3.2 .ECI .2 .2 Th ese a re a ll initial ized equally

0

that the urn of thcir val ues is 100.

3.2.ECI .2 .3 The va lue of a qua lity canno t be bOlh gTeater than 0 and less than 0.5. 3 .2.EC I .2 4 Fo r the fi rst re lease, these qll.1 itie wi II be (Olletll lrali oll , ;IItrlligrllcr, pal;ntcr , ,'amllla , and

strmglb. • 3.2.ECI .2. 1 is validated by goi ng through each quality o n the srI quallf;'S ,,' indo,,' and ensuri ng th.t each has a deCImal value , as shown in Figu re 28.4 . • We validate 3.2 .ECI .2 by c hecki ng o n Ele na's quahties as the game begi ns

; Elena quality uJldate

.'~"\'~

Total life points: 60.0

Concentration Stamina

120 .0 OK

Fl&ure 28.4 System testing of Encounter Video game

, testing with GUI for setting qualities

698

CHAPTER28 TEsnNG AT THE SYSTEM LEVEL

. Elena quality update

I

'

I

Total life points: 25.563635

~

. fiend status

)(

I

I

Curre nt life POints 25 16364

Current value:

1

Concentration

0.0

Con centration

1°.4

1

-

•

-,

I

Inte lligence Patience

Done ' ~ Before last encounter: 1.3454546

lL _ _ _ _ _ _ _ __ __ __ _ _ _ _ . --

Figure 28.S System testing of Encounter video game testing via GUI for setting and viewing qualities

• Validatin g 3.2.EC. 1. 3 ca n be do ne by redllCing Elena's poin ts o n a quality to less than 0.5 . The result of se tting stamina ( 0 0 04 and showrn g thal Encounter actu all y sets th is imcrnall y to 0 is s(--e n in Figure 28 .5 .

• \VIc validate re qui rement 3.2.EC.I .2.4 by e nsunng that all pro mised qualities arc present and th at there are no additio nal quali ti es. We co ntinue testin g in thi s manner for the res t of the use cases and functional requ iremen ts.

Met n cs fo r fu ncti o nal testing are lIsually based on the requirements, and include the fo ll owing , • Nu mber/percent of detaded req uirements partially, and no t fu ll y real ized •

umber/percent

or detailed

requirements no t realized at

ell!

• Number of hi gh ·level req uirements no t implemented, as pe rceived by th e Custo me r • Number of detailed reqll1remenl not implemc!llcd, as perceived

by

the customer

28.2 NONFUNCTIONAL TESTING Thi s cction dcsuibes several common types of nonfuncti onal testing : performance, load/s tress, reliability

and availability, recoverability, lIsability, security , compalibili ty , installation, and serviceability test ing.

28.2.1 Performance Testing Perfonnance testing vahdates that a system meelS Its specified perfonnancc requirements b b h y 0 servIng t e throughput, or speed of the system. Throughput rerers to the number o f transactions that can be _" . Th e meaning . 0 f a transaction . d epen dson t h c: type of .lpplication that 's L- . procesScu · given amount a f time . d F 111 a • • 1 UC:Ing tes te . or our Video SlO'" apphcatJon, speed could be measured by the l1umbe r of-vldeo rentals th.I can b- P d ' .... rocesse per mmute.

NONFUNCTIONAlTESnNG For a ~31 · tim~ communication system , peed nllght be measured by the number of data packets that can be p~ and forwarded ~r econd. Good requi~ments w,lI have avoided vague statements about ~rfonnance such as 'customer ,csponses should be acceptably fast ' uch vagucness causes problems because the stakeholders can harbor very different interpretation of ' fast : For the video store application, a well·wronen ~rfonnance requirement is 'The appl, ation hall be able to successfully handle a load of 1000 rental requests per minute.' Te t environments such as Eclipse's Test and Performance Tool Platform ( ee Section 28.6) identify the packages, classes, and methods with high execution times, as well as those invoked frequently . Mernes for performance testong are u ually based on perfonnance requ,rements, and include the fo llowing, • Number/percent of speed requirements not satisned • Number of memory use requirements not satisned • Number of s~ed requirements not sati sfled, as perceived by the customer • Number of memory use requirements not sa tisned , as perceived by the customer

28.2.2 load/Stress Event Testing The purpose of loadlstress testi ng is to subject a system to incrcasi·ng loads and to tress it in various other ways to detennine its breaking point. Another way of stating th os is 'under what load does the systcm start to breakt Examples ofthe types of loads used are maximum number of users supported , maximum number of transactions ~r second, and maximum data transfer rate. Once the points of failure are determ,ned we can understand whether the system meets its load ·related requirements. Knowing these limits also allows us to examine the system desi gn to understand those pans of the architecture that arc susceptible to stress, and use this for future plann,ng. A good requirements document speCifics the performance of the applicati on under precisely stre ed circumsta nces. As an example, suppose we have the fo ll owing performance req uirement. Th, sot, shall halldl, custOll"r v,sits with a maxi",,,m of fD stcollds wait "m, "ndtr th, followillg conditions. VISIts occur in a Pois son (probability) distrih,,"on with at, avtrag, of fDO ptr IIIill"t, Each ordtr is ai' avtrag, of 2 books, distrib"t,d IIonllally with a stalldard dwia tion of 1 . An example of a loadlstress test based on th is requirement is the fo llowing. Visit th, sil, for 10 mill"ttS with an aotrag' of 100 c"stomm ptr mill "t,. Each ord,rs at, a"trag' of 2 books, w,tb a standard dwiation of L Rtcall that the Poissoll distrib"tion si mul ates arroval times at a queue, the st""dard dwiation measures the extent to which data varies from the mean . For examp le, a variance of zero ,n the orders of the above requoremen! would mean that exactly 100 customers ca ll every minute O nce we va lidate the system ca n handle this load , we increase the number of cu tomer vi it ~ per minute to determine the point at which the application exhibits a probl em. In many cases, loads and strcss limit arc no t ex ploc,t1}' spe oil ed in a requirements document In th,s ca e, the project manager, QA, o r management decides o n the rargets to be attained based o n the lollowing factors • User and customer ex pectations • Technical lim'ts • Costs of improvement

699

700

CHAPTER 28 TESTING AT THE SYSTEM LEVEL

• Le8~1 advice •

larkct

ond ili ons

• 4xpt'ncncc with past products • Comparisons Wilh competitors' products

T ools such as Eclipse's T est and Performance T ools Platform (TPTP

see Section 28 .6) provide the

number of objec ts rca ted at nlntimc and the amount of memory they consume. V arious gra ph ica l devIces art:

prOVided th.t sho" a "thermometer" reading o f memory consumption (min to ma x) by mo uSing over a sequence diagram of h.nction Invoca ti ons. Tc'S tcrs seck ma ximum and near·ma xlmum rea dings . The sequence diagram

can be ge nerated fro m the test execution . TPTP shows how many objects refere nced a give n object at runtime. MetriCS for loadlstress testin g include the fo llowing , •

'umber/ percent of load/stres requirements not satisfied

•

umber/ perce nt of loadlstress standards (industry or company) not satisfied These can be decomposed by types of loads and stresses.

28.2.3 Reliability and Availability Testing It IS an implICit requirement fo r every application th.t it be available for usc! Sometimes it is acknowledged that the system will have defects or th.t it wi ll not be able to survive defects in its environment (e.g ., the opera ting sys tem) and will crash at times. Rtliabi/ity "lid a"ai/ability assess and measure the extent of this. Relia bility and avai lability arc ty pically measu red by the mean time between fa ilures (MTBF). T o obtai n MTBF, a defillition of "failure" is first specified-for example, a crash of the appl ication that requires its reload. Several different levels of failure ma y actually be defined and used. To compute the MTBF. a tester start.s the application and notes the time. He orshe then executes the appl ication using, ideal!y, random scenarios until the system fa ds. The elapsed time is computed. This process is performed repeatedly; the MTnF is the average of these times. Obtai ning a very reliable value of MTBF involves hiring people to use the applicatio n according to some controlled rules and procedures. Gathering these data for man y hours requires significant compensatioA for testers. Naturally. one tries to gather the data while users are using the application for another purpose. However, the other purpos~r purposes cannot be permitted to bias the results. A related technique is to have a large body of users exercise the applICation in advance of its official release (see Section 28.4.3 concerning alpha and beta releases). To obtalll an MTBF, it is necessary then to estimate the number of users and the lime they spend using the application. As many know, the gathering of this kind of data continues even after a prod uct is shipped. as in the pop·up message "Please send us notiRcation of th is fail ure . .. •

28.2.4 Recoverability Testing Many otherwise excellent applications crash from time to time, The reasons may be beyond the control of developers, such as power outages. A good SRS specifics what should take place when an application crashes. A common require ment is that, whC'n restarted , the application returns to its state at the time of tht: crash. This is a rrc01JfI'ab,lily rcqul,,,"ml. Anothercommon requirement is for a designated log ~Ie to conta',n a . I . f h .

.

n exp anahOn 0 t C

crash s cause (ratherlike an airplane s black box). As an example of a recovery techn 'Ique con d h"b k • • $1 C'f( e ac StOP technique employed by Tom VanCourt on the Encounter video game The code ,' s ho . L' . wn In I tlllg 28. 1.

NONFUNCTlON.Al TESTING

28.1: Recoverability in Encounter video game

INbliC: .tatic: void main( Stringl] argv) { try {

// Create the main applicat ion wi n dow . 1!n&1 GameMain gameFr ameM = new GameMain ( ) ; g ameFrameM . addWindowListener ( new windowAdapter () { public void windowC losed ( WindowEvent e ) { Sy s te m. exit(O) ; } public void windowClos ing ( WindowEvent e ) { gameF r ameM . dispose ( ) ; }

)

} ;

// Set frame to a workable size . The size given here is only // approximate , since the frame can be resized and the layout / / manager can adapt the content over a wide ran ge of sizes . // Ad d in approximate amou n ts for window frames , etc . gam eFr a meM . resize ( GAME_AREA_WIDTH + 25 , GAME_AREA_HEIGHT + THUMBNAIL_HEIGHT + 25 ) ; gameFrameM . createGameUI ( ) ; // Set up the user interface . gameFr ameM . show ( ) ; // Display the win dow . gameFrameM . validate () ; /1 Display the win d ow co n te n ts . gameF r ameM . toFront () ; // Start in front of other wind ows. } catch ( Throwable thrownException ) { // Backstop exception handler : Catch any exceptions not already I I hand l ed elsewhere and try to get debug informatio n fro m them. / I Runt imeExcept ion obj ects , in part icular , can be thrown by // any method wi thou t hav ing been dec lar ed in a ' thr ows ' clause . System . err . println( thrownException . getMessage() ) ; thrownException . printStackTrace( System . err ) ; }

}

The effect of this odc i to trap excep tion, not hand led elsewhere and report them before the applicataon stops. One can tc~ t for thl at :hc system leve l by entering ill ega l valell's suc h as 10 '0 for strength value of a qlll1lily . M e trics for 10acVs tre.- tc ~ tin g include the fo llOW ing: • Number/ percen t of rc ove rabil,ty reqUireme nt > nOt
701

702

CHAPTER 28 TESTING AT THE SYSTEM LEVEL • Frequcncy of auto· recovery compared with thc deslrcd auto ·recovery frequency •

tcan recovery time

• Mean r('S tart time

28.2.5 Usability Testing U,./lIlily ''' 1119 va lidates an application's acceptability to Its users. Thc primary goa l 01 u ability testing is to ensure that the application sa tisfies Its stated u ability requirements. These should be provided in the SRS In quanrified tem1 S, toget her with the manncr in which the deSIred quantities arc to be measured. Kit [ Il lists the overa ll critcna in Figure 28.6 as csscnrial lor usabi lity tcsting. For example, wc might reqUirc rhat a random sample of 30 users of our home finance application rate the application o n a scale of 0 to 10, as shown in T ablc 28 . 1. An inspection of the accessibility results shows that our application scores about 12 percent lower than the industry average-some cause (or concern . Our va ri ance is lower than that found In industry, however, which means that the sampled users agreed more on

• Accrssib,/,ly How easily can users cnter, navigate, and exit ' • For example , mea ure by average time laken to ... • RcsponslIJnltss

How rcady IS the application to allow the uscr to accomplish specified goals? • How often IS CUI display accurate (pe rce ntage)? • How quickly arc user actions ack nowledged? • How oftcn is the application rcady for user actio n? • EfficifflCY Degree to which the number of required steps for sclected functiona lity is minimal • "Minimal" calculated theoretically • For example , measure

by

minimal limclav('ragc time

• Compr
Figure 28.6 Key attributes sought in usability testing so..n-to. Kit. &1Waro. SOftware Testing in !tie Real Wor1O Impn:Mng the PrOCt"SS. Addlson·Wesley, 199$

Table 28.1 An example of usability scores

Score

Vat1ance

Industry average score

Accessibility

8.1

2.1

8 .2

3.5

Responsiveness

9.3

3.2

5.0

3.0

7.2

1.1

6.0

0.3

Quality

Efficiency COmprehensibility

5.6 2.3

2.0

O.S

+

Industry average vat1ance

NONFUNCTIONAl. TESTING

thIS seo"' .than u ~rs t pically as",e on the usabiloty of a UI. This tell< us thot a smaller percentage probably acru.lly dl Ioke uson g our applocatlon than i u ual. The appropriate ample sIze depends On the desi red probability of an erroneous conclusion. If we want a smaller probabiloty o( Cllor, we need a large r sample. Usability data can be collected on a controlled or uncontoolled environment. In a contro lled envi ronment , subjects arc o bserved and data like the following are obrainerl: • Average time for the u er to comple te deSig nated functI o ns • The rate of user errors on desig nated interactions • Average time take n to learn new function • Average time taken to complete d eSignated tasks (e.g., crea te a letter in a word processor) • The results are compared with required , compan y, and industry no rms. Users arc very sensitive to applications with which the or experience deviate much from what they arc used to . In designing usabili ty questionnaires, the challenge is to obtai n data that enable engineers to remedy the most serious shortcomings without exceeding the lim its of user ' time and patience Alling out questionnaires. Usability data can be expensive to collect because users often expect compensatio n fo r the time and trouble of providing detailed feedback. For example, a client of o ne of the authors develops software for a device used by physicians. The company provides a free dinner and signiAca nt mo neta ry compensa tion in return for viewing and commenting on screen sho ts and demonstrati o ns Turning now to uncontroll ed environments, Figures 28 .7 and 28 .8 show the beginnings of the Purdue Usability Testing Questionnaire [2], which provides useful data from which to assess the value of and potential improvements in a set of CU ls.

28.2.6 Security Testing Security testing co nsists of id enti fy ing securi ty defects and measuring the extent of an application's security . Recall that some princi pal aspect of security are those Ii ted in Figure 28 .9. We can base securi ty testong on these. The I.esting ca n be performed by using or imulating interception of traffic (called "sniffers"), usi ng software that attempts to break systems, such as sc rip ts that repea tedl y try pa<sword break -ins, and by uSIn g people of varied skill leve ls to try delibe ratel y breachong the desig nated security aspects . At the hig h end of this spectrum o f skills are people wi th experie nce '1, acking." A hi gh leve l o f Sc urity clearance i< required fo r them . Usi ng hacker ca n prese nt majo r problems whe n an external co nsultong company i the o nl y alternati,'c and especially when the experie nced people have bee n invo lved in unautho ro zed activi tIes in the pa t The OPtto Sou,Ct Security Testooog Methodology Mml u"' (OSSTMM ) is an Opell standard me th od o logy (or performing secu ro ty tests [3]. OSSTMM focu<es o n the technica l detail . o f which Iteon need to be tested , what to do during a sccuroty tcs t, and when dlffcrent type< of securi ty test. shou ld be plTformed. A checklIst for confide ntia lity testIng in in forma tio n secu rit y, parti y ada pted from OSSn,1M , includes the fo llOWIng actions_ o me arc part of non -securot y lest lng as we ll , a o ne co ntlnue< to re ognize thnt many se urity breaches SImply exploit a defect In the ohware • Validate conflde nlo al d atabase 10 alo o ns • Scr e n all dat.bast:s for co nfide ntoal co nt en t

7Cd

"g n

Purdue

~

Questionnaire 11><>1111'/7 ofDf6
"""on.

oCpE.nU

g1 '" '"

iil :;j

Z

"~

PIe ... raIe th. u.ability of the system.

J!

m

II>

Try 10 respond 10 all the items. • For Items tlw ate not appbcable. use NA o Make run: the •• 6elch are 61!ed in. System: Email I. :

-< ;ri

o

II>

;:

t2

• Add a cOUlment about an dem by c~cking on its II Icon, or add comment fields for aU items by cbckmg on Comment All.

To mail III your result•• chck on: Mail D.,.

o

J

Syrtam.l_

-. ..".-, -- ..--.,....

-~

.

.

..

"'~'-'~-~'-

r

j-

r

Email I,,, r~_ _ _ __

commenlS and your et:naJl address

r/.

m

to the bOK

_,",.",.~

~~;'.;..t.1- . .",,_r~ RF:TURN TO REFERRINO PAOE

1. \,;um rAU"",u:1' - - - - --

I. Is the control of cursor compatible with movement? 111

bad

2. Are the results of control enb'y compatible with user expectations? GIl

bad

3. Is the control matched to user skill? ,.

bad

4. Are the coding compatible with familiar conventions? lD

bad

5. Is the wording familiar?

bad

FIgure 28,7 Purdue usability questionnaire fragment. 1 of 2 Soufu Plldue usability T6 Ung Qu
1 1 3 4

5

6

7

r r r r r

r r r r r

r r r r r

r r r r

good

('

good

r r r r r

r r r r r

r r r r· r

NA good good good

r r r r r

6. Is the assignment of colour codes conventional? C

bad

r:

2 11 S J[ ot u-S II'! 0 0 () (j 0

7. Is the coding consistent across displays. menu options? C

bad

0

0

0

0

(j

8 Is the cursor placement consistent? C

bad (j

(j

(j

(j

0

9. Is the display fOllllat cO!lS1stent? C

bad

0

0

0

0

0

10 Is the feedback consistent? C

bad

0

C· C 0

0

11. Is the fomlat within data fields consistent? C

bad (J

0

r

()

C

12, Is the label format consistent? C

bad (J

0

C

(J

C

r o good 0 r C good C ('. r good r 0 r good C r C good 0

13 Is the label location consistent? C

bad

r: 0 0

r·

()

r. C

14. Is the labelling itself consistent? C

bad

0

0

0

0

r: c

C good C

15 Is the display orientation consistent? -- panning vs , scrolling. C

bad (J

0

()

()

0

16 Are the user actions required consistent? C

bad C

0

0

0

C 0

17. Is the wording consistent across displays? C

bad

0

0

C

r

C 0

18. Is the data display consistent with entry requirements? C

bad C

(",

0

0

0

(",

19. Is the data display conSiStent with user conventions? C

bad C

0

0

0

0

0

r o o o o

20. Are symbols for graphic data standard? I::J

bad

0

0

0

(",

0

C- O good 0

21 Is the option wording consistent with command language? I::J

bad

0•

0

0

0

0

0

22. Is the wording consistent with user guidance? C

bad

0

0

0

0

0

0

--

Figure 28 ,8 Purdue usability questionnaire fragment. 2 of 2

.source

P\KOue vsabdity Tescng QueslJoMaire. httDl /WYM acm Ofg!- perlmanlquestion cgi1form",PUlQ

"

C good ()

C C

~

0

o o

C

good

good C

good

r

good () good

0

good

0

good

0

good

0

good

0

-

z 0 z ."

c: Z

!:l (5 ~

r-

~~

~

706

CHAPTER 28 TESTING AT THE SYSTEM lEVEL

• ConRdenti.lity • ",ffers vahdate that d.ta passed not vi sible to unauthonzed p.rtles • Hlrc profession. 1 hackers] • Nonrcpudiation • Experiments to va lidatc • Integrity • Alter data .nd validate consequences • Authentication • Hire profeSSional hackers) • Authorization

• Hire professional hackers) Figure 28.9 Testing (or security

• Valid"te cookies •

Content, types , expiration , and encryption

• Check for buffer overflow protection • Check for memory leaks • Test for illicit site navigation

• Validate Sign -inS • Include default IDs and passwords • Check protection against illegal and out-of-bounds input (not necessarily input that allows breaches) Merrics for securiry testing include the following . • Number/percent of specific security requirements not satisfied

• Number/ percent of security standards (industry or company) not satisRed • Confidentiality: Average time required to gain disallowed access to informa.tion • at a specified level of security • by testers of a specified degree of training and expenence • NonrcpudiatlOn: Average time required to repud iate agreements • Integrity: Average time required to alter data in transit , undetected

• Authentication; Average time required to verify identity • Authorization : Average time required to gain disallowed access to a location

28.2.7 Compatibility Testing Many applications arc designed to work with other applications. For example a word pro h II . . . . . Ceisor t at a ows the Insemon of a ~prcadshcet must be compatible With the spreadsheet application Anoth I . . . fr I -h . . . or examp e IS an application that obtainS data om peop e Wit mobile deVIces of variou.s brands Com 'b ' I' . _ ,

patr

I

Ity testing

IS

NONFUNCTIONAl TESTING

s.milar to integrat.on te ting III that it tests the interactions between parts of an application. The difference .s that the Interfaces are typ.cally developed by different organizations, and developers normally can't change the applications with which they mu t be compatible . An important subfield of compatibility testing is assuring that the application operates w.th deSignated past ver<.ons of software on which it depends . This includes versions of the operating system. An example is an online learning env.ronment, wh ich must work with various versions of Windows as well as with UN IX. Compatibility with future versions can be planned for to some extent, and it is sometimes possible to si mulate upcoming changes. Testing must include combonations of versions. Metri~ for compatibility testi ng include the following , •

umbe r/percent of speCific compatibility requirements not atisfied

• Number/ percent of compatibility standards (industry or company) not satisfied

28.2.8 Installation and Installability Testing An installation test validates that an applicati o n can indeed be install ed. An instal/ability te t is a more general concept in that it tests via installation test cases whether an applica ti o n can be installed o n a va ri ety of configurations. Installation tests whether an appltcation ca n be successful ly .nstalled o n its targe t system . These are binary canlcan't tests Many types of errors can occur during insta llatio n, espec.ally du c to the djfferences in hardware and software platforms. Applications are often required to execute o n multiple hardware and software platforms. Multiple platforms typically require separate tests. For example , .f our v.deo store app lication were required to execute on Windows and Macs with Internet requirements, we wou ld devise tests that ensure the satisfaction of the requirements on each of these platforms. Although we try to develop applications that arc plat fo rm independent, thi s has limitati o ns. Fo r example, we may need to te t with separate bar code readers for Windows and Mac platfo rms . Installatio n tests would be ide ntica l for the most part but would contain Windows·specific and Mac·specific parts. Once we have tested that an appltcation can be installed correctly, we run a second tier, co n ISting of installability tests that measure the level of d iffiwlty of installing the application . As computer u ers we are all too famdiar with how easy or how hard it is to install an app lication . Installability tests thi s proce S and the aspects of the application that make this easy or difflcult. Metrics for installation and insta ll abilty testing include the fo llowing , •

umber/percent of speCific in tallability requirements not sa tisned

• T.me required to install o n deSignated platform by custo mers with designated amount of expert en e or education • Time required to co nnrm installation intcgrity via a standard test seque nce • Number of d e fec t~ found durtng .nstallation, with "defects" carefull y defined

28.2.9 Serviceability Testing Serv.cing an applicat.on .s the pro css of repainng or enhanci ng it This could include visiting the itt and sending a full or partlal replacement ovcr the Internet. An applicatjon '~ strVlCcah,lity refers to the ease or dtlfi tllty w.th wh. h it an be kept opera t.o nal In the face of changes to .ts envlfonmcnt. For example, an expert system appltca t.on reltes o n Its knowledj:e base typ.cally in the form of a \et of rule., whKh may be straightforward to moddy Another exampl e b the ca<e

7m

708

CHAPTER 28

TESnNG ATTHE SYSTEM LEVEL

with which an appJ. Juan that nlns o n o ne versio n of an opcra tlnH sys tem can be made to run on Its successor

umber/ percent of spcCllk scrviccab.!lty requirements not 311shed

• Number/ percent of serviceability stand ard (,nduStry o r ompa ny) no t allsf,ed • Time reqUIred

to

sC r"\' lce

actions on deSignated platfo rms

28.3 TESTING WITH LIGHTWEIGHT REQUIREMENTS Th is secrion di scusses tc tln g in the co ntext of requirements that range from being not written duwn at all (Section 28 3. t) to betng o nl y partially expressed in writing via the user stories of ag tl e processes (Secti o n 28 .3.5 ).

28.3.1 Testing in the Absence of Requirements i\4ost of the softwa re engineenng literature emphasizes the importance of requirements a nd the execution of testing against th ose requiremen ts. Hi g her CMM levels arc bestowed only on those organizallons that wnte down reqUirements thoroughl y (see Chapter 6 ). However, man y real · world applications have Incomplete or even nonexistent requireme nts docume n ts. Our concern in thi s chapter is how to rest such applications . Even when requi remen ts do exist in written form , the)' generally cannot prOVide a very good feeling for [he apphcation compared with running code. This is like the dif fe rence between drawin g detailed plaAs for a house and living in the house after it is built-they arc simpl y not the same. In fuct. if we want to determine whether a hou.se that is already built satlsnes needs, it is more useful to ask the occupants thaa to inspect the architect's drawings. Figure 28 . 10 summarizes the reasons for res't ing wit h little or no reference to a re::quirem ents document .

Suppose that yo u have been asked to test an applicatio n for which there is no requirements document. Where do you begin ) In the next sections, we'll describe a starling poi nt, a h,haDiora' ",odel of the applica ti on .

• PrOVides a "feel" for the application Even complete , wnnen req uirements do not accomplish this effectively • The Requirements document omits implicit ones

• The ReqUirements may - be incomplcre - be inco nsistent With the code - be missing - never have been written down at all • You can't access the requirements because the product is from Vendor software that you must test before using

d

third party

Figure 21.10 Reasons to test without basing the tests on written requirements

TESTING WITH LIGHTWEIGHT REQUIREMENTS

28.3.2 Models for Software Testing To tcst an applicatIon 10 the ab cnce o( \vell -wrltten reqUIrements, the tester needs a .cnsc o( how thc applicanon is meant to beh. e and how it actually behaves. ThIS IS ca lled btl,.1IIo",/ moddillg . Mo t o( us have alread had a behavioral modehns expericn e In dealing with an unfamdl3r application. Although we may road the manual or follow a tlilo nal , we often si mpl y ' play around" with the application . Th, s cCtl on conCerns dLClplined ways to "play around" with the goa l of fi ndlOS as many defects, as serious as po sible, in as little nmo as possIble. ThIS is not the black·and -white proces of requirements-based tesllOg, and it is someti mes called 3n "arl: Good artist . however, arc extremely well -dis iplincd, and good testers are too. Onc approa h to forming the concepts of an as· built (already constnlcted ) applicati on is to u e the software design models that we covered in haptcr 15 These are the uS! .It modds, clnss modds , dtllnJlow ,"odds, and slalt mo.lds. These arc valuable (or creatIng desi gns o( applicat Io ns yet unbuilt , but they are less 0 (or modeling already -built applications. Table 282 indicates whcn these deSIgn model could apply to behavioral modeling of already-bu ilt applicat Ions ThIS suggests that a different or modified model shou ld be soug ht , as di scussed next. Table 28.2 Applicability of various deSign models to black box testing of as-built applications oeslgn Model

Applicability to As-Built Black BOX Testing

use case Model

Apply use cases to identify the main, unbranching behavior Typically not especially useful for black-box testing Possible if the tester recognizes principal functions Possible if the tester recognizes states that the application transitions through

Class Model Oata Flow Model State Model

28.3.3 Constructing Directed Graphs for Black Box Testing

w. will

use the concept of dlrtcltd gmpiJS in what fo li o"" . A directed graph is a Rgure consi ting of node , together with arrows between certa in nodes, called tdglS , illustrated in Figure 28 . II The meaning o( nodes and edges depends on the conlext in which they art app lI ed

node

edge

Figure 28.11 Directed graphs

709

710

CHAPTER 28

TEsnNG AT THE SYSTEM LEVEL

3 ~---

1

4

Actions • Launch text document processing • Enter leX1 • Hit liIe / save • Enter a file name and press save

An action

Edge Indicates sequence (only one in this case)

Figure 28.12 Initial directed graph for OpenOffice

O ne approach to modeling as· built applications is to sta rt from what appears best to be a beginn ing point of th e application , and then keep track of the paths from th ere In directed gra ph form . Each node represe nts an act io n performed by the user o r the appli cati o n (someti mes a seque nce of such act io ns instead). Each edge leads to the next possible act io n. Edges arc labeled ",hen necessary to distin gu is h options. This use of nodes and edges IS neither data flow nor state/ transition. It can be tho ug ht of as a control flow in that each node represenlS a point at which the applicarion i in control.

As an exam ple, let's perform th is for the word processor of the open source ofRce suite OpenOfRce. Besides servi ng as a means forblack box testi ng, a directed graph is a means of ge tting to know the application. Figure 28. 12 shows the ~glnning of a directed graph for executing OpenOfRce's "Writer.' its word processor. Si nce thero is no branching in the example o f Figure 28 .12, there is no need to label the edges to understand the seque nce of actions. In Figure 28 . 13, o n the o ther hand, there is such a need. Branch points aro labeled as nodes like any other (which makes these diagrams different from o thers we have studied in this book). Figure 28 . 13 shows a continuation o f the graph ing process. The numbering serves o nl y to label the nodes and docs not denote an o rder. The la~ls on edges are used to assist in d ifferentiating among branching o ptions.

1\-----

s:::- savebold

Actions 1. Launch text document processing. 2. Enter text 3. Hit file I save as 4 . Enter a file name and press save 5. Convert 3 line to headings at levels I .

save

4

headings ~

[Pred icate

nOde)

7

F

2. and 3

T

6. Bold some lext 7. File exists? 8. Hit save ' "already exists" pops up ,

FllUre 28.13 Elcample of a directed graph for OpenOffice

yes

8

TESTING WITH LlGtfTWElGHT REQUIREMENTS

- - -1

-

. save -

"

Palhs:

--- - -~

- ->

·• .. headings •

bold " " '"

Actions '. " 1. Launch text document processing. 2. Enter lext 3. Hil file ' sa VB as IPredicate 4 . Enter a Ii Ie name and press saVB node] 5. Convert 3 line to headings at levels ' . 2, and 3 6. Bold some text 7. File exists? 8. Hit save '"already exists' pops up ' yes

save / /

F T

8

f"tgUre 28.14 Using a directed graph for testing-openOffice example

• The most .,xpected path s with no e rror o r a no maly condit io ns • Th., most expected paths with error or anomaly co nd iti o ns • The paths most likely to Yield defects Figure 28.1 5 Selecting paths in directed graphs for testing

28.3,4 Using Directed Graphs in Testing Tests are de igned via sequences that traver e mult ip le no des. A reasonable goa l is to crea te enough of these to cover all nodes. (Attempting 10 cover all pnl/, co .. blllalioll' exposes more defects but usually leads to a combinatorial explosion in the number of poss ibilities.) Figure 28 . 14 sh ows Ihree paths that cover all nodes , The number of eque nces made of these path s ca n be extreme ly large . The tester can be elective among these as in Figure 28 IS , h owever.

28,3,5 Testing for Agile Processes As mcnlloned in previou c hapters, continual tes ting IS an IIlteg ral part of agi le proces os, especiall y via utilities such as JUnll and N Unit Allh oug h suc h tests focu, on a method under constnlction , a growing , cumulative set of unit tests ca n e ffe c ti vely te,t large parts of an app lica ti o n as it grow . A sU ite of jUnit te t , grown mel hod by metho d and class by la, (as In hap ter 27), rn a be part! usable for functional testing ( , e , to check that the rcqullcme nls have been . at"Red ) H owever, Invariab ly there will be reqUirements for whl h th 'yare not a pp ropria te , uc h a th o.e that reqUire user intera tl On The follOWin g kinds of teS lin g arc ca rn ed o ul for a!,l dc rroJ,:c t\ In the sa me wa y a, for non . ~gdc ones

•

onfunctlona l tcst lll g (pe rfo mla nce, 10aeVs trc", cvcont, rc ovcrab ,hty, lIsab ili! , SeCliftry, o illpatibil itv ,"stallatlon , servlceabdit y)

• Accertancc tc,tlng (a cnlr. I part of Ih ' a~ d c approa h )

711

712

CHAPTER 28

TEsnNG ATTHE SYSTEM LEVEL

28.3.6 Qualities of a Good Tester - g 0 r 's bu I It applicallons. A good tester, We have described various tcchnlques fo r t hc blac k' I)OX te.Sttn however, goes well beyond them In hIS or her efforts In tryi n!: to ferret out defect that could be encountered _.,111 an t time ' ., per. Il aps In u nant, c,pated ways. He orsh. .shou. ld w hen many people usc the appilCJllOn ror J sign U

·

be an Independent th,nker and should not be part of the tea m that deSIgned or ,mplemented the appllcat,on under test. Thi

IS

bcc~u~c ('ven

the most Independent pc:r o n involved

a vlS,on of the app hcall o n that , eve n when excellent " following arc o rne of the qualities of a good tester:

In

dcc;lgn or

Implemcntatl~n

develops

likel y to overlook or misunderstand ISsueS . The

• Willingness to learn goals of applica tio n • Wdlingness to pu t self in uscr shoe< • Dcterrmned • Dogged • Fearless • Imagi native

• "Outside the box" thinker • Curious

• Meticulous

Let's translate these qualities into the testing of OpenOfr,cc. T o fi nd as many defects as possi ble within a fixed amount of time , the tester would need sufficient detenninatlo n to go beyond the obvious ways of using the application This is because the com mon procedures will probab ly have been exercised many times and thus have been debugged . The tester would need dogged nes< to stay with h, or her intuition concerning lurking bugs even when it yields few initial bug finds . In the nonnal usc of an application , users tend to be relatively gentle . For example, the y avoid hitting a cont ro l-X butto n while a fi le is bein g saved, o r pressing many keys in rapid succession, including functio n keys. A tcster, on the o ther hand , need the fearlessness to stress th e application In such a manne r.

There is another sense in which testers need to be dogged: ge lling actIOn on the defects that they And. Kaner [5] notes that Anding 'lnd obtai ning action o n discovered defects i significantl y mo re important than simply fi nding them. H is pOint i that the time spent discovering a defec t i wasted if the defec t is never repatred. It is certainl y the task of QA to ensure that qual iry is present. and this includes en uring appro priate actio n o n def(·e ts.

T t'Sters need enough imagination to think of many different ways of usi ng the appl ication . The)' need to · think out ide the box· because defects arc usuall y found in execution paths that arc not obvious. For example, in testing the OpenOfAcc word processor, a good tester would pursue sequences very different from the nln ' of·the- mill opm fildtdillsavt sequencc_A more de111and ing sequence is opm fllrl..,ld 10 1i""ISt' Somt Ii"" '" II
TESTING SHORTLY BEFORE RELEASE

28.' ~STlNG SHORTlY BEFORE RELEASE Every project ha, a hi tory of testi ng lasti ng almost as lo ng as the projec t Itself. H owever. the period JUSt pro or to relea,ing the appll aloon has specia l testing characteristics. which are described in thIs sectIon.

28.4.1 Soak Testing h is common to conduct loak 1<s/on9 ncar the end of the system testi ng phase. During soak testing the applicaroon IS executed In an environment that simulates as closely as pos ible the way a tYPIcal customer WIll use the sy tem under no rmal load . The soak lest is conducted for an extended penod of time for eX.IIOple , twO weeks. rest scnp~ are used so that the testing can continue for the entire duration wilhout intemoption . The purpose i to uncover problems such as memory leaks and timong.related is ues that only manofe
28.4.2 Acceptance Testing In principle , the customer contracts with the developer to build an application . At ome POonl, the developer claims to have fulfilled his or her part of the contract, the cuStomer validates this , and then pays for the application if satisfied . The customer performs thl validation by means of ncaplalla 1<sls In pnnclple , these arc most important for all concerned . Acceptance tests can be executed by the custo mer, or by the development organization-in ome sorr of clearly demonstrable manner on behalf of the customer. Acceptance tests arc lYpically driven by the SRS . A subset of the system tests i selected that valodate maJor funerional requirements and selected nonfunctional requirements. It is a realiry of software de velopment that deli ve red applocatlons contaIn defects. If a con tra t were to stale that software will not be paid for if a defect IS found , very few compan Ies would ro sk deve loping software. Defects therefore have to be factored into contracts There arc several ,,'ays to deal WIth this, mostly legal In nature, that relieve the devel opment orga nIzati o n of a degree of responsibility . Recall that soltware ~an meet all its requireme nts ye t nOt meet the II"dl of the custOmer. o ntrac ts attempt to navIgate the gap between customers, who want appl, cation . that arc satISfactory to them (" ' rot te n or not ), and developers, who need to work WIth wcll ·dcflllcd ends. Acceptan c testong IS planned and tonducted accordingly. Metrics for acceptance leStong are a subse t of those covered so far In thIS hapter, by mutual agreement between the customer and devel oper, made In advance.

28.4.3 Alpha and Beta Releases Th,s sectIon concerns ap pll ato o ns Intended for usc by a large number of pc pic A oftware product versIon I rtl"",d when it os officially turned over to CUStomers. This usually take. place dorectly after a ceptan e tecs , I,,'n "Ira'" arc ~ Iven Out 1 he e arc

713

714

CHAPTER 28 TESTlr.jG AT THE SYSTEM LEVEL

/"-/'0"" a"d

hig/I/Y !M"J

"sc,..

• Multiplies tes tlll g • Prcvlcw~ custo mer rea c ti on

Alpha

• BeneAts thlrd -pany deve lopers • Foresta ll co mpetitio n

c/ected cU5tomers • Multiplies testin g act ivity • Obtains c usto me r reactio n

Beta

Figure 28 _16 Alpha and beta releases

give n to part of the custo mer co mmun ity wi th th e unde rs tandin g that they re po rt defects fo und . Alpha and bet. releases are also used to co nv mce potential custo mers that th e re rea ll y is a product behind th e vendor's pro mises. A prinCipal motiva tion to be alp ha testers and beta testers is to gai n advan ce know ledge of the product. Developers can gam informati o n about the appl ication (typica ll y its AP ls) so that th ey ca n begin to d evelop applications that use It. Users can begi n to fo rm decisions abo ut purchasing the application o r gai n •

•

t!xpen(" ncc uSing H.

Metncs fo r alpha and beta testing include the metrics mentio ned so fa r 10 th is c hapter, in principle. Alpha and beta tesllng are generall y not focused o n particular attributes. ll,ei r products are bug reports, which arc ge nera ll y ca tegori zed Metrics include mos t of those already mentio ned in thiS c hapter, as well as th o se with a simpler ca tegorization such as the fo ll owi ng: •

umber of majo r defects detec ted within the firs t x days/weeks/mo nths

• Number of no n-major defec ts detec ted within the Arst x days/weeks/mo nths

28.S CASE STUDY: ENCOUNTER SOFTWARE TEST DOCUMENTATION'

Note to the Student: Th is document describes the overall testing of Encounter. The document uscs the IEEE Standard 829- 1998 Software T cst Documen tation (STD ) headings (in'roduc'ion. plan. ttSt JrsigH. Icst CdStS, Itst proceJwrn . trst .ttm rro"slIIillal "port. ,,,' log. incid.. , "port. ' UIIIlIIary ) and refers to the various particular t~sts (i ntegnUlon tests, system tests, acceptance tesfS, etc.). These, in fum , are described using th~ same IEEE SID headings. Thos~ involved in testing appreciate fhe documentation a

'tS'

'tS' 'tS'

g reat deal since it improves their ability to make applications more reliable .

H IStory of version of th is document: 1111 /98 E. Braude, In itial Draft 4/4/99 E. Braude: Revised 8/23/99 K Bostwick· Documents reviewed and recommendations made I R(produced wit h permiSSion ,

CASE STUDY: ENCOUNTER SOFTWARE TEST DOCUMENTATION

8/2411999

E.

Braude:

integrated

Recommendations

Status: to be completed

game. IEEE standard 829- 1998 for Software Testing Documentation is used at every I~I of testing. The test philosophy for the Encounter video game is summarized in Figures 28. 17 and 28. 18.

1. Introduction This document contains the STD for Encounter and its role-playing game (RPG ) fra mework. The categories of testing addressed in this document include unit • integration, system, acceptance, and installation test. ing. This document describes the testi ng required to validate the nrst three builds of the Encou nter video

Although the SOD is not explicitly a requirements document, it efkctively imposes requirements on the implellientation. Sometimes these requirements are spelled out in a separate document. The case study in this book does not contain such a separate document.

Test Type

Unit

Integration

Approach White and black box; method and class tests, tcst agai nst detailed requirements and design. Gray box; mostly package· level; orien ted to builds ( I, 2 , and 3), test against architecture and high-level requirements.

Corresponding document sections SRS scction(s): 3.2 Classc.IObj,el. SDD sectio n(s): 6. D,'ajt,d dt<jgll

•

SRS sectio n(s): 2. Outrall dt
quirements in 3.2 Classr.IObj,cls SDD sectio n(s): 3. D,compo.ilioll dt
System

Black box, all packages; whole system (Build 3); test against nonfunctional requirements, . r· chitecture and hi gh-level requiremen ts.

quirements in 3.2 Classt
mluirrmruls, 3.4 DrsigH constra;,ds, 3.5 Sofllva" allribult< , 3.6 Olh" "4I1irr",,,,', t

,y,'tm

SDD ectio n(s): 3. D,composlljoll dtScriPllolI , 4 _ D,pmd
Figure 28_17 Approaches to system test and their documentation, , of 2

Acceptance

lostailation

rt:qUlremenrs.

SRS scction(s): 2. Outrall drsrn'pljoll, 3.2 Clams! Obi' Is

Black box, ail packages; whole
SR section(s): 2 Ol'(rall dt
Black box, all packages: whole system (Build 3), test against high-level requirements and detai led

Fleur. 28_18 Approaches to system test and their documentation, 2 of 2

715

716

CHAPTeR 28

TeSTING ATTHE SYSTeM LEVEL

2. Encounter Video Game Test Documentation

n,e5 I 0 for En

<>tin ter and th e RPC f", mewo rk covers

pa koge and the Encoun ler harael'" package It de · scribes how to verify thai the player and foreign c haracters Ca n be retrieved . modi(,cd, and dIsplayed thro llg h the singicton Enco""I"C"" object

lCSt planning. speCifica tion, and reporting . TI'\crc arc

separa te tcst plan for unit, mt'cgnm on, ystem , accep -

2.2.1.1.3 Test Items The classes and method< '"

tance, and ",stallatio n te ling. Each test plan reference< its test design, rc t case, and test procedure spc IRca· lions. The' tcst reporting documen tation consists o( the

th e G",", harael", a nd E"cou",,,Ch.,. I", packages arc te. ted throu g h the EncountcrCast sIng leton .

tCSt 108, incid~nt report , and summary report.

2.1 Unit Test STD Refer to th e separate

UOit

test document .

2.2.1 .1.4 Features to Be Tested The features tested by the tes t desig n speci ftcation Budd 1_ TD ar" based o n the reqUIrements with", the SRS and SDO, as listed in Figure 1810.

2.2.1 .1.5 Features Not to Be Tested See the case srudy in Chapter 17.

2.2 Integration Test STD

•

The 5 I 0 fo r Integration testing consists of the separa te STDs for budd I, build 1, and build 3, as described next. Refer to Appe nd IX A in the SCM P fo r an expla natio n of th e construc tio n of th e build in tegration baselines. T csts will be Ident iRed acco rd · Ing to the convc: ntlo ns shown In Fi&'Ure 28. 19 .

Inevitably, infinitely many points simpl y can't be tested for. but identifying particular issues that will not be tested for sometimes helps to clarify the test ing process.

The testing of th e feature s associated with th e EncoutlltrEnu"onm mt and EncounlrrCamt packages and their fra meworks is deferred until the build I and build 2 integra tio n testing .

2.2.1 Build 1 STD

2.2.1 .1.6 Approach The approach to the ve rifica· 2.2.1.1 Build 1 Test Plan 2.2.1.1.1 Test Plan Identifier Build 1_ TP 2.2.1.1.2 Introduction This test plan covers the integration test for the G. ,",Ch. ,.cl'~ framework

tion of build I consists of verifying that the characters of the ga me can be ret rieve d and displayed through the Si ngle to n EncounterCast o bject. Th e method and interface tests verify that the re quire d (public) inter. face methods of th e Encounter Cha racters package are av. dable from the EncounterCast si ngleton.

Test Document Identifier

Test Document

Document Identifier

Build Build Build Build Build BUIld Build

Build 1_ TP Build 1_ TD BUIld 1_ TC I toBu ild 1- T C .. Build 1_TP I toBuild I TP . .. Buildl _ LOCI to Buildl _ LOC " Build UnRep I to BUilcMJnRcp . .. BlIIldl _SlImRepl to BuildiSumR"p ...

I T est Plan

I Test Design Spocificallon I Test Case Specifications I Test Procedure SpeCifications

I T est Logs I Test Incld"nt Report I Test Summary Report

Figure 28.19 Test document file Identification

-

717

CASE STUDY: ENCOUNTER Document

Section

Requirement Title

SRS

2. 1.2.2

User

3. 1.1.2

User interface for sening quality values

3.2.EC

Encounter characters

3.2 .FC

Foreign characters

3.2.P

Player characters

3.2 .PQ

The player quality window

3. 1.2

Characters package

5.0

Interface description

3. 1.2

EocounterCharacters package

4.2

Interprocess dependencies

5. 1.2

Interface to the Enco"PlltrCharacltrS package

SOD for RPG framework

SOD for Encounter

interf~ce

for setting quality values

-

--

Figure 28.20 Features to be tested in build 1

2.2.1.1.7 Item Pass/Fail Criteria Pass/fail criteria are based upon satisfying the corresponding requirements in the SRS and SOD. 2.2.1 .1.8 Suspension Criteria and Resumption Requirements (N/ A) 2.2.1 _1.9 Test Deliverables The documents listed in Figure 28 . 19 are to be delivered to the conRguration management group at the completion of the build I integrati on test. 2.2.1.1.10 Testing Tasks The testing tash sisl of the foilowlIlg steps:

on -

I. Load build I and Ihe pa ka ge Build_ I. 2 Execule build I Ie I procedures from Ihe malllO mel hod of Bu ild_ ITest ,n package Budd_ I 3 Wme lest report documentall on wllh Sect,on 2.2 I I 9

In

accord.nce

4 Slore ail te
2.2.1.1.11 Environment Needs Depending upon equipment avaiiabil.iIY, either an IBM PC, Sun SPA RC workstalion , or an Apple iMAC hardware configuration can be used. The Eclip e In te · graled Development Environmenl (IDE) should be used for Ihe build 1 testing. 2.2.1.1.12 ReSponsibilities Sally Si lver and Jose Hernandes from the SQA group are responsible for managing. preparing , and execullll8 Ihe bUIld I integrati on test. In addition , the Encounler development group addres es lechni cal quest,on and respond to teSI inCldenl reports. o nAguration ontrol stores aU te st documentation and data.

2.2 .1.1.13 Staffing and Training Needs The SPMP speciAes the ovcra ll stafRnl( and tra,ning need, for integration rel.i tln g

2.2.1.1.14 Schedule The chedul e for lIlle!(ratiOI1 tcstlng ,S 111 luded ,n the P"IP, 'uion 5 VC,",'OIl

and hi gher (

t"Ct!CH\

Iq

d"

tI",CI\

(lu.'

718

CHAPTER 28 TESnNG AT THE SYSTEM LEVEL

upd~tlng

of the

2.2.1.2.3 Approach Refinements

PMP to rene t the arc hitecture

• •

selected ) 2 .2.1.3.2 Test Items The functlonaJ.ty to be te ted is conta ined ,n the pcone.tlons for the follow ,n g publi c met hods of fl1 CO""ltrCasl.

TI,e ca e studies in this book do not include the updated SPMP.

E"co""ltr asl g"n"fl1coll11 I' rCns l()

Gam,(I,a,acltr 9"Th,Player(haracl, )

2.2.1.1.15 Risks and Contingencies

If the SQA

Ga ,",Characler g" Th, FortigllChaTaCI,r( )

tcam is unable to execute tests, or the numberof defects

causes an unacceptable number of system failuTes. then Alfred I\lurray of the Encounter development team w,lI be aSSIgned to the budd I integration test.

void stlPlay,rO,. ,acl,rQual,ty(SI,illg 4",,[ity,jloal oa[.,) oo,d stIFortigllC/UI,"clerQ""I,ty(SI,,"g qua[ity, jloal oalu, )

2.2.1.1.16 Approvals The completion of this test requires the approval of the SQA Manager, the Encounter Development Manager, and the CCB Representative.

jloal geIP[ayerC/'araCltrQlIa[,'y() jloal 9" Fort1911C/,aracl,rQ"al,ty()

2.2.1.2 Build 1 Test Design

ur~

These arc tested in accordance with Fig28.21.

2.2.1.3.3 Input Specifications: see Figure 28.21

2.2.1.2 .1 Test Design Specification Identifier . .

2.2.1.3.4 Output Specifications: see Figure 28.21

2.2.1.2.2 Features to Be Tested The test for build I w,lI get the f llco""lerC,,sl object and the player and foreign characters, change the va lues of various quahtics, get these va lues, and (hen verify their

2.2.1.3.5 Environmental Needs ThIS testing is performed with the Gam,Cba ,acl,'S and fll co,ml,rCbar·

co rrec tness.

actcrs packages alone.

Qu.llry

Phytr input

Foreign

v• .luf:

v.lut

Inp ut

Othu

Action

InCCBr3t1on

Tnt. 81.1

N/A

N/A

N/A

Bl.l

IA

N/A

NlA

Vcnfy by n.lmc

Get

fortlsn

char.lcte r

Verify by name

BI.3

Conccntr.ltlon

30

40

N/ A

Venr output valun __ Input v.llu('<.

B1.4

Sloamlnoa

30

40

N/A

Verify OUtput .".. Iu« •• InflUt valuC'S

Bu

•

•

•

Figure 21.21 Integration test Inputs, outputs, and actions

•

•

CASE STUDY: ENCOUNTER SOFTWARE TEST DOCUMENTATION

2.2.1.3.6 Special Procedural None

Requirements:

2.2.1.4.4 Procedure Steps Po pulate the Ale Build I_test_data with input data and expected output values fo r Ihe qualiti es in the following fonna t.

2.2.1.3.7 Interface Dependencies: None < quality name > < illput > < expected output> This section dcscri~s the ",Iarion hips among lhe various inlerfaces . This becomes signin . anI for fulUr., bUilds, but is not an ISsue for build I.

< quality name > < input> •

•

•

There is no additio nal begi nning o r e nding text.

2.2.1.5 Build 1 Test Item Transmittal 2.2.1.4 Build 1 Test Procedures

Report

... . ..

2.2.1.4.1 Test Procedure Specification

2.2.1.6.3 Activity and Event Entries

Identifier

The ' defect rderence" is the number used by the defect tracking system for Ihis defect

This identines the class/method from wh ich Ihe test is executed.

2.2.1.7 Build 1 Test Incident Report Inregration_ Tests/Build I_T est in package T ests

2.2.1.7.1 Test Incident Report Identifier

2.2.1.4.2 Purpose T o sct up a tesl of build I wilh

Bu ild U cst3

a minimum o f o ther parts of the appl icati o n

2.2.1.7.2 Summary see Figure 28.22 .

2.2.1.4.3 Special Requirements The test hal"

2.2.1.7.3 Incident Description Ed Blake wa d is-

ness in Integrati on TestslBuildl _T esl, m nsisting of a class with a si ngle method, mainO, is to be co n· structed . and tests 1, 2, 3, . . arc to be executed and the results compared.

tracted during the execulion of tesl 3 by an alann in the building, and could no t record the re ui ts It was decided no t to inte rrupl or repeat the test seq uence, and to conducl test 3 as part of Ihe tesling for bui ld 2.

Defect reference

Result

Test

*

Build I Te

t

Log

I

Passed

N/A

2

Fa il ed

1823

3

Dala 10,1 - T o be repca led

N/A

Lost 01prec Isio n in re lu rned value

2872

s

• ••

••

Figure 28.22 Build 1 lest log (summary)

•

•

••

719

720

CHAPTER 28 TESTING AT THE SYSTEM LEVEl

repe t, tlon of lh b lest.

d "played th roug h the Enco"n ltrEnviro",mml object, an d Ih ,1' the o nncctlon< among them arc con ,sLent wi th the SR .

2.2.1.8 Build 1 Test Summary Report

2.2.2.2 Build 2 Test Design T hese teSts first will

2.2.1.7.4 Impact It \ ,s d~c ldcd th, t the Irl IdcnL(s) repo n ed above were n Ot serl ou enough to rcqum.: a

ve rify th at the correc t Etlfo lHllrrEnvironmCJ1 t object ca n

2.2.1.8.1 Test Summary Report

be obtai ned, and the n wdl show that the Arca o bJeclS

Identifier

and Art'(/ COPlllrclioll objec t ca n be re tn eved as req uired.

... I t~Sl passed wi th

2.2.2.3 Build 2 Test Case The func tio nality to

the exceptIon of the defec ts noted . TI, i wi ll be h,ndled by the regula r defect repair process.

be tested is co ntai ned in the fo ll owi ng publ ic fun c·

2.2.1.8.2 summary TI,e bud d

2.2.1.8.3 variances

tio ns of

GnmcArm 9c1TI"DrmillgRoomO

co build I teq incident re port.

2.2.1.8.4 Comprehensive Assessment

Ellcolm f(rEIIVffOtHlltn l .

GnmcArm gCIThcO""9tO" O •

• • •

•

•

•

Enco ll PlltrEnvi rOl' ,"ril l 9(1 ThrEt'ICO UH IrrEllvi r(l",molr()

Add itional remarks supplyi ng details c an be placed here.

2.2.2.4 Build 2 Test Procedures: To be 2.2.1.8.5 Summary of Results

supplied •

•

•

•

•

•

•

2.2.2 Build 2 STD

2.3 System Test STD This (annat is similar La the fo rmat in Lhe build I S I D.

2.3. 1 System Test Plan Th ese lc t5 arc pcrfo m1 cd agai nst lhe arc hitec ture, as

2.2.2.1 Build 2 Test Plan These tests will ve rify

described in Figure 28.23 . TI,e tests verify that the effects of game actio ns

that th e areas of the game can be re trieved and

in

Eu oUl1ttrCa mr

corrt"ctl y manifes t them selves as

EncounterGame

EncounterGame EncounlerCharacters

-'.c.de·

EncounterCast -'8PcM _

EncounterEnvironmenl

EncounterEnvlroniicent ott.c •••

Figure 28.23 ArChitecture and modularization for Encounter video game

CASE STUDY: ENCOUNTER SOFTWARE TEST DOCUMENTATION

nlO~nl~nts of EH

O".t"

chara ters

wllhin

the The integralion leslS verify that the require· ments of Encounter, as stated in the SRS, have been satisAed.

~nvlron",ent .

2.3.2 System Test Design ~ syslem lests are designed to verify the

The acceptance te IS arc slored in the Accept· package, and include the usc cases. The Initialize usc case IS sh own In Figure 28 .24 and is executed by the mai"O method of the class Initia lize in the Acctpt."erTts' package.

architecrure by executi"g and verifying se. quences of "'Ierface methods

."crT",

2.3.3 System Test Cases Syst~m T est I

The E"rounltr Fortig., CJJarn

use case is shown in Figure 28 .25 and is executed by the ",.i"O metho d o f the class Acctpta"ctTts t l"itia/izt .

I. Move player character into dllngeon .

Itr

2. Move foreign character into courtyard. 3. Move foreign character into dungeon .

2.4.2 Acceptance Test Design

4. Execute an encOllnter in the dungeon .

The use cases indicated in Section 2 4. 1 are to be executed in sequence severa l times, in accordance wilh the lest case in Section 2.4 .3.

System Test 2 •

•

•

2.4.3 Acceptance Test Cases

2.3.4 System Test Procedures

2.4.3.1 Test Cases for Initialize Use Case

• • • •

2.4 Acceptance Test STD

The lests are instances of the Initialize use

case, also known as "sct"narios."

2.4.1 Acceptance Test Plan

:Encounter· Game

main player character: Pia er Character

User

1a· .

:Player quality window .. create"

dress ing room:

Area

I

1 b. -create .. ~

2. -create-

'y

I la . onter quality valuo

Jb. • etOuolityO 4. select exit tor character

,

5. moveO

• Numberlng key ed to uH case

Fleur. 28.2.4

Sequence diagram for Initialize use case In Encounter

.,.,

721

722

CHAPTER 28 TESn NG ATTHE SYSTEM LEVEL

:Encounter arne

:Encounter Cast

freddie: Foreign Character

1. 1 displayForolgnCharO

:Player's main character

1.2 d,splayO

~

engagement: En a ement

1.3 .. create ..

2 execuleO

I

2. 1 S.IP~ye.aua ll1yO

I

2.3 selForolgnOualityO

2.2 seIQua/l1yO

2.4 selQuall1yO I

:Engagement Di~a

3. 1 .. create ..

r 3.2 dispiayAesul10

Figure 28.25 Sequence diagram for Encounter Foreign Character use case in Encounter

2.4.3.1.1 Initialize Acceptance Test 1 1. S1~n up game

2. Supply main characte r wi1h 1he fo ll owi ng qual. ity values ,

In

2.4.3.1.4 Initialize Acceptance Test 4 . .. 2.4.3.2 Test Cases for Encounter Foreign Character Use Case

the order show n:

Strength , 30, then Conce ntratio n, 20. 3. Move the main character to the counya rei

2.4.3.1.2 Initialize Acceptance Test 2

2.4.3.2.1 Encounter Foreign Character Acceptance Test 1 I. Set the main chara cter's "patience" va lue to 30.

2. Set the foreig n c haracter's "patience" value to 20. 1. Start up game.

3. Move the main c haracter to the draWing room. 2. Supply main character with the foll owing qual· ity values.

10

the order shown:

Strength , 30, Concentrati on, 20, and Patience, 30. 3. Move the main c haracter to the courtyard.

2.4.3.1.3 Initialize Acceptance Test 3

4. Cause the fo reign characte r to enter the drawi ng room.

5. Ve rify that an e ngageme nt has taken place 6. Observe the e ngageme nt window showing the results .

1. Start up game.

(The players patience value should be 40. and the foreign c haracter's 10.)

2. Supply main character with the following qual · ity values, in the order shown, Strength, 30 and Concentration, 20

2.4.3.2,2 Encounter Foreign Character Acceptance Test 2

3. Move the main character to the dungeon .

I. Set the main character's ' stren<»h" o~ va Iue to ;.'0.

CASE STUDY: ECUPSE

l . Set the foreign c harac ter' "strength" value to 20. 3.

love the ma in chara ter to the dungeon .

The installation tests shall consist of the accep· tance tests conducted o n all of the above platforms,

4 Cause the fore'g n character to enter the dungeon .

5. Verify that an engageme nt has taken place.

28.6

6. Observe the engagement window showi ng the

W e continue to use Eclipse for a case study, as in past chapters. There are many systems for automating tests; and to appreciate the kind of capabilities that they provi de, we focus o n the Eclipse Test and Perfo rmance Tools Platform (TPTP), The fo ll OWi ng is quoted and adapted from the o nline documenta· tion for TPTP [ 6), TPTP is a sui te of "test, trace and monitoring tools ," It addresses the "test and performance life cycle , fro m earl y testing to production app lication mo nito ring, including test editing and execution , monitoring, tracing and proAling, and log analysis capabilities." TPTP addresses many of the issues di cusses in th is chapter, includi ng the col lection of metrics , The TPTP profili ng tool can be u cd to profile a Web application , including memory use and exe U· tio n time (the two ma in performance metri cs), The ize of the hea p as the execution progresses is an example, TI,e profiling process all ows the user to select parameters as well as output formats such as graphs, TPTP can be used to record trafAc at a Web application, In particu lar, it e nables loops within which a test engi neer ca n embed a test . te t parame · ters varying fro m pass to pass, TPTP has built · in facilities for maki ng logs of the te t re ult for exa mple , a grap hica l output showi ng reque t that take the longest time.

resul~ .

(The player's strength va lue sho uld be 40, and the foreign character's 10 .)

2.4.3.2.3 Encounter Foreign Character Acceptance Test 3 '" 2.4.4 Acceptance Test Procedures Acceptance tests shall be carried o ut with two desig. nated representatives of the customer present These representatives shall carry out all testing wi th the assist.ance of the vendor. Whenever possible, events should occur as a result of the random processe of the game instead of being sti mulated. An example of th, s 's the arriva l of the fore ig n character in an area , A log of all tests shall be maintained by the customer repre· sentatives and ig ned by all panics; an y sig natory can enter dissen ting statemen ts in the log ,

2.5 Installation Test STD These are tests verifyi ng that the applicatio n executes correctly in its required hardware and ope'f3,ating system environments,

The installation test s for Encoun ter co nsist of executing the system tests on the fo ll owong hardware conAgurations, 1 IIlM .compatible PC w,th at leas t 32 megabytes of RAM and 100 megabytes of d, sk space

2. SUN SPARC mode l mmm with at lea t 32 megabytes of RAM and 100 mega bytes of disk space 3 Apple ,MAC mode l 1234 or later w,th 32 mega · bytes of RAM and 100 megabyte s of d, sk space

CASE STUDY: ECLIPSE

St.'vc:ral "agents" ca n be set to monitor various

aspect of the execu ti o n, These ca n be thollgh! of as processes a tong in para ll el with the executi o n of the app lication under scn,tiny. Besides heap and stack usage data , TPTP ca n be used to vie,,, the II age of objects l-rom varoous cia ses. It can account for all of the objects of a class that come onto being dllron!! execution, allOWing a trace into th e exe lIt ion TIm can be di splayed ,n the fo rm of r an of a ,cqut'nct' diag ram For example , ,t may happe n that 0 man ,n stances 0 1 the 'm'9 cia s exis t at runtim e that the applicat , n' performance i, compro mISed

723

724

CHAPTER 28 TESTING AT THE SYSTEM LEVEL

n,e key to man y analy <5 I the Iden Ion of unlled by o thers . TPTP proVIdes a means for prosramme'> to insert "frag ments of Java code that ca n be invoked at specIfied POints," the Java closs ... " This i< ca lled "l s ln~mnll(Jliotl

It includes monitori ng (or "method

entl)', method exil, ca tch/ fi nall y block . and cia s loa ding," \X/ ith sla'lC instrum entation. probe

arc

Inse rted before execlltion. These have 10 be rem oved often by hand-before the application ca n be deployed . Th is can introduce errors via

Method Invocallon, ca n be compared, as In Figure 2826. In thIS exa mple, dI splay parameter< have becn chosen so as to aVOId dISplaying methods invoked a negligIble nllmber of tImes (7]. Method execullo n limes ca n be displayed as In F,gure 28 .27. TPTP includes the abilll)' to generate test cases and test procedures from higher. level descriptIons, as wel l as the ability to record CU I interactions. In o ther words. the application is execu ted and the user interac ts WIth CU ls. When the application IS exe· cuted again in plnyba k mode. the user's same CUI

pro bes Inadvertently left in the code. With d)'llnmic inslnlmcntation, moddled cia scs can be ubstllutcd

actions arc automatically performed .

(or unmoddi c:d ones at runtime . This avoids the manual c1can ·up process, but the application must

example, to test a word procc sor, we would test

T ests arc often o rganized In hierarchies. For

be execuled in a speCIal mode to use il. Listing 28.2 is example output from a class Order that has been

"child" teSts for Rle handling capab,lit,es, editing capabilities. display capabilities, and ot hers. The Rle handling tests break down into subsidial)' tCSts, and so

taocally Instrumented with method entry and exit

on. Managing tests within such hierarchies is a signif.

probes [7)

icant challenge, and tools like TPTP lacilitate this.

Listing 28.2: TPTP output trace of entry and exit of Order class

Entered: Order.main Start Entered: Order. Exited: Order . Entered: Order .placeOrder Entered: Order.getSupplierList Exited: Order.getSupplierList Entered: Order.connectWithSupplier Exited: Order.connectwithSupplier Entered: Order.sendOrder Entered: Order.constructOrderForm Entered: Order.checkProductAvailabilit Exited: order.checkProductAvailabilit y Exited:Order.constructOrderForm Y . Exception:Order.sendOrder! Toomanyitemsre ested. Ex~ted:Order.sendOrder qu Exited:Order.placeOrder Finish Exited,Order.main

CASE STUOY: ECUPSE

"" .000 ....

Method Invocltlons

........-

llS,ODD

•0c

" .... "'0_

.... .s- ..... -• ' .000 , ..... ' .000 ' .0lIl ,11

~

0 0

Q

E

'.000

Z

.'.000

Methods

Figure 28.26 A comparison of method invocations In Eclipse

source. Eclipse Test and Performance ToolS Platform ProrecL reprOduced WIth permISSIon, htt+fJ /WNW edipse.orgItptplplat1omv document!JprObeklvprot>eklt.html

Method Execution Time (In seconds)

Figure 28.27 Graphical comparison of methOd execution time In Eclipse ~ [dipse Test

and PtriOf'lnance 10015 PIilUOfm PfOjOC.t. JopI"oducca wlUl permISSIOn, I'&UlTJIWww.edipse OfIll~platformidon'menIJlPfoDelllliptObekit hlmt

725

726

CHAPTER 28

28.7

TEsnNG AT THE SYSTEM lEVEL

CASE STUDY: OPENOFFICE

need

n."V I('"W , I t

is pO~ltive progrc!)s that is cs~ntja l to

keep th is projcc i moving lorward • Note to the tudent, QA for o pe n source project' is characterized by user involvement, as exempli Red in this case tudy.

The OpenOfRce teSti ng missio n tatement is at httpilqa.openofRee.org/, ''To provide an easy way for voluntee r to find , update and bettcl' de Rne issues. and to deBne tc"t processes to validate a build 01 the Olfice SUIte."

28.7 .1 Open Contribution to Quality Assurance 1ueh of this section is quoted o r adapted from h up';I q a .openof Rce .org/hel pi n g. h tm I. Th,' latter "describes ways in which anybody ca n he lp make OpenOffice.org better, even no ndevelopers. OurCUTTcnt focus isonconAnning issue that an: marked WIth the Aags 'unconfirmed' and 'defect.' O ur goal is to r<-"Spond to new Issues po t<.°d by users a soon as possible

as we ll asclcarout the backlog of unconfirmed issues that currently resides in thc IssllcZilln database. However, we recognize that there is a lot m OTC to Quality Assura lKe (QA) than just reviewi ng and i o lati ng is u(s. In the future , OpenOlfice.org (000) QA will invol ve te
cases, regression tests, QA spccifkation documentation . or any other idea you think wou ld be val uable to Improving the qualIty of 000.

It IS indicative of the scale of OpenOfRce that settling 100 issues a day (over 36,000 per yea r) is considered "insignificant."

EveI)' little bit 01 contributio n counts and is in· valuable. For example, if we have 100 Interested volun· teers, and thcya ll work o n o ne issue per day, we would be able 10 cover 100 issues per day. As insignificant as that may seem ""hen compared to the number of issues that

28.7.2 Smoke Tests Smo ke tests arc superficial tests c hecki ng that c hanges to the baseline ha ve no t resulted in cataserophic errors. A smoke lest is a reduced regression test. "Insta llatio n tests" here are no t fu ll inscallation tests

The fo llOWIng is quoled and ed ,ted fro m the si te give n at [ 8]. "Smoke Te ts (a lso ca ll ed Shakedown tests) va lidate a build of 000. These arc not fu ll y . fled ged test CJses, but \'Ie may use them to create (est cases in

th e future , Your ideas are welcome." The c consist of the fo llowing, quoted fro m th e reference . Insta llatio n T es ts. In ta ll 000 in both sta nd · alone and ncrworked environments

File type Test. T es t th at 000 can open and correc tl y display specified fi le types. Ca n open! execute a Java app let (sa mp les avai lable ). File Actions. T est that 000 can create and save different types of files . Ca n sen d mail using an external mail program .

Insert Actions. T e t that 000 can insert spec. iRed ac tions into a text document.

Edit Actions. T es t that 000 edit actions func. tio n as speCified with a text document. T est that em and paste integrate with ex tern al editors

and 000.

View Actions. Test that 000 view actions ftlnction .s specified . Format Actions. Te t that 000 fom» t ac tio ns funCtion as pecified . Tool S/Options . T est that 000 tool. options fun tion correctl y. Print . Test that 000 Prints, text do ument to a default printer. Hdp . Test 000 help Content. and fu nc llo n<.

CASE ST1JOY: OPENOFFICE

28.7.3

QA Priorities

~ proce:du ~ de:scribed here ,s designed to en$U~ that t he: most ,mportant issues are woritcd on first. Its somewhat mechanical fonn i n~essary in aD open·source environ. me:nt since no single manager i making con. tinual decisions.

Table 28.3 reAects the OpenOffice QA pnorit .

,es (taken, with

minor editing , from the source given

The following is quoted and adapted from [II ]. 1ne qadcvOOo project proVides a te t harness to execute test cases wri l len in different prOgr.Jmming languages, like + , Java, Python, or BaSIC. These test cases are responsib le for validating the functionality and reliability of speCified APls. The test harness

ac+

(written in Java) is responsible: for setting up, running, and controlling the test processes and threads: "The test harness and a nearly complete set of Java and Basic ICSt cases for the OpenOffice.org API are at [ I I ] as well as the desired value set for the test runs and a set of test documents used by the test cases "

in [9J. QA contributor procedures are given at the source in [ 10].

28.7.4 Automated Product Source Code QA This section d escribes a test harness for exe cu ting OpenOffice tests.

28.7.5 Automated GUI Testing 'The automated C UI testing provides a test frame· work with test scripts and an application (TtsrTool) to test alm os! the w hole of~ce application automati · cally. The TtsrTool scripts are wrinen ,n BAS IC with some additiona l functions especially for the o ffice . The TrsrTool communicates via TCP/ IP with the office app licatio n." [ 8 J

Table 28.3 Example of priorities in Open Office Rank

Task

IssueZilla (lZ) Search Tips

1.

New issues posted for the current month or today.

Look at the 'Untouched" issues hnked at http://Qa.openoffice.org/issuelinks.html Also try searching IZ with Issue Type set to "Oefect" and Status set to "Unconfirmed," where the fiel d(s) is set to "[Issue CreatlOnl" .. .

2.

Follow up on unconfifmed defect issues with the "oooQa" keyword . Ideally. start with the oldest "oooQa" issues and work your way to the most current. If the issue is older than 3 weeks and the Issue does not follow the guidelines listed in the "How you can help?" page, leave a comment to the user Indicating you are clOSing the Issue for now. but If they can provide more information to help reproduce the issue, they can reopen the Issue at their convenience.

Try searching IZ with only the following fields set: Keywords set to " oooqa" ... Limit the search to a particular time frame .. . .

3.

Close out issues reported against versions of 000 that are no longer current. Do a Quick check to see whether the issue is verlfable. If the Issue cannot be verified, send a message to the user to see whether upgrading to the latest version of OpenOfflce.org resolves the Issue. II upgrading 10 the latest version resolves the problem, close the Issue. If the upgrade does not resolve the problem follow the 000 QA " How you can help?" guidelines.

Try searching IZ with Issue type set to " Defect." Status set to " Unconfirmed," and the Component and Version fields set to your choice.

727

728

CHAPTER 28

TESTING AT THE SYSTEM LEVEL

28.8 SUMMARY nee integratio n tesling is omplclcd, th e appli ca ti on a~;) w hole I ~ tes ted T hi s i~ known as system testi ng. y arc lC It' d.

Appl icatio ns arc freq ue ntly distributed in-hou c fo r te ting (alpha t es t in~ ) and 10 partt ci patlng usto mers to try o ut with a lear unders tand ing of liS
system tesrs. j\~a ny rca l· world appl ica tiolls have incomplete or even nonexistent requin:mc nts documl"nts. T c:sting in th e Jbsencc of well -wrin en requirements requires th e tes ter to obtai n a sen c of ho\,{ th e appl ica tio n behaves and how it i meant to behave. This is called bt'haoioml modtlmg . A n approac h to tes tin g in thi s srtua tio n is to

S'art fro", wha, appea r; best to be a beginning poi n' o f the applicatio n, and th e n kee p ,rack o( ,he fun c ti o nal path s fr o m th ere . Directed graphs arc used to document ,hese path s. Te t, are devised to execute a set of pa,hs ,hat altai n a kind of coverage In o rd e r to be effec ti ve at Rndin g defec,s, a good software tes ter mus' be de termined , dogged, (eariess, imaginati ve , curious, meticul ous, and must think "outside the box ."The les ter's gOoll is to discover ddects that c.a n mani fes t wh en an appl ication is used (or a significant tim e

by user , perhaps In unanticipated ways.

28.9 EXERCISES Answer th e following exercises in your own words. I. Why arc black box ' cS tS (rath er than white box tests) used in system testing )

2. What is th c purpose o( acceptance testin g and wh y is it nl'cessary 7 Cive an exa mple o ( an applicatio n and a defec t that co uld go undetected in system tes ting yet be c au g ht by acceptance tes ting .

3. A compan y is develo ping an applicati o n, and th inks it has d iscove red a novel way to speed up its tes ting cycl e. It decides to dispen se with sys tem testing, and in tead deliver th e appl icati o n to customers just after integrati on testing

is complet ed. The company will lherefore rely on its

custo me r; to discover problems in the appl icatio n. Wha, arc the ad vanta ges a nd d i ad vantages of this approach) Be speCi fic and ex plain your answer. 4. What is the purpose of soak testing) Gi ve an exa mple o f a defect thi s ty pe o f tes tin g is likel y to uncover.

5. Load and sfrtS5 tC'sting is often conducted on indiv idu a l units dllring unit and in,eg~ t Ion ' . I testin g. n •

. •

•

•

IU

thIS teslIng, unllS are subjected to hi g h levels 01 stress [ 0 e nsure ,hat th ey do h 'b' . . no t ex I It an y problems. Why IS It necessary 10 conduc, system-level stre« 'c, ,, even if all of ,·h e '"'' t t'"'-'SO t e IS . are success1uI7

6. Describe the various levels of testing to whic h you wo uld sub)'ec t ,he' I' . d . . . .. "pp Icallo n escnbed In E-xerclse 7 In Chap,er 27. Indicate which o f the clas es and pac kages ( ho . h fi wn In t e gure ) would be

BIBUOGRAPHY

involved in each. (Many more classes wi ll be involved in buildi ng the completc application. but you are not required to show these.) 7. For Nch of the black box testcr qualities listed in Section 28 .3.6. give an example of how that quality could be counterproductive if take n to an extreme.

BIBUOGRAPHY t

2: 3 ... 5 6 7. 8 9. 10. 11

Kit, Edward, £JjlfL.'\Qft Ttjtlrtg ,PI II" Rcal World l,"pro,,,,,; ,Ix Proem, Addison. Wc:sley. 1995 Purdue Usab,hcy T CUing QuC'Stlonna ire, hnp Jlold"ww.acm ,orglpcrlma nlques llon ,cgI1form . PUTQ [accessed 121 15109] Herzog. Petcr, OSSTMj\'I - Open Source Security Tc:stlOg ''''!ethodalat,,), Manual httpJlwww.lsccom org/projcctvOSSlmm shlml [accessed 12I 15109 J. Snnlv~san Deslkan , and Goplllaswamy Ramc:sh. Software TCStHlg. Pnnclples and PraCtiCes , Pearson Education. 2006 Kiner, Cern, J;ICk. Falk, and Hung Quoc Nguyen, T Nli"g (olllp",'tr SO/IIlIQrc, John Wiley & Sons, 1999. EclIpse T~, t ~ Performance Tools Platform ProJect . hnpJlwww.cc\lpse.org/lpt.p/ [accC..Sscd 11 / 11 /2009]. Eclipse T e"Sl & Performanc~ T 001<; Platform Pr.ojecL htlpJlwwwed.psc.o rg!tptplpladormldocumentslprobcklvprobekit.html [accessed 11/ 1112009J. OpenOfAc~ Project. hakedown Test SUlle · hllp J/qa opc nofAcc.org/tcstcasc:/mdc)(.html (.lcccsscd 11 / 1112009]. O~nOfAcc Project . · 000 QA Issue Revl cw PriOntl~." hnp j/qa opcnofficc o rg/ prio rltlcs.hlml [accessed 11 / 11 / 20091 O~nOfficC' ProJect. "A Quick Stan CUlde to contributmg to this prOJeCt. ~ hltpJ/qa .openorAce.org/W'W"Wslagingil askslqlllckstan . html [.ccess.d 11 / 11 12009J OpenOfS« Project. "Automated product source code QA: hupJ/qa.openofRcc orglqadcvOOo_dodi ndex.html (accessed 12I IS/09}

729

Software Maintenance

Planning

•

What are the units of software maIntenance?

•

What are the differences between corrective , adaptive , perfective , and preventalive maintenance?

•

What are some management challenges in maintenance? Process challenges?

•

What are the rna," technical Issues?

•

What is the maintenance process ?

•

How do patches work?

•

What standards are lhere for software maintenance?

•

What is reverse engineering? Reengineering?

•

What maintenance metrics are available?

Testing The Software Development Ufecycle

Raquir8J'L8nt& analyaIs

Figure 29.1 Tlle context and learning goals for this chapter

Software systems continue to evolve after their initial release. The l'ttainlt'HflH Ct o f a software sy trm consists of those activities performed upon it aftcr it ;s released. The IEEE glossary [ I ] deAne< ofcware maintenance as follows:

TYPES OF SOFTWARE MAINTENANCE

TI,. proctSS oj mod,Jyi"!l a SOJlwart 'y,'m or eo,"poHrnl afler d,/i",ry 10 corr,el faults , impro", p,rjO"",,HCt or olb., a/lnb.ttS, or adapi 10 a eha"9,d ,H"oroH,"rnl. Maintenance is an activity of trul y il!nincant proportions, consuming an estimated 40 to 90 pe,cent of the total life cycle co ~ of applocations (see, for example [2] and [3]) . Perhaps the most famous maintenance effort involved the year 2000 (Y2K ) problem, for which maS
As

software systems evolve over

tmHo",

the y require co ntinuous ma intenance in order

[0

remain useful.

Lehman ([ 4] and [5]) claims the existence of several laws of software evolut,on borne out by extensive experience. The nrst, eOH IoHu iH9 ehaH9', s tates that if a program IS not cont,nually adapted to ongoing needs, it becomes less and less useful over time . According to the second law, "'Crta''''9 eomp/"",y, as a program is changed over time, it complexity increase unless ,,,ork is done speCifically to alleviate this. An example is a maintenance action that increases coupling between modules . Lehman's two laws are relaled . As oftware evolves, it is modined by engineers who may be competent to make each change but may not completely understand the overall desi.g n and implementation . TI,is is not surprising, give n the sheer magnit ude and complexity of many applications, As a result , the applicat,on's structure and maintainability decline. Il is for these and other reasons lhal software maintenance of several varielles is necessaty ' The addition of new features and functionalilY to an application is n::a ll y a kind of dcvc1opmenttypica ll y of the application's next release . Nevertheless, the process IS somelimes included in the "mainte · nance" rubric , especially when the new features are very much ,n the spirit of the application's curre nt functionality and when they are small by comparoso n. This type of mainte nance i explained in this chapter. In many ways, agile projects can be viewed as being In "maintenance" mode from the beginning . This i because agility relies on adding to a code ba e a procc s that has much in commo n with ma,ntenance

29.1 TYPES OF SOFTWARE MAINTENANCE This section introduces the unit of maintenance . It also names and describes vanous type of m.,ntenance activities.

29,1 ,1 Maintenance Requests Maintenance organizations manage lheir work by identifying task . Ideally , the c sh ould be of comparable magnitude (imagine the Inappropriateness of a li st of c hores that Inc ludes "buy bananas" and also "build house"). Each such unit of maintena nce is ca lled a MaoHlrnaH" Rtqutsl (MR) in IEEE term inology We try to ize MRs to be of a regular mag nitude , but the amount of code needed for each ca n vary and the Impact can vary as well. A phYSICally small code c hange may have a major effect on an application . One way to keep MRs at comparable effort is to decompose them into c hild MRs . An MR is either a "paor or an ".hmoe''"tlfl It IS a repair when it co nce rns a defect relative to the existing requirements, An enhancement MR is one of two types. The first in troduce a feanlre no t called for in ,he requirements at dclovery t,me, the second type of enhancement c han !!c~ the design o r implementation , wh,le keeping the functionality unchanged. ThIS is known as refactori ng , as Introduced in C hapter 24 . Refa tonng usually improves the deSign ,n order lO redu ce comp leXity a nd Increa e efficiency , and it is a re pon e to Lehman's seco nd law of Increasing co mple Xity Figure 29 .2 summan zes these distinctio ns. A common categorization of MRs IS defined by L,cintz, Swanso n, et al (6). (7). who reRne the,e twO types of malntenan e IntO twO .ubcategories, a' ,ummarized ,n Figure 29 3 and explained ,n the rest 01 this seCtion

731

732

CHAPTER 29

SOFlWARE MAINTENANCE

• Repair • FIXing defec t (relative to existing requirement s)

• Enhancement •

•

cw reqUIrement

• C hange desig n o r Im picment atio n (no func to onal hangc ) Figure 29.2 TYPes of mai ntenance Corrective

Repair

- defect identificatio n and rem ova l Adaptive - changes resulting fro m operati ng system . hardware, or DBMS chan ges

Enhance

Pc rfective - changes resulting from user requests Preventi ve

- changes made to the software 10 make it more maintainable Figure 29.3 -:)Ipes and subtypes of maintenance SOUrce Uentz. Benmltt P., E. (CACM),

no

BUitOrl

SWnnsoo, and Gerry E. Tompl(J1"IS. "Chat<1cterlstlcs 01 Applications Software Maintenance," CQmmunlcaUons of the ACM

21 . 1978, P 406 471 .

Maintenance Reguest 78 Problem When the player changes the va lue of a quality, the computatio ns are specified to keep the total invariant , but they do not.

Exa mple. If the qualities arc

' 1""9Ih = 10, pa,i",ct = 0.8, and ",du,anet = 0.8 (sum = 11 .6 ), and the player adjusts "''''9 ,h to I I , the result is slrclIg fh = 1 I, palimcc = 0 and mduranct = O. These do not sum to I 1.6. Figure 29 .4 Example of corrective maintenance request

29.1.2 Corrective Maintenance Correc tive maintenance is concerned wi th the repair of defec ts relative to exist ing req uirements. These

defects are typically d iscovered b y CUStomers as they use a software product. Each defect must be analyzed. priOritized, and repaire d, and fixes incorporated into new sofh\>'are revisions. As an example defect, consider

th e MR for the Encounter case study show n in Figure 29.4. MR 78 requi res the maintainer to determine th e cause o( the defect. One possibility is an error on the code, such as in the method adJustQu.lityO, which is responsible for adj ustong quality values when one of them is changed b y the user. Another posSibi li ty here is that eXIS ting requirements (or Encounter characters are defect've. Actually, th e latter is the case, because the requ ireme nts mand.te the follOWing ,

TYPES OF SOFTWARE MAINTENANCE

• The user hall be peml ined to sel any Quality qualitic .

10

any va lue les than or equa l to the curre nl ,um of the

• The remaining qualities retain thdr mutual proporti on:,.

• No qualit

shall ha ve a value both grealer than zero and less Ihan 0.5 ,

• The sum of the qUJ.litte~ remains Invarianl.

can be Seen in the example in MR 78 , Ihese ca nnOI all be salisfied Since the defect is in the ~quirements , ill S the cu lo mer's preroga live to make o r permit the c hange, O ne wa y 10 do th iS is to relax the last ~quircment to the followin g , Isum of qualities - 0.5

* (N - 1)1 <= (sum of qualilies)' => sum of q ualities

where N i the number o f qualitie and x'

IS

Ihe va lue of x after Ihe adjustmc nl proce

Th is modiAcation keep Ihe effect of di _cou ragi ng the player from changi ng quali ry va lues too many times becau e point ma y be 105 1 wheneve r Ih,s is Gone ,

100

muc h o r

29.1.3 Adaptive Maintenance Adaptive maintenance i concerned wllh ada pIing the software

10

changes in the operating envi ro nm ent uch

as a new operating system relea se or a new versio n of hardware. As oft'\"arc system s evolve ,

It IS

inevitable

that changes in their externa l environment will take place. An example i if '\Ie were to port o ur Encounler video game caSe study to an iPhone. It ma y seem awkward to classify adap ti ve ma intenance as a kind of re pai r, bur this is appropriate

if o ne views an app lica tio n as a liVing cntity . In ordt'r to r('mam

leg itimate, the

application must adapt to rea o nabl e chan ges in its e nviro nment.

29.1.4 Perfective Maintenance Perfective maintenance is the develo pme nt and Im plementallon of u er reqllesl suc h as new feature enhancements. Recall Lehman's Rrst law- Ihat ys tem s mu t con tinuall y adapt to o ngoi ng needs o r become less and less useful. As an exa mple of a perfecti ve maintenance reque
Figure 29.S Example of a perfectIVe maintenance request

733

734

CHAPTER 29

SOFlWARE MAINTENANCE

29.1.S Preventive Maintenance Preventive mJlntcnan c cone<; ,c;;ts of c hang ing J c;;oftwJrc applt a ll on

In

order to m&lke It eas ier to maintaIn

'n,e need for preventive maintenance can be deduced from Lehman' <econd low As

program evolves over

0

lime, hange made through correc ti ve , adap ti ve, and perfective millAlcnancc requests cause the system to become Inc reasing ly compl ex unless action

rakcn to prevent it. Preventive maintenance Involves proactively rdaclonng the sy'\tcm to reduce its comp leXity. It IS Jlway~ a good Idea to pe rform preventIve IS

maintenance on an ongoin g baSI An example preventive mainlcnllncc is to recog ni ze and anticipate Industry trends Suppose, (or

or

exampl e, that we sell a Windows ·based word pro cssor ond that we reco!: nl ze that word proce sors arc likely to m1grare, In pan , to the \'(Ieb, A preventative maintenance action would be lO alrcr th e word processor's architecture so that selected pans arc mo rc readily moveab le to the Web Metncs can be used to identify lIrcas thilt need improvement. For example , by examining ddect mc(rics It may be determined that a certain software modlilc has a hig h number of defecrs reported agalOst it After flirt her inve tlgation It may be detem,ined that many of the defect are a rc ult of changes made wh,le prior defects were repaired This might lead to a conclusion that the desig n of that modu le IS 100 complex, and thus not ca, ily modified. As a result , mointenance work moy be perfom,ed to redesign the module to make it Simp ler and morc mainta inable, without changi ng its hlOctionaliry , Subsequently , we would expect fewer defect to be filed ogainst the refactored module.

29.2 ISSUES OF SOFTWARE MAINTENANCE Software maintenance preseOls a unique set of cha llenges. Ben nett [8) has categorized them as manage· ment (what to do and who wi ll do it), process (what procedu re to fo ll ow), and techOical (design and Implementa t ion).

29.2.1 Management Challenges Senior management tends to focus o n delivering new products, which are a Ou rce of revenuc (or COSl savi ng if internal) and provide a quantdlablc return on investment. Funds spent on main .. enance , however, are usually not si mple lO justify. The cost of maintenance is high , and unless the maintenance organization ca n charge for their services, th e return on investment IS much les clear than for delivering new products . As a resllit, maintenance teams can often be understarred and lInderfunded . maklOg an already dtfficult job even harder. oo ner or later, the need for organized maintenance i recognized by management and resources are allocated !o it. Sometimes an. individual or a group or is assigned to repilir tasks ;lnd a se . pal'are group to en hancements, Incorporated In new update or releases As software moves from shnnk . wr. ppc d d eI'Ivery and big -bang integration to online deli very, cont lnuOliS '"tegratlon and security upd,tcs tlle tr:cn d h as be en toward more frequent version updates ra ther than major releases_The management of rno fr d . . " re cquent up ares IS more demanding thon that for major relcoses Simply because !he act of relcase . freql1ent Th'I .IS I more analogous to thc difference between managing a daily newspaper and a monthly magazine . The management of maintenance involves the assessment of benefits the calc I ' f ' u atlon 0 cost and the allocation of rcsourc~s, mainly pcopl~ . Table 29. 1 how examples of COSts MRs .. ' " . a r~ p non II zed bose
,

ISSUES OF SOFTWARE MAINTENANCE Table 29.1 Example of an es~mate for Implementing a maintenance request Estimate

Estimate ActMty

1. Understand the problem and Identify the functIOns that must be modified or added.

Actlvlty

(person-days)

2- 5

(person-days)

6. Compile and integrate Into baseline.

2-3

/-

2. oesign the changes.

HI

7. Test functionality of changes.

2-4

3. Peliorm impact analysIs.

1-4

8. perform regression testing.

2-4

4. Implement changes in source code.

1-4

9. Release new baseline and report results.

S. Change SRS. SOD. STP, and configuration status.

2-6

TOTAL

1 14-35

29.2.2 Process Challenges Process issues-the procedures to be carried ou t can also be a challenge. Extensive coordination is required to handle the inAow of MRs. T ypica lly , numerous maintena nce requests flow cont in ually through the organization. Some economy of sca le can be achieved , reducing the cost of cach change, but a stream of maintenance changes places a sig nifican t burden on the process. Programmers , tester , and wnte rs have to be coordinated. To take an example, shou ld the SRS be updated as soon as the customer indicates a Aaw in a reqUIrement , only after thorough testi ng , or o nl y when grouped with o ther maintenance actions) Each of these options leaves the documentation and source code in an inconsistent state for periods of time. Without careful management, these supposedly short· lived inconsiste ncies ca n multiply and the documen tation get out of control. The re ult is that it becomes difficult to know exactly what the application does. If a Single , focuse d change were the only o ne we had to handle, the n our process problems would be minor. However, source code changes in re ponse to an MR typically cause a ripple effect in the deSign , documentation , and test plans. An impact analysis (described in Section 20) determines the extent of the ripple effect, and a cost analysis determines the cos t of implementation. As an example of a COSt analysi , let's imagine that the Navy has inform ed us (a military cont ractor) that the algorithm for reconciling three independent sources of shipboard navigation data is Rawed. An e timate i needed of the cost of making thiS repair. Our calculation cou ld be performed as shown in Table 29. 1, which shows that the co t of making this change at $400 - $800 per day of loaded labor (i.e., Including benefits, etc. ) IS $5 ,600-$28 ,000

29.2.3 Technical Issues Maintenance ca n be thought of as a repetition of the de vel opment process but with a major additional constra int · that eXisting reqUired fun tionality of an eX isting code base i~ preserved . This Impcb 11< t ellher add onto the eXisting deSign o r 10 redc>lgn the app lication Maintenance actions that are repairs usually result In stayinll with the curren t dc,,!(n An e CC ptlor. to thi s is where the eX isti ng de ' Bn it<elf is a source of the proble m. Add,nll to an eX lstln!l de ign has th e adva nt age of not perturbing ,.hat already works but the pOte ntial disadvant'f(c of reatlng an lIna ~ cptablc overall de illn . Redcsllln has the OPPosite advantafje, and d"adv. nta!(c, T he rede
735

736

CHAPTER 29

SOFlWARE MAINTENANCE

A~ an exa mple, "UPPO)C

that \'\fC \\IJ llllO ('nh.mel'

~he F n toulllt: r video ),(Jmc with

tht: p rco;cncc of \cvcral

mon""" rJlher Ih an JUSI o nt oWe wo,dd prohably kee p Ihe Lurre", overa ll dC
rl' m a ll) S

th e

)JI1l(' In

SPirit ilnd

h CGlU"C

th t·

urrCJ11

archltc

II

because the

capJbk· of Jbs.orblng the

lUre "

add itio nal apal>dity . O n th e o lher hand . If we arc reqUired to rurn Encou nter 1111 0 J rea l' lIme 31) game In w hl h Ollr cha rJclt'r engages In v;:mouS "'Jy4; with the monster u~'ng wcapon) and they arc: Jblc to pursue each o th er wllhm area, and from area to arca , we would reexa mine- and pr bably alt('r- thc c:xl) lIng arc hitecture This IS because the COmbJl aspec ts wuuld domi ni.lt e the cXI"lIng ) la lC a~pcc{)

Tesllng IS a sig nl ficJ llIlechlll ailS ue Si mpl y focuslOg tes t on changed or added pans takes time enough because pecial ttst plans l1Iust o ften be devised for this purpose. But fo u cd te'ling IS no t enough . The posslbdl ty of npple e(fecls reqUIres th at we execute exte nsive regressio n teSlin g to cn, ure th at changes have not compromls(.'d th e app lication's preexlsllllg funct ionality Thi s i a major factor In th e hi gh CO'Jo l mai ntcnance

or

29.3 MAINTENANCE PROCESS A ","i"lnl""e, pro css dennes Ihe flow of MRs through an orga nlzallo n Figure 29.6 dlustrates a tYPica l ma intenance process in J large project, where the th icker lines indica te th e nominal path The additional

(thin · lined) paths show o ther ways In which MRs ca n be generated and retired. In th e process shown In Figure 29 .6, customers prov id e co mments on enhancements and defect

through the help desk . Th ese are wrillen up as MRs. O rga l1lzatio ns ha ve a limited number of resources to work o n IR, . mean ing that some of the proposed enhancements and repo n ed defects are eit her delayed or nevcr implemented . .vtalOtenan cC' engi neers must therefore priOrit ize;.: i\1Rs. A Inag( proc(ss IS ofte n empl oyed [9] th at includes the: re-vic\" of all proposed ffi (l/ntcnJncc reque sts and the prioritization of their importan ce to th e bU. ln ess and to customers. Triage starts with an ofRc lal orga nizall o nalun il, wh ich may be

- - - Marketing

nominal

Written

MRs Proposed MRs

MaIntenance manager

Customer

Help desk

MaIntenance engineer

Approved MRs Current source & documentation

Change control board Modified SOurce & documentation

Figure 29.6 A typical maintenance process for a large project SO'lf(e GtaQnk.s reprMQ'd wlltl

~

Irom COrm

Rejected MRs

MAINTENANCE PROCESS

a single person or a committee. deciding which MRs will be Implemerned and aSSIgning them a relat.ve pnority . This unIt is often referred to as a Cbal1g, COl1lrol Board (CCB) ( 10). It co nsists of stakeholders. selected from various organizations such as development . user documentation . marketing , quality assurance (QA). and customer uppOrt . Each organization brings its ow n perspective, and collectively they decide on MR priority. The group conducts an Impaci a,,"lysis . which as esses the scope of the changes to the product's artifacts that are necessary in order to Implement the MR. Each group represented by the CCB provides input into the impact analysis. Maintenance engineers prepare an estimate of how long it will take to implement the MR. and its impact on the system. including code and system spccl~cations . The user documentatIOn group determines which user manuals, if any. are affected and require updates. QA determines how much testing is required to validate that the MR is implemented correctly. and also to validate that problems aren't inadvertently introduced into other parts of the system. In the case of repair MRs. customer support may need to determine the impact on customers of the MR and whether there are any possible workarounds that can be employed in lieu of repairing the defect. Using all this information as input. the CCB estimates the number of resources required , the cost. and the risk of implementing the MR. It then decides whether to accept or reject it; and if accepted. assigns it a relative priority. MRs approved by the CCB are then retired by technical maintenance staff. New software versions and documentation are generated and available for customers. For efficiency reasons. multiple MRs arc often grouped together and released as part of a single maintenance release . The number of artifacts affected by the implementation of an MR is va riable . Figure 29.7 illustrate two extremes. At one extreme , the defect is in a requirement that requires changes in the SRS, the architecture. and so on, all the way through to the code that makes the system operable in its intended environment. At the other eXITeme. a defect could be present in the code for a method and the MR could affect that method implementation but nothing else. The minimal · impact case occurs, for example, when the programmer has failed to follow a standard i~ naming a local variable, o r when an unused variable is removed. In the worst case, however, every part of the process is affected. Even for a defect in the code o nl y, the impact can range from minor to major. A seemingly Maximal impact Requirements Df1f8C1/nlected 116'8

Maintenance: I mpact a I Del ect MR

,1 Architecture

Minimal impact Requirements Architecture

"

"

Detailed design

Detailed design

Interface specs

Interface specs

Function code

7

Function code

Defee. Injected 116,..

Module (e.g .• package) code

"Module (e.g" package)

System code

Key 5 I"""",

denoto.

Fllllr. 29,7 The Impact of a maintenance request- two extremes

System code

code

7T1

738

CHAPTER 29

SOFTWARE MAINTENANCE

-----

Requ irements

Arch lleclU",

__ - -

Oetalled design

--

--

Interface specs

~/ Function code

Accommods/e ability /0 change

:::.

g/obalappearanC6:

USB

Abstract

Factory dsslgn par/em

--- - --

- - - - - --

Module (e.g .. package) code

System code

Add: ·chsnge app6srsnC6 when plsyer achlaves new levels·

Add Interlace me/hods for Layout package

----- as --

----- --- -

Add classes and methods per de/ailed design

Modify gameplay ----control code

Figure 29.8 The impact of a maintenance request-a n example

SImple change such as an increase," the SIze of a compile-time C ++ array could have major ripple effects throughout the application. Maintenance Request 162, described ,n Figure 29.5 , aHects ewry aspect of the process, as shown in F'gure 29.8. Recall that this new requirement-t he concept of mu ltiple game levels-is a signiRcant addition . It leads to changes in every phase in the process_ When an application is designed with traceability in mind, the documentation of maintenance actions

can be manageable. Otherwise, the consequences can be extremely expensive.

29 .3.1 Root-Cause Analysis After a defect MR is repaired, a process sometimes known as root-caust aHniym is sometimes conducted. This is an iterative, problem-so lvi ng process ai med at determining the underlying reason Ihat a defect has occurred. Once the root cause is understood , process or other improvements can be implemented to prevent similar

defects from recurring in the fueure . Root -cause analysis is performed via the change control board or its d~ignee as part of the maintenance process. For each defect , the team asks a series of questions to narrow

down the root cause of the problem. As an example, suppose that after an initial investigation it is detennined that the reason for a particular

defect is due to a requirement being missed by the test plan. The roOt -cause analysis process is then invoked to determi ne the unde rlyi ng reason that the requirement was missed , and once determined, to ensu~ that

other requirements are not omitted in the future . The following series of questions illu trate the iterat,ve narure of rOOt-cause analysis (9), [II]. I. The requirement is no t t<sted for in the test plan .

2. Why? It appears that the requirement was cha nged after the SRS and test plans were completed. 3. W hy? The customer communicated wit h the product marketing group their desire for the ch.nge, but th is was commun icated o nl y to development. The rest of the tea m was unaware and therdore didn't update the SRS and test plan .

MAINTENANCE PROCESS

~ . Why~ Product marketing thought this was an .solated change that wouldn't affect product te t.ng, so they communicated it only to development. S. Why) Product marketing didn't underst:and that all changes to leatures must be communicated to the entire team .

Once th. root catlse is understood , the product marketing department can implement appropriate changes to its proc ..ss that prevent th.s type of problem from recurring . As root causes are detemlined, metTics are recorded to keep track of them . To provide consistency and make it easier to track and ana lyze, it is helpful to deRne a list of root causes from which the team can choose . Rakitin [9] suggests the fo ll owing list. 1. Function was missing from SRS 2. Function was incorrectly specified in SRS 3. Design problem-design was inadequate or inappropriate 4. Design problem

design review didn't catch it

S. Code problem

code was inadequate

6. Code problem

code review didn't catch it

7. Inadequat .. Untt testing 8. Inadequate system testing 9. Installation/e nvironment/versio n compatibility issue

A metrics analysis is periodically performed to identify the most common root cau es. The result are used to create a plan of action to eliminate these types of defects from recurring For example, if it is found thaI many defects are caused by Cod, prohlrm cod, rwi,w d.d" 'I ca lch iI, a review of and improvement to the code review process can be implemented.

29.3,2 Patch Releases Patches are used in two ways. The Ar t way concerns gelling new or replacement software vers.ons or parts to users. The second addresses delay< in impleme nt ing an MR . In Ihe first way, patches arc permanent replacements of parts of the application. They often take the form of a set of fi les, sent via the Internet. that replace object code already written . In th.s case, the challenge are for the customer's organization to ensure that patches arc appropriately installed. Many customers conduct their own system tests of patches that ' 5, 111 their ow n environment. The second way concerns the handling of defect MRs thot require s.gnincant time to remedy It al,o concerns defects that hamper a customer's use of the ys tem and so must be remedied quickl . A rap.d Ax is not always possib le. To take an extreme example , in a m.lirary application with which one of the authors was once involved , nine months cou ld elapse between the .dentiAcation of an MR ond it complete implementation and docume ntation l l n these case patches are modifications or addition s to the object code that either nx or work around a defect. FiBure 29 .9 showl a way .n whic h the'" patche an be organ.zed w.th.n the develop me nt orga ni zatio n It demon strates the nom.nal , "ofAcial" path taken for a pat .. h on the

739

740

CHAPTER 29

SOFTWARE MAINTENANCE

1. Get malntenance-!r8Quest 2 . Approve changes

:r 3. Plan changes

Assess impacl

Coordinate

Execute with patch

I

4. Change code and documentation

4

Implement.J

Release

Test changes

Document

Update documentation

patch removal

Figure 29.9 Patches In maintenance workarounds

Advantages

Disadvantages

• May be a complete solutio n to the problem • Keeps customers satisfied

• May duplicate work - patch a"d final fix both implemented

• Enables continued operati on and testi ng

• Temporaries sometimes ne ve r replaced

without prese nce of th e defect • Avoids masking other defects • Enables test of fix

- pro per fix deferred fo reve r • Complicates fi nal fix (where appltcable) -

must rem ove

• Complicates documentation process

• When too ls used for insertio n, ma y com .

promise code base Figure 29.10 Advantages and disadvantages of maintenance patches left-as well as an informal process f.or ge uing the patch into the application on a temporary basis on the right of FIgure 29 .9 . The advantages and disadvantages of patches include th ose li sted in Figure 29. 10. The comment about "masking" refers to the fact that allowin g defec ts to remain can make it difficult to detect other defects whose effects arc hidde n by the effects of the nonrepaired defect .

29.3.3 Software Trouble Reports, Maintenance Requests, and COlTection Reports It is simplest when a single test leads to an MR that is worked on as a SI ngle ac tion , but the proce s is often not so simple. Mai n tenance requests emerge fro m reports of trouble experienced with the application (often called sofl ware tro"bl, reports). There may be several pieces of evidence for a si ngl e MR or, Conve rse l)" several MRs th.t grow out of a single trouble report. E.ch part of the work on an MR that IS worth d ocumenting I recorded in a so ·called correction rtport . To deal with the prol ifera tio n of correction reportS, We may need to identify a child MR of the MR under conSideration . This organIzation is shown In Figure 29. t I.

IEEE MAINTENANCE STANDARDS

::t,

-;.,

Malnlenance

I,

~

Request

Sollware Trouble Report

1293

STR 902834

Correction

Correction

Correction

Report

Report

Report

1293.1

1293.2

1293.3

Maintenance Requesl 1293.1

Maintenance

Malnlenance

Request

Request

1293.2

1293.3

Figure 29.11 Software trouble reports. maintenance requests, and correction reports

29.4 IEEE MAINTENANCE STANDARDS The IEEE ha published standard Sid t 2 19· 1998 [ 12], which descri be. an iterallve process fo r managi ng and executing software maintenance activities. It is gea red to large projects. but it is instruc ti ve to examine this sta ndard as a speCific and de tail e d example o f a mainte nance proce s for projects o f a ll sizes. Its table of contents showing the pertine nt secli o ns I Ii sle d In Figll": 29. 12 .

I

Prob lem ide n tifka tion

1.1 Input 1.2 1.4 1.3 Contro l 1.5 Quality faclo rs 1.6 Metrics

4 Proce ss

4. I

Input

O utpul

4 .2

Proce ss

Codill9 and It lill9 4 .2 .3 Risk alialysis alld rroirw 4 .2.4 Tts l-rtadillfSS rwiw> 4 .2. I

2 Ana lysis 2. I Input 2.2

Imp le me ntatio n

4.3- 4 .6

Process

2.2. I Fea sibility analysis 2.2.2 Dtlailtd analysis 2.3-2 .6 Con lro l, o utput, quali ty factors, metncs

3 Desig n 3. 1-3 .6

fac to rs, rnerrics

5 System tes t 5. 1-5.6 6

7

SoIXGf"1EE£ l td ~'994 Reptoouced WlUl "cumtSskln

Inpll !, proce. <, control, Ollrpllt , quahlY fa tors, melnCS

Delivery

7. 1- 7,6

Alure 29.12 IEEE 840-1994 "Soltware Maintenance"

Input, process, control, output, quahty fa tors, metncs

Acceptance test

6. 1-6.6 In put, proces', contro l, output, quahty factors, me ln s

o nlro l, O"tp"! , quality

ta ble of contents

In put , process, contro l, output, qua hty fac tON, metnc,

7.1

7.2

CHAPTER 29 SOFTWARE MAINTENANCE

The sta ndard deA ne. seve n p hases t hat an MR flow< th roug h . each

orrc pondlng to a scction '"

Figu re 29. 12. as fo llows, I . Problem/mo d iRcatio n id ent iRcati o n . classiRcation. and prioritizatio n 2 Analysis

3. Dcsign 4 . Im plemen tation

5. Regressio n/system tcsti ng

6. Accep tance testi ng 7. Delivery Note th at th cse ph ases are si mila r to the phases of th e develo pme nt p rocess. Eac h of th e phases has six attribu tes th at desc ribe th e actio ns and data associ ated w ith th e m, 1. In put

2. Process

3 Control 4 . O utput

5. Q ual ity fac tors

6. Me trics Figu re 29. 13 su mma rizes the relationsh ip betwecn t he p hases and attributes. The foll OWi ng sectio ns describe how a mai ntena nce req ucst flows thro ugh each phase.

Phase

1. Problem identification

2. Analysis 3. Design 4 . Implementation

ANributes

a. Input 1I1e cycle art~acts lor this step Process required for this step c. How the process is

controlled 5. Syslem tes!

d. Output I~e cycle

6. Acceptance

artifacts

PrIX

7. Delivery

.s.

quafl1y

lactors Involved

Metrtcs lor this FIpue 29.13 Six attribUtes 01 each maintenance request phase

IEEE MAINTENANCE STANDARDS Table 29.2 IEEE 1219·1998-Malntenance phase l '• problem Identification

a. Input

• The Maintenance Request (MI\)

b. Process

• "ssign change number • Classify by type and severity. etc. • Accept or reject change • Make preliminary cost estimate • Prioritize

c. Control

• Identify MR uniquely • Enter MR into repository

d. Output

• validated MR

e. Selected quality factors

f. Selected metrics

• Clarity of the MR

• Correctness of the MR (e.g., type) • Number of omissions in the MR • Number of MR submissions to date • Number of duplicate MRs

• Time expected to confirm the problem SOUrce: IEEE Sld 1219-1998. Reproduced WIth permIssion

This section describes and explains Steps 1-4 in Figure 29 . 13. Steps 5-7 arc si milar to the regular testing and delivery process. Testing in particu lar emphasizes regressio n testing to ensure that exi stin g functionality has not been compromised.

29.4.1 Maintenance Problem Identification In this initial phase, MRs arc identified . claSSified , and assigned an ininal prio rity ranking . Table 29.2 summarizes the process (or the identification phase of maintenance requests "Problem Identi fication" In the Encounter case study, for exampl e, wa perfom,ed by the marketing department. They solicited and exam ll1ed user complain ts about the co mpl icated way In whi ch Encounter game characters exchange quality va lues as a result o ( engagements

29.4.2 Maintenance Problem Analysis Table 29.3 summarizes th e ana lysIS phase (or maintenance req ue ts. Maintenance problem s range (rom the Simple to the deeply halle nglng. Fo r example, suppo e that we want to provide the En ountcr ga me player with addin onal image op tl on< (or the main playn This appears to be a straightforward request, however, the ex tent o( mainte nance request> like thi S is often underestimated The ana lys; process is deSigned to uncove r the rca l work 111 ca rrying out modifica tio ns and additions For example, we might dete rmine that the InCrN cd number o( Image opti o n, req Ulf(: a o mple tc reworkll'lI o( the way In whic h th e Images arC di
arc req,"rcd O n c th c>c modificati o ns arc matie, it al'pe . .... that

7.3

744

CHAPTER 29 SOFlWARE MAINTENANCE Table 29 • 3 IEEE 1219 • 1998- Maintenance phase 2'• problem analysis a. Input

b. Process

• Original project documentation • validated MR from the Identiflcation phase • Study feas ibility of Ihe MR • Investigate Impact of the MR • Perform detailed analysis of the work required • Refine the MR descripllon

• Conduct technical review • Verify ... c. Control

d. Output

. .. test strategy appropriate . .. documentation updated • Identify safety and security issues

• Feasibility report • Detailed analysis report. including impact • Updated requirements • Preliminary modification list • Implementation plan • Test strategy

e. Selected quaJlty factors

• Comprehensibility of the analysis

f . Selected metrlcs

• Number of requirem£:flts that must be changed • Effort (required to analyze the MR) • Elapsed time

SOurce IEEE std 1219-1998 Reproduced with perrrusslon

we will need o nl y to replace all Area and Are.Connectl o n references in th e client code (the code usi ng the new configuration ) such as

· . . = new Ar ea ( ) ; a nd · •• = new Co nne ct io n ( ) ;

with calls of the form · . . = Le velNBuilder . getArea () ; and · . • = LevelNBuilder . getConnect ion ( ) ;

and so on IEEE metrics that quantify these modiRcations arc as fo ll ows .

• Number 01 requirements changes for MR ~ 162: between 140 and 450 as fo llows. Since we have organized the require menrs

by

class, we

COU nt

• The number of new classes that must be described: 60 to 90 (there are 20 to 30 levels let' d1 S .lY. an or ' f each of thes., Abstract Factory requires a .. ctory class . a ;ubcla s of Are. 'nd a bel f A • u u ass 0 rea. Connection) plus

• The number of new methods: (2 to 5) per cia s • (60 to 90) classes ", 120 to 450

IEEE MAINTENANCE STANDARDS

• Estlmat~ of effort for MR # 162: 2.4 to 9 person -month as follows : The effort ca n be estimated in tc nllS of the number of person -days per require me nt , based o n these data for the project 0 r..r, For example, If the original project has 300 detailed reqUirements and was completed with 0 person -months, we ca n USe 0 ,02 person -months per requirement, so that MR # 162 should be taken care of \~ith ( 120 • 0 .02 ) to (450 • 0 ,02 ) = 2.4 to 9 person -months. The highly repetitive narure of the classes uggests a lower number in this range , perhaps three person-months . • Elapsed time os!'imate for MR # 162 The elapsed time estimate can be computed from historical data in a si milar manner to the Effort compulation . To improve on these mNric , apply the following . a. Use linear regression, in which a set of past data is used to derive a straight-line approximation , and th is straight line is used to approximate the result. For example, instead of usi ng simply "300 detailed requirements were completed with 6 person -mo nth s = 0 .02 person -mo nths per requirement ," we ca n use a graph of several different past projects and fit a traight -Iine relation ship to these, as shown in Figure 29 . 14_ This gives a more reliable resuIt : • range of 2 .5 to 9 .3 person · mo nths. It should be noted that regression methods are also available that fit curved lines. b. Account for factors such as the nature of the application and the composition of staffing For example , if the data are available, one can create graphs that use o nl y projects of the sa me rype , or projects whose staff had equivalent experience levels. c . Include variances with the measures described . (It is useful to know averages , but we are also interested in the extent to which measurements have differed from the averages in the past.)

9

300 detailed requirements compleled w~h 6 person-mon1hs

-o

-

.8

•

g3

•

•

•

•

z

200

300

400

Number of detailed requl<ements

Flcure 29.14 Using linear regression to estimate the effort for Implementing an MR

,.,

7~6

CHAPTER 29 SOFTWARE MAINTENANCE • - Malntenance phase 3• design Table 29.4 lEE E 12191998

a. Input

b. Process

• Original project documentation • Analysis from the prevIous phase

• Create test cases • ReVise . .. requirements · . . Implementation plan • •

c. Control

• Verify design • Inspect design and test cases • Revised ...

d. Output

· .. modification list · .. detailed analysis · . . implementation plan • Updated ... · .. design baseline · .. test plans

• Flexibility (of the design) e. Selected quality factors

• Traceability • Reusability • Comprehensibility

• Effort in person·hOurs f. selected metrics

• Elapsed time • Number of applications of the change

SOUrce I£EE std 1219- 1998.. ReptodLICed WIth permtSSlOn.

29.4.3 Designing for a Maintenance Request Table 29.4 describes the design phase for MRs. A design handling MR # 162, for example, follows the Abstract Fac tory design pattern. which consists of modifying the ori gi nal Encolll1tcrfHl.1ironmmt package. The original documentation for thiS package is shown in

Figure 29.15 Instead of creating Area and EncounterAreaConnection objects directl y, the modi Red appJ.cation will do so through methods getAreaO and getAreaCon nection(). These are method of a new class, EnViron. mentFactory. Client code of the EncounterEnvironment package need have no knowledge of the rype of Aroa and AreaConnectlon objects being built, bocause all creatio n requests arc channeled through the particular EnvironmentFactory object aggregated by EncounterEnvironme nt. In other words, there will be no need to write separate conrrol code for the various levels. At runtime, the client code selects an object of the appropriate EnvlronmentFactory subclass. For illustrallon pUrposes, the object model in Figure 29. 16 shows Area and AreaConnection classes for three game· playing levels only (not for the larger number planned) A plan is reqUired for migrating from the old design to the new . Figure 29. 17 shows such a plan. !t Integrates the p.ns in • way that allows their testing, one at a time. \VIc .Iso try to keep existing parts operational while introducing new pans in order to allow the switch only when We have conRdence '" the new pans.

IEEE MAINTENANCE STANOMCUS

GameEnvironmenl

--+I GameCharacler

GameArea}=> GameAr88Connection

I Area

EncounterAreaConnection

EncounterEnvironment

I

EncounterEnvironment

I

Figure 29.15 EncounterEnvironment package (before modification)

'-1 Client I

1 .. n

EncounterEnvironment

EncounterAreaConnect/on

Level 1Area

LeV912Area

I I Level 1AreaConnection

Level3Area

I I

\

Level2AreaConnection

Level3AreaConnection

- create ..

Figure 29.16 Abstract Factory applied to Encounter video game

TIllS plan beg ins with the ex isting design. th en adds and tests parts that do not di rupt the existrng implementation such as ty pes of areas and co nn ectio ns. Before th e last step. the redesig n i ready to execute the Abstract Factory impl ementat ion. each of the pa ns hav rng bee n thoroughly tes ted In th e fi nal tep. the new crea tio n process is fi nall y "rurned o n" and tested

29.4.4 Implementing a Maintenance Request Table 29.5 shows steps and docu mentation for the Impl ementati o n of mai ntenan e req ue t<

7.7

.... t

2

Pha se 2: Introduce Subcla sses of Area and .. . Connection

."

rri

-<>1Encol.lnlerEnvironmenl I

~

Start: Existing Model

[ EnoountarEnybonman1

'"

~ VI

~

EncountsfAreaConnecrion

t:,

I

I

Level lArea

I

Level2Area

Level3Area

:p

-z

~

:p

., EncounterAreaConneJ:tJon

leval1 AreaConneclion

Phase 3: Inlroduce The .Builder Class and Subclasses

lovsl2AreaConnectlon

Final Phase: Aclivate

Level3AreaConn9Ction

buildAreall and bulldAreaConnecrlonll

Env(ronmontF8ctOry

EnvironmenrFac'ory

gelAre.()

gelAroa() ~

Area

Area

,--

,

~ Encount9rAreaCoonection I ~

EncounlerAreaConnecllon T

A Lev"" Area

Lovel2Area

level3Area

LevellArea

-.: ,

,, ,

l evelZAreaConnection

l evel3AreaConnection

LeVI" FIICIoty

L.....I2FacfDlY

~O

goIA1880

fl&Ure 29.17 MlgratJon plan lor level-based graphics

Level3Faciory getAreaO

~

,, ,

l evelt AreaConnection

,,

, , ,

Levell Factory

gotAre.O

Level3Area

l evel2Aroa

•,,, Ley~ 1AreaConnection

~

'";:m

f-----../ """ I

EncounlerEnvironmcnl

a

,

,

" ,, ,, ,

,,

Level2AreaConncction

,,

-

,, , ,, ,,

level2Faclory geWe.()

l"eveI3Area~ eellon "' , ,

~

,,

,,

,

Leve13FaC1DlY getAreaO

z

hl

SOFTWARE EVOLlJTlON

Table 29.5 IEEE 1219· 1998- Maintenance phase 4; Integration

• Original source code • Original project documentation • Detailed design from previous phase

a. Input

• Make code changes and additIOns b. Process

• Perform unit tests • Review readiness for system testing

• Inspect code • verify .. . c. Control

d. Output

• •

•

•

•

•

CM control of new code Traceability of new code

• Updated .. . · .. software · .. unit test repcrts · .. user documents Flexibility Traceability comprehensibility Maintainability Reliability

e. Selected quality f actors

• • • • •

f. Selected metTles

• Lines of code • Error rate

SOUrce" IEEE stO 1219-1998 ReOfoduced WIth permlSSlon

The response to maintenance reque sts can invo lve a sig nificant amount of development , and th is may actually introduce new d efec ts. The mor m/, is th e number of defects cr ea ted by thos m a", tenance dfort per unit of eflort (e.g . person. m onth ). The measurement metho do logy for these new defects has to be precisely defi ned-for example , "th e number of defec t< of medIum eve rity found within th ree mo nths of deployme nt." Suppose , for exa mple, that th e handlIng of MR " 162 de ribed above co n
29.5 SOFTWARE EVOLUTION Systems th at have been maintained for a signlr.ca nt amount of timt' arc referred to a /'9"')' sy /nll Thi, teml i, often used. more panlcularl y, for 'ystcm that most peo ple wou ld like to rep l.ce but would be expcn .. vc to replace. As previou
o nllnuous mai ntcuanc c-

• Inef(l(.lencles due to oldcr tec hno logy

' 1; ., Increased coupling

7.'

750

CHAPTER 29

SOFlWARE MAINTENANCE

• La k of a cur.lle do umenlatiOn •

rigin.1 developers who fully unoerstond the systems ore no longer avatloblc

A the complexity of legacy sy
thl

information its design and specifica tions arc recreated . That is, we start w ith a low

level of abstraction (sou rce codcl and c reate a higher level of abstraction (design and documentation ). Another common technique is '('"9111((rI1l9 , where the sys tem IS restructured in order to Improve H5 design and maintainability . The re-e nglnee nng process ofte n sta rt s with reverse eng ineering

29.5.1 ReverSe Engineering Soft\Y'are products under maintenance have a wide va ncty of possible hi stories, many existing applications

are poorly or Inconsistently documented, and not very well understood. This leads to inefficiencies as maintenance engineers attempt to Implement MRs on systems they do n't fu ll y understand . Reverse engineering brings such a system to a consistent , documented, understood sta te. Two components of

reverse engineering arc "doCllm",'allo" and dcsi9" " COvcry [ 13 J. Redocumentation IS typicall y the first step in reverse engmeering in which documentation describing the system is generated from cxi ling source code. Several commercial tools arc available to assist in th is purpose, which ca n, fo r example , reformat the source code to make It morc readable or extract comments to form documents.

O nce the necessary documentation IS available, the next step is desig n recovery. This I the process of analyzing the available documentation and know ledge about a system in order to understan d its desig n. Once successfull y completed, improvement to the design and the system can be impitmented . T ools are available to generate UM L class diagrams fro m source code, for example. Th is usuall y produces a very complicated diagram. The diagram can be used to build the key parts of the UML by hand or by erasures. Suppose, for example, that we were to lose track of the UML for the Encounter video ga me. \Vie could Rrst ge nerate the UML for all of the code. After that we could start with a key class such as EncounterEnvironment , identify all classes that it relates to , select some am ong th ose to retain , and then repeat the process with those or stan with other known classes.

29.5.2 Reengineering The short·term goal of maintenance IS to fix a probl em or install a feature as soon as possible. The lo ng.term goa l is to position the changlOg system so that it continues to work efficiently Jnd with reasonable cost per MR into the future . Due to increasing complexit), and the escalation in cost per MR. we periodically take a fTesh look at the entire architecture and design of the system. Making c hanges to the architecrure fTOm the tOP down is the maIO task of ""'9 i ",m"9 . As defined by hlkofsky and Cross [ 13J reeng' . . h .. " . . . . Ineenng IS t e examination and alteration of a subject sys tem to reconstitute it in a new fann and t·h b .. c SU sequen r impkmcnt-ation of the new fann . Sometimes the rccnglnccrcd sys tem support new requ I're mems t h at t h e • older system was unable to implement. The overall goa l of reengineering is to c I cat".....• sys t ('m [ h at IS Ies complcx, and ultlmatd y . easier to maintain and less cos tl y. As an example of recnginecrlng, suppose that the video stOre appilcation IS reqUired to - k h 'd • ~hlC t c non ·v, co Items that customers purchase at the store (candy, paraphernalia etc ) In the absenCA of . . . . ' . . ... rcenglneenng , we might add vanables to the C. , 'omrrclass so that when c.,,'omrrob)cct< are storcd th.ese add' t Id • I lana ata arc stored at the same time. In all likelihood, this approach will eventually produce a hard· tO·Ill· t I" .. In

am app .cation.

MAINTENANCE METRICS

DVDs

DVDAccess ./ac.C»...

DVDRenlaJs

DVDRenlal VSCustomers

DVDCustomerAccess H

D

"'facade~

D

•

Figure 29.18 Original video store architecture DVDs DVDRenials

DVDAccess

-t<> DVDRentalAccess

wfacadelO

to

.. facade,.

nonVideoltel1 ts VSCustomers

NonVideoAccess .. facade ,.

.facade.

YidaoStore

• to be completed• Key: reenginccrcd parts:

I I XX

figure 29.19 Reengineered video slDre architecture Now lei's consider a recngi neering approoc h Recall the exisling video
29.6 MAINTENANCE METRICS Since mamlenance con um es a large fTa tion o( I,(e y Ie 051 . illS pJrll ularl important 10 qUMHify il and benefils NOI all orgaOlzallons have rhe sa me goal, in pur uinl: rnomlenan c rl-.",nI 2.lio", Arsl determme the m.,ntenance go.ls (or Ihe appl,callon . then , de tor trcale metne< thaI measure their de~ree

751

752

CHAPTER 29

SOFTWARE MAINTENANCE

Table 29 • 6 Maintenance metric selection by goal Goal

Question

Selected Corresponding Metrics (The numbered metnes are from the IEEE)

Maximize customer satisfaction

HOw many problems are affecting the customer?

• Fault density ~ INumber of faults found in the applicationVKSWC "Faults" are defects found during testing or operation. KSLOC - thou sands of lines of noncom men ted source statements • Mean time to failure = The average time it takes to obtain a

failure . of the application measured from startup . • BrealcJfix ratio = {Number of defects introduced by maintenance actlonsII/Number of defects repairedl How long does it take to fix a problem?

• Fault closure = Average lime required to correct a defect. from start of correction work. • Fault open duration =Average rime from defect detection to validated correction.

Where are the bottlenecks?

•

Staff utilization per task type

=Average person-months to (a)

detect each defect and (b) repair each defect . • Computer utilization =Average time/CPU time per defect. Where are resources being used?

Optimize effort and schedule

Effort and time spent, per defect and per severity category planning • • reproducing customer finding • • •

• •

•

• • •

Where are defects most likely to be found?

•

•

•

• • •

Minimize defects

•

reporting error repairing enhancing

•

Number of entries and exits per module • Cyclomatic complexity • Ratio of commented lines/ KLoC (KLoC = thousands of lines of source code, including comments)

-'-

of success in attai n ing th o e goa ls. Tabl e 29 .6, bosed o n a tabl e by Stark and Kern [ t4 ] , illustrates this b y sh owing h o w three di ffe rent goals indicate the u e of different m etrics. "The definition of "fail ure" for th e applicatio n under teSt depends on what th e customer pereeives as fai lure, and ra nges from app lication cras h es to specific types of problems. For a fi nancia l application, for example, any calculation resulti ng in a discrepancy of a dollar o r m o re cou ld be defined as a fai lure. In any case, the definitions should be explicit. Let's consider how metries ca n be used to manage a maintenance activity . Th e fractio n of co mmented lines i n the ouree code h elps to pred.ct th e relative magnitude of a maintenance effort. For example, suppose that the application bei ng m ain tained co nsi sts of three modules (Accounts Received, Timesheet, and Sick Day Recorder) each with the size and com menting data shown by the respective black and white dots in Figure 29.20. Compared with the AccounfS rcccivtd and T.mrshrtf m odules, the Si k Day R,rord" module is liable to produce the biggest mai ntenance ch allenge because .t .s larger and has J larger proportion of uncommented lines 01co de. The Accounts R,crivabl, m o dule is likely to be the least expe nsive to maintain because it .s the smalles t and has a h igher than average proportion of co mments. Th e proportion of comment lines ca n be obta i ned usi ng a uti l ity program or by counting from a random sample of pages of code.

MAINTENANCE METRICS

0

I I I I I I I I I I I I I I I

t

0

Percentage 01 comment lines

(higher value = lower maintenance effort)

0

•

•

Size (lower value = lower maintenance effort) I Module:

• I I I I

Accounts received

I I I I I I I I

•

I

I I I I I I

I I I

0

I

Timesheet

I

I I I I I

Sick day recorder

LOWEST

HIGHEST

EFFORT

EFFORT

I I I I I

Figure 29.20 Predicting relative maintenance efforts T o manage a ma in tenance effort, grap hs like the one In I-ig urc 29 .2 1 arc useful. These s how new, ope n, and closed MRs. According to the c han in Figure 29 .21 , a large number of reque ts for repair and en hancement arnved in the nrst twO yea rs, resu lting in a peak backlog during th e seco nd yea r. This backlog was eventua ll y worked off The pronle in Figure 29.2 1 is a typica l o ne , w hether the comparable time scale are years , mo nths, or weeks. T ypica ll y , th e maintenan ce ma na ger t-rics to account separately for fau lt and en han ement, so that the mte cost of the application , as reqUired, can be tra cked . To manage an orga nization's effective ness in handling the maintenance workload , a graph '" has th.· One in Figure 29.22 can be used. The graph shows the average number 01' weeks that a maintenance request (whether

800

o

700 600#

# MR's received

- - - - - - - - - - - - - i . # MR's completed •

# MR's cancelled #

500# 400+f" 300# 200# 100

2000 Alure 29,21 Measuring maintenance productivity

2001

2002

2003

753

754

CHAPTER 29

SOFlWARE MAINTENANCE

t

For example, In April, the average enhancement MR had been open (or 8 weeks.

If weeks

open

10+

o

o

o

·FOOng~

•

Enhancemenl MRs

MAs

o "

.. "

5+

o

o o

o

o

Figure 29.22 ASSessing maintenance operations a repair or an enhonccmcnt ) has been waiting for resolution, measured from the time it was first r~portcd. It shows a converge nce to on average dciay of about one week for repairs, and roughly four weeks for enhancements.

29.7 CASE STUDY The folloWing is an excerpt fro m the OpenOfnce documentation that illustrates 0 means of handling defects and e nhancements.

there is time ). Here is a general rule of thumb for priorities, P I-Ope nOfnce cannot be used fo r testing or development.

ISSUE HANDLING AS A QA TECHNIQUE IN OPENOFFICE The 1,,",Zilla (IZ ) tool is an accesSible li st of Open . Of nee "issues." These indude defects and en · hancements. OpenOfRce publishes guidelines and protocols for dealing with issues. The following is quoted f"rOm o penofnce.o rg. Priorities ran ge from PI (very urge nt) to P5 (will be considered when

P2-0penOffice crashes o r basic feotures do not work. P3-Bugs that usuall y involve a feature not working as expected . P4-Bugs that do not offect basic features and usuolly have workarounds. PS-Very min o r annoyin g bugs.

ISSUEZILLA STATISTICS

Note to the Student, Bugzilla allows graphical forms 01 data, which supplement tables such as that shown below. The core of bug tracking is a hislory of new>, existing, and clcxed issues Over lime. Table 29.7 is an example of the statistics available using IssueZ,lIa [ 15] during an exomple time penod. It tracks the number 01 dderts in each state (e.g., rrop<",d) within each major part (e.g., ,preadsbttt) of OpenOf6ce.

Tab le 29.7 Examples of statistics available using Issuelilla

Project

State

changes 08/ 02/04 07126/ 04 07/19/04 07/12/04 07/05/04 06/ 28/04 06/21/04 06/14/04 06/07/04 06/01104

Api

reopened

0

1

1

1

1

1

1

1

1

1

1

Api

started

2

101

99

98

94

97

93

95

100

99

97

Api

unconfirmed

1

15

14

13

14

23

21

15

11

13

13

Api

new

-4

74

78

82

85

70

71

64

59

61

67

191

192

194

194

191

186

175

171

174

178

ap' Result Chart

reopened

0

0

0

0

0

0

0

0

0

0

0

Chart

started

0

47

47

46

46

42

40

40

38

40

43

Chart

unconfirmed

1

4

3

1

1

1

3

2

2

2

0

Chart

new

0

3

3

3

3

3

3

1

3

2

3

54

-53

50

-

50

-

46

-

46

-

43 -

43

-

44

46

database access

reopened

- 1

4

5

6

5

5

5

5

2

2

-2

database access

started

- 1

30

31

29

29

28

30

30

31

31

31

database access

unconfirmed

6

35

29

27

25

23

22

20

17

23

22

database access

new

- 1

72

73

75

74

86

96

96

58

61

59

141

138

137

133

142

153

151

108

117

114

chart Result

daUJbase access Result

-

-

~

§ .......

...

756

CHAPTER 29

SOFTWARE MAINTENANCE

T.,hlc 29 I ,how, defect , taLU at a summa ry leve l It " a u,oful furm for pro JcU leade"h.p when J "c" .n~ the matum of rc cnt MRs. ther form, of th e data
29.8 SUMMARY Software sys l e m s CO llt'l11UC' to l'volvt' after th c lr Inllial deve lopment and rel ease

o(tware mainte nance

co nsist o f those aCllv .t ies that are performcd o n the sy, tem after .t< release, such as rcpa or of defects, Implemen tation of enha ncements, and adaptation to changes In the enviro nmen t

The hallen ges of software mJ,,\lenance full into three mam arc", management , procc«, and techOlca\. "1anagcmcnl must undC'rsrand th e comple xit y and va llie o f maintenance and prOV ide adequate support .

Impl emcntong Jn efficient maintenance process helps rcdu e the complexity T ec hn. ca l challenges In lude th e desig n of regres ion te sts to ensure that Implemented malntcnan

C

requests do not havt" unintended '§I de

dfcc!> o n olher parts of the system . A tYP ical ma.intenance process starts with eu tamers provi din g co mm ent

on enhancementS

and defect s through the help desk . The care wrinen up as Maintenance Requ e ts (MRs ) MRs are reg ularly rcvie,y"d and prioritized , often by a change control board (CCS ). The CC B . composed of stakeholde r g ro ups suc h as development , use r documentati o n, marketing , quality assurance , and customer support .

An impact anal ysi i performed on incoming MRs that assesses the sco pe of the change to product artifacts that arc required in order to impiement the MR. Each group represented by the CCB prov.des inpUt.

Root·cause analysis is a process conducted after complet ing the repair of a defect MR. It purpo e is to determine the underlying reason that a defect has occurred . This information is then u ed to .mplement process improvements so that si milar defects are prevented from occurring on the future . IEEE Std 1219-1998 describes an iterative process for managing and execut.ng software maintenance activities. The standard defines seven phases that an MR flows through , similar to the pha ses that Occur during new product development, MR identification and prioritization , analysis, design , .mplementation , testing, and delivery. Each phase has six attributes associated with it that describe the activitie and data for that phase, input , process, control , output, quality factors , and metrics. As software systems evolve , they become more complex and less understood. Freque ntl y, much of the original documentation is lost or outdated, and man y if not all of the o ngonal devel opers are no longer available . Reverse engineering is a process that reconstructs system documentation, such as cnhan ed, mort" readable code, or class diagrams, from existing source code . An understand ing of software arc hitecture and de ign is then constructed from the new documentation . Periodically, organizations take a fresh look at the whole design of a ystcm , with the goal of reducing its complexity, increaSing its efficiency, and making it more cost effective to maintain . Changong to the software architecture and design to meet these goals is referred to as reengineering. This IS especially needed for older systems whose design has deteriorated over time. It is common for organizations to define specinc malOtenance goal and then de t or create metri that measure the organization's degree ofswccess in attaining those goals. For example. of a goal is to ",tn i mi~ defects. metrics would be collected to measure the complexity of the code. with a goal of retactonng tho areas that have the highest complexity.

EXERCISES

29.9 EXERCISES 1. DeRne the term · sohwar-e maintenance" in one entcncc.

2 D~cri~ in your own words four types of software maintenance. Is there an example of a maintenance request that might overlap two of the categories1

3. Give examples of corrective, adaptive, perfective, and preventive c hanges for the Encounter case study. 4 . Suppose that a proposal is made to change the le ngth of an array in an application to accommodate

requirements that were not previously satisfied. What activity is reqUIred before actual changes in the code can be made) 5. Describe a practical scenario in which the rather lengthy maintenance now illustrated in Figure 29 6 might need to be circumvented) 6 . A propo al has been made to implement the following requirement for the Encounter ca e study, which was initially designated optional. PlayerCharacter Requirement [desirable] ("Player character image") The player shall have the option to choose the image representing her main c haracter from at least 4 elF files a. What type of maintenance request (MR) is this) b. Provide an impact analysis for this MR. 7. Which of the following would require reengineering. Explain . a. Convert a simu lation of the operations of a bank into an automated bank security ys tem . b. Add to a simulation of the operations of a bank so that it handles the moveme nts of security personnel. c . Modify an online tutoring ystem 0 that it ca n to provide multiple-choice quizzes at any time to permit tudents to asses their understanding of what they are currentl y reading. 8. There are many co mmercial rever e engineering too ls that automatically genera te docu · mentati o n from source code. Using Inte rnet resea rch , Identify two suc h tools and descnbe the types of documentation the y generate , Explain h ow the documentati o n c1arines the source code

Maintenance (a) Obtaon projec t specdica tl o n, from twO o the r teams Ir. the la" Propo e at least une 01 c. h of the fo llOWing type, o f mo dification" orrec tl ve, adaptive, pcrfee.ivc , and preventive (ill Anothe r learn Will have proposed four ~uLh modir, tlo n< to your pro)c l. Develo p an Imp3 t asses~ment on your prOJect of each 0 1 the< mOOlnCatlOI1<

151

758

CHAPTER 29

SOFlWARE MAINTENANCE

( ) NegotlJte with the tca m proposin~ modifica tions to your project to make them reasonable In terms of the resources required , then Implement these modiAca tions. (d ) Implement, tcst, and measure your modifications Evaluation cri tena: ( I ) Degree to which the propo cd modifications arc of the types specified (2 ) Completeness of yo ur impact assessments (3) Degree to which the modifications have been tested

BIBLIOGRAPHY I ·,EEE St3ndard C losSilry or Soft""'Jr(' EngmC'cring Tc:munology,· IEfE Sid 6fO 12 · 19 90, Dccc:mbcr 1990 2 Foster, ) . Cost FJClo,,", In Softwa re M.,imcnancc, Ph D thesIs, Umversity of Durham. NC. Computer Science Dept, 1994 . as noted on [9)

.. 5

6 7.

8. 9

10. 11 12. 13

en, ProClted for A14Jlfagmg

Your SofrlD~rr !.mrs,.".ett', John Wiley &; Sons, 1996 LLhman, M , "Program .. , Life Cycles, and the: Laws of Software Evolulion," ProcrrJ'"9s IEEE, No 19, 1980, pp. 1060-1076 Lehman , M . "Progr3m Evolution Inlo m1311 on Procc~'SinJ.: Management: ProcttJilf9s fEEf. No. 20, 1984 , pp 19-36 Lentz, !knnt'n J> . and E. Bunon Swanso n, "Sofh"nrr Mn i"fnlaflCt MDrur9011ntl," Addison·Wc:slc:y, 1980. Llcntz, Bennctt P., E. Bunon Sw;)nson, and G<:ny E Tompkins, ·Char"ctcri'stics or Apphcallon5 Softwa re: Maintenance,· 0!ft"'111'11 {"aho"~ oj the ACAI (CA CM), No 21 , 1978, pp. 466-471. Bennet!, K.,"Soh",arc Malntcnance, A T ulOnal: Softw3 rc Engin("cn ng. IEEE Com/lIlla Soclrty, November 1999, as notcd In [Dorfman .lnd Tha yer. 19'-)9 J Rakltl n, Stcvcn R.. "SofhDtJrt Vcnjicallon a"d Validation fot PraChlrontr1 lind MII"agrn:," Artcch H ou~c Publishers. 200 I " McConnell. StC'Ve. "'Rapul Dnxfo"",ml To".ing Wild SojhDlH( 5
3. Pigosk •• Th oma .. M . Practical Sojfll."Jrt Ma'"'1'lt4lfCC

1990, pp 13-17 I..

Stark , Cc-orgc E , 3nd LOUIlOC C. Kcm, aA Sohwarc Metric Sel for Progr"m Maintenance Managcmcnt,- )(}uTMI of SYJf""S lIMd Sof'~IIIT.

No 24. 1994 , pp 239- 249. 1S. Opc:nOfAcc. hup:I/qa.opc-nofncc:.orgt. z_slatl.ak,hlml lacccsscd November 18, 2009).

Software Engineering: Modern Approaches

Read more

Fundamental Approaches to Software Engineering

Read more

Fundamental Approaches to Software Engineering

Read more

Fundamental Approaches to Software Engineering - FASE 2011

Read more

Evaluation of Novel Approaches to Software Engineering

Read more

Software Engineering

Read more

Software Engineering

Read more

Software Engineering

Read more

Software Radio Architecture: Object-Oriented Approaches to Wireless Systems Engineering

Read more

Fundamental Approaches to Software Engineering, 11 conf., FASE 2008

Read more

Mathematical Approaches to Software Quality

Read more

Software Security Engineering

Read more

Value-Based Software Engineering

Read more

Software Engineering 3

Read more

Software engineering measurement

Read more

Software Engineering, 9th Edition

Read more

Programming and Software Engineering)

Read more

Engineering Software for Accessibility

Read more

Value-Based Software Engineering

Read more

Software Engineering (6th Edition)

Read more

Rationale-Based Software Engineering

Read more

Programming and Software Engineering)

Read more

Advances in Software Engineering

Read more

Agile software engineering

Read more

Intelligent Agent Software Engineering

Read more

Software Engineering Handbook

Read more

Automotive Software Engineering

Read more

Programming and Software Engineering)

Read more

Categories for Software Engineering

Read more

Classics in Software Engineering

Read more

Recommend Documents

Software Engineering: Modern Approaches

Brief Contents Prefa C X IV Acknowledgmen ls Part I Part II •• XVII Introduction to Software Engineering Software ...

Fundamental Approaches to Software Engineering

Lecture Notes in Computer Science Edited by G. Goos, J. Hartmanis, and J. van Leeuwen 2984 3 Berlin Heidelberg New Y...

Fundamental Approaches to Software Engineering

Lecture Notes in Computer Science Edited by G. Goos, J. Hartmanis, and J. van Leeuwen 2984 Springer Berlin Heidelber...

Fundamental Approaches to Software Engineering - FASE 2011

Lecture Notes in Computer Science 6603 Commenced Publication in 1973 Founding and Former Series Editors: Gerhard Goos...

Evaluation of Novel Approaches to Software Engineering

Communications in Computer and Information Science 230 Leszek A. Maciaszek Pericles Loucopoulos (Eds.) Evaluation o...

Software Engineering

First Edition, 2009 ISBN 978 81 907188 8 2 © All rights reserved. Published by: Global Media 1819, Bhagirath Palace,...

Software Engineering

Argila, C.A., Jones, C., Martin, J.J. “Software Engineering” The Electrical Engineering Handbook Ed. Richard C. Dorf Boc...

Software Engineering

0321313798_cover.qxd 26/4/06 17:48 Page 1 Software Engineering S O M M E RV I L L E SOMMERVILLE 8 The 8th editio...

Software Radio Architecture: Object-Oriented Approaches to Wireless Systems Engineering

Software Radio Architecture: Object-Oriented Approaches to Wireless Systems Engineering Joseph Mitola III c Copyright !...

Fundamental Approaches to Software Engineering, 11 conf., FASE 2008

Lecture Notes in Computer Science Commenced Publication in 1973 Founding and Former Series Editors: Gerhard Goos, Juris ...