9. SYSTEM INTEGRATION

1
9. SYSTEM INTEGRATION
2
Software Engineering Roadmap Chapter 9 Focus
Construct system in stages - Plan
integration of parts to yield whole -
Test subassemblies - Assemble in builds -
Test whole system in a variety of ways
Identify corporate practices
Plan project
Maintain
Analyze requirements
Integrate test system
Design
Test units
Implement
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
3
Chapter Learning Goals

• Be able to plan the integration of modules
• Understand types of testing required
• Be able to plan and execute testing
• beyond the unit level

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
4
1. Introduction to system integration
5
Unified Process for Integration Test
Jacobson et al USDP
Elaboration
Inception
Construction
Transition
Requirements Analysis Design Implemen- ta
tion Test
Integration

Unit Tests
Integration tests ... System tests

Prelim. iterations
Iter. 1
Iter. n
Iter. n1
Iter. m
Iter. m1
Iter. k
..
..
6
Development Overview
Customer
loss of information
Requirements
loss
Architecture
7
Development Overview
Customer
loss of information
Requirements
loss
Architecture
loss
loss
Interface specs
Detailed design
loss
loss
Function code
Module (e.g., package) code
After Myers
System code
8
Testing Units in Context
Stand-alone unit test of function -- may require
driver stubs
Test of function in context -- eliminate or
reduce driver stubs
Function code
Function tests
code
Iteration or System code
Complete code
9
Testing Overview Artifact Flow (After Myers)
order of testing
Requirements
(11) Acceptance tests
Docs.
(10) Installation tests
Architecture
(9) Usability tests
Docs.
Docs.
(8) System tests
Detailed design
(7) Regression tests
Docs.
Interface specs
(6) Integration tests
Function code
Docs.
(5) Interface tests
Code
Code
Module (e.g., package) code
(2),(4) Module tests
Code
Code
(1),(3) Function tests
Iteration or System code
Complete code
10
Testing forValidation and Verification(After
Myers)
(11) Acceptance tests
Tested against requirements (validation)
Requirements
(10) Installation tests
(9) Usability tests
(8) System tests
(7) Regression tests
(1), (4) Function tests
Includes use-cases performance testing
11
Testing for Validation and Verification(After
Myers)
(11) Acceptance tests
Requirements
(10) Installation tests
validation1
(9) Usability tests
(8) System tests
Architecture
verification2
(7) Regression tests
(6) Integration tests
Interface specs
verification2
(5) Interface tests
(1), (4) Function tests
verification2
Detailed design
(2), (3) Module tests
Includes use-cases performance testing
Note 2 Tested against documents indicated
Note 1 Tested against requirements
12
2. The integration process
13
Build 1
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
14
Build 2
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
15
Build 3
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
16
Final Build of Single Level
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
17
Final Build of Double Level
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
18
The Build Process
Single level iteration
Double level iteration
. . . .
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
19
Integration in Spiral Development
Design
Requirements analysis
Second iteration
First iteration
2. Design for additional requirements
1. Get additional requirements
3. Code additional
5. Test
4. Integrate new code
Implementation
Test
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
20
Relating Builds and Iterations in the Unified
Process
Jacobson et al USDP
Elaboration
Inception
Construction
Transition
Requirements Analysis Design Implemen- ta
tion Test
First build for iteration i
Last build for iteration i
Prelim. iterations
Iter. 1
Iter. n
Iter. m1
Iter. k
Iter. n1
Iter. m
Iter. i
..
..
..
21
Typical Build 1
Module 1
2
3
4
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
22
Typical Build 2
Module 1
2
3
4
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
23
Unit-Oriented Build 1
Module 1
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
24
Unit-Oriented Build 2
Module 1
2
3
4
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
25
Unit-Oriented Build 3
Module 1
2
3
4
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
26
Last Build
Module 1
2
3
4
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
27
Build Sequences Ideal vs. Typical
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
28

• 1. Understand the architecture decomposition.
• try to make architecture simple to integrate
• 2. Identify the parts of the architecture that
  each iteration will implement.
• build framework classes first, or in parallel
• if possible, integrate continually
• build enough UI to anchor testing
• document requirements for each iteration
• try to build bottom-up
• so the parts are available when required
• try to plan iterations so as to retire risks
• biggest risks first
• specify iterations and builds so that each use
  case is handled completely by one
• 3. Decompose each iteration into builds if
  necessary.
• 4. Plan the testing, review and inspection
  process.
• see section tbd.
• 5. Refine the schedule to reflect the results.

One way to ...
Plan Integration Builds
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
29
Roadmap for Integration and System Test
1. Decide extent of all tests.
2. For each iteration
2.1 For each build
2.2 Perform iteration system and usability tests
-- see section tbd
3. Perform installation tests -- see section tbd
4. Perform acceptance tests -- see section tbd
30
Roadmap for Integration and System Test
1. Decide extent of all tests.
2. For each iteration
2.1 For each build
2.1.1 Perform regression testing from prior build
2.1.2 Retest functions if required
2. 1.3 Retest modules if required
2. 1.4 Test interfaces if required
2. 1.5 Perform build integration tests -- section
3.1
Development of iteration complete
2.2 Perform iteration system and usability tests
-- sections 3.4, 3.5
System implemented
3. Perform installation tests -- section 3.8
System installed
4. Perform acceptance tests -- section 3.7
Job complete
31
RPG Video Game Architecture Packages -- built
around the domain classes
Characters
framework package
EncounterCharacters
uses
application package
EncounterCharacter
PlayerCharacter
ForeignCharacter
PlayerQualityWindow
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
32
RPG Video Game Architecture Packages -- built
around the domain classes
Framework layer
GameArtifacts
GameEnvironment
framework package
framework package
RolePlayingGame
Characters
framework package
framework package
uses
Application layer
EncounterGame
uses
EncounterCharacters
application package
application package
EncounterGame
Engagement
EncounterCharacter
EngagementDisplay
uses
EncounterEnvironment
PlayerCharacter
application package
ForeignCharacter
Area
EncounterAreaConnection
PlayerQualityWindow
ConnectionHyperlink
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
33
Factors Determining the Sequence of Integration

• Usage of modules by other modules
• build and integrate modules used
  before modules that use them
• Defining and using framework classes
• Exercising integration early
• Exercising key risky parts of the application as
  early as possible
• Showing parts or prototypes to customers

technical (factors)
risk reduction
requirements
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
34
Integration Schedule
Milestones
Elaboration iterations
Iterations
Inception iteration
Iteration 2 elementary interaction
Iteration 1 view characters in areas
Builds
Modules
35
Integration Schedule
Month 1
Month 2
Month 3
Month 4
Month 5
1
2
3
4
1
2
3
4
1
2
3
4
1
2
3
4
1
2
3
4
1
Milestones
Complete prototype
Proto. requirements
Elaboration iterations
Iterations
Inception iteration
Iteration 2 elementary interaction
Iteration 1 view characters in areas
Builds
build 1
build 3
build 2
. . . . . . .
Modules
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
36
Integration Schedule
Month 1
Month 2
Month 3
Month 4
Month 5
1
2
3
4
1
2
3
4
1
2
3
4
1
2
3
4
1
2
3
4
1
Milestones
Complete prototype
Proto. requirements
Elaboration iterations
Iterations
Inception iteration
Iteration 2 elementary interaction
Iteration 1 view characters in areas
Builds
build 1
build 3
build 2
RolePlaying- Game package
Characters package
GameEn- vironment package
Modules
Encounter Characters package
Encounter- Environ- ment package
EncounterGame package
Integrate test
Integrate test
Integrate test
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
37
3. The testing process
38
Encounter Continual Integration week 3
RolePlayingGame
EncounterGame
Characters
GameCharacter
Layout
EncounterCharacters
EncounterLayout
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
39
Encounter Continual Integration week 7
RolePlayingGame
RPGame
EncounterGame
Characters
GameCharacter
Layout
EncounterCharacters
Map
EncounterLayout
EncounterEnvironment facade
EncounterCast facade
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
40
Encounter Continual Integration week 11
RolePlayingGame
RPGame
EncounterGame
Characters
GameCharacter
Layout
EncounterCharacters
Map
EncounterLayout
EncounterEnvironment facade
EncounterCast facade
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
41
RolePlayingGame
Encounter Continual Integration week 15
RPGame
EncounterGame
Characters
EncounterGame facade
GameCharacter
Layout
EncounterCharacters
Map
Location
EncounterCharacter
EncounterLayout
EncounterEnvironment facade
EncounterCast facade
Area
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
42
Plan and Execute Integration Tests
One way to ...

• 1. Decide how and where to store, reuse and code
  the integration tests.
• show this in the project schedule
• 2. Execute as many unit tests (again) as time
  allows
• this time in the context of the build
• no drivers or stubs required this time
• prioritize by those most likely to uncover
  defects
• 3. Exercise regression tests
• to ensure existing capability has not been
  compromised
• 4. Ensure build requirement are properly
  specified
• 5. Exercise use cases that the build should
  implement
• test against the SRS
• 6. Execute the system tests supported by this
  build

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
43
Relationship Between Use Cases, Iterations and
Builds
Iteration 5
build 5.3
Use case 14
44
Relationship between Use Cases, Iterations and
Builds
Iteration 5
4
6
5.4
5.2
build 5.3
Use case 7

Use case 14


Use case 23
Use case 9
extends or includes
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
45
Final Code Build and Integration Schedule a
Banking Example
week 23
week 31
biweekly
daily
weekly code builds
baseline
release
46
Final Code Build and Integration Schedule a
Banking Example
week 23
week 31
biweekly
daily
weekly code builds
baseline
Integration of module into baseline
bank query module
release
tasks
bank deposit module
bank withdrawal module
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
47
Typical Day-by-Day Code Integration Process
biweekly
daily
weekly builds
week 31
week 23
release
48
Typical Day-by-Day Code Integration Process
Run
regression tests
6 pm
7 am
development
development
time
Confirm baseline or revert to previous baseline
Freeze development
biweekly
daily
weekly builds
week 25
week 26
week 27
week 28
week 29
week 30
week 31
week 24
week 23
release
overnight regression test
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
49
Artifacts and Roles for Integration Testing
Component engineer
Integration tester
System tester
Test engineer
. . . . . . . . . . . . . . . . . . responsible
for . . . . . . . . . . . . . . . . . . . . . . .
. . . . .
50
Artifacts and Roles for Integration Testing
Component engineer
Integration tester
System tester
Test engineer
. . . . . . . . . . . . . . . . . . responsible
for . . . . . . . . . . . . . . . . . . . . . . .
. . . . .
Test evaluation
?
Use-case model

Test procedure
Test plan
Test component
Defect management
Test case
Jacobson et al USDP
51
Interface Testing for Encounter
EncounterCharacters
EncounterCast facade getTheEncounterCast() getTh
ePlayerCharacter() getTheForeignCharacter()
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
52
Interface Testing for Encounter
EncounterGame
InterfaceTest test class
EncounterGame facade getTheEncounterGame() getSt
ate() setState() handleEvent()
References all packages
EncounterCharacters
EncounterCast facade getTheEncounterCast() getTh
ePlayerCharacter() getTheForeignCharacter()
EncounterEnvironment
EncounterEnvironment facade setLocation()
Class relationships not fully shown.
Area
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
53
Interface Test Scenarioof Encounter
Kitchen
Courtyard
Dressing room
Living room
Dungeon
Study
Key
connection
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 20001), with permission.
Graphics reproduced with permission from Corel.
54
Types of System Tests 1

• Volume
• Subject product to large amounts of input.
• Usability
• Measure user reaction (e.g., score 1-10).
• Performance
• Measure speed under various circumstances.
• Configuration
• Configure to various hardware / software
• e.g., measure set-up time.
• Compatibility
• -- with other designated applications
• e.g., measure adaptation time.
• Reliability / Availability
• Measure up-time over extended period.

see Kit Ki
55

• Security
• Subject to compromise attempts.
• e.g., measure average time to break in.
• Resource usage
• Measure usage of RAM and disk space etc.
• Install-abililty
• Install under various circumstances.
• measure time to install.
• Recoverability
• Force activities that take the application down.
• measure time to recover
• Serviceabililty
• Service application under various situations.
• measure time to service
• Load / Stress
• Subject to extreme data event traffic

Types of System Tests 2
see Kit Ki
56
Key Attributes for Usability Testing

• Accessibility
• How easily can users enter, navigate exit?
• e.g., measure by average time taken to . . .
• Responsiveness
• How quickly does the application allow the user
  to accomplish specified goals?
• e.g., measure by average time taken
• Efficiency
• Degree to which the number of required steps for
  selected functionality is minimal
• minimal deduced in theory
• e.g., measure by minimal time / average time
• Comprehensibility
• How easy is the product to understand and use
  with documentation and help?
• e.g., measure time taken for standard queries

Adapted from Kit Ki.
57
4. Documenting integration and tests
58
ANSI/IEEE 829-1983 Software Test Documentation
(reaff. 1991)
1. Introduction 2. Test plan items under test,
scope, approach, resources,
schedule, personnel 3. Test design items to be
tested, the approach, the plan in detail 4.
Test cases sets of inputs and events 5. Test
procedures steps for setting up and executing
the test cases
59
ANSI/IEEE 829-1983 Software Test Documentation
(reaff. 1991)
1. Introduction 2. Test plan items under test,
scope, approach, resources,
schedule, personnel 3. Test design items to be
tested, the approach, the plan in detail 4.
Test cases sets of inputs and events 5. Test
procedures steps for setting up and executing
the test cases
6. Test item transmittal report items under test,
physical location of results, person responsible
for transmitting 7. Test log chronological
record, physical location of test, tester name
8. Test incident report documentation of any
event occurring during testing which requires
further investigation 9. Test summary
report summarizes the above
60
System Test Documentation in Context
SPMP Software Project Management Plan
SCMP Software Configuration Management Plan --
statement of procedures
Appendix -- references all versions of documents
SDD Software Design Document
Source Code
STD Software Test Documentation
SRS Software Requirements Specification
Key
Refers to
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
61
Organization of Integration and System Test
Documentation
Software Test Documentation
STD
SCMP
consists of ...
System T.D.
Acceptance T.D.
Installation T.D.
Integration T.D.
references ...
Test Documentation, each divided into

• Introduction
• Test plans
• Test designs
• Test cases
• Test procedures
• Test log

Build 1 T.D.
Build 2 T.D.
Build 3 T.D.
With R. Bostwick
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
62
5. The Transition iterations
63
Goals of the Transition Iterations

• Find defects through customer use
• Test user documentation and help

Transition
Requirements Analysis Design Implemen- ta
tion Test
Iter. m1
Iter. k

64
Goals of the Transition Iterations

• Find defects through customer use
• Test user documentation and help
• Determine realistically whether application
  meets customer requirements
• Retire deployment risks
• Satisfy miscellaneous marketing goals

Transition
Requirements Analysis Design Implemen- ta
tion Test
Iter. m1
Iter. k

65
Alpha- and Beta- Releases

• In-house and highly trusted users
• Multiplies testing
• Previews customer reaction
• Benefits third-party developers
• Forestalls competition

Alpha
66
Alpha- and Beta- Releases

• In-house and highly trusted users
• Multiplies testing
• Previews customer reaction
• Benefits third-party developers
• Forestalls competition

Alpha

• Selected customers
• Multiplies testing activity
• Gets customer reaction

Beta
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
67
Roadmap for the Transition Iterations

• Define population
• Plan defect collection
• Identify stopping criteria

1. Plan alpha and beta testing.
68
Roadmap for the Transition Iterations

• Define population
• Plan defect collection
• Identify stopping criteria

1. Plan alpha and beta testing.

• Prepare
• Distribute install
• Carry out (users / customers)
• Gather defect reports
• Observe stopping criteria
• Correct defects

2. Conduct alpha testing.
3. Conduct beta testing.
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
69
Stopping Criteria

• Completing a particular test methodology
• Complete the procedures of a method or tool.
• Estimated percent coverage for each category
• predetermine percent of each how to calculate
• e.g., 95 statement coverage
• Error detection rate
• predetermine rate with given severity level
• e.g., 2 medium severity defects or less per 100
  hours of operation
• Total number of errors found
• (if possible) computed from a percentage of
  remaining defects
• predetermine percent
• e.g., 95 of estimated existing defects found

Kit Ki
70
Stopping Criteria Graphical Representation
Percentage of deposit transaction types tested

Target 95
week 1
71
Stopping Criteria Graphical Representation
Number per 1000 hrs
Error detection rate
Target lt 7 per1000 hrs for 4 weeks

Percentage of deposit transaction types tested
Target 98
Target 91
Percentage of withdrawal transactions tested
week 1
End tests
week 10
week 20
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
72
6. Quality in integration, verification and
validation
73
CMM Levels (SEI)
1. Initial
undefined, ad hoc tracks cost, schedule,
functionality after fact documented,
standardized, tailorable detailed measurement
control continual quantified process improvement
2. Repeatable
3. Defined
4. Managed
5. Optimized
74
Postmortem Example Requirements Analysis Through
System Integration
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
75
7. Tools for integration and system testing
76
Capabilities of Automated System Test Tools

• 1. Record mouse and keyboard actions to enable
  repeated playback
• 2. Run test scripts repeatedly
• 3. Enable recording of test results
• 4. Record execution timing
• 5. Record runtime errors

77
Capabilities of Automated System Test Tools

• 1. Record mouse and keyboard actions to enable
  repeated playback
• 2. Run test scripts repeatedly
• 3. Enable recording of test results
• 4. Record execution timing
• 5. Record runtime errors
• 6. Create and manages regression tests
• 7. Generate test reports
• 8. Generate test data
• 9. Record memory usage
• 10. Manage test cases
• 11. Analyze coverage

78
Types of Capture/Playback Tests

• Native / software intrusive
• test software intermingled with software under
  test
• could compromise software under test
• least expensive
• Native / hardware intrusive
• test hardware intermingled with software under
  test
• could compromise software under test
• Non-intrusive
• uses separate test hardware
• does not compromise software under test
• most expensive

adapted from Kit Ki
79
Memory Usage Test Tools

• Memory leaks
• detect growing amounts of unusable memory
• inadvertently caused by the implementation
• Memory usage behavior
• confirm expectations
• identify bottlenecks
• Data bounds behavior
• e.g., confirm integrity of arrays
• e.g., detect attainment of limiting values
• Variable initialization
• indicate un-initialized variables
• Overwriting of active memory

80
Test Case Management

• Provide user interface
• to manage tests
• Organize tests
• for ease of use
• for maintenance
• Manage test execution sessions
• to run tests selected by user
• Integrate with other test tools
• to capture and play back
• to analyse coverage
• Provide reporting
• Provide documentation

adapted from Kit Ki
81
8. Summary
82
Summary ofSystem Integration and Verification

• Integration process executed in carefully planned
  builds
• Integration testing each build
• System testing whole application
• Regression testing verify that changes do not
  compromise pre-existing capabilities

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
83
Case study - SCMP Appendix APlan for
Integration Baselines
84
Integration Plan
Build 3
EncounterGame
Build 1
EncounterGame
EncounterCharacters
EncounterCast
Build 2
EncounterEnvironment
EncounterEnvironment
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
85
Build 1
GameCharacters
framework package
GameCharacter
Encounter Characters
EncounterCharacter
PlayerCharacter
EncounterCast façade singleton
ForeignCharacter
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
86
Build 2
GameEnvironment
GameAreaConnection
GameArea
GameCharacter
GameLayout
Area
EncounterEnvironment facade
EncounterCast facade
EncounterEnvironment
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
87
Status After Build 2
Characters
GameEnvironment
framework package
framework package
EncounterCharacters
EncounterLayout
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
88
Build 3 -- Includes Builds 1 and 2 (not shown)
RolePlayingGame
RPGMouseEventListener notifyOfEvent()
RPGame handleEvent()
GameState handleEvent()
EncounterGame ltltsingletongtgt
Waiting handleEvent()
Engaging handleEvent()
Engagement
Preparing handleEvent()
Reporting handleEvent()
EngagementDisplay
EncounterGame
Key
Domain class
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
89
Software Test Documentation for Encounter
90
Approaches and Documentation for Test Types
91
Approaches and Documentation for Test Types
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
92
Features to be Tested in Build 1
93
Test Document Identifiers
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
94
Integration Test Inputs, Outputs, and Actions
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
95
Build 1 Test Log
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
96
Architecture and Modularization of Encounter
Role-playing Game
EncounterGame
EncounterGame facade
EncounterCharacters
EncounterCast facade
EncounterEnvironment
EncounterEnvironment facade
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
97
Sequence Diagram for Initialize Use Case
Player quality window
main player character Player Character
dressing room Area
Encounter- Game
User
1a. create
1b. create
2. create
3a. enter quality value
3b. setQuality()
4. select exit for character
5. move()
Numbering keyed to use case
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
98
Sequence Diagram for Encounter Foreign Character
Use Case
engagement Engagement
Encounter game
freddie Foreign Character
Encounter Cast
1.1 displayForeignChar()
Players main character
1.2 display()
1.3 create
2. execute()
Engagement Display
2.1 setPlayerQuality()
2.2 setQuality()
2.3 setForeignQuality()
3.1 create
2.4 setQuality()
3.2 displayResult()
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.