5. design i: software architecture. plan project integrate & test system analyze requirements...

5. DESIGN I:SOFTWARE

ARCHITECTURE

Plan project

Integrate & test system

Analyze requirements

Design

Maintain

Test unitsImplement

Software Engineering Roadmap: Chapter 5 Focus

Identify corporate practices

Develop Architecture

Develop Detailed Design (next chapter)

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Chapter Learning Goals

• Understand “Software Architecture” term

• Utilize frameworks, design patterns, and

models

• Develop architecture alternatives

• Relate architectures to detailed designs

• Apply the IEEE SDD standard


1. Introduction to system engineering and software architecture

Player m

GameCorp Billing server

Player n

A Physical Configuration for Internet-based Encounter

Key:

EncounterGUI

EncounterGUI

. . . .

Hardwareplatform

Softwaresubsystem

Internet

Encounter Server

Encounterengine

EncounterReporter

Accountdatabase

Accountprocessing


Autocontrol

processor

Antilock Braking System Diagram

Key:

ABS controller

HardwareSoftwaresubsystem

Wheel speed sensor

Speed thresh-hold alert

Hydraulic pressuremodulator unit

Warning lamp

Pressure controller


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


Cohesion and Coupling

1

2 3 4

5 6High cohesion Low couplingBridge

component

component


Cohesion and Coupling

1

2 3 4

5 6High cohesion Low coupling

High coupling

Bridge

component

component

component

Steeltruss


1. Develop a mental model of the application at a high level.– as if it were a small applicatione.g., personal finance application ... … “works by receiving money or paying out money,

in any order, controlled through a user interface”.

2. Decompose into the required components.– look for high cohesion & low couplinge.g., personal finance application ... … decomposes into Assets, Suppliers, & Interface.

3. Repeat this process for the components.

Begin Selecting a Basic Architecture

Note: To use established architectures, see the rest of this chapter


2. Models, frameworks, and design patterns

TargetApplication

Class model“with objects of these classes ...”

e.g., with Engagement … classes

Use-case model“Do this ...”

e.g., engage foreign character

To express requirements, architecture & detailed designModels

TargetApplication

Class model“with objects of these classes ...”

e.g., with Engagement … classes

State model“reacting to these events ...”

e.g., when foreign character enters

Use-case model“Do this ...”

e.g., engage foreign character

Component model“in this way ...”

e.g., scores flow from … to

To express requirements, architecture & detailed designModels

ModelsTarget

Application

Class model: “with ...”

State model: “when”

Use-case model: “do this”

Component model: “how”

class

methods

States

Transitions

Use case

Scenarios

Business use case

Component

Sub-component

Data flow

Local data flow

elaborated by ...Sequencediagram

package

consistsof ...

organizedby ...

Substatesdecomposedinto ...

Jacobson et al

package of classes

abstract classpackage MyPackage; abstract class AbstractClass . . . .

package MyPackage; class DerivedClass extends AbstractClass{ int att; . . . . . void myFunction( ReferencedClass r ) { . .. }} DerivedClass

att: intmyFunction()

UML Notation … and … Typical Implementation

AbstractClass

MyPackage

attribute

operation

inheritance


package MyPackage; class DerivedClass extends MyClass{ AggregatedClass ac; int att; . . . . . void myFunction( ReferencedClass r ) { . .. }}

DerivedClassatt: intmyFunction() AggregatedClassac

aggregation

1



package MyPackage; class DerivedClass extends MyClass{ AggregatedClass ac; int att; . . . . . void myFunction( ReferencedClass r ) { . .. }}

DerivedClassatt: intmyFunction() AggregatedClass

ReferencedClass

ac

MyClass

MyPackage

aggregation

dependency(reference to a class)


1


«application package»

RPG Video Game Layering

«framework package»

Characters

PlayerCharacter

EncounterCharacter

ForeignCharacter

EncounterCharacters

PlayerQualityWindow

«uses»

Framework layer

Application layer






Characters RolePlayingGame

GameEnvironment

EncounterEnvironmentPlayerCharacter

EncounterCharacter


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»


1. Create domain classes

-- from requirementsanalysis

3. Create design classes

-- specific to this application-- to complete the class model

One Way to Obtain The Class Model

2. Create and/or use framework classes

-- for architectureMore

general


Domain classes

Design classes

Class Model vs.

Architecture and Detailed

Design Framework classes

Detailed design

Architecture

ApplicationDesign

Class Model


Categorization of Software Architectures (Shaw & Garlan)

• Dataflow architectures• Batch sequential

• Pipes and Filters

• Independent components

• Parallel communicating processes

• Client-server systems

• Event systems

Categorization of Software Architectures (Shaw & Garlan)

• Dataflow architectures• Batch sequential


• Independent components

• Parallel communicating processes


• Event systems

• Virtual machines • Interpreters

• Rule-based systems

• Repository architectures

• Databases

• Hypertext systems

• Blackboards

• Layered architectures

Design pattern

Architectural Design Patterns

Design Goal Design pattern

Provide an interface to a set of objects of various classes. Facade

Client code


Design patternArchitecturalDesign Patterns:Summary

Design Goal Design pattern

Provide an interface to a set of objects of various classes. Facade

Cause an object to behave in a manner determined by its current state. State

Encapsulate ways of "visiting" the objects in a collection, so that client code can select a way of visiting at runtime.

Iterator

Facilitate the response of interested entities to changes in a data source. Observer

Interpret statements written in a formal grammar. Interpreter

Client code

see ...

3.2.1

3.2.3

3.4.1

3.2.2.1

3.4.1

Setup code


Framework classes

Domain classes

Design classes

Detailed design

Architecture

DP

DP

DP

DP

Design

ModelsClass Use case Component

Software DesignsState

= design pattern

Key: DP


3. Software architecture alternatives and their class models

Architecture(Garlan & Shaw)

Frequently applicable

design pattern(s)

CommentsCategory Subcategory

Dataflow

Batch sequential Decorator

pattern may apply (see [Ga])Pipes and Filters

Independent components

Parallel communicating processes

Observer (section 3.2.2.1)

Client-server systems

Façade (section 3.2.1)

Event systemsState (section

3.23)Observer

Table 5.1: 1 of 2 Architecture Alternatives (partly Garlan & Shaw)

Virtual machines

InterpretersInterpreter

(section 3.3)

Rule-based systems

See [Ha4] for explanation of rules

Repository architectures

DatabasesObserver, Iterator

(section 3..4.1)

Hypertext systems See Decorator

in [Ga]

Blackboards

See [En] for definition of blackboards

Layered architectures

Most design patterns consist of an abstract layer and a non-abstract layer

Table 5.1: 2 of 2 Architecture Alternatives (partly Garlan & Shaw)

account #& deposit

balancequery

account #& deposit

account #

User

Makeinquiry

accountdatabase

deposittransaction

accountdata

Get deposit

Get inquiry

Validateinquiry

Do deposit

transaction

Create account

summary

Validatedeposit

errorerror

Printer

memberbanks

bank name

Display account

account #

accountdata

accountdisplay

Partial Data Flow Diagram for ATM Application


Pipe and Filter Architectures

filter

filter

filter

filter filter

filter

pipe

< stream

stream >

pipe

Example of Pipe & Filter Data Flow Architecture Choice

Bank

Maintain wired financial transactions.

Bankdata

A Class model:

Accounts package

Requirement:

record Logtransaction analyze

deposit

deposit data

withdraw

withdrawal

account data

bank address

transaction result

transaction result

transaction

Architecture:

Transactionanalyze()record()

Accountwithdraw()

deposit()

account data

account data

Comm

account data


*

1

Example of Batch Sequential Data Flow Architecture

Customer AccountBank

mtgPool unsecurePool

Manage bank funds available for mortgages & unsecured lending.

Collectmortgage funds

Accountbalances

Mortgagepool

Unsecuredpool

Architecture:

Class model:

Collectunsecured funds

Accounts package

Requirement:

Bank package


Facade Design Pattern Structure

P

«not exposed»

Façade«exposed»

This call replaced by 1 & 2; (Client can’t refer to “P”)

Client


Facade Design Pattern Structure

«not exposed»

P

«not exposed»

Façade«exposed»

This call replaced by 1 & 2; (Client can’t refer to “P”)

Client1

2

«not exposed» «not exposed»

«not exposed»

«not exposed»


Architecture and Modularization of Encounter Role-playing Game

EncounterCharacters

EncounterGame

EncounterCast«facade»

EncounterGame«facade»

EncounterEnvironment

EncounterEnvironment«facade»


*

Example of Parallel Communicating Processes Architecture Choice

Manage ATM traffic.

Class model:Sessions

Requirement:

SessionCustomer*

Customers

Accountdeposit()

withdraw()retrieve()

*

Example of Parallel Communicating Processes Architecture

Manage ATM traffic.

Architecture:

Class model:Sessions

Requirement:

Customer:customer n

withdraw

Customer:customer n+1

Session:session k

Session:session m

deposit

create

Account:customer n+1 saving

Account:customer nchecking

create

SessionCustomer*

Customers

retrieve

retrieve

Accountdeposit()

withdraw()retrieve()

1 23

4

‡

‡:numbering for explanation in text.Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Observer Design Pattern

Sourcenotify()

Observerupdate()

for all Observer’s o:o.update();

Client of thissystem1

2

1..n

Server part Client part

Gamma et al

Observer Design Pattern

Sourcenotify()

Observerupdate()

ConcreteSubjectstate

ConcreteObserverobserverState

update()


if(…) observerState = subject.getState();

Client of thissystem1

2

3

subject

1..n


Gamma et al

Observer Applied to

International Hamburger Co.

Sourcenotify()

Observerupdate()

Headquartersdemand

SeniorManagementobserverState

update()


User of thissystem

1

2

3hq

1..n

MarketingmarketingDemand

update()doDisplay()

if( abs( hq.demand - marketingDemand ) > 0.01 ) { marketingDemand = hq.getDemand();

doDisplay(); }



TargetdoRequest()

State Design Pattern Structure: doRequest() behaves according to state of Target

TargetStatehandleRequest()

Client

1

{ state.handleRequest(); }

targetState

target:Target

Gamma et al

TargetStateBhandleRequest()

TargetdoRequest()

State Design Pattern Structure: doRequest() behaves according to state of Target

targetState TargetStatehandleRequest()

Client

TargetStateAhandleRequest()

1

{ state.handleRequest(); }

. . . . . .

target:Target

Gamma et al

RolePlayingGame

State Design Pattern Applied to Role-Playing Game

RPGamehandleEvent()

GameStatehandleEvent()

state

{ state.handleEvent(); }

RolePlayingGameState Design Pattern Applied to Role-Playing Game

RPGamehandleEvent()


state


ReportinghandleEvent()

EngaginghandleEvent()

SettingUphandleEvent()

EncounterGame EncounterGame

WaitinghandleEvent()

Setting QualitieshandleEvent()


Example of a Virtual Machine “Program”

260Mhz & 64MB

400Mhz & 128MB

260Mhz & 32MB

assemble ….

Graphics reproduced with permission from Corel. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Interpreter Design Pattern

AbstractExpressioninterpret()

Client

TerminalExpressioninterpret()

NonTerminalExpressioninterpret()

1..n

Gamma et al

Interpreter Design Pattern

Componentassemble()

Systemassemble()

system1

OrderApplication

Application of Interpreter Design Pattern

Componentassemble()

Computerassemble()

Systemassemble()

system1

system2

RAMassemble()

getRAMType()

CPUassemble()cpu

ram

OrderApplication

n1 = getNewName(); n2 = getnewName();System.out.println( “\nConstruct ” + n1 + “as follows: ” system1.assemble() + “\nConstruct ” + n2 + “as follows: ” system2.assemble() + “\nConnect ” + n1 + “ and “ + n2);

return( getDescription );

return( “\tComputer with ” + cpu.assemble() + “ and ” ram.assemble())


A Typical Repository Architecture

Database

DBMS

GUI

Analysisprocess

1

Analysisprocess

n…...…...

Control


Functions for Iterator

// Iterator "points" to first element:

void setToFirst();

// true if iterator "points" past the last element:

boolean isDone();

Functions for Iterator

// Iterator "points" to first element:

void setToFirst();

// true if iterator "points" past the last element:

boolean isDone();

// Causes the iterator to point to its next element:

void increment();

// Return the element pointed to by the iterator:

C getcurrentElement(); Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Using Iterator Functions

/*

To perform desiredOperation() on elements of

the aggregate according to the iteration (order) i:

*/

for( i.setToFirst(); i.isDone(); i.increment() )

desiredOperation( i.getcurrentElement() );

Adapted from Gamma et al.

Role-playing game layer

Layered Architecture

Characters LayoutRolePlayingGame

EncounterCharacters


Encounter Game

Application layer

3D engine layer

«uses»

«uses»


Layered Architecture Example Using Aggregation

Print monthly statements.

Architecture:

Requirement:

Ajax bank printing LayerAccounts Layer Ajax bank common library Layer

Vendor-supplied Layer

“uses”

Layered Architecture Example Using Aggregation

Print monthly statements.

Architecture:

Class model:(relationships withinpackages not shown)

Requirement:

Ajax bank printing LayerAccounts Layer Ajax bank common library Layer

Ajax bank printing

Printer PageFormatter

AjaxLogo AjaxDisclaimer Regulations

Accounts

Account Customer

Vendor-supplied Layer

Ajax bank common library

“uses”

Vendor-suppliedlayer not shown


Example of Architecture Uses

Parallel communi-cating processes

Rule-basedsystem

Characters

Posible architecture types used

Example of Architecture Uses

Parallel communi-cating processes Event system

Rule-basedsystem

Databasesystem

DatabasesystemLayered

system

Characters

Artifacts

RolePlayingGame

Layout

Encounter Layout

Posible architecture types used


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


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


4. Architecture notation, standards and tools

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

1. Introduction 1.1. Purpose 1.2. Scope 1.3. Definitions, acronyms & abbreviations2. References3. Decomposition description 3.1. Module decomposition 3.1.1 Module 1 description 3.1.1 Module 2 description 3.2 Concurrent process decomposition 3.2.1 Process 1 description 3.2.2 Process 2 description 3.3 Data decomposition 3.3.1 Data entry 1 description 3.3.2 Data entry 2 description

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

1. Introduction 1.1. Purpose 1.2. Scope 1.3. Definitions, acronyms & abbreviations2. References3. Decomposition description 3.1. Module decomposition 3.1.1 Module 1 description 3.1.1 Module 2 description 3.2 Concurrent process decomposition 3.2.1 Process 1 description 3.2.2 Process 2 description 3.3 Data decomposition 3.3.1 Data entry 1 description 3.3.2 Data entry 2 description

4. Dependency description 4.1 Intermodule dependencies 4.2 Interprocess dependencies 4.3 Data dependencies5. Interface description 5.1 Module interface 5.1.1 Module 1 description 5.1.2 Module 2 description 5.2 Process interface 5.2.1 Process 1 description 5.2.2 Process 2 description6. Detailed design 6.1 Module detailed design 6.1.1 Module 1 detail 6.2.2 Module 2 detail 6.2 Data detailed design 6.2.1 Data entity 1 detail 6.2.2 Data entity 2 detail

Architecture

5. Architecture selection QA

Architecture 1 Architecture 2 Architecture 3

QualityQuality weight:

1-109 =High; 5 = Medium; 2 = Low

Extension e ea1 ea2 ea3

Change c ca1 ca2 ca3

Simplicity s sa1 sa2 sa3

Efficiency: speed

esp espa1 espa2 espa3

Efficiency: storage

est esta1 esta2 esta3

TOTAL:e*ea1 + c*ca1 + s*sa1 + esp*espa1 + est*esta1

e*ea2 + c*ca2 + s*sa2 + esp*espa2 + est*esta2

e*ea3 + c*ca3 + s*sa3 + esp*espa3 + est*esta3

Table 5.2 Fuzzy method for comparing architectures


Architecture Metrics (IEEE 982.1)

13. Number of entries and exits per module

(package)

– If Façade used, number of entries = number of

public methods in Façade object.

Architecture Metrics (IEEE 982.1)

13. Number of entries and exits per module

(package)

– If Façade used, number of entries = number of

public methods in Façade object.

– e.g., class EncounterGame has public methods

getEncounterGame(), execute(), reportState(), and

showResult(). # exit points is number of public

functions that return quantities to the caller or

make changes in the environment external to them.

Architecture for a Simulation

Configuration

ItemsEvents

SimDriver

Random

SimItemSimEvent

serviceDurationNumber

Simulationexecute()initialize()

time()

ScheduledEventsaddEvent()

removeEarliest()

SimConfigurationsetUp()

QueueForTeller

Architecture for a Simulation

SimConfiguration

SimItemsSimEvents

SimDriver

Random


Teller

Architecture Alternative 2 for Encounter

PlayerCharacter

Areadisplay()

AreaConnectorarea1area2

transition()

PlayerCharacterWindowset( Quality, float )

exit()

ActionListener

ForeignCharacter

2 *


Key: if this event occurs while Encounter is in this state, then perform the corresponding action in the table.

Event

Click on exit

Request quality change

Dismiss quality window

Foreign character

entersForeign character leaves

Go to indicated

area

Show quality window

Remove quality

widow, and Transition to Waiting

state

Show both characters,

and transition to Engaging

state

Engaging (do

nothing)

Compute results of engage-ment, and transition to

Waiting state

Setting qualities

Transition to Waiting

state

Transition to

Engaging state

Transition to Waiting state

Table 5.3 Table-Driven State-

Transition Event Handling


Architecture alternative

1. State design pattern

2. ad hoc GUI-driven

3. State-transition table

QualityQuality weight:

1-10High = 9; Medium = 5; Low = 2

Extension 9 High Low Medium

Change 7 High Low Medium

Simplicity 5 Low High Medium

Efficiency: speed

5 Medium High Medium

Efficiency: storage

2 Low Low Medium

TOTAL: (higher = better) 183 126 140

Table 5.4 Fuzzy method for comparing architectures


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


Preparing

Defects in Encounter State-Transition Diagram

Setting up

EngagingWaiting

Player completes

setup

Player dismisses window

Reporting

Move to adjacent

area

Foreign character

enters area

Player ready to proceed

Foreign character

enters area

Player dismisses qualities

menuPlayer

requests status

Player clicks qualities

menu

Not specific enough Not

specific enough

Does not handleplayer’s entry to area containing

foreign character

State unclear

Schedule Following Architecture Selection

Month 1

1 2 3 4

Month 2

1 2 3 4

Month 3

1 2 3 4

Month 4

1 2 3 4

Month 5

1 2 3 4

Milestones

Iteration 1

Iteration 2

Release to productionComplete testingFreeze requirements

Characters I

Characters IIRolePlayingGame I

Layout I

EncounterCharacters I

EncounterGame I

EncounterLayout I

Integration& Test I

Integration& Test II

RolePlayingGame I

Layout I

EncounterCharacters II

EncounterGame II

EncounterLayout II


6. Summary

Chapter Summary (1/2)

• “Software Architecture” == overall design• Some alternatives:

– Dataflow architectures• Batch sequential


– Independent components• Parallel communicating processes


• Event systems

– Virtual machines • Interpreters

• Rule-based systems


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


Case Study

RPG Framework for Role-Playing Video Games

CharactersRolePlayingGame

Artifacts

GameEnvironment

RPG Framework for Role-Playing Video Games

CharactersRolePlayingGame

RPGamehandleEvent()


state


GameCharacter

Artifacts

GameArea

RPGEvent

GameAreaConnection

2GameLayout

0..n

GameEnvironment

For future releases


Architecture and Modularization of Encounter Role-playing Game

EncounterCharacters

EncounterGame

EncounterCast«facade»

EncounterGame«facade»


EncounterEnvironment«facade»


Settingqualities

Sketch of Encounter State-Transition Diagram

Setting up

Engaging

Waiting

Player completes

setup

Player dismisses

report window

Reporting

Foreign character

enters area

Encounter completed

Player dismisses

set qualities widow

Player requests status

Player requests to

set qualities Foreign

character enters area

/ foreign character

absent

/ foreign character present

Player moves to adjacent

areaPlayer quits


Encounter Use Cases

Encounterforeign

character

player

Initialize

Travel toadjacent

area


Architecture / Modularization

EncounterCharacters

EncounterGame

EncounterCast

EncounterGame




FrameWork / Application Dependency

Encounter video game layer

Role-playing game layer

FrameWork / Application Dependency

EncounterCharacters

EncounterGameEncounterCast

EncounterGame



Characters GameEnvironment RolePlayingGame

«uses»*«uses»

«uses»

Encounter video game layer

Role-playing game layer (framework)

* by member classes implemen-ting framework interfaces


5. design i: software architecture. plan project integrate & test system analyze requirements...

Documents

software architecture

objectoriented perspective

braude wiley

software architecture

system engineering

high speed

high cohesion low coupling

encounter gui encounter