Chapter 6 Designb

8/2/2019 Chapter 6 Designb

1/93

6. DESIGN II:DETAILED DESIGN


2/93

Plan

project

Integrate

& test system

Analyzerequirements

Design

Maintain

Test unitsImplement

Software Engineering

Roadmap:

Chapter 6 Focus

Identify

corporate

practices

Develop

Architecture

-see chapter 5

Perform Detailed Design

-apply design patterns- accommodate use cases

supply methods

- exploit libraries (STL, Java, )- describe methods where required

- develop detailed object models

- develop other models

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.


3/93

Chapter Learning Goals

Understand how design patterns

describe some detailed designs

Specify classes and functions completely

Specify algorithms

use flowcharts

use pseudocode



4/93

1. Introduction to Detailed Design


5/93

Relating Use Cases, Architecture, & Detailed Design

1. Use case --analysis

Cars should

be able to

travel from thetop of Smith

Hill at 65 mph,

travel in a

straight line,

and arrive at

Jones Hollow

within 3

minutes.

3. Architecure2. Domainclasses

Auto

Road

Cable

Pylon


6/93

Relating Use Cases, Architecture, & Detailed Design

1. Use case(part of

requirements)

Cars should

be able totravel from the

top of Smith

Hill at 65 mph,

travel in a

straight line,

and arrive at

Jones Hollow

within 3

minutes.

3. Architecure2. Domainclasses

Auto

Road

Support use case

Auto

Road4. Detailed

Design

Smith

Hill

Cable

Cable

Jones Hollow

Pylon

Pylon

(not specifically required)

(added for

detailed design)

Guardrail



7/93

Typical Roadmap for Detailed Design

1. Begin with architectural models-- see chapter 5 class model: domain & architectural classes

overall state model*

overall data flow model*

overall use case model (several use cases)

3. Refine models & make them consistent -- see section tbd

2. Introduce design patterns & classes which connect the

architecture classes with the domain classes -- see section tbd

. . . . .


8/93

Typical

Roadmap

for

Detailed

Design

8.Release for implementation

1. Begin with architectural models -- see chapter 5

class model: domain & architectural classes

overall state model*

overall data flow model* use case model

6. Sketch unit test plans -- see chapter 8

7. Inspect test plans & design -- section 9

3. Refine models, make consistent, ensure complete

5. Specify methods with pre- and post-conditions,

flowcharts* & pseudocode* -- sections 3 and 4

2. Introduce classes & design patterns* which connect the

architecture classes with the domain classes --sections 1 and 5

concentrate on riskiest parts first; try alternatives

4. Specify class invariants* -- section 3.1

* if applicable

For each class ...

For each method ...

For each unit ...



9/93

Organize the Team for Detailed Design 1/2

1. Prepare for a detailed design kick-off meeting.

Ensure team members aware of the models (views) they

are expected to produce

typically object model, sequence diagrams, state, & data flow

Ensure team members aware of the notation expected typically: UML plus a pseudocode standard and/or example

Design leader prepares list of modules

Design leader creates a meeting agenda

Project leader allocates time to agenda items

(people can speak about detailed designs indefinitely if allowed to!)

allocate the time among the agenda items



10/93

Organize the Team for Detailed Design 2/2

2. Hold the kick-off meeting Designate someone to monitor the agenda item time Confirm that the architecture is ready for detailed design

Make sure that module interfaces the are clear revise as a group if not

Dont try to develop detailed designs as a group not necessary: individuals have the responsibility groups are seldom good at designing details together

Allocate modules to members Request time estimates to design lead by a fixed date

Write out the conclusions and copy/e-mail every member Decide how and when the results are to be reviewed

3. Update the documentation set

more detailed schedule with modules & inspections4. Inspect the detailed designs

see figure TBD below

5. Rework as a result of inspections6. Conduct post mortem and write out lessons learned



11/93

Unified Software Development Process: Design

Inception Elaboration Construction TransitionU. P. Term

Requirements

Analysis

Design

Implemen-tation

Test

(Jacobson et al) Prelim.

iterations

Iter.

#1

Iter.

#n

Iter.

#n+1

Iter.

#m

Iter.

#m+1

Iter.

#k.. ..

1*

3

2

1 = 3 =2 =

*Key: terminologyused in this book Requirements Achitecture

Detailed

design

Jacobson et al:


12/93

Analysis

1. Conceptual & abstract

2. Applicable to several

designs

1. Concrete:

implementationblueprint

2. Specific for an

implementation

After Jacobson

et al: USDP

Design 1/2


13/93

Analysis

1. Conceptual & abstract

2. Applicable to several

designs3. control, entity &

boundary

stereotypes

4. Less formal

5. Less expensive to

develop

1. Concrete:

implementationblueprint

2. Specific for an

implementation

3. No limit on class

stereotypes

4. More formal

5. More expensive to

develop ( 5)

After Jacobson

et al: USDP

Design 1/2


14/93

6. Outlines the design

7. Emerges from

conceptual thinking

8. Lower priority for in-

process maintenance

6. Manifests the design

(architecture one view)

7. May use tools (e.g. visual,

round-trip engineering)

8. Higher priority for in-

process maintenance

Analysis After Jacobsonet al: USDP

Design 2/2


15/93

6. Outlines the design

7. Emerges fromconceptual thinking

8. Lower priority for in-process maintenance

9. Relatively

unconstrained10. Less focus on

sequence diagrams

11. Few layers

6. Manifests the design

(architecture one view)

7. May use tools (e.g. visual,

round-trip engineering)

8. Higher priority for in-process maintenance

9. Constrained by theanalysis & architecture

10. More focus on sequence

11. Many layers

Analysis After Jacobsonet al: USDP

Design 2/2


16/93

Designing Against Interfaces

Customerbill()

printAccounts()

RegularCustomer

bill()

printAccounts()

BillingClient

listCustomers()

billCustomers()

Abstract layer

Concrete (non-abstract) layer

Client code Used code

-- written in terms of

Customer (not

specific types of

Customer)



17/93

2. Sequence and data flow diagrams

for detailed design


18/93

Refine Models forDetailed Design

1/2: Sequence Diagrams

1. Begin with the sequence diagrams constructed for

detailed requirements and/or architecture (if any)

corresponding to the use cases.

2. Introduce additional use cases, if necessary, todescribe how parts of the design typically interact

with the rest of the application.

3. Provide sequence diagrams with complete details be sure that the exact objects & their classes are specified

select specific function names in place of natural language

(calls of one object to another to perform an operation)



19/93

1. Gather data flow diagrams (DFDs) constructed fordetailed requirements and/or architecture (if any).

2. Introduce additional DFDs, if necessary, to explaindata and processing flows.

3. Indicate what part(s) of the other models the DFDscorresponds to.

e.g., the following DFD is for eachAccountobject

4. Provide all details on the DFDs

indicate clearly the nature of the processing at each node

indicate clearly the kind of data transmitted

expand processing nodes into DFDs if the processingdescription requires more detail

Refine Models forDetailed Design

2/2: Data Flow Diagrams



20/93

2. execute()

2.1 setPlayerQuality()

2.3 setForeignQuality()

engagement:Engagement

1.3 new Engagement()

3.2 displayResult()

:Players

maincharacter

:Encountergame

Sequence Diagram forEncounter Foreign Character Use Case

:EngagementDisplay

freddie:Foreign

Character

1.2 display()

:EncounterCast

1.1 displayForeignChar()

2.2 setQuality()

2.4 setQuality()


3.1 new EngagementDisplay()


21/93

Classes of theEncounterForeignCharacter Use Case

Engagementexecute()

EngagementDisplaydisplayResult()

EncounterGame

EncounterCastdisplayForeignChar()

setPlayerQuality()

setForeignQuality()ForeignCharacter

setQuality()

PlayerCharacter

setQuality()



22/93

Detailed Data Flow Diagram for a Banking Application

User

Customer.

getDetails()Cus-tomer

Account.

getDeposit()

. . . . .


23/93

screen

template

Detailed Data Flow Diagram for a Banking

Application

User

Customer.

getDetails()

Account.getPass-

word()Account.

verifyPass-

word()

Expand details

..

Pass-word

Cus-tomer

Account

unacceptable

ATM users

Cus-

tomer

Deposit-

screen.display()

Account.

getDeposit()

status

local

log



24/93

3. Specifying classes and functions


25/93

1. Gather the attributes listed in the SRS.

if the SRS is organized by class

2. Add additional attributes required for the design.

3. Name a method corresponding to each of therequirements for this class.

easy if the SRS is organized by class

4. Name additional methods required for the design.5. Show the attributes & methods on the object model.

6. State class invariants.

Specify A Class



26/93

Specify a Function

1. Note the section(s) of the SRS or SDD which this

function (method) satisfies.2. State what expressions the function must leave

invariant.

3. State the methods pre-conditions (what it assumes).

4. State the methods post-conditions (its effects).

5. Provide pseudocode and/or a flowchart to specify the

algorithm to be used.

unless very straightforward



27/93

Classes at Detailed Design

Responsibilities:

-- describes eachcanister undergoing

fabrication

+ display()- getNumSlotsOpen()+ setStatus()

+ numCanisters: int- numWafers: int- size: float

Canister Class name

Attribute: type

+: visiblefrom without Operations

Place forcomments



28/93

Specifying Functions: withdraw() inAccount

Invariant ofwithdraw():availableFundsI= max( 0,balanceI)

*The function invariant is an additional pre- and post-condition

xIdenotes

an

attribute;

xP denotes

a function

parameter;

x'is the

value ofxafter

execution;

Xdenotes a

class

constant

. . . . .


29/93

Specifying Functions: withdraw() inAccount

Invariant ofwithdraw():

availableFundsI= max( 0,balanceI)

Precondition*:

withdrawalAmountP >= 0 ANDbalanceI- withdrawalAmountP

>= OVERDRAFT_MAX

Postcondition*:

balanceI' =balanceI- withdrawalAmountP

*The function invariant is an additional pre- and post-condition

xIdenotes

an

attribute;

xP denotes

a function

parameter;

x'is the

value ofxafter

execution;

Xdenotes a

class

constant



30/93

4. Specifying algorithms


31/93

Flowchart

Example

protected final void setName( String aName ){

// Check legitimacy of parameter and settingsif( ( aName == null ) || ( maxNumCharsInName() alltimeLimitOfNameLength() ) ){ _name = new String( "defaultName" );

System.out.println( "defaultName selected by GameCharacter.setName()");

}

else// Truncate if aName too longif( aName.length() > maxNumCharsInName() )

_name = new String( aName.getBytes(), 0, maxNumCharsInName() );

else // assign the parameter name

_name = new String( aName );}

Parameter &

settings make

sense?

Set _name to

defaultName"

Y

Parameter

name too

long?

N

TruncatenameSet _nameto parameter

YN

Nominal path



32/93

An Architecture for Chaining

RuleaddRule()

proveAntecedents()forwardChain()

Factcontent

addFact()proveBack()

consequent

antecedents

static factList static ruleBase

Set Fact.factList to the known factsand a Rule.ruleBase to the known rules.

Create Fact object soughtFact

Execute soughtFact.proveBack( ruleBase );

1

1..n


Flowchart for


33/93

Flowchart for

soughtFact.proveBack( ruleBase )soughtFact

in factList?

N

Another rule R

with

soughtFact as

consequent?

Y

ApplyR.proveAntecedents()

YNominal path

Succeede

d?

Report TRUE

Y

Report FALSE

N

N



34/93

FOR number of microseconds supplied by operator

IF number of microseconds exceeds critical value

Try to get supervisor's approval

IF no supervisor's approval

abort with "no supervisor approval for unusual

duration" message ENDIF ENDIF

Pseuodocode Example

See section tbd

for inspection

results of this

pseudocode

. . . .

FOR b f i d li d b t


35/93

FOR number of microseconds supplied by operatorIF number of microseconds exceeds critical value

Try to get supervisor's approvalIF no supervisor's approval

abort with "no supervisor approval for unusual

duration" message ENDIF ENDIF

IF power level exceeds critical value

abort with "power level exceeded" message ENDIFIF ( patient properly aligned & shield properly placed

& machine self-test passed )

Apply X-ray at power level p ENDIF. . . . . . .ENDFOR

PseuodocodeExample

See section tbd

for inspection

results of thispseudocode



36/93

//p FOR number of microseconds supplied by operator

for( int i = 0; i < numMicrosecs; ++I ) {

//p IF number of microseconds exceeds critical valueif( numMicrosecs >

XRayPolicies.CRITICAL_NUM_MICROSECS )

//p Try to get supervisor's approval

int supervisorMicrosecsApproval =

getApprovalOfSuperForLongExposure();

//p IF no supervisor approval

if( supervisorMicrosecsApproval


37/93

Advantages of Pseudocode & Flowcharts

Clarify algorithms in many cases

Impose increased discipline on the process of

documenting detailed design

Provide additional level at which inspection canbe performed

Help to trap defects before they become code

Increases product reliability

May decreases overall costs



38/93

Disadvantages of Pseudocode & Flowcharts

Creates an additional level of documentation

to maintain

Introduces error possibilities in translating

to code

May require tool to extract pseudocode and

facilitate drawing flowcharts



39/93

5. Design Patterns II: Techniques of

detailed design

A l D i P tt i D il d D i


40/93

Apply Design Patterns inDetailed Design

1. Become familiar with the design problems solved by

design patterns at a minimum, understand the distinction among (C)

creationalvs. (S)structuralvs. (B)behavioralpatterns

Consider each part of the detailed design in turn:

2. Determine whether the problem has to do with (C)

creating something complex, (S) representing acomplex structure, or (B) capturing behavior

3. Determine whether there is a design patterns thataddresses the problem try looking in the category identified (C, S, or B)

use this book and/or Gamma et al [Ga]

4. Decide if benefits outweigh drawbacks benefits usually include increased flexibility drawbacks increased class complexity(?), less efficient(?)



41/93

Factory: Example

AnimalCell

getNewCellObject()

PlantCell

getNewCellObject()

Factory design pattern

BiologicalCell

getNewCellObject()Client


P t t E l


42/93

MyOfficeApplication

myMethod()

Prototype: Example

PurchaseOrderDocument

clone()

InvoiceDocument

clone()

Document

clone()

_documentPrototype

Client

. . . . .


P t t E l


43/93

MyOfficeApplication

myMethod()

Prototype: Example

PurchaseOrderDocument

clone()

InvoiceDocument

clone()

Document

clone()

documentPrototypeS

Client

Customer

clone()

CashCustomer

clone()

CreditCustomer

clone()

customerPrototypeS


P D i P T i l C d 1/2


44/93

public class MyOfficeApplication

{ private static Document documentPrototypeS;

private static Customer customerPrototypeS;

Prototype Design Pattern: Typical Code 1/2

This class is unaware of which type (subclass) of

Documentor Customerit is being executed with

. . . .

public class MyOfficeApplication P t t


45/93

public class MyOfficeApplication

{ private static Document documentPrototypeS;

private static Customer customerPrototypeS;public MyOfficeApplication

( Document dProtopypeP, Customer cPrototypeP )

{ documentPrototypeS = dProtopypeP;customerPrototypeS = cPrototypeP; }

public myMethod

{ . . . .// Need a new Document object:Document d = documentPrototypeS.clone();

. . . .// Need a new Customerobject:

Customer c = customerPrototypeS.clone(); . . .

Prototype

Design

Pattern:

Typical

Code 1/2

This classisunawareof whichtype(subclass)of

DocumentorCustomerit is beingexecutedwith


b t t l D t Prototype Design


46/93

abstract class Document

{ protected Document clone();

}

Prototype Design

Pattern: Typical

Code 2/2

. . . .

b t t l D t Prototype Design


47/93

abstract class Document

{ protected Document clone();

}

Prototype Design

Pattern: Typical

Code 2/2

public class InvoiceDocument

{ . . . .

protected Document clone()

{. . . . return new InvoiceDocument();

}

public class PurchaseOrderDocument

{ . . . .protected Document clone()

{. . . . return new PurchaseOrderDocument();

}

Customerhas an

equivalent

hierarchy of

classes

implementing

clone()


Client


48/93

AbstractFactory

Applied to

Encounter

Area

Level3Area

Level3Factory

getArea()

getAreaConnection()

EnvironmentFactory

getArea()

buildConnection()

EncounterEnvironment

Client

1..n

. . . . .

A tA () {


49/93

Abstract Factory Applied toEncounter

Area

Level2Area

Level2Factory

getArea()

getAreaConnection()

EncounterAreaConnection

EnvironmentFactorygetArea()

getConnection()

EncounterEnvironmentgetArea()

getConnection()

incrementLevel()

Level2AreaConnection

Client

create create

1..n

1..n

Area getArea() {

return envFactory.getArea();

}

envFactory


Client


50/93

Abstract

Factory

Applied to

Encounter

Area

Level2AreaLevel1Area Level3Area

Level1Factory

getArea()

getAreaConnection()

Level2Factory

getArea()

getAreaConnection()

Level3Factory

getArea()

getAreaConnection()


EnvironmentFactory

getArea()

getConnection()


Level1AreaConnection Level2AreaConnection

Client

Level3AreaConnection

create

1..n


The Basis for Composite & Decorator Structures


51/93

NonLeafNode

The Basis for Composite & Decorator Structures

Component

every object involvedis a Componentobject

non-leafnodeshave one or

morecomponents

leaf nodenon-leaf node


Composite & Decorator Structures


52/93

NonLeafNode

doIt()

Composite & Decorator Structures

etc.

component

Component

doIt()

Leaf

doIt()

TypeANonLeafNode

doIt()

TypeBNonLeafNode

doIt()

Composite: 1..n

ClientDecorator: 1

for all elements e in component

e.doIt()


Architecture of Encounter: Class Model


53/93

Architecture ofEncounter: Class Model

EncounterCharacters

EncounterGame

EncounterCast

EncounterGame




Ad t D i P tt


54/93

Adapter Design Pattern

Financialamount() Principal

computeValue()

Client

Legacy systemAdaptationApplication

Ad t D i P tt


55/93

FinancialAdapter

amount()

AdapterDesign Pattern

{ legacyAdaptee.computeValue(); }

Financialamount() Principal

computeValue()

Client

Legacy systemAdaptation

legacyAdaptee

Application


Proxy Design Pattern After Gamma et al


56/93

Proxy Design Pattern After Gamma et alBaseActiveClass

expensiveMethod()

cheapMethod()

RealActiveClass

expensiveMethod()

cheapMethod()

Proxy

expensiveMethod()

cheapMethod()

Client

_realActiveObject

. . .if( _realActiveObject == null ){// never referenced

_realActiveObject = getRealActiveObject();

_realActiveObject.expensiveMethod(); }

After Gamma et al


Th I D i P

Key: Intended sequence


57/93

TheIterator Design Pattern

iterator:

Iterator

element:

Element

Aggregate of

Element

objects

y q

ofElementobjects

Afterfirst()executes, iteratorreferences this

object.

Afternext()

executes, iteratorreferences thisobject.

Before next()executes, iteratorreferences this

object.


The Mediator Design Pattern


58/93

TheMediator Design Pattern

Encapsulates behavior among objects of a

class so that they neednt refer to each other.

Mediator Colleague

ConcreteMediator

ConcreteColleague1 ConcreteColleague2

Gamma et al

The Mediator Design Pattern


59/93

TheMediator Design Pattern

EngagementDisplayItem

Mediator Colleague

ConcreteMediator ConcreteColleague1 ConcreteColleague2

SetQualitiesDisplay

Applied toEncounter

QualListDisp QualValueDisp

EncounterDisplay

StrengthEnduranceIntelligence

Patience

Value

16.18Endurance



60/93

7. Standards, notation and tools for

detailed design

IEEE 1016-1987 Software Design Document Table of Contents (Reaffirmed 1993)


61/93

1. Introduction1.1. Purpose1.2. Scope

1.3. Definitions, acronyms& abbreviations

2. References3. Decomposition description

3.1. Module decomposition

3.1.1 Module 1 description3.1.1 Module 2 description

3.2 Concurrent processdecomposition

3.2.1 Process 1 description

3.2.2 Process 2 description3.3 Data decomposition

3.3.1 Data entry 1 description3.3.2 Data entry 2 description

4. Dependency description4.1 Intermodule dependencies4.2 Interprocess dependencies

4.3 Data dependencies5. Interface description

5.1 Module interface5.1.1 Module 1 description5.1.2 Module 2 description

5.2 Process interface5.2.1 Process 1 description5.2.2 Process 2 description

6. Detailed design

6.1 Module detailed design6.1.1 Module 1 detail6.2.2 Module 2 detail

6.2 Data detailed design6.2.1 Data entity 1 detail

6.2.2 Data entity 2 detail

Architecture

/**Java Source with Javadoc 1/2


62/93

No character name willever exceed this length */

public final int

alltimeLimitOfNameLength() ..

/** For logging*/

protected void display()..

/**

Accessor of _name."defaultName" assignedif this is first-timeaccess.

*/

public String getName()..

Java Source with Javadoc 1/2

..

/**Character of role-playing games.

@author Eric Braude

@version 0.1, 7/14/98

*/public abstract class GameCharacter

{

/**

Name of the game character;initially null

*/

private String _name;


Java Source with Javadoc 2/2


63/93

/**

Subclasses must declare limit on size of character names

*/protected abstract int maxNumCharsInName();

/**

Sets _name to aName if length is within aMaxNumCharsin length; otherwise truncates.

Inheritors should use this for setName( String ), but notoverride

@param aName: proposed name for _name

@param aMaxNumChars -- at which to truncate aName

*/

protected final void setName( String aName ) ..

..Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.


64/93

8. Effects on projects of completing

detailed designs

1. Make sure the SDD reflects latest version of detailed


65/93

1. Make sure the SDD reflects latest version of detaileddesign, as settled on after inspections.

2. Give complete detail to the schedule (SPMP).

3. Allocate precise tasks to team members (SPMP).4. Improve project cost & time estimates (see below).

5. Update the SCMP to reflect the new parts.

6. Review process by which the detailed design wascreated, & determine improvements. Include ...

time taken; broken down to include preparation of the designs

inspection

change

defect summary number remaining open, found at detailed design, closed at

detailed design

where injected; include previous phases & detailed design stages

Bring the ProjectUp-to-Date

After CompletingDetailed Design


Estimate Size & Time from Detailed Designs


66/93

Estimate Size & Time from Detailed Designs

1. Start with the list of methods

ensure completeness, otherwise underestimate will result2. Estimate the lines of code (LOC) for each

classify as very small,small,medium, large, very large normally in 7% / 24% / 38% / 24% / 7% proportions

use personal data to covert to LOC otherwise use Humphrys table below

3. Sum the LOC

4. Covert LOC to person-hours

use personal conversion factor if possible otherwise use published factor

5. Ensure that your estimates of method sizes and timewill be compared and saved at project end.


CATEGORY

Table 6.1 Lines of code


67/93

Very

smallSmall Medium Large

Very

large

METHOD

TYPE

Calcula-

tion

2.34 5.13 11.25 24.66 54.04

Data 2.60 4.79 8.84 16.31 30.09

I/O 9.01 12.06 16.15 21.62 28.93

Logic 7.55 10.98 15.98 23.25 33.83

Set-up 3.88 5.04 6.56 8.53 11.09

Text 3.75 8.00 17.07 36.41 77.67

Table 6.1 Lines of code

(Humphrey)

N l Di t ib ti f M di S ll t


68/93

Normal Distribution of Medium, Small etc.

-2

Standard deviations from the mean

VS

7%

Approximate

percentage of

methods

classified with thisdescription

N l Di t ib ti f M di S ll t


69/93

Normal Distribution of Medium, Small etc.

0 1-1 2-2

Standard deviations from the mean

MS L

VS VL

38%24% 24% 7%7%

Approximate

percentage of

methods

classified with this

description



70/93

9. Quality in detailed designs

Inspect Detailed Designs 1 of 2


71/93

p g

1. Prepare to record metrics during the design process.

Include (1.1) time taken; (1.2) type of defect; (1.3) severity

2. Ensure each architecture module is expanded.

3. Ensure each detail is part of the architecture.

if a detail does not belong to any such module, the

architecture may have to be revised

4. Ensure the design fulfills its required functions

5. Ensure that design is complete (classes & methods)

6. Ensure that the design is testable.

See chapter 1 for inspection procedures.Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

7. Check detailed design for --


72/93

7. Check detailed design for

simplicitya design that few can understand (after a legitimate

effort!) is expensive to maintain, and can result indefects

generalityenables design of similar applications?

expandability

enables enhancements?

efficiencyspeed, storage

portability

8. Ensure all details are provided only code itself is excluded as a detail

the detail work must be done eventually, and thisis the best time to do it: dont postpose

InspectDetailed

Designs2 of 2


Severity Description


73/93


Urgent

Failure causes system crash, unrecoverable data

loss; or jeopardizes personnel

HighCauses impairment of critical system functions,

and no workaround solution does exist

MediumCauses impairment of critical system functions,

though a workaround solution does exist

Low Causes inconvenience or annoyance

None None of the above

Table 6.2 IEEE 1044.1

Severity classificationAdapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Table 6.3 Defect severity classification using triage


74/93


Major Requirement(s) not satisfied

Medium Neither major nor trivial

Trivial A defect which will not affect

operation or maintenanceAdapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Types of Defects (1) (IEEE)


75/93

Types of Defects (1) (IEEE)

[PS] Logic problem

(forgotten cases or steps; duplicate logic;

extreme conditions neglected; unnecessary

functions; misinterpretation; missingcondition test; checking wrong variable;

iterating loop incorrectly etc.)

[PS] Computational problem(Equation insufficient or incorrect;

precision loss; sign convention fault)


Types of Defects (3)


76/93

yp ( )

[XDOC, PS] Data problem (sensor dataincorrect or missing; operator data incorrect or

missing; embedded data in tables incorrect or

missing; external data incorrect or missing;

output data incorrect or missing; input data

incorrect or missing)

[XDOC, PS] Documentation problem

(ambiguous statement etc.)




77/93

yp ( )

[XDOC, PS] Document quality problem

(Applicable standards not met etc.)

[XDOC, PS] Enhancement (change in

program requirements etc.)

[XDOC, PS] Failure caused by a previous fix




78/93

yp ( )

Performance problem

[XDOC, PS] Interoperability problem (not compatible

with other software or component)

[XDOC, PS] Standards conformance problem

[XDOC, PS] Other (none of the above)


IF aQuality is not recognizedPseudocode

f I i1


79/93


IFaQualityis not recognized

Log error to log file

Inform user qualities unchanged

ELSE

IFaQualityValue out of bounds

Log error to log file

Inform user qualities unchangedELSE

Set the stated quality to aQualityValue

Reduce the remaining qualities,

... retaining their mutual proportion,

... making the sum of qualities unchanged

ENDIF

ENDIF

for Inspection1

2

3

4

5

6

78

9

10

setQuality()

should be

mentioned

Lacks detail on how to allocate

the remaining quality values

Make these

preconditions;

dont check.


80/93

10. Summary

Summary of Detailed Design


81/93

Summary ofDetailed Design

Should be sufficient to code from

Try standard design patterns

Define selected algorithms

flowcharts

pseudocode

Apply select tools

e,g., Javadoc



82/93

Case Study

Detailed Design of RolePlayingGame Package


83/93

Detailed Design ofRolePlayingGame Package

RPGamehandleEvent()

GameStatehandleEvent()state

{ state.handleEvent(); }

. . . .

Detailed Design of RolePlayingGame Package


84/93

Detailed Design ofRolePlayingGame Package

RPGamehandleEvent()

GameStatehandleEvent()stateS

{ stateS.handleEvent(); }

RPGMouseEventListener

mouseEnter()

MouseListener{ rPGameS.handleEvent(); }

rPGameS


eventTargetUser :RPGame :GameState


85/93

eventTarget

2. mouseClicked()

User

1. mouse

action

3. handleEvent

( Event )

:RPGame :GameState

4. handleEvent( Event)

:RPGMouseEventListener

Sequence Diagram for

Handling Mouse EventsAdapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

RPG Video Game Architecture Packages --showing domain classes only

RolePlayingGame


86/93

framework package

framework package

framework package

framework package

application package

Characters

GameArtifacts

GameEnvironment


PlayerCharacter

EncounterCharacter

application package

ForeignCharacter

EncounterCharacters application package

EncounterGame Engagement

EngagementDisplay

EncounterGame

Area

PlayerQualityWindow

uses

uses

uses


ConnectionHyperlink


EncounterGameDisplays

MouseListener


87/93


Detailed Design of


Sub-package

EngagementDisplay

PreparinghandleEvent()

ReportinghandleEvent()

SetQualityDisplay

EncounterDisplayItem

QualListDispl

QualValueDispl

SetQualValueDispl

EncounterCast

EncounterDisplay


Sequence Diagram for

Dismissing Engagement


88/93

:EngagementDisplay

2. mouseClicked()

User

1. hit

dismiss

button


3. handleEvent()

:EncounterGame

:ReportingEncounter

4. handleEvent()

5. setVisible( false )

6. setState

(new Waiting())

Dismissing Engagement

Display


Sequence Diagram forPlayer Completes Setup


89/93

:PlayerQualityWindow

2. mouseClicked()

User

1. hit

dismiss

button


3. handleEvent()

:EncounterGame

:SettingUp

4. handleEvent()

5. setVisible( false )

6. setState

(new Waiting())


:AreaConnectionHyperlinkUser :Waiting:EncounterCast


90/93

2. mouseClicked()

1. hit

area

connectionhyperlink


4. handleEvent()5. setVisible( false )

9. setState

(new Engaging())

6. displayArea()

7. displayPlayerCharacter()

3. handleEvent()

:EncounterGame

:EncounterEnvironment

If foreign character present

8. displayForeignCharacter()


Sequence Diagram

forPlayer Moves to

Adjacent Area

Detailed Design ofEncounterCharacters Package


91/93

facade

EncounterCast

PlayerCharacter

ForeignCharacter

Charactersframework package

GameCharacter

EncounterCharacters

application package

EncounterCharacter


EncounterEnvironment Package


92/93

GameEnvironment

GameCharacterGameArea

GameAreaConnection

. . . .

EncounterEnvironment Package


93/93

GameEnvironment

GameCharacterGameArea

Area


GameAreaConnection


ConnectionHyperlink

Documents

Chapter 6 Designb