Software Engineering
Modern Approaches
Eric Braude and Michael Bernstein
1
Chapter 18: Software Architecture
© 2010 John Wiley & Sons Ltd.
2
Learning Goals of This Chapter
Planning
Maintenance
Testing
The Software
Development
Requirements
Lifecycle
analysis
Implementation
•
How do you classify “software
architectures?”
•
What are data flow architectures?
•
What are three-tier architectures and
their generalizations?
•
What makes database-centric
systems a separate type of
architecture?
•
What are service-oriented
architectures?
•
What are the IEEE standards for
expressing designs?
•
What do real-world architectures look
like?
Design
Phase most
relevant to this
chapter is shown in
bold
3
© 2010 John Wiley & Sons Ltd.
Categorization of Software Architectures
(Shaw & Garlan)
 Dataflow architectures
 Virtual machines
 Pipes and Filters
 Interpreters
 Batch sequential
 Rule-based systems
 Independent components
 Repository architectures
 Client-server systems
 Databases
 Parallel communicating
processes
 Hypertext systems
 Event systems
 Service-oriented (added)
© 2010 John Wiley & Sons Ltd.
 Blackboards
 Layered architectures
4
Partial Data Flow Diagram for ATM Application
member
banks
bank
nam
e
Get
deposit
Get
inquiry
User
error
account #
account #
& deposit
account
display
Validate
inquiry
Validate
deposit
account #
& deposit
Display
account
© 2010 John Wiley & Sons Ltd.
account #
Make
inquiry
Printer
account
data
Do
deposit
transaction
error
deposit
transaction
balance
query
account
database
account
data
Create
account
summary
5
Platforms in Data Flow Architectures: An Example
ATM
Get deposit
Get inquiry
Display account
Consortium
server
Bank
server
Make inquiry
Do deposit transaction
Create account summary
Validate deposit
Validate inquiry
6
© 2010 John Wiley & Sons Ltd.
Pipe and Filter Architectures
stream >
filter
pipe
filter
filter
filter
filter
pipe
filter
< stream
7
© 2010 John Wiley & Sons Ltd.
Example of Pipe & Filter Data Flow Architecture
Requirement: Maintain wired financial transactions.
account data
account data
account data
Bank
data
transaction
deposit
deposit data
analyze
Comm
bank address
transaction
withdrawal
transaction result
record
Log
transaction result
withdraw
account data
8
© 2010 John Wiley & Sons Ltd.
Example of Batch Sequential Data Flow Architecture
Requirement: Manage bank funds available for
mortgages & unsecured lending.
Architecture:
Account
balances
Collect
mortgage funds
Mortgage
pool
Collect
unsecured funds
Unsecured
pool
9
© 2010 John Wiley & Sons Ltd.
Class Model for Batch Sequential
Data Flow
Accounts package
Customer
Bank package
Bank
Account
getMtgPool()
getUnsecurePool()
10
© 2010 John Wiley & Sons Ltd.
Platforms for Communicating Processors
Platform 1
Platform 2
Platform 3
comunication
execution
11
© 2010 John Wiley & Sons Ltd.
Example of Parallel Communicating Processes Architecture
Requirement: Manage ATM traffic.
Architecture beginning with first session:
session_m
:Session
Customer_n
:Customer:
1
customer_n_
checking
:Account
‡
2
create
retrieve*
4
deposit
deposit*
3
5
(more work)
(thread detail omitted)*
© 2010 John Wiley & Sons Ltd.
12
Example of Parallel Communicating Processes Architecture
Requirement: Manage ATM traffic.
customer_
s_saving
: Account
Architecture:
1
Customer_n
session_m
:Session
:Customer:
session_k
:Session
2
customer s
create
retrieve*
:Customer
customer_n_
checking
:Account
3
create
retrieve*
4 deposit
withdraw
© 2010 John Wiley & Sons Ltd.
5
deposit*
withdraw*
(thread detail omitted)*
13
Class Model For Parallel Example
Customers
Sessions
* Account
Session
*
Customer
deposit()
withdraw()
retrieve()
14
© 2010 John Wiley & Sons Ltd.
State Design Pattern Applied to Encounter
RolePlayingGame
state
RPGame
handleEvent()
GameState
handleEvent()
{ state.handleEvent(); }
EncounterGame
15
© 2010 John Wiley & Sons Ltd.
Virtual Machine Architectures:
Leveraging Interpreter to Facilitate Creation of Appliations
Application 1
Application 2
Program 1
written in language
understood
by interpreter
Program 2
written in language
understood
by interpreter
Interpreter
Interpreter
16
© 2010 John Wiley & Sons Ltd.
A Typical Repository Architecture
GUI
Analysis
process
1
Control
…...
…...
Analysis
process
n
DBMS
Key:
Control flow:
Data flow:
Database
17
© 2010 John Wiley & Sons Ltd.
Layered Architecture
3D engine layer
Role-playing game layer
Characters
«uses»
RolePlayingGame
«uses»
Application layer
Encounter
Characters
Layout
Encounter
Environment
Encounter Game
18
© 2010 John Wiley & Sons Ltd.
StarOffice API
Framework Layer
Application Layer
Framework Layer
Application Framework
Library
SVX Library
Infrastructure Layer
From http://www.openoffice.org/white_papers/tech_overview/tech_overview.html#3
19
© 2010 John Wiley & Sons Ltd.
Layered Architecture Example Using
Aggregation
Architecture:
“uses”
Ajax bank printing Layer
Ajax bank common library Layer
Accounts Layer
Vendor-supplied Layer
Class model:
(relationships within
packages not shown)
Ajax bank printing
Printer
Formatter
Page
Accounts
Account
Vendor-supplied
layer not shown
Customer
Ajax bank common library
AjaxLogo
© 2010 John Wiley & Sons Ltd.
AjaxDisclaimer
Regulations
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
– Instead: Define an order schema; reference when
Web services involve orders
© 2010 John Wiley & Sons Ltd.
21
Service-Oriented Architectures 2 of 2
• “Fire and forget”
– Stateless as much as possible
• Extensible
– Additional functionality easily
added
• Discoverable
• Account for Quality of Service
– E.g., security
Many of these points are from Service-Oriented Architecture by T. Erl
© 2010 John Wiley & Sons Ltd.
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 Service
– E.g., security
Many of these points are from Service-Oriented Architecture by T. Erl
© 2010 John Wiley & Sons Ltd.
23
Layering for Service-Oriented Architectures
Appplication A
(.NET)
Application B
(JEE)
Appplication C
(Legacy)
«uses»
Service Interface Layer
«uses»
Business Process Layer
Adapted from Erl: “Service-Oriented Architectures”
© 2010 John Wiley & Sons Ltd.
24
3-Tier Architecture Aternative
VSGUIs
Presentation
tier
VSOperations
Middle
tier
VSData
Data
tier
25
© 2010 John Wiley & Sons Ltd.
Alternative Architecture for a Video Store Application
DVRentals
DVDs
VSCustomers
26
© 2010 John Wiley & Sons Ltd.
Comparing Architectures
Three-tier
Understand- Yes
able?
Alternative
Yes
Yes: GUI easy to change Yes: Basic building blocks
Flexible?
easy to identify.
Not very: Each layer is
Reusable? special to Video Store
rentals.
Easy to Perhaps
construct?
Yes: Easy to generalize to
generic rentals
Yes: Clear potential to use
Façade.
27
© 2010 John Wiley & Sons Ltd.
IEEE 1016-1998 SDD Example Table of Contents
1. Introduction
1.1.
Purpose
1.2.
Scope
Architecture
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
4. Dependency description
4.1 Inter-module dependencies
4.2 Inter-process dependencies
4.3 Data dependencies
5. 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 description
6. 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
28
© 2010 John Wiley & Sons Ltd.
Schedule Following Architecture Selection
Month 1
Month 2
Month 3
Month 4
Month 5
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Milestones
Freeze requirements
Characters I
Encounter
Characters I
Iteration 1
RolePlaying
Game I
Encounter
Game I
Layout I
Encounter
Layout I
© 2010 John Wiley & Sons Ltd.
Complete testing
Release to production
Integration
& Test I
Characters II
Encounter
Characters II
RolePlaying
Game I
Encounter
Game II
Layout I
Encounter
Layout II
Integration
& Test II
Iteration 2
29
RPG Framework for Role-Playing Video Games
RolePlayingGame
RPGame
Characters
state
GameCharacter
handleEvent()
0..n
{ state.handleEvent(); }
RPGEvent
GameState
GameEnvironment
handleEvent()
GameLayout
2
GameArea
Artifacts
For future
releases
GameAreaConnection
30
© 2010 John Wiley & Sons Ltd.
Architecture / Modularization of Encounter
EncounterGame
EncounterGame
EncounterCharacters
EncounterCast
EncounterEnvironment
EncounterEnvironment
31
© 2010 John Wiley & Sons Ltd.
RPG Framework for Role-Playing Video Games
RolePlayingGame
RPGame
Characters
state
GameCharacter
handleEvent()
0..n
{ state.handleEvent(); }
RPGEvent
GameState
GameEnvironment
handleEvent()
GameLayout
2
GameArea
Artifacts
For future
releases
GameAreaConnection
32
© 2010 John Wiley & Sons Ltd.
FrameWork / Application Dependency
Characters
GameEnvironment
RolePlayingGame
Role-playing game layer (framework)
«uses»
Encounter video game layer
«uses»*
«uses»
EncounterCast
EncounterGame
EncounterGame
EncounterCharacters
EncounterEnvironment
* by member classes implementing framework interfaces
© 2010 John Wiley & Sons Ltd.
EncounterEnvironment
33
Architecture of Eclipse 1: Overall
Plug-In Development Environment
 depends on
Java Development Tools

Adapted from “Contributing to Eclipse” p5
Platform
34
© 2010 John Wiley & Sons Ltd.
Architecture of Eclipse
UI
Workbench
JFace
Java Development Tools
SWT
Java Core
Core: Workspace
Core: Runtime
[“Contributing to Eclipse p282]
35
© 2010 John Wiley & Sons Ltd.
Architecture of Eclipse 2: The Platform
UI
Workbench
JFace
Plug-In Development Environment
Standard Widget Toolset
Java Development Tools
Platform
Core
 depends on
Workspace
Runtime
Key:
A
B
A depends on B.
[Adapted from “Contributing to Eclipse” p283]
36
© 2010 John Wiley & Sons Ltd.
StarOffice
API
OpenOffice Architecture
Application
Dependent 
Framework
Infrastructure
System Abstraction
VCL
Operation System / GUI
Layers
Edited, from http://www.openoffice.org/white_papers/tech_overview/tech_overview.html#3
37
© 2010 John Wiley & Sons Ltd.
OpenOffice Architecture
© 2010 John Wiley & Sons Ltd.
38
From http://www.openoffice.org/white_papers/tech_overview/tech_overview.html#3