software engineering - baylor...

Software EngineeringSoftware Engineering Modern Approaches

Eric Braude and Michael Bernstein1

Ch t 18 S ft A hit tChapter 18: Software Architecture

© 2010 John Wiley & Sons Ltd.2

Learning Goals of This ChapterPlanning

• How do you classify “software architectures?”Testing

Maintenance

g

Th S ft • What are data flow architectures?

• What are three-tier architectures and their generalizations?

Requirements analysis

Testing The Software Development

Lifecycletheir generalizations?

• What makes database-centric systems a separate type of

hit t ?

analysis

Design

Implementation

architecture?

• What are service-oriented architectures?

g

Phase most relevant to this

• What are the IEEE standards for expressing designs?

relevant to this chapter is shown in

bold

• What do real-world architectures look like?


Categorization of Software Architectures(Shaw & Garlan)

Dataflow architectures Virtual machines Dataflow architectures Pipes and Filters

Batch sequential

Virtual machines Interpreters

l b d Batch sequential

Independent componentsl

Rule‐based systems

Repository architectures Client‐server systems

Parallel communicating processes

Databases

Hypertext systemsprocesses

Event systems

Service oriented (added)

Blackboards

Layered architectures Service‐oriented (added)

© 2010 John Wiley & Sons Ltd. 4

UserGet Get memberbanks

Partial Data Flow Diagram for ATM Application

account #

Userdeposit inquiry

error errorbank name

account #& deposit

account #

ValidateValidate

eaccountdisplay

Make

Validateinquiry

Validatedeposit

Display t

account #

b l

account #& deposit

inquiryPrinter

account

t balancequery

deposit tDo

depositCreate account

accountdata

accountdatabase

deposittransaction

accountdata

deposittransaction

accountsummary


Platforms in Data Flow Architectures: An Example

Get deposit

ATM

pGet inquiryDisplay account

B kConsortium

Bankserver

Make inquiry

server

Do deposit transactionCreate account summary

Validate depositValidate depositValidate inquiry


Pipe and Filter Architecturesp

filterstream >

pipe

filter

filter

filter filter

filter

pipe

filter

< stream


Example of Pipe & Filter Data Flow Architecture

Maintain wired financial transactions. Requirement:account data

depositaccount data

account data

Bank dl

deposit data transaction result

transaction

account data

data record Logtransaction analyze

withdrawal transaction result

transaction

Commwithdrawbank address

transaction resultCo

account data© 2010 John Wiley & Sons Ltd.

8

Example of Batch Sequential Data Flow Architecture

Manage bank funds available for Requirement:mortgages & unsecured lending.

A hit t Collectmortgage funds

Account

Mortgagepool

Architecture:

Accountbalances Unsecured

poolCollect

unsecured funds p


Class Model for Batch Sequential Data Flow

Customer AccountBank

getMtgPool()

Accounts package Bank package

Customer Account getMtgPool() getUnsecurePool()


Platforms for Communicating Processors

Platform 1 Platform 2 Platform 3

execution

comunication


Example of Parallel Communicating Processes Architecture

M ATM ffi Requirement: Manage ATM traffic.

Architecture beginning with first session:

Requirement:

Architecture beginning with first session:

Customer_n:Customer:

session_m:Session

customer_n_checkingA t

create

12

3

‡:Customer: Sess o :Account

create retrieve*3

4 5deposit deposit*

5

(more work)(more work)

(thread detail omitted)*© 2010 John Wiley & Sons Ltd.

12

Example of Parallel Communicating Processes Architecture

M ATM ffi Requirement: Manage ATM traffic.

Architecture:

Requirement: customer_ s_saving : AccountArchitecture:

1 Customer_n :Customer:

session_k:Session

session_m :Session

customer_n_checkingA t

create2

3

:Customer:

customer s

Sess oSess o :Account

create

create retrieve*

retrieve*

3customer s :Customer

withdraw

deposit

retrieve4 deposit*5

© 2010 John Wiley & Sons Ltd. (thread detail omitted)*

withdraw*

13

Class Model For Parallel ExampleClass Model For Parallel Example

*Sessions

Customers

AccountSession Customer

Accountdeposit()

withdraw()retrieve()

*


State Design Pattern Applied to Encounter

RolePlayingGame

t tRPGamehandleEvent()

GameStatehandleEvent()

state

{ state.handleEvent(); }

EncounterGame


Virtual Machine Architectures:Leveraging Interpreter to Facilitate Creation of AppliationsLeveraging Interpreter to Facilitate Creation of Appliations

Application 1 Application 2

Program 1written in language

understoodby interpreter

Program 2written in language

understoodby interpreter

Interpreter

by interpreter

Interpreter

by interpreter


A Typical Repository Architecture

GUI

Analysis AnalysisControlAnalysisprocess

1

Analysisprocess

n…...…...

Control

DBMS1 n

DatabaseKey:Control flow: DatabaseControl flow:Data flow:


Layered Architecture

3D engine layer

Role-playing game layer «uses»

Characters LayoutRolePlayingGame

Application layer «uses»

EncounterCharacters

EncounterEnvironment

Encounter Game


Framework LayerFramework Layer

Application LayerFramework Layer A

PI

Framework LayerApplication Framework

LibrarySVX Library

rOffic

e

Infrastructure LayerStar

From http://www.openoffice.org/white_papers/tech_overview/tech_overview.html#3


Layered Architecture Example Using AggregationAggregation

Architecture:Ajax bank printing Layer

A t L Aj b k lib L

“uses”

Cl d l

Accounts Layer Ajax bank common library LayerVendor-supplied Layer

Class model:(relationships withinpackages not shown)

Ajax bank printing

Printer PageFormatter

Accounts

Account CustomerVendor-suppliedlayer not shown

Ajax bank common library

layer not shown

AjaxLogo AjaxDisclaimer Regulations


Service‐Oriented Architectures

Based on components that provide functionality according to an interface spec.– Principally via Web services – In the spirit of façade objects– Not necessarily OO

Example: An application concerning orders. Wouldn’t assume an Order class known to all– Wouldn’t assume an Order class known to all

– Instead: Define an order schema; reference when Web services involve orders

© 2010 John Wiley & Sons Ltd.

Web services involve orders

21

Service‐Oriented Architectures 2 of 2• “Fire and forget”

– Stateless as much as possibleStateless as much as possible

• Extensible– Additional functionality easily added

• Discoverable

f Q li f S i• Account for Quality of Service– E.g., security


Many of these points are from Service-Oriented Architecture by T. Erl

22

Service‐Oriented Architectures 3 of 3

• “Fire and forget”– Stateless as much as possible

• Extensible– Additional functionality easily added

• Discoverable• Account for Quality of ServiceAccount for Quality of Service

– E.g., security


Many of these points are from Service-Oriented Architecture by T. Erl

23

Layering for Service‐Oriented Architectures

Appplication A(.NET)

Appplication C(Legacy)

Application B(JEE)

Service Interface Layer

«uses»

«uses»

Business Process Layer

Adapted from Erl: “Service-Oriented Architectures”© 2010 John Wiley & Sons Ltd.

24

3-Tier Architecture Aternative3 Tier Architecture Aternative

VSGUIs VSDataVSOperations

Presentationtier

Middletier

Datatier


Alternative Architecture for a Video Store Application

DVRentalsDVDs

VSCustomersSCusto e s


Comparing Architectures

Three-tier Alternative

Understand-able?

Yes Yesable?

Flexible?Yes: GUI easy to change Yes: Basic building blocks

easy to identify.y y

Reusable?Not very: Each layer is special to Video Store

Yes: Easy to generalize to generic rentalsp

rentals.g

Easy to Perhaps Yes: Clear potential to use F dconstruct? Façade.


IEEE 1016‐1998 SDD Example Table of Contents

1. Introduction1 1 P

4. Dependency description4 1 I t d l d d i1.1. Purpose

1.2. Scope 1.3. Definitions, acronyms

& abbreviations2 f

4.1 Inter-module dependencies4.2 Inter-process dependencies4.3 Data dependencies

5. Interface description

Architecture

2. References3. Decomposition description

3.1. Module decomposition3 1 1 Module 1 description

5.1 Module interface5.1.1 Module 1 description5.1.2 Module 2 description

5 2 Process interface3.1.1 Module 1 description3.1.1 Module 2 description

3.2 Concurrent process decomposition

3 2 1 Process 1 description

5.2 Process interface5.2.1 Process 1 description5.2.2 Process 2 description

6. Detailed design3.2.1 Process 1 description3.2.2 Process 2 description

3.3 Data decomposition3.3.1 Data entry 1 description

6.1 Module detailed design6.1.1 Module 1 detail6.2.2 Module 2 detail

6.2 Data detailed design3.3.2 Data entry 2 description

g6.2.1 Data entity 1 detail6.2.2 Data entity 2 detail


Schedule Following Architecture Selection

Month 1 Month 2 Month 3 Month 4 Month 5Month 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 Complete testingFreeze requirementsMilestonesRelease to production

Complete testingq

Characters I Integration& T t I

I i 1

Characters IIRolePlayingG I

EncounterCharacters I

& Test I

EncounterIteration 1 Game I

L t I

EncounterGame I Integration

& Test IIRolePlayingGame I

EncounterCharacters II

Iteration 2

Layout I

EncounterLayout I

Layout I

EncounterGame II

yEncounterLayout II


RPG Framework for Role‐Playing Video Games

CharactersRolePlayingGame

stateRPGamehandleEvent()

stateGameCharacter

0..n

GameState


G E i tGameStatehandleEvent()RPGEvent

2GameLayout

GameEnvironment

ArtifactsGameArea

For future l GameAreaConnectionreleases


Architecture / Modularization of EncounterArchitecture / Modularization of Encounter

EncounterGame

EncounterGameEncounterCharacters

EncounterCastEncounterCast

EncounterEnvironmentEncounterEnvironment

EncounterEnvironmentEncounterEnvironment


RPG Framework for Role‐Playing Video Games

CharactersRolePlayingGame

stateRPGamehandleEvent()

stateGameCharacter

0..n

GameState


G E i tGameStatehandleEvent()RPGEvent

2GameLayout

GameEnvironment

ArtifactsGameArea

For future l GameAreaConnectionreleases


FrameWork / Application Dependency

Characters GameEnvironment RolePlayingGame

«uses»

Encounter video game layer

Role-playing game layer (framework)

EncounterGame«uses»*«uses»

Encounter video game layer

EncounterGameEncounterCast

EncounterCharactersEncounterEnvironment

* by member classes implemenEncounterEnvironment

* by member classes implemen-ting framework interfaces


Architecture of Eclipse 1: Overall

Plug-In Development Environment

Java Development Tools depends on

Platform

Adapted from “Contributing to Eclipse” p5


Architecture of EclipseArchitecture of EclipseUI

WorkbenchWorkbench

JFaceJava Development Tools

SWTJava Development Tools

Java Core

Core: Workspace

Core: Runtime

[“Contributing to Eclipse p282]


Architecture of Eclipse 2: The PlatformpUI

Workbench

Java Development Tools

Plug-In Development EnvironmentJFace

Standard Widget Toolset

PlatformCore

depends on

Workspace

Runtime

[Adapted from “Contributing to Eclipse” p283] AB

Key: A depends on B.


OpenOffice ArchitectureOpenOffice ArchitectureApplicationice

Dependent

FrameworkInfrastructureSt

arOf

fAP

I

Layers

Dependent

InfrastructureSystem Abstraction

S

VCLOperation System / GUI

Edit d f htt // ffi / hit /t h i /t h i ht l#3Edited, from http://www.openoffice.org/white_papers/tech_overview/tech_overview.html#3


OpenOffice Architecture

From http://www.openoffice.org/white_papers/tech_overview/tech_overview.html#3© 2010 John Wiley & Sons Ltd.38

software engineering - baylor...

Documents