1. DESIGN 2: DETAILED DESIGN

2. Software Engineering Roadmap: Chapter 6 Focus
Develop Architecture
- see chapter 5
Identify
corporate
practices
Perform Detailed Design
- apply design patterns
- accommodate use cases
supply methods
- exploit libraries (Java, Swing…)
- describe methods where required
- develop detailed object models
- dev. detailed logic (pseudo-code)
Plan
project
Analyze
requirements
Maintain
Integrate
& test system
Design
Implement
Test units
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

3. Chapter Learning Goals
Understand how design patterns describe some detailed designs
Specify classes and functions completely
Specify algorithms
use flowcharts
use pseudocode
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

4. 1. Introduction to Detailed Design
Objective: To fully prepare for implementation of a system that meets requirements.
Outcomes: (1) blueprints (models),
(2) associated details (documentation),
(3) detailed implementation plan for construction, integration and testing

5. 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.”
2. Domain
classes
3. Architecure
Cable
Auto
Road
Pylon

6. 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
3. Architecure
Cable
(not specifically required)
Auto
Road
Pylon
4. Detailed
Design
(added for detailed design)
Support use case
Auto
Guardrail
Cable
Road
Smith
Hill
Pylon
Jones Hollow
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

7. What is the difference between high-level (architectural) design and detailed design?
High-Level Design
Detailed Design

8. 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*
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
4. Specify class invariants* -- section 3.1
For each class ...
For each method ...
5. Specify methods with pre- and post-conditions, flowcharts* & pseudocode* -- sections 3 and 4
For each unit ...
6. Sketch unit test plans -- see chapter 8
7. Inspect test plans & design -- section 9
* if applicable
8.Release for implementation
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

9. Organize the Team for Detailed Design 1/2
One way to ...
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
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

10. Organize the Team for Detailed Design 2/2
One way to ...
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/ every member
Decide how and when the results are to be reviewed
3. Update the documentation set
more detailed schedule with modules & inspections
4. Inspect the detailed designs (see section 9)
5. Rework as a result of inspections
6. Conduct post mortem and write out lessons learned
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

11. Unified Software Development Process: Design
U. P. Term
Requirements
Analysis
Design
Implemen-
tation
Test
(Jacobson et al)
Inception
Elaboration
Construction
Transition 1*
Jacobson et al: 2 3
Prelim.
iterations
Iter. #1
Iter. #n
Iter.
#n+1
Iter. #m
Iter.
#m+1
Iter. #k
…..
…..
*Key: terminology used in this book
“Detailed
design”
1 =
“Requirements”
2 =
“Achitecture”
3 =

12. Analysis Design 1. Conceptual & abstract
1/2
After Jacobson
et al: USDP
1. Conceptual & abstract
2. Applicable to several designs
3. «control», «entity» & «boundary» class 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 times)

13. Analysis Design 6. Manifests the design (architecture one view)
2/2
After Jacobson
et al: USDP
6. Outlines the design
7. Emerges from conceptual thinking
8. Flexibility still exists for process modifications
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. Maintaining estabished process is a high priority
9. Constrained by the analysis & architecture
10. More focus on seq. diag.
11. Many layers

14. Designing Against Interfaces
Client code
Used code
Abstract layer
BillingClient
listCustomers()
billCustomers()
Customer
bill()
printAccounts()
-- written in terms of Customer (not specific types of Customer)
Concrete (non-abstract) layer
RegularCustomer
bill()
printAccounts()
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

15. Reusing Components
Functionality we need is becoming more convenient to locate and reuse
Microsoft MFC library
Visual Basic controls
COM objects
OMG’s CORBA
Javascript and Java Applet libraries
JavaBeans (servlet code)
Enterprise JavaBeans

16. 2. Sequence and data flow diagrams for detailed design

17. Refine Models for Detailed Design 1/2: Sequence Diagrams
One way to ...
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)
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

18. Refine Models for Detailed Design 2/2: Data Flow Diagrams
One way to ...
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
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

19. Requirements: Sequence Diagram for Engage Foreign Character Use Case
:Encounter
Game
freddie:
Foreign
Character
:Engagement
:Engagement
Display
:Player
Character
1.1 create; display
1.2 create
2.1 execute
2.2 change quality values
3.1 Display result
3.2 create
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

20. Design: Sequence Diagram for Encounter Foreign Character Use Case
game
:Encounter
Cast
freddie:
Foreign
Character
engagement:
Engagement
1.1 displayForeignChar()
:Engagement
Display
1.2 display()
1.3 new Engagement()
2. execute()
:Player’s
main
character
2.1 setPlayerQuality()
2.2 setQuality()
2.3 setForeignQuality()
3.1 new EngagementDisplay()
2.4 setQuality()
3.2 displayResult()
Design: Sequence Diagram for Encounter Foreign Character Use Case
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

21. Classes of the EncounterForeignCharacter Use Case
Engagement
execute()
EngagementDisplay
displayResult()
EncounterGame
PlayerCharacter
setQuality()
EncounterCast
displayForeignChar()
setPlayerQuality()
setForeignQuality()
ForeignCharacter
setQuality()
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

22. Detailed Data Flow Diagram for a Banking Application
Customer.
getDetails()
Account.
getDeposit()
customer info
User
screen
template
Account.
getPass-
word()
verifyPass-
pass-
word
Account
unacceptable
ATM users
Cus-
tomer
Deposit-
screen.
display()
status
local
log
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

23. A helpful demonstration:
CRC Cards
Class Responsibility and Collaboration cards provide an effective technique for exploring the possible ways of allocating responsibilities to classes and the collaborations that are necessary to fullfil the responsibilities.
A helpful demonstration:

24. Design Refinement with CRC Cards
Exercise:
Use Case: You are registering for a new course in astronomy. You require permission from the instructor and you must interact with the registrars office to signup and pay for the course.
Develop the classes and responsibilities using CRC cards

25. 3. Specifying classes and functions

26. Specify A Class 1. Gather the attributes listed in the SRS.
One way to ...
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.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

27. Specify a Function
One way to ...
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
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

28. Classes at Detailed Design
Data type
Range
Default value
Security issues
Canister
Class name
+ numCanisters: int
- numWafers: int
- size: float
Attribute: type
+: visible
from without
+ display()
- getNumSlotsOpen()
+ setStatus()
Operations
Interface specs
Functional
details
Invariants
Responsibilities:
-- describes each
canister undergoing
fabrication
Place for
comments
Instance details
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

29. 4. Specifying algorithms

30. Flowchart Example for setName()
Parameter & settings make
sense? N Y
Nominal path
Set _name to
“defaultName"
Parameter name too long? N Y
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 );
Set _name
to parameter
Truncate
name
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

31. 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
abort with "no supervisor approval for unusual
duration" message ENDIF ENDIF
See later section tbd for inspection results of this pseudocode

32. Pseudocode Extraction
//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
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

33. 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 decrease overall costs
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

34. 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
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

35. 5. Design Patterns II: Techniques of detailed design

36. Apply Design Patterns in Detailed Design
One way to ...
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(?)
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

37. User Interface Design
System users often judge a system by its interface rather than its functionality
A poorly designed interface can cause a user to make catastrophic errors
Poor user interface design is the reason why so many software systems are never used

38. User-Centred design
User-centred design is an approach to UI design where the needs of the user are paramount and where the user is involved in the design process
UI design always involves the development of prototype interfaces
See UI_design.ppt

39. 7. Standards, notation and tools for detailed design

40. 6.1 Module detailed design Architecture
IEEE Software Design Document Table of Contents (Reaffirmed 1993)
1. Introduction
1.1. Purpose
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
Architecture
Can be replaced with:
6.1 Class#1 detailed design
6.1.1 Attributes
6.1.2 Methods
6.1.3 Instance details
Other:
- UI details (if applicable)

41. 8. Effects on projects of completing detailed designs

42. Bring the Project Up-to-Date After Completing Detailed Design
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 Project Up-to-Date After Completing Detailed Design
One way to ...
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

43. Estimate Size & Time from Detailed Designs
One way to ...
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 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.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

44. 9. Quality in detailed designs

45. Inspect‡ Detailed Designs 1 of 2
One way to ...
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.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
‡ See chapter 1 for inspection procedures.

46. Inspect Detailed Designs 2 of 2
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
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
One way to ...
Inspect Detailed Designs 2 of 2
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

47. Inspection for Defects
Identify defect and its type
Specify its severity (two methods following slides)
Identify the source of the defect – so that the defect does not occur in another project …
At another time, usually one person works on a resolution to defect

48. Table 6.2 IEEE 1044.1 Severity classification
Description
Urgent
Failure causes system crash, unrecoverable data loss; or jeopardizes personnel
High
Causes impairment of critical system functions, and no workaround solution does exist
Medium
Causes 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 Severity classification
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

49. Requirement(s) not satisfied
Table 6.3 Defect severity classification using Triage
Severity
Description
Major
Requirement(s) not satisfied
Medium
Neither major nor trivial
Trivial
A defect which will not affect operation or maintenance
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

50. 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)
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

51. 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.)
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

52. Types of Defects (4)
[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
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

53. Types of Defects (5)
[PS] Suspect performance problem (inefficient logic, data structure)
[XDOC, PS] Interoperability problem (not compatible with other software or component)
[XDOC, PS] Standards conformance problem
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

54. Pseudocode for Inspection1 2 3 4 5 6 7 8 9 10
IF aQuality is not recognized
Log error to log file
Inform user qualities unchanged
ELSE
IF aQualityValue out of bounds
Set the stated quality to aQualityValue
Reduce the remaining qualities,
... retaining their mutual proportion,
... making the sum of qualities unchanged
ENDIF
setQuality() should be mentioned
Make these preconditions; don’t check.
Lacks detail on how to allocate the remaining quality values
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

55. Case Study

56. Detailed Design of RolePlayingGame Package
GameState
handleEvent()
RPGame
handleEvent()
state
{ state.handleEvent(); }

57. Detailed Design of RolePlayingGame Package
MouseListener
{ rPGameS.handleEvent(); }
rPGameS
RPGMouseEventListener
mouseEnter()
GameState
handleEvent()
RPGame
handleEvent()
stateS
{ stateS.handleEvent(); }
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

58. Sequence Diagram for Handling Mouse Events
User
eventTarget
:RPGame
:GameState
:RPGMouseEventListener
1. mouse
action
2. mouseClicked()
3. handleEvent
( Event )
4. handleEvent
( Event)
Sequence Diagram for Handling Mouse Events
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

59. RPG Video Game Architecture Packages -- showing domain classes only
RolePlayingGame
Characters
«framework package»
«framework package»
EncounterGame
«uses»
«application package»
EncounterCharacters
«uses»
EncounterGame
Engagement
«application package»
EngagementDisplay
EncounterCharacter
GameEnvironment
PlayerCharacter
«framework package»
ForeignCharacter
EncounterEnvironment
«uses»
PlayerQualityWindow
«application package»
Area
EncounterAreaConnection
GameArtifacts
ConnectionHyperlink
«framework package»
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

60. Detailed Design of EncounterGameDisplays Sub-package
MouseListener
EncounterGameDisplays
EncounterDisplayItem
EncounterCast
EncounterDisplay
Detailed Design of EncounterGameDisplays Sub-package
QualListDispl
SetQualValueDispl
QualValueDispl
Reporting
handleEvent()
EngagementDisplay
Preparing
handleEvent()
SetQualityDisplay
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

61. Sequence Diagram for Dismissing Engagement Display
User
:EngagementDisplay
:RPGMouse
EventListener
1. hit
dismiss
button
:ReportingEncounter
2. mouseClicked()
:EncounterGame
3. handleEvent()
4. handleEvent()
5. setVisible( false ) 
6. setState
(new Waiting()) 
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

62. Sequence Diagram for Player Completes Setup
User
:PlayerQualityWindow
:SettingUp
:RPGMouse
EventListener
1. hit
dismiss
button
2. mouseClicked()
:EncounterGame
3. handleEvent()
4. handleEvent()
5. setVisible( false ) 
6. setState
(new Waiting()) 
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

63. Sequence Diagram for Player Moves to Adjacent Area
User
:AreaConnectionHyperlink
:EncounterCast
:Waiting
1. hit
area
connection
hyperlink
:RPGMouse
EventListener
:EncounterEnvironment
:EncounterGame
2. mouseClicked()
3. handleEvent()
4. handleEvent()
5. setVisible( false ) 
6. displayArea()
7. displayPlayerCharacter()
If foreign character present
Sequence Diagram for Player Moves to Adjacent Area
8. displayForeignCharacter()
9. setState
(new Engaging())
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

64. Detailed Design of EncounterCharacters Package
«framework package»
GameCharacter
EncounterCharacters
«application package»
EncounterCharacter
PlayerCharacter
«facade»
EncounterCast
ForeignCharacter
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

65. EncounterEnvironment Package
GameEnvironment
GameArea
GameCharacter
GameAreaConnection

66. EncounterEnvironment Package
GameEnvironment
GameArea
GameCharacter
GameAreaConnection
Area
EncounterAreaConnection
EncounterEnvironment
ConnectionHyperlink
EncounterEnvironment
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.