6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:

6. DESIGN II:DETAILED DESIGN

Plan project

Integrate & test system

Analyze requirements

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.

Chapter Learning Goals

• Understand how design patterns

describe some detailed designs

• Specify classes and functions completely

• Specify algorithms

– use flowcharts

– use pseudocode


1. Introduction to Detailed Design

Relating Use Cases, Architecture, & Detailed Design

1. Use case -- analysis

“Cars should be able to travel 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

Cable

Pylon

Relating Use Cases, Architecture, & Detailed Design

1. Use case (part of requirements)

“Cars should be able to travel 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. DetailedDesign

Smith Hill

Cable

Cable

Jones Hollow

Pylon

Pylon

(not specifically required)

(added for detailed design)

Guardrail


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

. . . . .

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 ...


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


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

• Don’t 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 reviewed3. Update the documentation set

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

– see figure TBD below5. Rework as a result of inspections6. Conduct post mortem and write out lessons learned


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: terminology used in this book “Requirements” “Achitecture” “Detailed

design”

Jacobson et al:

Analysis

1. Conceptual & abstract

2. Applicable to several designs

1. Concrete: implementation blueprint

2. Specific for an implementation

After Jacobson et al: USDP

Design 1/2

Analysis

1. Conceptual & abstract

2. Applicable to several designs

3. «control», «entity» & «boundary» stereotypes

4. Less formal

5. Less expensive to develop

1. Concrete: implementation blueprint

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

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 Jacobson et al: USDP

Design 2/2

6. Outlines the design

7. Emerges from conceptual thinking

8. Lower priority for in-process maintenance

9. Relatively unconstrained

10. 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 the analysis & architecture

10. More focus on sequence

11. Many layers

Analysis After Jacobson et al: USDP

Design 2/2

Designing Against Interfaces

Customerbill()

printAccounts()

RegularCustomerbill()

printAccounts()

BillingClientlistCustomers()billCustomers()

Abstract layer

Concrete (non-abstract) layer

Client code Used code

-- written in terms of Customer (not specific types of Customer)


2. Sequence and data flow diagrams for detailed design

Refine Models for Detailed Design

1/2: Sequence Diagrams1. 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, to describe 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)


1. Gather data flow diagrams (DFD’s) constructed for detailed requirements and/or architecture (if any).

2. Introduce additional DFD’s, if necessary, to explain data and processing flows.

3. Indicate what part(s) of the other models the DFD’s corresponds to. – e.g., “the following DFD is for each Account object”

4. Provide all details on the DFD’s– indicate clearly the nature of the processing at each node– indicate clearly the kind of data transmitted– expand processing nodes into DFD’s if the processing

description requires more detail

Refine Models for Detailed Design2/2: Data Flow Diagrams


2. execute()

2.1 setPlayerQuality()

2.3 setForeignQuality()

engagement:Engagement

1.3 new Engagement()

3.2 displayResult()

:Player’s main

character

:Encountergame

Sequence Diagram for Encounter 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()

Classes of the EncounterForeignCharacter Use Case

Engagementexecute()

EngagementDisplaydisplayResult()

EncounterGame

EncounterCastdisplayForeignChar()

setPlayerQuality()setForeignQuality()

ForeignCharactersetQuality()

PlayerCharactersetQuality()


Detailed Data Flow Diagram for a Banking Application

User

Customer.getDetails()

Cus-tomer

Account.getDeposit()

. . . . .

screentemplate

Detailed Data Flow Diagram for a Banking Application

User

Customer.getDetails()

Account.getPass-word()Account.

verifyPass-word()

Expand details……..

Pass-word

Cus-tomer

Account

unacceptableATM users

Cus-tomer

Deposit-screen.

display()

Account.getDeposit()

status

locallog


3. Specifying classes and functions

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 the

requirements 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


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 method’s pre-conditions (what it assumes).

4. State the method’s post-conditions (its effects).

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

algorithm to be used.

– unless very straightforward


Classes at Detailed Design

Responsibilities:-- describes each canister undergoing fabrication

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

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

Canister Class name

Attribute: type

+: visiblefrom without Operations

Place for comments


Specifying Functions: withdraw() in Account

Invariant of withdraw():

availableFundsI = max( 0, balanceI )

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

xI denotes an attribute; xP denotes a function parameter;x' is the value of x after execution;X denotes a class constant

. . . . .

Specifying Functions: withdraw() in Account

Invariant of withdraw():

availableFundsI = max( 0, balanceI )

Precondition*:

withdrawalAmountP >= 0 AND

balanceI - withdrawalAmountP

>= OVERDRAFT_MAX

Postcondition*:

balanceI' = balanceI - withdrawalAmountP*The function invariant is an additional pre- and post-condition

xI denotes an attribute; xP denotes a function parameter;x' is the value of x after execution;X denotes a class constant


4. Specifying algorithms

Flowchart Example

protected final void setName( String aName ) { // Check legitimacy of parameter and settings if( ( aName == null ) || ( maxNumCharsInName() <= 0 ) || ( maxNumCharsInName() > alltimeLimitOfNameLength() ) ) { _name = new String( "defaultName" ); System.out.println ( "defaultName selected by GameCharacter.setName()"); } else // Truncate if aName too long if( 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

Truncate name

Set _name to parameter

YN

Nominal path


An Architecture for Chaining

RuleaddRule()

proveAntecedents()forwardChain()

Factcontent

addFact()proveBack()

consequent

antecedents

static factList static ruleBase

Set Fact.factList to the known facts

and a Rule.ruleBase to the known rules.

Create Fact object soughtFact

Execute soughtFact.proveBack( ruleBase );

1

1..n


Flowchart for soughtFact.proveBack( ruleBase )soughtFact

in factList?N

Another rule Rwith

soughtFact as consequent?

Y

Apply R.proveAntecedents()

YNominal path

Succeeded?

Report TRUE

Y

Report FALSE

N

N


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 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

IF power level exceeds critical value

abort with "power level exceeded" message ENDIF

IF ( 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 this pseudocode


//p FOR number of microseconds supplied by operator

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

//p IF number of microseconds exceeds critical value

if( numMicrosecs >

XRayPolicies.CRITICAL_NUM_MICROSECS )

//p Try to get supervisor's approval

int supervisorMicrosecsApproval =

getApprovalOfSuperForLongExposure();

//p IF no supervisor approval

if( supervisorMicrosecsApproval <= 0 )

throw ( new SupervisorMicrosecsApprovalException() );

. . . . . . . . .

Pseudocode Extraction


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 can

be performed

Help to trap defects before they become code

Increases product reliability

May decreases overall costs


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


5. Design Patterns II: Techniques of detailed design

Apply Design Patterns in Detailed Design

1. Become familiar with the design problems solved by design patterns– at a minimum, understand the distinction among (C)

creational vs. (S) structural vs. (B) behavioral patternsConsider each part of the detailed design in turn: 2. Determine whether the problem has to do with (C)

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

3. Determine whether there is a design patterns that addresses 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(?)


Factory: Example

AnimalCell getNewCellObject()

PlantCell getNewCellObject()

Factory design pattern

BiologicalCell getNewCellObject()Client


MyOfficeApplicationmyMethod()

Prototype: Example

PurchaseOrderDocument clone()

InvoiceDocument clone()

Documentclone()

_documentPrototype

Client

. . . . .


MyOfficeApplicationmyMethod()

Prototype: Example

PurchaseOrderDocument clone()

InvoiceDocument clone()

Documentclone()

documentPrototypeS

Client

Customerclone()

CashCustomer clone()

CreditCustomer clone()

customerPrototypeS


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

Document or Customer it is being executed with

. . . .

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 Customer object:

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

Prototype Design Pattern: Typical Code 1/2

This class is unaware of which type (subclass) of Document or Customer it is being executed with


abstract class Document

{ protected Document clone();}

Prototype Design Pattern: Typical

Code 2/2

. . . .

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();}

Customer has an equivalent hierarchy of classes implementing clone()


Abstract Factory

Applied to Encounter

Area

Level3Area

Level3FactorygetArea()getAreaConnection()

EnvironmentFactorygetArea()buildConnection()

EncounterEnvironment

Client1..n

. . . . .

Abstract Factory Applied to Encounter

Area

Level2Area


EncounterAreaConnection

EnvironmentFactorygetArea()getConnection()

EncounterEnvironmentgetArea()getConnection()incrementLevel()

Level2AreaConnection

Client

«create» «create»

1..n

1..n

Area getArea() { return envFactory.getArea();}

envFactory


Abstract Factory

Applied to Encounter

Area

Level2AreaLevel1Area Level3Area





EnvironmentFactorygetArea()getConnection()


Level1AreaConnection Level2AreaConnection

Client

Level3AreaConnection

«create»

1..n


NonLeafNode

The Basis for Composite & Decorator Structures

Component

“every object involvedis a Component object”

“non-leaf nodes have one or

more components”

leaf nodenon-leaf node


NonLeafNodedoIt()

Composite & Decorator Structures

etc.

component

ComponentdoIt()

LeafdoIt()

TypeANonLeafNodedoIt()

TypeBNonLeafNodedoIt()

Composite: 1..nClient

Decorator: 1

for all elements e in componente.doIt()


Architecture of Encounter: Class Model

EncounterCharacters

EncounterGame

EncounterCast

EncounterGame




Adapter Design Pattern

Financialamount() Principal

computeValue()

Client

Legacy systemAdaptationApplication

FinancialAdapteramount()

Adapter Design Pattern

{ legacyAdaptee.computeValue(); }

Financialamount() Principal

computeValue()

Client

Legacy systemAdaptation

legacyAdaptee

Application


Proxy Design Pattern After Gamma et al BaseActiveClass

expensiveMethod()cheapMethod()

RealActiveClassexpensiveMethod()

cheapMethod()

ProxyexpensiveMethod()

cheapMethod()

Client

_realActiveObject

. . .if ( _realActiveObject == null ){ // never referenced_realActiveObject = getRealActiveObject(); _realActiveObject.expensiveMethod(); }

After Gamma et al


The Iterator Design Pattern

iterator:Iterator

element:Element

Aggregate of Elementobjects

Key: Intended sequence of Element objects

After first() executes, iterator references this object.

After next() executes, iterator references this object.

Before next() executes, iterator references this object.


The Mediator Design Pattern

Encapsulates behavior among objects of a class so that they needn’t refer to each other.

Mediator Colleague

ConcreteMediator

ConcreteColleague1 ConcreteColleague2

Gamma et al

The Mediator Design Pattern

EngagementDisplayItem

Mediator Colleague

ConcreteMediator ConcreteColleague1 ConcreteColleague2

SetQualitiesDisplay

… Applied to Encounter

QualListDisp QualValueDisp

EncounterDisplay


7. Standards, notation and tools for detailed design

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

1. Introduction 1.1. Purpose 1.2. Scope 1.3. Definitions, acronyms & abbreviations2. References3. Decomposition description 3.1. Module decomposition 3.1.1 Module 1 description 3.1.1 Module 2 description 3.2 Concurrent process 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 entry 2 description

4. Dependency description 4.1 Intermodule dependencies 4.2 Interprocess dependencies 4.3 Data dependencies5. Interface description 5.1 Module interface 5.1.1 Module 1 description 5.1.2 Module 2 description 5.2 Process interface 5.2.1 Process 1 description 5.2.2 Process 2 description6. Detailed design 6.1 Module detailed design 6.1.1 Module 1 detail 6.2.2 Module 2 detail 6.2 Data detailed design 6.2.1 Data entity 1 detail 6.2.2 Data entity 2 detail

Architecture

/**No character name will ever exceed this length */public final int alltimeLimitOfNameLength() ……..

/** For logging*/protected void display() ……../** Accessor of _name. "defaultName" assigned if this is first-time access. */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;


/**Subclasses must declare limit on size of character names*/protected abstract int maxNumCharsInName();

/**Sets _name to aName if length is within aMaxNumChars in length; otherwise truncates.Inheritors should use this for setName( String ), but not override@param aName: proposed name for _name@param aMaxNumChars -- at which to truncate aName*/protected final void setName( String aName ) ……..

……..

Java Source with Javadoc 2/2


8. Effects on projects of completing detailed designs

1. Make sure the SDD reflects latest version of detailed design, 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 was

created, & 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 Completing Detailed Design


Estimate Size & Time from Detailed Designs

1. Start with the list of methods– ensure completeness, otherwise underestimate will result

2. 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 Humphry’s table below

3. Sum the LOC4. Covert LOC to person-hours

– use personal conversion factor if possible• otherwise use published factor

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


CATEGORY

Very small

Small Medium LargeVery 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)

Normal Distribution of “Medium”, “Small” etc.

-2

Standard deviations from the mean

VS

7%

Approximate percentage of methods classified with this description

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


9. Quality in detailed designs

Inspect‡ Detailed Designs 1 of 2

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 --– simplicity

a design that few can understand (after a legitimate effort!) is expensive to maintain, and can result in defects

– generalityenables design of similar applications?

– expandabilityenables 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 this

is the best time to do it: don’t postpose

Inspect Detailed Designs 2 of 2


Severity Description

UrgentFailure 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 classification


Severity Description

Major Requirement(s) not satisfied

Medium Neither major nor trivial

Trivial A defect which will not affect operation or maintenance

Table 6.3 Defect severity classification using triage


Types of Defects (1) (IEEE)

• [PS] Logic problem (forgotten cases or steps; duplicate logic; extreme conditions neglected; unnecessary functions; misinterpretation; missing condition test; checking wrong variable; iterating loop incorrectly etc.)

• [PS] Computational problem (Equation insufficient or incorrect; precision loss; sign convention fault)


Types of Defects (3)

• [XDOC, PS] Data problem (sensor data incorrect 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.)



• [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



• 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 recognizedLog error to log file Inform user qualities unchanged

ELSE IF aQualityValue out of bounds

Log error to log fileInform user qualities unchanged

ELSESet the stated quality to aQualityValueReduce the remaining qualities, ... retaining their mutual proportion, ... making the sum of qualities unchanged

ENDIFENDIF

Pseudocodefor Inspection1

2345678910

setQuality() should be mentioned

Lacks detail on how to allocate the remaining quality values

Make these preconditions; don’t check.

10. Summary

Summary of Detailed Design

• Should be sufficient to code from

• Try standard design patterns

• Define selected algorithms

– flowcharts

– pseudocode

• Apply select tools

– e,g., Javadoc


Case Study

Detailed Design of RolePlayingGame Package

RPGamehandleEvent()

GameStatehandleEvent()state

{ state.handleEvent(); }

. . . .

Detailed Design of RolePlayingGame Package

RPGamehandleEvent()

GameStatehandleEvent()stateS

{ stateS.handleEvent(); }

RPGMouseEventListenermouseEnter()

MouseListener

{ rPGameS.handleEvent(); }

rPGameS


eventTarget

2. mouseClicked()

User

1. mouseaction

3. handleEvent( Event )

:RPGame :GameState

4. handleEvent( Event)

:RPGMouseEventListener

Sequence Diagram forHandling Mouse Events


RPG Video Game Architecture Packages -- showing domain classes only

«framework package»




«application package»

Characters

GameArtifacts

RolePlayingGame

GameEnvironment


PlayerCharacter

EncounterCharacter

«application package»

ForeignCharacter

EncounterCharacters «application package»

EncounterGame Engagement

EngagementDisplay

EncounterGame

Area

PlayerQualityWindow

«uses»

«uses»

«uses»


ConnectionHyperlink


EncounterGameDisplays

Detailed Design of EncounterGameDisplays

Sub-package

EngagementDisplay

PreparinghandleEvent()

ReportinghandleEvent()

SetQualityDisplay

EncounterDisplayItem

QualListDispl

QualValueDispl

SetQualValueDispl

EncounterCast

EncounterDisplay

MouseListener


:EngagementDisplay

2. mouseClicked()

User

1. hit dismissbutton


3. handleEvent()

:EncounterGame

:ReportingEncounter

4. handleEvent()

5. setVisible( false )

6. setState(new Waiting())

Sequence Diagram forDismissing Engagement

Display


:PlayerQualityWindow

2. mouseClicked()

User

1. hit dismissbutton


3. handleEvent()

:EncounterGame

:SettingUp

4. handleEvent()

5. setVisible( false )

6. setState(new Waiting())

Sequence Diagram for Player Completes Setup


:AreaConnectionHyperlink

2. mouseClicked()

User

1. hit areaconnectionhyperlink


:Waiting

4. handleEvent()5. setVisible( false )

9. setState(new Engaging())

6. displayArea()

7. displayPlayerCharacter()

3. handleEvent()

:EncounterGame

:EncounterEnvironment

:EncounterCast

If foreign character present

8. displayForeignCharacter()


Sequence Diagram for Player Moves to

Adjacent Area

Detailed Design of EncounterCharacters Package

«facade»

EncounterCast

PlayerCharacter

ForeignCharacter

Characters«framework package»

GameCharacter

EncounterCharacters«application package»

EncounterCharacter


EncounterEnvironment Package

GameEnvironment

GameCharacterGameArea

GameAreaConnection

. . . .

EncounterEnvironment Package

GameEnvironment

GameCharacterGameArea


Area


GameAreaConnection


ConnectionHyperlink


Documents

6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap: