5. DESIGN I: SOFTWARE ARCHITECTURE. Plan project Integrate & test system Analyze requirements Design...
Transcript of 5. DESIGN I: SOFTWARE ARCHITECTURE. Plan project Integrate & test system Analyze requirements Design...
5. DESIGN I:SOFTWARE
ARCHITECTURE
Plan project
Integrate & test system
Analyze requirements
Design
Maintain
Test unitsImplement
Software Engineering Roadmap: Chapter 5 Focus
Identify corporate practices
Develop Architecture
Develop Detailed Design (next chapter)
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Chapter Learning Goals
• Understand “Software Architecture” term
• Utilize frameworks, design patterns, and
models
• Develop architecture alternatives
• Relate architectures to detailed designs
• Apply the IEEE SDD standard
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
1. Introduction to system engineering and software architecture
Player m
GameCorp Billing server
Player n
A Physical Configuration for Internet-based Encounter
Key:
EncounterGUI
EncounterGUI
. . . .
Hardwareplatform
Softwaresubsystem
Internet
Encounter Server
Encounterengine
EncounterReporter
Accountdatabase
Accountprocessing
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Autocontrol
processor
Antilock Braking System Diagram
Key:
ABS controller
HardwareSoftwaresubsystem
Wheel speed sensor
Speed thresh-hold alert
Hydraulic pressuremodulator unit
Warning lamp
Pressure controller
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Some Design Goals
• Extension– facilitate adding features
• Change– facilitate changing requirements
• Simplicity – make easy to understand – make easy to implement
• Efficiency– attain high speed: execution and/or compilation – attain low size: runtime and/or code base
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Cohesion and Coupling
1
2 3 4
5 6High cohesion Low couplingBridge
component
component
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Cohesion and Coupling
1
2 3 4
5 6High cohesion Low coupling
High coupling
Bridge
component
component
component
Steeltruss
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
1. Develop a mental model of the application at a high level.– as if it were a small applicatione.g., personal finance application ... … “works by receiving money or paying out money,
in any order, controlled through a user interface”.
2. Decompose into the required components.– look for high cohesion & low couplinge.g., personal finance application ... … decomposes into Assets, Suppliers, & Interface.
3. Repeat this process for the components.
Begin Selecting a Basic Architecture
Note: To use established architectures, see the rest of this chapter
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
2. Models, frameworks, and design patterns
TargetApplication
Class model“with objects of these classes ...”
e.g., with Engagement … classes
Use-case model“Do this ...”
e.g., engage foreign character
To express requirements, architecture & detailed designModels
TargetApplication
Class model“with objects of these classes ...”
e.g., with Engagement … classes
State model“reacting to these events ...”
e.g., when foreign character enters
Use-case model“Do this ...”
e.g., engage foreign character
Component model“in this way ...”
e.g., scores flow from … to
To express requirements, architecture & detailed designModels
ModelsTarget
Application
Class model: “with ...”
State model: “when”
Use-case model: “do this”
Component model: “how”
class
methods
States
Transitions
Use case
Scenarios
Business use case
Component
Sub-component
Data flow
Local data flow
elaborated by ...Sequencediagram
package
consistsof ...
organizedby ...
Substatesdecomposedinto ...
Jacobson et al
package of classes
abstract classpackage MyPackage; abstract class AbstractClass . . . .
package MyPackage; class DerivedClass extends AbstractClass{ int att; . . . . . void myFunction( ReferencedClass r ) { . .. }} DerivedClass
att: intmyFunction()
UML Notation … and … Typical Implementation
AbstractClass
MyPackage
attribute
operation
inheritance
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
package MyPackage; class DerivedClass extends MyClass{ AggregatedClass ac; int att; . . . . . void myFunction( ReferencedClass r ) { . .. }}
DerivedClassatt: intmyFunction() AggregatedClassac
aggregation
1
UML Notation … and … Typical Implementation
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
package MyPackage; class DerivedClass extends MyClass{ AggregatedClass ac; int att; . . . . . void myFunction( ReferencedClass r ) { . .. }}
DerivedClassatt: intmyFunction() AggregatedClass
ReferencedClass
ac
MyClass
MyPackage
aggregation
dependency(reference to a class)
UML Notation … and … Typical Implementation
1
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
«application package»
RPG Video Game Layering
«framework package»
Characters
PlayerCharacter
EncounterCharacter
ForeignCharacter
EncounterCharacters
PlayerQualityWindow
«uses»
Framework layer
Application layer
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
«framework package»
«framework package»
«framework package»
«application package»
Characters RolePlayingGame
GameEnvironment
EncounterEnvironmentPlayerCharacter
EncounterCharacter
«application package»
ForeignCharacter
EncounterCharacters «application package»
EncounterGame Engagement
EngagementDisplay
EncounterGame
Area
PlayerQualityWindow
EncounterAreaConnection
Framework layer
Application layer
Role-Playing Game, and Encounter Packages -- showing domain classes
ConnectionHyperlink
«uses»
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
1. Create domain classes
-- from requirementsanalysis
3. Create design classes
-- specific to this application-- to complete the class model
One Way to Obtain The Class Model
2. Create and/or use framework classes
-- for architectureMore
general
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Domain classes
Design classes
Class Model vs.
Architecture and Detailed
Design Framework classes
Detailed design
Architecture
ApplicationDesign
Class Model
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Categorization of Software Architectures (Shaw & Garlan)
• Dataflow architectures• Batch sequential
• Pipes and Filters
• Independent components
• Parallel communicating processes
• Client-server systems
• Event systems
Categorization of Software Architectures (Shaw & Garlan)
• Dataflow architectures• Batch sequential
• Pipes and Filters
• Independent components
• Parallel communicating processes
• Client-server systems
• Event systems
• Virtual machines • Interpreters
• Rule-based systems
• Repository architectures
• Databases
• Hypertext systems
• Blackboards
• Layered architectures
Design pattern
Architectural Design Patterns
Design Goal Design pattern
Provide an interface to a set of objects of various classes. Facade
Client code
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Design patternArchitecturalDesign Patterns:Summary
Design Goal Design pattern
Provide an interface to a set of objects of various classes. Facade
Cause an object to behave in a manner determined by its current state. State
Encapsulate ways of "visiting" the objects in a collection, so that client code can select a way of visiting at runtime.
Iterator
Facilitate the response of interested entities to changes in a data source. Observer
Interpret statements written in a formal grammar. Interpreter
Client code
see ...
3.2.1
3.2.3
3.4.1
3.2.2.1
3.4.1
Setup code
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Framework classes
Domain classes
Design classes
Detailed design
Architecture
DP
DP
DP
DP
Design
ModelsClass Use case Component
Software DesignsState
= design pattern
Key: DP
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
3. Software architecture alternatives and their class models
Architecture(Garlan & Shaw)
Frequently applicable
design pattern(s)
CommentsCategory Subcategory
Dataflow
Batch sequential Decorator
pattern may apply (see [Ga])Pipes and Filters
Independent components
Parallel communicating processes
Observer (section 3.2.2.1)
Client-server systems
Façade (section 3.2.1)
Event systemsState (section
3.23)Observer
Table 5.1: 1 of 2 Architecture Alternatives (partly Garlan & Shaw)
Virtual machines
InterpretersInterpreter
(section 3.3)
Rule-based systems
See [Ha4] for explanation of rules
Repository architectures
DatabasesObserver, Iterator
(section 3..4.1)
Hypertext systems See Decorator
in [Ga]
Blackboards
See [En] for definition of blackboards
Layered architectures
Most design patterns consist of an abstract layer and a non-abstract layer
Table 5.1: 2 of 2 Architecture Alternatives (partly Garlan & Shaw)
account #& deposit
balancequery
account #& deposit
account #
User
Makeinquiry
accountdatabase
deposittransaction
accountdata
Get deposit
Get inquiry
Validateinquiry
Do deposit
transaction
Create account
summary
Validatedeposit
errorerror
Printer
memberbanks
bank name
Display account
account #
accountdata
accountdisplay
Partial Data Flow Diagram for ATM Application
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Pipe and Filter Architectures
filter
filter
filter
filter filter
filter
pipe
< stream
stream >
pipe
Example of Pipe & Filter Data Flow Architecture Choice
Bank
Maintain wired financial transactions.
Bankdata
A Class model:
Accounts package
Requirement:
record Logtransaction analyze
deposit
deposit data
withdraw
withdrawal
account data
bank address
transaction result
transaction result
transaction
Architecture:
Transactionanalyze()record()
Accountwithdraw()
deposit()
account data
account data
Comm
account data
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
*
1
Example of Batch Sequential Data Flow Architecture
Customer AccountBank
mtgPool unsecurePool
Manage bank funds available for mortgages & unsecured lending.
Collectmortgage funds
Accountbalances
Mortgagepool
Unsecuredpool
Architecture:
Class model:
Collectunsecured funds
Accounts package
Requirement:
Bank package
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Facade Design Pattern Structure
P
«not exposed»
Façade«exposed»
This call replaced by 1 & 2; (Client can’t refer to “P”)
Client
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Facade Design Pattern Structure
«not exposed»
P
«not exposed»
Façade«exposed»
This call replaced by 1 & 2; (Client can’t refer to “P”)
Client1
2
«not exposed» «not exposed»
«not exposed»
«not exposed»
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Architecture and Modularization of Encounter Role-playing Game
EncounterCharacters
EncounterGame
EncounterCast«facade»
EncounterGame«facade»
EncounterEnvironment
EncounterEnvironment«facade»
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
*
Example of Parallel Communicating Processes Architecture Choice
Manage ATM traffic.
Class model:Sessions
Requirement:
SessionCustomer*
Customers
Accountdeposit()
withdraw()retrieve()
*
Example of Parallel Communicating Processes Architecture
Manage ATM traffic.
Architecture:
Class model:Sessions
Requirement:
Customer:customer n
withdraw
Customer:customer n+1
Session:session k
Session:session m
deposit
create
Account:customer n+1 saving
Account:customer nchecking
create
SessionCustomer*
Customers
retrieve
retrieve
Accountdeposit()
withdraw()retrieve()
1 23
4
‡
‡:numbering for explanation in text.Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Observer Design Pattern
Sourcenotify()
Observerupdate()
for all Observer’s o:o.update();
Client of thissystem1
2
1..n
Server part Client part
Gamma et al
Observer Design Pattern
Sourcenotify()
Observerupdate()
ConcreteSubjectstate
ConcreteObserverobserverState
update()
for all Observer’s o:o.update();
if(…) observerState = subject.getState();
Client of thissystem1
2
3
subject
1..n
Server part Client part
Gamma et al
Observer Applied to
International Hamburger Co.
Sourcenotify()
Observerupdate()
Headquartersdemand
SeniorManagementobserverState
update()
for all Observer’s o:o.update();
User of thissystem
1
2
3hq
1..n
MarketingmarketingDemand
update()doDisplay()
if( abs( hq.demand - marketingDemand ) > 0.01 ) { marketingDemand = hq.getDemand();
doDisplay(); }
Server part Client part
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
TargetdoRequest()
State Design Pattern Structure: doRequest() behaves according to state of Target
TargetStatehandleRequest()
Client
1
{ state.handleRequest(); }
targetState
target:Target
Gamma et al
TargetStateBhandleRequest()
TargetdoRequest()
State Design Pattern Structure: doRequest() behaves according to state of Target
targetState TargetStatehandleRequest()
Client
TargetStateAhandleRequest()
1
{ state.handleRequest(); }
. . . . . .
target:Target
Gamma et al
RolePlayingGame
State Design Pattern Applied to Role-Playing Game
RPGamehandleEvent()
GameStatehandleEvent()
state
{ state.handleEvent(); }
RolePlayingGameState Design Pattern Applied to Role-Playing Game
RPGamehandleEvent()
GameStatehandleEvent()
state
{ state.handleEvent(); }
ReportinghandleEvent()
EngaginghandleEvent()
SettingUphandleEvent()
EncounterGame EncounterGame
WaitinghandleEvent()
Setting QualitieshandleEvent()
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Example of a Virtual Machine “Program”
260Mhz & 64MB
400Mhz & 128MB
260Mhz & 32MB
assemble ….
Graphics reproduced with permission from Corel. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Interpreter Design Pattern
AbstractExpressioninterpret()
Client
TerminalExpressioninterpret()
NonTerminalExpressioninterpret()
1..n
Gamma et al
Interpreter Design Pattern
Componentassemble()
Systemassemble()
system1
OrderApplication
Application of Interpreter Design Pattern
Componentassemble()
Computerassemble()
Systemassemble()
system1
system2
RAMassemble()
getRAMType()
CPUassemble()cpu
ram
OrderApplication
n1 = getNewName(); n2 = getnewName();System.out.println( “\nConstruct ” + n1 + “as follows: ” system1.assemble() + “\nConstruct ” + n2 + “as follows: ” system2.assemble() + “\nConnect ” + n1 + “ and “ + n2);
return( getDescription );
return( “\tComputer with ” + cpu.assemble() + “ and ” ram.assemble())
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
A Typical Repository Architecture
Database
DBMS
GUI
Analysisprocess
1
Analysisprocess
n…...…...
Control
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Functions for Iterator
// Iterator "points" to first element:
void setToFirst();
// true if iterator "points" past the last element:
boolean isDone();
Functions for Iterator
// Iterator "points" to first element:
void setToFirst();
// true if iterator "points" past the last element:
boolean isDone();
// Causes the iterator to point to its next element:
void increment();
// Return the element pointed to by the iterator:
C getcurrentElement(); Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Using Iterator Functions
/*
To perform desiredOperation() on elements of
the aggregate according to the iteration (order) i:
*/
for( i.setToFirst(); i.isDone(); i.increment() )
desiredOperation( i.getcurrentElement() );
Adapted from Gamma et al.
Role-playing game layer
Layered Architecture
Characters LayoutRolePlayingGame
EncounterCharacters
EncounterEnvironment
Encounter Game
Application layer
3D engine layer
«uses»
«uses»
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Layered Architecture Example Using Aggregation
Print monthly statements.
Architecture:
Requirement:
Ajax bank printing LayerAccounts Layer Ajax bank common library Layer
Vendor-supplied Layer
“uses”
Layered Architecture Example Using Aggregation
Print monthly statements.
Architecture:
Class model:(relationships withinpackages not shown)
Requirement:
Ajax bank printing LayerAccounts Layer Ajax bank common library Layer
Ajax bank printing
Printer PageFormatter
AjaxLogo AjaxDisclaimer Regulations
Accounts
Account Customer
Vendor-supplied Layer
Ajax bank common library
“uses”
Vendor-suppliedlayer not shown
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Example of Architecture Uses
Parallel communi-cating processes
Rule-basedsystem
Characters
Posible architecture types used
Example of Architecture Uses
Parallel communi-cating processes Event system
Rule-basedsystem
Databasesystem
DatabasesystemLayered
system
Characters
Artifacts
RolePlayingGame
Layout
Encounter Layout
Posible architecture types used
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
1. Decompose into self-contained modules.2. Compare with a standard architecture (e.g., Garlan
and Shaw’s classification). Improve decomposition.– Data flowing in batches between processing stations?
• batch sequential dataflow– Processing stations waiting for data, then executing?
• pipe-and-filter dataflow– Processes executing in parallel?
• parallel communicating processors – A process supplying the needs of user processes?
• client-server– A process only reacting to events occurring upon it?
• event systems– Each execution the interpretation of a script?
• interpreters– An application centered on a data store?
• repository– Arranged in layers?
• layered
Try to develop at least two alternative architectures.
Select an Architecture 1
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
2. Select among the alternatives identified.3. Add classes to those from requirements analysis, to
accommodate the architecture selected– e.g., data flow: … to control flow among the elements– e.g., event systems: … to control transitions among states
4. Apply an existing framework and/or design pattern.– if a helpful one can be identified
5. Partition the collection of classes into packages– ideally, 4-8 (nest packages for larger applications) – each package should make sense in the language of the
application (e.g., “videos” OK; “big classes” not OK) 6. Verify high cohesion within parts; low coupling
among parts -- otherwise, adjust choice.7. Consider introducing a Façade class/object to
control the interface to each package
Select an Architecture 2
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
4. Architecture notation, standards and tools
IEEE 1016-1987 SDD Example 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
IEEE 1016-1987 SDD Example 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
5. Architecture selection QA
Architecture 1 Architecture 2 Architecture 3
QualityQuality weight:
1-109 =High; 5 = Medium; 2 = Low
Extension e ea1 ea2 ea3
Change c ca1 ca2 ca3
Simplicity s sa1 sa2 sa3
Efficiency: speed
esp espa1 espa2 espa3
Efficiency: storage
est esta1 esta2 esta3
TOTAL:e*ea1 + c*ca1 + s*sa1 + esp*espa1 + est*esta1
e*ea2 + c*ca2 + s*sa2 + esp*espa2 + est*esta2
e*ea3 + c*ca3 + s*sa3 + esp*espa3 + est*esta3
Table 5.2 Fuzzy method for comparing architectures
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Architecture Metrics (IEEE 982.1)
13. Number of entries and exits per module
(package)
– If Façade used, number of entries = number of
public methods in Façade object.
Architecture Metrics (IEEE 982.1)
13. Number of entries and exits per module
(package)
– If Façade used, number of entries = number of
public methods in Façade object.
– e.g., class EncounterGame has public methods
getEncounterGame(), execute(), reportState(), and
showResult(). # exit points is number of public
functions that return quantities to the caller or
make changes in the environment external to them.
Architecture for a Simulation
Configuration
ItemsEvents
SimDriver
Random
SimItemSimEvent
serviceDurationNumber
Simulationexecute()initialize()
time()
ScheduledEventsaddEvent()
removeEarliest()
SimConfigurationsetUp()
QueueForTeller
Architecture for a Simulation
SimConfiguration
SimItemsSimEvents
SimDriver
Random
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Teller
Architecture Alternative 2 for Encounter
PlayerCharacter
Areadisplay()
AreaConnectorarea1area2
transition()
PlayerCharacterWindowset( Quality, float )
exit()
ActionListener
ForeignCharacter
2 *
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Key: if this event occurs while Encounter is in this state, then perform the corresponding action in the table.
Event
Click on exit
Request quality change
Dismiss quality window
Foreign character
entersForeign character leaves
Go to indicated
area
Show quality window
Remove quality
widow, and Transition to Waiting
state
Show both characters,
and transition to Engaging
state
Engaging (do
nothing)
Compute results of engage-ment, and transition to
Waiting state
Setting qualities
Transition to Waiting
state
Transition to
Engaging state
Transition to Waiting state
Table 5.3 Table-Driven State-
Transition Event Handling
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Architecture alternative
1. State design pattern
2. ad hoc GUI-driven
3. State-transition table
QualityQuality weight:
1-10High = 9; Medium = 5; Low = 2
Extension 9 High Low Medium
Change 7 High Low Medium
Simplicity 5 Low High Medium
Efficiency: speed
5 Medium High Medium
Efficiency: storage
2 Low Low Medium
TOTAL: (higher = better) 183 126 140
Table 5.4 Fuzzy method for comparing architectures
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Notes on Architecture Inspections
• Inspected against requirements.
• Architecture: lots of room for the creativity
– appears to be difficult to inspect,
• Payoff for defect detection is highest at the
early stages
• Metrics provide an anchor
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Preparing
Defects in Encounter State-Transition Diagram
Setting up
EngagingWaiting
Player completes
setup
Player dismisses window
Reporting
Move to adjacent
area
Foreign character
enters area
Player ready to proceed
Foreign character
enters area
Player dismisses qualities
menuPlayer
requests status
Player clicks qualities
menu
Not specific enough Not
specific enough
Does not handleplayer’s entry to area containing
foreign character
State unclear
Schedule Following Architecture Selection
Month 1
1 2 3 4
Month 2
1 2 3 4
Month 3
1 2 3 4
Month 4
1 2 3 4
Month 5
1 2 3 4
Milestones
Iteration 1
Iteration 2
Release to productionComplete testingFreeze requirements
Characters I
Characters IIRolePlayingGame I
Layout I
EncounterCharacters I
EncounterGame I
EncounterLayout I
Integration& Test I
Integration& Test II
RolePlayingGame I
Layout I
EncounterCharacters II
EncounterGame II
EncounterLayout II
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
6. Summary
Chapter Summary (1/2)
• “Software Architecture” == overall design• Some alternatives:
– Dataflow architectures• Batch sequential
• Pipes and Filters
– Independent components• Parallel communicating processes
• Client-server systems
• Event systems
– Virtual machines • Interpreters
• Rule-based systems
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Chapter Summary (2/2)
• “Frameworks” == generic setting
• “Design patterns” == re-usable combinations
of classes solving frequent design problems
• IEEE SDD standard useful outline
• Create and compare architecture alternatives
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Case Study
RPG Framework for Role-Playing Video Games
CharactersRolePlayingGame
Artifacts
GameEnvironment
RPG Framework for Role-Playing Video Games
CharactersRolePlayingGame
RPGamehandleEvent()
GameStatehandleEvent()
state
{ state.handleEvent(); }
GameCharacter
Artifacts
GameArea
RPGEvent
GameAreaConnection
2GameLayout
0..n
GameEnvironment
For future releases
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Architecture and Modularization of Encounter Role-playing Game
EncounterCharacters
EncounterGame
EncounterCast«facade»
EncounterGame«facade»
EncounterEnvironment
EncounterEnvironment«facade»
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Settingqualities
Sketch of Encounter State-Transition Diagram
Setting up
Engaging
Waiting
Player completes
setup
Player dismisses
report window
Reporting
Foreign character
enters area
Encounter completed
Player dismisses
set qualities widow
Player requests status
Player requests to
set qualities Foreign
character enters area
/ foreign character
absent
/ foreign character present
Player moves to adjacent
areaPlayer quits
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Encounter Use Cases
Encounterforeign
character
player
Initialize
Travel toadjacent
area
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Architecture / Modularization
EncounterCharacters
EncounterGame
EncounterCast
EncounterGame
EncounterEnvironment
EncounterEnvironment
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
FrameWork / Application Dependency
Encounter video game layer
Role-playing game layer
FrameWork / Application Dependency
EncounterCharacters
EncounterGameEncounterCast
EncounterGame
EncounterEnvironment
EncounterEnvironment
Characters GameEnvironment RolePlayingGame
«uses»*«uses»
«uses»
Encounter video game layer
Role-playing game layer (framework)
* by member classes implemen-ting framework interfaces
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.