5. DESIGN I: SOFTWARE ARCHITECTURE

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 standardAdapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

1. Introduction to system engineering and software architecture

System Engineering and s/w Acrh.

• System Engineering = analysis and design process which decomposes an application (system) in components (hardware, software, people) and then reassembles it

Systems analysis – decomposes a system into its component pieces for the purpose of studying how well those component parts work and interact - deals with “What”

Systems design – reassembles a system’s component pieces back into a complete system … hopefully, an improved system (via addition, change) – deals with “How”

• Software Architecture = design at the highest level– Beyond requirements that defined what system must do, where it

must do it and when – Focus moves strongly toward how system will meet requirements

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

Hardware Softwaresubsystem

Wheel speed sensor

Speed thresh-hold alert

Hydraulic pressuremodulator unit

Warning lamp

Pressure controller


An example of Embedded s/w

Workshop

• In your project teams …• Consider a high-rise building of 25 stories

composed of offices.• Draw a high-level architecture showing the

major h/w and s/w components

Cohesion and Coupling

1

2 3 4

5 6High cohesion Low couplingBridge

component

component


Effective modularization = max. cohesion within modules + min. coupling between modules

Cohesion and Coupling

1

2 3 4

5 6High cohesion Low coupling

High coupling

Bridge

component

component

component

Steeltruss


Why High Cohesion /Low Coupling?

• Extensibility – easy to add requirements• Facilitates change / replacement• Simplicity of structure … easy to

understand, implement, maintain• Usually more efficient – smaller in size,

faster, requires less resources• Facilitates layered and distributed

architectures• THESE ARE THE KEY DESIGN GOALS

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


Workshop

• In your project teams …• Consider the high-rise building of 25 stories

once more.• Can you increase cohension within

components and decrease coupling between components through re-design?

• Focus on two related components and take them to the next level of detail (eg. Electrical and Security subsystems)

2. Models, frameworks, and design patterns

Definitions:

• Model = a perspective (usually graphical) of the decomposition of a system into components and the relationship between those components– Different models are used for each system

• Framework = a family or class of applications for which models can be reused– Design patterns of interrelated classes that have

been used many times (eg. queuing system)– A general RPG framework will be developed

for role playing games, then used for Encounter

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

«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


Categorization of Software Architectures (Shaw & Garlan)

• Dataflow architectures• Batch sequential• Pipes and Filters

• Independent components

• Parallel communicating processes

• Client-server systems• Event systems

• Virtual machines • Interpreters• Rule-based systems

• Repository architectures

• Databases• Hypertext systems• Blackboards

• Layered architectures

• Comm. stacks

Design patternArchitecturalDesign Patterns:Summary

Design Goal Design patternProvide 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


3. Software architecture alternatives and their class models

(design patterns)

Facade Design Pattern Structure

P

«exposed»

This shows a direct call to a process “P” from Client

Client


Q «exposed»

Wide field of accessto server objects

Facade Design Pattern Structure

Q «not exposed»

P

«not exposed»

Façade«exposed»

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

Client1

2

«not exposed» «not exposed»

«not exposed»

«not exposed»


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


TargetStateBhandleRequest()

TargetdoRequest()

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

targetState TargetStatehandleRequest()

Client

TargetStateAhandleRequest()

1

{ targetState.handleRequest(); }

. . . . . .

target:Target

Gamma et al

RolePlayingGameState Design Pattern Applied to Role-Playing Game

RPGamehandleEvent()

GameStatehandleEvent()

state

{ state.handleEvent(); }

ReportinghandleEvent()

EngaginghandleEvent()

SettingUphandleEvent()

EncounterGame EncounterGame

WaitinghandleEvent()

Setting QualitieshandleEvent()


A Typical Repository Architecture

Database

DBMS

GUI

Analysisprocess

1

Analysisprocess

n…...…...

Control


Entity Relationship Modeling

ERD = Entity Relationship Diagram

An Example: Relational Tables

pnum pdesc psd ped1 E911 Apr Nov2 CAPC Aug Dec

eid ename9902 Ritter, Tex0103 Nasium, Jim

aid ………………..apnum aeid alnum abd aed1 9902 Hfx1 May Oct1 0103 Hfx1 May Aug2 0103 Yrm2 Sep Oct

lnum laddressHfx1 1234 Barrington St.Yrm2 56 Front St.

PROJECT EMPLOYEE

ASSIGNMENTLOCATION

Role-playing game layer

Layered Architecture

Characters LayoutRolePlayingGame

EncounterCharacters

EncounterEnvironment

Encounter Game

Application layer

3D engine layer

«uses»

«uses»


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?

• layeredTry 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


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 Alternative

1. State design pattern

2. ad hoc GUI-driven

3. State-transition table

Quality Quality weight:1-10 High = 9; Medium = 5; Low = 2

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


WORKSHOP

• Outline three different architectures for an electronic mail system for Acadia staff.

• Use the following matrix to decide which architecture would be best (weight = 1-5).

Quality Weight Alt. 1Client/Server

Alt. 2 Browser-based

Alt. 3Telnet-based

Extension 4 5 20Change 5 3 15Simplicity 5 3 15Eff. Speed 3 5 15Eff. Storage 1 4 4TOTALS 69

Notes on Architecture Inspections

• Payoff for defect detection is highest at the early stages

• Lots of room for creativity, appears to be difficult to inspect

• Inspect against requirements.

• Check with Use Cases – does the arch. cover all scenarios


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

Settingqualities


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 to



/ foreign character

absent

/ foreign character present


areaPlayer quits


Schedule Following Architecture Selection

Month 11 2 3 4

Month 21 2 3 4

Month 31 2 3 4

Month 41 2 3 4

Month 51 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


Case Study

RPG Framework for Role-Playing Video Games

CharactersRolePlayingGame

Artifacts

GameEnvironment

RPG Framework for Role-Playing Video Games

CharactersRolePlayingGame

RPGamehandleEvent()

GameStatehandleEvent()

state

{ state.handleEvent(); }

GameCharacter

ArtifactsGameArea

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


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 to



/ foreign character

absent

/ foreign character present


areaPlayer quits


Encounter Use Cases

Encounterforeign

character

player

Initialize

Travel toadjacent

area


Architecture / Modularization

EncounterCharacters

EncounterGame

EncounterCast

EncounterGame




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


Date post:	18-Feb-2016
Category:	Documents
Upload:	ramona
View:	56 times
Download:	0 times

5. DESIGN I: SOFTWARE ARCHITECTURE

Documents