Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
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?
© 2010 John Wiley & Sons Ltd.3
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
© 2010 John Wiley & Sons Ltd. 5
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
© 2010 John Wiley & Sons Ltd.6
Pipe and Filter Architecturesp
filterstream >
pipe
filter
filter
filter filter
filter
pipe
filter
< stream
© 2010 John Wiley & Sons Ltd.7
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
© 2010 John Wiley & Sons Ltd.9
Class Model for Batch Sequential Data Flow
Customer AccountBank
getMtgPool()
Accounts package Bank package
Customer Account getMtgPool() getUnsecurePool()
© 2010 John Wiley & Sons Ltd.10
Platforms for Communicating Processors
Platform 1 Platform 2 Platform 3
execution
comunication
© 2010 John Wiley & Sons Ltd.11
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()
*
© 2010 John Wiley & Sons Ltd.14
State Design Pattern Applied to Encounter
RolePlayingGame
t tRPGamehandleEvent()
GameStatehandleEvent()
state
{ state.handleEvent(); }
EncounterGame
© 2010 John Wiley & Sons Ltd.15
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
© 2010 John Wiley & Sons Ltd.16
A Typical Repository Architecture
GUI
Analysis AnalysisControlAnalysisprocess
1
Analysisprocess
n…...…...
Control
DBMS1 n
DatabaseKey:Control flow: DatabaseControl flow:Data flow:
© 2010 John Wiley & Sons Ltd.17
Layered Architecture
3D engine layer
Role-playing game layer «uses»
Characters LayoutRolePlayingGame
Application layer «uses»
EncounterCharacters
EncounterEnvironment
Encounter Game
© 2010 John Wiley & Sons Ltd.18
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
© 2010 John Wiley & Sons Ltd.19
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
© 2010 John Wiley & Sons Ltd. 20
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
© 2010 John Wiley & Sons Ltd.
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
© 2010 John Wiley & Sons Ltd.
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
© 2010 John Wiley & Sons Ltd.25
Alternative Architecture for a Video Store Application
DVRentalsDVDs
VSCustomersSCusto e s
© 2010 John Wiley & Sons Ltd.26
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.
© 2010 John Wiley & Sons Ltd.27
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
© 2010 John Wiley & Sons Ltd.28
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
© 2010 John Wiley & Sons Ltd.29
RPG Framework for Role‐Playing Video Games
CharactersRolePlayingGame
stateRPGamehandleEvent()
stateGameCharacter
0..n
GameState
{ state.handleEvent(); }
G E i tGameStatehandleEvent()RPGEvent
2GameLayout
GameEnvironment
ArtifactsGameArea
For future l GameAreaConnectionreleases
© 2010 John Wiley & Sons Ltd.30
Architecture / Modularization of EncounterArchitecture / Modularization of Encounter
EncounterGame
EncounterGameEncounterCharacters
EncounterCastEncounterCast
EncounterEnvironmentEncounterEnvironment
EncounterEnvironmentEncounterEnvironment
© 2010 John Wiley & Sons Ltd.31
RPG Framework for Role‐Playing Video Games
CharactersRolePlayingGame
stateRPGamehandleEvent()
stateGameCharacter
0..n
GameState
{ state.handleEvent(); }
G E i tGameStatehandleEvent()RPGEvent
2GameLayout
GameEnvironment
ArtifactsGameArea
For future l GameAreaConnectionreleases
© 2010 John Wiley & Sons Ltd.32
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
© 2010 John Wiley & Sons Ltd. 33
Architecture of Eclipse 1: Overall
Plug-In Development Environment
Java Development Tools depends on
Platform
Adapted from “Contributing to Eclipse” p5
© 2010 John Wiley & Sons Ltd.34
Architecture of EclipseArchitecture of EclipseUI
WorkbenchWorkbench
JFaceJava Development Tools
SWTJava Development Tools
Java Core
Core: Workspace
Core: Runtime
[“Contributing to Eclipse p282]
© 2010 John Wiley & Sons Ltd.35
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.
© 2010 John Wiley & Sons Ltd.36
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
© 2010 John Wiley & Sons Ltd.37
OpenOffice Architecture
From http://www.openoffice.org/white_papers/tech_overview/tech_overview.html#3© 2010 John Wiley & Sons Ltd.38