Chapter 6 Designb

6.
DESIGN II: DETAILED DESIGN
Develop Architecture - see chapter 5
Software Engineering Roadmap: Chapter 6 Focus
Identify corporate practices Plan project

Analyze requirements
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
Maintain Integrate & test system Implement Test units
Design
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 2. Domain classes Auto Road Pylon 3. Architecure Cable
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.
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. 2. Domain classes Auto Road
(added for detailed design)
3. Architecure
(not specifically required)
Cable
Pylon Support use case Guardrail Cable
Auto
4. Detailed Design
Smith Hill
Road
Pylon
Jones Hollow
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) 2. Introduce design patterns & classes which connect the architecture classes with the domain classes -- see section tbd 3. Refine models & make them consistent -- see section tbd .....
1. Begin with architectural models -- see chapter 5 class model: domain & architectural classes overall state model* overall data flow model* use case model
Typical Roadmap for Detailed Design
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
3. Refine models, make consistent, ensure complete
For each class ... 4. Specify class invariants* -- section 3.1 For each method ... 5. Specify methods with pre- and post-conditions,
flowcharts* & pseudocode* -- sections 3 and 4

For each unit ...
* if applicable
6. Sketch unit test plans -- see chapter 8

7. Inspect test plans & design -- section 9 8.Release for implementation
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
revise as a group if not
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 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
Write out the conclusions and copy/e-mail every member Decide how and when the results are to be reviewed
Request time estimates to design lead by a fixed date
3. Update the documentation set
more detailed schedule with modules & inspections see figure TBD below
4. Inspect the detailed designs

5. Rework as a result of inspections 6. Conduct post mortem and write out lessons learned
Unified Software Development Process: Design

U. P. Term 1* 2 3 Requirements
Jacobson et al:
Inception Elaboration
Construction
Transition
Analysis Design Implementation Test

(Jacobson et al) Prelim. Iter. iterations #1 Iter. Iter. #n #n+1 .. Iter. #m Iter. .. #m+1 Iter. #k
*Key: terminology
used in this book
1 = Requirements
2 = Achitecture
3=
Detailed design
Analysis
1. Conceptual & abstract
Design
1. Concrete: implementation blueprint 2. Specific for an implementation
1/2
After Jacobson et al: USDP
2. Applicable to several designs
Analysis
1. Conceptual & abstract
Design
1/2
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)
Analysis
6. Outlines the design
Design
2/2
6. Manifests the design (architecture one view)
7. Emerges from conceptual thinking 8. Lower priority for inprocess maintenance
7. May use tools (e.g. visual, round-trip engineering) 8. Higher priority for inprocess maintenance
Analysis
6. Outlines the design
Design
2/2
6. Manifests the design (architecture one view)
7. Emerges from conceptual thinking

8. Lower priority for inprocess maintenance 9. Relatively unconstrained
7. May use tools (e.g. visual, round-trip engineering)

8. Higher priority for inprocess maintenance 9. Constrained by the analysis & architecture
10. Less focus on sequence diagrams

11. Few layers
10. More focus on sequence

11. Many layers
Designing Against Interfaces

Client code BillingClient
listCustomers() billCustomers() -- written in terms of Customer (not specific types of Customer)
Used code Customer

bill() printAccounts()
Abstract layer
RegularCustomer
bill() printAccounts()
Concrete (non-abstract) layer

2. Sequence and data flow diagrams for detailed design
Refine Models for Detailed 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, 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)
Refine Models for Detailed Design 2/2: Data Flow Diagrams

1. Gather data flow diagrams (DFDs) constructed for detailed requirements and/or architecture (if any). 2. Introduce additional DFDs, if necessary, to explain data and processing flows. 3. Indicate what part(s) of the other models the DFDs corresponds to.
e.g., the following DFD is for each Account object
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 processing description requires more detail
:Encounter :Encounter game Cast

1.1 displayForeignChar()
freddie: Foreign Character
engagement: Engagement :Engagement Display :Players main character
1.2 display() 1.3 new Engagement() 2. execute() 2.1 setPlayerQuality() 2.2 setQuality() 2.3 setForeignQuality() 2.4 setQuality()
3.1 new EngagementDisplay()
3.2 displayResult()
Sequence Diagram for Encounter Foreign Character Use Case

Classes of the EncounterForeignCharacter Use Case

Engagement execute() EngagementDisplay displayResult()
EncounterGame
EncounterCast displayForeignChar() setPlayerQuality() setForeignQuality()
PlayerCharacter setQuality() ForeignCharacter setQuality()
Detailed Data Flow Diagram for a Banking Application
Account. getDeposit()
Customer
User
Customer. getDetails()
.....
Detailed Data Flow Diagram for a Banking Application
Expand details .. User Customer. getDetails()
Account. getDeposit()
Customer
Account screen template Depositscreen. display() status Customer local log
unacceptable ATM users

Account. getPassword()
Account. verifyPassword()
Password
3. Specifying classes and functions
Specify A Class
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 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
Classes at Detailed Design

Canister + numCanisters: int - numWafers: int - size: float + display() - getNumSlotsOpen() + setStatus() Responsibilities: -- describes each canister undergoing fabrication
Class name Attribute: type
+: visible from without
Operations
Place for comments
Specifying Functions: withdraw() in Account
Invariant of withdraw():
availableFundsI = max( 0, balanceI ) .....
xI denotes an attribute; xP denotes a function parameter; x' is the value of x after execution; X denotes a class constant
*The function invariant is an additional pre- and post-condition
Specifying Functions: withdraw() in Account Invariant of withdraw(): availableFundsI = max( 0, balanceI )

xI denotes an attribute; xP denotes a function parameter; x' is the value of x after execution; X denotes a class constant
Precondition*:
withdrawalAmountP >= 0 AND
balanceI - withdrawalAmountP
>= OVERDRAFT_MAX Postcondition*:
balanceI' = balanceI - withdrawalAmountP

*The function invariant is an additional pre- and post-condition
4. Specifying algorithms
Flowchart Example
Parameter & settings make sense?
Y
Nominal path
Set _name to defaultName"
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()"); } Set _name Truncate else to parameter name // 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 ); } Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Parameter name too long?
An Architecture for Chaining

static factList static ruleBase
Fact
content addFact() proveBack()
consequent
Rule
addRule() proveAntecedents() forwardChain()
1..n antecedents
Set Fact.factList to the known facts and a Rule.ruleBase to the known rules.
Create Fact object soughtFact

Execute soughtFact.proveBack( ruleBase );
soughtFact in factList?
Flowchart for soughtFact.proveBack( ruleBase )
Nominal path
Another rule R with soughtFact as consequent?
Apply R.proveAntecedents()
Succeede d?
Report TRUE
Report FALSE
Pseuodocode Example
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
See section tbd for inspection results of this pseudocode
abort with "no supervisor approval for unusual duration" message ENDIF ENDIF
....
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
See section tbd for inspection results of this pseudocode
Pseuodocode Example
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
//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
Pseudocode Extraction
if( supervisorMicrosecsApproval <= 0 )

throw ( new SupervisorMicrosecsApprovalException() ); .........
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 patterns
Consider 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
Factory design pattern
Client
BiologicalCell getNewCellObject()
AnimalCell PlantCell getNewCellObject() getNewCellObject()

Prototype: Example
Client
_documentPrototype
MyOfficeApplication myMethod()
.....
Document clone()
PurchaseOrderDocument clone()
InvoiceDocument clone()
Prototype: Example
Client
MyOfficeApplication myMethod()
documentPrototypeS
Document clone()
Customer customerPrototypeS clone() CreditCustomer clone() InvoiceDocument clone()
CashCustomer clone()
PurchaseOrderDocument clone()
Prototype Design Pattern: Typical Code 1/2
public class MyOfficeApplication { private static Document documentPrototypeS; private static Customer customerPrototypeS; ....
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 )

This class is unaware of which type (subclass) of Document or Customer it is being executed with
documentPrototypeS = dProtopypeP;
customerPrototypeS = cPrototypeP; }
public myMethod { . . . . // Need a new Document object: Document d = documentPrototypeS.clone(); . . . . // Need a new Customer object: Customer c = customerPrototypeS.clone(); . . .
abstract class Document { } protected Document clone();
....
abstract class Document
{ protected Document clone(); } public class InvoiceDocument { .... protected Document clone() {. . . . return new InvoiceDocument(); }

Customer has an equivalent hierarchy of classes implementing clone()
public class PurchaseOrderDocument { .... protected Document clone() {. . . . return new PurchaseOrderDocument(); }
Client 1..n
EncounterEnvironment Area EnvironmentFactory getArea() buildConnection()
Abstract Factory Applied to Encounter

.....
Level3Area
Level3Factory getArea() getAreaConnection()
Client
Area getArea() { return envFactory.getArea(); } EncounterEnvironment getArea() getConnection() incrementLevel() 1..n EnvironmentFactory getArea() getConnection()
envFactory
EncounterAreaConnection
1..n
Area
Level2Area
create
Level2AreaConnection
create
Client 1..n
EncounterEnvironment Area EnvironmentFactory getArea() getConnection()
EncounterAreaConnection Level1Area Level2Area Level3Area
create
The Basis for Composite & Decorator Structures non-leaf node leaf node
Component
every object involved is a Component object non-leaf nodes have one or more components
NonLeafNode
Composite & Decorator Structures

Client Component doIt()
Composite: 1..n
Decorator: 1
for all elements e in component e.doIt()
Leaf doIt()
NonLeafNode doIt()
component
TypeANonLeafNode doIt()
TypeBNonLeafNode doIt()
etc.
Architecture of Encounter: Class Model
EncounterGame
EncounterGame
EncounterCharacters
EncounterCast
EncounterEnvironment
Adapter Design Pattern

Application Adaptation Legacy system
Financial
amount()
Principal
computeValue()
Client
Adapter Design Pattern

Application Adaptation Legacy system
Financial
amount()
Principal
computeValue()
Client
FinancialAdapter
amount()
legacyAdaptee
{ legacyAdaptee.computeValue(); }
Proxy Design Pattern After Gamma et al

Client
After Gamma et al
BaseActiveClass expensiveMethod() cheapMethod()
RealActiveClass _realActiveObject Proxy expensiveMethod() expensiveMethod() cheapMethod() cheapMethod()
... if ( _realActiveObject == null ){ // never referenced _realActiveObject = getRealActiveObject(); _realActiveObject.expensiveMethod(); }

The Iterator Design Pattern

element: Element
After first() executes, iterator references this object.
Key: Intended sequence of Element objects
iterator: Iterator
Aggregate of Element objects Before next() executes, iterator references this object.
After next() executes, iterator references this object.
The Mediator Design Pattern

Encapsulates behavior among objects of a class so that they neednt refer to each other.
Mediator
Colleague
ConcreteColleague1 ConcreteColleague2
ConcreteMediator
Gamma et al
The Mediator Design Pattern

Mediator
ConcreteMediator
Elena
User Interface for Status
Colleague
ConcreteColleague1 ConcreteColleague2
Current life points: 56
EncounterDisplay
Strength Endurance Endurance Intelligence Patience Value
EngagementDisplayItem
Applied to Encounter
16.18
QualListDisp QualValueDisp
SetQualitiesDisplay
7. Standards, notation and tools for detailed design
IEEE 1016-1987 Software Design Document Table of Contents (Reaffirmed 1993)
1. Introduction 1.1. Purpose Architecture 1.2. Scope 1.3. Definitions, acronyms & abbreviations 2. References 3. 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 dependencies 5. 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 description
6. 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
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;
/** 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 2/2

/** 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 ) ..
..
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
Bring the Project Up-to-Date After Completing Detailed Design
number remaining open, found at detailed design, closed at detailed design where injected; include previous phases & detailed design stages
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 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 time will be compared and saved at project end.
CATEGORY
Table 6.1 Lines of code (Humphrey)
Very small
Small
Medium
Large
Very large
Calculation
2.34
5.13
11.25
24.66
54.04
Data
2.60
4.79
8.84
16.31
30.09
METHOD TYPE
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
Normal Distribution of Medium, Small etc.

Approximate percentage of methods classified with this description 7%
VS
-2
Standard deviations from the mean
Normal Distribution of Medium, Small etc.

Approximate percentage of methods classified with this description 7%
VS
-2 -1 0 1
24% 38% 24%

VL
2
7%
Standard deviations from the mean

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.
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
generality
enables design of similar applications?
expandability
enables enhancements?
efficiency
speed, storage
Inspect Detailed Designs 2 of 2
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: dont postpose
Severity
Description
Urgent
Failure causes system crash, unrecoverable data loss; or jeopardizes personnel

Causes impairment of critical system functions, and no workaround solution does exist Causes impairment of critical system functions, though a workaround solution does exist Causes inconvenience or annoyance
High
Medium
Low None
None of the above
Table 6.2 IEEE 1044.1 Severity classification
Table 6.3 Defect severity classification using triage
Severity
Major Medium
Description
Requirement(s) not satisfied Neither major nor trivial
Trivial
A defect which will not affect operation or maintenance
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)
1 IF aQuality is not recognized Log error to log file 2 Inform user qualities unchanged 3 4 ELSE setQuality() IF aQualityValue out of bounds should be 5 mentioned Log error to log file 6 Inform user qualities unchanged 7 ELSE 8 Set the stated quality to aQualityValue 9 Reduce the remaining qualities, 10 ... retaining their mutual proportion, Make these ... making the sum of qualities unchanged preconditions; dont check. ENDIF Lacks detail on how to allocate ENDIF the remaining quality values
Pseudocode for Inspection
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
RPGame
handleEvent()
state
GameState
handleEvent()
{ state.handleEvent(); }
....
Detailed Design of RolePlayingGame Package

MouseListener
{ rPGameS.handleEvent(); }
rPGameS
RPGMouseEventListener
mouseEnter()
RPGame
handleEvent()
stateS
GameState
handleEvent()
{ stateS.handleEvent(); }
User
eventTarget
:RPGame
:GameState
:RPGMouseEventListener
1. mouse action 2. mouseClicked()
3. handleEvent ( Event ) 4. handleEvent ( Event)
Sequence Diagram for Handling Mouse Events

RPG Video Game Architecture Packages -showing domain classes only
RolePlayingGame
framework package
Characters
framework package
EncounterGame
application package
uses
EncounterCharacters uses
application package EncounterCharacter PlayerCharacter ForeignCharacter PlayerQualityWindow
EncounterGame
Engagement
EngagementDisplay
GameEnvironment
framework package
application package Area
uses
GameArtifacts
framework package
EncounterAreaConnection ConnectionHyperlink
MouseListener
EncounterGameDisplays
EncounterDisplayItem EncounterDisplay
EncounterCast
Detailed Design of EncounterGameDisplays Sub-package
QualListDispl
SetQualValueDispl
QualValueDispl Reporting
handleEvent()
EngagementDisplay
SetQualityDisplay
Preparing
handleEvent()
User
:EngagementDisplay
Sequence Diagram for Dismissing Engagement Display

:ReportingEncounter :EncounterGame
3. handleEvent() 4. handleEvent()
1. hit dismiss button
:RPGMouse EventListener
2. mouseClicked()
5. setVisible( false )
6. setState (new Waiting())
Sequence Diagram for Player Completes Setup

User :PlayerQualityWindow :SettingUp
1. hit dismiss button
2. mouseClicked()
:EncounterGame
3. handleEvent()
4. handleEvent()
5. setVisible( false ) 6. setState (new Waiting())
User :AreaConnectionHyperlink
1. hit area connection hyperlink
:EncounterCast
:Waiting
2. mouseClicked()
:EncounterEnvironment :EncounterGame
3. handleEvent() 4. handleEvent() 6. displayArea() 7. displayPlayerCharacter()
5. setVisible( false )
If foreign character present
Sequence Diagram for Player Moves to Adjacent Area
8. displayForeignCharacter() 9. setState (new Engaging())
Detailed Design of EncounterCharacters Package

Characters
framework package
GameCharacter
EncounterCharacters
application package
EncounterCharacter
facade
PlayerCharacter
EncounterCast ForeignCharacter
EncounterEnvironment Package
GameEnvironment GameArea GameAreaConnection
GameCharacter
....
EncounterEnvironment Package
GameEnvironment GameArea GameAreaConnection GameCharacter
Area EncounterEnvironment
EncounterAreaConnection ConnectionHyperlink EncounterEnvironment

Chapter 6 Designb

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 6 Designb

Uploaded by

Copyright:

Available Formats

6.

DESIGN II: DETAILED DESIGN

Develop Architecture - see chapter 5

Software Engineering Roadmap: Chapter 6 Focus

Identify corporate practices Plan project

Perform Detailed Design - apply design patterns

Maintain Integrate & test system Implement Test units

Chapter Learning Goals

1. Introduction to Detailed Design

Relating Use Cases, Architecture, & Detailed Design

Relating Use Cases, Architecture, & Detailed Design

Pylon Support use case Guardrail Cable

Typical Roadmap for Detailed Design

Typical Roadmap for Detailed Design

flowcharts* & pseudocode* -- sections 3 and 4

6. Sketch unit test plans -- see chapter 8

Ensure team members aware of the notation expected

Allocate modules to members

Request time estimates to design lead by a fixed date

3. Update the documentation set

4. Inspect the detailed designs

Unified Software Development Process: Design

Analysis Design Implementation Test

2. Applicable to several designs

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

6. Manifests the design (architecture one view)

7. Emerges from conceptual thinking 8. Lower priority for inprocess maintenance

After Jacobson et al: USDP

6. Manifests the design (architecture one view)

7. Emerges from conceptual thinking

7. May use tools (e.g. visual, round-trip engineering)

10. Less focus on sequence diagrams

10. More focus on sequence

Designing Against Interfaces

Used code Customer

Concrete (non-abstract) layer

2. Sequence and data flow diagrams for detailed design

Refine Models for Detailed Design 1/2: Sequence Diagrams

3. Provide sequence diagrams with complete details

Refine Models for Detailed Design 2/2: Data Flow Diagrams

4. Provide all details on the DFDs

:Encounter :Encounter game Cast

freddie: Foreign Character

engagement: Engagement :Engagement Display :Players main character

3.1 new EngagementDisplay()

Sequence Diagram for Encounter Foreign Character Use Case

Classes of the EncounterForeignCharacter Use Case

EncounterCast displayForeignChar() setPlayerQuality() setForeignQuality()

PlayerCharacter setQuality() ForeignCharacter setQuality()

Detailed Data Flow Diagram for a Banking Application

Detailed Data Flow Diagram for a Banking Application

Expand details .. User Customer. getDetails()

Account screen template Depositscreen. display() status Customer local log

unacceptable ATM users

3. Specifying classes and functions

4. Name additional methods required for the design.

5. Show the attributes & methods on the object model.

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

Classes at Detailed Design

Class name Attribute: type

+: visible from without