1. 5. DESIGN I: SOFTWARE ARCHITECTURE

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

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

4. 1. Introduction to system engineering and software architecture

5. Player m GameCorp Billing server Player n A Physical Configuration for Internet- based Encounter Key: Encounter GUI Encounter GUI.. Hardware platform Software subsystem Internet Encounter Server Encounter engine Encounter Reporter Account database Account processing Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

6. Auto control processor Antilock Braking System Diagram Key: ABS controller Hardware Software subsystem Wheel speed sensor Speed thresh- hold alert Hydraulic pressure modulator unit Warning lamp Pressure controller Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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

8. Cohesion and Coupling 1 234 56 High cohesionLow coupling Bridge component  Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

9. Cohesion and Coupling 1 234 56 High cohesionLow coupling High coupling Bridge component    Steel truss Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

10. 1. Develop a mental model of the application at a high level. –as if it were a small application e.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 coupling e.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.

11. 2. Models, frameworks, and design patterns

12. Target Application 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 design Models

13. Target Application 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 design Models

14. Target 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... Sequence diagram package consists of... organized by... Substates decomposed into... Jacobson et al

15. package of classes abstract class package MyPackage; abstract class AbstractClass.... package MyPackage; class DerivedClass extends AbstractClass { int att;..... void myFunction( ReferencedClass r ) {... } } DerivedClass att: int myFunction() 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.

16. package MyPackage; class DerivedClass extends MyClass { AggregatedClass ac; int att;..... void myFunction( ReferencedClass r ) {... } } DerivedClass att: int myFunction() AggregatedClass ac aggregation 1 UML Notation … and … Typical Implementation Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

17. package MyPackage; class DerivedClass extends MyClass { AggregatedClass ac; int att;..... void myFunction( ReferencedClass r ) {... } } DerivedClass att: int myFunction() 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.

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

19. «framework package» «application package» Characters RolePlayingGame GameEnvironment EncounterEnvironment PlayerCharacter 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.

20. 1. Create domain classes -- from requirements analysis 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 architecture More general Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

21. Domain classes Design classes Class Model vs. Architecture and Detailed Design Framework classes Detailed design Architecture Application Design Class Model Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

22. Categorization of Software Architectures (Shaw & Garlan) Dataflow architectures Batch sequential Pipes and Filters Independent components Parallel communicating processes Client-server systems Event systems

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

24. Design pattern Architectural Design Patterns Design GoalDesign 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.

25. Design pattern Architectural Design Patterns: Summary Design GoalDesign 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.

26. Framework classes Domain classes Design classes Detailed design Architecture DP Design Models ClassUse caseComponent Software Designs State = design pattern Key: DP Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

27. 3. Software architecture alternatives and their class models

28. Architecture (Garlan & Shaw) Frequently applicable design pattern(s) Comments CategorySubcategory 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 systems State (section 3.23) Observer Table 5.1: 1 of 2 Architecture Alternatives (partly Garlan & Shaw)

29. Virtual machines Interpreters Interpreter (section 3.3) Rule-based systems See [Ha4] for explanation of rules Repository architectures Databases Observer, 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)

30. account # & deposit balance query account # & deposit account # User Make inquiry account database deposit transaction account data Get deposit Get inquiry Validate inquiry Do deposit transaction Create account summary Validate deposit error Printer member banks bank name Display account account # account data account display Partial Data Flow Diagram for ATM Application Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

31. Pipe and Filter Architectures filter pipe < stream stream > pipe

32. Example of Pipe & Filter Data Flow Architecture Choice Bank Maintain wired financial transactions. Bank data A Class model: Accounts package Requirement: record Log transaction analyze deposit deposit data withdraw withdrawal account data bank address transaction result transaction Architecture: Transaction analyze() record() Account withdraw() deposit() account data Comm account data Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. * 1

33. Example of Batch Sequential Data Flow Architecture Customer Account Bank mtgPool unsecurePool Manage bank funds available for mortgages & unsecured lending. Collect mortgage funds Account balances Mortgage pool Unsecured pool Architecture: Class model: Collect unsecured funds Accounts package Requirement: Bank package Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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

35. Facade Design Pattern Structure «not exposed» P «not exposed» Façade «exposed» This call replaced by 1 & 2; (Client can’t refer to “P”) Client 1 2 «not exposed» Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

36. Architecture and Modularization of Encounter Role-playing Game EncounterCharacters EncounterGame EncounterCast «facade» EncounterGame «facade» EncounterEnvironment «facade» Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

37. * Example of Parallel Communicating Processes Architecture Choice Manage ATM traffic. Class model: Sessions Requirement: Session Customer * Customers Account deposit() withdraw() retrieve()

38. * 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 n checking create Session Customer * Customers retrieve Account deposit() withdraw() retrieve() 1 2 3 4 ‡ ‡: numbering for explanation in text. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

39. Observer Design Pattern Source notify() Observer update() for all Observer ’s o : o.update(); Client of this system 1 2 1..n Server partClient part Gamma et al

40. Observer Design Pattern Source notify() Observer update() ConcreteSubject state ConcreteObserver observerState update() for all Observer ’s o : o.update(); if (…) observerState = subject.getState(); Client of this system 1 2 3 subject 1..n Server partClient part Gamma et al

41. Observer Applied to International Hamburger Co. Source notify() Observer update() Headquarters demand SeniorManagement observerState update() for all Observer’s o: o.update(); User of this system 1 2 3 hq 1..n Marketing marketingDemand update() doDisplay() if ( abs( hq.demand - marketingDemand ) > 0.01 ) {marketingDemand = hq.getDemand(); doDisplay(); } Server partClient part Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

42. Target doRequest() State Design Pattern Structure: doRequest() behaves according to state of Target TargetState handleRequest() Client 1 { state.handleRequest(); } targetState target: Target Gamma et al

43. TargetStateB handleRequest() Target doRequest() State Design Pattern Structure: doRequest() behaves according to state of Target targetState TargetState handleRequest() Client TargetStateA handleRequest() 1 { state.handleRequest(); }... target: Target Gamma et al

44. RolePlayingGame State Design Pattern Applied to Role-Playing Game RPGame handleEvent() GameState handleEvent() state { state.handleEvent(); }

45. RolePlayingGame State Design Pattern Applied to Role-Playing Game RPGame handleEvent() GameState handleEvent() state { state.handleEvent(); } Reporting handleEvent() Engaging handleEvent() SettingUp handleEvent() EncounterGame Waiting handleEvent() Setting Qualities handleEvent() Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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

47. Interpreter Design Pattern AbstractExpression interpret() Client TerminalExpression interpret() NonTerminalExpression interpret() 1..n Gamma et al

48. Interpreter Design Pattern Component assemble() System assemble() system1 OrderApplication

49. Application of Interpreter Design Pattern Component assemble() Computer assemble() System assemble() system1 system2 RAM assemble() getRAMType() CPU assemble() 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.

50. A Typical Repository Architecture Database DBMS GUI Analysis process 1 Analysis process n …... Control Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

51. Functions for Iterator // Iterator "points" to first element: void setToFirst(); // true if iterator "points" past the last element: boolean isDone();

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

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

54. Role-playing game layer Layered Architecture Characters LayoutRolePlayingGame Encounter Characters Encounter Environment Encounter Game Application layer 3D engine layer «uses» Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

55. Layered Architecture Example Using Aggregation Print monthly statements. Architecture: Requirement: Ajax bank printing Layer Accounts Layer Ajax bank common library Layer Vendor-supplied Layer “uses”

56. Layered Architecture Example Using Aggregation Print monthly statements. Architecture: Class model: (relationships within packages not shown) Requirement: Ajax bank printing Layer Accounts Layer Ajax bank common library Layer Ajax bank printing PrinterPageFormatter AjaxLogoAjaxDisclaimerRegulations Accounts AccountCustomer Vendor-supplied Layer Ajax bank common library “uses” Vendor-supplied layer not shown Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

57. Example of Architecture Uses Parallel communi- cating processes Rule-based system Characters Posible architecture types used

58. Example of Architecture Uses Parallel communi- cating processes Event system Rule-based system Database system Database system Layered 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.

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

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

61. 4. Architecture notation, standards and tools

62. IEEE 1016-1987 SDD Example 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

63. IEEE 1016-1987 SDD Example 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

64. 5. Architecture selection QA

65. Architecture 1Architecture 2Architecture 3 Quality Quality weight: 1-10 9 =High; 5 = Medium; 2 = Low Extensioneea1ea2ea3 Changecca1ca2ca3 Simplicityssa1sa2sa3 Efficiency: speed espespa1espa2espa3 Efficiency: storage estesta1esta2esta3 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.

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

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

68. Architecture for a Simulation Configuration Items Events SimDriver Random

69. SimItem SimEvent serviceDuration Number Simulation execute() initialize() time() ScheduledEvents addEvent() removeEarliest() SimConfiguration setUp() QueueForTeller Architecture for a Simulation SimConfiguration SimItems SimEvents SimDriver Random Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Teller

70. Architecture Alternative 2 for Encounter PlayerCharacter Area display() AreaConnector area1 area2 transition() PlayerCharacterWindow set( Quality, float ) exit() ActionListener ForeignCharacter 2 * Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

71. Key: if this  event occurs while Encounte r is in this  state, then perform the correspo nding action in the table. Event Click on exit Request quality change Dismiss quality window Foreign character enters Foreign 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.

72. Architecture alternative 1. State design pattern 2. ad hoc GUI-driven 3. State- transition table Quality Quality weight: 1-10 High = 9; Medium = 5; Low = 2 Extension9HighLowMedium Change7HighLowMedium Simplicity5LowHighMedium Efficiency: speed 5MediumHighMedium Efficiency: storage 2Low Medium TOTAL: (higher = better)183126140 Table 5.4 Fuzzy method for comparing architectures Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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

74. 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 menu Player requests status Player clicks qualities menu Not specific enough Not specific enough Does not handle player’s entry to area containing foreign character State unclear

75. Schedule Following Architecture Selection Month 1 1234 Month 2 1234 Month 3 1234 Month 4 1234 Month 5 1234 Milestones Iteration 1 Iteration 2 Release to production Complete testing Freeze requirements Characters I Characters II RolePlaying Game I Layout I Encounter Characters I Encounter Game I Encounter Layout I Integration & Test I Integration & Test II RolePlaying Game I Layout I Encounter Characters II Encounter Game II Encounter Layout II Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

76. 6. Summary

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

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

79. Case Study

80. RPG Framework for Role-Playing Video Games CharactersRolePlayingGame Artifacts GameEnvironment

81. RPG Framework for Role-Playing Video Games CharactersRolePlayingGame RPGame handleEvent() GameState handleEvent() state { state.handleEvent(); } GameCharacter Artifacts GameArea RPGEvent GameAreaConnection 2 GameLayout 0..n GameEnvironment For future releases Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

82. Architecture and Modularization of Encounter Role-playing Game EncounterCharacters EncounterGame EncounterCast «facade» EncounterGame «facade» EncounterEnvironment «facade» Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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

84. Encounter Use Cases Encounter foreign character player Initialize Travel to adjacent area Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

85. Architecture / Modularization EncounterCharacters EncounterGame EncounterCast EncounterGame EncounterEnvironment Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

86. FrameWork / Application Dependency Encounter video game layer Role-playing game layer

87. FrameWork / Application Dependency EncounterCharacters EncounterGame EncounterCast EncounterGame EncounterEnvironment CharactersGameEnvironmentRolePlayingGame «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.