5 DESIGN I SOFTWARE ARCHITECTURE Software Engineering Roadmap
- Slides: 87
5. DESIGN I: SOFTWARE ARCHITECTURE
Software Engineering Roadmap: Chapter 5 Focus Develop Architecture Identify corporate practices Develop Detailed Design (next chapter) 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.
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
A Physical Configuration for Internetbased Encounter GUI Player m Encounter engine Encounter Server Encounter Reporter . . Encounter GUI Player n Key: Hardware platform Internet Software subsystem Account database Game. Corp Billing server Account processing Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Antilock Braking System Diagram Warning lamp Speed threshhold alert Wheel speed sensor Auto control processor ABS controller Pressure controller Hydraulic pressure modulator unit Key: Hardware Software subsystem 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 component 3 4 component High cohesion 5 Bridge Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. 6 Low coupling
Cohesion and Coupling 1 2 component 3 4 component High cohesion 5 Bridge 6 Low coupling Stee l truss component High coupling Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Begin Selecting a Basic Architecture 1. Develop a mental model of the application at a high level. Note: To use established – as if it were a small application architectures, see the e. g. , personal finance application. . . rest of this chapter … “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. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
2. Models, frameworks, and design patterns
Models To express requirements, architecture & detailed d Use-case model Class model “Do this. . . ” “with objects of these classes. . . ” e. g. , engage foreign character e. g. , with Engagement … classes Target Application
Models To express requirements, architecture & detailed d Use-case model Class model “Do this. . . ” “with objects of these classes. . . ” e. g. , engage foreign character e. g. , with Engagement … classes Target Application Component model State model “in this way. . . ” “reacting to these events. . . ” e. g. , scores flow from … to e. g. , when foreign character enters
Use-case model: “do this” Business use case Class model: “with. . . ” Use case package elaborated by. . . consist s of. . . Sequence diagram Scenarios methods Target Application Models Component model: “how” Component organize d by. . . class Data flow Local data flow Sub-component State model: “when” States decompos ed into. . . Substates Transitions Jacobson et al
UML Notation … and … Typical Implementation package of classes My. Package abstract class Abstract. Class inheritance Derived. Class att: int my. Function() package My. Package; abstract class Abstract. Class. . package My. Package; class Derived. Class extends Abstract. Class { int att; . . . void my. Function( Referenced. Class r ) {. . . } } attribute operation Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
UML Notation … and … Typical Implementation package My. Package; class Derived. Class extends My. Class { Aggregated. Class ac; int att; . . . void my. Function( Referenced. Class r ) {. . . } } Derived. Class att: int my. Function() aggregation ac 1 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Aggregated. Class
UML Notation … and … Typical Implementation My. Package My. Class Derived. Class att: int my. Function() package My. Package; class Derived. Class extends My. Class { Aggregated. Class ac; int att; . . . void my. Function( Referenced. Class r ) {. . . } } aggregation dependency (reference to a class) ac 1 Aggregated. Class Referenced. Class Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
RPG Video Game Layering Framework layer Characters «framework package» Encounter. Characters «application package» Application layer Encounter. Character Player. Character Foreign. Character Player. Quality. Window Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. «uses»
Role-Playing Game, and Encounter Packages -- showing domain classes Framework layer Game. Environment «framework package» Role. Playing. Game Characters «framework package» Application layer Encounter. Characters «application package» «framework package» «uses» Encounter. Game «application package» Encounter. Game Encounter. Character Player. Character Foreign. Character Player. Quality. Window Engagement. Display Encounter. Environment «application package» Area Encounter. Area. Connection. Hyperlink Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
One Way to Obtain The Class Model 2. Create and/or use framework classes More general -- for architecture 3. Create design classes 1. Create domain classes -- specific to this application -- to complete the class model -- from requirements analysis Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Class Model vs. Architecture and Detailed Design Class Model Framework classes Architecture Design classes Application Design Detailed design Domain classes 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 • Virtual machines • Batch sequential • Interpreters • Pipes and Filters • Rule-based systems • Independent components • Repository architectures • Parallel communicating processes • Databases • Client-server systems • Blackboards • Event systems • Hypertext systems • Layered architectures
Architectural Design Patterns Clien t code Design pattern Design Goal Provide an interface to a set of objects of various classes. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Design pattern Facade
Architectural Design Patterns: Setu Summary p code Clien t code Design Goal Design pattern see. . . Facade 3. 2. 1 State 3. 2. 3 Iterator 3. 4. 1 Provide an interface to a set of objects of various classes. Cause an object to behave in a manner determined by its current state. Encapsulate ways of "visiting" the objects in a collection, so that client code can select a way of visiting at runtime. Facilitate the response of interested entities to changes in a data source. Interpret statements written in a formal grammar. Observer Interpreter Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. 3. 2. 2. 1 3. 4. 1
Models Software Designs Class Framework classes Use case Component State DP Architecture DP Design classes Design DP DP Detailed design Domain classes Key: DP = design pattern 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) Category Frequently applicable design pattern(s) Subcategory Decorator pattern may apply (see [Ga]) Batch sequential Dataflow Pipes and Filters Table 5. 1: 1 of 2 Architecture Alternatives (partly Garlan & Shaw) Independent components Parallel communicating processes Comments Observer (section 3. 2. 2. 1) Client-server systems Façade (section 3. 2. 1) Event systems State (section 3. 23) Observer
Interpreter (section 3. 3) Interpreters Virtual machines Table 5. 1: 2 of 2 Architecture Alternatives (partly Garlan & Shaw) Repository architectures See [Ha 4] for explanation of rules Observer, Iterator (section 3. . 4. 1) Rule-based systems Databases Hypertext systems Blackboards Layered architectures See Decorator in [Ga] See [En] for definition of blackboards Most design patterns consist of an abstract layer and a nonabstract layer
member banks bank name Partial Data Flow Diagram for ATM Application Get deposit Get inquiry User error account # & deposit account display Validate inquiry Validate deposit account # & deposit Display account data Do deposit transaction error Make inquiry account # Printer balance query account database account data Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Create account summary
Pipe and Filter Architectures stream > filter pipe filter < stream filter
Example of Pipe & Filter Data Flow Architecture Choice Requirement: Maintain wired financial transactions. account data deposit data Bank data transaction analyze transaction Architecture: transaction result record withdrawal Comm bank address Log transaction result withdraw account data A Class model: Accounts package Transaction analyze() record() 1 Bank Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. * Account withdraw() deposit()
Example of Batch Sequential Data Flow Architecture Requirement: Manage bank funds available for mortgages & unsecured lending. Architecture: Account balances Class model: Customer Collect mortgage funds Mortgage pool Collect unsecured funds Unsecured pool Accounts package Account Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Bank package Bank mtg. Pool unsecure. Pool
Facade Design Pattern Structure Façade Client This call replaced by 1 & 2; (Client can’t refer to “P”) «exposed» P «not exposed» Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Facade Design Pattern Structure Client This call replaced by 1 & 2; (Client can’t refer to “P”) Façade 1 «exposed» 2 «not exposed» P «not exposed» Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. «not exposed»
Architecture and Modularization of Encounter Role-playing Game Encounter. Characters «facade» Encounter. Cast «facade» Encounter. Environment «facade» Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Example of Parallel Communicating Processes Architecture Choice Requirement: Manage ATM traffic. Class model: Customers Session * Customer * Account deposit() withdraw() retrieve()
Example of Parallel Communicating Processes Architecture Requirement: Manage ATM traffic. Architecture: Customer: 1 ‡ customer n Customer: customer n+1 Session: session m 2 create deposit withdraw Class model: ‡: numbering for explanation in text. Session: session k Account: customer n checking 3 retrieve create retrieve 4 Customers Session Account: customer n+1 saving * Customer Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. * Account deposit() withdraw() retrieve()
Observer Design Pattern Server part Source notify() 1 Client part Client of this system 1. . n Observer update() 2 for all Observer’s o: o. update(); Gamma et al
Observer Design Pattern Server part 1 Source notify() Client part Client of this system 1. . n 2 Observer update() for all Observer’s o: o. update(); Concrete. Subject state Concrete. Observer observer. State update() subject 3 if(…) observer. State = subject. get. State(); Gamma et al
User of this Server part system 1 Observer Applied to International Hamburger Co. Observer update() 1. . n Source notify() Client part for all Observer’s o: 2 o. update(); Headquarters demand hq 3 Senior. Management observer. State Marketing update() marketing. Demand update() do. Display() if( abs( hq. demand - marketing. Demand ) > 0. 01 ) { marketing. Demand = hq. get. Demand(); do. Display(); } Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
State Design Pattern Structure: do. Request() behaves according to state of Target Client { state. handle. Request(); } Target. State target. State do. Request() 1 handle. Request() target: Target Gamma et al
State Design Pattern Structure: do. Request() behaves according to state of Target Client { state. handle. Request(); } Target do. Request() target: Target. State. A handle. Request() target. State Target. State 1 handle. Request() Target. State. B handle. Request() . . . Gamma et al
State Design Pattern Applied to Role-Playing Game RPGame state handle. Event() { state. handle. Event(); } Role. Playing. Game. State
State Design Pattern Applied to Role-Playing Game state RPGame Role. Playing. Game. State handle. Event() { state. handle. Event(); } Encounter. Game Waiting Setting Qualities handle. Event() Setting. Up Reporting Engaging handle. Event() Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Example of a Virtual Machine “Program” 400 Mhz & 128 MB assemble …. 260 Mhz & 64 MB 260 Mhz & 32 MB 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 Abstract. Expression 1. . n Client interpret() Terminal. Expression Non. Terminal. Expression interpret() Gamma et al
Order. Application Component assemble() system 1 System Interpreter Design Pattern assemble()
n 1 = get. New. Name(); n 2 = getnew. Name(); System. out. println ( “n. Construct ” + n 1 + “as follows: ” system 1. asse “n. Construct ” + n 2 + “as follows: ” system 2. assem “n. Connect ” + n 1 + “ and “ + n 2); Order. Application of Interpreter Design Pattern Component assemble() system 1 return( “t. Computer with ” + System cpu. assemble() + “ and ” assemble() ram. assemble()) cpu Computer assemble() CPU system 2 return( get. Description ); assemble() ram Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. RAM assemble() get. RAMType()
A Typical Repository Architecture GUI Analysis process 1 Control …. . . DBMS Database Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Analysis process n
Functions for Iterator // Iterator "points" to first element: void set. To. First(); // true if iterator "points" past the last element: boolean is. Done();
Functions for Iterator // Iterator "points" to first element: void set. To. First(); // true if iterator "points" past the last element: boolean is. Done(); // Causes the iterator to point to its next element: void increment(); // Return the element pointed to by the iterator: C getcurrent. Element(); Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Using Iterator Functions /* To perform desired. Operation() on elements of the aggregate according to the iteration (order) i: */ for( i. set. To. First(); i. is. Done(); i. increment() ) desired. Operation( i. getcurrent. Element() ); Adapted from Gamma et al.
Layered Architecture 3 D engine layer Role-playing game layer Characters «uses» Role. Playing. Game Layout «uses» Application layer Encounter Characters Encounter Environment Encounter Game Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Layered Architecture Example Using Aggregation Requirement: Print monthly statements. Architecture: “uses” Ajax bank printing Layer Accounts Layer Ajax bank common library Layer Vendor-supplied Layer
Layered Architecture Example Using Aggregation Requirement: Print monthly statements. Architecture: “uses” Ajax bank printing Layer Accounts Layer Ajax bank common library Layer Vendor-supplied Layer Class model: Ajax bank printing (relationships within packages not shown) Printer Formatter Page Accounts Account Vendor-supplied layer not shown Customer Ajax bank common library Ajax. Logo Ajax. Disclaimer Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Regulations
Example of Architecture Uses Characters Parallel communicating processes Rule-based system Posible architectu re types used
Example of Architecture Uses Characters Role. Playing. Game Parallel communicating processes Rule-based system Artifacts Database system Event system Posible architectu re types used Layout Layered system Database system Encounter Layout 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 Select an Architecture 1 Try to develop at least two alternative architectures. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Select an Architecture 2 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 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 & 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
IEEE 1016 -1987 SDD Example Table of Contents (Reaffirmed 1993) 1. Introduction 4. Dependency description 1. 1. Purpose 4. 1 Intermodule dependencies Architecture 1. 2. Scope 4. 2 Interprocess dependencies 1. 3. Definitions, acronyms 4. 3 Data dependencies & abbreviations 5. Interface description 2. References 5. 1 Module interface 3. Decomposition description 5. 1. 1 Module 1 description 3. 1. Module decomposition 5. 1. 2 Module 2 description 3. 1. 1 Module 1 description 5. 2 Process interface 3. 1. 1 Module 2 description 5. 2. 1 Process 1 description 3. 2 Concurrent process 5. 2. 2 Process 2 description decomposition 6. Detailed design 3. 2. 1 Process 1 description 6. 1 Module detailed design 3. 2. 2 Process 2 description 6. 1. 1 Module 1 detail 3. 3 Data decomposition 6. 2. 2 Module 2 detail 3. 3. 1 Data entry 1 description 6. 2 Data detailed design 3. 3. 2 Data entry 2 description 6. 2. 1 Data entity 1 detail 6. 2. 2 Data entity 2 detail
5. Architecture selection QA
Table 5. 2 Fuzzy method for comparing architectures Quality Architecture 1 weight: 1 -10 Quality Architecture 2 Architecture 3 9 =High; 5 = Medium; 2 = Low Extension e ea 1 ea 2 ea 3 Change c ca 1 ca 2 ca 3 Simplicity s sa 1 sa 2 sa 3 Efficiency: speed espa 1 espa 2 espa 3 Efficiency: storage esta 1 esta 2 esta 3 TOTAL: e*ea 1 + c*ca 1 + s*sa 1 + esp*espa 1 + est*esta 1 e*ea 2 + c*ca 2 + s*sa 2 + esp*espa 2 + est*esta 2 e*ea 3 + c*ca 3 + s*sa 3 + esp*espa 3 + est*esta 3 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 Encounter. Game has public methods get. Encounter. Game(), execute(), report. State(), and show. Result(). # 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 Items Configuration Events Sim. Driver Random
Architecture for a Simulation Sim. Items Sim. Configuration Sim. Events Sim. Item Sim. Event Queue. For. Teller Simulation Sim. Configuration set. Up() Random Teller service. Duration execute() initialize() time() Sim. Driver Scheduled. Events Number Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. add. Event() remove. Earliest()
Architecture Alternative 2 for Encounter. Action. Listener Area. Connector area 1 * area 2 transition() Area 2 display() Foreign. Character Player. Character. Window set( Quality, float ) exit() Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
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 Go to indicated area Request quality change Dismiss quality window Foreign character enters Show quality window Remove quality widow, and Transition to Waiting state Show both characters, and transition to Engaging state Engaging Setting qualities (do nothing) Transition to Waiting state Foreign character leaves Table 5. 3 Table. Driven State. Transition Event Handling Transition to Engaging state Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Compute results of engage-ment, and transition to Waiting state Transition to Waiting state
Table 5. 4 Fuzzy method for comparing architectures Quality Architecture alternative 1. State design pattern Quality weight: 1 -10 2. ad hoc GUI -driven 3. Statetransition table High = 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 Medium TOTAL: (higher = better) 183 126 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. 140
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.
Defects in Encounter State-Transition Diagram Setting up Player completes setup Not specific enough Player dismisses window Player dismisses qualities menu Reporting Preparing Does not handle player’s entry to area containing Player requests foreign character Move to adjacent area Waiting State unclear Foreign character enters area status Player clicks qualities menu Player ready to proceed Engaging Not specific enough Foreign character enters area
Schedule Following Architecture Selection Month 1 Month 2 Month 3 Month 4 Month 5 1 2 3 4 1 2 3 4 Milestones Freeze requirements Characters I Encounter Characters I Iteration 1 Role. Playing Game I Encounter Game I Layout I Encounter Layout I Complete testing Release to production Integration & Test I Characters II Encounter Characters II Role. Playing Game I Encounter Game II Layout I Encounter Layout II Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Integration & Test II Iteration 2
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 Role. Playing. Game Characters Game. Environment Artifacts
RPG Framework for Role-Playing Video Games Role. Playing. Game RPGame Characters state Game. Character handle. Event() 0. . n { state. handle. Event(); } RPGEvent Game. State handle. Event() Game. Environment Game. Layout Game. Area Artifacts For future releases Game. Area. Connection Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. 2
Architecture and Modularization of Encounter Role-playing Game Encounter. Characters «facade» Encounter. Cast «facade» Encounter. Environment «facade» Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Sketch of Encounter State-Transition Diagram Setting up Player completes setup Player dismisses set qualities widow Setting qualities Reporting Player dismisses report window Player requests status Player requests to set qualities Foreign character enters area Waiting Player moves to adjacent area Player quits / foreign character absent Foreign character enters area Encounter completed / foreign character present Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Engaging
Encounter Use Cases Initialize player Travel to adjacent area Encounter foreign character Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Architecture / Modularization Encounter. Game Encounter. Characters Encounter. Cast Encounter. Environment Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Frame. Work / Application Dependency Role-playing game layer Encounter video game layer
Frame. Work / Application Dependency Characters Game. Environment Role. Playing. Game «uses» Role-playing game layer (framework) Encounter video game layer «uses» * «uses» Encounter. Cast Encounter. Characters * by member classes implementing framework interfaces Encounter. Game Encounter. Environment Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
- Software engineering roadmap
- Software engineering roadmap
- Real time software design in software engineering
- Software design fundamentals in software engineering
- What is architecture business cycle
- Call and return architecture in software engineering
- Repository architecture style
- Data-centered architecture
- Ess enterprise
- System procurement process in software engineering
- Forward engineering in software engineering
- Requirements engineering a roadmap
- Specialcourseinfo
- Electrical engineering roadmap
- Requirements engineering: a roadmap
- What is component diagram in software engineering
- Complex software design
- Software architecture design
- Architectural pattern in software engineering
- User interface design steps in software engineering
- Design patterns software engineering
- Gui in software engineering
- What is function oriented design in software engineering
- Design concepts in software engineering
- Architectural design in software engineering
- Design principles in software engineering
- Detailed design in software engineering
- Interface design in software engineering
- Software engineering slides
- What is the software?
- User interface design principles in software engineering
- Component-level design in software engineering
- Interface analysis means understanding
- Design concepts in software engineering
- Interface design in software engineering
- Design issues in software engineering
- Web app interface design in software engineering
- Design changes example
- Design metrics in software engineering
- User interface design process in software engineering
- In structural decomposition are concerned
- Design thinking roadmap
- Software maintenance in software engineering ppt
- Who invented software engineering
- Metrics computer science
- Types of software crisis
- Software measurement and metrics
- Testing de software
- Integral architecture example
- Modular product architectures
- Buses in computer architecture
- General architecture for text engineering
- Roman architecture and engineering
- General architecture for text engineering
- General architecture for text engineering
- Engineering elegant systems: theory of systems engineering
- Elegant systems
- Reverse engineering vs forward engineering
- Architecture analysis and design language
- Plugin design pattern java
- Memory system
- Honeycomb design architecture
- Harris & harris digital design and computer architecture
- Physical architecture layer design
- Physical architecture layer design
- Design objectives architecture
- West 8 architecture
- Physical architecture layer design
- Digital design and computer architecture
- 64 bit alu
- Digital design and computer architecture
- Digital design and computer architecture
- Atm topology
- Architecture design principles
- Architecture design principles
- Contoh desain arsitektur aplikasi
- Network analysis architecture and design
- Processor logic design
- Gradated rhythm
- Control unit design
- Design synthesis architecture
- Basic computer design
- Alu in computer architecture
- What is a decorative design
- Cloud responsibility
- Bubble pushing example
- Register in computer organization
- Hadoop distributed file system architecture design