5 DESIGN I SOFTWARE ARCHITECTURE Software Engineering Roadmap

  • Slides: 87
Download presentation
5. DESIGN I: SOFTWARE ARCHITECTURE

5. DESIGN I: SOFTWARE ARCHITECTURE

Software Engineering Roadmap: Chapter 5 Focus Develop Architecture Identify corporate practices Develop Detailed Design

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

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

1. Introduction to system engineering and software architecture

A Physical Configuration for Internetbased Encounter GUI Player m Encounter engine Encounter Server Encounter

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

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

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

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

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

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

2. Models, frameworks, and design patterns

Models To express requirements, architecture & detailed d Use-case model Class model “Do this.

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.

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

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

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

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:

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

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

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

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

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 •

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 •

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

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

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

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

3. Software architecture alternatives and their class models

Architecture (Garlan & Shaw) Category Frequently applicable design pattern(s) Subcategory Decorator pattern may apply

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

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

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

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

Example of Pipe & Filter Data Flow Architecture Choice Requirement: Maintain wired financial transactions.

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

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

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

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.

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

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 ‡

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

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

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

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

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.

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

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.

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()

Order. Application Component assemble() system 1 System Interpreter Design Pattern assemble()

n 1 = get. New. Name(); n 2 = getnew. Name(); System. out. println

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

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(); //

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(); //

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

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

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

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

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

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

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

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

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

4. Architecture notation, standards and tools

IEEE 1016 -1987 SDD Example Table of Contents (Reaffirmed 1993) 1. Introduction 1. 1.

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

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

5. Architecture selection QA

 Table 5. 2 Fuzzy method for comparing architectures Quality Architecture 1 weight: 1

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)

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)

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 Items Configuration Events Sim. Driver Random

Architecture for a Simulation Sim. Items Sim. Configuration Sim. Events Sim. Item Sim. Event

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

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

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

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

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

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

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

6. Summary

Chapter Summary (1/2) • “Software Architecture” == overall design • Some alternatives: – Dataflow

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

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

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 Characters Game. Environment Artifacts

RPG Framework for Role-Playing Video Games Role. Playing. Game RPGame Characters state Game. Character

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.

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

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

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

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 Role-playing game layer Encounter video game layer

Frame. Work / Application Dependency Characters Game. Environment Role. Playing. Game «uses» Role-playing game

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.